深入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}

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

ntotaltokens

type: latency

metrics:

timetofirst_token

outputtokensper_sec

timetolast_token

正如我们在编程 Agent 示例中所示，这个任务展示了多种评分器类型，仅用于说明。在实际操作中，对话 Agent 的评测通常使用基于模型的评分器来同时评估交互质量和目标完成情况，因为许多任务——例如回答问题——可能存在多种“正确”解法。

评测研究 Agent

研究 Agent 的工作是收集、综合并分析信息，然后生成输出，例如答案或报告。与编程 Agent 不同，研究任务无法通过单元测试提供简单的二元对错信号，研究质量必须根据任务情境来判断。什么算“全面”、“来源可靠”或“正确”，依赖具体场景：市场调研、并购尽调、科学报告，各自的标准都不同。

研究评测面临一些独特挑战：专家可能对综合内容是否全面存在分歧；参考内容持续变化导致“标准答案”不断漂移；长篇、开放式输出给错误留下更多空间。例如基准测试BrowseComp就考察 AI Agent 能否在开放网络中找到“干草堆中的针”——问题设计易于验证，但解决难度高。

构建研究 Agent 的评测策略之一是结合多种评分器类型：

• 事实性检查（Groundedness checks）：验证输出内容是否有检索到的来源支撑 • 覆盖率检查（Coverage checks）：定义一个良好答案必须包含的关键事实 • 来源质量检查（Source quality checks）：确认引用的来源权威可靠，而不仅仅是检索到的第一个

对于具有客观正确答案的任务（例如“X 公司第三季度营收是多少？”），可以使用精确匹配。LLM 评分器不仅可以标记 unsupported claims 和信息覆盖缺口，还可以评估开放式综合输出的连贯性和完整性。

由于研究质量具有主观性，基于 LLM 的评分器应定期与专家判断进行校准，以确保对研究 Agent 的评测有效。

电脑操作 Agent 的评测

电脑操作 Agent 通过人类界面操作软件——如截图、鼠标点击、键盘输入和滚动——而非通过 API 或代码执行，能够使用任何图形界面应用程序（GUI），从设计工具到遗留企业软件均可。评测要求在真实或沙盒环境中运行 Agent，观察其是否达成预期目标。

• 例如WebArena：测试基于浏览器的任务，通过 URL 和页面状态检查验证 Agent 是否正确导航，同时通过后台状态检查确认任务是否实际完成（例如订单是否真正生成，而不仅仅是确认页显示）。 • OSWorld：将评测扩展到整个操作系统，评测脚本在任务完成后检查多种产物：文件系统状态、应用配置、数据库内容以及 UI 元素属性。

浏览器 Agent 的评测需要在Token 使用效率与延迟之间找到平衡：

• 基于 DOM 的操作执行快，但消耗大量 Token • 基于截图的操作慢，但更节省 Token

例如，让 Claude 总结 Wikipedia 内容时，从 DOM 提取文本效率更高；在 Amazon 找笔记本保护壳时，截图操作更省 Token（因为完整提取 DOM 代价太高）。在Claude for Chrome产品中，我们开发了评测来检查 Agent 是否在每种场景中选择了正确工具，从而实现更快、更准确的浏览器任务完成。

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

无论 Agent 类型如何，其行为在不同运行中可能会有所不同，这使得评测结果比表面看起来更难解读。每个任务都有自身的成功率：一个任务可能在 90% 的尝试中成功，另一个任务可能仅有 50%；一次评测中通过的任务，下次可能失败。有时我们关注的，是 Agent 在多次尝试中成功的频率（试次比例）。

两个指标常用于量化这种非确定性：

• pass@k：表示 Agent 在 k 次尝试中至少一次成功的概率。随着 k 增加，pass@k 分数上升——尝试次数越多，至少一次成功的概率越高。举例来说，如果 pass@1 = 50%，意味着模型在评测中第一次尝试成功了一半任务。在编程场景，我们通常最关心第一次尝试能否成功（pass@1）。在其他场景，提出多种解决方案也是有效的，只要其中至少有一个成功。 • pass^k：表示 k 次尝试全部成功的概率。随着 k 增加，这个指标下降，因为要求在更多试次中保持一致更难。例如，如果 Agent 单次试次成功率为 75%，运行 3 次试次，那么三次全成功的概率为 0.75³ ≈ 42%。这一指标对面向用户的 Agent 尤为重要，因为用户期望每次都能可靠完成任务。

随着试次增加，pass@k与pass^k会出现明显分化。在k = 1时，两者相同，都等于单次试次的成功率。但到k = 10时，它们会呈现完全相反的趋势：pass@k接近 100%，而pass^k则降至 0%。

两种指标都有用，具体选用哪一个取决于产品需求：pass@k适用于只需一次成功即可的工具，pass^k则适用于对一致性有严格要求的 Agent。

从零到一：打造高质量 Agent 评测的路线图

本节分享在实战中验证过的经验，指导团队从没有评测到建立可靠评测的过程。把它看作以评测驱动的 Agent 开发路线图：早定义成功标准、明确衡量方式、持续迭代。

收集初始评测任务集

Step 0. 及早开始

许多团队拖延建立评测，因为他们认为需要上百个任务。实际上，20–50 个源自真实失败的简单任务就足够起步。早期 Agent 开发中，每次系统改动通常都会产生明显影响，这种大效应意味着小样本也能显现问题。随着 Agent 越成熟，可能需要更大、更难的评测来捕捉微小变化，但初期采用 80/20 法则最合适。评测建立越晚越困难。早期，产品需求自然能转化为测试用例；等太久，就需要从运行中的系统逆向推断成功标准。

Step 1. 从已有的手动测试开始

从开发过程中手动检查的内容入手——每次发布前验证的行为、用户常做的任务。如果 Agent 已上线，可查看 ...