原文：12-demystifying-evals-for-ai-agents.md 来源：https://www.anthropic.com/engineering/demystifying-evals-for-ai-agents
揭秘 AI Agent 评估
发布于 2026 年 1 月 9 日
让 Agent 有用的能力，也让它们难以评估。跨部署起作用的策略结合多种技术以匹配它们衡量的系统的复杂性。
引言
好的评估帮团队更自信地交付 AI Agent。没有评估，很容易陷入响应式循环——只在生产中捕捉问题，修一个失败创造另一个。评估让问题和行为变化在影响用户之前可见，价值在 Agent 生命周期中复合。
构建有效 Agent 一文中描述：Agent 跨多轮运作——调用工具、修改状态、基于中间结果适应。这些让 AI Agent 有用的能力——自治、智能、灵活——也让它们更难评估。
评估的结构
评估（eval）是 AI 系统的测试：给 AI 一个输入，对输出应用评分逻辑衡量成功。本文聚焦自动化评估——可以在开发期间运行而无需真实用户。
单轮评估直接：提示、响应、评分逻辑。早期 LLM 中，单轮、非 Agent 评估是主要评估方法。多轮评估随能力进步变得越来越常见。
Agent 评估更复杂。Agent 跨多轮使用工具、修改环境状态、边走边适应——错误可以传播和复合。前沿模型也能找到超越静态评估限制的创意方案。例如 Opus 4.5 通过发现政策漏洞解决了 𝜏2-bench 的订机票问题。它"按所写"失败评估，但实际为用户提出了更好方案。
关键定义
| 术语 | 定义 |
|---|---|
| 任务（task / problem / test case） | 带定义输入和成功标准的单个测试 |
| 试运行（trial） | 任务的一次尝试。模型输出运行间变化，多次试运行产生更一致结果 |
| 评分员（grader） | 评分 Agent 表现某方面的逻辑。一个任务可有多个评分员，每个含多个断言（checks） |
| 转录（transcript / trace / trajectory） | 试运行的完整记录——输出、工具调用、推理、中间结果、其他交互 |
| 结果（outcome） | 试运行结束时环境的最终状态 |
| 评估 harness | 端到端运行评估的基础设施 |
| Agent harness（scaffold） | 让模型作为 Agent 行动的系统 |
| 评估套件（eval suite） | 设计衡量特定能力或行为的任务集合 |
为什么构建评估？
团队开始构建 Agent 时，结合手工测试、内部用、直觉能走得令人惊讶地远。更严格的评估甚至看似拖慢交付的开销。但早期原型阶段后，一旦 Agent 进入生产并开始扩展，无评估构建就开始崩溃。
崩溃点常在：用户报告 Agent 改动后感觉变差，团队"盲飞"——除了猜和检查没有验证方式。没有评估调试是响应式的：等抱怨、手工复现、修 bug、希望没回归。团队无法区分真正回归 vs. 噪声、自动测试改动、衡量改进。
写评估在 Agent 生命周期任何阶段都有用。早期评估迫使产品团队明确成功对 Agent 意味着什么，后期帮助维持一致质量门槛。
评估也塑造你能多快采用新模型。强大模型出现时，没评估的团队面临数周测试，有评估的竞争对手能快速确定模型强项、调整提示、几天内升级。
如何评估 AI Agent
Agent 评估员的类型
Agent 评估通常结合三种评估员：基于代码、基于模型、人类。
基于代码的评估员
方法：字符串匹配检查（精确、regex、模糊）、二进制测试、静态分析（lint、type、security）、结果验证、工具调用验证、转录分析
优点：快速、便宜、客观、可复现、易调试、验证特定条件
缺点：对不精确匹配预期模式的有效变体脆弱、缺乏细微、对某些更主观任务有限
基于模型的评估员
方法：基于规则评分、自然语言断言、成对对比、基于参考的评估、多评判员共识
优点：灵活、可扩展、捕捉细微、处理开放任务、处理自由形式输出
缺点：非确定、比代码贵、需与人类评分员校准
人类评估员
方法：主题专家审查、众包判断、抽查采样、A/B 测试、评注者间一致性
优点：黄金标准质量、匹配专家用户判断、用于校准基于模型的评估员
缺点：贵、慢、常需大规模人类专家访问
能力评估 vs. 回归评估
能力（"质量"）评估问"这个 Agent 能做好什么？" 应该从低通过率开始，瞄准 Agent 挣扎的任务，给团队一座要爬的山。
回归评估问"Agent 还处理它过去能处理的所有任务吗？" 应有近 100% 通过率。它们防止退化——分数下降信号有什么坏了。
Agent 启动并优化后，高通过率的能力评估可"毕业"成为持续运行的回归套件——曾衡量"我们能做这个吗？"的任务现在衡量"我们还能可靠做这个吗？"
评估编码 Agent
编码 Agent 写、测试、调试代码——像人类开发者那样导航代码库和运行命令。有效评估通常依赖良好规格的任务、稳定测试环境、对生成代码的彻底测试 。
确定性评估员对编码 Agent 是天然的——软件评估通常直接：代码运行吗？测试通过吗？两个广泛使用的编码 Agent 基准 SWE-bench Verified 和 Terminal-Bench 遵循这种方法。LLM 在 SWE-bench Verified 上仅一年内从 40% 进步到 >80%。
评估对话 Agent
对话 Agent 在客户支持、销售、教练等领域与用户交互。不像传统聊天机器人，它们维持状态、用工具、对话中段采取行动。有效评估通常依赖可验证的最终状态结果和捕捉任务完成与交互质量的规则。
不像大多数其他评估，它们常需要第二个 LLM 模拟用户。我们在对齐审计 Agent 中用此方法通过扩展、对抗对话压测模型。
对话 Agent 成功可以是多维的：工单解决了吗（状态检查）？10 轮内完成吗（转录约束）？语调适当吗（LLM 规则）？
评估研究 Agent
研究 Agent 收集、综合、分析信息，然后产出回答或报告。研究质量只能相对任务判断。"全面"、"来源良好"、甚至"正确"的标准取决于上下文。
研究评估面临独特挑战：专家可能对综合是否全面意见不一致、参考内容不断变化让真值漂移、更长更开放的输出为错误创造更多 空间。
结合评估员类型：根据性检查验证声明被检索源支持、覆盖检查定义好回答必须包含的关键事实、源质量检查确认咨询源是权威的而非简单地是首次检索的。
计算机使用 Agent
计算机使用 Agent 通过与人类相同的接口与软件交互——截图、鼠标点击、键盘输入、滚动——而非通过 API 或代码执行。它们可以使用任何带 GUI 的应用。
评估需要在真实或沙箱环境运行 Agent——它能使用软件应用并检查是否达到预期结果。
浏览器使用 Agent 需要token 效率与延迟之间的平衡。基于 DOM 的交互执行快但消耗多 token，基于截图的交互慢但 token 更高效。例如要 Claude 总结 Wikipedia 时，从 DOM 提取文本更高效；在 Amazon 找新笔记本电脑包时，截图更高效（提取整个 DOM token 密集）。
如何看待 Agent 评估中的非确定性
无论 Agent 类型，Agent 行为运行间变化——让评估结果比表面更难解读。每个任务有自己的成功率——一个任务 90%，另一个 50%——一个评估运行通过的任务下个可能失败。有时我们想衡量 Agent 多频繁（试运行的多大比例）成功一 个任务。
两个指标
pass@k：Agent 在 k 次尝试中至少得到一个正确解的可能性。k 增加 pass@k 上升：更多"射门"意味着至少 1 次成功的更高几率。编码中我们常最关心 Agent 第一次找到解——pass@1。
pass^k：所有 k 次试运行都成功的概率。k 增加 pass^k 下降：要求更多试运行的一致性是更难的标准。如果你的 Agent 有 75% 单试运行成功率运行 3 次，所有三次通过的概率是 (0.75)³ ≈ 42%。这个指标对面向客户的 Agent 特别重要——用户期望每次可靠行为。
从零到一：Agent 优秀评估路线图
收集初始评估数据集的任务
第 0 步：早开始：团队推迟构建评估因为他们认为需要数百任务。实际上 20-50 个简单任务（来自真实失败）是好开始。早期 Agent 开发中，每个改动常有清晰、明显影响——这种大效应大小让小样本量足够。评估等得越久越难构建。
第 1 步：从你已经手工测试的开始：从开发期间运行的手工检查、每次发布前验证的行为、终端用户尝试的常见任务开始。如果已在生产中，看 bug 跟踪器和支持队列。把用户报告的失败转化为测试用例确保你的套件反映实际使用。
第 2 步：写带参考方案的明确任务：好任务是两个领域专家会独立达到相同 pass/fail 判决的任务。他们能自己通过任务吗？如果不能，任务需要改进。任务规格中的歧义在指标中变成噪声。
每个任务应该可被遵循指令的 Agent 通过。前沿模型上，许多试运行 0% 通过率（即 0% pass@100）最常是任务损坏的信号，不是 Agent 无能——是双重检查任务规格和评估员的信号。每个任务，创建参考方案有用：通过所有评估员的已知工作输出。
第 3 步：构建平衡问题集：测试行为应该发生和不应发生的情况。单边评估造成单边优化。
设计评估 harness 和评估员
第 4 步：用稳定环境构建健壮评估 harness：评估中的 Agent 应与生产中使用的 Agent 大致相同地运作。每次试运行从干净环境开始隔离。运行间不必要的共享状态（残留文件、缓存数据、资源耗尽）可能导致基础设施抖动而非 Agent 性能引起的相关失败。
第 5 步：审慎设计评估员：尽可能选择确定性评估员，必要或为额外灵活性时选 LLM 评估员，明智用人类评估员做额外验证。
有种检查 Agent 遵循非常具体步骤（如以正确顺序工具调用序列）的常见本能——我们发现这种方法太僵化导致过于脆弱的测试。评估 Agent 产出的，而非它走的路径。
多组件任务构建部分学分。正确识别问题并验证客户但未处理退款的支持 Agent，比立即失败的有意义地更好。
模型评分常需要仔细迭代验证准确性。LLM-as-judge 评估员应与人类专家紧密校准。避免幻觉给 LLM 出路——如指令在没足够信息时返回"未知"。
让评估员抗绕过或破解。Agent 不应能容易"作弊"评估。
长期维护和使用评估
第 6 步：检查转录：你不会知道评估员是否工作良好除非读多个试运行的转录和分数。任务失败时，转录告诉你 Agent 是否犯了真错误，或评估员拒绝了有效方案。
第 7 步：监控能力评估饱和：100% 评估跟踪回归但不为改进提供信号。评估饱和发生在 Agent 通过所有可解任务时。SWE-Bench Verified 分数今年从 30% 开始，前沿模型现在接近饱和 >80%。作为规则，我们不在有人深入评估细节并读一些转录前按面值看评估分数。
第 8 步：通过 开放贡献和维护保持评估套件长期健康：评估套件是需要持续关注和清晰所有权才能保持有用的活产物。对 AI 产品团队，拥有和迭代评估应像维护单元测试一样常规。
我们推荐实践评估驱动开发：在 Agent 能完成前构建评估定义计划能力，然后迭代直到 Agent 表现良好。新模型发布时运行套件快速揭示哪些押注成功。
评估如何与其他方法适配以全面理解 Agent
| 方法 | 优点 | 缺点 |
|---|---|---|
| 自动化评估 | 更快迭代、完全可复现、无用户影响、每次提交可运行、规模测试场景 | 前期投资大、需要持续维护避免漂移、若不匹配真实使用模式可能造成虚假信心 |
| 生产监控 | 揭示规模上的真实用户行为、捕捉合成评估错过的问题、提供 Agent 实际表现的真值 | 响应式（问题在你知道前到达用户）、信号噪声、需仪表化投入、缺乏评分真值 |
| A/B 测试 | 衡量实际用户结果、控制混淆、可扩展系统化 | 慢、只测试你部署的改动、缺少指标变化的"为什么"信号 |
| 用户反馈 | 浮现你没预期的问题、来自实际人类用户的真实示例 | 稀疏自选、偏向严重问题、用户很少解释为什么失败 |
| 手工转录 审查 | 建立失败模式直觉、捕捉自动化检查错过的微妙质量问题 | 时间密集、不可扩展、覆盖不一致 |
| 系统人类研究 | 多个人类评分员的黄金标准质量判断、处理主观或模糊任务 | 相对昂贵慢、难频繁运行、评分员不一致需调和 |
像安全工程的瑞士奶酪模型——没有单一评估层捕捉每个问题。多种方法结合，一层漏掉的失败被另一层捕捉。
结论
无评估的团队陷入响应式循环——修一个失败造另一个，无法区分真回归 vs. 噪声。早投资的团队发现相反：开发加速，因为失败变成测试用例、测试用例防止回归、指标取代猜测。
模式因 Agent 类型而异，但这里描述的基础是恒定的：早开始不要等完美套件、从你看到的失败采购真实任务、定义无歧义健壮的成功标准、审慎设计评估员并结合多种类型、确保问题对模型足够难、迭代评估改善信噪比、读转录！
AI Agent 评估仍是新生、快速演化的领域。Agent 承担更长任务、协作多 Agent 系统、处理日益主观的工作时，我们需要适应技术。