原文: English original · Anthropic/OpenAI 官方

揭开 AI agents 评测的神秘面纱

让 agents 变得有用的能力，也让它们难以评测。跨部署有效的策略，会组合多种技术，使评测方法与被测系统的复杂性相匹配。

引言

好的评测能帮助团队更有信心地发布 AI agents。没有评测，团队很容易陷入被动循环：只有到了生产环境才发现问题，而修复一个失败又会制造新的失败。评测能在问题和行为变化影响用户之前把它们暴露出来，并且它们的价值会在 agent 的整个生命周期中持续累积。

正如我们在《构建高效的 agent》中所说，agents 会跨多个轮次运行：调用工具、修改状态，并根据中间结果调整行为。正是这些让 AI agents 有用的能力——自主性、智能和灵活性——也让它们更难评测。

通过内部实践，以及与处在 agent 开发前沿的客户合作，我们学会了如何为 agents 设计更严谨、更有用的评测。下面这些做法，已经在真实部署中的多种 agent 架构和用例里被证明有效。

评测的结构

评测是针对 AI 系统的测试：给 AI 一个输入，然后对它的输出应用评分逻辑来衡量成功与否。本文关注的是自动化评测，也就是可以在开发期间运行、无需真实用户参与的评测。

单轮评测很直接：一个 prompt、一个响应，以及评分逻辑。对于早期 LLM，单轮、非 agentic 评测是主要的评测方法。随着 AI 能力提升，多轮评测越来越常见。

Agent 评测更复杂。Agents 会跨多个轮次使用工具，在环境中修改状态，并在过程中不断调整，这意味着错误可能传播并累积。前沿模型还可能找到富有创造性的解决方案，超出静态评测的限制。例如，Opus 4.5 在解决一个关于预订航班的 τ2-bench 问题时，发现了政策中的一个漏洞。按评测文本来看它“失败”了，但实际上为用户想出了更好的方案。

在构建 agent 评测时，我们使用以下定义：

• 任务（也称 problem 或 test case）是一个单独测试，包含明确输入和成功标准。
• 对某个任务的每次尝试称为一次 trial。由于模型输出在不同运行之间会变化，我们会运行多次 trials，以得到更稳定的结果。
• 评分器是对 agent 某方面表现进行打分的逻辑。一个任务可以有多个评分器，每个评分器包含多个断言（有时称为 checks）。
• Transcript（也称 trace 或 trajectory）是一次 trial 的完整记录，包括输出、工具调用、推理、中间结果，以及任何其他交互。对于 Anthropic API 来说，它就是一次评测运行结束时完整的 messages array，其中包含评测期间对 API 的所有调用和所有返回响应。
• Outcome 是 trial 结束时环境中的最终状态。一个航班预订 agent 可能会在 transcript 末尾说“Your flight has been booked”，但 outcome 是环境的 SQL 数据库里是否真的存在一条预订记录。
• 评测 harness 是端到端运行评测的基础设施。它提供指令和工具，并发运行任务，记录所有步骤，对输出评分，并聚合结果。
• Agent harness（或 scaffold）是让模型能够作为 agent 行动的系统：它处理输入、编排工具调用并返回结果。当我们评测“一个 agent”时，我们评测的是 harness 与模型的协同工作。例如，Claude Code 是一个灵活的 agent harness，而我们通过 Agent SDK 使用了它的核心 primitives，构建了我们的长时间运行 agent harness。
• 评测套件是一组任务，用于衡量特定能力或行为。套件中的任务通常共享一个宽泛目标。例如，客户支持评测套件可能测试退款、取消和升级处理。

为什么要构建评测？

团队刚开始构建 agents 时，凭借手动测试、dogfooding 和直觉的组合，往往能推进得出人意料地远。更严谨的评测甚至可能看起来像是拖慢发布的额外开销。但在早期原型阶段之后，一旦 agent 进入生产并开始扩展，不做评测的构建方式就会开始失效。

转折点通常出现在用户反馈说改动之后 agent 变差了，而团队却在“盲飞”，除了猜测和反复试错，没有办法验证。没有评测时，调试是被动的：等待投诉，手动复现，修 bug，然后希望没有别的地方退化。团队无法区分真实退化和噪声，无法在发布前自动用数百个场景测试改动，也无法衡量改进。

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

在 agent 生命周期的任何阶段编写评测都有价值。早期，评测会迫使产品团队明确 agent 的成功意味着什么；后期，评测则帮助维持一致的质量标准。

