解密 Agent 评测：Anthropic 工程团队的八步路线图

解密 AI Agent 评测

发布于 2026 年 1 月 9 日

让 agent 变得有用的那些能力，同样让它们难以评测。在各种部署中行之有效的策略，是把多种技术组合起来，以匹配被测系统的复杂度。

引言

好的评测帮助团队更有信心地交付 AI agent。没有评测，团队很容易陷入被动循环——只在生产环境中发现问题，而修复一个失败又制造出别的失败。评测让问题与行为变化在影响用户之前变得可见，其价值会在 agent 的整个生命周期中复利累积。

正如我们在《Building effective agents》中所述，agent 在多轮中运行：调用工具、修改状态，并基于中间结果进行调整。这些让 AI agent 变得有用的能力——自主性、智能与灵活性——同样让它们更难评测。

通过我们的内部工作以及与处于 agent 开发前沿的客户合作，我们学会了如何为 agent 设计更严格、更有用的评测。以下是在真实部署中、跨多种 agent 架构与用例行之有效的做法。

一次评测的结构

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

单轮评测很直接：一个提示、一个响应、一段评分逻辑。对早期 LLM 而言，单轮、非 agentic 的评测是主要评测方法。随着 AI 能力的进步，多轮评测变得日益普遍。

在一个简单评测中，agent 处理一个提示，评审器（grader）检查输出是否符合预期。在更复杂的多轮评测中，一个编码 agent 接收工具、一个任务（本例中是构建一个 MCP server）与一个环境，执行一个「agent 循环」（工具调用与推理），并用实现更新环境。然后评分使用单元测试验证这个可工作的 MCP server。

Agent 评测更加复杂。agent 在多轮中使用工具，修改环境中的状态并随之调整——这意味着错误可以传播并复合。前沿模型还可能找到超越静态评测极限的创造性解法。例如，Opus 4.5 在解决一个关于预订航班的 τ2-bench 问题时，发现了政策中的一个漏洞。按评测原文它「失败」了，但实际上它为用户想出了一个更好的解法。

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

• 一个任务（task，又称问题 problem 或测试用例 test case）是一个具有确定输入与成功标准的单项测试。
• 对任务的一次尝试是一次试验（trial）。因为模型输出在多次运行之间会变化，我们运行多次试验以产生更一致的结果。
• 一个评审器（grader）是对 agent 表现的某个方面打分的逻辑。一个任务可以有多个评审器，每个评审器包含多个断言（有时称为检查 checks）。
• 一份转录（transcript，也称轨迹 trace 或 trajectory）是一次试验的完整记录，包括输出、工具调用、推理、中间结果与任何其他交互。对 Anthropic API 而言，这是评测运行结束时的完整 messages 数组——包含评测期间对 API 的全部调用与全部返回的响应。
• 结局（outcome）是试验结束时环境中的最终状态。一个订机票的 agent 可能在转录末尾说「您的航班已预订」，但结局是环境的 SQL 数据库中是否存在一条预订记录。
• 一个评测 harness（evaluation harness）是端到端运行评测的基础设施。它提供指令与工具、并发运行任务、记录所有步骤、为输出打分并聚合结果。
• 一个 agent harness（或脚手架 scaffold）是让模型能够作为 agent 行动的系统：它处理输入、编排工具调用并返回结果。当我们评测「一个 agent」时，我们评测的是 harness _与_模型的协同工作。例如，Claude Code 是一个灵活的 agent harness，我们通过 Agent SDK 使用它的核心原语构建了我们的长时运行 agent harness。
• 一个评测套件（evaluation suite）是为测量特定能力或行为而设计的任务集合。套件中的任务通常共享一个宽泛目标。例如，一个客服评测套件可能测试退款、取消与升级。

Agent 评测的各组件。

为什么要构建评测？

团队刚开始构建 agent 时，靠手动测试、吃自己狗粮（dogfooding）与直觉的组合，可以走出惊人的距离。更严格的评测甚至看起来像是拖慢交付的额外开销。但在早期原型阶段之后，一旦 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

我们看到今天有若干类常见的 agent 被大规模部署，包括编码 agent、研究 agent、计算机使用 agent 与对话 agent。每一类都可能部署在多种行业，但可以用相似的技术评测。你不需要从零发明一套评测。下文描述针对几类 agent 的成熟技术。把这些方法当作基础，再扩展到你的领域。

Agent 评审器的类型

Agent 评测通常组合三类评审器：基于代码的、基于模型的和人工的。每个评审器评估转录或结局的某一部分。有效评测设计的一个关键组件，是为工作选对评审器。

基于代码的评审器

基于模型的评审器

人工评审器

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

能力评测 vs 回归评测

能力或「质量」评测问的是：「这个 agent 能把什么做好？」它们应以较低的通过率起步，瞄准 agent 吃力的任务，给团队一座可以攀登的山。

