解开AI智能体评估的神秘面纱

# 引言

良好的评估有助于团队更自信地发布 AI 智能体。如果没有评估，很容易陷入被动循环——只能在生产环境中发现问题，而在那里修复一个故障往往会导致其他故障。评估能让问题和行为变化在影响用户之前显现出来，并且它们的价值会在智能体的整个生命周期中复利递增。

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

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

# 评估的结构

评估（“eval”）是对 AI 系统的测试：给 AI 一个输入，然后对其输出应用评分逻辑以衡量成功与否。在本文中，我们重点关注自动化评估，即可以在开发过程中运行而无需真实用户参与的评估。

单轮评估直截了当：包含一个提示词、一个回复和评分逻辑。对于早期的 LLM（大语言模型），单轮、非智能体式的评估是主要的评估方法。随着 AI 能力的提升，多轮评估变得越来越普遍。

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

智能体评估则更加复杂。智能体在多轮交互中使用工具，修改环境状态并随之调整——这意味着错误可能会传播和累积。前沿模型还能找到超越静态评估限制的创造性解决方案。例如，Opus 4.5 通过发现政策中的漏洞，解决了一个关于预订航班的 𝜏2-bench 问题。按照既定标准，它在评估中“失败”了，但实际上为用户提出了更好的解决方案。

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

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

代理评估的组件。

# 为什么要构建评估？

当团队刚开始构建智能体（Agent）时，通过结合手动测试、吃自家的狗粮（内部试用）和直觉，他们往往能取得惊人的进展。更严格的评估甚至可能看起来像是拖慢发布速度的负担。但在早期的原型阶段之后，一旦智能体投入生产并开始扩展，没有评估（evals）的构建方式就会开始难以为继。

临界点通常出现在用户反馈变更后智能体的体验变差，而团队处于“盲飞”状态，除了猜测和验证外无法确认问题。缺乏评估时，调试是被动的：等待投诉，手动复现，修复漏洞，并祈祷没有其他功能退化。团队无法区分真正的退化和噪音，无法在发布前针对数百个场景自动测试变更，也无法衡量改进效果。

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

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

Descript 的智能体帮助用户编辑视频，因此他们围绕成功编辑工作流的三个维度构建了评估：不搞破坏、执行指令和完成出色。他们从人工打分演变为由产品团队定义标准并定期进行人工校准的 LLM 打分器，现在定期运行两套独立的测试套件，分别用于质量基准测试和回归测试。Bolt AI 团队开始构建评估的时间较晚，是在他们已经拥有广泛使用的智能体之后。在 3 个月内，他们构建了一个评估系统，运行其智能体并通过静态分析对输出进行评分，使用浏览器智能体测试应用，并利用 LLM 裁判来评估指令遵循等行为。

有些团队在开发之初就创建评估；另一些则在规模化之后，当缺乏评估成为改进智能体的瓶颈时才添加。在智能体开发初期，评估对于显式编码预期行为特别有用。两位工程师阅读同一份初始规范，可能会对 AI 应如何处理边缘情况产生不同的理解。一套评估套件可以消除这种歧义。无论何时创建，评估都有助于加速开发。

评估也决定了你采用新模型的速度。当更强大的模型问世时，没有评估机制的团队面临数周的测试，而拥有评估机制的竞争对手可以在几天内迅速确定模型的优势、调整提示词并完成升级。

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

# 如何评估 AI 智能体

我们看到如今有几种常见类型的智能体正在大规模部署，包括编程智能体、研究智能体、计算机操作智能体和对话智能体。

每种类型都可能部署在各行各业，但它们可以使用类似的技术进行评估。你不需要从零开始设计评估方法。下面的章节描述了几种针对特定智能体类型的成熟技术。请以这些方法为基础，然后将其扩展到你的领域中。

# 智能体评分器的类型

智能体评估通常结合三种类型的评分器：基于代码的、基于模型的和人工的。每种评分器都会评估对话记录或结果的一部分。有效评估设计的一个重要组成部分是为任务选择合适的评分器。

基于代码的评分器

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

基于模型的评分器

人工评分器

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

# 能力评估与回归评估

能力评估或“质量”评估询问“该智能体擅长做什么？”它们的初始通过率应该较低，针对智能体难以处理的任务，从而给团队提供一个攀登的目标。

回归评估询问“该智能体是否仍能处理它过去能处理的所有任务？”并且应该具有接近 100% 的通过率。它们防止性能倒退，因为分数的下降意味着某处出现了故障，需要进行改进。当团队在能力评估上不断攀登时，运行回归评估同样重要，以确保变更不会在其他地方引发问题。

