AI Agent 评测：从任务集到长期维护

说明：本文基于 Anthropic Engineering 的文章 Demystifying evals for AI agents 做中文译述与学习整理，并非逐字全译。原文发布于 2026-01-09，作者为 Mikaela Grace、Jeremy Hadfield、Rodrigo Olivares、Jiri De Jonghe。

文章定位

这篇文章讨论的是一个非常工程化的问题：当 AI Agent 具备多轮推理、工具调用、状态修改和自主决策能力之后，我们应该如何评估它到底有没有变好。

普通 LLM 评测通常比较像一次函数调用：给模型一个输入，拿到一个输出，然后检查答案是否正确。Agent 不一样。Agent 会在任务过程中调用工具、读写环境、根据中间结果改变计划，甚至可能用一种评测脚本没有预料到的方式完成任务。也就是说，Agent 的价值来自灵活性，而评测的难点也正来自这种灵活性。

原文的核心观点可以概括为一句话：Agent eval 不是一次打分，而是一套让团队持续发现问题、避免回归、推动改进的工程系统。

一、为什么 Agent Eval 更难

单轮模型评测关注的是“输入和输出”。例如给一个问题，模型回答后，评测逻辑检查答案是否匹配参考答案。

但 Agent 评测要看的是一条完整轨迹：

Agent 收到了什么任务；
它调用了哪些工具；
工具返回了什么；
它如何根据中间状态调整计划；
最终环境是否真的发生了正确变化；
它是否用合理、稳定、可解释的方式完成任务。

这里有两个概念特别重要：

Transcript 是一次运行的完整过程记录，包括模型输出、工具调用、中间观察和交互轨迹。它回答的是“Agent 是怎么做的”。

Outcome 是任务结束后的最终环境状态。它回答的是“事情真的办成了吗”。例如客服 Agent 说“退款已处理”不够，真正的结果应该看系统里是否产生了正确的退款记录。

Agent 的难点在于：一个看似失败的过程可能带来了更好的用户结果，一个看似成功的回答也可能只是口头承诺，环境状态并没有改变。因此，评测不能只看最终文本，也不能只看中间轨迹，往往需要把过程和结果结合起来。

二、Eval 的基本组成

原文把 Agent eval 拆成几个基本概念。

Task：一个具体测试任务，也可以理解为问题或测试用例。它需要有输入、环境和成功标准。

Trial：同一个任务的一次尝试。由于模型具有非确定性，同一个任务通常要跑多次 trial。

Grader：评分逻辑，用来判断 Agent 在某些维度上是否达标。一个 task 可以有多个 grader，一个 grader 里也可以包含多个检查项。

Evaluation harness：运行评测的基础设施。它负责准备任务、提供工具、并发执行、记录轨迹、调用 grader、聚合结果。

Agent harness：让模型成为 Agent 的系统外壳。它处理输入、编排工具调用、管理状态并返回结果。评测 Agent 时，实际上评测的是模型和 agent harness 共同组成的系统。

Eval suite：一组相关任务的集合。它通常针对某一类能力或某一个产品行为，例如文件编辑能力、客服处理能力、浏览器操作能力等。

这些概念说明了一件事：Agent eval 不是“写几个 prompt 看看结果”，而是要把任务、环境、执行过程、评分逻辑和结果统计组织成可重复运行的系统。

三、为什么要尽早做 Eval

很多团队在 Agent 早期开发时，会依赖人工测试、内部试用和直觉判断。这在原型阶段可以走得很快，但一旦系统进入生产环境，问题会开始显现。

没有 eval 时，团队很容易陷入被动循环：

用户反馈“新版本好像变差了”；
团队手动复现几个案例；
修掉一个问题；
另一个行为又发生回归；
最后很难判断变化到底是提升、噪声还是退化。

Eval 的价值是把这些模糊感觉转化为可观察信号。早期 eval 可以帮助团队定义“什么叫成功”，中后期 eval 可以帮助团队守住质量底线。随着产品变复杂，eval 还可以成为研发、产品和研究团队之间的共同语言。

一个实用启发是：不要等到有几百个测试任务才开始。原文建议，早期用 20 到 50 个来自真实失败或手工测试的任务就足以起步。因为早期系统变化通常影响很大，小样本也能暴露方向性问题。

四、三类 Grader

Agent eval 通常会组合使用三类 grader。

4.1 代码型 Grader

代码型 grader 是最稳定的一类。它通过程序逻辑直接判断结果，例如：

