《揭开AI Agent 评测神秘面纱》
Anthropic Engineering 中文整理版
Agent 越自主、越灵活、越能调用工具，就越难被评测。真正有效的方案，是让评测系统的复杂度与 Agent 的行为复杂度相匹配。
原文标题：Demystifying evals for AI agents
原文发布：2026 年 1 月 9 日
作者：Mikaela Grace、Jeremy Hadfield、Rodrigo Olivares、Jiri De Jonghe
原文链接：https://www.anthropic.com/engineering/demystifying-evals-for-ai-agents
本文是对 Anthropic 原文的中文内容整理与忠实转述，重点覆盖文章的论证结构、概念定义、方法建议和实践路线；不是原文的逐字全文翻译。完整内容请阅读英文原文。
好的评测，让团队在上线前看见问题、理解行为变化，并且能够持续改进 Agent。没有评测，团队很容易陷入被动循环：用户先发现问题，团队再手工复现，修好一个问题后又担心引入新的回归。
一、为什么 Agent 评测更难
传统的单轮评测通常只有三个要素：输入、模型回答和评分逻辑。Agent 则会在多个回合中调用工具、修改环境状态，并根据中间结果调整下一步行动。错误可能在这个过程中传播并累积，模型也可能找到评测设计者没有预料到的解法。
因此，评测不能只看最终文字是否“像一个正确答案”，还要观察：
任务是否真正完成；
环境状态是否正确；
过程是否满足必要约束；
Agent 的行为是否具有足够的稳定性。
二、评测系统中的基本概念
任务 Task
一个包含明确输入和成功标准的测试用例，也可以理解为一个问题或测试场景。
试验 Trial
任务的一次执行。由于模型每次输出可能不同，同一任务通常需要执行多次。
评分器 Grader
用于衡量 Agent 某一方面表现的逻辑。一个任务可以组合多个评分器和多个断言。
轨迹 Transcript
一次试验的完整记录，包括模型输出、工具调用、推理过程、中间结果和交互消息。
结果 Outcome
试验结束时环境的最终状态。例如，机票是否真的写入预订数据库，而不只是 Agent 说“已经订好了”。
评测框架 Harness
负责端到端运行评测的基础设施：执行任务、隔离环境、记录步骤、评分并汇总结果。
Agent Harness
让模型能够作为 Agent 行动的系统，负责处理输入、编排工具调用并返回结果。评测的其实是模型与 Harness 的组合。
评测套件 Suite
围绕某种能力或行为组织的一组任务，例如客服场景中的退款、取消和升级处理。
三、为什么要尽早建立评测
在原型阶段，人工测试、团队内部试用和直觉往往足够。但当 Agent 进入生产并开始规模化后，仅靠用户反馈会变得非常被动：团队无法判断一次改动究竟带来了真实回归，还是只是遇到了随机噪声；也无法在发布前自动覆盖数百个场景。
评测的价值会随着时间累积。它可以把用户报告的问题变成回归测试，把产品要求变成明确的成功标准，也可以帮助团队更快判断新模型是否值得接入，并持续跟踪延迟、Token 用量、单任务成本和错误率。
核心观点：评测不是发布前的一次性检查，而是 Agent 开发过程中的共同语言。它让“感觉变差了”变成可定位、可复现、可改进的问题。
四、三类评分器如何组合
代码评分器
包括字符串匹配、二元测试、静态分析、最终状态校验、工具调用检查和轨迹指标。
优点是速度快、成本低、客观且可复现；缺点是容易对有效的非预期解法过于苛刻，也不擅长主观质量判断。
模型评分器
包括基于规则的打分、自然语言断言、成对比较、参考答案评测和多评审共识。
优点是灵活、可扩展、能处理开放式输出；缺点是具有不确定性，需要通过人工校准保证准确性。
人工评分器
包括领域专家评审、众包判断、抽样检查、A/B 测试和标注者一致性分析。
优点是质量上限高，适合校准模型评分器；缺点是成本高、速度慢，并且需要专家资源。
组合方式
可以采用加权分数、全量通过的二元规则，或两者混合。多组成任务应保留部分得分，避免把“完成了一半”与“完全没有完成”混成同一种失败。
五、能力评测与回归评测
能力评测回答“Agent 现在能做好什么”。它应该从低通过率、较难的任务开始，为团队提供继续爬坡的空间。
回归评测回答“过去能做好的事情现在是否仍然能做好”。它的目标是接近 100% 通过，用来防止系统在优化一个方向时破坏另一个方向。
当能力评测中的任务已经稳定通过时，它们可以“毕业”为回归套件，持续检查能力是否发生漂移。
六、不同类型 Agent 的评测重点
编码 Agent
编码任务通常适合确定性评分：代码能否运行、测试是否通过、是否引入安全或类型问题。除了单元测试，还可以检查静态分析结果、最终环境状态、工具调用，以及代码质量和与用户交互的方式。
对话 Agent
客服、销售和教练类 Agent 的难点在于“交互质量”本身也属于结果。一个任务可能同时要求工单已解决、对话不超过一定回合数、语气合适，并且关键操作使用了正确工具。
此类评测经常需要另一个模型模拟用户，进行多轮甚至对抗式对话。
研究 Agent
研究质量依赖任务上下文。“全面”“有充分来源”“正确”在市场扫描、并购尽调和科学报告中可能有不同含义。
可以组合事实依据检查、覆盖度检查、来源质量检查和精确匹配；开放式综合则应使用模型评分，并定期与专家判断校准。
计算机操作 Agent
这类 Agent 通过截图、鼠标、键盘和滚动操作图形界面。评测应在真实或沙盒环境中运行，并检查文件系统、应用配置、数据库和页面状态等最终结果。
DOM 操作通常更快但消耗更多 Token，截图操作通常更慢但更节省 Token，具体选择取决于任务。
七、如何处理 Agent 的随机性
同一个任务在不同运行中可能成功率不同，因此单次结果并不能完整描述能力。文章重点介绍了两个指标：
pass@k
在 k 次尝试中至少成功一次的概率。k 越大，至少找到一个正确解的机会通常越高，适合“只要有一次成功就有价值”的工具。
pass^k
k 次尝试全部成功的概率。k 越大，要求越严格，适合用户期待每次都可靠的 Agent。
例如单次成功率为 75%，连续三次全部成功的概率是：
TEXT复制
0.75³ ≈ 42%
因此，选择哪个指标应由产品需求决定，而不能只看更好看的数字。
八、从零开始建立可靠评测的路线
第 0 步：尽早开始
不必等到拥有数百个任务。由真实失败案例构成的 20～50 个简单任务，已经足以启动早期迭代。
第 1 步：把已有人工检查转成任务
优先处理发布前反复检查的行为、用户常见任务、Bug 记录和客服队列中的失败案例，并按用户影响排序。
第 2 步：写清楚任务和参考解
两个领域专家应该能够独立得到相同的通过或失败判断。任务中所有会被评分器检查的条件都必须明确，并提供一个已知可行的参考解来证明任务和评分器没有坏掉。
第 3 步：建立平衡的问题集
既测试“应该触发某行为”的情况，也测试“应该不触发”的情况。单向评测会导致单向优化，例如让 Agent 在所有问题上都搜索。
第 4 步：建设稳定、隔离的 Harness
评测中的 Agent 应尽量接近生产 Agent，每次试验从干净环境开始，避免残留文件、缓存、资源耗尽或历史记录造成相关失败和虚假高分。
第 5 步：谨慎设计评分器
能用确定性规则就优先使用；需要灵活性时再使用模型评分；人工评分则用于校准和关键验证。
尽量评分最终产物，而不是强制一条唯一的工具调用路径，以免惩罚有效的创造性解法。
第 6 步：阅读轨迹和评分
失败时要判断究竟是 Agent 真错了，还是评分器拒绝了一个有效解法。只有读过足够多的轨迹，才能确认评测测量的是实际重要的行为。
第 7 步：关注能力评测饱和
当通过率接近 100%，评测只能发现回归，无法继续提供能力提升信号。需要补充更难、更长或更贴近真实任务的新题目。
第 8 步：持续维护评测套件
评测是一种需要负责人、持续贡献和定期修订的“活资产”。最接近产品需求和用户的人，往往最适合定义成功标准和贡献新的评测任务。
九、评测不是唯一信号
自动化评测可以在不影响真实用户的情况下大规模运行，但它不能替代所有观察手段。完整的 Agent 质量判断应组合多层信号。
自动化评测
适合快速迭代、持续集成、回归检查和规模化覆盖；缺点是需要前期建设，且可能与真实使用分布不一致。
生产监控
提供真实用户行为和线上错误信号；缺点是问题通常已经触达用户，信号也可能嘈杂。
A/B 测试
能观察真实流量下的任务完成和留存等结果；但需要时间和足够流量，且不容易解释“为什么”发生变化。
用户反馈
能暴露预料之外的问题并提供真实案例；但反馈稀疏、带有自选择偏差，用户通常不会解释失败原因。
人工阅读轨迹
有助于建立失败模式直觉、发现自动检查漏掉的细节，并校准“什么是好”；但耗时、难规模化且覆盖不稳定。
系统化人工研究
适合主观、含糊或高风险任务，能提供多位标注者的高质量判断；代价是昂贵、周期长，并需要处理标注者分歧。
可以把这些方法理解为安全工程中的“瑞士奶酪模型”：没有任何一层能抓住所有问题，但多层组合可以让一层漏过的故障被另一层发现。
十、结论
没有评测的团队，往往被困在被动修复的循环里：修掉一个问题，又引入另一个问题，还无法分辨真实回归和随机噪声。投入评测后，失败会变成测试用例，测试用例会阻止回归，指标会替代猜测，团队也会得到一个清晰的改进目标。
最重要的实践原则可以浓缩为几句话：
尽早开始。
从真实失败中收集任务。
把成功标准写清楚。
组合不同类型的评分器。
保证环境稳定且试验相互隔离。
检查评分器是否公平。
阅读轨迹。
持续更新评测套件。
Agent 评测仍处在快速演进阶段。随着 Agent 执行更长任务、参与多 Agent 协作，并承担更主观的工作，评测方法也需要继续适应。
附：可选的评测框架
原文列举了若干开源或商业框架，包括 Harbor、Braintrust、LangSmith、Langfuse 和 Arize Phoenix。工具可以帮助团队加速运行、观测和实验管理，但框架本身不会自动产生高质量评测。
真正决定效果的，仍然是任务、评分标准和评测数据的质量。