揭开 AI Agent 评估的面纱

Note

让 Agent 有用的能力也让它们难以评估。在各类部署中行之有效的策略，是将多种技术组合以匹配其所衡量系统的复杂度。

引言 Link to heading

好的评估能帮助团队更自信地发布 AI Agent。没有评估，很容易陷入被动循环——只在生产环境中发现问题，而修复一个故障又会引发其他故障。评估让问题和行为变化在影响用户之前变得可见，其价值在 Agent 的整个生命周期中不断累积。

正如我们在构建有效的 Agent中所描述的，Agent 在多个轮次中运作：调用工具、修改状态，并根据中间结果进行调整。这些让 AI Agent 变得有用的能力——自主性、智能性和灵活性——同时也让它们更难评估。

通过我们的内部工作以及与处于 Agent 开发前沿的客户合作，我们学会了如何为 Agent 设计更严谨、更实用的评估。以下是我们在各种 Agent 架构和实际部署用例中验证有效的经验。

评估的结构 Link to heading

评估（eval）是对 AI 系统的测试：给 AI 一个输入，然后对其输出应用评分逻辑来衡量成功与否。在本文中，我们聚焦于可以在开发期间无需真实用户即可运行的自动化评估。

单轮评估很简单：一个提示、一个回复和评分逻辑。对于早期的 LLM，单轮、非 Agent 的评估是主要的评估方法。随着 AI 能力的进步，多轮评估变得越来越普遍。

在简单的评估中，智能体处理一条提示词，评分器检查输出是否符合预期。对于更复杂的多轮评估，编码智能体会获得工具、任务（此处为构建一个MCP服务器）和环境，执行“智能体循环”（工具调用与推理），并用实现结果更新环境。随后，评分环节通过单元测试来验证MCP服务器是否正常工作。

Agent 评估更加复杂。Agent 在多个轮次中使用工具，在环境中修改状态并不断适应——这意味着错误可能传播和累积。前沿模型还可能找到超越静态评估限制的创造性解决方案。例如，Opus 4.5 通过发现策略中的漏洞，解决了一个关于预订航班的 𝜏2-bench 问题。它按照评估的设定"失败"了，但实际上为用户想出了一个更好的解决方案。

在构建 Agent 评估时，我们使用以下定义：

任务（也称问题或测试用例）是一个具有明确输入和成功标准的单一测试。
对任务的每次尝试称为一次试验。由于模型输出在不同运行之间会有变化，我们运行多次试验以产生更一致的结果。
评分器是对 Agent 性能的某个方面进行评分的逻辑。一个任务可以有多个评分器，每个评分器包含多个断言（有时称为检查）。
记录（也称轨迹或轨迹线）是试验的完整记录，包括输出、工具调用、推理、中间结果以及所有其他交互。对于 Anthropic API，这是评估运行结束时的完整消息数组——包含评估期间对 API 的所有调用和所有返回的响应。
结果是试验结束时环境中的最终状态。一个航班预订 Agent 可能在记录末尾说"您的航班已预订"，但结果是环境的 SQL 数据库中是否存在预订记录。
评估 Harness 是端到端运行评估的基础设施。它提供指令和工具、并发运行任务、记录所有步骤、评分输出并汇总结果。
Agent Harness（或脚手架）是使模型能够作为 Agent 行动的系统：它处理输入、编排工具调用并返回结果。当我们评估"一个 Agent"时，我们评估的是 Harness 与模型协同工作的整体。例如，Claude Code 是一个灵活的 Agent Harness，我们通过 Agent SDK 使用其核心原语来构建我们的长时间运行 Agent Harness。
评估套件是为衡量特定能力或行为而设计的任务集合。套件中的任务通常共享一个广泛的目标。例如，客户支持评估套件可能测试退款、取消和升级。

Agent 评估的组成部分。

为什么要构建评估？ Link to heading

当团队刚开始构建 Agent 时，通过手动测试、吃自己的狗粮和直觉的组合，可以走得相当远。更严谨的评估甚至可能看起来是拖慢发布速度的开销。但在早期原型阶段之后，一旦 Agent 进入生产环境并开始扩展，没有评估的开发就会开始出问题。