在智能体发布并优化后，通过率较高的能力评估可以“毕业”成为回归测试套件，持续运行以捕捉任何偏差。曾经用来衡量“我们可以做这件事吗？”的任务，转而变为衡量“我们还能可靠地做这件事吗？”

# 评估编程智能体

编程智能体像人类开发者一样编写、测试和调试代码，浏览代码库并运行命令。对现代编程智能体进行有效的评估，通常依赖于明确指定的任务、稳定的测试环境以及对生成代码的详尽测试。

确定性评分器对于编程智能体来说是很自然的，因为软件评估通常很直观：代码能运行吗？测试能通过吗？两个广泛使用的编程智能体基准测试，SWE-bench Verified 和 Terminal-Bench，都遵循这一方法。SWE-bench Verified 为智能体提供来自流行 Python 仓库的 GitHub issues，并通过运行测试套件来对解决方案进行评分；只有当解决方案修复了失败的测试且没有破坏现有的测试时，才算通过。仅仅一年时间，大语言模型（LLM）在此项评估中的通过率就从 40% 提高到了 >80%。Terminal-Bench 则采取了不同的路径：它测试端到端的技术任务，例如从源码构建 Linux 内核或训练机器学习模型。

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

示例：编程智能体的理论评估

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

task:
  id: "fix-auth-bypass_1"
  desc: "修复当密码字段为空时的认证绕过问题……"
  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 评分标准来评估整体代码质量，仅在需要时才会添加额外的评分器和指标。

# 评估对话式智能体

对话式智能体在客服、销售或辅导等领域与用户进行互动。与传统聊天机器人不同，它们能够维护状态、使用工具并在对话过程中采取行动。虽然编程和研究智能体也可能涉及与用户的多轮互动，但对话式智能体带来了一个独特的挑战：互动本身的质量也是你需要评估的一部分。对对话式智能体的有效评估通常依赖于可验证的最终状态结果，以及既能捕捉任务完成情况又能捕捉互动质量的评分标准。与大多数其他评估不同，它们通常需要第二个大语言模型（LLM）来模拟用户。我们在对齐审计智能体中使用了这种方法，通过长时间的对抗性对话对模型进行压力测试。

对话式智能体的成功可以是多维度的：工单是否已解决（状态检查）？是否在 10 轮以内完成（对话记录约束）？语气是否得当（LLM 评分标准）？结合了多维度特性的两个基准测试是 𝜏-Bench 及其后续版本 τ2-Bench。这些基准测试模拟了零售客服和机票预订等领域的多轮互动，其中一个模型扮演用户角色，而智能体则应对现实场景。

示例：对话式智能体的理论评估

考虑一个客服任务，智能体必须为一位沮丧的客户处理退款。

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

正如我们的编码智能体示例一样，本任务展示了多种评分器类型以作说明。在实践中，对话智能体的评估通常使用基于模型的评分器来评估沟通质量和目标完成情况，因为许多任务——比如回答问题——可能有多种“正确”的解决方案。

# 评估研究智能体

研究智能体收集、综合和分析信息，然后生成像答案或报告这样的输出。与通过单元测试提供二元通过/失败信号的编码智能体不同，研究质量只能依据具体任务进行评判。什么算作“全面”、“来源详实”甚至“正确”取决于具体情境：市场扫描、收购尽职调查和科学报告各自需要不同的标准。

研究评估面临独特的挑战：专家可能对综合内容是否全面持不同意见，基本事实（ground truth）随着参考内容的不断变化而改变，而且更长、更开放的输出也留下了更多犯错的空间。例如，像 BrowseComp 这样的基准测试，考察了 AI 智能体能否在开放网络中“大海捞针”——即回答那些设计上易于验证但难以解决的问题。

构建研究智能体评估的一种策略是结合多种评分器类型。依据性检查（Groundedness checks）验证论点是否得到检索来源的支持，覆盖率检查（coverage checks）定义好的答案必须包含的关键事实，而来源质量检查（source quality checks）则确认所参考的来源具备权威性，而不仅仅是首先检索到的结果。对于有客观正确答案的任务（“X 公司第三季度的收入是多少？”），完全匹配（exact match）是有效的。LLM 不仅可以标记无凭据的论点和覆盖范围的缺失，还可以验证开放式综合内容的连贯性和完整性。