回归评测问的是：「agent 还能处理它以前能处理的所有任务吗？」通过率应接近 100%。它们防止倒退，因为分数下降意味着有东西坏了、需要改进。当团队在能力评测上爬坡时，同样重要的是运行回归评测，确保变更不会在别处引发问题。

agent 上线并优化之后，通过率已高的能力评测可以「毕业」成为持续运行的回归套件，以捕捉任何漂移。曾经测量「我们到底能不能做到？」的任务，转而测量「我们还能可靠地做到吗？」

评测编码 Agent

编码 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

对话 agent 在客服、销售、辅导等领域与用户交互。与传统聊天机器人不同，它们维持状态、使用工具，并在对话中途采取行动。虽然编码 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

研究 agent 收集、综合并分析信息，然后产出答案或报告等输出。与单元测试提供二元通过/失败信号的编码 agent 不同，研究质量只能相对于任务来评判。什么算「全面」、「来源可靠」甚至「正确」取决于语境：市场扫描、收购尽调与科学报告各自要求不同的标准。

研究评测面临独特挑战：专家可能对一次综合是否全面意见不一；真值随参考内容不断变化而漂移；更长、更开放的输出为错误创造了更多空间。例如 BrowseComp 这样的基准，测试 AI agent 能否在开放网络中大海捞针——这些问题被设计为易于验证但难以解决。

构建研究 agent 评测的一种策略是组合评审器类型。锚定性检查验证主张是否被检索到的来源支持；覆盖检查定义好答案必须包含的关键事实；来源质量检查确认所查来源是权威的，而非仅仅是最先检索到的。对客观上有正确答案的任务（「X 公司第三季度营收是多少？」），精确匹配即可。LLM 可以标记无依据的主张与覆盖缺口，也可以验证开放式综合的连贯性与完整性。

鉴于研究质量的主观性，基于 LLM 的评分细则应经常对照专家人工判断进行校准，才能有效地为这些 agent 打分。

计算机使用 Agent

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

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

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

无论 agent 类型如何，agent 行为在多次运行之间会变化，这使评测结果比表面看起来更难解读。每个任务有自己的成功率——也许一个任务 90%、另一个 50%——一次评测运行中通过的任务，下一次可能失败。有时，我们想测量的是 agent 在一个任务上成功的_频率_（试验中的占比）。

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

pass@k 测量 agent 在 _k_ 次尝试中获得至少一个正确解法的可能性。随着 _k_ 增大，pass@k 分数上升：更多「射门机会」意味着至少一次成功的概率更高。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，对一致性至关重要的 agent 用 pass^k。

从零到一：打造优秀 Agent 评测的路线图

本节给出我们从无评测到拥有可信赖评测的实用、经实战检验的建议。把它当作评测驱动的 agent 开发路线图：尽早定义成功、清晰地度量它、持续迭代。

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

第 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 的网页搜索构建评测时亲身体会到这一点。挑战在于防止模型在不该搜索时搜索，同时保留它在适当时做大量调研的能力。团队构建了覆盖两个方向的评测：模型应该搜索的查询（比如查天气）与应该用既有知识回答的查询（比如「谁创立了 Apple？」）。在触发不足（该搜索时不搜索）与触发过度（不该搜索时搜索）之间取得正确平衡很困难，对提示词与评测都经过多轮打磨。随着更多示例问题出现，我们持续为评测添加内容以改进覆盖。

设计评测 Harness 与评审器

第 4 步：构建带稳定环境的健壮评测 harness

至关重要的是，评测中的 agent 与生产中使用的 agent 运行方式大体相同，且环境本身不引入进一步噪声。每次试验都应通过从干净环境启动来「隔离」。运行之间不必要的共享状态（残留文件、缓存数据、资源耗尽）可能因基础设施抖动而非 agent 性能导致相关性失败。共享状态还可能人为抬高表现。例如，在一些内部评测中，我们观察到 Claude 通过查看先前试验的 git 历史在某些任务上获得不公平优势。如果多个不同试验因环境的同一局限（如 CPU 内存有限）而失败，这些试验不是独立的，因为它们受同一因素影响，评测结果对度量 agent 性能变得不可靠。

第 5 步：用心设计评审器

如上所述，优秀的评测设计涉及为 agent 与任务选择最佳评审器。我们建议尽可能选择确定性评审器，在必要处或为额外灵活性使用 LLM 评审器，并有节制地使用人工评审器做额外验证。

一个常见直觉是检查 agent 是否遵循了非常具体的步骤，比如按正确顺序的一串工具调用。我们发现这种方法过于僵硬，导致测试过度脆弱，因为 agent 经常找到评测设计者没有预料到的有效路径。为了不无谓地惩罚创造性，通常更好的做法是给 agent 产出的东西打分，而不是它走的路径。

对多组件任务，内置部分得分。一个正确识别问题并验证客户身份、但未能处理退款的客服 agent，明显好于一个立即失败的 agent。在结果中呈现这种成功的连续谱很重要。