转折点通常出现在用户报告 Agent 在变更后感觉变差了，而团队却"盲飞"——除了猜测和验证之外没有其他方法来确认。没有评估，调试是被动的：等待投诉、手动复现、修复 bug，然后祈祷没有其他回归。团队无法区分真正的回归和噪声，无法在发布前自动测试数百个场景的变更，也无法衡量改进。

我们多次看到这种进展过程。例如，Claude Code 最初基于 Anthropic 员工和外部用户的反馈进行快速迭代。后来，我们添加了评估——先是针对简洁性和文件编辑等狭窄领域，然后是过度工程等更复杂的行为。这些评估帮助识别问题、指导改进，并聚焦研究-产品协作。结合生产监控、A/B 测试、用户研究等，评估为 Claude Code 在扩展过程中持续改进提供了信号。

编写评估在 Agent 生命周期的任何阶段都是有用的。早期，评估迫使产品团队明确 Agent 的成功标准；后期，它们帮助维持一致的质量标准。

Descript的 Agent 帮助用户编辑视频，因此他们围绕成功编辑工作流的三个维度构建了评估：不破坏东西、做我要求的事、做得好。他们从手动评分演进到由产品团队定义标准的 LLM 评分器并定期进行人工校准，现在定期运行两套独立的评估套件用于质量基准测试和回归测试。Bolt AI 团队在已经有广泛使用的 Agent 之后才开始构建评估。在 3 个月内，他们构建了一个评估系统，运行 Agent 并用静态分析评分输出，使用浏览器 Agent 测试应用，并使用 LLM 评判器评估指令遵循等行为。

有些团队在开发之初就创建评估；另一些则在规模扩大、评估成为改进 Agent 的瓶颈时才添加。评估在 Agent 开发初期尤其有用，可以明确编码预期行为。两个工程师阅读同一份初始规范，可能对 AI 应如何处理边缘情况有不同的理解。评估套件可以消除这种歧义。无论何时创建，评估都有助于加速开发。

评估还影响你采用新模型的速度。当更强大的模型发布时，没有评估的团队面临数周的测试，而有评估的团队可以快速确定模型的优势、调整提示，并在几天内完成升级。

一旦评估存在，你就免费获得了基线和回归测试：延迟、Token 使用量、每任务成本和错误率可以在固定的任务库上追踪。评估还可以成为产品团队和研究团队之间最高带宽的沟通渠道，定义研究人员可以优化的指标。显然，评估的好处远不止追踪回归和改进。其累积价值很容易被忽视，因为成本是前期可见的，而收益是后期累积的。

如何评估 AI Agent Link to heading

我们看到当今大规模部署了几种常见类型的 Agent，包括编码 Agent、研究 Agent、计算机使用 Agent 和对话 Agent。每种类型可能部署在各种行业中，但可以使用类似的技术进行评估。你不需要从零开始发明评估方法。以下各节描述了针对多种 Agent 类型的经过验证的技术。将这些方法作为基础，然后扩展到你的领域。

Agent 的评分器类型 Link to heading

Agent 评估通常组合三种类型的评分器：基于代码的、基于模型的和人工的。每个评分器评估记录或结果的某个部分。有效评估设计的关键组成部分是为任务选择合适的评分器。

基于代码的评分器 Link to heading

方法	优势	劣势
• 字符串匹配检查（精确、正则、模糊等） • 二值测试（失败到通过、通过到通过） • 静态分析（lint、类型、安全） • 结果验证 • 工具调用验证（使用的工具、参数） • 记录分析（轮次数、Token 使用量）	• 快速 • 便宜 • 客观 • 可复现 • 易于调试 • 验证特定条件	• 对不完全匹配预期模式的有效变体过于脆弱 • 缺乏细微度 • 对评估某些更主观的任务能力有限

基于模型的评分器 Link to heading

方法	优势	劣势
• 基于评分标准的打分 • 自然语言断言 • 成对比较 • 基于参考的评估 • 多评判器共识	• 灵活 • 可扩展 • 捕捉细微差别 • 处理开放式任务 • 处理自由格式输出	• 非确定性 • 比基于代码的评分器更贵 • 需要与人工评分器校准以确保准确性

人工评分器 Link to heading

