从“会不会做”到“能否稳定交付”：AI Agent 评测体系的工程化方法论

目录

一、Agent 时代，评测对象已经发生了根本变化

（一）传统“输入—输出—打分”为什么不够了

1、从静态文本生成，转向持续改变世界状态

2、“模型能力”与“产品能力”必须分开

（二）真正的 ground truth 往往在 outcome，而不在 transcript

1、最终状态应该优先于“看起来像成功”

2. 结果负责定输赢，轨迹负责解释原因

二、把一个 Agent eval 拆开：你真正需要设计的是什么

（一）Task、Trial、Grader、Trace、Outcome 是五个不同问题

1、Task：不是一道“题”，而是一份可执行契约

2、Trial：一次运行不能代表一个随机系统

3、Grader：评分器本身也是一个需要被验证的软件系统

4、Trace：不是为了监控每一步，而是为了定位失效机制

5、Outcome：最好能被独立验证

（二）Evaluation harness：测量系统也要有“测量学纪律”

1、环境漂移会把假问题伪装成模型问题

2. 推荐记录的最小运行元数据

三、从“能力”走向“可靠交付”：为什么一次成功远远不够

（一）pass@k 与 pass^k 讲的是两种完全不同的产品故事

1、pass@k：多给几次机会，至少成功一次

2、pass^k：连续 k 次都成功

（二）长链路任务的真正敌人，是可靠性乘法

1、单步看起来很高的成功率，串起来可能非常脆弱

2. 需要把“恢复能力”也纳入评测

（三）评测结果不应该只有一个总分

四维评分比单一排行榜更接近生产决策

四、评分器设计：最重要的不是“智能”，而是“可验证”

（一）能用确定性检查，就不要先上 LLM Judge

1、硬事实交给代码

2、主观质量再交给模型评分器

（二）一个大而全的 Judge，通常不如多个窄 Judge

1、把评价维度拆开

2. 给 Judge “不知道”的出口

（三）结果评分与过程评分要有不同权重

1、核心业务状态通常是硬约束

2、路径约束只用于真正必要的流程

五、评测数据集设计：真正困难的是定义“什么叫成功”

（一）最好的第一批测试，通常来自真实失败

1、不需要一开始就有几百条

2、把线上失败变成永不丢失的回归资产

（二）每道题都必须先证明“它真的可解”

1、两名领域专家能否独立达成相同判断

2、Reference solution 是评测基础设施的单元测试

（三）平衡“应该做”和“不应该做”的案例

单侧数据集会制造过度行为

（四）能力集与回归集必须分开维护

1、Capability eval 要故意难

2、Regression eval 要接近全通过

六、从“一套 benchmark”升级成“评测资产组合”

（一）生产级 Agent 至少需要四类 suite

1、能力前沿集：告诉你下一座山在哪里

2、回归保护集：告诉你有没有把旧东西弄坏

3、生产回放集：告诉你离真实用户还有多远

4、对抗与策略集：告诉你系统会不会“聪明地做错事”

（二）为什么“一个总榜”容易误导团队

1、不同 suite 的目标函数本来就不同

2、发布决策应该基于门禁与权衡，而不是单一均值

七、EvalOps：把评测从研究脚本变成产品基础设施

（一）评测必须进入版本控制和 CI/CD

1、Eval 应与 prompt、tool schema、agent code 一起变更

2、每次变更都要保留可比较的实验记录

（二）失败分析是 eval 中最不能自动化掉的一环

1、定期阅读 trace 是团队理解系统的高带宽渠道

2、建立固定的失败分类法

（三）防止评测饱和和“考试教学化”

1、100% 通过的能力集已经失去研究信号

2、不能只优化榜单，必须持续验证分布外行为

八、Agent 评测正在进入第二阶段：长任务、动态世界与人机协同

（一）长任务不只是更多 token，而是更多隐藏状态

OSWorld 2.0 体现了新的难点

（二）用户不再只是出题者，而会成为环境的一部分

τ²-bench 的双控制视角非常重要

（三）时间跨度会成为重要的能力坐标

“能完成多长的人类任务”比单题正确率更有解释力

（四）多 Agent 系统会让评测更像分布式系统测试

新问题是协调、通信和共享记忆

九、一个更实用的工程框架：把 Eval 当成“可执行产品契约”