Descript 的 agent 帮助用户编辑视频，因此他们围绕成功编辑 workflow 的三个维度构建评测：不要破坏东西、按我的要求做、并且做得好。他们从人工评分演进到 LLM 评分器，由产品团队定义标准并定期进行人工校准；现在他们会定期运行两套独立套件，分别用于质量基准测试和回归测试。

Bolt AI 团队开始构建评测的时间较晚，当时他们已经拥有一个被广泛使用的 agent。他们用 3 个月构建出一个评测系统，可以运行他们的 agent，并用静态分析对输出评分，使用 browser agents 测试应用，还用 LLM judges 评估遵循指令等行为。

有些团队在开发一开始就创建评测；另一些团队则是在规模化之后，当评测成为改进 agent 的瓶颈时才补上。评测在 agent 开发早期尤其有用，因为它能显式编码预期行为。两个工程师阅读同一份初始 spec，可能会对 AI 应该如何处理边界情况产生不同理解。评测套件可以消除这种歧义。无论何时创建，评测都有助于加速开发。

评测还会影响你采用新模型的速度。当更强大的模型发布时，没有评测的团队可能要花数周测试；而有评测的竞争对手可以迅速判断模型优势，调优 prompts，并在几天内完成升级。

一旦有了评测，你就自动获得了基线和回归测试：延迟、token 使用量、每个任务的成本和错误率，都可以在一组静态任务库上持续跟踪。评测也可能成为产品团队与研究团队之间最高带宽的沟通渠道，定义研究人员可以优化的指标。显然，评测的收益远不止跟踪退化和改进。

由于成本在前期清晰可见，而收益是在后续逐渐累积，评测的复利价值很容易被低估。

如何评测 AI agents

我们看到目前有几类常见 agents 已经规模化部署，包括 coding agents、research agents、computer use agents 和 conversational agents。每一类都可能部署在非常多样的行业中，但可以用相似技术来评测。你不需要从零发明一套评测。下面几节介绍了几类 agent 的成熟技术。可以把这些方法作为基础，再扩展到你的领域。

Agents 的评分器类型

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

基于代码的评分器

基于模型的评分器

人工评分器

对每个任务而言，评分可以是加权的（组合评分必须达到阈值）、二元的（所有评分器都必须通过），也可以是混合形式。

能力评测与回归评测

能力或“质量”评测问的是：“这个 agent 能把什么做好？”它们应该从较低通过率开始，瞄准 agent 难以完成的任务，给团队一个明确的改进目标。

回归评测问的是：“这个 agent 是否仍能处理过去能处理的所有任务？”并且应该接近 100% 通过率。它们防止能力倒退，因为分数下降意味着某些东西坏了，需要改进。随着团队在能力评测上持续提升，同时运行回归评测也很重要，以确保改动不会在其他地方引发问题。

Agent 发布并优化之后，通过率很高的能力评测可以“毕业”，成为持续运行的回归套件，用来捕捉任何漂移。曾经衡量“我们到底能不能做到？”的任务，随后会衡量“我们是否仍能可靠地做到？”

评测 coding agents

Coding agents 会编写、测试和调试代码，像人类开发者一样浏览代码库并运行命令。面向现代 coding agents 的有效评测通常依赖定义清晰的任务、稳定的测试环境，以及针对生成代码的充分测试。

确定性评分器天然适合 coding agents，因为软件通常很容易评估：代码能否运行，测试是否通过？两个被广泛使用的 coding agent 基准 SWE-bench Verified 和 Terminal-Bench 就采用了这种方法。SWE-bench Verified 给 agents 来自流行 Python 仓库的 GitHub issues，并通过运行测试套件来给解决方案评分；只有修复失败测试且不破坏现有测试的方案才算通过。

LLMs 在这个评测上的成绩仅用一年就从 40% 提升到 >80%。Terminal-Bench 走的是另一条路线：它测试端到端技术任务，例如从源码构建 Linux kernel，或训练一个 ML model。

一旦你拥有一组用于验证 coding 任务关键 outcomes 的通过/失败测试，通常也值得对 transcript 进行评分。例如，基于启发式的代码质量规则可以在通过测试之外评估生成代码，而带有清晰 rubrics 的基于模型评分器可以评估 agent 如何调用工具或与用户交互等行为。

示例：coding agent 的理论评测

考虑一个 coding 任务：agent 必须修复一个 authentication bypass vulnerability。如下方示意性的 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