方法	优势	劣势
• 领域专家评审 • 众包判断 • 抽样检查 • A/B 测试 • 标注者间一致性	• 金标准质量 • 匹配专家用户判断 • 用于校准基于模型的评分器	• 昂贵 • 缓慢 • 通常需要大规模获取人类专家

对于每个任务，评分可以是加权的（组合评分器分数必须达到阈值）、二值的（所有评分器必须通过）或混合的。

能力评估 vs 回归评估 Link to heading

能力评估或"质量"评估问的是：“这个 Agent 擅长做什么？“它们应该从低通过率开始，针对 Agent 难以完成的任务，给团队一个攀登的山头。

回归评估问的是：“Agent 是否仍然能处理以前能做的所有任务？“其通过率应该接近 100%。它们防止倒退，因为分数下降意味着有什么东西坏了需要改进。当团队在能力评估上攀登时，同时运行回归评估以确保变更不会在其他方面没有引发问题，这很重要。

在 Agent 发布并优化之后，高通过率的能力评估可以"毕业"成为持续运行的回归套件，以捕捉任何漂移。曾经衡量"我们能不能做到"的任务，现在衡量"我们还能不能可靠地做到”。

评估编码 Agent Link to heading

编码 Agent 编写、测试和调试代码，像人类开发者一样在代码库中导航并运行命令。现代编码 Agent 的有效评估通常依赖于明确规范的任务、稳定的测试环境以及对生成代码的全面测试。

确定性评分器天然适合编码 Agent，因为软件通常很容易评估：代码能运行吗？测试能通过吗？两个广泛使用的编码 Agent 基准，SWE-bench Verified和 Terminal-Bench，都遵循这种方法。SWE-bench Verified 给 Agent 来自流行 Python 仓库的 GitHub issue，通过运行测试套件来评分解决方案；只有当解决方案修复了失败的测试而没有破坏现有测试时才算通过。LLM 在这个评估上的表现仅一年就从 40% 进步到 >80%。Terminal-Bench 采取了不同的路线：它测试端到端的技术任务，例如从源代码构建 Linux 内核或训练 ML 模型。

一旦你有了一组用于验证编码任务关键结果的通过/失败测试，通常也值得对记录进行评分。例如，基于启发式的代码质量规则可以基于超越通过测试的标准来评估生成的代码，而具有明确评分标准的基于模型的评分器可以评估 Agent 如何调用工具或与用户交互等行为。

示例：编码 Agent 的理论评估

考虑一个编码任务，Agent 必须修复一个身份验证绕过漏洞。如下面的示例 YAML 文件所示，可以使用评分器和指标来评估这个 Agent。

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 Link to heading

对话 Agent 在支持、销售或辅导等领域与用户交互。与传统的聊天机器人不同，它们维护状态、使用工具，并在对话中采取行动。虽然编码和研究 Agent 也可能涉及与用户的多轮交互，但对话 Agent 呈现了一个独特的挑战：交互本身的质量就是你要评估的一部分。对话 Agent 的有效评估通常依赖于可验证的终态结果和同时捕捉任务完成度与交互质量的评分标准。与大多数其他评估不同，它们通常需要第二个 LLM 来模拟用户。我们在对齐审计 Agent中使用这种方法，通过扩展的对抗性对话来压力测试模型。

对话 Agent 的成功可以是多维的：工单是否已解决（状态检查）、是否在 <10 轮内完成（记录约束）、语气是否恰当（LLM 评分标准）？两个纳入多维度的基准是 𝜏-Bench 及其后续版本 τ2-Bench。它们模拟零售支持和航空预订等领域的多轮交互，其中一个模型扮演用户角色，而 Agent 在真实场景中导航。

示例：对话 Agent 的理论评估

考虑一个支持任务，Agent 必须为一位沮丧的客户处理退款。

graders:
  - type: llm_rubric
    rubric: prompts/support_quality.md
    assertions:
      - "Agent showed empathy for customer's frustration"
      - "Resolution was clearly explained"
      - "Agent's response grounded in fetch_policy tool results"
  - type: state_check
    expect:
      tickets: {status: resolved}
      refunds: {status: processed}
  - type: tool_calls
    required:
      - {tool: verify_identity}
      - {tool: process_refund, params: {amount: "<=100"}}
      - {tool: send_confirmation}
  - type: transcript
    max_turns: 10
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

