CS329Z中文学习站
首页 / 第8周 · LLM-as-Judge

"解构 AI Agent 评测"

"Demystifying evals for AI agents"

"Mikaela Grace, Jeremy Hadfield, Rodrigo Olivares, Jiri De Jonghe(Anthropic)" · "Anthropic Engineering Blog · 2026-01-09"

必读全文中译查看原文(HTML) ↗

导读

如果说 Zheng et al. (2023) 奠定了「用 LLM 评审 LLM」的学术范式,这篇 Anthropic 工程博客则回答了工业界落地的问题:真实的 Agent 产品团队到底应该怎么搭评测?文章价值在于三点:第一,给出一套精确的评测词汇表(task/trial/grader/transcript/outcome/eval harness/agent harness/eval suite),这是团队沟通的基础设施;第二,把评分器系统分为代码型、模型型、人类三类并给出选型建议,与本周论文的 LLM-as-Judge 直接呼应;第三,给出从零到一的八步路线图(尽早开始、20-50 个任务起步、写无歧义任务、平衡正反例、读轨迹、监控饱和),每一步都来自 Claude Code、Claude for Chrome 等一线产品的真实教训(如 Opus 4.5 在 CORE-Bench 上因评分 bug 从 42% 跳到 95%)。对要动手做课程项目评测的同学,这是本周最实用的一份材料。

全文中译

原文:Demystifying evals for AI agents · Anthropic Engineering,2026 年 1 月 9 日发布。

让 Agent 变得有用的那些能力,也让它们变得难以评测。在各类部署场景中都行之有效的策略,是通过组合多种技术来匹配被测系统的复杂度。

引言

好的评测(evaluation)能帮助团队更自信地发布 AI Agent。没有评测,团队很容易陷入被动循环——只能在线上环境中发现问题,而修复一个失败又引入新的失败。评测让问题与行为变化在影响用户之前就可见,其价值会在 Agent 的整个生命周期中不断复利累积。

正如我们在《Building effective agents》中所描述的,Agent 的运行跨越许多轮次:调用工具、修改状态、并根据中间结果进行调整。正是这些让 AI Agent 变得有用的能力——自主性、智能与灵活性——也让它们更难评测。

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

评测的结构

一次评测(eval)是对 AI 系统的一次测试:给 AI 一个输入,然后对其输出应用评分逻辑(grading logic)来度量成功与否。本文聚焦于可以在开发阶段运行、无需真实用户的自动化评测。

单轮评测(single-turn evaluations)很直接:一个提示、一个回答、一段评分逻辑。对于早期的 LLM,单轮、非 Agent 的评测是主要的评测方法。随着 AI 能力的进步,多轮评测(multi-turn evaluations)日益普遍。

在一个简单的评测中,Agent 处理一个提示,评分器(grader)检查输出是否符合预期。而在更复杂的多轮评测中,一个编码 Agent 会获得工具、任务(此处是构建一个 MCP 服务器)和环境,执行「Agent 循环」(工具调用与推理),并用实现结果更新环境;评分再用单元测试来验证 MCP 服务器是否可用。

图:Agent 评测的各个组成部分。

Agent 评测则更加复杂。Agent 跨越多轮使用工具,在环境中修改状态并随之调整——这意味着错误会传播并复合。前沿模型还可能找到超越静态评测边界的创造性解法。例如,Opus 4.5 在求解一道关于订机票的 τ²-bench 问题时,发现了一个策略上的漏洞。按题目字面它「未通过」评测,但实际上它为用户想出了一个更好的解法。

