Anthropic 发布 AIAgent 评估体系完整指南，对 AIAgent 发展有何意义？

Anthropic虽然价值观有问题，但是他们的文章还是值得学习和研究的。我个人认为这算是目前最实用的 Agent 评估指南。

现在大部分的 Agent基本上都是“Demo 看着惊艳，上线全是 Bug”。这是因为 Agent 和传统的聊天机器人（Chatbot）压根就是两个产品。我们测Chatbot很简单，你问个问题看看回答通不通顺、跑个 MMLU 分数大概就知道情况了。

但 Agent 不一样。它要调用工具、要读写文件、要根据中间结果调整下一步操作。你用写文档的方式去评测，结果实际让他去服务器上部署代码。这时候你再盯着他的“文笔”是没意义的，你得看他有没有把服务器搞挂，任务到底做完没有。

这就是Agent的最主要的特征：它够自主、够灵活、够智能，但这些特性反过来让评估变得极其棘手。

Anthropic 举了个经典案例: Opus 4.5 在解决 τ2-bench 的航班预订问题时发现了政策里的一个漏洞，给出了比标准答案更好的方案。结果按评估标准它"不及格"了，这不就是把高智商的学生给干掉了么。

评估体系

所以Anthropic 定义了一套完整的术语体系（Anthropic 老自己定义概念，哈）

Task (任务) ：单个测试用例，包含输入和成功标准。但是因为模型输出有随机性，同一个任务要跑多次 Trial (试验) 才能得到可靠结果。

Transcript (转录)： 记录了完整的执行过程，这个过程记录了所有工具调用、推理步骤、中间结果。

但真正重要的是 Outcome (结果)：也就是任务结束时环境的最终状态。

比如航班预订 Agent 可能说"您的航班已预订"但真正的 outcome 是数据库里有没有订单记录那就不对了。

评分靠 Grader (评分器) ，并且Anthropic 把评分器分成三类:

基于代码的评分器通过字符串匹配、单元测试、静态分析这些来进行评分。这个的优点是快、便宜、结果稳定，缺点是容易太死板碰到合理但不在预期内的输出就完蛋了。

基于模型的评分器用 LLM 来打分，比如 LLM-as-a-judge。这个方法的特点是灵活性强，能处理开放式任务，理解细微差别。但它不确定、成本高，而且必须定期和人类评分校准不然容易飘。

人类评分器肯定是最好的，但是需要人工的介入所以贵而且慢只能用在关键环节使用。

Anthropic 的建议是: 能用代码就用代码，必要时上 LLM，人类评分留给校准和验证。（这其实听废话的，我们应该都是这样用的）

评估不同类型的 Agent

编码 Agent

编码 Agent 其实最好评估代码要么能跑要么不能跑，测试要么过要么不过，这个我们都知道。不过Anthropic 又加了一层，它们基于启发式的代码质量规则用 LLM 评估 Agent 怎么调用工具、怎么和用户交互，这些细节决定了 Agent 好不好用。

他们还特别强调：别去检查 Agent 是不是按特定步骤执行了任务。Agent 经常能找到你没想到的有效路径，过度限制反而会扼杀创造性。重点应该放在它产生了什么，而不是它怎么产生的。

对话 Agent

对话 Agent 麻烦的点在于交互质量本身就是要评估的一部分，所以要引入第二个 LLM 来模拟用户。Anthropic 自己在做 alignment auditing agents 时也用这个方法，让两个模型进行长时间的对抗性对话，压力测试模型的表现。

研究 Agent

研究 Agent 是最难评估的，因为不仅要"全面"?，还要"有据可查"，而且什么叫"正确"专家之间也会有分歧。

Anthropic 给的建议是组合着用:用 groundedness check 验证声明有没有来源支持，用 coverage check 确认关键事实有没有遗漏，用 source quality check 保证引用的来源够权威。对于有客观答案的问题 ("X 公司 Q3 营收多少?")直接精确匹配。

而且最后还需要专家判断校准。

计算机使用 Agent

这类 Agent 通过 GUI 和软件交互：截图、鼠标点击、键盘输入，就是模拟用户操作。

Anthropic 在做 Claude for Chrome 时发现平衡 token 效率和延迟很关键。基于 DOM 的交互快但吃 token但是基于截图的交互慢但省 token，他们专门做了评估来检查 Agent 是不是在每种场景下选对了工具。

关键指标和步骤

Anthropic 给了评估的2个关键指标：

pass@k 测的是在 k 次尝试中至少成功一次的概率。pass^k 反过来，测的是 k 次尝试全部成功的概率。

用哪个指标取决于Agent的应用场景，如比如写代码能找到一个可行解就够了用 pass@k；如果是面向用户的客服 Agent，必须保证每次都稳定就要看 pass^k了。

Anthropic 给出了一个 0 到 8 步骤详细介绍。这里我盗个图就不废话

个人看法

就像我前面说的 Anthropic 的文章都值得深入研究，它们是真的在认真做工程，这绝对是基于 Claude Code 这种真实产品打磨出来的方法论。尤其是他们说 "不要检查步骤，要检查结果"这个跟我们一般的想法不一样，因为我们都是本能是想控制执行路径，但对 Agent 来说这种控制反而会扼杀它最有价值的能力。

不过它这个指南里还有很多问题没解决，比如多 Agent 系统怎么评? 长期运行 (几天、几周) 的任务怎么评? 高度主观的创意工作怎么评? 评估本身的成本怎么控制? 我觉得这些有的可能已经有一些，因为留着精华慢慢发算是Anthropic 的老传统了。

不过可以看的出来这份指南的发布时机很关键，26年注定是Agent爆发的一年Anthropic 这次算是往工程化方向又推了一把。