（一）产品需求必须能被翻译成机器可检查的承诺

1、每个关键能力都应对应至少一个可执行测试

2、每个关键风险也应对应一个反例测试

（二）可以引入一个“评测债务”概念

评测债务会随着系统变化速度复利

（三）最终目标不是追求最高分，而是缩短“安全改进循环”

好 eval 的本质是提高研发反馈带宽

十、落地路线：从零开始建立可用的 Agent Eval

（一）第 1 周：定义成功，而不是先选工具

1、建立 20–50 个高价值任务

2、给任务分层

（二）第 2 周：先做 outcome verifier，再做复杂 Judge

1、建立稳定环境

2、保存完整 trace 与元数据

（三）第 3 周：加入模型评分器并完成人工校准

1、只把主观问题交给 LLM Judge

2、同时测能力与可靠性

（四）第 4 周：接入 CI/CD，建立长期维护制度

1、每次关键变更自动跑回归

2、每周固定审查失败轨迹

3、每月检查评测健康度

十一、结语：真正成熟的 Agent 团队，先建设“可验证性”

可参考文章与论文

干货分享，感谢您的阅读！

当大模型从“回答问题”走向“调用工具、修改状态、持续规划并与用户协作”，传统以单轮答案为中心的评测方法开始失效。真正需要被验证的，不再只是模型能否生成一个看起来正确的结果，而是“模型 + Agent 脚手架 + 工具 + 环境 + 多轮轨迹 + 最终状态”组成的完整系统，能否在真实约束下稳定地完成任务。我们在系统吸收 Anthropic 2026 年关于 Agent eval 的工程经验基础上，进一步提出一套面向生产系统的评测框架：以最终状态为主判据、以轨迹为诊断证据；把能力、可靠性、安全性与效率拆成独立维度；用能力前沿、回归保护、生产回放与对抗策略四类评测组合成“评测资产组合”；再通过 EvalOps 把线上失败持续转化为离线测试。同时讨论 pass@k、pass^k、长链路可靠性、LLM-as-a-Judge 校准、环境隔离、任务可解性、评测饱和、动态世界与双控制交互等关键问题，并给出一套可直接落地的实施路线。

一、Agent 时代，评测对象已经发生了根本变化

（一）传统“输入—输出—打分”为什么不够了

1、从静态文本生成，转向持续改变世界状态

过去的语言模型评测通常可以被压缩成三个元素：给定一个问题，得到一个回答，再判断回答是否正确。这个范式非常适合翻译、分类、数学题、知识问答等“输出即结果”的任务。

Agent 则不同。一个真正有行动能力的 Agent 往往要读取文件、调用 API、搜索网页、修改数据库、执行代码、与用户来回确认，并依据中间结果动态调整后续动作。最终用户在意的并不是它“说了什么”，而是它究竟“做成了什么”。因此，一个客服 Agent 即使最后回复“退款已完成”，如果数据库里没有退款记录，它仍然失败；一个代码 Agent 即使解释得非常合理，如果测试没有通过，它也没有完成任务。

这意味着 Agent 的评测对象必须从“语言输出”扩展为“状态转换系统”。Anthropic 将 task、trial、grader、transcript、outcome、evaluation harness、agent harness 和 evaluation suite 分开定义，本质上是在提醒开发者：评测 Agent 时，需要先把“任务”“一次尝试”“执行轨迹”“最终状态”“评分逻辑”和“运行基础设施”解耦，否则很容易把不同层次的问题混成一个分数。[1]

微小错误会在长链路中被放大

单轮模型犯一次小错，往往只影响一次回答；Agent 在长链路里犯一次小错，则可能改变后续所有观察。比如，一个研究 Agent 在第一轮检索中把公司名称识别错了，后续引用、数据匹配、结论和建议都可能建立在错误实体之上。换句话说，Agent 不是简单地“多回答几次”，而是在一个可变环境里持续执行状态转移。

因此，评测必须回答至少四个问题：任务定义是否清楚？环境是否可信？行为轨迹是否合理？最终状态是否满足目标？只看最后一段文本，无法区分这些问题。

2、“模型能力”与“产品能力”必须分开