与编码 Agent 示例一样，此任务展示了多种评分器类型以供说明。在实践中，对话 Agent 评估通常使用基于模型的评分器来同时评估沟通质量和目标完成度，因为许多任务——如回答问题——可能有多个"正确"解决方案。

评估研究 Agent Link to heading

研究 Agent 收集、综合和分析信息，然后产生答案或报告等输出。与编码 Agent 可以通过单元测试提供二元的通过/失败信号不同，研究质量只能相对于任务来判断。什么算作"全面”、“来源充分"甚至"正确"取决于上下文：市场扫描、收购的尽职调查和科学报告各自需要不同的标准。

研究评估面临独特的挑战：专家可能对综合是否全面存在分歧，随着参考内容不断变化，真实基准也在变化，而更长、更开放的输出为错误创造了更多空间。例如，BrowseComp这样的基准测试 AI Agent 能否在开放网络的干草堆中找到针——问题设计为易于验证但难以解决。

构建研究 Agent 评估的一种策略是组合评分器类型。有据性检查验证声明是否由检索到的来源支持，覆盖度检查定义好的答案必须包含的关键事实，来源质量检查确认所参考的来源是权威的，而不仅仅是首先检索到的。对于有客观正确答案的任务（“X 公司第三季度营收是多少？"），精确匹配有效。LLM 可以标记不支持的声明和覆盖度缺口，但也可以验证开放式综合的连贯性和完整性。

鉴于研究质量的主观性，基于 LLM 的评分标准应经常与专家人工判断校准，以有效评分这些 Agent。

计算机使用 Agent Link to heading

计算机使用 Agent 通过与人类相同的界面与软件交互——截图、鼠标点击、键盘输入和滚动——而不是通过 API 或代码执行。它们可以使用任何具有图形用户界面（GUI）的应用程序，从设计工具到传统企业软件。评估需要在真实或沙盒环境中运行 Agent，使其能够使用软件应用程序，并检查它是否达成了预期结果。例如，WebArena测试基于浏览器的任务，使用 URL 和页面状态检查来验证 Agent 是否正确导航，以及对修改数据的任务进行后端状态验证（确认订单确实已下，而不仅仅是确认页面出现了）。OSWorld将此扩展到完整的操作系统控制，评估脚本在任务完成后检查各种产物：文件系统状态、应用程序配置、数据库内容和 UI 元素属性。

浏览器使用 Agent 需要在 Token 效率和延迟之间取得平衡。基于 DOM 的交互执行快速但消耗大量 Token，而基于截图的交互较慢但更节省 Token。例如，当要求 Claude 总结维基百科时，从 DOM 中提取文本更高效。当在亚马逊上寻找新的笔记本电脑包时，截图更高效（因为提取整个 DOM 非常消耗 Token）。在我们的 Claude for Chrome 产品中，我们开发了评估来检查 Agent 是否为每个上下文选择了正确的工具。这使我们能够更快、更准确地完成基于浏览器的任务。

如何看待 Agent 评估中的非确定性 Link to heading

无论 Agent 类型如何，Agent 的行为在不同运行之间会有变化，这使得评估结果比乍看之下更难解读。每个任务都有自己的成功率——可能一个任务 90%，另一个 50%——而在一次评估运行中通过的任务可能在下一次失败。有时，我们想衡量的是 Agent 在一个任务上多经常（多少比例的试验）成功。

两个指标有助于捕捉这种细微差别：

pass@k衡量 Agent 在 k 次尝试中至少获得一个正确解决方案的可能性。随着 k 增加，pass@k 分数上升：更多"射门"意味着至少 1 次成功的几率更高。50% 的 pass@1 分数意味着模型在第一次尝试时成功完成了一半的评估任务。在编码中，我们通常最关心 Agent 是否能在第一次尝试时找到解决方案——pass@1。在其他情况下，只要有一个方案可行，提出多个解决方案也是有效的。

pass^k衡量所有 k 次试验全部成功的概率。随着 k 增加，pass^k 下降，因为要求更多试验中保持一致性是更难达到的标准。如果你的 Agent 每次试验的成功率是 75%，运行 3 次试验，全部通过的概率是 (0.75)³ ≈ 42%。这个指标对于面向用户的 Agent 尤其重要，因为用户期望每次都能获得可靠的行为。

