好的评估体系让团队能更有信心地发布 AI Agent。没有评估，你只能在生产环境里发现问题——修一个故障又引发另一个，陷入被动循环。评估让问题在影响用户之前就变得可见。
这篇文章整理自 Anthropic 工程团队的分享。
为什么要搞评估？
刚开始构建 Agent 的时候，手动测试、内部试用、直觉判断，靠这些能走很远。评估看起来反而像是拖慢发布的额外负担。
但当 Agent 进入生产环境开始规模化，这套模式就会崩溃。
崩溃点通常长这样：用户报告 Agent 在改动后"感觉变差了"，但除了猜测，你没有任何方法验证。没有评估，调试只能是被动的——等投诉、手动复现、修 bug、祈祷没有其他地方退化。
有评估的好处：
- 发布前能自动测试数百个场景
- 能区分真正的回归和随机噪音
- 新模型发布时，有评估的团队几天能完成迁移，没评估的要几周
- 产品和研究团队有共同的优化目标
Claude Code 的例子：一开始靠内外部用户反馈快速迭代，后来加了评估——先针对简洁性和文件编辑这些窄领域，然后扩展到更复杂的行为比如过度工程化。这些评估帮助识别问题、指导改进，产品和研究能对齐。
核心概念
一个评估就是对 AI 系统的测试：给 AI 一个输入，对输出应用评分逻辑来衡量成功。
几个术语：
| 术语 | 什么意思 |
|---|---|
| 任务 (Task) | 带有定义输入和成功标准的单个测试 |
| 试验 (Trial) | 对任务的单次尝试，因为模型输出会变化，需要跑多次 |
| 评分器 (Grader) | 对 Agent 某方面性能打分的逻辑 |
| 记录 (Transcript) | 试验的完整记录，包括输出、工具调用、推理等 |
| 结果 (Outcome) | 试验结束时环境的最终状态 |
Agent 评估比单轮评估复杂得多：Agent 跨多个回合用工具、会修改环境状态、错误可能传播累积。前沿模型还经常找到超越静态评估限制的创造性解决方案。
有个有意思的例子：Opus 4.5 在解决一个预订航班的问题时，发现了政策里的一个漏洞。它"未通过"书面评估，但实际上给用户想出了更好的方案。
评分器类型
Agent 评估通常结合三种评分器：
基于代码的评分器
确定性输出，完全可重现，执行速度快，成本低。适合单元测试、状态验证、格式检查。
基于模型的评分器
灵活处理开放式任务，能捕捉细微差别，可扩展。方法包括基于评分准则打分、自然语言断言、成对比较、多评委共识。挑战是非确定性，比代码更贵，需要跟人工评分校准。
人工评分器
黄金标准质量，匹配专家判断，用于校准模型评分器。挑战是贵且慢。
能力评估 vs 回归评估
能力评估问的是："这个 Agent 能做好什么？"
应该从低通过率开始，针对 Agent 难以完成的任务，给团队一个需要攀登的高峰。
回归评估问的是："Agent 还能处理它以前能处理的任务吗？"
应该有接近 100% 的通过率。分数下降意味着有问题需要修复。
演进路径：高通过率的能力评估可以"毕业"成为回归套件。曾经衡量"我们能做到吗"的任务变成衡量"我们还能可靠地做到吗"。
不同类型 Agent 怎么评估
编码 Agent
核心方法是确定性测试 + LLM 准则评估 + 静态分析 + 状态检查 + 工具调用追踪。
关键基准：SWE-bench Verified（给 Agent GitHub issue，跑测试套件评分），Terminal-Bench（端到端技术任务，比如从源码构建 Linux 内核）。
对话 Agent
交互本身的质量就是评估内容的一部分。多维度成功：工单是否解决（状态检查）+ 是否在 10 轮内完成（记录约束）+ 语气是否合适（LLM 准则）。
研究 Agent
挑战在于专家可能对综合是否全面存在分歧，参考内容不断变化，更长更开放的输出为错误创造更多空间。
策略：事实依据检查（声明得到检索源支持）、覆盖率检查（好答案必须包含的关键事实）、来源质量检查（来源是权威的）。
计算机使用 Agent
需要在真实或沙箱环境跑 Agent，检查是否达到预期结果，做后端状态验证（确认订单确实下了，不只是确认页面出现了）。
处理非确定性
Agent 行为在运行之间会变化，两个关键指标：
pass@k：Agent 在 k 次尝试中至少获得一个正确解决方案的可能性。适合"有一个成功就够"的工具。
pass^k：所有 k 次试验都成功的概率。如果每次试验成功率是 75%，跑 3 次全部通过的概率是 (0.75)³ ≈ 42%。适合面向用户的 Agent，用户期望每次都可靠。
从零到一的路线图
第 0 步：尽早开始
不需要几百个任务才开始。20-50 个从真实失败中提取的简单任务就是很好的起点。
早期 Agent 开发中，每次系统变更通常有清晰可见的影响，大效应量意味着小样本量就够了。
第 1 步：从手动测试开始
从你开发时运行的手动检查开始——每次发布前验证的行为，用户尝试的常见任务，bug 追踪器，支持队列。
第 2 步：写明确的任务和参考解决方案
好任务的标准：两个领域专家独立评判会得出相同的通过/失败结论。
任务规范里的模糊性会变成指标里的噪音。评分器检查的一切都应该在任务描述里明确。
重要提示：用前沿模型时，多次试验 0% 通过率通常是任务有问题的信号，不一定是 Agent 无能。
第 3 步：构建平衡的问题集
测试行为应该发生和不应该发生的情况。单边评估会导致单边优化。
例子：为 Claude.ai 构建网络搜索评估时，挑战是防止模型在不该搜索时搜索，同时保持它在适当时进行广泛研究的能力。团队构建了两个方向的评估：应该搜索的查询和应该从现有知识回答的查询。
第 4 步：构建健壮的评估框架
环境隔离：每次试验从干净环境开始。避免运行间不必要的共享状态。
第 5 步：周到地设计评分器
推荐顺序：尽可能用确定性评分器 → 必要时用 LLM 评分器 → 谨慎用人工评分器。
关键原则：
- 评分产出，不是路径（Agent 经常找到设计者没预料到的有效方法）
- 为多组件任务构建部分学分
- 给 LLM 一条出路（返回"未知"的指令）
- 让评分器抵抗绕过
第 6 步：检查记录
你不知道评分器是否工作良好，除非你阅读许多试验的记录和成绩。失败应该看起来公平，清楚 Agent 做错了什么。
阅读记录是验证评估在衡量真正重要内容的方式。
第 7 步：监控能力评估饱和
100% 的评估追踪回归但不提供改进信号。
Qodo 的例子：最初对 Opus 4.5 印象不深，因为他们的一次性编码评估没捕捉到更长更复杂任务的收益。后来开发了新的 Agent 评估框架，才看清楚进步。
第 8 步：长期维护
评估套件是需要持续关注和明确所有权才能保持有用的活文档。
最有效的方法：建立专门的评估团队拥有核心基础设施，领域专家和产品团队贡献大多数任务并自己运行评估。让最接近产品需求和用户的人定义成功。
评估与其他方法的配合
评估只是理解 Agent 性能的众多方式之一：
| 方法 | 优势 | 最佳时机 |
|---|---|---|
| 自动化评估 | 更快迭代、完全可重现 | 预发布、CI/CD |
| 生产监控 | 揭示真实用户行为 | 发布后 |
| A/B 测试 | 衡量实际用户结果 | 重大变更验证 |
| 用户反馈 | 带有真实用户例子 | 持续 |
| 手动记录审查 | 建立对失败模式的直觉 | 持续 |
| 系统性人工评估 | 黄金标准质量判断 | 校准 LLM 评分器 |
最有效的团队结合这些方法——自动化评估用于快速迭代，生产监控用于真相，定期人工审查用于校准。就像瑞士奶酪模型，多层防护。
总结
没有评估的团队陷入被动循环——修一个失败，创造另一个，无法区分真正的回归和噪音。
早期投资评估的团队发现相反的情况：失败变成测试用例，测试用例防止回归，指标取代猜测。
核心原则：
- 尽早开始，不要等完美的套件
- 来源于真实失败
- 定义明确的成功标准
- 结合多种评分器类型
- 确保问题足够难
- 迭代提高信噪比
- 阅读记录
延伸阅读
- Claude Agent SDK 详解 - 用代码构建 AI Agent 的生产级工具
- 上下文工程实践指南 - 优化 AI 编程的核心策略