我们可能一直在用错误的方法评测 AI Agent

让 Agent 真正有用的那些能力，也恰恰让它们更难评测。实践中行之有效的方法，往往需要组合多种技术，才能匹配被测系统本身的复杂度。

引言

好的评测，能让团队更有信心地发布 AI Agent。没有评测，团队很容易陷入被动响应的循环：问题只有进入生产环境后才被发现，修复一个故障又引发另一个故障。评测能在问题和行为变化影响用户之前，把它们暴露出来；而且在 Agent 的整个生命周期里，评测带来的价值会不断累积。

正如 Anthropic 在《构建高效 Agent》中介绍的那样，Agent 会在多个回合中运行：调用工具、修改状态，并根据中间结果调整行动。自主性、智能和灵活性让 AI Agent 变得有用，但同样也让它们更难评测。

结合 Anthropic 的内部实践，以及与 Agent 开发前沿客户的合作经验，团队逐渐摸索出一套更严谨、更有用的 Agent 评测设计方法。下面介绍的，是这些方法在多种 Agent 架构和真实部署场景中的实践结果。

评测的结构

评测（evaluation，简称 eval）是针对 AI 系统的一项测试：向 AI 提供输入，再用评分逻辑检查它的输出，以衡量是否成功。本文重点讨论的是可以在开发阶段运行、不需要真实用户参与的自动化评测。

单轮评测相对简单：一个提示词、一次响应，再加一套评分逻辑。对于早期 LLM，单轮、非 Agent 式评测曾是主要方法。随着 AI 能力提高，多轮评测越来越普遍。

在简单评测中，Agent 处理提示词，评分器检查输出是否符合预期。在更复杂的多轮评测中，编程 Agent 会获得工具、任务（图中是构建一个 MCP server）和运行环境；它执行由工具调用和推理组成的“Agent 循环”，并用实现结果更新环境。随后，评分环节通过单元测试验证 MCP server 是否真正可用。

Agent 评测更为复杂。Agent 会在多个回合中使用工具、修改环境状态并持续调整行动，因此错误可能沿流程传播并不断累积。前沿模型还可能找到超出静态评测预设范围的创造性方案。例如，Opus 4.5 在解决一个机票预订的 τ2-bench 题目时，发现了规则中的一个漏洞。按照原有评分标准，它“没有通过”评测，但实际上却为用户找到了更好的解决方案。

在构建 Agent 评测时，Anthropic 使用以下定义：

• • 任务（task，也称 problem 或 test case）是一次独立测试，包含明确的输入和成功标准。
• • 对任务的每一次尝试称为一次试次（trial）。模型每次运行的输出会有差异，因此需要运行多个试次，才能得到更稳定的结果。
• • 评分器（grader）是对 Agent 表现的某个方面进行打分的逻辑。一个任务可以包含多个评分器，每个评分器又可以包含多个断言，有时也叫检查项（check）。
• • 记录（transcript，也称 trace 或 trajectory）是一次试次的完整过程记录，包括输出、工具调用、推理、中间结果以及其他交互。对于 Anthropic API，它对应一次评测运行结束时的完整 messages 数组，其中包含所有 API 调用以及 API 返回的全部响应。
• • 结果（outcome）是试次结束时环境中的最终状态。机票预订 Agent 可能在记录末尾说“您的航班已预订”，但真正的结果要看环境的 SQL 数据库中是否存在这条预订记录。
• • 评测运行框架（evaluation harness）是端到端运行评测的基础设施。它提供指令和工具，并发运行任务，记录所有步骤，对输出评分并汇总结果。
• • Agent 框架（agent harness，也称 scaffold）是让模型能够作为 Agent 行动的系统：它处理输入、编排工具调用并返回结果。当团队评测“一个 Agent”时，实际评测的是 Agent 框架与模型的组合。Claude Code 就是一种灵活的 Agent 框架；Anthropic 也曾通过 Agent SDK 使用其核心原语，构建长时间运行的 Agent 框架。
• • 评测套件（evaluation suite）是一组用于衡量特定能力或行为的任务。一个套件中的任务通常具有共同的总体目标，例如客服评测套件可以测试退款、取消和升级处理。
• 

Agent 评测的组成部分。

为什么要构建评测