pass@k 和 pass^k 随着试验次数增加而分化。在 k=1 时，它们相同（都等于每次试验的成功率）。到 k=10 时，它们讲述相反的故事：pass@k 接近 100%，而 pass^k 降至 0%。

两个指标都有用，使用哪个取决于产品需求：pass@k 适用于一次成功就重要的工具，pass^k 适用于一致性至关重要的 Agent。

从零到一：构建优秀 Agent 评估的路线图 Link to heading

本节列出了我们经过实践检验的建议，帮助你从没有评估到拥有可以信任的评估。将此视为评估驱动的 Agent 开发路线图：尽早定义成功、清晰衡量、持续迭代。

为初始评估数据集收集任务 Link to heading

第 0 步：尽早开始

我们看到团队因为认为需要数百个任务而推迟构建评估。实际上，从真实失败中提取的 20-50 个简单任务就是一个很好的起点。毕竟，在 Agent 开发早期，系统的每次变更通常都有明显的影响，这种大效应量意味着小样本量就足够了。更成熟的 Agent 可能需要更大、更难的评估来检测更小的效应，但最好在开始时采取 80/20 的方法。等待时间越长，评估就越难构建。早期，产品需求自然可以转化为测试用例。等太久，你就得从运行中的系统逆向工程成功标准。

第 1 步：从你已经在手动测试的内容开始

从你在开发期间运行的手动检查开始——每次发布前验证的行为和终端用户尝试的常见任务。如果你已经在生产环境中，查看你的 bug 追踪器和支持队列。将用户报告的失败转化为测试用例，确保你的套件反映实际使用情况；按用户影响优先排序有助于你将精力投入到最重要的地方。

第 2 步：编写无歧义的任务并提供参考解决方案

把任务质量做对比看起来更难。一个好的任务是两个领域专家能独立得出相同通过/失败结论的任务。他们自己能通过这个任务吗？如果不能，任务需要改进。任务规范中的歧义会变成指标中的噪声。基于模型的评分器的标准也是如此：模糊的评分标准会产生不一致的判断。

每个任务都应该能被正确遵循指令的 Agent 通过。这可能很微妙。例如，审计 Terminal-Bench 发现，如果一个任务要求 Agent 编写脚本但没有指定文件路径，而测试假设了特定的文件路径，Agent 可能不是自己的过错而失败。评分器检查的所有内容都应该在任务描述中明确；Agent 不应因模糊的规范而失败。对于前沿模型，多次试验中 0% 的通过率（即 0% pass@100）通常是任务有问题的信号，而不是 Agent 能力不足，也是重新检查任务规范和评分器的标志。对于每个任务，创建一个参考解决方案很有用：一个已知能通过所有评分器的有效输出。这证明任务是可解的，并验证评分器配置正确。

第 3 步：构建平衡的问题集

同时测试行为应该发生和不应该发生的情况。单方面的评估导致单方面的优化。例如，如果你只测试 Agent 是否在应该搜索时是否搜索，你可能最终得到一个几乎什么都搜索的 Agent。尽量避免类别不平衡的评估。我们在为 Claude.ai的网页搜索构建评估时亲身学到了这一点。挑战在于防止模型在不应该搜索时搜索，同时保留其在适当时进行广泛研究的能力。团队构建了覆盖两个方向的评估：模型应该搜索的查询（如查找天气）和应该从现有知识回答的查询（如"谁创立了苹果公司？"）。在欠触发（应该搜索时不搜索）和过触发（不应该搜索时搜索）之间取得正确平衡很困难，需要对提示和评估进行多轮改进。随着更多示例问题出现，我们继续向评估中添加内容以改进覆盖度。

设计评估 Harness 和评分器 Link to heading

第 4 步：构建具有稳定环境的健壮评估 Harness