同一个模型装进不同 Agent harness，表现可能显著不同。工具描述是否清晰、上下文裁剪是否合理、错误重试策略是否健壮、是否允许并行、是否设置了停止条件、是否保留了正确的环境反馈，都会影响最终成功率。Anthropic 在更早的 Agent 工程文章中也强调，Agent 的工具接口和脚手架设计本身会显著影响效果，因此不能把一个 Agent 产品的结果简单归因于底层模型。[2]

这带来一个重要工程结论：模型 benchmark 不是产品验收测试。 模型 benchmark 可以告诉你底层能力的上限和趋势，但真正用于发布决策的 eval，必须尽量复现生产环境中的工具、提示词、状态、权限、预算和交互方式。

（二）真正的 ground truth 往往在 outcome，而不在 transcript

1、最终状态应该优先于“看起来像成功”

Agent 有一种非常危险的失败：语言层面给人以“已经完成”的错觉，但真实世界状态没有发生对应变化。对这类系统，最可信的评分方式通常是检查执行后的环境：数据库有没有新记录，文件有没有被正确修改，订单是否存在，测试是否通过，权限是否满足，页面状态是否达到要求。

这也是 τ-bench、SWE-bench、WebArena、OSWorld 等 Agent benchmark 共同体现的趋势：尽量使用可执行环境和状态验证，而不是只让另一个模型阅读最终答案后判断。[3][5][8]

2. 结果负责定输赢，轨迹负责解释原因

“结果优先”并不意味着轨迹不重要。恰恰相反，transcript/trace 是诊断 Agent 的关键证据。一个任务失败后，团队需要知道失败究竟来自哪里：需求理解错、工具选择错、参数填错、环境超时、检索质量差、规划中断，还是评分器本身写错。

更稳健的原则是：outcome-first, trace-diagnostic。 即：尽可能用最终状态判定是否完成核心目标；再用轨迹检查政策遵循、工具使用质量、沟通质量、效率和失败原因，而不是把某一条固定执行路径强行写成“唯一正确答案”。

核心结果用状态验证，过程轨迹用于诊断、合规和质量判断。这样既减少对“唯一正确路径”的过拟合，又保留足够的可解释性。

二、把一个 Agent eval 拆开：你真正需要设计的是什么

（一）Task、Trial、Grader、Trace、Outcome 是五个不同问题

1、Task：不是一道“题”，而是一份可执行契约

一个高质量 task 至少要明确：初始状态、用户目标、允许使用的工具、约束条件、结束条件和成功标准。对于开放式任务，还应该说明哪些约束是硬约束，哪些是质量偏好。

很多评测的噪声并不来自模型，而来自任务本身不完整。例如，要求 Agent 生成脚本却没有指定保存路径，但评分脚本默认只在固定目录查找；或者题目要求达到某个阈值，评分器却要求明显高于阈值。这类“任务—评分器不一致”会把评测变成测量基础设施缺陷，而不是测量 Agent 能力。[1]

2、Trial：一次运行不能代表一个随机系统

生成式模型和 Agent 都具有随机性。同一个任务运行两次，可能走完全不同的路径。因此，“这个任务通过/失败”往往只是一次样本，不是稳定事实。

对关键任务，至少要运行多个独立 trial，并保留模型版本、温度、工具版本、环境快照、随机种子、时间预算和 token 预算等元数据。否则团队很难判断一个分数变化究竟是系统升级带来的真实提升，还是抽样噪声。

3、Grader：评分器本身也是一个需要被验证的软件系统

Agent 的 grader 大致可分为三类：确定性评分器、模型评分器和人工评分器。确定性评分器便宜、快、可复现，适合状态、测试、格式、安全策略和数值约束；模型评分器适合开放文本、沟通质量、完整性和细粒度语义判断；人工评分器成本最高，但仍然是校准主观标准和处理高风险场景的重要参考。[1]

真正成熟的 eval 不是“选择一种 grader”，而是把不同 grader 放在合适的位置。

4、Trace：不是为了监控每一步，而是为了定位失效机制

很多团队初次做 Agent eval 时，会本能地检查“工具 A 必须先于工具 B”“必须按照某个固定顺序操作”。这种做法很容易变得脆弱，因为强模型往往能找到设计者没预料到但仍然正确的路径。