模型评分往往需要仔细迭代以验证准确性。LLM-as-judge 评审器应与人类专家紧密校准，以获得人工评分与模型评分之间分歧很小的信心。为避免幻觉，给 LLM 一条出路，比如提供一条指令：当信息不足时返回「Unknown」。创建清晰、结构化的评分细则来给任务的每个维度打分也有帮助，然后用各自隔离的 LLM-as-judge 给每个维度打分，而不是用一个评审所有维度。系统健壮之后，只需偶尔使用人工评审即可。

有些评测存在微妙的失败模式，即使 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 不应能轻易「作弊」通过评测。任务与评审器的设计应使通过真正需要解决问题，而不是利用无意的漏洞。

长期维护并使用评测

第 6 步：查看转录

除非你阅读许多试验的转录与评分，否则你不会知道评审器工作得好不好。在 Anthropic，我们投资了查看评测转录的工具，并定期花时间阅读它们。当一个任务失败时，转录会告诉你：是 agent 犯了真正的错误，还是你的评审器拒绝了一个有效解法。它还常常揭示关于 agent 与评测行为的关键细节。

失败应该看起来公平：清楚 agent 错在哪里、为什么错。当分数不再上升时，我们需要有信心这是 agent 性能所致而非评测所致。阅读转录是你验证评测确实在测量真正重要之事的方式，也是 agent 开发的一项关键技能。

第 7 步：监控能力评测的饱和

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

作为一项规则，在有人深挖评测细节并阅读一些转录之前，我们不轻信评测分数。如果评分不公平、任务有歧义、有效解法被惩罚，或 harness 约束了模型，评测就应被修订。

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

一个评测套件是一个活的产物，需要持续的关注与清晰的归属才能保持有用。

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

对 AI 产品团队，拥有并迭代评测应当像维护单元测试一样例行。团队可能在「早期测试中能工作」的 AI 功能上浪费数周，却达不到一个设计良好的评测本可以早早暴露的未言明期望。定义评测任务是压力测试产品需求是否具体到可以开工的最佳方式之一。

我们建议实践评测驱动开发：在 agent 尚不能实现规划能力之前就构建评测来定义它们，然后迭代直到 agent 表现良好。在内部，我们经常构建今天「足够好」、但押注模型几个月后能力的功能。从低通过率起步的能力评测让这一点变得可见。当新模型发布时，运行套件能快速揭示哪些押注得到了回报。

离产品需求与用户最近的人最有条件定义成功。以当前的模型能力，产品经理、客户成功经理或销售人员可以用 Claude Code 以 PR 形式贡献一个评测任务——让他们做吧！或者更好的是，积极赋能他们。

_创建一个有效评测的过程。_

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

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

理解 AI agent 性能的方法总览

这些方法对应 agent 开发的不同阶段。自动化评测在发布前与 CI/CD 中尤其有用，在每次 agent 变更与模型升级时运行，作为质量问题的第一道防线。生产监控在发布后接手，检测分布漂移与未预料的真实世界失败。A/B 测试在流量足够时验证重大变更。用户反馈与转录审阅是填补空白的持续实践：不断分诊反馈、每周抽样阅读转录，并按需深挖。把系统化人工研究留给校准 LLM 评审器，或评估以人类共识为参照标准的主观输出。

与安全工程中的瑞士奶酪模型一样，没有单一评测层能捕捉每个问题。多种方法组合后，从一层漏过的失败会被另一层接住。

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

结论

没有评测的团队会陷入被动循环——修复一个失败、制造另一个，无法区分真实退化与噪声。尽早投入的团队发现恰恰相反：随着失败变成测试用例、测试用例防止回归、指标取代猜测，开发加速了。评测给整个团队一座清晰可攀的山，把「agent 感觉变差了」变成可行动的东西。价值会复利累积，但前提是你把评测当作核心组件，而非事后补充。

模式因 agent 类型而异，但这里描述的基本功是不变的。尽早开始，不要等完美的套件。从你看到的失败中取材真实任务。定义无歧义、健壮的成功标准。用心设计评审器并组合多种类型。确保问题对模型足够难。迭代评测以改进其信噪比。阅读转录！

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 registry 发布，使你很容易在自定义评测套件之外运行成熟基准。

Braintrust 是一个把离线评测与生产可观测性、实验追踪结合起来的平台——对需要在开发期间迭代、又要在生产中监控质量的团队很有用。它的 autoevals 库包含针对事实性、相关性及其他常见维度的预置评分器。

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

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

许多团队组合多个工具、自研评测框架，或干脆从简单的评测脚本起步。我们发现，框架虽然是加速进步与标准化的宝贵方式，但它们的价值取决于你通过它们运行的评测任务。通常最好的做法是快速选一个适合你工作流的框架，然后把精力投入到评测本身——迭代高质量的测试用例与评审器。