没有评估的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工程 #小凯