这篇解决了「Agent 到底该怎么评」的问题：从概念定义到可直接照抄的路线图，一站式讲清 Agent 评测的落地方法。
最值得拿走的是三类评分器（代码/模型/人工）的选型框架，以及 pass@k 与 pass^k 的区分——前者衡量「至少成功一次」，后者衡量「次次都成功」，面向客户的产品应盯后者。最易误用之处：用固定工具调用序列当评分标准，作者明确主张「评产物而非路径」；此外多次试验 0% 通过率往往是任务坏了，不是模型不行。
相比站内已有的评测概念内容，这篇是 Anthropic 在 SWE-bench、τ2-bench 等基准语境下的一手实践：20-50 个真实故障任务即可起步、评测饱和与「毕业」为回归套件的生命周期视角、以及评测驱动开发（先写评测定义未来能力，等新模型发布时验证押注）。国内读者可直接把第 4-8 步套进自己的 CI 流程，并把领域专家贡献评测任务纳入协作机制。
读完今天就从客服队列或 bug 列表里挑 20 个真实故障，写成带参考解法的评测任务。
—— FDEChina编辑部 · 架构师视角
导语
良好的评测（evaluation，简称 eval）能帮助团队更有底气地发布 AI Agent。没有评测，团队很容易陷入被动循环——只在生产环境中发现问题，而修好一个故障又会引发新的故障。评测能在问题和行为变化影响用户之前就让它们显形，而且其价值会在 Agent 的整个生命周期中不断复利累积。
正如我们在 Building effective agents 一文中所描述的，Agent 的运行横跨许多回合：调用工具、修改状态，并根据中间结果不断调整。让 AI Agent 有用的那些能力——自主性、智能与灵活性——恰恰也是让它们更难被评测的原因。
通过内部实践，以及与处在 Agent 开发前沿的客户合作，我们摸索出了如何为 Agent 设计更严谨、更有用的评测。以下是这些方法在真实部署中、跨多种 Agent 架构与用例反复验证有效的经验。
评测的结构
评测（eval）是对 AI 系统的一次测试：给 AI 一个输入，然后对其输出应用评分逻辑来衡量成败。本文聚焦于可以在开发过程中运行、无需真实用户参与的自动化评测。
单轮评测很简单：一条提示词、一个响应、一套评分逻辑。对早期的 LLM 而言，单轮、非 Agent 化的评测是主要评测方式。随着 AI 能力的进步，多轮评测变得越来越普遍。
在一个简单的评测中，Agent 处理一条提示词，由评分器（grader）检查输出是否符合预期。在更复杂的多轮评测中，一个编码 Agent 会拿到工具、一个任务（此例中是构建一个 MCP server）和一个环境，执行「Agent 循环」（工具调用与推理），并把实现写入环境。评分阶段再用单元测试来验证这个 MCP server 能否正常工作。
Agent 评测还要更复杂。Agent 会在许多回合中使用工具、修改环境状态并随机应变——这意味着错误会传播并叠加。前沿模型还可能找到超出静态评测边界的创造性解法。例如，Opus 4.5 在解 τ2-bench 一道订机票的题目时，发现了政策中的一个漏洞。按评测的原意它「失败」了，但实际上它为用户找到了更好的方案。
构建 Agent 评测时，我们使用以下定义：
- 任务（task，也叫 problem 或 test case）：一次有明确输入与成功标准的单独测试。
- 任务的每次尝试是一个试验（trial）。由于模型输出在多次运行之间会有波动，我们会运行多次试验来获得更一致的结果。
- 评分器（grader）：对 Agent 表现的某个方面打分的逻辑。一个任务可以有多个评分器，每个评分器内部又包含多条断言（assertion，有时也叫 check）。
- 转录（transcript，也叫 trace 或 trajectory）：一次试验的完整记录，包括输出、工具调用、推理、中间结果以及其他所有交互。对 Anthropic API 来说，就是评测运行结束时完整的 messages 数组——包含评测期间对 API 的所有调用与返回的全部响应。
- 结果（outcome）：试验结束时环境中的最终状态。一个订机票 Agent 可能会在转录末尾说「您的机票已订好」，但结果指的是环境的 SQL 数据库里是否真的存在一条预订记录。
- 评测框架（evaluation harness）：端到端运行评测的基础设施。它提供指令与工具、并发运行任务、记录所有步骤、给输出打分并汇总结果。
- Agent 框架（agent harness，或 scaffold）：让模型能够作为 Agent 行动的系统：处理输入、编排工具调用并返回结果。当我们评测「一个 Agent」时，评测的是框架与模型协作的整体。例如，Claude Code 是一个灵活的 Agent 框架，我们通过 Agent SDK 使用它的核心原语构建了自己的长时运行 Agent 框架。
- 评测套件（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、计算机操作（computer use）Agent 和对话式 Agent。每种类型都可能部署在各种行业中，但可以用相似的技术来评测。你不需要从零发明一套评测。下面几节介绍针对若干 Agent 类型的经过验证的方法。把它们当作地基，再扩展到你自己的领域。
Agent 评测的三类评分器
Agent 评测通常结合三类评分器：基于代码的、基于模型的和人工的。每个评分器评估转录或结果的某一部分。高效评测设计的一个关键环节，就是为手头的工作选对评分器。
基于代码的评分器
| 方法 | 优势 | 劣势 |
|---|---|---|
|
|
|
基于模型的评分器
| 方法 | 优势 | 劣势 |
|---|---|---|
|
|
|
人工评分器
| 方法 | 优势 | 劣势 |
|---|---|---|
|
|
|
对每个任务，计分可以是加权式的（各评分器得分合计须达到阈值）、二元式的（所有评分器都须通过）或混合式。
能力评测与回归评测
能力（capability）评测或「质量」评测问的是：「这个 Agent 能把什么做好？」它们的通过率应该起步较低，瞄准 Agent 搞不定的任务，给团队一座可以攀登的山。
回归（regression）评测问的是：「Agent 还能处理过去能处理的所有任务吗？」通过率应接近 100%。它们防止倒退——分数下滑意味着出了问题、需要修复。团队在能力评测上登山时，也要同时运行回归评测，确保改动不在别处引发问题。
Agent 上线并优化之后，通过率很高的能力评测可以「毕业」成为持续运行的回归套件，用来捕捉任何漂移。曾经衡量「我们到底能不能做到？」的任务，转而衡量「我们还能稳定做到吗？」
评测编码 Agent
编码 Agent 编写、测试并调试代码，像人类开发者一样在代码库中导航、运行命令。对现代编码 Agent 有效的评测通常依赖三样东西：定义清晰的任务、稳定的测试环境，以及对生成代码的充分测试。
确定性评分器天然适合编码 Agent，因为软件通常不难评价：代码能跑吗？测试通过吗？两个广泛使用的编码基准 SWE-bench Verified 和 Terminal-Bench 都遵循这一思路。SWE-bench Verified 把热门 Python 仓库的 GitHub issue 交给 Agent，通过运行测试套件来评分；只有修好了失败的测试、又没破坏现有测试的解法才算通过。短短一年间，LLM 在这个评测上的成绩从 40% 提升到 80% 以上。Terminal-Bench 走的是另一条路：它测试端到端的技术任务，比如从源码构建 Linux 内核，或训练一个机器学习模型。
一旦有了一套判定编码任务关键结果的通过/失败测试，对转录进行评分往往也有价值。例如，基于启发式的代码质量规则可以在「测试是否通过」之外评价生成的代码；带有清晰量规的基于模型的评分器则可以评估 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 评测通常依赖可验证的终态结果，以及同时捕捉任务完成度与交互质量的量规。与大多数其他评测不同，它们常常需要一个第二 LLM 来模拟用户。我们在对齐审计（alignment auditing）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: 10tracked_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）检查验证论断是否被检索到的来源支撑；覆盖度检查定义一份好答案必须包含的关键事实；来源质量检查确认引用的来源是权威的，而不只是碰巧排在检索结果前面的那几个。对有客观正确答案的任务（「X 公司三季度的营收是多少？」），精确匹配就够用。LLM 可以标记缺乏支撑的论断与覆盖缺口，同时也能核查开放式综述的连贯性与完整性。
鉴于研究质量的主观性，基于 LLM 的量规应当频繁地与专家人工判断进行校准，才能有效评测这类 Agent。
计算机操作（computer use）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）最常见的原因是任务本身有问题，而不是模型不行——这是提醒你复查任务规格与评分器的信号。为每个任务创建一个参考解法（reference solution）也很有用：一个能通过所有评分器的已知正确输出。它证明任务可解，也验证评分器配置无误。
第 3 步：构建均衡的题目集
既测试「某行为应该发生」的情形，也测试「不该发生」的情形。单边的评测催生单边的优化。例如，如果你只测试 Agent 在该搜索时是否搜索，最后可能得到一个对几乎什么都去搜索的 Agent。尽量避免类别不均衡的评测。我们在为 Claude.ai 的网页搜索构建评测时对此深有体会。挑战在于：既要防止模型在不该搜索时搜索，又要保留它在合适时机做深入研究的能力。团队构建了覆盖两个方向的评测：模型应当搜索的查询（比如查天气），以及模型应当凭已有知识回答的查询（比如「苹果公司是谁创办的？」）。在触发不足（该搜不搜）与过度触发（不该搜也搜）之间找到平衡非常困难，提示词和评测都经历了许多轮打磨。随着更多样例出现，我们持续往评测里补充以扩大覆盖面。
设计评测框架与评分器
第 4 步：搭建拥有稳定环境的健壮评测框架
关键在于：评测中的 Agent 的行为要大体等同于生产中的 Agent，同时环境本身不引入额外噪声。每次试验都应当「隔离」，从干净的环境起步。运行之间不必要的共享状态（残留文件、缓存数据、资源耗尽）会因为基础设施抖动而非 Agent 表现导致关联性失败。共享状态还会人为抬高成绩。例如，在一些内部评测中，我们观察到 Claude 通过翻看之前试验留下的 git 历史而在某些任务上获得了不公平优势。如果多个不同的试验因为环境中的同一个限制（比如 CPU 内存不足）而失败，这些试验就不是独立的——它们受同一因素影响，评测结果对衡量 Agent 表现而言就不可靠。
第 5 步：深思熟虑地设计评分器
如前所述，优秀的评测设计要为 Agent 和任务选择最合适的评分器。我们的建议是：能用确定性评分器就用确定性评分器，必要或需要额外灵活性时用 LLM 评分器，并审慎地使用人工评分器做补充验证。
有一种常见的本能：检查 Agent 是否严格遵循了非常具体的步骤，比如按正确顺序的一串工具调用。我们发现这种做法太僵硬，会造出极其脆弱的测试，因为 Agent 经常找到评测设计者没有预料到的有效路径。为了不过度惩罚创造力，更好的做法往往是给 Agent 产出的东西评分，而不是给它走的路径评分。
对有多个组成部分的任务，要设计部分得分（partial credit）。一个正确识别问题、验证了客户身份、但没能处理退款的客服 Agent，明显好于一开始就失败的 Agent。在结果中呈现这种成功的连续谱很重要。
模型评分往往需要细致的迭代来验证准确性。LLM 裁判（LLM-as-judge）评分器应与人类专家紧密校准，以确信人工评分与模型评分之间分歧很小。为避免幻觉，要给 LLM 留退路，比如指示它在信息不足时返回「Unknown」。创建清晰、结构化的量规来给任务的每个维度打分，然后用彼此隔离的 LLM 裁判分别评每个维度（而不是用一个裁判评所有维度），也有帮助。等系统足够稳健之后，只需偶尔进行人工复核即可。
有些评测存在隐蔽的失败模式：即使 Agent 表现良好也得分很低，因为 Agent 因评分 bug、Agent 框架限制或歧义而「没能解题」。连非常成熟的团队也会漏掉这些问题。例如，Opus 4.5 在 CORE-Bench 上最初只得 42%，直到一位 Anthropic 研究员发现了多个问题：僵化的评分（预期「96.124991…」时对「96.12」判罚）、含糊的任务规格，以及无法精确复现的随机性任务。修复 bug 并换用约束更少的 scaffold 之后，Opus 4.5 的分数跳到了 95%。类似地，METR 在其时间跨度（time horizon）基准中发现若干配置错误的任务：任务要求 Agent 优化到某个给定的分数阈值，但评分却要求超过该阈值。这让像 Claude 这样遵循指令的模型受到惩罚，而忽视既定目标的模型反而得分更高。仔细复查任务与评分器可以帮助避免这些问题。
要让评分器抗绕过、抗作弊。Agent 不应能轻易「骗过」评测。任务与评分器的设计应确保：通过评测真的需要解决问题，而不是钻非预期的空子。
长期维护并使用评测
第 6 步：阅读转录
除非你阅读大量试验的转录与评分，否则你不会知道评分器是否工作良好。在 Anthropic，我们投入建设了查看评测转录的工具，并定期花时间阅读它们。当某个任务失败时，转录会告诉你：是 Agent 真的犯了错，还是你的评分器拒绝了一个有效解。它还常常暴露出关于 Agent 与评测行为的关键细节。
失败应当显得公平：能清楚看出 Agent 错在哪、为什么错。当分数不再上升时，我们需要确信这源于 Agent 表现而非评测本身。阅读转录是你验证「评测正在衡量真正重要的东西」的方法，也是 Agent 开发的一项关键技能。
第 7 步：监控能力评测的饱和
100% 的评测只能跟踪回归，对改进不再提供任何信号。当 Agent 通过了所有可解任务、再无改进空间时，就发生了评测饱和。例如，SWE-bench Verified 的分数今年从 30% 起步，前沿模型如今已接近 80% 以上的饱和区。随着评测接近饱和，进展也会放缓，因为只剩最难的任务。这会让结果具有欺骗性：巨大的能力提升在分数上只表现为小幅增长。例如，代码评审创业公司 Qodo 最初对 Opus 4.5 印象平平，因为他们的单轮编码评测没能体现更长、更复杂任务上的收益。作为回应，他们开发了一套新的 Agent 化评测框架，从而更清晰地看到进展。
作为一条规则，在有人深入研究评测细节并阅读一些转录之前，我们不直接采信评测分数。如果评分不公、任务含糊、有效解被误判，或框架限制了模型，就应该修订评测。
第 8 步：通过开放贡献与持续维护让评测套件长期健康
评测套件是一个需要持续关照和明确归属的活文档，否则就无法保持有用。
在 Anthropic，我们试验过各种评测维护方式。事实证明最有效的是：成立专门的评测团队负责核心基础设施，而领域专家与产品团队贡献大多数评测任务，并自己运行评测。
对 AI 产品团队而言，拥有并迭代评测应当像维护单元测试一样成为日常。团队可能在「早期测试能跑通」的 AI 功能上浪费数周，而这些功能满足不了未曾言明的期望——一套设计良好的评测本可以更早把它们暴露出来。定义评测任务是检验产品需求是否具体到可以开工的最佳方式之一。
我们推荐实践评测驱动开发（eval-driven development）：在 Agent 还做不到之前，先构建评测来定义计划中的能力，然后迭代直到 Agent 表现良好。在内部，我们经常构建今天「够用」的功能，但它们其实是对几个月内模型能力的押注。从低通过率起步的能力评测让这种押注可见。新模型发布时，跑一遍套件就能迅速看出哪些押注兑现了。
离产品需求和用户最近的人最有资格定义成功。以当前模型的能力，产品经理、客户成功经理或销售都可以用 Claude Code 以 PR 的形式贡献一个评测任务——放手让他们做！或者更进一步，主动为他们创造条件。
创建有效评测的流程。
评测如何与其他方法配合，形成对 Agent 的完整认知
自动化评测可以在数千个任务上运行，无需部署到生产环境或影响真实用户。但这只是理解 Agent 表现的众多方式之一。完整的图景还包括生产监控、用户反馈、A/B 测试、人工转录审读和系统性人类评估。
理解 AI Agent 表现的各类方法一览
| 方法 | 优势 | 劣势 |
|---|---|---|
| 自动化评测 以程序方式运行测试，不涉及真实用户 |
|
|
| 生产监控 跟踪线上系统中的指标与错误 |
|
|
| A/B 测试 用真实用户流量比较不同版本 |
|
|
| 用户反馈 点踩、bug 报告等显式信号 |
|
|
| 人工转录审读 人类通读 Agent 对话 |
|
|
| 系统性人类研究 由受训评分者对 Agent 输出做结构化评分 |
|
|
这些方法对应 Agent 开发的不同阶段。自动化评测在发布前和 CI/CD 中尤其有用：每次 Agent 变更和模型升级时运行，是抵御质量问题的第一道防线。生产监控在上线后启动，用于检测分布漂移与预料之外的真实故障。一旦流量足够，A/B 测试用来验证重大变更。用户反馈与转录审读是持续进行的补位实践：不断分诊反馈，每周抽样阅读转录，必要时深入挖掘。系统性人类研究则留给校准 LLM 评分器，或评估那些以人类共识为参照标准的主观输出。
正如安全工程中的瑞士奶酪模型（Swiss Cheese Model），没有任何单一的评测层能捕捉所有问题。多方法组合之后，从一层漏掉的失败会被另一层接住。
最高效的团队组合使用这些方法：自动化评测用于快速迭代，生产监控提供基准真值，周期性的人工复核用于校准。
结论
没有评测的团队深陷被动循环——修好一个故障又制造另一个，无法区分真实回归与噪声。尽早投入的团队则看到相反的图景：失败变成测试用例，测试用例阻止回归，指标取代猜测，开发随之加速。评测给整个团队一座清晰可攀的山，把「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 注册表分发，让运行既有基准与自定义评测套件都变得容易。
Braintrust 是一个把离线评测、生产可观测性与实验追踪结合起来的平台——适合既要在开发期迭代、又要监控生产质量的团队。它的 autoevals 库内置了事实性、相关性等常见维度的现成评分器。
LangSmith 提供追踪、离线与在线评测以及数据集管理，与 LangChain 生态深度集成。Langfuse 提供类似能力，是面向有数据驻留要求团队的、可自托管的开源替代品。
Arize 提供开源的 LLM 追踪、调试与离线/在线评测平台 Phoenix，以及在其之上扩展的 SaaS 产品 AX，支持规模化、优化与监控。
许多团队会组合多种工具、自研评测框架，或从简单的评测脚本起步。我们的体会是：框架固然能加速进展、统一规范，但它的价值取决于你用它运行什么评测任务。最好的做法通常是快速选一个契合工作流的框架，然后把精力投入评测本身——迭代高质量测试用例与评分器。
延伸阅读：如果你在搭建 Agent 或评测体系，可以继续阅读 FDEChina 的 Agent 专题与 实践指南，也可以了解 FDE 项目生命周期中评测在交付各阶段的定位。
本文由 FDEChina 团队翻译自原文，转载已注明出处；如需引用请以原文为准。