Anthropic 万字长文：AI Agent 评估体系全解析

核心内容速览

• pass@k 与 pass^k 是两个问题：pass@k 问「跑 k 次至少成一次的概率」（能力上限），pass^k 问「跑 k 次全都成的概率」（可靠性）。面向用户的产品，pass^k 更要紧。
• 能力评估 vs 回归评估：前者测「模型能不能做」（用难任务），后者测「改动有没有把原来能用的弄坏」（用已覆盖任务），两者的评测集应该分开维护。
• 一定要读 trace：自动评分之外，人必须定期亲自读执行轨迹——很多「通过了但很蠢」的行为只有读 trace 才能发现。
• 瑞士奶酪模型：单层评测都有洞，多层评估（单元级、轨迹级、端到端、线上监控）叠加才能兜底。

适合谁 · 怎么用

有一定基础后精读（建议先读完白皮书系列）。最佳方式是读本站导读后，对照 Anthropic 英文原文再读一遍（本站补充资料区有原文链接和完整中文版）。

闯关自测

先合上原文在心里作答，再点开对照。全对 = 本篇真正通关。

以下为原文全文

上方为本站原创导读，下方为原文完整收录，便于对照阅读。

做过 Agent 开发的朋友都有体会：你改了个 Prompt，跑了几个 case 看起来没问题，结果上线后用户投诉「感觉变蠢了」。想验证是真退步还是错觉，却发现除了手动测几个场景，没有任何靠谱的办法。早期靠直觉和手动测试能走挺远，但一旦 Agent 进入生产环境开始扩展，没有系统化评估就会出各种问题。

评估的基本概念

评估（eval）就是给 AI 系统做测试：给它一个输入，用评分逻辑对输出打分。单轮评估很简单：一个提示、一个响应、一套评分逻辑。但 Agent 是多轮运行的，会调用工具、修改状态、根据中间结果动态调整，这让评估复杂得多。

一个有趣的例子：Opus 4.5 在做 τ2-bench 的航班预订任务时，发现了政策里的漏洞，给用户找到了更好的方案。按评估的字面标准它「失败」了，但实际比标准答案更聪明——Agent 评估不能太死板。

Anthropic 定义的关键术语：

• 任务（Task）：一个独立的测试用例，有明确的输入和成功标准；
• 试验（Trial）：对任务的一次尝试，因模型有随机性，通常要跑多次；
• 评分器（Grader）：打分逻辑，一个任务可以有多个评分器；
• 转录（Transcript）：一次试验的完整记录，含所有工具调用、推理过程、中间结果；
• 结果（Outcome）：试验结束时环境的最终状态。Agent 说「航班已预订」不算数，数据库里真的有预订记录才算；
• 评估框架（Evaluation Harness）：端到端运行评估的基础设施；
• Agent 框架（Agent Harness / Scaffold）：让模型能作为 Agent 运行的系统。评估一个 Agent 时，实际是在评估框架和模型的协同工作；
• 评估套件（Evaluation Suite）：为衡量特定能力而设计的任务集合。

为什么需要评估体系？

很多团队觉得评估是额外负担。早期确实可以不要，但总有临界点：用户反馈 Agent 改版后变差，团队两眼一抹黑，调试变成被动响应——等投诉、手动复现、修 bug、祈祷没引入新问题。无法区分真正的退化和噪声，无法在发布前自动测试数百个场景，也无法量化改进效果。

评估还有隐藏价值：更强的模型发布时，有评估的团队能快速验证、调整提示词，几天完成升级；没有评估的团队要花数周手动测试。评估体系建起来后，延迟、token 用量、成本、错误率都可以在固定任务集上持续追踪。评估的复利效应容易被忽视，因为成本是前期可见的，收益是后期累积的。

三类评分器

• 基于代码的评分器：字符串匹配、单元测试、静态分析。快、便宜、客观、可复现；但脆弱，对有效变体不够宽容；
• 基于模型的评分器：LLM 按评分标准打分、自然语言断言、成对比较。灵活、能处理开放式任务；但非确定性、更贵、需要和人工校准；
• 人工评分器：领域专家评审、抽样检查。黄金标准，但贵、慢、难以规模化。

Anthropic 的建议：尽可能用确定性评分器，必要时加 LLM 评分器，人工评分器用来校准。

能力评估 vs 回归评估

能力评估问「Agent 擅长做什么」，通过率应从较低开始，针对 Agent 难以完成的任务，给团队爬坡目标。回归评估问「Agent 还能做好以前能做的事吗」，通过率应接近 100%，分数下降意味着出问题了。两者要同时跑；能力评估通过率高了，可以升级到回归套件里。