更合理的 trace 评分应该关注：是否调用了不允许的工具，是否泄露敏感信息，是否反复无意义尝试，是否忽略关键用户信息，是否违反费用或时间预算，以及失败前发生了什么。路径约束只应在业务流程确实要求固定顺序时使用，例如强制身份验证必须先于退款。

5、Outcome：最好能被独立验证

如果一个任务可以通过数据库查询、单元测试、文件哈希、接口状态、页面 DOM、业务流水或日志来确认完成结果，就不要只依赖模型自报成功。越接近真实环境状态，ground truth 越强。

（二）Evaluation harness：测量系统也要有“测量学纪律”

1、环境漂移会把假问题伪装成模型问题

Agent eval 常常包含容器、浏览器、数据库、网络请求、外部依赖和并发任务，因此环境比普通 NLP benchmark 更容易产生噪声。共享缓存、残留文件、API 限流、时间戳变化、依赖升级、CPU/内存争用，都可能导致任务之间相关失败。

一旦多个 trial 因同一个基础设施问题同时失败，就不能把这些样本当作独立证据。成熟的 harness 应该把“Agent failure”和“environment failure”分开记录，必要时自动重跑环境异常，而不是直接计入模型失败。

2. 推荐记录的最小运行元数据

至少包括：模型与版本、系统提示词版本、Agent harness 版本、工具 schema 版本、评测数据版本、环境镜像版本、开始与结束时间、随机参数、token/时间/费用预算、异常类型、最终状态摘要、grader 版本和原始 trace 地址。

这些信息看似繁琐，却决定了你的评测是否能被复现。

三、从“能力”走向“可靠交付”：为什么一次成功远远不够

（一）pass@k 与 pass^k 讲的是两种完全不同的产品故事

1、pass@k：多给几次机会，至少成功一次

在代码生成等场景中，如果系统可以一次生成多个候选，然后通过测试选出可用答案，那么“k 次尝试里至少有一次成功”非常有价值。Codex 相关工作系统化使用了 pass@k 思路，反映重复采样可以显著提高“找到一个可行解”的概率。[6]

在独立同分布的简化近似下，如果单次成功率为 p，那么至少一次成功的概率可写成：

pass@k ≈ 1 – (1 – p)^k

它适合回答：给系统多几次机会，能不能找到一个正确解？

2、pass^k：连续 k 次都成功

面向客服、财务操作、企业流程等用户场景，用户不会接受“同样的请求有时成功、有时失败”。τ-bench 因此引入 pass^k 来强调行为一致性。[3]

在相同的独立近似下：

pass^k ≈ p^k

它适合回答：如果用户重复遇到同类任务，系统能不能稳定地都做对？

假设某任务单次成功率为 75%，三次尝试中“至少成功一次”的概率约为 98.4%，看起来非常优秀；但“连续三次全部成功”的概率只有约 42.2%。同一套 Agent，在两个指标下会呈现出几乎相反的产品印象。

以单次成功率 75% 为例，随着尝试次数增加，pass@k 快速接近 100%，而 pass^k 持续下降。两者分别描述“找到一次成功”与“保持一致成功”。

（二）长链路任务的真正敌人，是可靠性乘法

1、单步看起来很高的成功率，串起来可能非常脆弱

一个 Agent 完成复杂任务通常需要多个关键环节。如果把每个环节近似看成独立事件，整条链路全部成功的概率约等于各环节成功率的乘积。

例如，20 个关键步骤每一步都有 97% 的成功率，整条链全部成功的近似概率只有约 54%。即使每一步提高到 99%，50 个关键步骤全部成功的概率也只有约 60%。现实中步骤之间并不独立，但这个简单模型已经足以说明为什么“长任务”不是“短任务多做几次”那么简单。

2. 需要把“恢复能力”也纳入评测

优秀 Agent 不应该要求每一步永不出错，而应该具备检测错误、回滚、重试、询问用户、重新规划和最终验证的能力。长链路 eval 应设计出可恢复的中间故障，检查系统是否能回到正确状态，而不是只测试一路顺风的“happy path”。

METR 以人类完成任务所需时间来刻画 AI Agent 的“任务完成时间跨度”，本质上也在研究任务长度与成功概率之间的关系；其公开方法强调多次独立运行、任务难度和成功率曲线，而不是只看一次是否通过。[10]

（三）评测结果不应该只有一个总分