在构建 Agent 评测时,我们使用以下定义:

  • 任务(task)(又称 problem 或 test case)是单个测试,有明确的输入与成功标准。
  • 对一项任务的每次尝试称为一次试验(trial)。由于模型输出在多次运行之间会有差异,我们会运行多次试验以得到更一致的结果。
  • 评分器(grader)是对 Agent 表现的某个方面进行打分的逻辑。一个任务可以有多个评分器,每个评分器又包含多条断言(assertion,有时也称检查(check))。
  • 轨迹(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 时,靠手动测试、内部试用(dogfooding)和直觉的组合,往往能走得出乎意料地远。更严谨的评测甚至可能显得像拖慢发布节奏的开销。但在早期原型阶段之后,一旦 Agent 上线并开始规模化,没有评测的开发就会开始崩塌。

崩塌点常常出现在用户反馈 Agent 在某次改动后「变差了」,而团队只能「盲飞」,除了猜和试没有任何验证手段。没有评测,调试是被动的:等投诉、手动复现、修 bug、祈祷没有别的地方退化。团队无法区分真正的回归与噪声,无法在发布前针对数百个场景自动测试改动,也无法度量改进。

我们多次目睹这一进程。例如 Claude Code 起初依靠 Anthropic 员工与外部用户的反馈快速迭代;后来我们加入了评测——先是针对简洁度、文件编辑等窄域,再扩展到过度工程(over-engineering)等更复杂的行为。这些评测帮助定位问题、指导改进并聚焦研究-产品协作。结合生产监控、A/B 测试、用户研究等手段,评测为 Claude Code 在规模化过程中持续改进提供了信号。

在 Agent 生命周期的任何阶段写评测都有用。早期,评测迫使产品团队明确「成功」对 Agent 意味着什么;后期,评测帮助维持一致的质量底线。

Descript 的 Agent 帮用户剪辑视频,他们围绕成功剪辑工作流的三个维度构建评测:别搞坏东西、按我说的做、把它做好。他们从手动评分演进到由产品团队定义标准、辅以周期性人工校准的 LLM 评分器,如今定期运行质量基准与回归测试两套独立套件。Bolt 的 AI 团队起步较晚,在 Agent 已被广泛使用后才开始。三个月内,他们搭起了一套评测系统:运行 Agent 并用静态分析评分输出、用浏览器 Agent 测试应用、用 LLM 评审评估指令遵循等行为。

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

评测还决定你多快能采用新模型。更强的模型发布时,没有评测的团队要面对数周的测试,而有评测的竞品可以快速判断模型的强项、调整提示、几天内完成升级。

一旦有了评测,你就免费获得了基线与回归测试:延迟、token 用量、单任务成本、错误率都可以在一组静态任务上跟踪。评测还可以成为产品团队与研究团队之间带宽最高的沟通渠道,定义研究者可以针对性优化的指标。显然,评测的价值远超跟踪回归与改进。其复利效应容易被低估——成本在前、收益在后。

如何评测 AI Agent

我们看到当前大规模部署的常见 Agent 类型包括编码 Agent、研究 Agent、计算机使用 Agent 与对话式 Agent。每种类型都可能部署在各类行业,但可以用相似的技术评测。你不需要从零发明评测。下面几节描述了针对若干 Agent 类型的、经过验证的技术。以这些方法为基础,再扩展到你的领域。

Agent 评分器的类型

Agent 评测通常组合三类评分器:代码型、模型型与人类。每个评分器评估轨迹或结局的一部分。有效评测设计的核心一环,是为任务选择合适的评分器。

代码型评分器(code-based graders)

  • 方法:字符串匹配检查(精确、正则、模糊等);二元测试(fail-to-pass、pass-to-pass);静态分析(lint、类型、安全);结局验证;工具调用验证(用了哪些工具、参数);轨迹分析(轮次数、token 用量)。
  • 优点:快、便宜、客观、可复现、易调试、能验证特定条件。
  • 缺点:对不精确匹配预期模式的合法变体很脆弱;缺乏细微分辨力;对部分更主观的任务能力有限。

模型型评分器(model-based graders)

  • 方法:基于量表的打分(rubric-based scoring)、自然语言断言、成对比较、基于参考答案的评测、多评审共识。
  • 优点:灵活、可扩展、能捕捉细微差异、能处理开放式任务与自由格式输出。
  • 缺点:非确定性;比代码贵;需要与人类评分器校准才能保证准确性。

人类评分器(human graders)

  • 方法:领域专家(SME)评审、众包判断、抽样抽查、A/B 测试、标注者间一致性。
  • 优点:金标准质量;匹配专家级用户判断;用于校准模型型评分器。
  • 缺点:贵、慢;常需要大规模获取人类专家。

对每个任务,打分可以是加权式(多个评分器得分组合后须达到阈值)、二元式(所有评分器必须通过)或混合式。

能力评测 vs 回归评测

能力评测(或「质量」评测)问的是:「这个 Agent 擅长做什么?」它们应从较低的通过率起步,瞄准 Agent 还做不好的任务,给团队一座可攀登的山。

回归评测(regression evals)问的是:「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 所示,可以用多种评分器与指标来评测:

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 中就采用这一方式,通过长时间的对抗性对话对模型做压力测试。

对话式 Agent 的成功是多维的:工单是否解决(状态检查)、是否在 10 轮内完成(轨迹约束)、语气是否得体(LLM 量表)?纳入多维度的两个基准是 τ-Bench 及其继任者 τ²-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 的单元测试提供二元通过/失败信号不同,研究质量只能相对于任务来判断。什么算「全面」「来源扎实」甚至「正确」,都取决于语境:市场扫描、并购尽调与科学报告各自需要不同的标准。

研究评测面临独特挑战:专家之间可能对一份综述是否全面意见不一;参考内容不断变化导致真值(ground truth)漂移;更长、更开放的输出留下更多出错空间。例如 BrowseComp 这类基准测试 AI Agent 能否在开放网络的大海里捞针——题目设计得易于验证但难以求解。

构建研究 Agent 评测的一种策略是组合评分器:接地性检查(groundedness checks)验证论断是否有检索到的来源支撑;覆盖度检查定义好答案必须包含的关键事实;来源质量检查确认所参考的来源是权威的,而不只是排最前面的检索结果。对有客观正确答案的任务(「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 上升:「射门次数」越多,至少命中一次的概率越高。pass@1 为 50% 意味着模型首次尝试就能完成评测中一半的任务。在编码领域,我们通常最关心 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 不行,是复查任务规范与评分器的信号。为每个任务创建参考解(reference solution)也很有用:一个已知可通过全部评分器的有效输出。这证明任务可解,并验证评分器配置正确。

第 3 步:构建平衡的问题集。 既测试行为应当发生的场景,也测试不应发生的场景。单边的评测造成单边的优化。例如只测 Agent 该搜索时是否搜索,可能得到一个几乎事事都搜索的 Agent。尽量避免类别失衡的评测。我们在为 Claude.ai 的网页搜索构建评测时对此有切身体会:难点在于既防止模型在不该搜索时搜索,又保留其在适当时深入调研的能力。团队构建了双向评测:应该搜索的查询(如查天气)与应凭既有知识回答的查询(如「苹果公司是谁创立的?」)。在欠触发(该搜不搜)与过触发(不该搜乱搜)之间找到平衡很困难,提示与评测都经过多轮打磨。随着新问题出现,我们持续向评测补充以提高覆盖。

设计评测 harness 与评分器

第 4 步:构建带稳定环境的健壮评测 harness。 至关重要的是:评测中的 Agent 与生产中的 Agent 大致一致,且环境本身不引入额外噪声。每次试验都应从干净环境开始以实现「隔离」。运行之间不必要的共享状态(遗留文件、缓存数据、资源耗尽)可能因基础设施抖动而非 Agent 表现导致相关的失败。共享状态也可能虚增性能。例如在一些内部评测中,我们观察到 Claude 通过查看先前试验的 git 历史在某些任务上获得不公平优势。若多个试验因环境的同一限制(如 CPU 内存不足)而失败,这些试验就不是独立的,评测结果对度量 Agent 表现而言不可靠。

第 5 步:用心设计评分器。 如上所述,优秀的评测设计在于为 Agent 与任务选择最合适的评分器。我们建议:尽可能选确定性评分器,必要时或需要灵活性时用 LLM 评分器,人类评分器则审慎地用于额外验证。

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

对包含多个组件的任务,要内建部分得分(partial credit)。一个正确识别问题并验证了客户身份但没处理退款的客服 Agent,明显好于一个立刻失败的 Agent。在结果中呈现这种成功的连续谱很重要。

模型评分往往需要仔细迭代才能验证准确性。LLM-as-Judge 评分器应与人类专家紧密校准,确信人类评分与模型评分分歧不大。为避免幻觉,给 LLM 留退路,比如指示它在信息不足时返回「Unknown」。为每个维度创建清晰、结构化的量表,再用相互隔离的 LLM-as-Judge 分别评每个维度(而非用一个评所有维度),也会有帮助。系统稳健之后,只需偶尔人工复核即可。

有些评测存在微妙的失败模式,即使 Agent 表现良好也得低分——因为评分 bug、harness 约束或任务歧义导致 Agent 无法解题。即使老练的团队也会漏掉这些问题。例如 Opus 4.5 起初在 CORE-Bench 上只得 42%,直到一位 Anthropic 研究员发现多个问题:僵硬的评分在期望「96.124991…」时惩罚了「96.12」、含糊的任务规范、以及无法精确复现的随机任务。修复 bug 并改用约束更少的 scaffold 后,Opus 4.5 的分数跳到 95%。类似地,METR 在其时间视界(time horizon)基准中发现若干配置错误的任务:任务要求 Agent 优化到给定的分数阈值,评分却要求超过该阈值。这惩罚了像 Claude 这样遵循指令的模型,而无视既定目标的模型反而得分更高。仔细复查任务与评分器有助于避免这些问题。

让你的评分器能抵御绕过与作弊。Agent 不应能轻易「骗过」评测。任务与评分器应设计成:通过评测必须真正解决问题,而不是钻 unintended 的空子。

长期维护和使用评测

第 6 步:检查轨迹。 不阅读多次试验的轨迹与评分,你就不知道评分器是否工作良好。在 Anthropic,我们投资了查看评测轨迹的工具,并定期抽时间阅读。任务失败时,轨迹会告诉你:是 Agent 真的犯了错,还是你的评分器否决了有效解。它还常常浮出 Agent 与评测行为的关键细节。

失败应当看起来公平:Agent 错在哪、为什么,应当一目了然。分数爬不上去时,我们需要确信原因在 Agent 而非评测。读轨迹是验证「评测度量的是真正重要的东西」的手段,也是 Agent 开发的关键技能。

第 7 步:监控能力评测饱和。 100% 的评测只能跟踪回归,对改进毫无信号。评测饱和(eval saturation)发生在 Agent 通过了全部可解任务、没有提升空间之时。例如 SWE-Bench Verified 今年初分数为 30%,前沿模型现已接近饱和的 80% 以上。评测接近饱和时进展也会放缓,因为只剩最难的任务。这会让结果具有欺骗性——大幅的能力提升只表现为分数的小幅上涨。例如代码评审创业公司 Qodo 起初对 Opus 4.5 印象平平,因为他们的单次(one-shot)编码评测没有捕捉到模型在更长更复杂任务上的提升。作为回应,他们开发了新的 Agent 化评测框架,从而获得了清晰得多的进展图景。

作为惯例,在有人深入评测细节、读过一些轨迹之前,我们不把评测分数当真。若评分不公、任务含糊、有效解被惩罚、或 harness 束缚了模型,评测就应当修订。

第 8 步:通过开放贡献与维护,保持评测套件长期健康。 评测套件是需要持续关注与明确归属的活的工件。

在 Anthropic,我们试验过多种评测维护方式。最有效的是:设立专门的评测团队负责核心基础设施,而由领域专家与产品团队贡献大部分评测任务并自行运行评测。

对 AI 产品团队而言,拥有并迭代评测应当像维护单元测试一样常规。团队可能在「早期测试中能用」的 AI 特性上浪费数周,而一个设计良好的评测本可提前暴露那些未被言明的期望。定义评测任务是对「产品需求是否具体到可以开工」进行压力测试的最佳方式之一。

我们推荐实践评测驱动开发:在 Agent 尚不能满足计划中的能力之前,先建好评测来定义它们,然后迭代直到 Agent 表现良好。在内部,我们经常构建今天「够用」的功能,但它们是对未来几个月模型能力的押注。从低通过率起步的能力评测让这些押注可见。新模型发布时,跑一遍套件就能迅速 reveal 哪些押注成功了。

最贴近产品需求与用户的人,最适合定义成功。以当前的模型能力,产品经理、客户成功经理或销售都可以用 Claude Code 以 PR 形式贡献评测任务——随他们去!或者更好:主动为他们赋能。

图:创建有效评测的流程。

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

自动化评测可以在不部署到生产、不影响真实用户的前提下,对 Agent 跑成千上万个任务。但这只是理解 Agent 表现的众多方式之一。完整的图景包括:生产监控、用户反馈、A/B 测试、手动轨迹评审与系统性人类研究。

方法 做法 优点 缺点
自动化评测 无需真实用户、程序化运行测试 迭代更快;完全可复现;不影响用户;可在每次提交时运行;无需生产部署即可大规模测试场景 前期投入更大;需随产品与模型演进持续维护以避免漂移;若与真实使用模式不符会造成虚假信心
生产监控 在线上系统中跟踪指标与错误 大规模揭示真实用户行为;捕捉合成评测遗漏的问题;提供 Agent 真实表现的真值 被动;问题到达用户后才发现;信号可能嘈杂;需要在埋点上投入;缺乏用于评分的真值
A/B 测试 用真实用户流量对比变体 度量真实用户结果(留存、任务完成);控制混淆因素;可扩展且系统化 慢;需数天到数周才能显著且需要足够流量;只测试你部署的改动;不细看轨迹就难以获知指标变化的「为什么」
用户反馈 点踩、bug 报告等显式信号 浮现你未预料的问题;自带真实用户实例;反馈常与产品目标相关 稀疏且自选择;偏向严重问题;用户很少解释为什么失败;非自动化;主要依赖用户发现问题可能造成负面用户体验
手动轨迹评审 人类通读 Agent 对话 建立对失败模式的直觉;捕捉自动化检查遗漏的细微质量问题;帮助校准「好」的样子并把握细节 耗时;不可扩展;覆盖不一致;评审疲劳或评审者差异会影响信号质量;通常只给定性信号而非清晰定量评分
系统性人类研究 受训评分者对 Agent 输出做结构化评分 多人评分的金标准质量判断;处理主观或含糊任务;为改进模型型评分器提供信号 相对昂贵、周转慢;难以高频运行;评分者分歧需要仲裁;复杂领域(法律、金融、医疗)需要人类专家执行

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

就像安全工程中的瑞士奶酪模型(Swiss Cheese Model),没有哪一层评测能抓住所有问题。多种方法组合时,穿过一层的失败会被另一层拦住。最有效的团队组合这些方法:自动化评测换快速迭代,生产监控给真值,周期性人工评审做校准。

结论

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

模式因 Agent 类型而异,但本文的基本功是恒定的:尽早开始,别等完美套件;从你看到的失败中提取真实任务;定义无歧义、稳健的成功标准;用心设计评分器并组合多种类型;确保题目对模型足够难;迭代评测以提高信噪比。去读轨迹!(Read the 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 类型、现有技术栈,以及你需要离线评测、生产可观测性还是两者兼有。

Harbor 面向在容器化环境中运行 Agent,提供跨云厂商大规模运行试验的基础设施,以及定义任务与评分器的标准化格式。Terminal-Bench 2.0 等流行基准通过 Harbor registry 发布,便于将既有基准与自定义评测套件一起运行。

Braintrust 是一个结合离线评测、生产可观测性与实验跟踪的平台——适合既要在开发期迭代、又要监控生产质量的团队。其 autoevals 库包含事实性、相关性等常见维度的预置评分器。

LangSmith 提供追踪、离线与在线评测及数据集管理,与 LangChain 生态深度集成。

Langfuse 为有数据驻留要求的团队提供可自托管的开源替代方案,能力与上述类似。

Arize 提供开源的 LLM 追踪、调试与离线/在线评测平台 Phoenix,以及面向规模、优化与监控的 SaaS 产品 AX。

许多团队组合多种工具、自研评测框架,或仅以简单评测脚本起步。我们发现:框架虽能加速与标准化,但其价值上限取决于你跑过其中的评测任务。通常最好的做法是快速选定适合工作流的框架,然后把精力投入评测本身——迭代高质量的测试用例与评分器。

要点速览

  • 评测词汇表:任务(单个测试)、试验(一次尝试)、评分器(打分逻辑,含多条断言)、轨迹(一次试验的完整记录)、结局(环境最终状态)、评测 harness(跑评测的基础设施)、Agent harness(让模型成为 Agent 的脚手架)、评测套件(任务集合)。
  • Agent 之所以难评:多轮 + 改状态导致错误传播复合;前沿模型还会找到超出静态评测预期的创造性解法(Opus 4.5 利用 τ²-bench 策略漏洞给用户更优解,却「未通过」评测)。
  • 三类评分器组合使用:代码型(快、便宜、客观但脆)、模型型(灵活、可扩展但需与人类校准)、人类(金标准但贵且慢);可用加权、二元或混合方式聚合成任务得分。
  • 能力评测问「擅长什么」(低通过率起步)、回归评测问「还做得到吗」(接近 100%);高通过率的能力评测可以「毕业」为回归套件。
  • 非确定性用两个指标刻画:pass@k(k 次至少一次成功,k 越大越高)与 pass^k(k 次全部成功,k 越大越低);k=1 时相等,k=10 时走向两个极端;一次性工具用前者、可靠性敏感的 Agent 用后者。
  • 八步路线图:0 尽早开始(20-50 个任务即可)、1 从手动测试与 bug 工单提取、2 写带参考解的无歧义任务(0% pass@100 往往是任务坏了)、3 构建正反例平衡的问题集。
  • harness 与评分器工程:每次试验隔离防共享状态污染(如 Claude 偷看历史试验的 git 记录);评「产出」而非「路径」以免惩罚创造性;给 LLM 评分器留「Unknown」退路并分维度隔离评审。
  • 真实教训:Opus 4.5 在 CORE-Bench 因评分 bug 从 42% 修到 95%;METR 时间视界基准中循规模型反被扣分;SWE-bench Verified 一年内 30%/40% 升至 80% 以上接近饱和,Qodo 因单次编码评测而低估 Opus 4.5。
  • 运维与组合:坚持读轨迹(验证评测度量了真正重要的东西)、监控评测饱和、用瑞士奶酪模型组合自动化评测 + 生产监控 + A/B 测试 + 用户反馈 + 人工评审 + 系统性人类研究。
  • 工具生态:Harbor、Braintrust、LangSmith、Langfuse、Arize(Phoenix/AX);框架只是加速器,评测质量取决于任务与评分器本身。