团队刚开始构建 Agent 时，仅凭手动测试、内部试用（dogfooding）和直觉，往往就能取得出人意料的进展。更严谨的评测甚至可能显得像额外负担，拖慢产品发布。但当早期原型阶段结束，Agent 进入生产环境并开始扩大规模后，没有评测的开发方式就会逐渐失效。

临界点通常出现在用户开始反馈“改完之后 Agent 反而变差了”，而团队却像蒙着眼飞行，只能不断猜测和试错。没有评测，调试只能被动进行：等待投诉，手动复现，修复问题，再祈祷没有引入其他回归。团队无法区分真正的功能回退和随机噪声，也无法在发布前自动用数百种场景测试改动，更无法量化改进。

Anthropic 多次见过这种发展过程。Claude Code 最初依靠 Anthropic 员工和外部用户的反馈快速迭代。后来，团队加入了评测：先覆盖简洁度、文件编辑等范围较窄的领域，再扩展到过度设计等更复杂的行为。这些评测帮助团队识别问题、指导改进，并把研究与产品之间的协作聚焦到关键问题上。结合生产监控、A/B 测试和用户研究等方法，评测为 Claude Code 的规模化改进持续提供信号。

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

Descript 的 Agent 用于帮助用户编辑视频，因此他们围绕成功编辑工作流的三个维度构建评测：不要破坏已有内容、完成用户要求、而且完成得足够好。他们从人工评分逐步转向由产品团队定义标准的 LLM 评分器，并定期用人工结果进行校准；现在，团队会固定运行两套独立评测，分别用于质量基准测试和回归测试。

Bolt 的 AI 团队开始构建评测的时间更晚，当时他们已经拥有一个被广泛使用的 Agent。三个月内，他们建立了一套评测系统：运行 Agent，用静态分析给输出评分，通过浏览器 Agent 测试应用，并用 LLM judge 检查指令遵循等行为。

有些团队在开发之初就创建评测，也有团队等产品达到一定规模、评测缺失已经成为继续改进的瓶颈后才补上。评测尤其适合在 Agent 开发早期明确编码预期行为。两个工程师阅读同一份初始规格，可能对 AI 应当如何处理边缘情况形成不同理解；评测套件可以消除这种歧义。无论从何时开始，评测最终都会加快开发速度。

评测还决定了团队采用新模型的速度。当更强的模型发布时，没有评测的团队可能需要几周才能完成测试；拥有评测的竞争者则能迅速确定模型的优势、调整提示词，并在几天内完成升级。

评测一旦建立，基线和回归测试也就自然具备了：团队可以在一组固定任务上追踪延迟、token 用量、单任务成本和错误率。评测还可能成为产品团队与研究团队之间信息带宽最高的沟通渠道，把研究人员可以优化的指标明确下来。显然，评测的作用远不只是追踪回归和改进。它的前期成本清晰可见，收益却在之后逐渐累积，因此其复利价值很容易被低估。

如何评测 AI Agent

目前大规模部署的 Agent 常见类型包括编程 Agent、研究 Agent、计算机操作 Agent 和对话 Agent。它们可能服务于完全不同的行业，但可以用相似的方法进行评测。团队不必从零发明一套评测方案。下面介绍几类 Agent 已被验证有效的评测技术；可以先把这些方法作为基础，再针对自己的领域扩展。

Agent 评分器的类型

Agent 评测通常会组合三类评分器：基于代码、基于模型和基于人工的评分器。每一种评分器都会检查记录或最终结果中的某一部分。有效评测设计的关键之一，就是为具体工作选择合适的评分器。

基于代码的评分器

基于模型的评分器

人工评分器

对于每个任务，评分可以采用加权方式（多个评分器的合计分达到阈值）、二元方式（所有评分器都必须通过），或者把两者混合使用。

能力评测与回归评测

能力评测，也叫“质量评测”，回答的问题是：“这个 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 kernel，或训练一个机器学习模型。

在拥有一组用于验证编程任务关键结果的通过/失败测试后，通常还值得对过程记录进行评分。例如，基于启发式规则的代码质量检查，可以从“测试是否通过”之外的角度评估生成代码；拥有明确 rubric 的模型评分器，还可以评价 Agent 调用工具或与用户交互的方式。

示例：编程 Agent 的理论评测

设想一个编程任务：Agent 必须修复身份验证绕过漏洞。下面的 YAML 示例展示了如何同时使用评分器和指标来评测这个 Agent。