评估中的 Agent 应该与生产中使用的 Agent 大致相同地运行，环境本身不应引入更多噪声。每次试验应该通过从干净环境开始来"隔离”。运行之间不必要的共享状态（残留文件、缓存数据、资源耗尽）可能因基础设施不稳定而非 Agent 性能导致相关故障。共享状态还可能人为地提高性能。例如，在一些内部评估中，我们观察到 Claude 通过检查之前试验的 git 历史在某些任务上获得了不公平的优势。如果多个不同的试验因环境的相同限制（如 CPU 内存有限）而失败，这些试验不是独立的，因为它们受相同因素影响，评估结果对衡量 Agent 性能变得不可靠。

第 5 步：精心设计评分器

如上所述，好的评估设计涉及为 Agent 和任务选择最佳评分器。我们建议尽可能选择确定性评分器，在必要时或需要额外灵活性时使用 LLM 评分器，并审慎使用人工评分器进行额外验证。

有一种常见的本能是检查 Agent 是否遵循了非常具体的步骤，比如按正确顺序的一系列工具调用。我们发现这种方法过于僵化，导致测试过于脆弱，因为 Agent 经常找到评估设计者没有预料到的有效方法。为了不必要地惩罚创造性，通常更好的做法是评估 Agent 产出了什么，而不是它采取了什么路径。

对于有多个组件的任务，建立部分计分机制。一个正确识别问题并验证了客户但未能处理退款的支持 Agent，明显比一个立即失败的 Agent 更好。在结果中表示这种成功的连续性很重要。

模型评分通常需要仔细迭代以验证准确性。LLM 作为评判器的评分器应与人类专家密切校准，以确信人工评分和模型评分之间几乎没有分歧。为避免幻觉，给 LLM 一个退路，比如提供一条指令在信息不足时返回"未知”。创建清晰、结构化的评分标准来评估任务的每个维度也有帮助，然后用独立的 LLM 评判器评估每个维度，而不是用一个评判器评估所有维度。一旦系统足够健壮，只需偶尔进行人工审查即可。

一些评估有微妙的失败模式，即使 Agent 表现良好也会导致低分，因为 Agent 因评分 bug、Agent Harness 约束或歧义而未能解决任务。即使是经验丰富的团队也可能忽略这些问题。例如，Opus 4.5 在 CORE-Bench 上最初得分 42%，直到一位 Anthropic 研究员发现了多个问题：僵化的评分在期望"96.124991…“时惩罚了"96.12”、模糊的任务规范，以及不可能精确复现的随机任务。修复 bug 并使用约束更少的脚手架后，Opus 4.5 的分数跃升至 95%。类似地，METR 发现他们的时间范围基准中有几个配置错误的任务，要求 Agent 优化到声明的分数阈值，但评分要求超过该阈值。这惩罚了像 Claude 这样遵循指令的模型，而忽略声明目标的模型反而获得了更好的分数。仔细复查任务和评分器可以帮助避免这些问题。

让你的评分器能够抵抗绕过或破解。Agent 不应该能轻易"作弊"通过评估。任务和评分器的设计应确保通过确实需要解决问题，而不是利用意外的漏洞。

长期维护和使用评估 Link to heading

第 6 步：检查记录

除非你阅读多次试验的记录和评分，否则你不会知道评分器是否运作良好。在 Anthropic，我们投入了查看评估记录的工具，并定期花时间阅读它们。当任务失败时，记录告诉你 Agent 是犯了真正的错误，还是你的评分器拒绝了有效的解决方案。它还经常揭示关于 Agent 和评估行为的关键细节。

失败应该看起来是公平的：Agent 做错了什么以及为什么应该是清楚的。当分数不上升时，我们需要确信这是由于 Agent 性能而非评估本身。阅读记录是你验证评估是否衡量了真正重要内容的方式，也是 Agent 开发的关键技能。

第 7 步：监控能力评估饱和

100% 的评估追踪回归但不提供改进信号。评估饱和发生在 Agent 通过了所有可解决的任务，没有改进空间时。例如，SWE-Bench Verified 分数今年从 30% 起步，前沿模型现在接近饱和的 >80%。随着评估接近饱和，进展也会放缓，因为只剩下最困难的任务。这可能使结果具有欺骗性，因为大的能力改进表现为分数的小幅增加。例如，代码审查初创公司 Qodo 最初对 Opus 4.5 不以为然，因为他们的单次编码评估没有捕捉到在更长、更复杂任务上的提升。作为回应，他们开发了一个新的 Agent 评估框架，提供了更清晰的进展图景。