四维评分比单一排行榜更接近生产决策

对生产 Agent，更建议把评测拆成四个独立维度：

• Capability（能力）：能否处理更难、更长、更开放的任务；

• Reliability（可靠性）：在重复运行、输入扰动和环境变化下是否稳定；

• Safety/Policy（安全与策略）：是否遵守权限、流程、合规与风险边界；

• Efficiency（效率）：成本、延迟、token、工具调用次数和人工介入率。

这四个维度不应简单相加。安全和关键业务状态通常应采用“硬门槛”；质量、成本和延迟更适合作为软优化目标。一个在质量总分上高一点、但偶发越权的版本，不应该因为均值更高而被发布。

四、评分器设计：最重要的不是“智能”，而是“可验证”

（一）能用确定性检查，就不要先上 LLM Judge

1、硬事实交给代码

文件是否存在、数据库状态是否改变、金额是否在阈值内、测试是否通过、是否调用了禁止工具、是否在规定轮数内结束，这类问题应该优先使用代码评分器。原因不是 LLM Judge 不够强，而是这些条件本来就可以被更便宜、更稳定、更可审计地验证。

2、主观质量再交给模型评分器

沟通是否清楚、报告是否全面、解释是否专业、是否覆盖关键事实、语气是否适合特定用户，这类开放问题才是模型评分器的优势区间。

但是，LLM-as-a-Judge 并不是“自动真理机器”。MT-Bench/Chatbot Arena 的研究显示，强模型作为评审可以与人类偏好达到较高一致性，但也存在位置偏差、冗长偏差、自我偏好等系统性问题。[7] 因此，模型评分器必须像任何检测器一样做校准：拿一批人类专家已标注样本，持续计算一致率、误报、漏报和边界案例。

（二）一个大而全的 Judge，通常不如多个窄 Judge

1、把评价维度拆开

如果让一个 LLM 同时判断事实正确性、完整性、语气、政策遵循、引用质量和效率，它容易在不同维度之间互相补偿。更稳妥的方式是把维度拆开，每个 Judge 只负责一个清晰 rubric，然后再由程序做聚合。

例如研究 Agent 可以拆成：事实是否有来源支撑、是否覆盖指定主题、来源是否具备权威性、结论是否与证据一致、是否出现未经支持的推断。这样既方便定位问题，也更容易与人工校准。

2. 给 Judge “不知道”的出口

评分器被迫在信息不足时给出明确结论，会产生新的幻觉。对需要上下文才能判定的维度，应允许返回 Unknown / Insufficient evidence，再由规则决定是否触发人工复核。一个好的 grader 不只是会打分，还应该知道自己什么时候没有足够证据。

（三）结果评分与过程评分要有不同权重

1、核心业务状态通常是硬约束

对于退款、下单、代码修复、配置修改、权限变更等任务，最终状态应该拥有最高优先级。过程中的“表达很好”不能补偿结果没有完成。

2、路径约束只用于真正必要的流程

如果业务要求“必须先验证身份再退款”，就应该检查顺序；如果只是要求“找到正确文件并修复 bug”，则不应该规定 Agent 必须先 grep 再打开文件。好的 eval 应允许创造性解法，但不能允许违反不可协商的规则。

五、评测数据集设计：真正困难的是定义“什么叫成功”

（一）最好的第一批测试，通常来自真实失败

1、不需要一开始就有几百条

Anthropic 的实践建议非常务实：早期从 20–50 个真实任务启动就足够有价值，尤其是直接来自手工测试、bug tracker、客服反馈和用户失败案例的任务。[1] 在系统还处于高速变化阶段时，大改动往往带来大效应，小而高质量的数据集比大而模糊的数据集更有用。

2、把线上失败变成永不丢失的回归资产

每一个严重线上问题都应该经历一条固定路径：复现 -> 去敏 -> 归因 -> 写成 eval task -> 修复 -> 加入回归套件。否则团队会不断“修同一种问题的不同实例”。

（二）每道题都必须先证明“它真的可解”

1、两名领域专家能否独立达成相同判断

如果两个专家读完任务后都无法一致判断什么算通过，那么这个任务还不够清楚。模糊任务会让评分噪声直接进入模型指标。

2、Reference solution 是评测基础设施的单元测试