task:id:"fix-auth-bypass_1"desc:"Fix authentication bypass when password field is empty and ..."graders:-type:deterministic_testsrequired: [test_empty_pw_rejected.py, test_null_pw_rejected.py]-type:llm_rubricrubric:prompts/code_quality.md-type:static_analysiscommands: [ruff, mypy, bandit]-type:state_checkexpect:security_logs: {event_type:"auth_blocked"}-type:tool_callsrequired:- {tool:read_file, params: {path:"src/auth/*"}}- {tool:edit_file}- {tool:run_tests}tracked_metrics:-type:transcriptmetrics:-n_turns-n_toolcalls-n_total_tokens-type:latencymetrics:-time_to_first_token-output_tokens_per_sec-time_to_last_token

这个例子为了说明，展示了可用评分器的完整范围。在实际编程评测中，团队通常主要依靠单元测试验证正确性，再用 LLM rubric 评估整体代码质量；只有确有需要时，才会加入额外的评分器和指标。

评测对话 Agent

对话 Agent 会在客服、销售或辅导等领域与用户交互。与传统聊天机器人不同，它们会维护状态、使用工具，并在对话中途执行操作。编程 Agent 和研究 Agent 同样可能与用户进行多轮交互，但对话 Agent 有一个独特难点：交互本身的质量就是评测对象的一部分。

有效的对话 Agent 评测通常依赖可以验证的最终状态，以及同时覆盖任务完成情况和交互质量的 rubric。与大多数其他评测不同，这类评测往往还需要第二个 LLM 来模拟用户。Anthropic 在一致性审计 Agent 中就使用了这种方法，通过长时间、对抗性的对话对模型进行压力测试。

对话 Agent 的成功可能包含多个维度：工单是否解决（状态检查）、是否在 10 个回合内完成（记录约束）、语气是否恰当（LLM rubric）。τ-Bench 及其后续版本 τ2-Bench 都体现了这种多维性。它们会模拟零售客服、航空订票等场景中的多轮交互：一个模型扮演用户角色，Agent 则在现实感较强的情境中完成任务。

示例：对话 Agent 的理论评测

考虑一个客服任务：Agent 必须为一位情绪受挫的客户处理退款。

graders:-type:llm_rubricrubric:prompts/support_quality.mdassertions:-"Agent showed empathy for customer's frustration"-"Resolution was clearly explained"-"Agent's response grounded in fetch_policy tool results"-type:state_checkexpect:tickets: {status:resolved}refunds: {status:processed}-type:tool_callsrequired:- {tool:verify_identity}- {tool:process_refund, params: {amount:"<=100"}}- {tool:send_confirmation}-type:transcriptmax_turns:10tracked_metrics:-type:transcriptmetrics:-n_turns-n_toolcalls-n_total_tokens-type:latencymetrics:-time_to_first_token-output_tokens_per_sec-time_to_last_token

与编程 Agent 的例子一样，这个任务为了说明而同时展示了多种评分器。实际的对话 Agent 评测，通常会用基于模型的评分器同时判断沟通质量和目标完成情况，因为回答问题等任务可能存在多个“正确”方案。

评测研究 Agent

研究 Agent 会收集、综合和分析信息，再生成答案或报告。编程 Agent 可以通过单元测试获得二元的通过/失败信号，研究质量却只能相对于具体任务判断。“全面”“来源可靠”甚至“正确”到底意味着什么，取决于上下文：市场扫描、并购尽调和科学报告需要的标准并不相同。

研究评测面临一些独有难题：专家可能对一份综合材料是否全面意见不一；参考内容持续变化，ground truth 也会随之改变；更长、更开放的输出还会给错误留下更多空间。BrowseComp 这类基准测试的，就是 AI Agent 能否在开放网络的大海捞针题目中找到答案——这些问题容易验证，却很难解决。

构建研究 Agent 评测的一种方法，是组合多类评分器：groundedness 检查验证结论是否得到检索来源支持；覆盖度检查定义一份好答案必须包含的关键事实；来源质量检查则确认 Agent 使用的是权威来源，而不只是检索结果中的第一条。对于“X 公司第三季度收入是多少”这类存在客观答案的问题，可以直接使用精确匹配。

LLM 既可以标记缺乏来源支持的结论和覆盖缺口，也可以检查开放式综合内容的一致性与完整性。不过，由于研究质量带有较强主观性，要有效评测此类 Agent，仍应频繁用专家的人工判断校准基于 LLM 的 rubric。

