刚刚！Anthropic 公开完整的 AI Agent 评估实战指南！

传统的软件开发，代码是确定的，输入 A 必然得到输出 B。但在 Agent 的世界里，模型是概率性的，工具调用是动态的。你可能只是改了一句提示词（Prompt），原本能完美运行的代码助手突然就开始“胡言乱语”，或者不仅没修好 Bug，还把数据库给删了。

很多团队目前的状态是：凭感觉（Vibes）开发。

“感觉这个回答比上一个好”，“好像变聪明了一点”。这种“玄学”调优，在 Demo 阶段没问题，一旦上线面临真实用户的复杂场景，就会变成一场灾难。

最近，Anthropic（Claude 背后的公司）发布了一篇极具价值的工程博客《Demystifying evals for AI agents》，详细复盘了他们如何构建 Agent 评估体系（Evals）。

如果你正在构建或准备构建 Agent，这篇文章里的工程经验，价值千金。

为什么 Agent 评估这么难？

想象一下，你不是在测试一个函数，而是在面试一个员工。

普通的 API 测试像是在做“填空题”：输入是什么？输出对不对？

而 Agent 评估则是在做“模拟实习”：

1. 1. 多轮交互：它需要和环境互动，可能要查资料、写代码、运行测试、再修改代码。
2. 2. 状态变化：它的每一步操作都会改变环境（比如在数据库里写了一条记录）。
3. 3. 路径多样：达成目标的方法不只一种。

Anthropic 提到一个有趣的案例：他们曾测试 Claude Opus 4.5 预订机票的能力。模型发现了一个政策漏洞，用一种意想不到的方式“成功”预订了机票。虽然从测试规则上看它“失败”了（没按规定流程走），但从结果看它反而帮用户省了钱。

这种复杂性，决定了我们不能只看“最终答案”，必须建立一套完整的评估解剖学。

拆解：一个完整的评估体系长什么样？

Anthropic 建议，不要把评估想得太神秘，它其实是由几个核心组件搭积木组成的。

• • 1. 任务（Task）与 试验（Trial）

这是考试的“题目”。一个任务不仅包含输入（Prompt），还包含环境。

比如：“帮我构建一个 MCP 服务器”。Agent 需要在一个沙盒环境里，安装依赖、写代码、调试。

因为模型有随机性，同一个任务我们通常要跑多次，每一次尝试就叫一个“试验”。

• • 2. 抄本（Transcript）

这是考试的“过程记录”。

它不仅仅是聊天记录，还包括 Agent 的每一次思考（Chain of Thought）、每一次工具调用、每一次环境反馈。

这是调试的金矿。如果不看过程只看结果，你永远不知道 Agent 是真的懂了，还是瞎猫碰上死耗子。

• • 3. 评分员（Grader）：谁来阅卷？

这是评估体系中最核心的部分。Anthropic 将“阅卷老师”分为三类，各有优劣：

• • A 类：代码评分员（Code-based Graders）
• • 角色：死板的数学老师。
• • 方法：用正则表达式匹配字符串，或者运行单元测试。
• • 优点：极快、极便宜、客观。
• • 缺点：不懂变通。比如你要求输出 JSON，模型多输出了一句“好的，这是 JSON”，它就会判错。
• • B 类：模型评分员（Model-based Graders / LLM-as-a-Judge）
• • 角色：灵活的语文老师。
• • 方法：用另一个强模型（比如 Claude 4.5 Sonnet）来通过复杂的 Prompt 评价 Agent 的表现。
• • 优点：能理解意图，能评价“语气是否礼貌”、“逻辑是否通顺”等主观指标。
• • 缺点：贵、慢，而且模型自己也可能看走眼。
• • C 类：人类评分员（Human）
• • 角色：最终拍板的校长。
• • 方法：真实的人类专家进行审查。
• • 优点：黄金标准（Gold Standard）。
• • 缺点：太贵、太慢，无法大规模扩展。

最佳实践：混合双打。

绝大多数测试用代码评分（比如代码能不能跑通）；复杂的逻辑用模型评分；定期抽取少量样本由人类复核，用来校准模型评分员的准确度。

很多开发者有个误区：评估就是跑分。

实际上，Anthropic 提出了一套类似安全工程中“瑞士奶酪模型”的防御体系。没有任何一层防御是完美的，但层层叠加就能堵住漏洞。

1. 1. 自动化评估（Automated Evals）：

• • 防线位置：开发阶段、CI/CD 流水线。
• • 作用：在这个阶段，你不需要真实用户。你可以跑成千上万个测试用例。如果新版本的模型在“退款流程”测试集上分数下降了，坚决不上线。

• 2. 生产环境监控（Production Monitoring）：
• • 防线位置：上线后。
• • 作用：真实世界总有你想不到的边缘情况（Edge Cases）。监控错误率、延迟、用户反馈。这是“地面真理”（Ground Truth）。
• 3. A/B 测试：
• • 防线位置：灰度发布。
• • 作用：通过真实流量对比新旧版本的核心指标（如任务完成率、用户留存）。
• 4. 人工审查（Manual Review）：
• • 防线位置：日常巡检。
• • 作用：哪怕只是每周随机抽读 10 个对话记录（Transcript），往往也能发现自动化测试覆盖不到的“低级错误”。

给开发者的实战建议

读完 Anthropic 的指南，我们总结了三条最落地的建议，适合刚开始做 Agent 的团队：

1. 尽早开始，别等完美

不要试图一开始就憋一个完美的“评估大模型”。哪怕只是写 5 个最基础的测试用例（比如：“用户说‘你好’时，不要报错”），也比裸奔强。
来自 Anthropic 的经验：Claude Code 项目一开始也只有简单的测试，后来随着功能变复杂，才加入了针对“过度设计”或“文件修改准确性”的复杂评估。

2. 从失败中提取测试题

当你的 Agent 在生产环境“翻车”时，别只修 Bug。

把这次失败转化成一个测试用例（Test Case）。

如果用户问 “天气怎么样” 导致 Agent 崩溃了，那就把“问天气”加入到你的永久测试集中。这样你的防线会越来越厚。

3. 必须看“回放”

不要只看分数（Pass/Fail）。去读 Transcript（交互记录）。

很多时候，Agent 虽然任务失败了，但它可能展现出了惊人的创造力；或者它任务成功了，但中间过程其实是错误的（比如它虽然输出了正确代码，但其实是把你的示例代码原封不动抄了一遍）。