深入Anthropic万字长文：构建高效AI Agent评测体系指南

type

status

date

slug

summary

category

icon

password

网址

让 Agents 更可用的部分模块，也恰恰是它们更难评测的部分。

传统模型评测方法无法胜任 Agent 系统的复杂行为，而有效的评测能够帮助团队在产品发布前发现深层问题，而不是等到用户反馈后再去盲目修正。

Agent 并不是一次性输出的系统。它们运行在多轮交互之中：调用工具、修改内部状态、根据中间结果不断调整策略。

也正是这些让 Agent 变得有用的能力 ——自主性、智能性与灵活性 —— 同时也让它们变得更难以评估。

Anthropic 在与内部团队的实践，以及与一线 Agent 开发者和客户的合作中，逐渐摸索出一套更严谨、也更具实际价值的 Agent 评测设计方法。

下面分享的，是这些方法在不同 Agent 架构、不同真实应用场景中反复验证后，总结出的有效经验。

评测的结构

评测（evaluation，简称eval），本质上是对一个 AI 系统进行测试：

向 AI 提供输入，再通过一套评分或判定逻辑，对其输出进行衡量，以判断是否达成预期目标。

在这篇文章中，我们关注的是可在开发阶段运行、无需真实用户参与的自动化评测。

单轮评测的结构相对简单：一个提示、一段回复，以及对应的评分逻辑。在早期的大模型阶段，单轮、非 Agent 化的评测，几乎是主流乃至唯一的评估方式。

但随着 AI 能力不断提升，系统开始具备规划、多步推理与工具调用能力，多轮交互、具备 Agent 特征的评测，逐渐成为新的常态。

在简单的评测中，Agent 接收一个提示并生成输出，评分器只需判断结果是否符合预期。而在更复杂的多轮评测里，一个编程 Agent 会被提供工具、任务（例如构建一个 MCP 服务器）以及运行环境，在此基础上执行完整的 Agent 循环（包括推理与工具调用），并将实现结果写入环境。最终，评测通过运行单元测试来验证该 MCP 服务器是否真正可用。

Agent 会在多轮交互中使用工具、不断修改环境状态并动态调整行为，这意味着一次失误可能被持续放大、层层叠加。与此同时，前沿的新模型有时还能通过“非常规路径”解决问题，超出静态评测的设计边界。

例如，Opus 4.5 在一个关于订机票的 𝜏2-bench 任务中，通过发现策略漏洞给出了更优解——虽然按照原评测规则判定为“失败”，但对用户而言反而是更好的结果。

在构建 Agent 评测时，我们采用如下定义：

• 任务（Task）：一次独立测试，包含明确的输入与成功标准。 • 试次（Trial）：任务的一次运行。由于模型输出存在随机性，通常会进行多次试次以获得稳定结果。 • 评分器（Grader）：用于评估 Agent 表现某一方面的判定逻辑。一个任务可以包含多个评分器，每个评分器内部可包含多个断言（check）。 • 记录（Transcript / Trace / Trajectory）：一次试次的完整过程记录，包括输出、工具调用、推理、中间结果及所有交互。在 Anthropic API 中，对应的是一次评测结束后完整的 messages 数组。 • 结果（Outcome）：试次结束时环境中的最终状态。比如订票 Agent 最后可能输出“机票已预订”，但真正的结果是数据库中是否存在有效的预订记录。 • 评测框架（Evaluation Harness）：用于端到端运行评测的基础设施，负责提供指令与工具、并发执行任务、记录过程、评分并汇总结果。 • Agent 框架（Agent Harness / Scaffold）：使模型能够作为 Agent 运作的系统，负责处理输入、调度工具调用并返回结果。评测“一个 Agent”时，实际上是在同时评测模型与其 Agent 框架。 • 评测套件（Evaluation Suite）：围绕特定能力或行为设计的一组任务集合，通常共享一个总体目标，例如客服场景下的退款、取消与升级处理等。

Agent 评估的组成部分

为什么要做评测？

在最初开发 Agent 时，团队往往靠手动测试、内部试用和直觉，就能推进很远。此时，严格的评测甚至可能被认为是拖慢交付的额外负担。

但一旦 Agent 上线、开始扩展规模，缺乏评测的问题就会显现。典型场景是：用户反馈改动后体验下降，而团队陷入迷茫，唯一手段只能是猜测与尝试。

没有评测，调试只能被动进行：等投诉、手动复现、修复，再祈祷没有引入新问题。团队无法区分真正的调优与噪声，也无法在上线前自动验证数百种场景，甚至无法量化改进效果。

我们多次观察到这样的发展过程。以 Claude Code 为例，最初团队依靠员工和外部用户反馈快速迭代。后来加入了评测——从单一指标（如简洁度、文件修改）到更复杂行为（如过度工程化）——帮助发现问题、指导改进，并强化研发与产品的协作。结合生产监控、A/B 测试和用户研究，评测为 Claude Code 的持续优化提供了关键信号。