鉴于研究质量的主观性，基于 LLM 的评分标准应经常根据人类专家的判断进行校准，以有效地对这些智能体进行评分。

# 计算机使用智能体

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

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

# 如何思考智能体评估中的非确定性

无论智能体类型如何，智能体行为在不同运行之间都会存在差异，这使得评估结果比乍看之下更难解读。每个任务都有其自身的成功率——可能一个任务是 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 到 1：构建出色智能体评估的路线图

本节列出了我们经过实战检验的实用建议，旨在帮助你从没有评估过渡到可以信赖的评估。可以将此视为评估驱动型智能体开发的路线图：尽早定义成功，清晰地进行衡量，并持续迭代。

# 收集初始评估数据集的任务

步骤 0. 尽早开始

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

步骤 1. 从你已经手动测试的内容开始

从开发过程中运行的手动检查开始——即你在每次发布前验证的行为以及最终用户尝试的常见任务。如果你已经上线（在生产环境中），请查看你的错误跟踪器和支持队列。将用户报告的失败案例转化为测试用例，可以确保你的测试套件反映实际使用情况；按用户影响优先级排序有助于将精力投入到关键之处。

步骤 2：编写带有参考答案的无歧义任务

确立高质量的任务比看起来要难。一个好的任务是指两位领域专家能够独立得出相同的通过/失败结论。他们自己能通过这个任务吗？如果不能，任务就需要完善。任务规范中的歧义会变成指标中的噪声。这同样适用于基于模型的评分器（grader）的标准：模糊的评分细则会导致判断不一致。

每个任务都应该是能够被正确遵循指令的智能体通过的。这可能很微妙。例如，审计 Terminal-Bench 发现，如果任务要求智能体编写脚本但没有指定文件路径，而测试却预设脚本位于特定路径，智能体可能会在没有过错的情况下失败。评分器检查的所有内容都应该在任务描述中清晰可见；智能体不应因规格模糊而失败。对于前沿模型，如果在多次尝试中通过率为 0%（即 0% pass@100），通常是任务本身有问题，而不是智能体能力不足，这标志着需要仔细检查你的任务规范和评分器。对于每个任务，创建一个参考答案是很有用的：即一个已知可行的、能通过所有评分器的输出。这证明了任务是可解的，并验证了评分器配置正确。

步骤 3：构建均衡的问题集

既要测试行为应该发生的情况，也要测试不应该发生的情况。片面的评估会导致片面的优化。例如，如果你只测试智能体是否在应该搜索时进行了搜索，最终可能会得到一个几乎对所有内容都进行搜索的智能体。请尽量避免类别不平衡的评估。我们在为 Claude.ai 构建网络搜索评估时，对此有了切身体会。当时的挑战在于，既要防止模型在不该搜索时进行搜索，又要保留其在适当时进行深入研究的能力。团队构建了涵盖这两个方面的评估：模型应该搜索的查询（如查询天气），以及应该利用现有知识回答的查询（如“谁创立了苹果？”）。在触发不足（该搜索时不搜）与过度触发（不该搜索时乱搜）之间找到恰当的平衡点非常困难，我们需要对提示词和评估进行多轮打磨。随着更多问题案例的出现，我们持续将其添加到评估中，以提高覆盖率。

# 设计评估框架与评分器

步骤 4：构建稳健的评估框架与稳定的环境

至关重要的是，评估中的智能体（Agent）必须与生产环境中使用的智能体运行方式大致相同，且环境本身不应引入额外的干扰。每次试验都应通过从一个干净的环境启动来保持“隔离”。运行之间不必要的共享状态（遗留文件、缓存数据、资源耗尽）可能导致因基础设施不稳定（flakiness）而非智能体性能问题引起的关联故障。共享状态还可能人为地虚高性能表现。例如，在一些内部评估中，我们观察到 Claude 通过查看之前试验的 git 历史记录，在某些任务上获得了不公平的优势。如果多个不同的试验因为环境中的同一个限制（如 CPU 内存受限）而失败，这些试验就不是独立的，因为它们受到了相同因素的影响，从而导致评估结果在衡量智能体性能时变得不可靠。

步骤 5：精心设计评分器

如前所述，优秀的评估设计包括为智能体和任务选择最佳的评分器。我们建议在可能的情况下选择确定性评分器，在必要时或为了增加灵活性使用 LLM 评分器，并审慎地使用人工评分员进行额外的验证。

