Anthropic 的AI Agents评估体系：「瑞士奶酪模型」

上一篇文章写到 Hamel Husain 跨越三年的评估心法：Look at your data，这是培养 AI 产品品味的必经之路。但当从 Demo 走向 Production，面对线上每天数万次的交互、每个任务涉及十几步的复杂工具调用时，光靠肉眼盯着 Excel 看就远远不够了。

Anthropic 最近发布了一份工程化的评估手册，并回答了一个核心问题：如何把「看数据」这一动作，固化成一套可自动化、可度量、可迭代的系统？

这篇文章跟随原文的工程脉络，用更通俗的语言拆解这份 Agent 评估手册，一共分为五个部分。

一、Agent 评估体系的七大组件

Without evals, it’s easy to get stuck in reactive loops.

（没有评估，很容易陷入被动的死循环。）

这里的被动循环就是修了一个 Bug，却不知道是否引入了两个新 Bug。这种盲测的状态，是 Agent 从 Demo 走向产品的最大阻碍。

Anthropic 提出了一套完整的代理评估，并拆解成了七个组件。

其中最值得关注的是这两个概念：

• Transcript（轨迹）：Agent 思考、调用工具、报错、重试的全过程。这对应着上一篇说的「去读日志，看它的思考过程」。
• Outcome（结果）：任务结束时，环境发生的真实改变。这对应业务价值：票订好了吗？代码跑通了吗？

传统的 LLM 评估（比如 MMLU 测试）只看结果（答对了吗？），但 Agent 评估必须同时关注 Transcript。因为它可能通过胡乱猜测蒙对了结果，但思考路径却是完全错误的。如果不通过系统化的方式去审视 Transcript，这种运气的成功就是埋在系统里的雷。

二、没有万能钥匙：不同 Agent 的评估范式

Agent 的类型多种多样，Anthropic 提出了分而治之的评估策略。不同类型的 Agent，其评估的黄金标准截然不同。

1、编码类 Agent

也就是常说的 AI 程序员。它们需要浏览代码库、运行命令、修复 Bug。

评估核心是确定性测试。软件工程本身就有完美的评估标准：单元测试。代码能跑通吗？测试用例变绿了吗？这是最硬核的指标。

进阶做法：除了看结果，还可以引入静态代码分析作为评分器，检查代码风格；或者引入 LLM 评分器，检查代码的可读性。

只有在代码生成领域，我们才能拥有完美的「上帝视角」。

2、对话类 Agent

客服、销售、教练。它们不仅要解决问题，还要保持人设和礼貌。这是最难的，因为既要「把事办了」，又要「把话说明白」。

评估核心是多维混合评估：

• 状态检查：退款工单是否在系统中标记为「已处理」？（硬指标）
• LLM 评分：客服语气是否富有同理心？是否解释清楚了原因？（软指标，适合用 LLM-as-a-Judge）
• 轨迹约束：是否在 10 轮对话内解决了问题？（效率指标）

这就是上一篇提到的「用数据校准裁判」——需要根据人类的品味，去调教那个负责打分的 LLM。

3、研究类 Agent

搜集信息、写报告。

评估核心是主观与客观的平衡。难点在于：什么样的调研报告算好？专家之间都可能存在分歧。

Anthropic 建议组合维度：

• 覆盖率检查：报告是否包含关键事实（如公司 Q3 营收数据）？
• 来源核查：每一句话是否有引用来源？来源是否权威？
• 人类校准：必须定期用人类专家的打分来校准 LLM 评分器的标准。

在这里，看数据是为了防止幻觉。

4、计算机操作 Agent

像人一样点击鼠标、看屏幕。

评估核心是环境快照与 DOM 树。在沙盒环境中运行，检查任务结束后的文件系统、数据库状态或 UI 元素属性。文章中提到在浏览器操作中，DOM 树提取比截图更省 Token，但截图更通用。他们在 Claude for Chrome 中专门开发了 Evals 来判断 Agent 何时该用 DOM，何时该用截图。

三、直面随机性：pass@k 与 pass^k

这是最容易忽视的部分。

Agent 是概率性的。同一个 Prompt，跑两次结果可能不同。那如果一个任务 Agent 跑了 10 次，成功了 5 次，算过还是不过呢？

Anthropic 给出了两个衡量标准，分别对应着两种产品观。

