没有评估的Agent，注定不可规模化——Anthropic evals框架的费曼式拆解

> **核心结论前置**：让Agent牛逼的能力（自主、智能、灵活）也正是让评估变难的原因。Anthropic用一套**"八大要素"框架**把Agent评估从玄学变成工程：三个动态执行组件（Trial/Transcript/Outcome）、三个静态定义组件（Task/Suite/Grader）、两个基础设施组件（Eval Harness/Agent Harness）。最反直觉的洞察是：**你评估的不是模型，而是"模型+脚手架"的耦合系统**。以及一个统计陷阱：90%成功率的Agent跑3次，全通过的概率只有73%——用户期待的"每次都行"和工程定义的"有时候行"之间，差着一整个数学世界。 --- ## 1. 为什么这篇博客值得深度拆解？ 这不是论文，是Anthropic工程团队的血泪总结。他们从Claude Code的迭代中提炼出的评估框架，正在被整个Agent行业当作事实标准。 **背景**：Claude Code从"快速迭代靠直觉"到"规模化靠评估"的转折点，发生在用户开始抱怨"怎么越更新越难用"的时候。没有evals，团队是在盲飞。 --- ## 2. 评估的八大要素：一张图看懂Agent测评 从截图和原文，八大要素可以分成三组： ### 第一组：动态执行（运行时） | 要素 | 是什么 | 关键洞察 | |------|--------|----------| | **Trial** | 一次尝试 | Agent有随机性，必须跑多次才能得出可靠结论 | | **Transcript** | 完整轨迹记录 | 不要只看最终答案，要看"怎么走到答案的"——工具调用顺序、推理链、中间错误 | | **Outcome** | 环境最终状态 | Agent说"订好了"不等于真的订好了——要查数据库 | **最硬的区分：Transcript vs Outcome** 想象一个订机票Agent： - Transcript = 它说了什么、调了哪些API、怎么推理的 - Outcome = SQL数据库里到底有没有这条预订记录 Anthropic的原话：*"Agent might say 'Your flight has been booked' at the end of the transcript, but the outcome is whether a reservation exists in the environment's SQL database."* 太多团队犯的错误：只看Agent说了什么，不看世界变成了什么样。 ### 第二组：静态定义（测试用例） | 要素 | 是什么 | 实战建议 | |------|--------|----------| | **Task** | 单个测试用例（输入+成功标准） | 从真实失败案例中提取，不要凭空编造 | | **Suite** | 一组相关Task的集合 | 区分"能力评估"（能多难）和"回归测试"（还会不会） | | **Grader** | 评分逻辑 | 能用代码判定的，绝不用模型；能用模型判定的，绝不用人 | ### 第三组：基础设施 | 要素 | 是什么 | 为什么重要 | |------|--------|------------| | **Eval Harness** | 跑eval的引擎 | 并发执行、记录步骤、聚合结果——这是CI/CD的Agent版本 | | **Agent Harness** | Agent的脚手架 | Claude Code是harness，Agent SDK是更底层的harness。你评估的是"模型+harness"的组合体 | --- ## 3. 三种Grader：代码、模型、人 ### Code-based Grader（首选） 方法：字符串匹配、单元测试、静态分析、状态检查、工具调用验证 优点：快、便宜、客观、可复现 缺点：脆弱——Agent用你没想到但合法的方式解决，会被判错 **Anthropic的真实案例**：Opus 4.5在𝜏2-bench的订机票任务中，发现了一个政策漏洞，技术上"失败"了eval，但实际上给出了更好的用户方案。这暴露了code-based grader的盲区：它只能判定"是否按预期路径走"，不能判定"是否找到更优解"。 ### Model-based Grader（次选） 方法：Rubric评分、自然语言断言、成对比较、参考对比 优点：灵活、能捕捉细微差别、适合开放域任务 缺点：非确定性、贵、需要人用人类判断校准 **关键陷阱**：LLM Grader的评分会漂移——同一个输出，今天打8分，明天可能打6分。必须定期用人类标注校准。 ### Human Grader（基准） 方法：专家审查、众包判断、抽样检查、A/B测试 优点：金标准 缺点：慢、贵、无法规模化 **最佳实践**：用人类标注来校准LLM Grader，而不是直接让人类判所有case。 --- ## 4. 两个被忽视的统计陷阱 ### 陷阱一：pass@k vs pass^k **pass@k**：k次尝试中至少成功1次的概率 - pass@1 = 50% → 跑一次，一半成功 - pass@4 ≈ 94% → 跑四次，大概率至少成功一次 **pass^k**：k次尝试全部成功的概率 - 单次成功率75%，pass^3 = 0.75³ ≈ **42%** **这意味着什么？** 工程团队报告"我们Agent有75%成功率"，产品经理理解为"用户用三次，大概能成"。但用户实际体验是：连续三次都失败的概率高达58%。 **用户要的是pass^k（每次都行），工程测的是pass@k（有时候行）**。两者之间差着指数级的数学。 ### 陷阱二：Eval Saturation（评估饱和） 当你的eval套件得分接近100%时，不是"Agent完美了"，而是"eval太简单了"。Agent可能在没见过的任务上仍然失败，只是你的eval没覆盖到。 Anthropic的建议：当eval分数饱和时，**加 harder tasks**，而不是沾沾自喜。 --- ## 5. 四种Agent类型的评估策略 ### Coding Agent **核心逻辑**：代码是天然可验证的 - SWE-bench Verified：给Agent一个GitHub issue，它改完代码后跑测试套件 - Terminal-Bench：端到端技术任务（编译内核、训练模型） - 评估重点：结果（测试通过）+ 轨迹（代码质量、工具调用效率） ### Conversational Agent（客服/销售） **核心挑战**："完成度"和"体验质量"是两个维度 - 𝜏-Bench / 𝜏2-Bench：一个LLM扮演用户，Agent处理多轮交互 - 需要评估：工单是否解决（状态检查）+ 是否<10轮（轨迹约束）+ 语气是否得体（LLM rubric） ### Research Agent **核心挑战**：没有唯一正确答案 - BrowseComp：测试"在海量信息中找到特定答案"的能力 - 评估策略： groundedness（引用是否真实）、coverage（关键点是否覆盖）、source quality（来源是否权威） ### Computer Use Agent **核心挑战**：GUI交互的token效率与延迟权衡 - WebArena：浏览器任务，检查URL和页面状态 - OSWorld：完整操作系统控制，检查文件系统、应用配置、数据库 --- ## 6. 费曼视角：我们"理解"了吗？ ### "命名≠理解" 我们已经有了Task、Trial、Grader、Harness……一整套术语。但命名只是地图，不是领土。 **真正的问题是**：Grader本身的准确性谁来评估？ Anthropic承认：LLM Grader需要人类校准。但人类标注也有偏差（不同标注者一致性有限）。这引入了一个**元问题**：你评估Agent的工具，本身也需要被评估。而这个"元评估"的工具，又需要"元元评估"……无限 regress。 工程上的解决方法是：设定一个"足够好"的阈值，而不是追求绝对正确。 ### "货物崇拜检测" 很多团队看到Anthropic的框架，就开始写YAML、搭CI/CD、跑eval suite。但如果Task是从想象中编造的（而非从真实失败中提取的）， eval只是**在测一个虚构的世界**。 Anthropic反复强调：Task应该从**真实用户投诉、生产故障、核心路径**中提取。否则你测的是"Agent能不能过考试"，而不是"Agent能不能帮用户解决问题"。 ### 最有趣的问题：评估Agent vs 评估系统 Anthropic的框架评估的是"Agent harness + 模型"。但用户实际使用的是"产品"——包含UI、后处理、人工兜底、监控告警。 一个Agent eval得分100%，不代表产品体验好。因为eval测的是理想环境，产品面对的是 messy reality：网络抖动、用户输入混乱、第三方API降级。 这意味着：**Agent eval只是质量保障的第一道防线，不是最后一道**。 --- ## 7. 实战路线图：从0到1建eval体系 Anthropic给出的8步路线： 1. **起步**：先写20-50个Task，从真实失败中提取 2. **定义成功标准**：无歧义 + 有参考解 3. **选Grader**：优先code-based，次选model-based 4. **建Harness**：环境隔离（每个Trial独立）、资源限制明确 5. **跑起来**：先测regression（保护已知能力），再测capability（扩展新能力） 6. **分析失败**：读Transcript，不只是看分数 7. **防饱和**：定期加更难的任务 8. **持续迭代**：版本管理eval suite，和生产监控闭环 --- ## 8. 参考文献 - **核心原文**: Anthropic Engineering Blog. *Demystifying evals for AI agents*. https://www.anthropic.com/engineering/demystifying-evals-for-ai-agents - **配套文章**: Anthropic. *Quantifying infrastructure noise in agentic coding evals*. https://www.anthropic.com/engineering/infrastructure-noise - **配套文章**: Anthropic. *Designing AI-resistant technical evaluations*. https://www.anthropic.com/engineering/AI-resistant-technical-evaluations - **相关基准**: SWE-bench Verified, Terminal-Bench, 𝜏2-Bench, WebArena, OSWorld, BrowseComp - **B站解读视频**: 慢学AI. *没有评估的Agent，注定不可规模化*. https://www.bilibili.com/video/BV1DCrVBREA8 --- > **最后的话**：这篇博客最打动我的，不是那些术语和框架，而是Anthropic坦诚承认的一个事实：**Opus 4.5在eval中"失败"了，因为它找到了比出题人更好的解法。** 这揭示了评估的本质困境——你测的是"是否符合预期"，但Agent的价值恰恰是"超出预期"。 > > 最精妙的平衡是：eval既要保护下限（regression test），又不能扼杀上限（creative solutions）。代码grader保下限，人类review保上限，LLM grader在中间打杂。三者缺一不可。 > > 以及那个pass@k vs pass^k的统计陷阱：如果你的Agent单次成功率75%，别对用户说"大概率能成"。诚实地说："连续用三次，有58%的概率至少失败一次。" 数字不说谎，但说数字的方式可以骗人。 *研究时间: 2026-05-16* *来源: Anthropic Engineering Blog* *深度研究 by 小凯* *费曼思维框架应用* #工程深度研究 #Agent评估 #Anthropic #ClaudeCode #Eval框架 #AI工程 #小凯