人们通常有一种本能，想要检查智能体是否遵循了非常具体的步骤，例如按正确顺序调用一系列工具。我们发现这种方法过于僵化，会导致测试过于脆弱，因为智能体经常能找到评估设计者未曾预料到的有效方法。为了不无谓地惩罚创造力，通常更好的做法是对智能体的产出进行评分，而不是对其采取的路径评分。

对于包含多个组件的任务，应设置部分得分。一个能正确识别问题并验证客户身份但未能处理退款的客服智能体，明显优于一个立即失败的智能体。在结果中体现这种成功的连续性非常重要。

模型评分通常需要仔细迭代以验证准确性。“LLM作为裁判”（LLM-as-judge）的评分器应与人类专家紧密校准，以确信人类评分与模型评分之间差异甚微。为避免幻觉，应给 LLM 留一条后路，例如提供一条指令，让它在信息不足时返回“未知”（Unknown）。为任务的每个维度制定清晰、结构化的评分标准，然后用独立的“LLM作为裁判”对每个维度进行评分，而不是用一个模型来评分所有维度，这也很有帮助。一旦系统变得稳健，只需偶尔进行人工审查即可。

某些评估存在隐蔽的失效模式，即使 Agent 表现出色得分也会很低，这是因为评分程序的 Bug、Agent 运行框架的限制或任务描述的歧义导致 Agent 无法完成任务。即使是顶尖团队也可能忽略这些问题。例如，Opus 4.5 起初在 CORE-Bench 上仅获得 42% 的分数，直到一位 Anthropic 的研究员发现了诸多问题：评分机制过于僵化（例如期望值为“96.124991…”时，输出“96.12”会被判错）、任务说明含糊不清，以及存在无法精确复现的随机性任务。在修复 Bug 并使用限制较少的框架后，Opus 4.5 的得分飙升至 95%。同样地，METR 发现在其长期任务基准测试中存在若干配置错误的任务，这些任务要求 Agent 优化至特定的分数阈值，但评分标准却要求必须超过该阈值。这导致像 Claude 这样严格遵循指令的模型被扣分，而那些忽略既定目标的模型反而获得了更高的分数。仔细地反复核查任务和评分程序有助于避免此类问题。

确保你的评分程序能够抵御绕过或“黑客式”的破解。Agent 不应能轻易在评估中“作弊”。任务和评分程序的设计应确保：通过测试意味着真正解决了问题，而不是利用了非预期的漏洞。

# 长期维护并使用评估

步骤 6：检查交互记录

除非你阅读多次试验的交互记录和评分，否则你无法得知评分器是否运作良好。在 Anthropic，我们投入资源开发了用于查看评估记录的工具，并且定期花时间去阅读这些记录。当任务失败时，记录能告诉你究竟是智能体真的犯了错，还是评分器误判了有效的解决方案。它通常还能揭示关于智能体和评估行为的关键细节。

失败应当显得合理：清楚地展示智能体错在哪里以及原因。当分数没有提升时，我们需要确信这是归因于智能体的表现，而非评估本身的问题。阅读交互记录是验证你的评估是否在衡量真正重要指标的手段，也是开发智能体的一项关键技能。

步骤 7：监控能力评估的饱和情况

一项达到 100% 的评估可以监测回退，但无法提供改进信号。当智能体通过了所有可解决的任务，不再有提升空间时，就发生了 评估饱和 (Eval saturation)。例如，SWE-Bench Verified 的分数今年起步于 30%，而现在前沿模型已接近饱和，分数超过 80%。随着评估趋于饱和，进展也会变慢，因为只剩下最难的任务了。这可能会使结果具有欺骗性，因为巨大的能力提升仅表现为分数的微小增长。例如，代码审查初创公司 Qodo 起初对 Opus 4.5 印象平平，因为他们的单次编码评估未能捕捉到其在更长、更复杂任务上的收益。为此，他们开发了一套新的代理式评估框架，从而更清晰地呈现了进展情况。

原则上，在有人深入挖掘评估细节并阅读部分交互记录之前，我们不会只看评估分数的表面数值。如果评分不公、任务歧义、有效方案被扣分，或者测试框架（harness）限制了模型发挥，那么该评估就需要进行修订。

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

评估套件是一种具有生命力的产物，需要持续的关注和明确的所有权归属才能保持其效用。

在 Anthropic，我们尝试了多种评估维护方法。事实证明最有效的方式是建立专门的评估团队来负责核心基础设施，而领域专家和产品团队则贡献绝大多数的评估任务并自行运行评估。