评测计算机操作 Agent

计算机操作 Agent 通过和人类相同的界面与软件交互——查看截图、点击鼠标、输入键盘和滚动页面——而不是通过 API 或代码执行。它们能够使用任何带有图形用户界面（GUI）的应用，从设计工具到传统企业软件。评测这类 Agent，需要让它在真实或沙箱环境中运行和操作软件，再检查它是否实现了预期结果。

例如，WebArena 测试基于浏览器的任务：用 URL 和页面状态检查 Agent 是否正确完成导航，并通过后端状态验证那些会修改数据的任务——例如确认订单确实已经创建，而不只是确认页面曾经出现。

OSWorld 把范围扩展到完整的操作系统控制。任务结束后，评测脚本会检查多种产物，包括文件系统状态、应用配置、数据库内容和 UI 元素属性。

浏览器操作 Agent 需要在 token 效率和延迟之间取得平衡。基于 DOM 的交互执行速度快，但会消耗大量 token；基于截图的交互速度较慢，却更节省 token。例如，让 Claude 总结 Wikipedia 页面时，直接从 DOM 提取文字更高效；让它在 Amazon 上寻找一个新的笔记本保护套时，使用截图反而更高效，因为提取整份 DOM 的 token 成本很高。

在 Claude for Chrome 产品中，Anthropic 构建了专门的评测，用来检查 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 tracker 和客服队列。把用户报告的故障转换成测试用例，能确保评测套件反映真实使用情况；再按用户影响排序，就能把精力投入真正重要的地方。

第 2 步：编写无歧义的任务，并提供参考解

保证任务质量比看上去更难。一个好的任务，应该让两位领域专家在彼此独立判断时，也能对通过或失败得出相同结论。他们自己能否完成这项任务？如果不能，任务还需要继续完善。任务规格中的歧义会变成指标里的噪声；模型评分器的标准同样如此，含糊的 rubric 会产生不一致的判断。

只要 Agent 正确遵循指令，每个任务就应该能够通过。这里可能存在一些很隐蔽的问题。对 Terminal-Bench 的审计发现：如果任务要求 Agent 编写脚本，却没有指定文件路径，而测试又默认脚本位于某个固定路径，Agent 可能在没有犯错的情况下被判失败。评分器检查的所有内容，都应当在任务说明中明确；不能让 Agent 因为规格含糊而失败。

对于前沿模型，如果一个任务在大量试次中的通过率始终为 0%，例如 pass@100 = 0%，更常见的原因是任务本身有问题，而不是 Agent 完全没有能力。这时应优先复查任务规格和评分器。为每个任务创建一个已知可行、能够通过所有评分器的参考解也很有用：它既能证明任务确实可解，也能验证评分器配置正确。

第 3 步：构建平衡的问题集

既要测试某个行为应该发生的情况，也要测试它不应该发生的情况。单边评测会导致单边优化。例如，只测试 Agent 是否会在必要时搜索，最终可能得到一个几乎遇到什么问题都搜索的 Agent。应尽量避免类别不平衡的评测。Anthropic 在为 Claude.ai 构建网页搜索评测时，就亲身遇到了这个问题。

难点是：既要阻止模型在不需要时搜索，又要保留它在适当情况下进行深度研究的能力。团队为两个方向都构建了评测：一类查询应该搜索，例如查询天气；另一类查询应该直接使用已有知识回答，例如“谁创立了 Apple？”

要在触发不足——该搜索时不搜索——和触发过度——不该搜索时也搜索——之间取得平衡并不容易。团队对提示词和评测进行了多轮完善。随着更多示例问题出现，评测中也会持续加入新任务，以扩大覆盖范围。

设计评测运行框架和评分器

第 4 步：构建稳健、环境稳定的评测运行框架

评测中的 Agent 必须与生产环境中的 Agent 大体一致，而且评测环境本身不能引入额外噪声。每一次试次都应从干净环境开始，彼此隔离。运行之间不必要的共享状态——遗留文件、缓存数据、资源耗尽等——可能因为基础设施不稳定造成相关性故障，而不是反映 Agent 的实际表现。共享状态也可能虚假地抬高成绩。

例如，在 Anthropic 的一些内部评测中，Claude 曾通过查看此前试次留下的 git history，在部分任务中获得不公平优势。反过来，如果多个不同试次都因为同一个环境限制而失败，例如 CPU 内存不足，那么这些试次受到了同一因素影响，并非真正独立；此时的评测结果也无法可靠衡量 Agent 表现。

