一、这篇文章在说什么
怎样判断一个 Agent 能否可靠完成任务？Anthropic 把问题拆成任务、试跑、评分、环境和长期维护。本篇适合需要制定验收标准、判断模型升级收益的产品经理和工程团队。
二、背景与阅读方式
原文发表于 2026 年 1 月 9 日。它是一篇工程方法文章，结合 Anthropic 与客户实践，不是所有 Agent 场景的统一标准。
以下按原文顺序保留正文、表格、图说、致谢和附录。普通正文是译文；“解读批注”是我的解释。五幅正文图均重绘为中文。原图与正文数值不一致之处保留来源值并单独校核；PDF 第9、10页的两段 YAML 折叠截断，尾部已对照官网展开内容，完整含义改为中文配置表，不作为可执行配置。
三、按原文顺序精读
让 Agent 有用的那些能力，也让它难以评测。能适用于不同部署场景的策略，会组合多种技术，以匹配被测系统的复杂程度。
引言
好的评测能帮助团队更有把握地交付 AI Agent。没有评测，团队很容易陷入被动循环：直到问题出现在生产环境中才发现它，而修好一个问题又引出其他问题。评测能在问题影响用户之前，让问题和行为变化变得可见；它的价值会在 Agent 的整个生命周期中不断累积。
正如我们在《构建有效的 Agent》中所述，Agent 会进行多轮操作：调用工具、修改状态，并根据中间结果调整行动。自主性、智能和灵活性让 AI Agent 有用，同时也让它们更难评测。
通过内部工作，以及与处于 Agent 开发前沿的客户合作，我们学会了如何设计更严谨、更有用的 Agent 评测。下面介绍的是在真实部署中，适用于多种 Agent 架构和使用场景的方法。
解读批注｜概念解释：eval 是用任务和标准检查系统表现。本文讨论开发时的自动化评测，不把一次线上用户满意度反馈等同于评测结论。原文的“我们”指 Anthropic 团队；批注中的示例用于解释，不代表作者或我的实际项目。
一次评测的结构
评测（evaluation，简称 eval）是对 AI 系统进行的一次测试：给 AI 一个输入，再对它的输出应用评分逻辑，衡量是否成功。本文关注的是能在开发期间运行、无需真实用户参与的自动化评测。
单轮评测很直接：一个提示词、一个回答、一套评分逻辑。对早期大语言模型而言，单轮、非 Agent 评测是主要方法。随着 AI 能力提升，多轮评测越来越常见。
图中文字：单轮评测中，提示词询问“某种动物有多少脚趾”，数据指定“动物＝猫”；大语言模型给出回答，再用“回答是否等于 18”的逻辑评分。Agent 评测中，工具包含网页搜索、文件编辑及数据库 MCP 工具；环境包含已安装的 Python、已配置的开发环境、网络访问和沙箱；任务是编写一个连接到应用的 MCP 服务器。Agent 读取文件、搜索 MCP 文档、修改文件、运行 pytest，更新环境后说“我完成了”。评分逻辑实际运行一组测试，确认 MCP 服务器能够工作。
图说：在简单评测中，Agent 处理提示词，评分器检查输出是否符合预期。在更复杂的多轮评测中，编程 Agent 接收工具、任务——这里是构建 MCP 服务器——和环境，执行由工具调用与推理组成的“Agent 循环”，并将实现写入环境。之后通过单元测试验证 MCP 服务器是否正常工作。
Agent 评测更加复杂。Agent 会在多轮操作中使用工具、修改环境状态，并随过程调整行动，这意味着错误可能传播和累积。前沿模型还可能找到超出静态评测设定范围的创造性解法。例如，Opus 4.5 在一个预订航班的 τ²-bench 问题中，发现了政策中的漏洞。按照评测的原始写法，它“失败”了，但实际上为用户找到了更好的解决方案。
构建 Agent 评测时，我们使用以下定义。
- 任务（task，也称 problem 或 test case）：一次具有明确输入和成功标准的测试。
- 试跑（trial）：对某个任务的一次尝试。模型输出在不同运行之间会变化，因此我们会执行多次试跑，得到更一致的结果。
- 评分器（grader）：对 Agent 表现的某个方面进行评分的逻辑。一个任务可以有多个评分器，每个评分器又可以包含多个断言，有时也称检查项。
- 完整运行记录（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 运行框架协作。示例任务是修复身份验证绕过问题；任务包含确定性测试、模型评分细则、状态检查、工具调用检查，并跟踪轮数、工具调用数、Token 和延迟。每个任务有多次试跑，每次保留包含消息、工具调用和推理等内容的完整轨迹。最终结果是环境的最终状态；评分器结合轨迹和最终结果给出分数。图中图例说明：任务＝输入＋成功标准＋评分器＋指标；试跑＝一次执行，轨迹＝完整记录；评分器评价表现的各个方面。
图说：Agent 评测的组成部分。
解读批注｜难点拆解：任务是题目，试跑是答一次题，轨迹是这次的过程记录，最终结果是事情结束后的真实状态。评测框架负责安排考试，Agent 框架负责让模型行动。这两种框架都影响分数，但职责不同。轨迹只包含实际记录或接口提供的信息，不意味着能看到模型全部内部思维。
为什么要构建评测
团队刚开始构建 Agent 时，通过手工测试、自己使用自己的产品，以及直觉，往往就能取得相当多的进展。更严谨的评测甚至可能显得像是拖慢交付的额外负担。但经过早期原型阶段，当 Agent 进入生产环境并开始扩大使用规模时，不做评测的开发方式就会逐渐失效。
转折点通常出现在用户反馈“改完以后 Agent 感觉更差了”的时候。团队却像在盲飞，除了猜测和试错，没有办法验证。没有评测，调试就是被动应对：等待投诉、手工复现、修复问题，再祈祷其他地方没有退步。团队无法区分真实退步与噪声，无法在交付前自动测试数百种场景，也无法衡量改进。
我们多次见过这种过程。例如，Claude Code 最初依靠 Anthropic 员工和外部用户的反馈快速迭代。后来，我们加入评测，先测试回答是否简洁、文件编辑等较窄的领域，再测试过度设计等更复杂的行为。这些评测帮助我们发现问题、指导改进，并让研究与产品团队的合作更聚焦。结合生产监控、A/B 测试、用户研究等方法，评测为持续改进规模不断扩大的 Claude Code 提供了信号。
在 Agent 生命周期的任何阶段编写评测都有价值。早期，评测迫使产品团队说明 Agent 的成功究竟意味着什么；后期，评测帮助维持一致的质量标准。
Descript 的 Agent 帮助用户编辑视频，所以他们围绕成功的视频编辑流程建立了三个评价维度：不要弄坏原有内容、完成用户要求、完成得好。他们从人工评分演进到大语言模型评分器，由产品团队制定标准，并定期进行人工校准；现在，他们定期运行两套独立套件，分别用于质量基准评测和回归测试。Bolt AI 团队在 Agent 已经得到广泛使用后才开始构建评测。在三个月内，他们建立了一个评测系统：运行 Agent，通过静态分析评价输出，使用浏览器 Agent 测试应用，再让大语言模型裁判评价指令遵循等行为。
一些团队在开发之初创建评测，另一些则在规模扩大后、评测成为改进瓶颈时才补上。评测在 Agent 开发初期特别有用，因为它能明确编码预期行为。两位工程师读同一份初始规格，可能对 AI 应如何处理边界情况得出不同理解。评测套件可以消除这种歧义。无论何时建立，评测都有助于加快开发。
评测也会影响你采用新模型的速度。当能力更强的新模型发布时，没有评测的团队可能需要花几周测试；有评测的竞争对手则能快速判断模型优势、调整提示词，并在几天内完成升级。
一旦建立评测，就能顺带获得基线和回归测试：在一组固定任务上持续跟踪延迟、Token 使用量、每个任务的成本和错误率。评测还可以成为产品与研究团队之间信息传递最充分的沟通渠道，定义研究人员可以优化的指标。显然，评测的好处远不止跟踪退步和改进。它的累积价值容易被忽视，因为成本在开始时就可见，而收益会在之后逐步积累。
解读批注｜PM 视角：把“不能退步”写成可以核验的条件。例如升级后仍能正确处理取消、退款、转人工。质量基线要注明模型、工具、提示词、环境和任务集版本。否则分数变化可能来自测试条件，不能直接归因于模型。
如何评测 AI Agent
目前，我们看到几类常见 Agent 被大规模部署，包括编程 Agent、研究 Agent、电脑操作 Agent，以及对话 Agent。每类都可能服务于很多行业，但可以使用相似技术进行评测。你不需要从零发明评测方法。以下介绍几类 Agent 已经验证过的方法。可以以此为基础，再扩展到自己的领域。
解读批注｜阅读提示：原文接下来按评分方式和 Agent 类型展开。分类不是互斥的：研究 Agent 也可能对话、写代码、操作浏览器；应按这次任务的结果和风险选择检查方法。
Agent 的评分器类型
Agent 评测通常组合三类评分器：基于代码、基于模型、人工评分。每个评分器评价运行记录或最终结果中的一部分。有效评测设计的重要组成，是为具体工作选择合适的评分器。
基于代码的评分器
| 方法 | 优点 | 缺点 |
|---|---|---|
| 字符串匹配：精确匹配、正则表达式、模糊匹配等；二元测试：原来失败的测试转为通过、原来通过的测试仍然通过；静态分析：代码规范、类型、安全；最终结果核验；工具调用核验：工具及参数；运行记录分析：轮数、Token 用量 | 快；便宜；客观；可复现；容易调试；能核验特定条件 | 对不完全匹配预期模式、但实际有效的变化很脆弱；难以捕捉细微差别；不适合某些主观任务 |
基于模型的评分器
| 方法 | 优点 | 缺点 |
|---|---|---|
| 按评分细则打分；自然语言断言；成对比较；基于参考答案的评价；多个裁判达成共识 | 灵活；可规模化；能捕捉细微差别；适合开放任务；能处理自由形式输出 | 非确定性；比代码评分更贵；需要与人工评分器校准以保证准确性 |
人工评分器
| 方法 | 优点 | 缺点 |
|---|---|---|
| 领域专家审查；众包判断；抽样检查；A/B 测试；标注者之间的一致性评价 | 具有金标准级别的质量；符合专家用户的判断；用于校准模型评分器 | 昂贵；慢；规模化时通常需要获得大量人类专家支持 |
对每个任务，可以采用加权评分——组合后的评分器分数必须达到阈值——也可以采用二元评分——所有评分器都必须通过——或者混合使用。
解读批注｜机制解释：代码评分适合明确、可验证的事实；模型评分适合有多种合理答案的质量判断；人工用来校准难以机器判断的部分。人工不是天然无误，多人也可能有分歧。加权总分不应掩盖硬性要求：示例中，退款越权属于失败，不能靠语气好把总分补回来。
能力评测与回归评测
能力评测，也称“质量”评测，问的是：“这个 Agent 能把什么做好？”它们应当从较低通过率开始，瞄准 Agent 还不擅长的任务，让团队有明确的提升方向。
回归评测问的是：“Agent 是否仍然能处理以前能处理的全部任务？”其通过率应接近 100%。它们用于防止退步；分数下降意味着某些地方出了问题，需要改进。团队在能力评测上持续提升时，也要运行回归评测，确保改动没有在其他地方引出问题。
Agent 上线并经过优化后，通过率较高的能力评测可以“毕业”，成为持续运行、用于捕捉漂移的回归套件。过去用于衡量“到底能不能做”的任务，转而衡量“现在还能不能可靠地做”。
解读批注｜概念解释：能力套件帮助发现还不会做什么，回归套件保护已经能做的事情。“能力评测起始低通过率”是选题原则，不是故意降低产品质量；回归接近满分也不等于整款产品接近零故障，它只描述选定任务集的表现。
评测编程 Agent
编程 Agent 会编写、测试和调试代码，像人类开发者一样浏览代码库、运行命令。有效的现代编程 Agent 评测，通常依靠明确的任务、稳定的测试环境，以及针对生成代码的充分测试。
确定性评分器很适合编程 Agent，因为软件通常比较容易评价：代码能否运行，测试是否通过？两个广泛使用的编程 Agent 基准——SWE-bench Verified 和 Terminal-Bench——采用了这种思路。SWE-bench Verified 给 Agent 提供热门 Python 仓库中的 GitHub issue，通过运行测试套件评价修复结果；只有修好失败测试、且没有破坏已有测试的方案才算通过。大语言模型在这个评测上的成绩，在一年内从 40% 提升到超过 80%。Terminal-Bench 则走另一条路线：测试端到端技术任务，例如从源码构建 Linux 内核，或训练机器学习模型。
有了一组用于验证编程任务关键结果的通过／失败测试后，往往还值得评价运行记录。例如，基于启发式规则的代码质量检查，能从是否通过测试以外的角度评价代码；具有明确评分细则的模型评分器，则能评价 Agent 如何调用工具、如何与用户互动等行为。
解读批注｜边界说明：原文的 40%→超过80% 是发表时的基准描述，不是截至今天的排名。通过测试证明的是测试覆盖的行为；没被测到的安全漏洞、可维护性问题仍可能存在。fail-to-pass 是把原先失败的测试修好，pass-to-pass 是让原先通过的测试继续通过。
示例：编程 Agent 的假设性评测
设想一个编程任务，要求 Agent 修复身份验证绕过漏洞。原文中的示意 YAML 展示了如何组合评分器和跟踪指标。以下将配置转写为中文说明。
| 配置部分 | 内容 |
|---|---|
| 任务 | 标识为 fix-auth-bypass_1；修复密码字段为空等情况下的身份验证绕过问题 |
| 确定性测试 | 必须通过拒绝空密码、拒绝 null 密码的测试 |
| 模型评分细则 | 按代码质量评分文件评价 |
| 静态分析 | 使用 ruff、mypy、bandit |
| 状态检查 | 安全日志必须包含身份验证被阻止的事件 |
| 工具调用检查 | 读取认证源码、编辑文件、运行测试 |
| 跟踪指标：运行记录 | 对话轮数、工具调用次数、总 Token 数 |
| 跟踪指标：延迟 | 首个 Token 耗时、每秒输出 Token 数、最后一个 Token 耗时 |
注意，这个例子为了说明而展示了全部可用评分器。实际编程评测通常使用单元测试验证正确性，再使用大语言模型评分细则评价整体代码质量；其他评分器和指标只在需要时添加。
解读批注｜配置解读：表中的评分器负责决定通过或分数，跟踪指标负责记录效率和用量，两者不是同一类东西。工具顺序只有在业务有必要约束时才应成为硬标准；这份假设性配置展示检查手段，不是要求所有编程任务照单全用。
评测对话 Agent
对话 Agent 与用户互动，应用于客服、销售或辅导等领域。它们不同于传统聊天机器人：会维护状态、使用工具，并在对话途中采取行动。编程 Agent 和研究 Agent 也可能与用户进行多轮交互，但对话 Agent 有一个独特挑战：交互本身的质量也是评测对象。
有效的对话 Agent 评测，通常依靠可验证的最终状态，以及同时覆盖任务完成和交互质量的评分细则。与大多数其他评测不同，它们往往需要第二个大语言模型模拟用户。我们在对齐审计 Agent中采用了这种方法，通过持续、对抗性的对话对模型进行压力测试。
对话 Agent 的成功可以包含多个维度：工单是否解决——状态检查；是否在少于十轮内完成——运行记录约束；语气是否合适——大语言模型评分细则。τ-Bench及其后继τ²-Bench 都包含这种多维评价。它们模拟零售客服和航班预订等领域的多轮互动：一个模型扮演用户，Agent 则处理真实感较强的场景。
解读批注｜边界说明：模拟用户能批量产生对话，但模拟结果不能替代真实用户研究。这里正文写“少于十轮”，配置写“最多十轮”，边界不同；真正落地时应明确是否允许第十轮，不要让评分器自行猜测。
示例：对话 Agent 的假设性评测
考虑一项客服任务：Agent 需要为一位感到沮丧的客户处理退款。原文 YAML 的配置含义如下。
| 配置部分 | 内容 |
|---|---|
| 模型评分细则 | 按客服质量评分文件检查：是否对客户的沮丧表达同理心；是否清楚解释解决方案；回答是否以获取政策工具返回的结果为依据 |
| 状态检查 | 工单已解决；退款已处理 |
| 工具调用检查 | 核验身份；处理金额不超过 100 的退款；发送确认 |
| 运行记录约束 | 最多十轮 |
| 跟踪指标：运行记录 | 对话轮数、工具调用次数、总 Token 数 |
| 跟踪指标：延迟 | 首个 Token 耗时、每秒输出 Token 数、最后一个 Token 耗时 |
与编程 Agent 的例子一样，这个任务为了说明而展示多种评分器。实践中，对话 Agent 评测通常使用模型评分器同时评价沟通质量和目标完成情况，因为很多任务——例如回答问题——可能有多个“正确”解法。
解读批注｜示例解释：“退款已处理”需要核验业务记录，礼貌地说“已退款”不能替代它。配置里的金额不超过100没有给出币种，不能补成100元。沟通质量与结果状态应分别记录，以便知道失败发生在哪里。
评测研究 Agent
研究 Agent 收集、整合和分析信息，然后生成答案或报告等输出。编程 Agent 可以通过单元测试获得二元通过／失败信号，研究质量却只能相对具体任务判断。什么叫“全面”“来源充分”，甚至“正确”，都依赖上下文：市场扫描、并购尽职调查和科学报告需要不同标准。
研究评测面临特有的挑战：专家可能对综合分析是否全面有不同意见；参考内容不断变化，使真实答案也在变化；更长、更开放的输出为错误留下更多空间。例如，BrowseComp基准测试 AI Agent 能否在开放网络中“大海捞针”，其问题被设计为容易验证、但难以解决。
构建研究 Agent 评测的一种策略，是组合评分器类型。依据性检查验证主张是否由检索到的来源支持；覆盖度检查定义好答案必须包含哪些关键事实；来源质量检查确认来源是否权威，而不只是最先搜到。对存在客观正确答案的任务，例如“X 公司第三季度营收是多少”，可以使用精确匹配。大语言模型可以标记缺乏支持的主张和覆盖遗漏，也可以评价开放式综合分析是否连贯、完整。
研究质量具有主观性，因此应经常用人类专家判断校准大语言模型评分细则，才能有效评价这类 Agent。
解读批注｜概念解释：依据性、覆盖度和来源质量回答三个不同问题：证据支持结论吗，关键问题答全了吗，证据来源可靠吗。引用数量多不保证这三项都好。用于历史营收核验的标准答案，还要固定报告期、币种和来源版本。
电脑操作 Agent
电脑操作 Agent 通过与人类相同的界面与软件互动：截图、鼠标点击、键盘输入和滚动，而不是通过 API 或代码执行。它们可以使用任何具有图形用户界面的应用，从设计工具到传统企业软件。评测需要让 Agent 在真实环境或沙箱环境中操作应用，并检查它是否达到了预期结果。例如，WebArena通过 URL 和页面状态检查验证浏览器导航，对修改数据的任务还核验后端状态——确认订单真的已提交，而不只是显示了确认页面。OSWorld将评测扩展到完整操作系统控制；任务完成后，评测脚本检查文件系统状态、应用配置、数据库内容和界面元素属性等多种产物。
浏览器操作 Agent 需要平衡 Token 效率和延迟。基于 DOM 的交互执行快，但消耗很多 Token；基于截图的交互更慢，但 Token 效率更高。例如，让 Claude 总结维基百科时，从 DOM 提取文本更有效率。到 Amazon 寻找新的笔记本电脑保护套时，截图则更有效率，因为提取完整 DOM 会消耗大量 Token。在 Claude for Chrome 产品中，我们构建评测，检查 Agent 是否为每种情境选择了正确工具。这帮助我们更快、更准确地完成浏览器任务。
解读批注｜概念解释：DOM 是网页的结构表示，可以理解为浏览器读到的页面元素和文本。截图更接近人看到的画面。原文的速度与Token比较来自其应用场景，不能直接推成所有网页都适用的定律；页面大小、工具实现和模型能力都会影响结果。
如何理解 Agent 评测中的非确定性
无论属于哪类，Agent 在不同运行之间的行为都会变化，因此评测结果比表面看上去更难解释。每个任务都有自己的成功率：可能在一个任务上是 90%，另一个上是 50%；某次评测中通过的任务，下次又可能失败。有时，我们想衡量的是 Agent 在某个任务上多大比例的试跑能成功。
两个指标有助于描述这种差别。
pass@k 衡量 Agent 在 k 次尝试中至少获得一个正确解法的概率。随着 k 增大，pass@k 会升高：尝试机会更多，至少成功一次的可能性也更高。pass@1 为 50%，意味着模型在评测中第一次尝试时能完成一半任务。在编程场景，我们通常最关心第一次尝试就找到解法，即 pass@1。其他场景中，只要有一个方案有效，提出多个候选也可能是合理的。
pass^k 衡量全部 k 次试跑都成功的概率。随着 k 增大，pass^k 会下降，因为要求更多次运行保持一致，是更高的标准。如果 Agent 每次试跑的成功率是 75%，运行三次，三次全部通过的概率就是 0.75³，约等于 42%。对面向客户的 Agent，这个指标尤其重要，因为用户期望每次都能可靠完成任务。
图中文字：横轴是试跑次数 k，纵轴是成功率。pass@k 表示“k 次中至少一次成功”，随着 k 增大趋向 100%；原图标注三次为 97%。pass^k 表示“全部 k 次成功”，随着 k 增大趋向 0%；原图标注三次为 39%。原图未给出完整数值表或明确的单次成功概率。
图说：随着试跑次数增加，pass@k 和 pass^k 会分离。k＝1 时两者相同，均等于单次成功率。到了 k＝10，原图说明它们呈现相反趋势：pass@k 接近 100%，pass^k 降向 0%。
译注：原图三次的 97%／39% 标注，与正文的 75% 单次成功率示例并不一致。中文图保留原图明确标注，并另列正文示例的计算校核。若每次成功概率相同且试跑相互独立，75% 单次成功率对应三次至少成功一次为 98.4375%，三次全部成功为 42.1875%；十次全部成功仍为约 5.63%，不等于零。不能由原图反推一组精确的未公开数据。
两个指标都有用，选择取决于产品要求：只要成功一次就有价值的工具适合 pass@k；一致性至关重要的 Agent 适合 pass^k。
解读批注｜指标与假设：在单次成功概率相同且各次独立的简化情形下，至少一次成功＝1−(1−p)^k，全部成功＝p^k。共享缓存、同一环境故障或会学习的Agent可能破坏独立假设。pass@k也不是只要重试就一定把好结果交给用户：系统还要能识别哪次成功、承担相应成本。
从零到一：构建优秀 Agent 评测的路线图
本节给出经过实践检验的建议，帮助团队从没有评测，走到拥有可信评测。可以将它看作评测驱动的 Agent 开发路线图：尽早定义成功、清楚衡量表现、持续迭代。
为初始评测数据集收集任务
第 0 步：尽早开始
我们看到有些团队推迟构建评测，因为认为需要准备数百个任务。实际上，从真实失败中提取 20—50 个简单任务，就是一个很好的开始。毕竟，在 Agent 开发早期，每次系统改动通常都会产生清楚、可察觉的影响。这种较大的效应量意味着小样本就足够。更成熟的 Agent 可能需要更大、更难的评测，才能检测更小的变化，但开始时最好采用 80/20 的思路。等得越久，评测越难构建。早期，产品需求自然可以转成测试用例；拖得太久，就变成从线上系统倒推成功标准。
解读批注｜边界说明：20—50题是开始建立反馈循环的建议，不是用几十题就能证明生产可靠性。低频严重错误、不同用户群和任务类型需要另外覆盖。先让评测可运行，再增加能改变产品判断的任务。
第 1 步：从已经在手工测试的内容开始
从开发过程中已有的手工检查开始：每次发布前验证的行为，以及最终用户常做的任务。如果已经上线，查看缺陷跟踪系统和客服队列。把用户报告的失败转成测试用例，可以确保套件反映真实使用；按用户影响排序，则能把精力投入最有价值的地方。
解读批注｜PM 视角：用户失败可以转成任务，但要补齐复现条件、成功标准和验收证据。高频失败不一定风险最高；一次不可逆的错误也可能比许多低影响问题更该优先处理。
第 2 步：编写无歧义的任务，并提供参考解法
把任务质量做好，比看起来更难。好的任务应该让两位领域专家独立得出相同的通过／失败结论。他们自己能通过这个任务吗？不能的话，就需要完善任务。任务规格的歧义会变成指标中的噪声。模型评分器的标准也是如此：模糊的评分细则会产生不一致判断。
每个任务都应当能被正确遵循指令的 Agent 完成。这里的细节可能很隐蔽。例如，审计 Terminal-Bench 时发现，如果任务只要求 Agent 编写一个脚本，没有指定文件路径，而测试却默认脚本位于特定路径，Agent 就可能在自己没有做错的情况下失败。
评分器检查的所有内容，都应当在任务描述中说明清楚；Agent 不应该因为规格含糊而失败。对前沿模型，如果多次试跑的通过率都是 0%，即 pass@100＝0%，通常更可能是任务出了问题，而不是 Agent 没有能力。这时应该重新检查任务规格和评分器。每个任务最好提供参考解法：一个已知有效、能通过全部评分器的输出。它既能证明任务可解，也能验证评分器配置正确。
解读批注｜边界说明：参考解法用于证明题目可解、评分器可工作，不代表Agent必须复制同一答案或路线。“多次零通过优先检查题目”是作者的经验判断，不能推成所有零分都由题目导致。模型确实可能缺乏该能力。
第 3 步：构建平衡的题集
既要测试某种行为应该发生的情形，也要测试不应该发生的情形。单向评测会产生单向优化。例如，如果只测试 Agent 该搜索时有没有搜索，最后可能得到一个几乎什么问题都搜索的 Agent。尽量避免类别不平衡的评测。
我们在为 Claude.ai 的网页搜索构建评测时，亲身遇到过这个问题：既要防止模型在不该搜索时搜索，也要保留它在合适情境中深入研究的能力。团队同时加入两类任务：应该搜索的问题，例如查天气；以及应该根据已有知识回答的问题，例如“谁创办了 Apple”。平衡漏触发——该搜索却没有搜索——和过度触发——不该搜索却搜索——很难，需要多轮调整提示词和评测。新问题出现后，我们会继续加入评测，提高覆盖度。
解读批注｜具体例子：一个假设的写入工具评测应同时检查“条件满足时正确写入”和“未获授权时保持不写”。如果只奖励写入成功，系统可能学会忽略禁止条件。正反任务覆盖的是行为边界，不只是数量各占一半。
设计评测框架和评分器
第 4 步：构建稳健的评测框架与稳定环境
评测中的 Agent，其运行方式应与生产环境中的 Agent 大致一致；环境本身不应引入额外噪声。每次试跑都应从干净环境开始，实现隔离。不必要的共享状态，例如残留文件、缓存数据或资源耗尽，会让多个试跑因基础设施不稳定而一起失败，而不是因为 Agent 表现不好。共享状态也可能人为抬高成绩。例如，一些内部评测中，我们观察到 Claude 检查之前试跑留下的 Git 历史，从而在某些任务上获得不公平优势。
如果多个不同试跑因为同一种环境限制——例如 CPU 内存不足——而失败，它们就不是独立的，因为都受同一因素影响。这会让评测结果无法可靠衡量 Agent 表现。
解读批注｜机制解释：隔离不是只把日志分开。测试前的文件、数据库、缓存、账户权限和资源状态都可能需要恢复。环境失败应单独归类；把它混进模型错误，会把修基础设施的问题误判成换模型的问题。
第 5 步：认真设计评分器
如前所述，好的评测设计需要为 Agent 和任务选择最佳评分器。我们建议：能用确定性评分器时就用；有必要或需要更多灵活性时使用大语言模型评分器；谨慎使用人工评分器补充验证。
人们常想检查 Agent 是否遵循非常具体的步骤，例如是否按指定顺序调用工具。我们发现这种方法过于僵硬，会形成很脆弱的测试，因为 Agent 经常找到评测设计者没有预料到的有效方法。为了避免不必要地惩罚创造性，往往更适合评价 Agent 产出了什么，而不是它走了哪条路径。
对于包含多个部分的任务，应设置部分得分。客服 Agent 正确识别问题、核验客户身份，但没有完成退款，显然比刚开始就失败的 Agent 更好。结果应体现这种从失败到成功的连续程度。
模型评分通常需要反复迭代，才能验证准确性。大语言模型裁判应与人类专家密切校准，以确保人工与模型评分之间没有明显偏差。为避免幻觉，可以给模型保留退路，例如在信息不足时返回“未知”。还可以为任务的每个维度建立清楚、结构化的评分细则，并分别使用相互隔离的大语言模型裁判评分，而不是由一个模型评价全部维度。系统变得稳健后，偶尔人工复核就足够。
一些评测有细微的失效方式：即使 Agent 表现不错，也会因为评分错误、Agent 框架限制或任务含糊而得到低分。成熟团队也可能漏掉这些问题。例如，Opus 4.5 在 CORE-Bench 上最初得分为 42%；后来，Anthropic 一位研究人员发现多项问题：僵硬的评分规则会因为期望“96.124991…”而惩罚“96.12”，任务规格存在歧义，还有无法精确复现的随机任务。修复问题并使用限制更少的框架后，Opus 4.5 的分数升至 95%。
类似地，METR 在时间跨度基准中发现多项配置错误：任务要求 Agent 优化到某个分数阈值，但评分却要求超过该阈值。这会惩罚遵循指令的 Claude 等模型，反而让忽略目标的模型得到更好成绩。仔细检查任务与评分器，有助于避免这些问题。
让评分器能够抵御绕过和投机。Agent 不应该轻易“作弊”。任务和评分器的设计，应确保通过真正依靠解决问题，而不是利用意外漏洞。
解读批注｜校准与归因：CORE-Bench从42%到95%同时涉及修题、修评分和减少框架限制，不能解释成模型单独提升了53个百分点。部分得分用于诊断；是否达到上线门槛仍需按完整结果和硬约束判断。“信息不足返回未知”能减少强行判断，也要报告未知比例。
长期维护和使用评测
第 6 步：检查完整运行记录
如果不阅读大量试跑的运行记录和分数，你不会知道评分器是否运行良好。在 Anthropic，我们投入资源建设查看评测运行记录的工具，并定期花时间阅读。任务失败时，运行记录能告诉你：Agent 是否真的犯了错误，还是评分器拒绝了有效解法。它也常常揭示 Agent 和评测行为的重要细节。
失败应该显得公平：能清楚看出 Agent 错在哪里、为什么错。分数不提升时，我们需要确信原因是 Agent 表现，而不是评测本身。阅读运行记录，是验证评测是否衡量真正重要内容的方法，也是 Agent 开发中的关键技能。
解读批注｜PM 视角：读记录时应先分清四类原因：Agent错误、任务歧义、评分器误判、环境故障。同一个“不通过”可能对应四种修法。还要抽查高分案例，防止系统通过了评分，却没有真正完成任务。
第 7 步：监测能力评测是否饱和
一个得分 100% 的评测可以跟踪退步，却无法提供改进信号。当 Agent 通过全部可解任务，没有提升空间时，评测就饱和了。例如，SWE-bench Verified 分数在原文所述阶段从 30% 起步，前沿模型现在达到超过 80%，接近饱和。评测接近饱和时，进展也会变慢，因为只剩最难的任务。这可能使结果具有误导性：很大的能力提升，只表现为分数小幅增加。
例如，代码审查初创公司 Qodo 最初觉得 Opus 4.5 没有明显改善，因为单次编程评测没有捕捉更长、更复杂任务上的收益。为此，他们开发了新的 Agent 评测框架，让进展变得清晰得多。
通常，在有人深入检查评测细节、阅读部分运行记录之前，我们不会照单全收评测分数。如果评分不公平、任务含糊、有效解法受到惩罚，或框架限制了模型，就应该修改评测。
解读批注｜概念解释：饱和不是到80%就自动发生。作者提到的是具体基准当时的状态。要看剩余题能否区分能力，以及分数是否仍能影响决策。旧题可以继续保护回归，另外加入更长、更复杂、确实有业务价值的新任务。
第 8 步：通过开放贡献与维护，让评测套件长期保持健康
评测套件是一份持续演进的产物；要保持有用，需要持续投入和明确负责人。
在 Anthropic，我们尝试了不同维护方式。最有效的是由专门的评测团队负责核心基础设施，而领域专家和产品团队贡献大多数任务，并自行运行评测。
对 AI 产品团队而言，拥有和迭代评测，应当像维护单元测试一样日常。团队可能在某项 AI 功能上浪费数周：早期测试看似“能工作”，却不符合那些没有明说的期望；设计良好的评测本可以早早发现这些问题。定义评测任务，是检查产品需求是否具体到足以开始开发的最佳方法之一。
我们建议采用评测驱动的开发：先用评测定义计划中的能力，即使 Agent 目前尚不能完成，再持续迭代直到表现良好。在内部，我们常构建今天已经“够用”、但也押注未来几个月模型能力的功能。起始通过率较低的能力评测能把这类押注呈现出来。新模型发布后，运行套件就能快速看出哪些押注兑现了。
最接近产品需求和用户的人，最适合定义成功。以当前模型能力，产品经理、客户成功经理或销售人员，都能用 Claude Code 以 PR 的形式贡献评测任务——让他们参与！更好的是，主动帮助他们这样做。
图中文字：评测套件开发包含第 0 步尽早开始、第 1 步从手工测试开始、第 2 步编写无歧义任务、第 3 步覆盖正反两类情况；框架开发包含第 4 步构建稳健评测框架、第 5 步认真设计评分器；评测维护包含第 6 步检查执行轨迹、第 7 步监测饱和、第 8 步长期维护。
图说：创建有效评测的过程。
解读批注｜PM 视角：产品团队定义用户任务和成功证据，领域专家校准正确性，工程团队提供可靠执行与记录。明确题集负责人、版本和维护入口，比只有一个总分更有利于持续迭代。评测驱动开发，是先把验收标准写清，再实现功能。
评测如何与其他方法配合，形成对 Agent 的完整理解
自动化评测无需上线到生产环境，也不会影响真实用户，就可以在数千个任务上测试 Agent。但它只是了解表现的多种方法之一。完整的图景还包括生产监控、用户反馈、A/B 测试、手工阅读运行记录，以及系统性的人工评价。
解读批注｜阅读提示：下面是原文对六种质量理解方法的比较。离线测评、线上监控、用户反馈和人工判断各有盲区。线上的真实行为可以作为观察依据，却不自动提供每次任务的正确标准答案。
了解 AI Agent 表现的方法概览
自动化评测：以程序运行测试，无需真实用户
优点：迭代更快；完全可复现；不影响用户；可以在每次代码提交时运行；无需生产部署，就能规模化测试场景。
缺点：前期构建投入更大；产品和模型演进时需要持续维护，避免漂移；如果与真实使用模式不符，可能带来虚假的信心。
生产监控：跟踪线上系统的指标与错误
优点：规模化揭示真实用户行为；发现合成评测漏掉的问题；为 Agent 实际表现提供真实依据。
缺点：被动应对，发现之前问题已触达用户；信号可能有噪声；需要投入建设埋点和观测能力；缺少用于评分的真实标准答案。
A/B 测试：用真实用户流量比较不同方案
优点：衡量实际用户结果，例如留存和任务完成；控制混杂因素；可规模化且系统化。
缺点：慢，需要数天或数周及足够流量才能达到统计显著性；只能测试已经部署的改动；如果无法充分阅读运行记录，就难以解释指标为什么变化。
用户反馈：点踩或缺陷报告等显式信号
优点：揭示未预料的问题；提供真实人类用户的真实案例；反馈往往与产品目标相关。
缺点：稀疏且存在自我选择偏差；更偏向严重问题；用户很少解释为什么失败；不能自动化；主要依靠用户发现问题，可能给用户带来负面影响。
人工阅读运行记录：由人阅读 Agent 的对话
优点：形成对失效方式的直觉；发现自动检查漏掉的细微质量问题；帮助校准“好”的标准，并理解细节。
缺点：耗时；难以规模化；覆盖不一致；审阅疲劳或人员不同会影响信号质量；通常提供定性信息，而不是清楚的定量评分。
系统性人工研究：由经过培训的评价者结构化评分
优点：多位评价者提供金标准级别的质量判断；能够处理主观或含糊任务；为改进模型评分器提供信号。
缺点：相对昂贵，反馈慢；难以频繁运行；评价者之间的分歧需要协调；法律、金融、医疗等复杂领域需要专家开展研究。
这些方法对应 Agent 开发的不同阶段。自动化评测尤其适合上线前和持续集成／持续交付阶段，在每次 Agent 改动和模型升级时运行，作为质量问题的第一道防线。上线后，生产监控用于发现分布漂移及未预料的真实失败。拥有足够流量后，A/B 测试用于验证重要改动。用户反馈与运行记录阅读是持续实践，用来填补空白：持续分类处理反馈，每周抽样阅读运行记录，并按需要深入调查。系统性人工研究则留给校准大语言模型评分器，或评价以人类共识作为参考标准的主观输出。
图中文字：自动化评测在部署前提供测量、基准测试、基线表现，以及上线前的退步捕捉；人工阅读运行记录与早期体验计划，捕捉细微问题、发现意料之外的用户或 Agent 行为；生产监控、A/B 测试与用户反馈，呈现规模化后的真实使用模式、边界情况和失效模式。
图说：就像安全工程中的瑞士奶酪模型，没有任何一层评测能发现所有问题。组合多种方法后，漏过某一层的失败，可以被另一层发现。
最有效的团队组合使用这些方法：自动化评测用于快速迭代，生产监控提供实际表现依据，定期人工审查用于校准。
解读批注｜边界说明：原文把自动化评测概括为“完全可复现”，应理解为流程和测试条件可记录、可重新执行，不是每次必得同一答案。非确定性仍然存在。多层检查降低漏检风险，但它们若共享同一误判标准，也可能同时漏掉问题。
结论
没有评测的团队会陷入被动循环：修好一个问题，引出另一个，无法区分真实退步与噪声。尽早投入评测的团队会发现相反情况：失败变成测试用例，测试用例防止退步，指标替代猜测，开发因此加快。评测让全团队有明确的提升目标，把“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提供 Phoenix，这是用于大语言模型追踪、调试及离线或在线评测的开源平台；还提供 AX 这一 SaaS 产品，在 Phoenix 基础上扩展规模化、优化和监控能力。
很多团队组合多个工具、自己构建评测框架，或从简单评测脚本开始。我们的经验是：框架能加快进展、帮助标准化，但其效果取决于其中运行的评测任务。通常最好快速选择一个符合工作流的框架，然后把精力投入评测本身，迭代高质量测试用例和评分器。
四、PM 视角：如何把这篇文章用于判断
作者反复强调的工作是定义成功，并核验实际结果。对产品经理，可以把需求中的“体验好”“准确”“可靠”，继续拆成任务条件、验收证据和失败边界。
下面是一个用于理解的假设示例：给数据查询 Agent 的任务是“查询上季度某渠道的有效订单数”。验收至少需要明确季度、渠道、有效订单口径、权限和数据来源。SQL 能执行是一项检查，结果符合口径是另一项检查；数字正确但引用错表，也值得单独记录。示例没有使用真实项目数据。
| 判断问题 | 应保留的证据 |
|---|---|
| 用户要的事完成了吗 | 交付物或业务系统最终状态 |
| 过程有没有越过边界 | 工具参数、权限、关键动作及日志 |
| 改动是否带来退步 | 固定回归套件、前后版本与运行条件 |
| 表现是否稳定 | 多次运行结果及失效原因分类 |
| 分数可信到什么程度 | 参考解法、裁判校准、人工抽查和未知比例 |
这套工作不要求产品经理亲自搭建全部基础设施，但需要与专家、工程同事共同维护“什么算成功”。不要把部分得分、公开榜单或一次成功直接当成业务交付已验收。
评测可信，要经过几次不同的判断
下面是本文对原文的进一步解读，不属于译文。可以把评测看成一条证据链：用户需求决定题目，题目决定成功标准，执行过程产生证据，评分器根据证据判断，团队再据此决定是否交付。
链条上每一步都可能出错。用户需要“当前身份可见的有效订单数”，题目却只写“订单数”，即使 Agent 完成题目、裁判也判对了，仍然不能证明需求被满足。题目写清了，但参考答案使用旧口径，分数又会惩罚正确行为。执行记录缺少最终状态时，裁判可能把一句“已完成”当成完成证据。
因此，“评分器与人工判断一致”只解决判分这一段，不能替代题目与需求的对应检查。自动评分有明确依据，才值得讨论扩大运行规模；规模不会补回缺失的业务定义。
平均分与交付结论，为什么要分开
假设一个建议生成 Agent 能找到正确账户、算对指标、写出清楚建议，却擅自修改了预算。如果将四项检查简单平均，它可能拿到较高分；但用户授权的是建议，未经确认写入就是本次任务的交付失败。这个案例是教学设计，未使用任何真实系统数据。
分项得分适合定位改进，交付结论需要按事前确认的约束判断。账户识别、计算正确、证据充分等项目可以分别记录；是否越过授权范围则要独立检查。必需条件之间不能靠高分相互抵消。哪些条件必须满足，由具体业务定义，不能从一份通用基准直接搬来。
这也解释了为什么要阅读高分案例。只抽查低分，容易漏掉“评分表奖励了错误结果”的问题：看似优秀的回答，可能恰好暴露评价标准的缺口。
“未知”不能被悄悄变成通过，也不能从报告中消失
假设八次任务中，六次确认成功，一次确认失败，一次因最终状态日志缺失无法判定。确认成功占全部任务的 6/8，即 75%；只在已判定任务中算通过率，则是 6/7，约 85.7%；已判定覆盖率是 7/8，即 87.5%。这三个数字描述不同问题，不能只选最高的一个展示。
那一次未知没有被宣布为业务失败；但当前证据也不支持将它算作成功。如果未知集中在写入后的状态确认，问题可能恰恰出现在最关键的交付环节。应先查明未知原因，并报告它在什么场景出现，而不是仅提高已判定样本的通过率。
离线通过之后，还缺什么
离线套件只能说明：在已定义的任务、环境与规则下，系统得到了哪些结果。它不能自动证明真实用户遇到的问题都已覆盖，也不能保证外部数据更新后仍然正确。
一个可执行的产品判断应保留四件事：已经验证的能力范围；尚未覆盖的任务与条件；会阻止交付的失败类型；上线后用什么证据发现遗漏。例如，离线测试固定了订单数据，就要另外安排线上数据变动与权限变化的检查。观察发现新问题后，再把可复现的任务加入回归套件。
这样，评测不是一次性盖章，而是帮助团队持续回答两个问题：这次改动解决了什么；哪些原有能力可能同时退步。数字是入口，任务和证据才让判断可复查。
五、延伸阅读方向
- 评分器是否判断正确：裁判校准、参考解法与误判分析。
- 评测环境是否改变分数：资源限制、试跑隔离与基础设施噪声。
- 线上结果与离线套件如何互相补充：用户反馈、回归任务和数据漂移。
原文与翻译说明
原文：Demystifying evals for AI agents。作者：Mikaela Grace、Jeremy Hadfield、Rodrigo Olivares、Jiri De Jonghe。本文译文来自用户提供的PDF，英文配图重绘为中文；解读批注、PM示例与图中校核均已标记。模型分数和框架介绍保留原文发表时语境。