请注意，这个示例为了说明，展示了可用评分器的完整范围。实践中，coding 评测通常依赖单元测试来验证正确性，并用 LLM rubric 评估整体代码质量；只有在需要时才会加入额外评分器和指标。

评测 conversational agents

Conversational agents 会在支持、销售或教练等领域与用户交互。不同于传统 chatbots，它们会维护状态、使用工具，并在对话中途采取行动。虽然 coding 和 research agents 也可能涉及与用户的多轮交互，但 conversational agents 提出了一个独特挑战：交互本身的质量也是你要评测的内容之一。

面向 conversational agents 的有效评测通常依赖可验证的最终状态 outcomes，以及能同时捕捉任务完成情况和交互质量的 rubrics。不同于大多数其他评测，它们经常需要第二个 LLM 来模拟用户。我们在 alignment auditing agents 中使用这种方法，通过长时间、对抗性的对话对模型进行压力测试。

Conversational agents 的成功可能是多维的：ticket 是否解决（状态检查），是否在 <10 轮内完成（transcript 约束），语气是否合适（LLM rubric）？两个体现多维性的基准是 τ-Bench 及其后继 τ2-Bench。它们模拟零售支持、航班预订等领域的多轮交互，其中一个模型扮演用户 persona，而 agent 负责处理真实感场景。

示例：conversational 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

和 coding agent 示例一样，这个任务为了说明展示了多种评分器类型。实践中，conversational agent 评测通常使用基于模型的评分器，同时评估沟通质量和目标完成情况，因为许多任务——例如回答一个问题——可能有多个“正确”解。

评测 research agents

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

Research 评测面临独特挑战：专家可能不同意某个综合是否全面，ground truth 会随着参考内容不断变化而移动，更长、更开放的输出也会为错误留下更多空间。例如 BrowseComp 这样的基准，会测试 AI agents 是否能在开放 web 的大海捞针问题中找到答案，这些问题设计成容易验证但难以解决。

构建 research agent 评测的一种策略，是组合多种评分器类型。Groundedness 检查验证 claims 是否有检索到的 sources 支撑，coverage 检查定义一个好答案必须包含的关键事实，source quality 检查确认所咨询的 sources 是权威的，而不是仅仅因为最先被检索到。对于有客观正确答案的任务（“Company X 的 Q3 revenue 是多少？”），精确匹配可以奏效。

LLM 可以标记没有支撑的 claims 和 coverage 缺口，也可以验证开放式综合是否连贯完整。

鉴于 research 质量的主观性，要有效给这些 agents 打分，基于 LLM 的 rubrics 应该频繁与专家人工判断进行校准。

Computer use agents

Computer use agents 不是通过 APIs 或代码执行与软件交互，而是通过与人类相同的界面：截图、鼠标点击、键盘输入和滚动。它们可以使用任何带图形用户界面（GUI）的应用，从设计工具到遗留企业软件都可以。评测需要让 agent 在真实或沙盒环境中运行，使其能够使用软件应用，并检查它是否达到了预期 outcome。

例如，WebArena 测试基于浏览器的任务，使用 URL 和页面状态检查来验证 agent 是否正确导航，并对会修改数据的任务进行后端状态验证（确认订单确实已下单，而不仅仅是出现了确认页面）。

OSWorld 将这一点扩展到完整操作系统控制，评测脚本会在任务完成后检查多种 artifacts：文件系统状态、应用配置、数据库内容和 UI 元素属性。

Browser use agents 需要在 token 效率和延迟之间取得平衡。基于 DOM 的交互执行很快，但会消耗很多 tokens；基于截图的交互较慢，但 token 效率更高。例如，当要求 Claude 总结 Wikipedia 时，从 DOM 中提取文本更高效。当在 Amazon 上寻找新的笔记本电脑包时，截图更高效（因为提取整个 DOM 会消耗大量 tokens）。

在我们的 Claude for Chrome 产品中，我们开发了评测来检查 agent 是否为每个上下文选择了正确工具。这让我们能更快、更准确地完成基于浏览器的任务。

如何看待 agents 评测中的非确定性

无论是哪类 agent，agent 行为都会在不同运行之间变化，这使得评测结果比初看起来更难解释。每个任务都有自己的成功率，可能某个任务是 90%，另一个任务是 50%；某次评测运行中通过的任务，下次可能失败。有时，我们想衡量的是 agent 对某个任务成功的频率，也就是 trials 中有多大比例成功。

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