每个确定性任务最好保留一个已知可通过的参考解，用它验证题目、环境和 grader 的组合确实能工作。一个看似“模型 0% 通过”的难题，可能只是任务定义、环境、脚手架或评分器出了问题。[1]

（三）平衡“应该做”和“不应该做”的案例

单侧数据集会制造过度行为

如果只测试“什么时候应该搜索”，系统可能学会对任何问题都搜索；如果只测试“什么时候应该拒绝”，系统可能越来越保守；如果只测试“应该升级人工的情形”，系统可能开始过度升级。

因此每个关键行为都应设计正例、反例和边界例。真实产品通常不是在“会不会做”上失败，而是在“该做时没做、不该做时乱做”的阈值问题上失败。

（四）能力集与回归集必须分开维护

1、Capability eval 要故意难

能力集的目的不是证明系统已经很好，而是持续暴露“还不会的东西”。它应该保留相当比例的失败，让团队有清晰的爬坡空间。

2、Regression eval 要接近全通过

回归集则用于守住已经获得的能力。它的理想状态是长期接近 100%，一旦下降就意味着新版本可能破坏了既有行为。

当能力集逐渐被攻克时，其中成熟任务可以“毕业”为回归用例。这样评测体系本身会随产品进化，而不是一年不变的静态 benchmark。[1]

六、从“一套 benchmark”升级成“评测资产组合”

（一）生产级 Agent 至少需要四类 suite

1、能力前沿集：告诉你下一座山在哪里

放入长任务、难任务、新工具、新领域、复杂决策和仍有明显失败率的案例。它主要服务模型选择、提示词研发、工具设计和新能力探索。

2、回归保护集：告诉你有没有把旧东西弄坏

放入已经稳定解决、但业务价值高的关键任务。它适合每次代码、提示词、模型、工具 schema 和路由规则变更时运行。

3、生产回放集：告诉你离真实用户还有多远

从匿名化真实流量中按场景、风险和失败类型抽样，定期离线重放。它比人工编写案例更能反映用户分布和语言多样性，也能发现离线 benchmark 没覆盖的漂移。

4、对抗与策略集：告诉你系统会不会“聪明地做错事”

Agent 越强，越可能找到评测设计者没有预料的路径。对权限、合规、费用、隐私、数据写入、危险工具和业务规则，需要专门设计诱导绕过、模糊指令、冲突目标和 loophole 场景。

（二）为什么“一个总榜”容易误导团队

1、不同 suite 的目标函数本来就不同

能力前沿希望分数不要太高，否则没有改进空间；回归保护希望接近全通过；生产回放追求代表性；对抗集追求高风险缺陷的发现率。把四者压成一个总分，会让团队不知道“到底是哪里变好了”。

2、发布决策应该基于门禁与权衡，而不是单一均值

更实用的发布标准是：关键硬约束不得退步；高价值回归必须全部通过；能力集有显著提升且置信区间可接受；生产回放中的严重错误率不升高；成本和延迟在预算内。这样一个版本是否可发布，是一组条件，而不是一个漂亮分数。

七、EvalOps：把评测从研究脚本变成产品基础设施

EvalOps 的核心是把生产失败持续转化为测试资产，并让测试结果反过来约束模型、提示词、工具和产品发布。

（一）评测必须进入版本控制和 CI/CD

1、Eval 应与 prompt、tool schema、agent code 一起变更

当开发者修改系统提示词、工具描述、重试策略、路由模型、上下文管理或安全规则时，应该能在同一个变更中看到对应 eval 结果。否则评测只是“发布前偶尔跑一次”的仪式，而不是工程反馈机制。

2、每次变更都要保留可比较的实验记录

至少记录基线版本、候选版本、每个 suite 的分数、trial 数、统计区间、严重失败样例、成本、延迟和 token 变化。对于大模型系统，纯平均分尤其危险，因为少量高风险失败可能被大量普通成功稀释。

（二）失败分析是 eval 中最不能自动化掉的一环

1、定期阅读 trace 是团队理解系统的高带宽渠道

Anthropic 特别强调阅读 transcript，因为只有看完整轨迹，才能判断失败是否公平、grader 是否拒绝了合理方案、Agent 是否受 harness 限制、还是环境本身异常。[1]