单元测试是否通过；
数据库里是否出现正确记录；
文件是否被正确修改；
页面状态是否满足预期；
API 返回值是否符合 schema。

只要成功标准能被程序明确验证，就应该优先使用代码型 grader。它速度快、成本低、可复现，也更适合作为回归测试。

4.2 模型型 Grader

模型型 grader 用另一个 LLM 来判断结果是否满足要求。它适合处理主观性更强的问题，例如：

回答是否礼貌；
解释是否清晰；
研究报告是否覆盖关键点；
对话是否遵守客服规范；
输出是否与证据来源一致。

模型型 grader 的好处是灵活，但风险是评分本身也会不稳定。因此 rubric 必须写得清楚，并且需要定期用人工判断校准。

4.3 人工 Grader

人工 grader 最贵也最慢，但在关键场景里不可替代。它适合用于：

校准模型型 grader；
判断开放式任务质量；
发现自动 grader 没覆盖的新问题；
审查高风险或高价值样例。

实践中更合理的方式不是让人类评估所有样例，而是把人工判断用于抽样、校准和困难样例分析。

五、能力评测与回归评测

原文区分了两类 eval：capability eval 和 regression eval。

能力评测回答的是：这个 Agent 现在能不能做更难的事。它应该包含 Agent 还做不好的任务，初始通过率不需要很高。这样的任务集给团队提供了一个可以攀爬的坡。

回归评测回答的是：这个 Agent 以前会做的事，现在是否仍然稳定。它的通过率应该接近 100%，一旦下降，就说明系统某处发生了退化。

这两类评测最好同时存在。只做能力评测，可能会在追求新能力时破坏旧能力；只做回归评测，又很难推动系统向更高水平演进。

一个自然的生命周期是：某些能力评测中的任务，随着 Agent 逐渐稳定通过，可以“毕业”进入回归测试集。这样，过去的挑战会变成未来的质量护栏。

六、不同 Agent 的评测重点

6.1 编程 Agent

编程 Agent 的评测相对容易做成确定性形式，因为代码可以运行，测试可以验证。

好的编程 Agent eval 通常包括：

明确的问题描述；
稳定、隔离的代码环境；
能判断最终结果的测试；
对生成代码质量和工具调用行为的补充检查。

仅仅“测试通过”还不一定足够。有时还要看 Agent 是否过度设计、是否修改了无关文件、是否绕开测试、是否使用了不合理的工具调用路径。

6.2 对话 Agent

对话 Agent 常见于客服、销售、辅导等场景。它的评测不只是任务是否完成，还包括交互质量。

例如一个退款客服 Agent，评测维度可能包括：

身份验证是否完成；
退款状态是否写入系统；
是否在限定轮次内完成；
是否保持合适语气；
是否基于工具返回结果回答，而不是编造政策。

这类评测往往需要模拟用户。也就是说，评测系统中可能会有另一个模型扮演用户，与被测 Agent 进行多轮交互。

6.3 研究 Agent

研究 Agent 的难点在于结果通常不是简单的对错。市场调研、尽职调查、技术综述、科学报告，对“全面”“可靠”“有洞察”的标准都不一样。

研究类评测可以组合以下信号：

事实是否有来源支持；
是否覆盖必要信息点；
引用来源是否权威；
是否遗漏关键反例；
综合分析是否连贯；
是否把检索材料中的不确定性说清楚。

由于主观性较强，研究 Agent 的 LLM rubric 需要经常和专家人工判断对齐。否则评测分数看起来很精确，实际可能只是另一种噪声。

6.4 电脑使用 Agent

电脑使用 Agent 通过屏幕截图、鼠标、键盘和滚动来操作软件，而不是直接调用 API。它可以处理浏览器、设计软件、企业旧系统等 GUI 场景。

这类 Agent 的评测重点是检查最终环境状态，而不是只看界面上出现了什么。例如浏览器里出现“订单成功”页面不够，还要看后端状态里订单是否真的创建。

另一个关键点是工具选择。浏览器任务中，DOM 信息和截图各有优缺点：DOM 适合提取结构化文本，截图适合理解视觉页面和复杂交互。评测可以专门检查 Agent 是否在合适的场景选择了合适的观察方式。

七、非确定性：pass@k 与 pass^k

Agent 的行为会随运行次数变化。同一个任务，这次成功，下次可能失败。因此只看一次运行容易误判。

原文提到两个有用指标。