pass@k 衡量 agent 在 k 次尝试中至少得到一个正确解的可能性。随着 k 增加，pass@k 分数会上升：更多“射门机会”意味着至少成功 1 次的概率更高。pass@1 为 50% 意味着模型在评测中有一半任务能第一次尝试成功。在 coding 中，我们通常最关心 agent 第一次就找到解，也就是 pass@1。在其他情况下，只要其中一个可行，提出多个方案也是有效的。

pass^k 衡量全部 k 次 trials 都成功的概率。随着 k 增加，pass^k 会下降，因为要求更多 trials 都保持一致成功，是更高门槛。如果你的 agent 每次 trial 的成功率是 75%，并运行 3 次 trials，那么全部三次都通过的概率是 (0.75)³ ≈ 42%。这个指标对面向客户的 agents 尤其重要，因为用户期待每次行为都可靠。

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

从零到一：通往优秀 agent 评测的路线图

本节给出我们经过实践检验的建议，帮助你从没有评测走向可信赖的评测。可以把它看作评测驱动的 agent 开发路线图：尽早定义成功，清晰衡量，并持续迭代。

为初始评测数据集收集任务

Step 0. 尽早开始

我们看到一些团队推迟构建评测，因为他们以为需要数百个任务。现实中，从真实失败中抽取 20-50 个简单任务，就是一个很好的起点。毕竟，在 agent 开发早期，系统的每次改动通常都有清晰、明显的影响；这种较大的 effect size 意味着小样本量已经足够。更成熟的 agents 可能需要更大、更困难的评测来检测更小的影响，但一开始最好采取 80/20 方法。越晚开始，评测越难构建。

早期，产品需求会自然转化为 test cases。等得太久，你就会从一个已经上线的系统中反向工程成功标准。

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

先从开发期间会运行的手动检查开始，也就是每次发布前会验证的行为，以及终端用户常尝试的任务。如果你已经在生产环境中，就查看 bug tracker 和支持队列。把用户报告的失败转化为 test cases，能确保你的套件反映真实使用；按用户影响排序，则能帮助你把精力投入到真正重要的地方。

Step 2: 编写没有歧义且带参考解的任务

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

每个任务都应该能被一个正确遵循指令的 agent 完成。这一点可能很微妙。例如，对 Terminal-Bench 的审计显示，如果某个任务要求 agent 写一个脚本，但没有指定 filepath，而测试又假设脚本位于某个特定 filepath，那么 agent 可能会在没有犯错的情况下失败。评分器检查的所有内容都应该能从任务描述中清楚看出；agents 不应该因为 spec 含糊而失败。

对于前沿模型，如果在许多 trials 上通过率都是 0%（即 0% pass@100），这最常见的信号不是 agent 没能力，而是任务本身有问题，也提醒你重新检查任务 spec 和评分器。对每个任务，创建一个参考解也很有用：一个已知可行、能通过所有评分器的输出。这证明任务可解，也验证评分器配置正确。

Step 3: 构建均衡的问题集

既要测试某种行为应该发生的情况，也要测试它不应该发生的情况。单边评测会造成单边优化。例如，如果你只测试 agent 是否在应该搜索时进行了搜索，最终可能得到一个几乎什么都搜索的 agent。尽量避免类别不均衡的评测。我们在为 Claude.ai 构建 web search 评测时亲身学到了这一点。

挑战在于：既要防止模型在不该搜索时搜索，又要保留它在适当情况下进行广泛 research 的能力。团队构建了覆盖两个方向的评测：模型应该搜索的 queries（例如查询天气），以及模型应该基于已有知识回答的 queries（例如“who founded Apple?”）。

在 undertriggering（该搜索时不搜索）和 overtriggering（不该搜索时搜索）之间取得合适平衡很困难，需要多轮改进 prompts 和评测。随着更多示例问题出现，我们会继续加入评测，以提高覆盖率。

设计评测 harness 和评分器

Step 4: 构建带稳定环境的稳健评测 harness

评测中的 agent 与生产中使用的 agent 功能大致一致，并且环境本身不引入额外噪声，这一点至关重要。每次 trial 都应该从干净环境开始，从而实现“隔离”。运行之间不必要的共享状态（遗留文件、缓存数据、资源耗尽）可能因为基础设施不稳定而造成相关性失败，而不是反映 agent 表现。共享状态也可能人为抬高表现。