这项工作不能完全被“再加一个 LLM Judge”取代。模型可以帮助聚类和初步归因，但负责 eval 的工程师与产品专家仍然需要周期性抽查真实轨迹，建立对系统行为的直觉。

2、建立固定的失败分类法

建议至少区分：任务定义问题、环境问题、工具问题、规划问题、知识/检索问题、执行问题、沟通问题、政策问题、grader 问题、资源预算问题。长期统计各类占比，比只追踪总成功率更能指导研发投入。

（三）防止评测饱和和“考试教学化”

1、100% 通过的能力集已经失去研究信号

一套 eval 一旦长期接近满分，它就更适合做回归，而不再适合衡量前沿能力。此时应该增加更长、更开放、更组合化、更接近真实工作的任务，而不是继续在已饱和数据上追逐小数点变化。[1]

2、不能只优化榜单，必须持续验证分布外行为

如果团队每天只看固定测试集，提示词和策略会逐渐针对那批题优化，形成新的“过拟合”。生产回放、动态生成边界案例、专家红队和新任务扩充，都是保持 eval 有效性的必要机制。

八、Agent 评测正在进入第二阶段：长任务、动态世界与人机协同

（一）长任务不只是更多 token，而是更多隐藏状态

OSWorld 2.0 体现了新的难点

早期电脑使用 benchmark 已经证明，仅凭截图和 GUI 操作完成跨应用任务非常困难。到 2026 年的 OSWorld 2.0，任务进一步转向长链路真实工作流，强调动态环境、跨来源推理、隐含状态恢复、视觉空间精度和持续验证等现象。[9]

这说明未来 Agent eval 的重点会从“能不能点击对按钮”转向“能不能在一小时级工作流里持续记住约束、发现状态变化、主动确认并验证结果”。

（二）用户不再只是出题者，而会成为环境的一部分

τ²-bench 的双控制视角非常重要

真实客服、IT 支持和协作式 Agent 往往无法独自完成所有动作。Agent 需要指导用户重启设备、修改设置、提供验证码或完成某个现实世界操作。τ²-bench 因此把用户也建模为可以操作共享环境的一方，测试 Agent 的推理、沟通和协同能力。[4]

这类任务提醒我们：未来的 Agent 成功标准不仅是“自己会做”，还包括“能否让另一个人正确地做”。

（三）时间跨度会成为重要的能力坐标

“能完成多长的人类任务”比单题正确率更有解释力

METR 提出的 task-completion time horizon，把任务按人类专家完成所需时间映射到 Agent 成功概率，为“长任务能力”提供了一个直观坐标。[10] 这种方法并不能替代领域 eval，但它带来一个有价值的思路：当 Agent 的目标从十分钟任务扩展到数小时、数天甚至更长流程时，单纯统计“通过多少道题”可能不再足够。

（四）多 Agent 系统会让评测更像分布式系统测试

新问题是协调、通信和共享记忆

当一个 orchestrator 调度多个 worker，错误可能来自任务拆分、职责冲突、重复工作、信息丢失、上下文不同步和结果合并。此时评测需要同时观察单体能力和系统级组织效率。

未来成熟的多 Agent eval 很可能要引入类似分布式系统测试的概念：故障注入、部分失效、消息延迟、重复消息、共享状态冲突和恢复策略。它测量的将不是“几个模型加起来有多聪明”，而是“一个协作系统在不完美条件下是否仍能完成目标”。

九、一个更实用的工程框架：把 Eval 当成“可执行产品契约”

（一）产品需求必须能被翻译成机器可检查的承诺

1、每个关键能力都应对应至少一个可执行测试

例如“能够安全处理退款”不是可执行需求；更可执行的表达是：身份验证通过后，100 美元以内退款可自动处理；超过阈值必须升级；退款成功后数据库状态、工单状态和确认消息同时更新；禁止绕过身份验证。

Eval 的价值就在于迫使团队把“感觉应该这样”变成“可以验证的行为契约”。

2、每个关键风险也应对应一个反例测试

如果产品担心过度搜索、过度升级、过度拒绝、越权写入、误删文件或无依据行动，就应该把这些风险转成 explicit negative tests，而不是等线上事故证明它们存在。

（二）可以引入一个“评测债务”概念

评测债务会随着系统变化速度复利