不同类型 Agent 怎么评估

编码 Agent

评估相对简单，因为软件可客观验证：代码能跑吗？测试过了吗？SWE-bench Verified 和 Terminal-Bench 是常用基准。实践中，编码评估通常就是单元测试加 LLM 代码质量评分，再按需叠加静态分析、状态检查、工具调用检查及转录/延迟指标。

对话 Agent

交互本身的质量也是评估内容：工单解决了吗？10 轮内完成了吗？语气恰当吗？τ-Bench / τ2-Bench 用一个模型扮演用户、另一个是被测 Agent 来模拟真实场景——对话 Agent 评估通常需要第二个 LLM 模拟用户。

研究 Agent

最难评估，因为「好」是主观的。要组合多种检查：基础性（声明有来源支持吗）、覆盖度（关键事实都包含了吗）、来源质量（来源权威吗）。LLM 评分标准要经常和人类专家校准。BrowseComp 的问题设计成「容易验证但难以解决」，专测 Agent 在开放网络大海捞针的能力。

计算机操作 Agent

在真实或沙盒环境运行，检查是否达成预期结果。WebArena 通过 URL 和页面状态检查导航，并对修改数据的任务做后端状态核实（确认订单确实已下单，而不只是出现确认页面）；OSWorld 扩展到完整操作系统控制。

处理非确定性

同一个任务可能这次通过、下次就挂。两个指标捕捉这种细微差别：

• pass@k：k 次尝试中至少一次成功的概率。k 越大分数越高。pass@1 是第一次就成功的概率，编码场景最关心；
• pass^k：k 次尝试全部成功的概率。k 越大分数越低。每次 75% 成功率，跑 3 次全过的概率仅约 42%。面向用户的 Agent 特别关心这个，因为用户期望每次都可靠。

k=1 时两个指标相同；k=10 时 pass@k 接近 100%，pass^k 降到 0%。选哪个取决于产品需求。

从 0 到 1 的实操路线图

收集任务

• 尽早开始，不要等完美：20—50 个从真实失败里提取的简单任务就够了。评估拖得越久越难；
• 从手动测试的内容开始：发布前验证的行为、用户常用场景、bug 追踪器和客服工单，都是现成的测试用例来源；
• 任务要有明确参考答案：好任务是两位领域专家独立看会得出相同的通过/失败判定。前沿模型多次尝试通过率为 0% 通常意味着任务本身有问题。每个任务配一个参考解决方案，证明任务可解、评分器配置正确；
• 构建平衡的问题集：测应该做的情况，也测不应该做的情况。只测「应该搜索」的场景，可能得到一个什么都搜索的 Agent。

设计评分器

• 环境要稳定隔离：每次试验从干净环境开始。Anthropic 曾发现 Claude 在某些任务上分数异常高，原因是它检查了之前试验的 git 历史；
• 评估结果而非路径：不要检查 Agent 是否按非常具体的步骤操作——Agent 经常找到设计者没预料到的有效方法；
• 加入部分得分：客服 Agent 正确识别问题、验证身份但没能处理退款，明显比直接失败好；
• 小心评估本身的 bug：Opus 4.5 最初在 CORE-Bench 上只得 42%，后来发现是评分器问题（精度误判、任务规格模糊、随机任务无法复现），修复后跳到 95%。

长期维护

• 读转录轨迹：不读大量试验轨迹，就无法知道评分器是否在正常工作；
• 监控饱和度：100% 通过的评估只能追踪回归，不能提供改进信号；
• 让更多人贡献评估：最接近产品需求和用户的人最有资格定义成功。评测驱动的开发方式：在 Agent 具备相关能力前，先构建评测来定义预期能力。

评估不是万能的：瑞士奶酪模型

• 自动化评估——上线前和 CI/CD 的第一道防线，每次改动都跑；
• 生产监控——上线后检测分布漂移和意外失败；
• A/B 测试——有足够流量后验证重大改动；
• 用户反馈和轨迹审查——持续填补空白；
• 系统性人工研究——校准 LLM 评分器、评估主观输出。

没有单一方法能捕捉所有问题，多层组合才能互相补位。

写在最后

没有评估的团队会陷入被动循环——修一个问题引入另一个，分不清退化和噪声。有评估的团队发现相反的情况：失败变成测试用例，测试用例防止回归，指标取代猜测。原则总结：尽早开始；从真实失败中获取任务；定义明确的成功标准；组合多种评分器；确保问题足够难；一定要读转录轨迹。框架可以加速起步（Promptfoo、Langfuse 等），但最终效果取决于评估任务的质量。