作为规则，在有人深入评估细节并阅读一些记录之前，我们不会按面值接受评估分数。如果评分不公平、任务有歧义、有效解决方案被惩罚，或 Harness 约束了模型，评估应该被修订。

第 8 步：通过开放贡献和维护保持评估套件长期健康

评估套件是一个需要持续关注和明确所有权才能保持有用的活文档。

在 Anthropic，我们尝试了各种评估维护方法。最有效的是建立专门的评估团队来拥有核心基础设施，而领域专家和产品团队贡献大部分评估任务并自己运行评估。

对于 AI 产品团队，拥有和迭代评估应该像维护单元测试一样常规。团队可能在 AI 功能上浪费数周，这些功能在早期测试中"有效"但未能满足设计良好的评估会及早暴露的未声明期望。定义评估任务是压力测试产品需求是否足够具体以开始构建的最佳方式之一。

我们推荐实践评估驱动开发：在 Agent 能够实现计划能力之前构建评估来定义它们，然后迭代直到 Agent 表现良好。在内部，我们经常构建今天"足够好"但押注于几个月后模型能做什么的功能。从低通过率开始的能力评估使这一点可见。当新模型发布时，运行套件可以快速揭示哪些押注得到了回报。

最接近产品需求和用户的人最适合定义成功。以当前的模型能力，产品经理、客户成功经理或销售人员可以使用 Claude Code 以 PR 的形式贡献评估任务——让他们做！或者更好的是，主动赋能他们。

创建有效评估的过程。

评估如何与其他方法配合以全面理解 Agent Link to heading

自动化评估可以在不部署到生产环境或影响真实用户的情况下，对 Agent 运行数千个任务。但这只是理解 Agent 性能的众多方式之一。完整的图景包括生产监控、用户反馈、A/B 测试、手动记录审查和系统性人工评估。

理解 AI Agent 性能的方法概览

方法	优点	缺点
自动化评估在没有真实用户的情况下程序化运行测试	• 更快的迭代 • 完全可复现 • 无用户影响 • 可在每次提交时运行 • 无需生产部署即可大规模测试场景	• 需要更多前期投入来构建 • 随着产品和模型演进需要持续维护以避免漂移 • 如果不匹配真实使用模式可能产生虚假信心
生产监控在运行系统中追踪指标和错误	• 揭示大规模的真实用户行为 • 捕捉合成评估遗漏的问题 • 提供 Agent 实际表现的真实基准	• 被动的；问题到达用户之前你不知道 • 信号可能有噪声 • 需要投入监控基础设施 • 缺乏评分的真实基准
A/B 测试用真实用户流量比较变体	• 衡量实际用户结果（留存、任务完成） • 控制混淆因素 • 可扩展且系统化	• 缓慢；需要数天或数周才能达到显著性，且需要足够流量 • 只测试你部署的变更 • 在无法彻底审查记录的情况下，对指标变化背后的"为什么"信号较少
用户反馈明确的信号，如差评或 bug 报告	• 发现你没有预料到的问题 • 附带真实人类用户的实际案例 • 反馈通常与产品目标相关	• 稀疏且自我选择 • 偏向严重问题 • 用户很少解释为什么某事失败 • 非自动化 • 主要依赖用户来发现问题可能对用户体验产生负面影响
手动记录审查人类阅读 Agent 对话	• 建立对失败模式的直觉 • 捕捉自动化检查遗漏的细微质量问题 • 帮助校准什么是"好的"并掌握细节	• 耗时 • 不可扩展 • 覆盖不一致 • 审查者疲劳或不同审查者可能影响信号质量 • 通常只给出定性信号而非清晰的定量评分
系统性人工研究由训练有素的评分者对 Agent 输出进行结构化评分	• 来自多个人类评分者的金标准质量判断 • 处理主观或模糊的任务 • 为改进基于模型的评分器提供信号	• 相对昂贵且周转缓慢 • 难以频繁运行 • 评分者间分歧需要协调 • 复杂领域（法律、金融、医疗）需要人类专家进行研究

