解密 AI Agent 的评测方法

# 揭秘 AI Agent 的评估方法 来源：https://www.anthropic.com/engineering/demystifying-evals-for-ai-agents ## 引言 良好的评估（eval）能帮助团队更自信地交付 AI Agent。没有评估，团队很容易陷入被动循环——只在生产环境发现问题，修复一个故障却引发其他问题。评估能在问题影响用户之前暴露问题和行为变化，并且其价值会随着 Agent 的生命周期不断累积。 正如我们在《构建高效 Agent》（https://www.anthropic.com/engineering/building-effective-agents）中所述，Agent 在多轮交互中运作：调用工具、修改状态、根据中间结果自适应调整。这些让 AI Agent 发挥作用的特性——自主性、智能性和灵活性——也使其更难评估。 通过内部工作以及与前沿 Agent 开发客户的合作，我们学会了如何为 Agent 设计更严谨、更实用的评估方法。以下是在真实部署中，经过多种 Agent 架构和应用场景验证的有效做法。 ## 评估的结构 **评估**（"eval"）是对 AI 系统的测试：给 AI 一个输入，然后对其输出应用评分逻辑来衡量成功。本文中，我们重点关注**自动化评估**，即可以在开发过程中无需真实用户参与即可运行的评估。 **单轮评估**很简单：一个提示、一个响应和评分逻辑。对于早期的大语言模型，单轮、非 Agent 式评估是主要的评估方式。随着 AI 能力的进步，**多轮评估**越来越普遍。 在简单评估中，Agent 处理提示，评分器检查输出是否符合预期。在更复杂的多轮评估中，编程 Agent 会接收工具、任务（本例中是构建 MCP 服务器）和环境，执行"Agent 循环"（工具调用和推理），并用实现更新环境。评分则通过单元测试来验证 MCP 服务器是否正常工作。 **Agent 评估**更为复杂。Agent 在多轮交互中使用工具，修改环境中的状态并实时适应——这意味着错误可能传播和累积。前沿模型还能找到超越静态评估限制的创造性解决方案。例如，Opus 4.5 在解决 τ2-bench（https://github.com/sierra-research/tau2-bench）的航班预订问题时，发现了一个政策漏洞（https://www.anthropic.com/news/claude-opus-4-5）。按评估原意它"失败"了，但实际上为用户提供了更优的解决方案。 构建 Agent 评估时，我们使用以下定义： - **任务**（又称**问题**或**测试用例**）是带有明确输入和成功标准的单一测试。 - 每次任务尝试称为**试验**（trial）。由于模型输出在不同运行间存在差异，我们运行多次试验以获得更稳定的结果。 - **评分器**（grader）是对 Agent 某方面表现进行评分的逻辑。一个任务可以有多个评分器，每个评分器包含多个断言（有时称为**检查**）。 - **转录记录**（又称**追踪**或**轨迹**）是试验的完整记录，包括输出、工具调用、推理过程、中间结果和其他交互。对于 Anthropic API，这是评估运行结束时的完整消息数组——包含评估期间所有 API 调用和返回的响应。 - **结果**（outcome）是试验结束时环境中的最终状态。航班预订 Agent 可能在转录记录末尾说"您的航班已预订"，但结果取决于环境的 SQL 数据库中是否存在预订记录。 - **评估框架**（evaluation harness）是端到端运行评估的基础设施。它提供指令和工具、并发运行任务、记录所有步骤、评分输出并汇总结果。 - **Agent 框架**（又称**脚手架**，scaffold）是使模型能够作为 Agent 运作的系统：处理输入、编排工具调用并返回结果。当我们评估"一个 Agent"时，我们评估的是框架**和**模型协同工作的效果。例如，Claude Code（https://claude.com/product/claude-code）是一个灵活的 Agent 框架，我们通过 Agent SDK（https://platform.claude.com/docs/en/agent-sdk/overview）使用其核心原语来构建我们的长时运行 Agent 框架（https://www.anthropic.com/engineering/effective-harnesses-for-long-running-agents）。 - **评估套件**（evaluation suite）是为衡量特定能力或行为而设计的任务集合。套件中的任务通常共享一个宏观目标。例如，客户支持评估套件可能测试退款、取消和升级场景。 Agent 评估的组成部分 ## 为什么要构建评估？ 团队刚开始构建 Agent 时，通过手动测试、内部试用（https://en.wikipedia.org/wiki/Eating_your_own_dog_food）和直觉往往能取得惊人进展。更严格的评估甚至可能被视为拖慢交付的开销。但在早期原型阶段之后，一旦 Agent 投入生产并开始扩展，没有评估的开发就会开始崩溃。 崩溃点通常出现在用户反馈 Agent 在变更后表现变差，而团队却"盲目飞行"，除了猜测和验证别无他法。缺乏评估时，调试是被动的：等待投诉、手动复现、修复 bug、希望没有其他地方退化。团队无法区分真正的退化与噪音，无法在上架前自动针对数百个场景测试变更，也无法衡量改进。 我们已多次目睹这一进程。例如，Claude Code 最初基于 Anthropic 员工和外部用户的反馈快速迭代。后来，我们增加了评估——先是针对简洁性和文件编辑等狭窄领域，然后是过度工程化等更复杂的行为。这些评估帮助识别问题、指导改进并聚焦研究与产品的协作。结合生产监控、A/B 测试、用户研究等，评估为 Claude Code 的规模化持续改进提供了信号。 在 Agent 生命周期的任何阶段编写评估都很有价值。早期，评估迫使产品团队明确 Agent 的成功标准；后期，它们帮助维持稳定的质量基线。 Descript（https://www.descript.com/）的 Agent 帮助用户编辑视频，因此他们围绕成功编辑工作流的三个维度构建评估：不要破坏东西、按我说的做、做得好。他们从手动评分发展到由产品团队定义标准并定期人工校准的 LLM 评分器，现在定期运行两个独立的套件用于质量基准测试和回归测试。Bolt（https://bolt.new/）AI 团队则是在 Agent 已广泛使用后才开始构建评估。在 3 个月内，他们构建了一个评估系统，运行其 Agent 并通过静态分析评分输出，使用浏览器 Agent 测试应用，并采用 LLM 评判器评估指令遵循等行为。 有些团队在开发初期就创建评估；有些则在规模化后、评估成为改进瓶颈时才添加。评估在 Agent 开发初期尤其有用，可以明确编码预期行为。两位工程师阅读同一份初始规范时，可能对 AI 如何处理边缘案例有不同理解。评估套件消除了这种模糊性。无论何时创建，评估都有助于加速开发。 评估还影响你采用新模型的速度。当更强大的模型发布时，没有评估的团队面临数周测试，而有评估的竞争对手可以快速确定模型优势、调整提示词，并在几天内完成升级。 一旦评估就位，你就能免费获得基线和回归测试：延迟、token 用量、每任务成本、错误率都可以在静态任务库上追踪。评估还能成为产品团队与研究团队之间最高带宽的沟通渠道，定义研究人员可以优化的指标。显然，评估的价值远不止追踪退化和改进。由于成本 upfront 可见而收益后期累积，其复合价值很容易被忽视。 ## 如何评估 AI Agent 我们目前看到几种常见的大规模部署 Agent，包括编程 Agent、研究 Agent、计算机使用 Agent 和对话 Agent。每种类型可能部署于各行各业，但可以使用类似的技术进行评估。你无需从零发明评估。以下章节介绍几种经过验证的 Agent 类型评估技术。将这些方法作为基础，然后扩展到你的领域。 ### Agent 的评分器类型 Agent 评估通常结合三种评分器：基于代码的、基于模型的和人工的。每个评分器评估转录记录或结果的某些部分。有效评估设计的关键组成部分是为工作选择合适的评分器。 基于代码的评分器 | 方法 | 优势 | 劣势 | |:---|:---|:---| | • 字符串匹配检查（精确、正则、模糊等）<br>• 二元测试（fail-to-pass、pass-to-pass）<br>• 静态分析（lint、类型、安全）<br>• 结果验证<br>• 工具调用验证（使用的工具、参数）<br>• 转录记录分析（轮数、token 用量） | • 快速<br>• 廉价<br>• 客观<br>• 可复现<br>• 易于调试<br>• 验证特定条件 | • 对不符合预期模式的合法变化脆弱<br>• 缺乏细微差别<br>• 对某些主观任务评估能力有限 | 基于模型的评分器 | 方法 | 优势 | 劣势 | |:---|:---|:---| | - 基于评分标准的评分<br>- 自然语言断言<br>- 成对比较<br>- 基于参考的评估<br>- 多评判共识 | - 灵活<br>- 可扩展<br>- 捕捉细微差别<br>- 处理开放式任务<br>- 处理自由格式输出 | - 非确定性<br>- 比代码更昂贵<br>- 需要与人工评分器校准以保证准确性 | 人工评分器 | 方法 | 优势 | 劣势 | |:---|:---|:---| | - 专家审核<br>- 众包判断<br>- 抽样检查<br>- A/B 测试<br>- 标注者间一致性 | - 黄金标准质量<br>- 匹配专家用户判断<br>- 用于校准基于模型的评分器 | - 昂贵<br>- 缓慢<br>- 通常需要大规模获取人类专家 | 对于每个任务，评分可以是加权的（组合评分器分数必须达到阈值）、二元的（所有评分器必须通过）或混合的。 ### 能力评估 vs. 回归评估 **能力或"质量"评估**问的是："这个 Agent 擅长做什么？" 它们应该以较低的通过率起步，针对 Agent 挣扎的任务，给团队一个攀登的目标。 **回归评估**问的是："Agent 仍然能处理它以前能处理的所有任务吗？" 应该有接近 100% 的通过率。它们防止倒退，因为分数下降意味着某些东西坏了需要修复。当团队在能力评估上攀登时，同时运行回归评估以确保变更不会在其他地方引发问题也很重要。 Agent 上线并优化后，高通过率的能力评估可以"毕业"成为持续运行以捕捉任何漂移的回归套件。曾经衡量"我们能不能做这个？"的任务，转而衡量"我们还能可靠地做这个吗？" ### 评估编程 Agent **编程 Agent**编写、测试和调试代码，浏览代码库并运行命令，就像人类开发者一样。现代编程 Agent 的有效评估通常依赖于定义明确的任务、稳定的测试环境和对生成代码的全面测试。 确定性评分器天然适合编程 Agent，因为软件通常易于评估：代码能运行吗？测试能通过吗？两个广泛使用的编程 Agent 基准 SWE-bench Verified（https://www.swebench.com/SWE-bench/）和 Terminal-Bench（https://www.tbench.ai/）遵循这一方法。SWE-bench Verified 给 Agent 来自流行 Python 仓库的 GitHub issue，并通过运行测试套件来评分解决方案；只有当解决方案修复了失败测试且没有破坏现有测试时才通过。LLM 在这一评估上的进展仅用一年就从 40% 提升到 >80%。Terminal-Bench 走了一条不同的路：它测试端到端的技术任务，例如从源码构建 Linux 内核或训练 ML 模型。 一旦有了验证编程任务关键**结果**的一组通过/失败测试，对**转录记录**进行评分也很有用。例如，基于启发式的代码质量规则可以基于通过测试之外的更多维度评估生成代码，带有清晰评分标准的基于模型的评分器可以评估 Agent 调用工具或与用户交互等行为。 **示例：编程 Agent 的理论评估** 考虑一个 Agent 必须修复身份验证绕过漏洞的编程任务。如下所示的示意性 YAML 文件展示了如何使用评分器和指标来评估该 Agent。 ```yaml task: id: "fix-auth-bypass_1" desc: "Fix authentication bypass when password field is empty and ..." graders: - type: deterministic_tests required: [test_empty_pw_rejected.py, test_null_pw_rejected.py] - type: llm_rubric rubric: prompts/code_quality.md - type: static_analysis commands: [ruff, mypy, bandit] - type: state_check expect: security_logs: {event_type: "auth_blocked"} - type: tool_calls required: - {tool: read_file, params: {path: "src/auth/*"}} - {tool: edit_file} - {tool: run_tests} tracked_metrics: - type: transcript metrics: - n_turns - n_toolcalls - n_total_tokens - type: latency metrics: - time_to_first_token - output_tokens_per_sec - time_to_last_token ``` 注意，此示例为说明目的展示了全部评分器范围。实践中，编程评估通常依赖单元测试进行正确性验证，LLM 评分标准评估整体代码质量，仅在需要时添加额外的评分器和指标。 ### 评估对话 Agent **对话 Agent**在支持、销售或辅导等领域与用户交互。与传统聊天机器人不同，它们维持状态、使用工具并在对话中采取行动。虽然编程和研究 Agent 也可能涉及与用户的多次交互，但对话 Agent 提出了独特的挑战：交互质量本身就是评估的一部分。对话 Agent 的有效评估通常依赖于可验证的终态结果和同时捕捉任务完成度与交互质量的评分标准。与其他大多数评估不同，它们通常需要第二个 LLM 来模拟用户。我们在对齐审计 Agent（https://alignment.anthropic.com/2025/automated-auditing/）中使用这种方法，通过长时间对抗性对话对模型进行压力测试。 对话 Agent 的成功可以是多维的：工单是否解决（状态检查）、是否在 10 轮内完成（转录记录约束）、语气是否恰当（LLM 评分标准）？两个体现多维性的基准是 τ-Bench（https://arxiv.org/abs/2406.12045）及其后继者 τ2-Bench（https://arxiv.org/abs/2506.07982）。它们模拟零售支持和航班预订等领域的多轮交互，一个模型扮演用户角色，Agent 在真实场景中导航。 **示例：对话 Agent 的理论评估** 考虑一个 Agent 必须为沮丧客户处理退款的支持任务。 ```yaml graders: - type: llm_rubric rubric: prompts/support_quality.md ```