指标一：pass@k（尝试 k 次，至少成功 1 次的概率）

• 场景：辅助编程、创意生成。
• 潜台词：「你多试几次，只要有一次对了我就能用。」
• 关注点：上限能力。k 越大，分数越高。

指标二：pass^k（尝试 k 次，连续成功 k 次的概率）

• 场景：银行转账、订机票、全自动客服。
• 潜台词：「必须 100% 靠谱，一次都不能搞砸。」
• 关注点：稳定性和可靠性。k 越大，分数掉得越快（指数级下跌）。

很多 Demo 看通过率很高，是因为展示的是 pass@1（甚至是从多次尝试里挑出来的最好的那一个）。但当做产品交付时，用户买单的是 pass^k。

例如，如果发现 Agent 在 pass@1 上表现优异，但在 pass^10 上惨不忍睹，说明这个系统极不稳定，可能需要引入自我反思或多数投票机制来收敛结果。

四、从 0 到 1 的实战路线图

Anthropic 的文章没有止步于理论，他们给出了一份非常落地的九步走指南。

Step 0-3：冷启动阶段

• 尽早开始：不要等有了 1000 个测试题才开始，20 到 50 个高质量的测试用例足够。早期的改进往往很明显，小样本就可以看出问题。
• 取材于实战：不要凭空编造测试题。从 Bug 列表、用户反馈、以及开发时的手动测试中提取案例。所有的测试题都应该来自真实的 bug 或用户日志。（这就是 Hamel 说的「从日志里捞」）
• 消除歧义：这是最关键的一点，给每个任务写一个标准答案。一个好的测试任务，应该让两个人类专家来做都能得出相同的结果。如果人类对「成功」的定义都有分歧，怎么能指望 Agent 做对呢？必须先有人类的共识，才会有机器的智能。

Step 4-5：构建与设计阶段

• 环境隔离：确保每次测试都是净室环境，不要让上一次测试残留的文件或缓存影响下一次。
• 评分器设计：能用代码（确定性）评，绝不用 LLM，因为代码又快又准。此外，不要过度评估过程——如果 Agent 用了一种人类没想到的方法解决了问题，那也算通过。评结果，别评路径。
• 部分分机制：识别出问题但没解决，比完全胡说八道要好。评分要有梯度。

Step 6-8：维护与迭代阶段

重点是 Check the transcripts：

如果不读 Transcript，就不知道评分器是否工作正常。

• 别只看分数：读 Agent 的思考过程。只有读了日志，才知道它是真的聪明，还是只是运气好蒙对；或者是评估代码写错了，还是 Agent 真的犯错了。
• 警惕指标饱和：当分数接近 100% 时，评估就失效了。这时候需要更难的任务，或者把这个评估集降级为回归测试，防止能力倒退。
• 全员参与：Evals 不仅仅是测试工程师的事。产品经理、销售甚至客户成功经理，都应该能提交测试用例。Evals 是产品需求的另一种表达形式。

看到这里，应该就会发现 Anthropic 与 Hamel 的核心观点殊途同归：无论系统多么自动化，最后都必须回到「人去阅读数据」这一步。

五、瑞士奶酪模型：不能只有单一防线

自动化 Evals 只是防线的一层。文章的最后，Anthropic 用「瑞士奶酪模型」来总结 Agent 的质量保障体系：每一层防线（奶酪）都有漏洞（孔洞），但只要层数够多，就能把风险挡住。

1. 自动化 Evals：第一道防线。在 CI/CD 中运行，快速迭代，覆盖面广。
2. 生产环境监控：真实世界的实况，捕捉那些合成数据里没有的 Corner Case。
3. A/B 测试：用真实流量验证改动带来的业务指标变化（如留存率、转化率）。
4. 人工抽检：即使有了 LLM 评分，人工阅读日志依然不可替代。它是校准「什么是好」的唯一标准。
5. 用户反馈：点赞和点踩。这是最直接但不一定最准确的信号，作为兜底。

在这个模型中，Look at your data 渗透在每一层里。

最后

Evals 是 AI 产品的生命线。从写下第一个自动化测试用例开始，把你的品味固化成 Agent 的规矩，把模糊的预期转化为确定的成功。

始于数据（Look at data），成于系统（Build Evals），终于洞察（Business Sense）。自动化评估让我们走得更快，但人工审查可以让我们走得更稳。