当 Agent 快速迭代但 eval 没有同步增长时，团队对“哪些行为仍然有效”越来越没有把握。每次升级模型或提示词，都需要更大规模的手工验证，研发速度反而下降。

可以用一个非严格但实用的启发式来理解评测债务：未覆盖的关键行为越多、系统变化越频繁、单次失败成本越高，评测债务越大。 它与技术债务类似：早期看起来省下了测试时间，后期却用更高的回归风险和人工验证成本偿还。

（三）最终目标不是追求最高分，而是缩短“安全改进循环”

好 eval 的本质是提高研发反馈带宽

一个团队如果能在几小时内知道新模型在哪些场景提升、哪些场景退步、为什么退步，就比只能靠用户投诉发现问题的团队拥有更快的学习速度。

因此，评测体系的终极 KPI 不应只是“benchmark 分数”，还应包括：发现回归需要多久、定位失败需要多久、新问题变成回归测试需要多久、新模型完成验收需要多久，以及严重线上问题有多少能被离线提前捕获。

自动 eval、生产监控、用户反馈、人工 trace 审查和系统性人工研究各自覆盖不同盲区。可信度来自多层证据，而不是单一分数。

十、落地路线：从零开始建立可用的 Agent Eval

（一）第 1 周：定义成功，而不是先选工具

1、建立 20–50 个高价值任务

从现有手工测试、线上失败、客服工单、典型用户路径和高风险流程中选取第一批案例。为每个 task 写清初始状态、目标、约束和成功标准。

2、给任务分层

标记哪些属于能力前沿、哪些必须进入回归、哪些是高风险政策场景。不要一开始就追求覆盖所有情况，先确保每个测试都高信号。

（二）第 2 周：先做 outcome verifier，再做复杂 Judge

1、建立稳定环境

容器化或快照化测试环境，确保每次 trial 从干净状态开始。对数据库、文件、API 和 GUI 状态写确定性验证器。

2、保存完整 trace 与元数据

保证任何失败都可以被回放和定位。此时甚至可以暂时用人工查看开放式质量问题，避免过早把复杂度放在 LLM Judge 上。

（三）第 3 周：加入模型评分器并完成人工校准

1、只把主观问题交给 LLM Judge

为每个维度写窄 rubric，准备 50–100 条人工标注样本，对 Judge 做一致性检查。对争议样本保留人工复核机制。

2、同时测能力与可靠性

对关键任务运行多 trial，至少同时报告单次成功率和一致性指标，避免“平均看起来不错、重复使用却不稳定”。

（四）第 4 周：接入 CI/CD，建立长期维护制度

1、每次关键变更自动跑回归

模型升级、提示词修改、工具 schema 变化和 Agent harness 变化都触发相应 suite。高成本能力集可以定时运行，关键回归集则尽量高频。

2、每周固定审查失败轨迹

由工程、产品和领域专家共同选取失败样本，判断是 Agent 问题、grader 问题还是任务问题。新发现的高价值案例直接进入数据集。

3、每月检查评测健康度

关注任务是否过时、是否饱和、是否存在重复、真实流量是否发生漂移、Judge 是否与人工标准偏离、基础设施是否增加了噪声。

十一、结语：真正成熟的 Agent 团队，先建设“可验证性”

Agent 的价值来自自主性，而自主性也让它更难被测量。越是强大的 Agent，越可能使用设计者没有预料的路径；越是长链路任务，越容易出现错误传播；越是开放式输出，越难靠单一 ground truth 判断。正因为如此，Agent 评测不能只是一个发布前 benchmark，而应该成为产品架构的一部分。

一套成熟的 Agent eval 应该做到四件事：第一，把最终状态和业务目标绑定，让“看起来成功”无法冒充真正成功；第二，把随机系统当作随机系统，用多 trial 和可靠性指标而不是单次分数做判断；第三，把确定性评分、模型评分与人工判断放到各自最擅长的位置；第四，把每一次真实失败持续沉淀为可复用的测试资产。

如果把 Agent 看成未来的软件执行主体，那么 eval 就是它的可执行产品契约。它不仅回答“这个模型有多聪明”，更重要的是回答：这个系统在我的业务、我的工具、我的约束和我的风险边界里，能不能持续、稳定、可解释地把事情做成。

可参考文章与论文