Anthropic 万字长文：一篇 AI Agent 评估体系的详细解析！
转自 | Datawhale
Anthropic 发布了一篇 blog《揭秘 AI Agents 评估》，细节满满！
原文略微有点长，整理了一张脑图，要点精髓：
良好的评估（evaluations）能帮助团队更有信心地发布 AI 智能体。没有评估，很容易陷入被动循环——只在生产环境中发现问题，修复一个故障又会引发其他问题。评估能在问题影响用户之前让问题和行为变化变得可见，其价值在智能体的整个生命周期中不断累积。
通过 Anthropic 内部工作以及与处于智能体开发前沿的客户合作，已经学会了如何为智能体设计更严格和有用的评估：
一、评价的结构
评估（”eval”）是对 AI 系统的测试：给 AI 一个输入，然后对其输出应用评分逻辑来衡量成功。在本文中，我们专注于自动化评估，可以在开发过程中无需真实用户即可运行。
单轮评估很简单：一个提示、一个响应和评分逻辑。对于早期的 LLM，单轮、非智能体评估是主要的评估方法。随着 AI 能力的提升，多轮评估变得越来越常见。
在简单的评估中，智能体处理一个提示，评分器检查输出是否符合预期。对于更复杂的多轮评估，编码智能体接收工具、任务（在此案例中是构建 MCP 服务器）和环境，执行 “智能体循环”（工具调用和推理），并用实现更新环境。然后使用单元测试来验证工作的 MCP 服务器。
智能体评估更加复杂。智能体在多轮中使用工具，修改环境中的状态并进行适应——这意味着错误可能会传播和累积。前沿模型还能找到超越静态评估限制的创造性解决方案。例如，Opus 4.5 通过发现政策中的漏洞解决了一个τ2-bench 关于预订航班的问题。它 “未能” 通过所写的评估，但实际上为用户提出了更好的解决方案。
在构建智能体评估时，使用以下定义：
任务（也称为问题或测试用例）是具有定义输入和成功标准的单个测试。
每个任务的尝试是一个试验。由于模型输出在运行之间会有所不同，我们运行多个试验以产生更一致的结果。
评分器是对智能体某些方面表现进行评分的逻辑。一个任务可以有多个评分器，每个评分器包含多个断言（有时称为检查）。
记录（也称为跟踪或轨迹）是试验的完整记录，包括输出、工具调用、推理、中间结果和任何其他交互。对于 Anthropic API，这是评估运行结束时完整的 messages 数组——包含评估期间对 API 的所有调用和所有返回的响应。
结果是试验结束时环境的最终状态。预订航班的智能体可能在记录结束时说 “您的航班已预订”，但结果是在环境的 SQL 数据库中是否存在预订。
评估框架是端到端运行评估的基础设施。它提供指令和工具，并发运行任务，记录所有步骤，对输出进行评分，并汇总结果。
智能体框架（或脚手架）是使模型能够作为智能体运行的系统：它处理输入，编排工具调用，并返回结果。当我们评估 “一个智能体” 时，我们是在评估框架和模型一起工作。例如，Claude Code 是一个灵活的智能体框架，我们通过 Agent SDK 使用其核心原语来构建我们的长运行智能体框架。
评估套件是为测量特定能力或行为而设计的任务集合。套件中的任务通常共享广泛的目标。例如，客户支持评估套件可能测试退款、取消和升级。
二、为什么要构建评估？
初期靠手动测试和直觉可快速推进智能体，但上线后若无评估，团队只能被动等投诉，难辨回归与噪声。早期或规模化阶段引入评估，都能明确成功定义、自动覆盖百种场景、加速迭代。Claude Code、Descript、Bolt AI 的实践显示：评估指导研究 - 产品协作、支持 A/B 测试与成本基线，并助团队在新模型发布数天而非数周内完成升级，长期收益远超前期投入。
三、如何评估 AI 智能体
展示几种智能体类型的成熟技术
智能体评分器类型
智能体评估通常结合三种类型的评分器：基于代码的、基于模型的和人类。每个评分器评估记录或结果的某些部分。有效评估设计的重要组成部分是为工作选择合适的评分器。
基于代码的评分器
| 方法 | 优势 | 劣势 |
|---|---|---|
| - 字符串匹配检查（精确、正则、模糊等） - 二进制测试（失败到通过、通过到通过） - 静态分析（lint、类型、安全） - 结果验证 - 工具调用验证（使用的工具、参数） - 记录分析（采取的轮次、令牌使用） |
- 快速 - 便宜 - 客观 - 可重现 - 易于调试 - 验证特定条件 |
- 对于不完全匹配预期模式的有效变化脆弱 - 缺乏细微差别 - 对于评估某些更主观的任务有限 |
基于模型的评分器
| 方法 | 优势 | 劣势 |
|---|---|---|
| - 基于评分标准的评分 - 自然语言断言 - 成对比较 - 基于参考的评估 - 多评判员共识 |
- 灵活 - 可扩展 - 捕捉细微差别 - 处理开放式任务 - 处理自由形式输出 |
- 非确定性 - 比代码更昂贵 - 需要与人类评分器校准以确保准确性 |
人类评分器
| 方法 | 优势 | 劣势 |
|---|---|---|
| - SME审查 - 众包判断 - 抽查采样 - A/B测试 - 注释者间一致性 |
- 黄金标准质量 - 匹配专家用户判断 - 用于校准基于模型的评分器 |
- 昂贵 - 慢 - 通常需要大规模访问人类专家 |
对于每个任务，评分可以是加权的（组合评分器分数必须达到阈值）、二进制的（所有评分器必须通过）或混合的。
能力与回归评估
能力评估聚焦 “能做什么”，从低通过率起步，推动团队挑战难题。回归评估确保“仍能做旧任务”，通过率应近 100%，防止倒退。能力评估达标后可转为回归套件，持续监控漂移，从“能否做到” 转为“是否仍可靠”。
评估编码智能体
编码智能体写、测、调代码，评估依赖明确任务与稳定测试。SWE-bench Verified 用 GitHub 问题 + 测试评分，通过率一年从 40% 升至 80%。Terminal-Bench 测构建内核等任务。除结果测试，还可评代码质量与行为记录，确保工具调用与交互规范。
评估对话智能体
对话智能体在支持、销售等场景交互，需评状态维护、工具使用与语气。成功维度含状态达成、轮次控制与语气合规。τ-Bench 与τ2-Bench 模拟多轮交互，一模型扮用户，一模型扮智能体，评任务完成与交互质量，覆盖零售、航空等场景。
评估研究智能体
研究智能体收集、综合、输出信息，质量依赖上下文：市场扫描、尽调、科研标准各异。评估需结合基础检查、覆盖验证、来源质量与连贯性评分。BrowseComp 测 “大海捞针” 式搜索。LLM 评分需与专家校准，确保综合全面、来源权威、结论可信。
计算机使用智能体
计算机使用智能体通过 GUI 操作软件，评估需在真实或沙盒环境中验证结果。WebArena 测浏览器任务，查 URL 与后端状态；OSWorld 扩展至操作系统级，评文件、配置、数据库与 UI 变化。需平衡令牌效率与延迟，选 DOM 或截图交互，确保任务准确完成。
如何思考智能体评估中的非确定性
无论智能体类型如何，智能体行为在运行之间都会有所不同，这使得评估结果比最初看起来更难解释。每个任务都有自己的成功率——一个任务可能是 90%，另一个任务可能是 50%——而在一次评估运行中通过的任务可能在下次失败。有时，我们想要测量的是智能体多频繁（试验成功的比例）成功完成一个任务。
两个指标有助于捕捉这种细微差别：
pass@k 衡量智能体在 k 次尝试中至少获得一个正确解决方案的可能性。随着 k 的增加，pass@k 分数上升——更多的 “射门次数” 意味着至少一次成功的几率更高。50% 的 pass@1 分数意味着模型在第一次尝试时成功完成了一半的评估任务。在编码中，我们通常最关心智能体在第一次尝试时找到解决方案——pass@1。在其他情况下，提出许多解决方案是有效的，只要有一个有效。
pass^k 衡量所有 k 次试验成功的概率。随着 k 的增加，pass^k 下降，因为要求在更多试验中保持一致是更难达到的标准。如果您的智能体每次试验成功率为 75%，并且您运行 3 次试验，通过所有三次的概率是 (0.75)³ ≈ 42%。这个指标对于用户期望可靠行为的面向客户智能体尤其重要。
随着试验次数的增加，pass@k 和 pass^k 出现分歧。在 k=1 时，它们是相同的（都等于每次试验的成功率）。到 k=10 时，它们讲述了相反的故事：pass@k 接近 100%，而 pass^k 下降到 0%。
两个指标都很有用，使用哪个取决于产品要求：对于工具一次成功重要的用 pass@k，对于一致性至关重要的智能体用 pass^k。
四、从零到一：通往优秀智能体评估的路线图
收集初始评估数据集的任务
第 0 步：尽早开始
- 20–50 个真实失败案例即可起步；拖得越久越难补。
第 1 步：从现成手动测试与工单里挖用例
- 按用户影响排序，直接转成任务。
第 2 步：写 “双专家可复判” 的明确任务
- 模糊规范 = 噪声；0% 通过率先查任务 / 评分器，而非模型。
第 3 步：正负样本平衡
- 只测 “该做” 会过度优化；同步覆盖 “不该做” 场景。
设计评估框架和评分器
第 4 步：隔离干净环境
- 禁残留文件 / 缓存 / 资源泄漏，防止 “git 偷看” 类假阳性。
第 5 步：评结果不评路径
- 多给部分分；LLM-as-judge 须与人拉齐，留 “未知” 出口；防阈值 / 格式等评分 Bug。
长期维护和使用评估
第 6 步：定期读日志
- 确认失败公平，排除评分器甩锅。
第 7 步：监控饱和
- 分数 > 80% 时换更难任务，避免 “小步美化” 掩盖真实提升。
第 8 步：持续贡献与所有权
- 核心 infra 归评估团队，业务方像写单元测试一样提任务；PR 式开放提交，评估先行再开发。
评估如何与其他方法配合，全面了解智能体
自动化评估可以在不影响生产环境或影响真实用户的情况下，针对智能体运行数千个任务。但这只是了解智能体性能的众多方法之一。完整的图景包括生产监控、用户反馈、A/B 测试、手动记录审查和系统的人工评估。
了解 AI 智能体性能的方法概述
| 方法 | 优点 |
|---|---|
| 自动化评估 无需真实用户即可编程方式运行测试 | - 更快的迭代 - 完全可重现 - 不影响用户 - 可以在每次提交时运行 - 在不要求生产部署的情况下大规模测试场景 |
| 生产监控 跟踪实时系统中的指标和错误 | - 揭示大规模真实用户行为 - 捕捉合成评估遗漏的问题 - 提供智能体实际表现的真相 |
| A/B测试 用真实用户流量比较变体 | - 测量实际用户结果（留存、任务完成） - 控制混杂因素 - 可扩展和系统化 |
| 用户反馈 明确的信号，如反对或错误报告 | - 表面您未曾预料到的问题 - 带有来自真实人类用户的真实示例 - 反馈通常与产品目标相关 |
| 手动记录审查 人类阅读智能体对话 | - 建立对失败模式的直觉 - 捕捉自动化检查遗漏的细微质量问题 - 有助于校准”好”的样子并掌握细节 |
| 系统人工研究 训练有素的评分者对智能体输出进行结构化评分 | - 来自多个人类评分者的黄金标准质量判断 - 处理主观或模糊的任务 - 为改进基于模型的评分器提供信号 |
这些方法映射到智能体开发的不同阶段。自动化评估在发布前和 CI/CD 中特别有用，在每次智能体更改和模型升级时作为抵御质量问题的第一道防线运行。生产监控在发布后启动，以检测分布漂移和未预料到的现实世界故障。A/B 测试在您有足够流量时验证重大更改。用户反馈和记录审查是填补空白的持续实践——不断分类反馈，每周抽样阅读记录，并根据需要深入挖掘。保留系统的人工研究，用于校准 LLM 评分器或评估主观输出，其中人类共识作为参考标准。
与安全工程中的 瑞士奶酪模型 一样，没有单一的评估层能捕捉到每个问题。结合多种方法，一个层漏掉的故障会被另一个层捕捉到。
最有效的团队结合这些方法——用于快速迭代的自动化评估、用于真相的生产监控，以及用于校准的定期人工审查。