在 Agent 生命周期的任何阶段，编写评测都是有价值的。早期，它迫使团队明确“成功标准”；后期，它保证了质量一致性。

例如 Descript 的视频编辑 Agent，他们围绕三条成功指标设计评测：不破坏现有内容、按要求完成、做好每一步。评测从人工评分演进为由产品团队定义标准的 LLM 自动评分，并辅以周期性人工校准，现在常态运行两套套件用于质量基准与回归测试。Bolt AI 则在 Agent 已广泛使用后才搭建评测系统，三个月内实现了自动运行 Agent、静态分析输出、浏览器测试应用、以及 LLM 判断行为的完整流程。

有的团队从开发一开始就做评测，有的则在扩展阶段才添加。评测尤其适合早期阶段，用于明确预期行为，避免两位工程师因初始规格理解不同而产生歧义。一套评测套件，可以统一判断标准，无论何时创建，都能加速开发。

评测还决定了团队采用新模型的速度。没有评测的团队，需要花数周测试新模型，而有评测的团队，可以在几天内快速发现模型优势、调整提示、升级 Agent。

一旦建立评测，就自带基线和回归测试：延迟、Token 使用量、任务成本、错误率等指标都能在固定任务库上追踪。同时，评测还能成为产品与研发之间高效沟通的渠道，定义可优化的指标。显然，评测的价值远不止追踪回归与改进，其复利效应往往被忽略：成本前置、收益延后，但积累下来却极为可观。

如何评测 AI Agent

目前大规模部署的 Agent 主要有几类：编程 Agent、研究 Agent、电脑操作 Agent 和对话 Agent。

虽然它们可能服务于不同行业，但评测方法可以相通。你不必从零设计评测，下面介绍一些已验证的技术，可作为基础，再根据你的应用场景进行拓展。

Agent 的评分器类型

Agent 评测通常结合三类评分器：基于代码的、基于模型的和人工评分。每类评分器用于评估记录（transcript）或最终结果（outcome）的不同部分。

设计有效评测的关键，在于为不同任务选择合适的评分器。

每个任务的评分可以采用加权（各评分器分数加权，达到阈值即通过）、二元制（所有评分器必须通过）或混合方式。

能力评测 vs. 回归评测

能力评测（Capability / Quality Eval）：问“这个 Agent 哪些方面做得好？”通常从较低通过率开始，关注 Agent 易错的任务，为团队设定提升目标。

回归评测（Regression Eval）：问“Agent 是否仍能完成之前能做的任务？”通过率接近 100%，用于防止性能倒退。一旦分数下降，说明出现了问题，需要修复。团队在能力评测上提升的同时，也要持续运行回归评测，确保改动没有引发新问题。

当 Agent 上线并优化成熟后，高通过率的能力评测可以“毕业”成为持续运行的回归套件，用于捕捉性能漂移。原本衡量“能否完成任务”的测试，转而衡量“能否稳定完成任务”。

评测编程 Agent

编程 Agent 会像人类开发者一样编写、测试、调试代码，并操作代码库和运行命令。现代编程 Agent 的有效评测通常依赖：明确的任务规范、稳定的测试环境、以及全面的代码测试。

确定性评分器非常适合编程 Agent，因为软件行为相对可量化：代码能否运行？测试是否通过？

两个常用基准：

• SWE-bench Verified：给 Agent 提供 GitHub 上 Python 项目的 issues，通过运行测试套件评分；仅在修复失败测试且不破坏原有功能时算通过。LLM 在一年内成绩从 40% 提升到 >80%。 • Terminal-Bench：面向端到端技术任务，例如从源码构建 Linux 内核或训练机器学习模型。

除了对关键结果的通过/失败测试外，评估记录（transcript）也很有用。例如：

• 可用启发式规则评估代码质量 • 可用模型评分器按明确标准评估 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: [testemptypwrejected.py, testnullpwrejected.py]

- type: llm_rubric

rubric: prompts/code_quality.md

- type: static_analysis

commands: [ruff, mypy, bandit]

- type: state_check

expect:

securitylogs: {eventtype: "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

ntotaltokens

- type: latency

metrics:

timetofirst_token

outputtokensper_sec

timetolast_token

需要注意的是，上述示例展示了可用评分器的全套范围，仅用于说明。实际上，编程 Agent 的评测通常只依赖单元测试验证正确性，以及LLM 评分标准评估整体代码质量，其他评分器和指标仅在必要时添加。

评测对话 Agent

对话 Agent 在客服、销售、辅导等场景中与用户交互。与传统聊天机器人不同，它们保持状态、使用工具、并可在对话中采取行动。虽然编程或研究 Agent 也可能有多轮用户交互，但对话 Agent 的独特挑战在于：交互本身的质量也是评测的一部分。

有效的对话 Agent 评测通常依赖：

• 可验证的最终状态（end-state outcome） • 能反映任务完成度和交互质量的评分标准（rubric）

与大多数评测不同，这类评测往往需要第二个 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}