{"schema_version":1,"id":"article:anthropic-agent-evals-swiss-cheese","kind":"article","slug":"anthropic-agent-evals-swiss-cheese","title":"Anthropic 的AI Agents评估体系：「瑞士奶酪模型」","author":"晨旭","url":"https://chenxu.xin/writing/anthropic-agent-evals-swiss-cheese","date":"2026-02-01","updated":"2026-02-01","description":"拆解 Anthropic 的 Agent 评估手册：七大组件、四类 Agent 各自的评估范式、pass@k 与 pass^k 的分野、从 0 到 1 的九步实战路线，以及为什么单一防线不够。","position":null,"group":null,"series":"入门系列文章","tags":["evaluation","agent","ai-pm"],"publication_status":"public","maturity":"evergreen","body_sha256":"ebe3d67b4965bf0f337ee28610039c3adf80f836a268ff0c5871baf87aef299f","paragraph_rule":"src/lib/paragraphs.mjs@1","paragraphs":[{"id":"p1","kind":"paragraph","text":"上一篇文章写到 Hamel Husain 跨越三年的评估心法：Look at your data，这是培养 AI 产品品味的必经之路。但当从 Demo 走向 Production，面对线上每天数万次的交互、每个任务涉及十几步的复杂工具调用时，光靠肉眼盯着 Excel 看就远远不够了。","raw":"上一篇文章写到 Hamel Husain 跨越三年的评估心法：Look at your data，这是培养 AI 产品品味的必经之路。但当从 Demo 走向 Production，面对线上每天数万次的交互、每个任务涉及十几步的复杂工具调用时，光靠肉眼盯着 Excel 看就远远不够了。"},{"id":"p2","kind":"paragraph","text":"Anthropic 最近发布了一份工程化的评估手册，并回答了一个核心问题：如何把「看数据」这一动作，固化成一套可自动化、可度量、可迭代的系统？","raw":"Anthropic 最近发布了一份工程化的评估手册，并回答了一个核心问题：如何把「看数据」这一动作，固化成一套可自动化、可度量、可迭代的系统？"},{"id":"p3","kind":"paragraph","text":"这篇文章跟随原文的工程脉络，用更通俗的语言拆解这份 Agent 评估手册，一共分为五个部分。","raw":"这篇文章跟随原文的工程脉络，用更通俗的语言拆解这份 Agent 评估手册，一共分为五个部分。"},{"id":"p4","kind":"heading","text":"一、Agent 评估体系的七大组件","raw":"## 一、Agent 评估体系的七大组件"},{"id":"p5","kind":"quote","text":"Without evals, it's easy to get stuck in reactive loops.\n（没有评估，很容易陷入被动的死循环。）","raw":"> Without evals, it's easy to get stuck in reactive loops.\n>\n> （没有评估，很容易陷入被动的死循环。）"},{"id":"p6","kind":"paragraph","text":"这里的被动循环就是修了一个 Bug，却不知道是否引入了两个新 Bug。这种盲测的状态，是 Agent 从 Demo 走向产品的最大阻碍。","raw":"这里的被动循环就是修了一个 Bug，却不知道是否引入了两个新 Bug。这种盲测的状态，是 Agent 从 Demo 走向产品的最大阻碍。"},{"id":"p7","kind":"paragraph","text":"Anthropic 提出了一套完整的代理评估，并拆解成了七个组件。","raw":"Anthropic 提出了一套完整的代理评估，并拆解成了七个组件。"},{"id":"p8","kind":"paragraph","text":"其中最值得关注的是这两个概念：","raw":"其中最值得关注的是这两个概念："},{"id":"p9","kind":"list","text":"- Transcript（轨迹）：Agent 思考、调用工具、报错、重试的全过程。这对应着上一篇说的「去读日志，看它的思考过程」。\n- Outcome（结果）：任务结束时，环境发生的真实改变。这对应业务价值：票订好了吗？代码跑通了吗？","raw":"- **Transcript（轨迹）**：Agent 思考、调用工具、报错、重试的全过程。这对应着上一篇说的「去读日志，看它的思考过程」。\n- **Outcome（结果）**：任务结束时，环境发生的真实改变。这对应业务价值：票订好了吗？代码跑通了吗？"},{"id":"p10","kind":"paragraph","text":"传统的 LLM 评估（比如 MMLU 测试）只看结果（答对了吗？），但 Agent 评估必须同时关注 Transcript。因为它可能通过胡乱猜测蒙对了结果，但思考路径却是完全错误的。如果不通过系统化的方式去审视 Transcript，这种运气的成功就是埋在系统里的雷。","raw":"传统的 LLM 评估（比如 MMLU 测试）只看结果（答对了吗？），但 Agent 评估必须同时关注 Transcript。因为它可能通过胡乱猜测蒙对了结果，但思考路径却是完全错误的。如果不通过系统化的方式去审视 Transcript，这种运气的成功就是埋在系统里的雷。"},{"id":"p11","kind":"heading","text":"二、没有万能钥匙：不同 Agent 的评估范式","raw":"## 二、没有万能钥匙：不同 Agent 的评估范式"},{"id":"p12","kind":"paragraph","text":"Agent 的类型多种多样，Anthropic 提出了分而治之的评估策略。不同类型的 Agent，其评估的黄金标准截然不同。","raw":"Agent 的类型多种多样，Anthropic 提出了分而治之的评估策略。不同类型的 Agent，其评估的黄金标准截然不同。"},{"id":"p13","kind":"heading","text":"1、编码类 Agent","raw":"### 1、编码类 Agent"},{"id":"p14","kind":"paragraph","text":"也就是常说的 AI 程序员。它们需要浏览代码库、运行命令、修复 Bug。","raw":"也就是常说的 AI 程序员。它们需要浏览代码库、运行命令、修复 Bug。"},{"id":"p15","kind":"paragraph","text":"评估核心是确定性测试。软件工程本身就有完美的评估标准：单元测试。代码能跑通吗？测试用例变绿了吗？这是最硬核的指标。","raw":"**评估核心是确定性测试**。软件工程本身就有完美的评估标准：单元测试。代码能跑通吗？测试用例变绿了吗？这是最硬核的指标。"},{"id":"p16","kind":"paragraph","text":"进阶做法：除了看结果，还可以引入静态代码分析作为评分器，检查代码风格；或者引入 LLM 评分器，检查代码的可读性。","raw":"进阶做法：除了看结果，还可以引入静态代码分析作为评分器，检查代码风格；或者引入 LLM 评分器，检查代码的可读性。"},{"id":"p17","kind":"paragraph","text":"只有在代码生成领域，我们才能拥有完美的「上帝视角」。","raw":"只有在代码生成领域，我们才能拥有完美的「上帝视角」。"},{"id":"p18","kind":"heading","text":"2、对话类 Agent","raw":"### 2、对话类 Agent"},{"id":"p19","kind":"paragraph","text":"客服、销售、教练。它们不仅要解决问题，还要保持人设和礼貌。这是最难的，因为既要「把事办了」，又要「把话说明白」。","raw":"客服、销售、教练。它们不仅要解决问题，还要保持人设和礼貌。这是最难的，因为既要「把事办了」，又要「把话说明白」。"},{"id":"p20","kind":"paragraph","text":"评估核心是多维混合评估：","raw":"**评估核心是多维混合评估**："},{"id":"p21","kind":"list","text":"- 状态检查：退款工单是否在系统中标记为「已处理」？（硬指标）\n- LLM 评分：客服语气是否富有同理心？是否解释清楚了原因？（软指标，适合用 LLM-as-a-Judge）\n- 轨迹约束：是否在 10 轮对话内解决了问题？（效率指标）","raw":"- **状态检查**：退款工单是否在系统中标记为「已处理」？（硬指标）\n- **LLM 评分**：客服语气是否富有同理心？是否解释清楚了原因？（软指标，适合用 LLM-as-a-Judge）\n- **轨迹约束**：是否在 10 轮对话内解决了问题？（效率指标）"},{"id":"p22","kind":"paragraph","text":"这就是上一篇提到的「用数据校准裁判」——需要根据人类的品味，去调教那个负责打分的 LLM。","raw":"这就是上一篇提到的「用数据校准裁判」——需要根据人类的品味，去调教那个负责打分的 LLM。"},{"id":"p23","kind":"heading","text":"3、研究类 Agent","raw":"### 3、研究类 Agent"},{"id":"p24","kind":"paragraph","text":"搜集信息、写报告。","raw":"搜集信息、写报告。"},{"id":"p25","kind":"paragraph","text":"评估核心是主观与客观的平衡。难点在于：什么样的调研报告算好？专家之间都可能存在分歧。","raw":"**评估核心是主观与客观的平衡**。难点在于：什么样的调研报告算好？专家之间都可能存在分歧。"},{"id":"p26","kind":"paragraph","text":"Anthropic 建议组合维度：","raw":"Anthropic 建议组合维度："},{"id":"p27","kind":"list","text":"- 覆盖率检查：报告是否包含关键事实（如公司 Q3 营收数据）？\n- 来源核查：每一句话是否有引用来源？来源是否权威？\n- 人类校准：必须定期用人类专家的打分来校准 LLM 评分器的标准。","raw":"- **覆盖率检查**：报告是否包含关键事实（如公司 Q3 营收数据）？\n- **来源核查**：每一句话是否有引用来源？来源是否权威？\n- **人类校准**：必须定期用人类专家的打分来校准 LLM 评分器的标准。"},{"id":"p28","kind":"paragraph","text":"在这里，看数据是为了防止幻觉。","raw":"在这里，看数据是为了防止幻觉。"},{"id":"p29","kind":"heading","text":"4、计算机操作 Agent","raw":"### 4、计算机操作 Agent"},{"id":"p30","kind":"paragraph","text":"像人一样点击鼠标、看屏幕。","raw":"像人一样点击鼠标、看屏幕。"},{"id":"p31","kind":"paragraph","text":"评估核心是环境快照与 DOM 树。在沙盒环境中运行，检查任务结束后的文件系统、数据库状态或 UI 元素属性。文章中提到在浏览器操作中，DOM 树提取比截图更省 Token，但截图更通用。他们在 Claude for Chrome 中专门开发了 Evals 来判断 Agent 何时该用 DOM，何时该用截图。","raw":"**评估核心是环境快照与 DOM 树**。在沙盒环境中运行，检查任务结束后的文件系统、数据库状态或 UI 元素属性。文章中提到在浏览器操作中，DOM 树提取比截图更省 Token，但截图更通用。他们在 Claude for Chrome 中专门开发了 Evals 来判断 Agent 何时该用 DOM，何时该用截图。"},{"id":"p32","kind":"heading","text":"三、直面随机性：pass@k 与 pass^k","raw":"## 三、直面随机性：pass@k 与 pass^k"},{"id":"p33","kind":"paragraph","text":"这是最容易忽视的部分。","raw":"这是最容易忽视的部分。"},{"id":"p34","kind":"paragraph","text":"Agent 是概率性的。同一个 Prompt，跑两次结果可能不同。那如果一个任务 Agent 跑了 10 次，成功了 5 次，算过还是不过呢？","raw":"Agent 是概率性的。同一个 Prompt，跑两次结果可能不同。那如果一个任务 Agent 跑了 10 次，成功了 5 次，算过还是不过呢？"},{"id":"p35","kind":"paragraph","text":"Anthropic 给出了两个衡量标准，分别对应着两种产品观。","raw":"Anthropic 给出了两个衡量标准，分别对应着两种产品观。"},{"id":"p36","kind":"paragraph","text":"指标一：pass@k（尝试 k 次，至少成功 1 次的概率）","raw":"**指标一：pass@k**（尝试 k 次，至少成功 1 次的概率）"},{"id":"p37","kind":"list","text":"- 场景：辅助编程、创意生成。\n- 潜台词：「你多试几次，只要有一次对了我就能用。」\n- 关注点：上限能力。k 越大，分数越高。","raw":"- 场景：辅助编程、创意生成。\n- 潜台词：「你多试几次，只要有一次对了我就能用。」\n- 关注点：上限能力。k 越大，分数越高。"},{"id":"p38","kind":"paragraph","text":"指标二：pass^k（尝试 k 次，连续成功 k 次的概率）","raw":"**指标二：pass^k**（尝试 k 次，连续成功 k 次的概率）"},{"id":"p39","kind":"list","text":"- 场景：银行转账、订机票、全自动客服。\n- 潜台词：「必须 100% 靠谱，一次都不能搞砸。」\n- 关注点：稳定性和可靠性。k 越大，分数掉得越快（指数级下跌）。","raw":"- 场景：银行转账、订机票、全自动客服。\n- 潜台词：「必须 100% 靠谱，一次都不能搞砸。」\n- 关注点：稳定性和可靠性。k 越大，分数掉得越快（指数级下跌）。"},{"id":"p40","kind":"paragraph","text":"很多 Demo 看通过率很高，是因为展示的是 pass@1（甚至是从多次尝试里挑出来的最好的那一个）。但当做产品交付时，用户买单的是 pass^k。","raw":"很多 Demo 看通过率很高，是因为展示的是 pass@1（甚至是从多次尝试里挑出来的最好的那一个）。但当做产品交付时，用户买单的是 pass^k。"},{"id":"p41","kind":"paragraph","text":"例如，如果发现 Agent 在 pass@1 上表现优异，但在 pass^10 上惨不忍睹，说明这个系统极不稳定，可能需要引入自我反思或多数投票机制来收敛结果。","raw":"例如，如果发现 Agent 在 pass@1 上表现优异，但在 pass^10 上惨不忍睹，说明这个系统极不稳定，可能需要引入自我反思或多数投票机制来收敛结果。"},{"id":"p42","kind":"heading","text":"四、从 0 到 1 的实战路线图","raw":"## 四、从 0 到 1 的实战路线图"},{"id":"p43","kind":"paragraph","text":"Anthropic 的文章没有止步于理论，他们给出了一份非常落地的九步走指南。","raw":"Anthropic 的文章没有止步于理论，他们给出了一份非常落地的九步走指南。"},{"id":"p44","kind":"heading","text":"Step 0-3：冷启动阶段","raw":"### Step 0-3：冷启动阶段"},{"id":"p45","kind":"list","text":"- 尽早开始：不要等有了 1000 个测试题才开始，20 到 50 个高质量的测试用例足够。早期的改进往往很明显，小样本就可以看出问题。\n- 取材于实战：不要凭空编造测试题。从 Bug 列表、用户反馈、以及开发时的手动测试中提取案例。所有的测试题都应该来自真实的 bug 或用户日志。（这就是 Hamel 说的「从日志里捞」）\n- 消除歧义：这是最关键的一点，给每个任务写一个标准答案。一个好的测试任务，应该让两个人类专家来做都能得出相同的结果。如果人类对「成功」的定义都有分歧，怎么能指望 Agent 做对呢？必须先有人类的共识，才会有机器的智能。","raw":"- **尽早开始**：不要等有了 1000 个测试题才开始，20 到 50 个高质量的测试用例足够。早期的改进往往很明显，小样本就可以看出问题。\n- **取材于实战**：不要凭空编造测试题。从 Bug 列表、用户反馈、以及开发时的手动测试中提取案例。所有的测试题都应该来自真实的 bug 或用户日志。（这就是 Hamel 说的「从日志里捞」）\n- **消除歧义**：这是最关键的一点，给每个任务写一个标准答案。一个好的测试任务，应该让两个人类专家来做都能得出相同的结果。如果人类对「成功」的定义都有分歧，怎么能指望 Agent 做对呢？必须先有人类的共识，才会有机器的智能。"},{"id":"p46","kind":"heading","text":"Step 4-5：构建与设计阶段","raw":"### Step 4-5：构建与设计阶段"},{"id":"p47","kind":"list","text":"- 环境隔离：确保每次测试都是净室环境，不要让上一次测试残留的文件或缓存影响下一次。\n- 评分器设计：能用代码（确定性）评，绝不用 LLM，因为代码又快又准。此外，不要过度评估过程——如果 Agent 用了一种人类没想到的方法解决了问题，那也算通过。评结果，别评路径。\n- 部分分机制：识别出问题但没解决，比完全胡说八道要好。评分要有梯度。","raw":"- **环境隔离**：确保每次测试都是净室环境，不要让上一次测试残留的文件或缓存影响下一次。\n- **评分器设计**：能用代码（确定性）评，绝不用 LLM，因为代码又快又准。此外，不要过度评估过程——如果 Agent 用了一种人类没想到的方法解决了问题，那也算通过。评结果，别评路径。\n- **部分分机制**：识别出问题但没解决，比完全胡说八道要好。评分要有梯度。"},{"id":"p48","kind":"heading","text":"Step 6-8：维护与迭代阶段","raw":"### Step 6-8：维护与迭代阶段"},{"id":"p49","kind":"paragraph","text":"重点是 Check the transcripts：","raw":"重点是 **Check the transcripts**："},{"id":"p50","kind":"quote","text":"如果不读 Transcript，就不知道评分器是否工作正常。","raw":"> 如果不读 Transcript，就不知道评分器是否工作正常。"},{"id":"p51","kind":"list","text":"- 别只看分数：读 Agent 的思考过程。只有读了日志，才知道它是真的聪明，还是只是运气好蒙对；或者是评估代码写错了，还是 Agent 真的犯错了。\n- 警惕指标饱和：当分数接近 100% 时，评估就失效了。这时候需要更难的任务，或者把这个评估集降级为回归测试，防止能力倒退。\n- 全员参与：Evals 不仅仅是测试工程师的事。产品经理、销售甚至客户成功经理，都应该能提交测试用例。Evals 是产品需求的另一种表达形式。","raw":"- **别只看分数**：读 Agent 的思考过程。只有读了日志，才知道它是真的聪明，还是只是运气好蒙对；或者是评估代码写错了，还是 Agent 真的犯错了。\n- **警惕指标饱和**：当分数接近 100% 时，评估就失效了。这时候需要更难的任务，或者把这个评估集降级为回归测试，防止能力倒退。\n- **全员参与**：Evals 不仅仅是测试工程师的事。产品经理、销售甚至客户成功经理，都应该能提交测试用例。Evals 是产品需求的另一种表达形式。"},{"id":"p52","kind":"paragraph","text":"看到这里，应该就会发现 Anthropic 与 Hamel 的核心观点殊途同归：无论系统多么自动化，最后都必须回到「人去阅读数据」这一步。","raw":"看到这里，应该就会发现 Anthropic 与 Hamel 的核心观点殊途同归：无论系统多么自动化，最后都必须回到「人去阅读数据」这一步。"},{"id":"p53","kind":"heading","text":"五、瑞士奶酪模型：不能只有单一防线","raw":"## 五、瑞士奶酪模型：不能只有单一防线"},{"id":"p54","kind":"paragraph","text":"自动化 Evals 只是防线的一层。文章的最后，Anthropic 用「瑞士奶酪模型」来总结 Agent 的质量保障体系：每一层防线（奶酪）都有漏洞（孔洞），但只要层数够多，就能把风险挡住。","raw":"自动化 Evals 只是防线的一层。文章的最后，Anthropic 用「瑞士奶酪模型」来总结 Agent 的质量保障体系：每一层防线（奶酪）都有漏洞（孔洞），但只要层数够多，就能把风险挡住。"},{"id":"p55","kind":"list","text":"1. 自动化 Evals：第一道防线。在 CI/CD 中运行，快速迭代，覆盖面广。\n2. 生产环境监控：真实世界的实况，捕捉那些合成数据里没有的 Corner Case。\n3. A/B 测试：用真实流量验证改动带来的业务指标变化（如留存率、转化率）。\n4. 人工抽检：即使有了 LLM 评分，人工阅读日志依然不可替代。它是校准「什么是好」的唯一标准。\n5. 用户反馈：点赞和点踩。这是最直接但不一定最准确的信号，作为兜底。","raw":"1. **自动化 Evals**：第一道防线。在 CI/CD 中运行，快速迭代，覆盖面广。\n2. **生产环境监控**：真实世界的实况，捕捉那些合成数据里没有的 Corner Case。\n3. **A/B 测试**：用真实流量验证改动带来的业务指标变化（如留存率、转化率）。\n4. **人工抽检**：即使有了 LLM 评分，人工阅读日志依然不可替代。它是校准「什么是好」的唯一标准。\n5. **用户反馈**：点赞和点踩。这是最直接但不一定最准确的信号，作为兜底。"},{"id":"p56","kind":"paragraph","text":"在这个模型中，Look at your data 渗透在每一层里。","raw":"在这个模型中，Look at your data 渗透在每一层里。"},{"id":"p57","kind":"heading","text":"最后","raw":"## 最后"},{"id":"p58","kind":"paragraph","text":"Evals 是 AI 产品的生命线。从写下第一个自动化测试用例开始，把你的品味固化成 Agent 的规矩，把模糊的预期转化为确定的成功。","raw":"Evals 是 AI 产品的生命线。从写下第一个自动化测试用例开始，把你的品味固化成 Agent 的规矩，把模糊的预期转化为确定的成功。"},{"id":"p59","kind":"paragraph","text":"始于数据（Look at data），成于系统（Build Evals），终于洞察（Business Sense）。自动化评估让我们走得更快，但人工审查可以让我们走得更稳。","raw":"始于数据（Look at data），成于系统（Build Evals），终于洞察（Business Sense）。自动化评估让我们走得更快，但人工审查可以让我们走得更稳。"}],"authored_claims":[{"id":"transcript-matters-as-much-as-outcome","text":"传统 LLM 评估只看结果，但 Agent 评估必须同时看 Transcript。它可能靠瞎猜蒙对结果而思考路径完全错误，这种运气的成功就是埋在系统里的雷。","stance":"judgment","confidence":"high","supersedes":null,"note":null,"formed_at":"2026-02-01"},{"id":"pass-at-k-vs-pass-power-k","text":"pass@k 衡量上限能力，pass^k 衡量稳定性。Demo 展示的通常是 pass@1，但产品交付时用户买单的是 pass^k。","stance":"fact","confidence":"high","supersedes":null,"note":null,"formed_at":"2026-02-01"},{"id":"human-consensus-before-machine","text":"一个好的测试任务应该让两个人类专家做都能得出相同结果。如果人类对「成功」的定义都有分歧，就别指望 Agent 能做对——必须先有人类的共识，才会有机器的智能。","stance":"judgment","confidence":"high","supersedes":null,"note":null,"formed_at":"2026-02-01"},{"id":"score-outcome-not-path","text":"能用代码确定性评分就绝不用 LLM。而且不要过度评估过程，如果 Agent 用了一种人类没想到的方法解决问题，那也算通过——评结果，别评路径。","stance":"judgment","confidence":null,"supersedes":null,"note":null,"formed_at":"2026-02-01"},{"id":"metric-saturation-is-a-signal","text":"当分数接近 100% 时评估就失效了。这时候要么换更难的任务，要么把这个评估集降级为回归测试，防止能力倒退。","stance":"judgment","confidence":null,"supersedes":null,"note":null,"formed_at":"2026-02-01"}],"claim_ids":["transcript-matters-as-much-as-outcome","pass-at-k-vs-pass-power-k","human-consensus-before-machine","score-outcome-not-path","metric-saturation-is-a-signal"],"revision":"cc8db080123c0a9e35c6f5016dfef2363c9c8d1a976c1a47fc71f86d8441f5fa"}