【行业前沿报告】Anthropic - Agent 评测：从结果验证到可靠交付

文章目录1. 先定义评测对象到底在测谁轨迹与结果为什么都要看2. 评分器分工哪些交给代码哪些需要判断部分得分和任务通过应分别报告模型评分器也需要被检查3. 四类 Agent需要不同的成功证据4. passk 与 pass^k找到一次答案和每次都成功先看一个理想化例子有限次运行怎样估计5. 任务质量先确保题目和判卷标准一致给每个任务准备一个能通过的参考解正例与反例要一起设计6. 环境与评分防止测量本身制造假象隔离运行还要保护裁判看轨迹时先定位证据断在哪里7. 能力集与回归集给不同阶段留下信号从第一批任务到持续维护8. 离线分数之外还缺哪些证据9. 一份小示例为什么“只看状态”会漏判框架解决执行任务定义决定测量价值参考文献摘要本文围绕 Agent 评测展开一套可检查的设计方法。先区分任务、尝试、轨迹与结果明确评测对象再按证据类型划分代码、模型与人工评分器并强调部分得分与任务通过应分别报告。随后按编码、对话、研究、电脑操作四类 Agent 给出不同的成功证据并对比 passk 与 pass^k 两种指标的含义与估计方式。文章还讨论了任务质量参考解、正反例、环境隔离与评分防假象、能力集与回归集的维护以及离线分数之外的线上证据。最后通过一个退款评分小示例说明“只看状态”为何会漏判并给出可落地的执行顺序与工具选型建议。任务确实完成了吗换一种对话还能完成吗分数下降时出错的是智能体还是评测器假设一个售后智能体需要为订单退回 80 元。它查了规则解释得体最后说“退款已完成。”如果数据库里没有退款记录这次任务仍然失败。另一条轨迹真的退了款却跳过了用户确认只检查最终余额又会把它判为成功。这两个例子暴露了 Agent 评测的困难一句回答、一次工具调用、一个最终状态分别只能提供一部分证据。系统还可能在相同任务的下一次尝试中走出另一条路径。Anthropic 于2026 年 1 月 9 日发表的Demystifying evals for AI agents提供了一个起点分清任务、尝试、轨迹和结果组合评分方法分别衡量能力与回归持续把真实失败变成测试。[1] 本文沿着这些问题结合 τ-bench、HumanEval 和官方评测文档展开一套可检查的设计方法。退款场景、评分组合与数值例子均为原创教学示例。先看一轮评测如何产生证据再讨论该怎样解释分数图 1一次 Agent 评测的结构。中心表示评测阶段左侧给出任务条件与运行配置右侧区分过程记录和环境结果。组合评分需要明确各类证据的用途。概念与布局为原创参考文献 [2]、[3]、[11]。1. 先定义评测对象到底在测谁给大模型一段文字、检查返回答案通常可以把测试对象理解为一次模型调用。Agent 会读取信息、调用工具、改变环境、接收返回再继续行动。此时一个最终分数包含了多个组件共同工作的结果。同一个模型换一套工具描述、重试机制或上下文整理方式完成率可能改变。因此要区分两套框架Agent harness智能体运行框架组织模型输入、工具调用、上下文、执行状态与恢复。Evaluation harness评测框架准备任务和环境启动尝试收集证据调用评分器汇总结果。前者属于被测系统后者负责测量。评测框架可能复用生产运行框架但二者的职责不能混在一起。Harbor 将任务组织为指令、环境与验证脚本并把一次执行称为 trialLangSmith 则将指定应用版本在数据集上的运行及评分记录为 experiment。[3][11]概念在退款例子中指什么记录时应保留什么Task任务为指定订单处理一次符合规则的退款输入、规则、初始状态、成功条件Trial一次尝试从规定初始状态开始的一次完整运行尝试编号、配置、预算与终止原因Transcript / trace轨迹用户消息、模型输出、工具调用及真实返回接口实际可见的过程记录Outcome结果状态退款是否创建金额、对象及次数是否正确权威数据源的状态或已保存的产物Grader评分器核验退款记录检查授权评价解释质量标准版本、证据与判定理由Suite评测集正常退款、超期拒绝、重复申请等用例集合覆盖范围、来源、分组与版本轨迹与结果为什么都要看结果回答“世界最后变成了什么样”轨迹帮助回答“怎样变成这样的”。二者不能互相替代。τ-bench 使用最终数据库状态和必要回复信息判定任务完成但论文明确指出某些状态正确的尝试仍可能违反过程规则例如未经确认就操作。[2, §3] 这是一条很实用的边界状态验证强于口头承诺但状态正确仍可能不足以证明完整成功。回到本文的假设任务至少要分开检查三个条件款项是否正确退回操作是否得到有效授权回复是否准确反映执行结果。礼貌的解释不能抵消未授权操作失败后的诚实说明也不能被记为退款成功。2. 评分器分工哪些交给代码哪些需要判断一个任务可以有多个评分器每个评分器也可以包含多个检查项。选评分器时先问证据是否明确再问判断是否需要理解语义。LangSmith 官方文档区分代码、模型和人工等评价方式并说明模型评分可以使用或不使用参考答案。[3]评分方式本文示例中的工作能直接提供的证据需要防范的失效代码评分检查退款金额、订单、重复支付、测试结果明确条件是否满足可定位到具体断言条件写错、数值容差不合理、只接受一种合法输出模型评分判断回复是否解释了处理结果是否与工具证据矛盾对开放表达作语义判断偏好长答案、忽略反证、评分随提示和模型变化人工评分裁决复杂规则争议校准模型评分领域判断与分歧解释人员标准不一致、成本高、覆盖有限这三类方法之间没有统一的优劣排名。检查refund.amount 80不需要另一个模型猜判断用户是否听懂解释则很难只靠关键词。可以把评分过程拆成以下层次图 2组合评分的职责划分。代码规则与模型判断并行提供维度结果虚线将人工校准关联到评分面板不要求每次运行都执行。硬性条件参与最终裁决不能被其他维度的高分抵消。布局与组合规则为原创参考文献 [3]、[4]。部分得分和任务通过应分别报告假设一次尝试完成了身份核验也找到了正确规则但退款工具返回失败。它比一开始就选错用户更接近目标这个进展可以作为诊断分数保留对用户而言钱仍未退回。本文为该示例定义任务通过 结果正确 ∧ 授权有效 ∧ 无重复操作 ∧ 回复与证据一致。解释质量、轮次数和成本另外记录。若产品还要求必须完成通知可以将通知加入硬性条件。哪些条件能够加权、哪些不能补偿要由任务要求决定不能在看到分数后临时更改。对于能够补偿的质量维度可以按预先约定的权重汇总二值判定则要求必要检查全部通过。也可以采用混合方式先通过硬性条件再达到质量阈值。三种汇总方式测量的目标不同报告时要明确规则。这个设计避免一种常见误读平均质量分升高不一定意味着更多任务可靠完成。报告多个维度的价值是让失败原因可见而不是让错误被平均掉。模型评分器也需要被检查Judging LLM-as-a-Judge在对话评价设置中研究了位置、冗长和自我偏好等偏差。[4] 这些结果不能直接给出某个业务评分器的误差率但说明“换一个强模型打分”不足以建立信任。一个可操作的校准办法是先建立人工裁决的小型证据集包含以下对照短而正确的回复长而错误的回复措辞漂亮但违背工具返回的回复以及证据不足的回复。然后逐项比较模型判定与人工理由。评分提示要说明每个等级所需的证据并允许“证据不足”。对于信息缺失的轨迹评分器不能根据智能体的自述补出并不存在的退款记录。多个评分维度可以分别判断防止语气、完整性和事实正确性互相干扰这些是本文的评分设计建议。3. 四类 Agent需要不同的成功证据评测对象的分类应该跟工作产物有关。代码、对话、研究和电脑操作都可能经过很多轮但各自的成功证据不同。Agent 类型一份明确的任务核心结果证据额外需要看的过程编码修复空密码仍可登录的漏洞新测试通过既有行为未被破坏是否改坏接口是否删除或绕过测试对话处理退款或解释为何不能退款与规则一致的业务状态和必要回复是否确认授权是否提供了错误承诺研究查证某项指标并形成分析事实、来源、关键问题覆盖引用是否支持对应主张是否忽略冲突证据电脑操作修改应用设置并保存文件实际配置、文件或后台状态操作是否落在正确对象上是否留下无关修改编码任务的验证通常可以运行测试。SWE-bench 的评测基础设施在规定环境中执行代码并生成结果报告在自己的任务里还要确认测试真正覆盖需求。[5] “测试全绿”可能说明测试充分也可能说明没有测到漏洞。可以加入独立的反例输入检查失败条件是否被修复。对话任务除了工具结果还包含信息收集和用户协作。τ-bench 模拟用户与 API 交互τ²-bench 进一步研究用户与智能体都能修改共享环境的双控制场景。[2][6] 例如远程排障时客服给出正确指令用户却没有执行环境仍然没有修好。评测不能把“指导说得对”直接当成“问题已解决”。研究任务要把查找事实与形成可靠综合判断分开。BrowseComp 面向难以检索、答案容易验证的问题不能代表所有研究报告的质量。[7] 对本文假设的指标分析还应预先列出必须覆盖的问题并逐条检查来源、时间口径和相互矛盾的信息。命中一个正确数字并不保证推导出的趋势成立。电脑操作尤其需要检查保存后的产物。WebArena 强调网页任务的功能性完成OSWorld 提供桌面任务的初始化与执行验证。[8][9] 点到了“保存”按钮是动作证据正确目录里出现可打开的目标文件才是结果证据。本文讨论这些基准的验证思路不比较不同版本的榜单分数。浏览器操作还需要记录工具选择与成本。Anthropic 原文讨论了文档结构读取和截图之间的令牌、延迟取舍这个例子不能推出一种接口在所有任务上更高效。[1] 在自己的评测中可以将同一任务、相同预算下的耗时和令牌数与完成条件一起记录。4. passk 与 pass^k找到一次答案和每次都成功某个任务运行三次结果是成功、失败、成功。这个智能体能做成任务但它的服务是否足够稳定还需要另一个问题来衡量。passk问k 次尝试里至少一次成功的概率是多少pass^k问k 次尝试全部成功的概率是多少τ-bench 用后一指标研究重复运行的一致性。[2, §3] HumanEval 的官方实现提供了 passk 的有限样本估计。[10]图 3同一组运行结果可以回答不同问题。“独立尝试”要求每轮按协议重置中央表示收集与统计过程不表示后一次尝试继承前一次的答案。候选选择是产品实现需要额外解决的问题。指标定义参考文献 [2]、[10]布局为原创。先看一个理想化例子设单个任务每次成功概率固定为 pk 次尝试独立且同分布则passk 1 − (1 − p)ᵏpass^k pᵏ。令 p 0.75得到下表。数字由公式计算是教学示例未测量任何模型。尝试次数 k至少一次成功passk全部成功pass^k175.00%75.00%398.44%42.19%599.90%23.73%10约 100.00%5.63%“约 100.00%”只是显示精度下的四舍五入。随着 k 增大一个指标更容易达标另一个更难达标。只有在这个单任务、固定 p 的假设下才可以直接用上述幂次计算。若某些任务总能成功、另一些从不成功平均 pass1 也可能是 75%。这时增加尝试并不会让整体 passk 像表中那样上升。不同任务应先分别统计再按约定口径汇总不能先取整体平均 p再套非线性公式。有限次运行怎样估计对于同一任务设已运行 n 次其中 c 次成功且 1 ≤ k ≤ n。用 C(a, k) 表示从 a 个元素里选出 k 个的组合数当 a k 时取零。passk 的估计 1 − C(n − c, k) / C(n, k)。pass^k 的估计 C(c, k) / C(n, k)。第一式排除“挑出的 k 次全部失败”第二式计算“挑出的 k 次全部成功”。在独立同分布的采样假设下它们是相应概率的无偏估计。[2][10]例如 n 4、c 3、k 2共有六种两次尝试的组合。每一组至少有一次成功所以 pass2 的估计为 100%只有三组全部成功所以 pass^2 的估计为 50%。它与直接代入(3/4)² 56.25%不同。配套计算脚本给出了这个例子与上表。估计值不是精确的未来成功率。运行次数少时应一并报告任务数、每任务的 n 与 c以及估计的不确定性避免让一个显示为100%的数值承诺超出证据的可靠性。还要区分统计指标与产品交付。passk 很高只说明候选中可能有正确解产品仍需可靠验证器选出它并支付额外计算成本。pass^k 则衡量对同一底层任务的重复表现不等于连续业务流程中 k 个不同步骤都成功。共享缓存、前次答案或一起发生的工具故障会破坏独立性假设。5. 任务质量先确保题目和判卷标准一致一个低分可能来自三处系统不会做题目没有讲清楚或者评分器拒绝了合法结果。需要通过可复查的证据把它们分开。假设任务要求“写一个解析脚本”评分器却只在一个未告知的固定路径下找文件。智能体把脚本写到了另一个合理位置失败是规格与验证不一致造成的。若路径很重要应写进任务若不重要评分器应按合理方式发现产物。给每个任务准备一个能通过的参考解参考解的作用是验证题目可完成、环境能运行、评分器能接受正确产物。它不要求智能体复制同一条工具路径。Harbor 的任务结构将参考解决方案、环境与测试分开保存适合把这些检查变成可重复运行的资产。[11]本例可以同时准备四类参考结果合法退款、正确拒绝、证据不足时请求补充、执行失败后准确说明。它们都是合理业务行为是否算“成功”取决于各自的任务定义不能把全部任务都设成必须退款。正例与反例要一起设计只测试“需要检索时是否检索”无法惩罚不必要的搜索。本文建议以同一业务边界成对构造用例应退款与不应退款应继续自动执行与应请求确认证据足够与证据不足。检查维度正例反例揭示的问题触发行为满足条件时执行退款不满足条件时仍执行说明过度触发用户授权明确确认后操作模糊回应被当成确认幂等与重复一次请求只产生一笔有效退款重试导致重复支付结果说明根据真实返回解释结果工具失败后仍声称已完成Anthropic 给出的早期起步建议是从20–50 个真实失败相关任务开始大量尝试仍为零分时应检查任务和评分器。[1] 这不是所有阶段都足够的样本量也不是“零分必然是假题”。接近版本选择时要看任务覆盖、效果大小和运行方差小幅提升尤其需要更多证据。不能只积累失败保留典型成功场景才能知道修复某个难例是否破坏了其他行为。难例集用于暴露边界代表真实流量的集合用于估计产品表现两者应有不同标签和汇总口径。6. 环境与评分防止测量本身制造假象一次尝试结束后工作目录、数据库、会话记忆和缓存都可能变化。下一次运行若继续读取它们测到的就可能是“上一轮留下的帮助”而不是规定起点下的能力。在本文的退款示例中第二轮读取第一轮已经完成的退款记录就可能不需要再执行任何动作。若任务仍被算作从零处理成功指标会虚高。反过来多轮共用限额和资源也可能制造一批相关失败。**应固定并记录模型版本、运行框架、提示与规则版本、工具权限、初始状态、预算、评分标准以及外部服务的状态。**比较两版模型时尽量让其他条件一致改变运行框架时固定模型。否则分数变化很难归因。隔离运行还要保护裁判智能体可以编辑项目文件不代表它应能修改隐藏评分器或权威业务账本。本文建议把被测产物与评分依据分开管理并记录被评分的确切版本。Harbor 官方文档提供可选的独立验证环境默认验证器仍在共享容器中运行分离需要显式配置。[12] 分离环境也不自动等于安全或正确哪些产物被传入、验证器读取什么、数据是否完整仍要检查。某个失败来自工具服务不可用不能悄悄丢掉某个智能体导致环境异常也不能自动算作基础设施故障。可以单列原因并在报告中说明重跑和剔除规则。规则应在比较前固定避免分数因选择性过滤而改变。看轨迹时先定位证据断在哪里对于退款失败依次问用户请求是否理解正确读取了哪一版规则工具参数是否对应目标订单返回是成功、失败还是超时最终状态与返回是否一致回复有没有越过证据作承诺这些问题分别指向意图、信息、决策、执行、验证与表达。只把失败写成“推理不够”无法知道该改数据、工具还是运行框架。评分结果也应保留具体失败断言方便在标准更新后重新评分。7. 能力集与回归集给不同阶段留下信号能力评测用于暴露系统还做不好的工作回归评测用于守住已承诺的行为。原文强调两者应分开成熟的能力任务可以转入回归集。[1]以退款系统为例常规单订单处理已经稳定后继续只测这类任务分数可能接近满分。下一版更擅长理解复杂请求也未必能在这套集合上表现出来。可以保留常规集再添加多订单、信息冲突、需要用户协作或恢复工具异常的任务。评测集本文示例主要使用方式能力探索集多个请求交织部分信息要澄清比较新方案并读取失败轨迹寻找边界回归保护集常规退款、正确拒绝、重复申请检查修改有没有破坏稳定行为保留验证集未用于反复改提示的独立任务降低反复调同一批题造成的过拟合能力集接近满分应增加能区分新能力的任务旧题不必删除仍可保留为回归保护。任务、规则和评分器版本一旦变化旧分数与新分数也不能直接混用。LangSmith 的文档支持数据集分组和版本管理为这种组织提供了具体工具。[3]从第一批任务到持续维护下面是本文将前述原则落成的一份执行顺序。它是可调整的工程安排不是任何框架的必填规范。收集现有人工检查、用户反馈和失败轨迹按影响整理第一批任务。写清输入、成功条件、参考解补上行为不该触发的反例。固定运行配置重置环境选择并验证评分器。多次运行保留分维度结果、预算与失败原因。人工阅读代表性轨迹检查误判与不公平失败。把修复后的用例转为回归保护当能力集饱和时扩展难度。明确基础设施、业务用例和规则版本的维护负责人保留独立验证集。图 4本文建议的评测维护流程。它连接线上反馈、离线比较与人工复核发布复核后的反馈可以继续补充用例。两侧卡片表示各阶段的检查职责连线不表示已经自动解决这些问题。参考文献 [3]、[13]流程与布局为原创。8. 离线分数之外还缺哪些证据固定任务集便于比较版本却不可能预先包含所有用户行为。LangSmith 和 Langfuse 都将离线实验与线上运行评分作为互补工作流。[3][13] 实际设计中还可以结合以下观察方式方式在示例产品中回答什么解释时的边界自动离线评测新版本在同一批退款任务上是否改善用例覆盖不足时结果不能代表所有用户生产监控工具错误、耗时或任务分布是否发生变化指标异常帮助发现问题但未必直接指出原因A/B 测试新版本是否改善真实任务完成和用户体验需要明确实验单位、流量与统计方案用户反馈哪些失败是设计时没有想到的主动反馈的人群和场景可能有选择偏差人工轨迹复查系统为什么成功或失败评分是否公平少量案例解释机制不能直接给出整体发生率系统化人工评价开放质量标准能否得到稳定共识应记录评审标准、分歧与裁决方式有反馈就立即改提示可能只修好一个场景。更有用的动作是把它变成可复现的任务说明它为何失败比较改动前后并检查相关回归用例。离线改进后再用合适的线上证据验证影响线上分数上升也需要排查任务分布是否变了。9. 一份小示例为什么“只看状态”会漏判配套素材提供了一段可直接运行的 Python 评分演示。它没有调用真实模型而是检查八条手工构造的轨迹与结果。目标订单为R-017授权退款 80 元每条记录都明确标注为合成示例。合成情况只检查最终结果加入授权与一致性检查后得到有效确认正确退款通过通过回复称已完成实际无退款失败失败正确退款但未经确认通过失败退款后才获得确认通过失败正确退款但回复称没有退款通过失败金额错误、重复退款或对象错误失败失败“只看结果”的评分接受了四条“组合评分”仅接受一条。这个差异是我们刻意构造的用来展示漏判机制不能把 4/8 或 1/8 当作真实 Agent 的成功率也没有验证模型评分器在自然语言授权识别上的效果。演示只规定必要关系有效确认必须早于退款事件。它允许额外的只读查询并未锁死完整工具调用顺序。完整程序、输入和实际运行输出都保存在素材包中。框架解决执行任务定义决定测量价值选择工具时可以按现有系统缺口比较而不必先追求功能最多的平台。下表依据各自官方页面整理不包含价格比较或性能排名。工具官方文档中可用于评测的部分采用前先明确什么Harbor任务环境、参考解、验证器与尝试执行 [11][12]是否需要可控环境产物怎样交给验证器LangSmith数据集、实验、代码/模型/人工评分与线上评测 [3]怎样接入现有轨迹怎样固定数据集版本Langfuse轨迹评分、数据集实验与人工校准 [13]哪些线上记录进入离线用例Braintrust轨迹、数据集实验与评分工作流 [14]是否要统一实验与生产问题分析Phoenix轨迹、评价、数据集与实验 [15]已有观测数据与评价标准如何复用回到开头的退款任务一份可靠的评测报告应让我们看到目标是否实现必要规则是否遵守重复运行怎样变化成本是什么以及失败能否被公平地解释。没有这些证据“看起来更好”很难转化成可验证的产品改进。参考文献Grace, M., Hadfield, J., Olivares, R., De Jonghe, J.Demystifying evals for AI agents.Anthropic 原文2026-01-09。本文的问题起点与补充阅读入口本文为独立中文技术解读未逐段翻译。Yao 等。τ-bench: A Benchmark for Tool-Agent-User Interaction in Real-World Domains.arXiv:2406.12045v12024。核对 §3 的奖励条件、过程规则限制与 pass^k、passk 估计式。LangChain。Evaluation concepts / LangSmith Evaluation.评价概念、工作流。核对评分方式、实验、数据集与线上/离线评价。Zheng 等。Judging LLM-as-a-Judge with MT-Bench and Chatbot Arena.arXiv:2306.056852023。摘要用于核对评分偏差类型不用于推断本文示例的准确率。SWE-bench。Evaluation guide.官方文档。核对运行环境、执行验证与结果报告。Barres 等。τ²-Bench: Evaluating Conversational Agents in a Dual-Control Environment.arXiv:2506.07982v12025。摘要用于核对双控制与用户协作的任务范围。BrowseComp: A Simple Yet Challenging Benchmark for Browsing Agents.arXiv:2504.125162025。摘要用于核对查找难、验证相对容易的基准定位。Zhou 等。WebArena: A Realistic Web Environment for Building Autonomous Agents.arXiv:2307.138542023。摘要用于核对功能性网页任务评价。Xie 等。OSWorld.原版项目页面。核对初始化与执行验证思路页面已提示后续版本本文不提供最新榜单比较。Chen 等。Evaluating Large Language Models Trained on Code.HumanEval 论文2021官方评价实现。passk 估计按官方实现核对未复现模型实验。Harbor。Tasks overview.官方文档。核对任务结构、参考解决方案、试验和验证脚本。Harbor。Separate verifier.官方文档。核对默认共享与可选独立验证环境。Langfuse。Evaluation overview.官方文档。核对线上评分、离线实验与人工校准入口。Braintrust。Observability and evals.官方页面。仅核对轨迹、数据集、评分和实验工作流。Arize。What is Arize Phoenix?官方文档。核对观测、评价与数据集实验功能。