例如，在一些内部评测中，我们观察到 Claude 通过查看之前 trials 的 git history，在某些任务上获得了不公平优势。如果多个不同 trials 因为环境中的同一个限制（例如 CPU / memory 资源有限）而失败，那么这些 trials 并不独立，因为它们受到同一因素影响，评测结果也就不能可靠衡量 agent 表现。

Step 5: 用心设计评分器

如上所述，优秀的评测设计要为 agent 和任务选择最合适的评分器。我们建议尽可能选择确定性评分器；在必要时或为了额外灵活性使用 LLM 评分器；谨慎使用人工评分器做额外验证。

一种常见直觉是检查 agents 是否按照非常具体的步骤执行，例如工具调用是否以正确顺序发生。我们发现这种方法过于僵硬，会导致测试过分脆弱，因为 agents 经常能找到评测设计者没有预料到的有效方法。为了不无谓惩罚创造性，通常更好的做法是评分 agent 产出了什么，而不是它走了哪条路径。

对于包含多个组成部分的任务，要设计部分得分。一个支持 agent 正确识别了问题并验证了客户，但未能处理退款，仍然明显好于一个立刻失败的 agent。在结果中表示这种成功连续谱很重要。

模型评分通常需要仔细迭代来验证准确性。LLM-as-judge 评分器应当与人类专家密切校准，以确认人工评分和模型评分之间几乎没有分歧。为避免幻觉，要给 LLM 一个退路，例如指示它在信息不足时返回“Unknown”。

为任务的每个维度创建清晰、结构化的 rubrics 也会有帮助；然后用相互隔离的 LLM-as-judge 分别给每个维度评分，而不是用一个 judge 给所有维度评分。系统稳健之后，只需偶尔进行人工审查即可。

有些评测存在细微失败模式，即便 agent 表现良好也会得到低分，因为 agent 是由于评分 bug、agent harness 约束或歧义而未能解题。即使成熟团队也可能漏掉这些问题。

例如，Opus 4.5 最初在 CORE-Bench 上得分为 42%，直到一位 Anthropic 研究员发现多个问题：僵硬的评分会在期待“96.124991…”时惩罚“96.12”，任务 spec 含糊，随机任务无法精确复现。修复 bug 并使用约束更少的 scaffold 后，Opus 4.5 的分数跃升到 95%。

类似地，METR 在他们的 time horizon benchmark 中发现了几个配置错误的任务：这些任务要求 agents 优化到一个明示的分数阈值，但评分却要求超过该阈值。这惩罚了像 Claude 这样遵循指令的模型，而忽略明示目标的模型反而得到更好分数。仔细复查任务和评分器，有助于避免这些问题。

让你的评分器能够抵抗绕过和 hack。Agent 不应能轻易“作弊”通过评测。任务和评分器应当被设计成：通过确实需要解决问题，而不是利用非预期漏洞。

长期维护并使用评测

Step 6: 检查 transcripts

除非你阅读大量 trials 的 transcripts 和分数，否则你不会知道评分器是否工作良好。在 Anthropic，我们投入了用于查看评测 transcripts 的工具，并定期花时间阅读它们。当任务失败时，transcript 会告诉你 agent 是真的犯错，还是你的评分器拒绝了一个有效方案。它也经常暴露 agent 和评测行为中的关键细节。

失败应当显得公平：agent 错在哪里、为什么错，都应该清楚。当分数没有上升时，我们需要确信原因是 agent 表现，而不是评测本身。阅读 transcripts 是验证评测是否真的衡量重要内容的方法，也是 agent 开发的一项关键能力。

Step 7: 监控能力评测饱和

一个达到 100% 的评测可以跟踪回归，但无法提供改进信号。评测饱和发生在 agent 通过了所有可解任务之后，此时没有改进空间。例如，SWE-Bench Verified 今年初的分数为 30%，而前沿模型现在已接近 >80% 的饱和。随着评测接近饱和，进展也会放缓，因为只剩下最困难的任务。这可能让结果具有迷惑性，因为大的能力提升看起来只是分数的小幅增长。

例如，code review startup Qodo 起初对 Opus 4.5 印象不深，因为他们的 one-shot coding 评测没有捕捉到模型在更长、更复杂任务上的提升。作为回应，他们开发了一个新的 agentic 评测框架，更清楚地呈现了进展。

通常，在有人深入评测细节并阅读一些 transcripts 之前，我们不会按表面值接受评测分数。如果评分不公平、任务含糊、有效解被惩罚，或 harness 限制了模型，就应该修订评测。