这些方法映射到 Agent 开发的不同阶段。自动化评估在发布前和 CI/CD 中尤其有用，在每次 Agent 变更和模型升级时运行，作为抵御质量问题的第一道防线。生产监控在发布后启动，检测分布漂移和未预料到的真实世界故障。A/B 测试在有足够流量时验证重大变更。用户反馈和记录审查是填补空白的持续实践：持续分类反馈、每周抽样阅读记录，并根据需要深入分析。将系统性人工研究保留用于校准 LLM 评分器或评估主观输出，其中人类共识作为参考标准。

就像安全工程中的瑞士奶酪模型，没有单一评估层能捕捉所有问题。多种方法组合使用时，穿过一层的失败会被另一层捕获。

最有效的团队组合使用这些方法：自动化评估用于快速迭代，生产监控用于真实基准，定期人工审查用于校准。

结论 Link to heading

没有评估的团队陷入被动循环——修复一个故障，又制造另一个，无法区分真正的回归和噪声。及早投入的团队发现恰恰相反：随着失败变成测试用例、测试用例防止回归、指标取代猜测，开发加速了。评估给整个团队一个清晰的山头去攀登，将"Agent 感觉变差了"变成可操作的内容。价值是累积的，但前提是你把评估作为核心组件，而不是事后补充。

模式因 Agent 类型而异，但这里描述的基本原则是不变的。尽早开始，不要等待完美的套件。从你看到的失败中获取真实任务。定义无歧义、健壮的成功标准。精心设计评分器并组合多种类型。确保问题对模型来说足够难。迭代评估以提高其信噪比。阅读记录！

AI Agent 评估仍然是一个新兴、快速发展的领域。随着 Agent 承担更长的任务、在多 Agent 系统中协作，以及处理越来越主观的工作，我们需要调整我们的技术。我们将继续在学到更多时分享最佳实践。

致谢 Link to heading

由 Mikaela Grace、Jeremy Hadfield、Rodrigo Olivares 和 Jiri De Jonghe 撰写。我们还感谢 David Hershey、Gian Segato、Mike Merrill、Alex Shaw、Nicholas Carlini、Ethan Dixon、Pedram Navid、Jake Eaton、Alyssa Baum、Lina Tawfik、Karen Zhou、Alexander Bricken、Sam Kennedy、Robert Ying 及其他人的贡献。特别感谢我们通过评估合作学习的客户和合作伙伴，包括 iGent、Cognition、Bolt、Sierra、Vals.ai、Macroscope、PromptLayer、Stripe、Shopify、Terminal Bench 团队等。这项工作反映了多个团队共同努力发展 Anthropic 评估实践的成果。

附录：评估框架 Link to heading

几个开源和商业框架可以帮助团队实现 Agent 评估，而无需从零构建基础设施。正确的选择取决于你的 Agent 类型、现有技术栈，以及你需要离线评估、生产可观测性还是两者兼需。

Harbor专为在容器化环境中运行 Agent 而设计，具有跨云提供商大规模运行试验的基础设施，以及定义任务和评分器的标准化格式。Terminal-Bench 2.0 等流行基准通过 Harbor 注册表发布，使得运行既有基准和自定义评估套件变得容易。

Braintrust是一个将离线评估与生产可观测性和实验追踪相结合的平台——适用于需要同时在开发期间迭代和生产中监控质量的团队。其 autoevals 库包含用于事实性、相关性等常见维度的预构建评分器。

LangSmith提供追踪、离线和在线评估以及数据集管理，与 LangChain 生态系统紧密集成。Langfuse提供类似功能，作为有数据驻留要求的团队的自托管开源替代方案。

Arize提供 Phoenix，一个用于 LLM 追踪、调试和离线或在线评估的开源平台，以及 AX，一个为规模、优化和监控扩展 Phoenix 的 SaaS 产品。

许多团队组合使用多种工具、自建评估框架，或仅使用简单的评估脚本作为起点。我们发现，虽然框架可以是加速进展和标准化的有价值方式，但它们的好坏取决于你通过它们运行的评估任务。通常最好的做法是快速选择一个适合你工作流的框架，然后通过迭代高质量测试用例和评分器将精力投入到评估本身。

原文链接 Link to heading

https://www.anthropic.com/engineering/demystifying-evals-for-ai-agents