第 5 步：审慎设计评分器

优秀的评测设计，需要为 Agent 和任务选择最合适的评分器。Anthropic 的建议是：能用确定性评分器时尽量使用；需要灵活性时再使用 LLM 评分器；同时谨慎地用人工评分做进一步验证。

人们常有一种直觉：应该检查 Agent 是否严格按照某个步骤序列行动，例如是否以正确顺序调用工具。实践表明，这种做法过于僵硬，会让测试变得异常脆弱，因为 Agent 经常找到评测设计者没有预料到的有效方法。为了避免无端惩罚创造性，通常更适合评测 Agent 最终产出了什么，而不是它走过哪条固定路径。

任务包含多个组成部分时，应当允许部分得分。一个客服 Agent 如果正确识别问题并验证了客户身份，却没能完成退款，依然明显优于一开始就失败的 Agent。评测结果需要表达这种连续的成功程度。

用模型评分通常要经过细致迭代，才能验证其准确性。LLM-as-judge 评分器应与人工专家的判断紧密校准，确保两者分歧足够小。为了减少幻觉，还应给 LLM 留出退出路径，例如明确要求它在信息不足时返回 Unknown。

另一种有效做法，是为任务的每个维度分别建立清晰、结构化的 rubric，再让相互独立的 LLM-as-judge 分别评测各个维度，而不是用一个模型一次评完所有内容。系统足够稳健后，只需偶尔进行人工审查。

一些评测存在隐蔽的故障模式，即使 Agent 表现良好，分数仍可能很低：任务失败的真正原因可能是评分 bug、Agent 框架限制或任务歧义。即便成熟团队也会忽略这些问题。

例如，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 的表现并不满意，因为他们的一次性编程评测没有反映出模型在更长、更复杂任务上的提升。为此，他们开发了新的 Agent 式评测框架，才更清楚地看到模型进步。

Anthropic 的原则是：在有人深入检查评测细节并阅读部分记录之前，不会只看表面分数就下结论。如果评分不公平、任务含糊、有效方案遭到惩罚，或者运行框架限制了模型，就应该修改评测。

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

评测套件是一项持续变化的产物。要长期保持价值，它需要持续投入和明确的负责人。

Anthropic 曾尝试过多种评测维护方式。实践中最有效的办法，是建立专门的评测团队负责核心基础设施，同时由领域专家和产品团队贡献大部分评测任务，并亲自运行评测。

对于 AI 产品团队，维护和迭代评测应当像维护单元测试一样日常。团队可能在某个 AI 功能上浪费数周：早期测试看起来“能用”，实际却无法满足那些未被明确写出的期望，而设计良好的评测本可以更早暴露这些问题。定义评测任务，是检验产品需求是否已经具体到足以开工的最佳方法之一。

Anthropic 建议采用评测驱动开发：在 Agent 还无法实现计划能力之前，就先用评测把目标定义清楚，然后持续迭代，直到 Agent 表现足够好。团队内部经常会构建一些今天只是“勉强可用”、但押注几个月后模型能力会跟上的功能。初始通过率较低的能力评测，可以把这种押注明确地表现出来。新模型一旦发布，运行评测套件就能迅速看出哪些押注兑现了。

最接近产品需求和用户的人，最适合定义什么叫成功。以当前模型能力，产品经理、客户成功经理或销售人员都可以使用 Claude Code，以 PR 形式贡献一项评测任务——团队应该允许他们这样做，更应该主动为他们提供条件。

创建有效评测的过程。

评测如何与其他方法共同构成对 Agent 的完整理解

自动化评测可以在不部署到生产环境、不影响真实用户的情况下，让 Agent 运行数千项任务。但它只是理解 Agent 表现的众多方法之一。完整图景还需要生产监控、用户反馈、A/B 测试、人工记录审查和系统化人工评测。

理解 AI Agent 表现的不同方法

这些方法对应 Agent 开发的不同阶段。自动化评测尤其适合发布前和 CI/CD 阶段，可以在每次 Agent 改动和模型升级时运行，成为抵御质量问题的第一道防线。产品发布后，生产监控开始发挥作用，用于发现分布漂移和未曾预料的真实故障。拥有足够流量后，A/B 测试可以验证重大改动。