Step 8: 通过开放贡献和维护，长期保持评测套件健康

评测套件是一个活的 artifact，需要持续关注和清晰 ownership 才能保持有用。

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

对 AI 产品团队来说，拥有并迭代评测，应当像维护单元测试一样日常化。团队可能会在早期测试中看似“有效”的 AI 功能上浪费数周，但这些功能后来无法满足未明说的预期；而设计良好的评测本可以更早暴露这些问题。定义评测任务，是压力测试产品需求是否足够具体、是否可以开始构建的最佳方式之一。

我们建议实践评测驱动开发：在 agents 具备对应能力之前，先构建评测来定义计划中的能力，然后迭代直到 agent 表现良好。在内部，我们经常构建一些今天“足够好”、但其实押注于模型几个月后能力的功能。以低通过率起步的能力评测会让这种押注可见。当新模型发布时，快速运行套件就能看出哪些押注兑现了。

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

评测如何与其他方法配合，形成对 agents 的整体理解

自动化评测可以在数千个任务上运行 agent，而无需部署到生产环境，也不会影响真实用户。但这只是理解 agent 表现的众多方式之一。完整图景包括生产监控、用户反馈、A/B testing、人工 transcript 审查，以及系统化人工评测。

理解 AI agent 表现的方法概览

这些方法对应 agent 开发的不同阶段。自动化评测在发布前和 CI/CD 中尤其有用，可以在每次 agent 改动和模型升级时运行，作为防御质量问题的第一道防线。生产监控在发布后发挥作用，用于检测分布漂移和意料之外的真实世界失败。A/B testing 在你拥有足够流量后验证重大改动。

用户反馈和 transcript 审查是持续实践，用来填补空白：持续 triage 反馈，每周抽样阅读 transcripts，并在需要时深挖。系统化人工研究则应保留给校准 LLM 评分器，或评估那些以人类共识作为参考标准的主观输出。

最有效的团队会组合这些方法：用自动化评测快速迭代，用生产监控获得 ground truth，并定期用人工审查做校准。

结论

没有评测的团队会陷入被动循环：修复一个失败，制造另一个失败，无法区分真实退化和噪声。早期投入评测的团队则会看到相反结果：失败会变成 test cases，test cases 防止回归，指标取代猜测，开发速度因此加快。评测给整个团队一个清晰的改进目标，把“agent 感觉变差了”变成可以行动的问题。价值会持续复利，但前提是你把评测视为核心组件，而不是事后补充。

不同 agent 类型的模式会有所不同，但本文描述的基本原则是不变的。尽早开始，不要等待完美套件。从你看到的失败中提取真实任务。定义无歧义、稳健的成功标准。用心设计评分器，并组合多种类型。确保问题对模型来说足够难。迭代评测，提高它们的 signal-to-noise ratio。阅读 transcripts！

AI agent 评测仍是一个新兴且快速演化的领域。随着 agents 承担更长任务，在 multi-agent systems 中协作，并处理越来越主观的工作，我们需要调整技术。随着我们学到更多，我们会继续分享最佳实践。

致谢

本文由 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 专为在容器化环境中运行 agents 而设计，提供基础设施以跨云服务商规模化运行 trials，并提供定义任务和评分器的标准化格式。Terminal-Bench 2.0 等流行基准通过 Harbor registry 发布，使团队可以轻松运行成熟基准和自定义评测套件。

Braintrust 是一个平台，结合了离线评测、生产可观测性和实验跟踪，适合既需要在开发期间迭代、又需要在生产中监控质量的团队。它的 autoevals library 包含事实性、相关性和其他常见维度的预构建 scorers。

LangSmith 提供 tracing、离线与在线评测，以及数据集管理，并与 LangChain 生态紧密集成。Langfuse 提供类似能力，是一种可自托管的开源替代方案，适合有数据驻留要求的团队。

Arize 提供 Phoenix，这是一个用于 LLM tracing、debugging 以及离线或在线评测的开源平台；还提供 AX，这是一个 SaaS 产品，在 Phoenix 基础上扩展了规模化、优化和监控能力。

许多团队会组合多个工具，自行构建评测框架，或者先用简单评测脚本起步。我们发现，框架可以成为加速进展和标准化的有价值方式，但它们的效果取决于你通过它们运行的评测任务质量。通常最好的做法是快速选择一个适合你 workflow 的框架，然后把精力投入评测本身：持续迭代高质量 test cases 和评分器。