pass@k 衡量的是 k 次尝试里至少成功一次的概率。k 越大，pass@k 往往越高。它适合表示“多给几次机会，Agent 能不能找到可行方案”。

pass^k 衡量的是 k 次尝试全部成功的概率。k 越大，pass^k 往往越低。它适合表示“Agent 是否每次都可靠”。对于面向用户的生产系统，这个指标尤其重要，因为用户通常不会关心 Agent 偶尔能成功，而是希望它稳定成功。

这两个指标提醒我们：Agent eval 不应该只报告一个平均分，还要考虑任务级成功率、运行次数和稳定性。

八、从零开始构建 Agent Eval

原文给了一个从零到一的路线图，可以整理为三组动作。

8.1 收集初始任务集

第一步是尽早开始。不要等到评测体系完美才动手，先从真实失败、手工测试和常见用户任务中收集样例。

第二步是把已有手工检查转成测试任务。开发者每次发布前会手动验证的行为，往往就是最适合进入 eval suite 的行为。

第三步是写清楚任务和参考解法。一个好任务应该让两个领域专家独立判断时得出相近结论。如果人类都无法判断是否通过，模型和 grader 更不可能稳定判断。

第四步是保持任务集平衡。任务不能全是容易题，也不能全是边角失败；既要覆盖高频路径，也要保留足够有挑战的样例。

8.2 设计 Harness 和 Grader

评测环境要尽量接近生产环境，但又要稳定、隔离、可复现。每个 trial 最好从干净环境开始，避免前一次运行留下文件、缓存、数据库状态或资源占用影响下一次。

共享状态会带来两个问题：一是基础设施噪声导致失败相关性变强，二是 Agent 可能从前一次运行残留的信息中获得不公平优势。对于 Agent eval 来说，环境隔离不是洁癖，而是统计结果可信的前提。

Grader 设计则遵循一个实用顺序：能用确定性检查就先用确定性检查；需要语义判断时再用 LLM grader；对关键、主观或高风险样例用人工校准。

8.3 长期维护 Eval

评测不是写完就结束。团队需要持续阅读 transcript，确认失败是否公平、grader 是否误杀、任务是否仍然代表真实需求。

当某个能力评测通过率长期很高时，它可能已经饱和，需要升级难度，或者转入回归测试。否则分数会变得很好看，但对后续改进没有指导意义。

长期维护还包括开放贡献和质量治理。随着团队发现新的失败模式，应该把高价值失败样例沉淀进任务集；同时也要清理过时、模糊、低信噪比的测试。

九、Eval 不是唯一信号

自动 eval 可以在不影响真实用户的前提下大规模运行，这是它的优势。但它不能替代所有质量判断。

完整的 Agent 质量理解还需要：

生产环境监控；
用户反馈；
A/B 测试；
人工 transcript 审查；
系统化人工评估；
错误案例复盘。

可以把这些方法理解成多层防线。Eval 擅长快速、可复现地发现已知问题；生产监控能暴露真实环境中的分布漂移；用户反馈能发现评测没有覆盖的体验问题；人工审查则帮助团队理解自动指标背后的真实行为。

十、我自己的落地清单

结合这篇文章，如果要给一个自己的 Agent 项目设计 eval，我会按下面的顺序推进。

先收集 20 到 50 个真实任务，优先来自手工测试、线上失败和用户高频路径。
为每个任务写清楚输入、初始环境、成功标准和失败边界。
能用程序检查的 outcome，就不要只让模型打分。
对话、研究、风格类任务使用 LLM rubric，但要定期做人类校准。
每次运行都保存 transcript，失败时优先读轨迹，而不是只看分数。
区分能力评测和回归评测，不要用同一套数据承担所有目标。
对非确定性任务跑多次 trial，同时关注 pass@k 和 pass^k。
把评测环境做成隔离、稳定、可复现的 harness。
定期清理任务集：移除模糊样例，升级饱和样例，补充新失败样例。
不把 eval 当作唯一真相，而是和监控、用户反馈、A/B 测试一起看。

总结

Agent eval 的本质不是“给 Agent 打一个分”，而是建立一个能持续暴露问题、约束回归、指导改进的反馈系统。

对于简单模型调用，评测可以只关心最终回答。对于 Agent，评测必须同时关心任务、环境、过程、工具调用、最终状态和长期稳定性。

这也是 Agent 工程和普通 prompt 调参最大的不同之一：当系统开始具备自主性和工具能力后，我们真正需要建设的，不只是更好的提示词，而是更可靠的评测、观测和迭代机制。