用户反馈和记录审查则应持续进行，用来填补其他方法的空白：不断分流和处理反馈，每周抽样阅读记录，并在必要时深入调查。系统化人工研究应主要用于校准 LLM 评分器，或者评测那些需要以人工共识作为参考标准的主观输出。

正如安全工程中的“瑞士奶酪模型”，没有任何单一评测层能够捕捉全部问题。多种方法组合使用时，从一层漏洞中穿过的故障，会被另一层拦住。

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

结论

没有评测的团队会陷入被动循环：修复一个故障，又制造另一个故障，而且无法区分真正的回归和随机噪声。尽早投入评测的团队则会看到相反结果：失败被转化为测试用例，测试用例阻止回归，指标取代猜测，开发速度随之提高。评测为整个团队提供了一个清晰、可以持续攀登的目标，把“Agent 好像变差了”转化成可以采取行动的问题。它的价值会不断复利增长，但前提是把评测当作核心组件，而不是事后补救。

不同类型 Agent 的具体方法会有差异，但本文介绍的基本原则保持不变：尽早开始，不要等完美套件；从已经发现的故障中提取真实任务；定义无歧义、稳健的成功标准；审慎设计评分器，并组合多种评分方式；确保题目对模型而言足够困难；持续迭代评测，提高信噪比；最后，务必阅读过程记录。

AI Agent 评测仍是一个刚刚起步、快速演进的领域。随着 Agent 开始承担更长的任务、在多 Agent 系统中协作，并处理越来越主观的工作，评测技术也必须继续调整。Anthropic 表示，他们会在实践中不断学习，并继续分享最佳方法。

附录：评测框架

多个开源和商业框架都可以帮助团队实现 Agent 评测，而不必从零构建基础设施。选择哪一种，取决于 Agent 类型、现有技术栈，以及团队需要离线评测、生产可观测性，还是两者都需要。

Harbor 专为在容器化环境中运行 Agent 而设计，提供跨云服务商大规模运行试次的基础设施，并用标准格式定义任务和评分器。Terminal-Bench 2.0 等热门基准通过 Harbor registry 发布，因此团队可以轻松运行既有基准和自定义评测套件。

Braintrust 把离线评测、生产可观测性和实验追踪整合在一个平台里，适合既要在开发阶段迭代、又要在生产环境中监控质量的团队。它的 autoevals 库包含事实性、相关性等常见维度的预构建评分器。

LangSmith 提供 tracing、离线与在线评测以及数据集管理，并与 LangChain 生态紧密集成。Langfuse 提供类似能力，同时以可自行托管的开源方案服务于有数据驻留要求的团队。

Arize 提供 Phoenix——用于 LLM tracing、调试以及离线或在线评测的开源平台；同时还提供 AX，这是一项在 Phoenix 基础上扩展规模化、优化和监控能力的 SaaS 服务。

许多团队会组合多个工具，自己开发评测框架，或者从简单评测脚本起步。Anthropic 的经验是：框架确实能加快进度并建立标准，但框架最终能发挥多大价值，取决于团队在其中运行的评测任务。通常更有效的做法，是迅速选择一个符合工作流的框架，然后把主要精力投入评测本身，持续迭代高质量测试用例和评分器。

参考链接

原文：https://www.anthropic.com/engineering/demystifying-evals-for-ai-agents

构建高效 Agent：https://www.anthropic.com/engineering/building-effective-agents

τ2-bench 项目：https://github.com/sierra-research/tau2-bench

长时间运行的 Agent 框架：https://www.anthropic.com/engineering/effective-harnesses-for-long-running-agents

SWE-bench Verified：https://www.swebench.com/SWE-bench/

Terminal-Bench：https://www.tbench.ai/

一致性审计 Agent：https://alignment.anthropic.com/2025/automated-auditing/

τ-Bench 论文：https://arxiv.org/abs/2406.12045

τ2-Bench 论文：https://arxiv.org/abs/2506.07982

BrowseComp 论文：http://arxiv.org/abs/2504.12516

WebArena 论文：https://arxiv.org/abs/2307.13854

pass@k 论文：https://proceedings.neurips.cc/paper/2019/file/7298332f04ac004a0ca44cc69ecf6f6b-Paper.pdf

Claude.ai 搜索评测：http://claude.ai/redirect/website.v1.b91e1c67-2478-46e7-be2f-31653a3ef567

瑞士奶酪模型：https://en.wikipedia.org/wiki/Swiss_cheese_model