对于 AI 产品团队而言，负责并迭代评估应当像维护单元测试一样成为常态。团队可能会在那些早期测试中看似“可行”的 AI 功能上浪费数周时间，结果却未能满足某些未明示的期望，而设计良好的评估本可以尽早暴露这些问题。定义评估任务是检验产品需求是否具体到可以开始构建的最佳方式之一，也是一种极好的压力测试。

我们建议实践评估驱动开发（eval-driven development）：在智能体能够实现目标能力之前，先构建评估标准来定义这些规划中的能力，然后不断迭代，直到智能体表现良好。在内部，我们经常构建一些在当下“勉强够用”的功能，但这其实是押注模型在未来几个月能达到何种能力。起始通过率较低的能力评估能让这种潜力变得清晰可见。当新模型发布时，运行测试套件能迅速揭示哪些押注获得了回报。

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

创建有效评估的流程。

# 评估如何与其他方法结合以全面了解智能体

自动化评估可以针对智能体运行数千项任务测试，而无需部署到生产环境或影响真实用户。但这只是了解智能体性能的众多方法之一。一个完整的评估体系还包括生产环境监控、用户反馈、A/B 测试、人工审查对话记录以及系统性的人工评估。

了解 AI 智能体性能的方法概览

这些方法对应于智能体开发的不同阶段。自动化评估在发布前和 CI/CD（持续集成/持续部署）环节尤为有用，它在每次智能体变更和模型升级时运行，作为防范质量问题的第一道防线。生产监控在发布后启动，以检测分布漂移和未预料到的现实世界故障。一旦拥有足够的流量，A/B 测试可用于验证重大变更。用户反馈和对话记录审查是填补空白的常态化做法——持续筛选反馈，每周抽样阅读对话记录，并在需要时深入挖掘。将系统性的人类研究保留用于校准 LLM 评分器，或评估那些以人类共识为参考标准的主观输出。

就像安全工程中的 瑞士奶酪模型 一样，没有任何单一的评估层能捕捉到所有问题。通过结合多种方法，漏过某一层的故障会被另一层拦截。

最有效的团队会结合使用这些方法——利用自动化评估实现快速迭代，利用生产监控掌握真实情况，并进行定期的人工审查以进行校准。

# 结论

没有建立评估机制（evals）的团队往往深陷于被动的循环中——修复一个故障，却引发另一个，无法分辨真正的退步（regression）与干扰噪音。而尽早投入评估的团队则会发现截然相反的景象：随着故障转化为测试用例，测试用例防止了功能回退，数据指标取代了凭空猜测，开发进程得以加速。评估为整个团队指明了清晰的攀登目标，将“Agent 感觉变差了”这种模糊的抱怨转化为可落实的具体行动。这种价值会产生复利效应，但前提是你必须将评估视为核心组件，而非事后的亡羊补牢。

尽管针对不同类型的 Agent 模式各异，但本文所述的基本原则是不变的。尽早开始，不要等待完美的测试套件。从你遇到的故障中汲取素材，构建现实的任务。定义明确且稳健的成功标准。精心设计评分器（graders），并结合多种类型使用。确保问题对模型具有足够的挑战性。不断迭代评估方法以提高信噪比。一定要阅读对话记录（transcripts）！

AI Agent 评估仍是一个处于萌芽阶段且快速发展的领域。随着 Agent 承担更长周期的任务、在多 Agent 系统中协作以及处理日益主观的工作，我们需要不断调整技术手段。随着认知的深入，我们将持续分享最佳实践。

# 致谢

本文由 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 推动评估实践发展的结晶。

# 附录：评估框架

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

Harbor 专为在容器化环境中运行 Agent 而设计，拥有跨云服务提供商大规模运行测试的基础设施，以及用于定义任务和评分器的标准化格式。像 Terminal-Bench 2.0 这样流行的基准测试通过 Harbor 仓库发布，使得运行既定的基准测试以及自定义评估套件变得容易。

Promptfoo 是一个轻量级、灵活且开源的框架，专注于使用声明式 YAML 配置进行提示词测试，其断言类型涵盖了从字符串匹配到 LLM-as-judge（大模型作为裁判）评分标准的各种形式。我们在许多产品评估中都使用了 Promptfoo 的某个版本。

Braintrust 是一个结合了离线评估、生产环境可观测性和实验跟踪的平台——对于需要在开发过程中迭代并在生产环境中监控质量的团队来说非常有用。它的 autoevals 库包含了针对真实性、相关性和其他常见维度的预置评分器。

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

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