# 理解 AI Agent 评估：方法与实践 作者：Hex4C59 · 发布于 2026-10-10 原文：https://hex4c59.cc/translations/demystifying-evals-for-ai-agents/ > **译文信息** > > - 原文：[Demystifying evals for AI agents](https://www.anthropic.com/engineering/demystifying-evals-for-ai-agents) > - 作者：Mikaela Grace、Jeremy Hadfield、Rodrigo Olivares、Jiri De Jonghe > - 原文发布：2026-01-09 > - 中文翻译：Hex4C59 > - 翻译整理：2026-10-10 > > 本文为非官方中文译文。正文中的「我们」指原文作者及其团队；模型版本、产品能力和评估结果均保留原文记录，译者未独立复现实验。文中的「今年」「如今」等时间表述，均以原文发布日期为参照。 Agent 能自主调用工具、修改环境，并根据中间结果调整行动。这些能力让 Agent 变得有用，也让它们更难评估。要评估不同部署场景中的复杂系统，需要结合多种方法。 ## 引言 良好的评估能帮助团队更有信心地交付 AI Agent。如果没有评估，团队很容易陷入被动应对的循环：只有到了生产环境才发现问题，修复一个故障又引发其他故障。评估让问题和行为变化在影响用户之前就显现出来，其价值也会在 Agent 的整个生命周期中不断累积。 正如我们在 [Building effective agents](https://www.anthropic.com/research/building-effective-agents) 中所描述的，Agent 会在多个交互轮次中运行：调用工具、修改状态，并根据中间结果调整行动。让 AI Agent 有用的这些能力——自主性、智能和灵活性——也让它们更难评估。 通过内部实践，以及与处于 Agent 开发前沿的客户合作，我们逐渐掌握了如何为 Agent 设计更严谨、更有用的评估。以下介绍的是，在实际部署的多种 Agent 架构和应用场景中行之有效的方法。 ## 一项评估的组成 评估（evaluation，简称 eval）是对 AI 系统的一项测试：给 AI 一个输入，再通过评分逻辑评价它的输出，衡量它是否成功。本文重点讨论那些可以在开发过程中运行、不需要真实用户参与的自动化评估。 单轮评估很直接：一个提示、一个回答，以及一套评分逻辑。对于早期的大语言模型，单轮、非 Agent 式的评估是主要方法。随着 AI 能力发展，多轮评估变得越来越常见。 > **原文图注**：在简单评估中，Agent 处理一个提示，评分器检查输出是否符合预期。在更复杂的多轮评估中，编程 Agent 会获得工具、任务和环境；此处的任务是构建一个 MCP 服务器。Agent 执行由工具调用和推理组成的「Agent 循环」，将实现写入环境。之后，评分阶段使用单元测试，验证 MCP 服务器能否正常工作。 Agent 评估更加复杂。Agent 在多个轮次中使用工具，修改环境中的状态，并在执行过程中调整策略，这意味着错误可能传播并不断累积。前沿模型还能找到富有创造性的解决方案，超出静态评估所能覆盖的范围。例如，Opus 4.5 在解决 τ2-Bench 中的一道机票预订问题时，发现了政策中的一个漏洞。按照原有评估规则，它「失败」了，但实际上却为用户找到了更好的解决方案。 在构建 Agent 评估时，我们采用以下定义： - **任务（task）**：也称问题（problem）或测试用例（test case），指一项具有明确输入和成功标准的独立测试。 - **试验（trial）**：对一项任务的一次尝试。由于模型每次运行的输出可能不同，我们会进行多次试验，以获得更稳定的结果。 - **评分器（grader）**：对 Agent 表现的某个方面进行评分的逻辑。一项任务可以使用多个评分器，每个评分器又可以包含多条断言（assertions），有时也称检查项（checks）。 - **执行记录（transcript）**：也称追踪记录（trace）或轨迹（trajectory），指一次试验的完整记录，包括输出、工具调用、推理、中间结果及其他交互。对于 Anthropic API，它是评估运行结束时完整的 `messages` 数组，包含评估期间对 API 的所有调用，以及返回的所有响应。 - **最终结果（outcome）**：试验结束时，环境中的最终状态。一个机票预订 Agent 可能会在执行记录末尾说「您的机票已经预订」，但最终结果要看环境中的 SQL 数据库里是否真的存在预订记录。 - **评估 Harness（evaluation harness）**：端到端运行评估的基础设施。它提供指令和工具，并发运行任务，记录全部步骤，对输出评分，并汇总结果。 - **Agent Harness**：也称支撑框架（scaffold），指让模型能够作为 Agent 行动的系统：处理输入、编排工具调用并返回结果。当我们评估「一个 Agent」时，实际评估的是 Harness 与模型共同工作的表现。例如，Claude Code 是一个灵活的 Agent Harness；我们通过 Agent SDK 使用它的核心基础能力，构建了面向长期运行任务的 Agent Harness。 - **评估套件（evaluation suite）**：为了衡量特定能力或行为而设计的一组任务。套件中的任务通常具有一个共同的总体目标。例如，客服评估套件可能测试退款、取消和升级处理等场景。 > **原文图注**：Agent 评估的组成部分。 ## 为什么要构建评估 团队刚开始开发 Agent 时，结合人工测试、内部试用和直觉，就可能取得出乎意料的进展。更严谨的评估甚至看起来像是拖慢交付的额外负担。但在早期原型阶段之后，一旦 Agent 上线并开始扩大使用规模，没有评估的开发方式就开始失灵。 转折点往往出现在用户反馈「改动后 Agent 感觉变差了」的时候：团队仿佛在盲飞，除了猜测和试错，没有办法验证。缺少评估时，调试只能被动进行：等待投诉、手动复现、修复缺陷，然后希望其他地方没有退步。团队无法区分能力确实退步和运行中的偶然波动，无法在交付前自动测试数百种场景，也无法衡量改进幅度。 我们多次见过这样的发展过程。例如，Claude Code 最初依靠 Anthropic 员工和外部用户的反馈快速迭代。后来，我们加入了评估：先覆盖简洁性、文件编辑等范围较窄的方面，再扩展到过度设计等更复杂的行为。这些评估帮助我们发现问题、指导改进，并让研究与产品团队的合作更有重点。结合生产监控、A/B 测试、用户研究等方法，评估为 Claude Code 在扩大规模的过程中持续改进提供了信号。 在 Agent 生命周期的任何阶段，编写评估都有用。早期，评估迫使产品团队明确 Agent 的成功究竟意味着什么；后期，评估帮助维持一致的质量标准。 Descript 的 Agent 帮助用户编辑视频，因此他们围绕成功编辑工作流的三个维度构建评估：别把东西弄坏、完成我要求的事情，并且把它做好。他们从人工评分逐步发展为大语言模型评分器，由产品团队定义标准，并定期用人工判断校准；如今，他们会定期运行两套独立的评估套件，分别用于质量基准测试和回归测试。Bolt AI 团队则较晚才开始构建评估，当时他们已经拥有一个广泛使用的 Agent。在三个月内，他们建立了一套评估系统：运行 Agent，通过静态分析为输出评分，使用浏览器 Agent 测试应用，并用大语言模型裁判评价指令遵循等行为。 有些团队从开发之初就创建评估；另一些团队则在规模扩大、评估成为改进 Agent 的瓶颈后才补上。评估在 Agent 开发早期尤其有用，可以把预期行为明确地写下来。两位工程师阅读同一份初始规格，可能会对 AI 应当如何处理边界情况得出不同理解。评估套件能够消除这种歧义。无论何时建立，评估都有助于加快开发。 评估还会影响你采用新模型的速度。当更强的模型发布时，没有评估的团队可能需要数周测试；而具备评估的竞争对手，可以快速判断模型的优势、调整提示，并在几天内完成升级。 一旦有了评估，你就顺带获得了基线与回归测试：可以在一组固定任务上追踪延迟、token 用量、单任务成本和错误率。评估也能成为产品与研究团队之间传递信息最有效的渠道，帮助研究人员明确可以优化的指标。评估的好处远不止追踪回归和改进。由于成本一开始就看得见，而收益会在之后逐步积累，人们很容易忽视它不断累积的价值。 ## 如何评估 AI Agent 我们如今看到几类常见 Agent 已被大规模部署，包括编程 Agent、研究 Agent、计算机操作 Agent 和对话 Agent。每一类都可能应用于多种行业，但可以使用相似的技术来评估。你不必从零发明一套评估方法。下面介绍几类 Agent 已经验证有效的方法，你可以以此为基础，再扩展到自己的领域。 ### Agent 评分器的类型 Agent 评估通常结合三类评分器：基于代码的、基于模型的，以及人工评分器。每个评分器评价执行记录或最终结果中的某一部分。有效评估设计的重要一环，就是为任务选择合适的评分器。 **基于代码的评分器** | 方法 | 优点 | 局限 | |---|---|---| | 字符串匹配检查：精确匹配、正则表达式、模糊匹配等。
二元测试：从失败变为通过、保持原有通过状态。
静态分析：lint、类型、安全检查。
最终结果验证。
工具调用验证：使用的工具及参数。
执行记录分析：交互轮数、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 如何调用工具、如何与用户交互等行为。 **示例：一个假想的编程 Agent 评估** 考虑这样一项编程任务：Agent 必须修复一个身份验证绕过漏洞。下面的示意 YAML 展示了如何同时使用评分器和指标来评价它。示例保留原文内容，属于评估配置示意，不是本博客的可运行配置。 ```yaml 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 ``` 这个例子为了说明问题，展示了各类可用的评分器。在实践中，编程评估通常依靠单元测试验证正确性，再用大语言模型评分标准评价整体代码质量；只有在需要时，才加入额外的评分器和指标。 ### 评估对话 Agent 对话 Agent 在客服、销售或辅导等领域与用户交互。与传统聊天机器人不同，它们会维护状态、使用工具，并在对话过程中采取行动。虽然编程和研究 Agent 也可能与用户进行多轮交互，但对话 Agent 面临一个独特挑战：交互本身的质量，也是评估对象的一部分。有效的对话 Agent 评估，通常依赖可验证的最终状态，以及同时涵盖任务完成情况和交互质量的评分标准。与大多数其他评估不同，它们往往需要第二个大语言模型模拟用户。我们在对齐审计 Agent 中使用这种方法，通过长时间的对抗性对话对模型进行压力测试。 对话 Agent 的成功可以有多个维度：工单是否解决，通过状态检查判断；是否在少于 10 轮交互内完成，通过执行记录约束判断；语气是否恰当，通过大语言模型评分标准判断。τ-Bench 及其后续版本 τ2-Bench，就是包含多个维度的两项基准测试。它们模拟零售客服、机票预订等领域的多轮交互：一个模型扮演特定用户角色，Agent 则在贴近现实的场景中处理问题。 **示例：一个假想的对话 Agent 评估** 考虑这样一项客服任务：Agent 必须为一位感到沮丧的客户处理退款。以下同样是原文保留的示意 YAML。 ```yaml 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 - n_total_tokens - type: latency metrics: - time_to_first_token - output_tokens_per_sec - time_to_last_token ``` 与编程 Agent 的示例一样，这项任务为了说明问题，展示了多种评分器。在实践中，对话 Agent 评估通常使用基于模型的评分器，同时评价沟通质量与目标完成情况，因为许多任务，例如回答问题，可能存在多个「正确」方案。 ### 评估研究 Agent 研究 Agent 收集、综合和分析信息，然后产出答案或报告等内容。编程 Agent 可以依靠单元测试获得二元的通过／失败信号，而研究质量只能结合任务来判断。什么算「全面」「来源充分」，甚至什么算「正确」，都取决于具体背景：市场概览、收购尽职调查和科学报告，需要不同的标准。 研究评估面临独特挑战：专家可能对一份综合分析是否全面持不同意见；参考内容不断变化，标准答案也会随之改变；更长、更开放的输出，又给错误留下了更多空间。例如，BrowseComp 这样的基准测试，会检验 AI Agent 能否在开放网络中大海捞针：题目被设计为容易验证，却很难解决。 构建研究 Agent 评估的一种策略，是组合不同类型的评分器。依据检查用于验证论断是否得到检索来源的支持；覆盖度检查规定一个好答案必须包含哪些关键事实；来源质量检查确认所参考的资料具有权威性，而不只是检索到的第一批结果。对于具有客观正确答案的任务，例如「X 公司第三季度的营收是多少」，精确匹配就能发挥作用。大语言模型既可以标记缺乏依据的论断、找出答案遗漏的关键内容，也可以检查开放式综合分析是否连贯、完整。 由于研究质量具有主观性，为了有效评价这类 Agent，基于大语言模型的评分标准应该经常根据人类专家判断进行校准。 ### 计算机操作 Agent 计算机操作 Agent 通过与人类相同的界面操作软件，包括屏幕截图、鼠标点击、键盘输入和滚动，而不是通过 API 或代码执行。它们可以使用任何具有图形用户界面（Graphical User Interface，GUI）的应用，从设计工具到传统企业软件。评估需要在真实环境或沙箱中运行 Agent，让它能够使用软件应用，再检查是否达到了预期结果。例如，WebArena 测试基于浏览器的任务，使用 URL 和页面状态检查确认 Agent 是否正确导航；对于修改数据的任务，还会验证后端状态，确认订单确实已提交，而不只是出现了确认页面。OSWorld 将这种方式扩展到整个操作系统的控制：任务完成后，由评估脚本检查多种产物，包括文件系统状态、应用配置、数据库内容和界面元素属性。 浏览器操作 Agent 需要在 token 效率与延迟之间取得平衡。基于文档对象模型（Document Object Model，DOM）的交互执行很快，但会消耗大量 token；基于截图的交互较慢，却更节省 token。例如，让 Claude 总结维基百科内容时，从 DOM 中提取文本更高效；在亚马逊上寻找新的笔记本电脑保护套时，截图更高效，因为提取整个 DOM 会消耗大量 token。在 Claude for Chrome 产品中，我们开发了评估，检查 Agent 是否为不同场景选择了正确的工具。这让我们能够更快、更准确地完成浏览器任务。 ## 如何理解 Agent 评估中的非确定性 无论是哪种 Agent，其行为在不同运行之间都会变化，因此评估结果比乍看之下更难解读。每项任务都有自己的成功率：一项可能是 90%，另一项可能是 50%；某项任务在一次评估中通过，下一次却可能失败。有时，我们希望衡量的是 Agent 在一项任务上成功的频率，也就是试验中成功的比例。 两个指标可以帮助表达这种差异： **pass@k** 衡量 Agent 在 k 次尝试中至少得到一个正确解决方案的概率。随着 k 增大，pass@k 会提高：尝试机会越多，至少成功一次的概率就越高。pass@1 为 50%，意味着模型在评估中有一半任务能够首次尝试就成功。在编程场景中，我们通常最关心 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：从已经手动测试的内容开始 从开发过程中运行的人工检查开始：每次发布前验证的行为，以及最终用户会尝试的常见任务。如果已经上线，就查看缺陷追踪系统和客服待处理队列。把用户报告的失败转化为测试用例，能够确保套件反映真实使用情况；按用户影响确定优先级，则能让你把精力投入到最重要的地方。 #### 步骤 2：编写没有歧义的任务，并提供参考解法 把任务质量做好，比看起来更难。一项好任务应该让两位领域专家独立评估时，得出相同的通过／失败结论。他们自己能通过这项任务吗？如果不能，任务就还需要完善。任务描述有歧义时，分数的变化就可能来自对题意的不同理解，而非 Agent 的能力变化。基于模型的评分器也一样：模糊的评分标准会产生不一致的判断。 每项任务都应该能被正确遵循指令的 Agent 完成。这一点可能相当微妙。例如，对 Terminal-Bench 的审计发现：如果任务要求 Agent 编写脚本，却没有指定文件路径，而测试又假定脚本位于某个特定路径，Agent 就可能在自己没有犯错的情况下失败。评分器检查的所有内容，都应该能从任务描述中明确得知；Agent 不应该因规格含糊而失败。对于前沿模型，如果在大量试验中通过率始终为 0%，也就是 pass@100 为 0%，通常更可能意味着任务有问题，而不是 Agent 没有能力，这时应该重新检查任务描述和评分器。为每项任务创建参考解法也很有用：提供一份已知可用、能够通过所有评分器的输出。这既证明任务可解，也能验证评分器配置正确。 #### 步骤 3：构建均衡的题目集合 既要测试某种行为应该发生的情况，也要测试它不应该发生的情况。单方面的评估，会带来单方面的优化。例如，如果你只测试 Agent 是否在应该搜索时进行搜索，最后可能会得到一个几乎什么都搜索的 Agent。尽量避免评估中的类别失衡。我们在为 Claude.ai 的网络搜索构建评估时，亲自体会到了这一点。挑战在于：既要防止模型在不该搜索时搜索，又要保留它在合适情况下深入研究的能力。团队为两个方向都构建了评估：模型应该搜索的查询，例如查询天气；以及应该凭已有知识回答的查询，例如「谁创立了苹果公司」。在触发不足，也就是该搜索时没有搜索，与过度触发，也就是不该搜索时却搜索之间找到平衡并不容易，需要对提示和评估进行多轮改进。随着更多示例问题出现，我们也继续把它们加入评估，扩大覆盖范围。 ### 设计评估 Harness 与评分器 #### 步骤 4：构建稳健的评估 Harness，提供稳定的环境 评估中的 Agent 应当与生产环境中的 Agent 以大致相同的方式运行，而且环境本身不能引入额外噪声，这一点至关重要。每次试验都应该从干净环境开始，彼此隔离。运行之间不必要的共享状态，例如残留文件、缓存数据或资源耗尽，可能因基础设施不稳定而导致相关联的失败，而不是反映 Agent 本身的表现。共享状态也可能人为抬高成绩。例如，在一些内部评估中，我们观察到 Claude 会查看此前试验留下的 Git 历史，从而在某些任务上获得不公平的优势。如果多个不同试验都因同一个环境限制而失败，例如 CPU 或内存资源有限，那么这些试验就不独立，因为它们受到了同一个因素的影响；评估结果也就无法可靠地衡量 Agent 表现。 #### 步骤 5：审慎设计评分器 如前所述，优秀的评估设计，需要为 Agent 和任务选择最合适的评分器。我们建议：能用确定性评分器时就用；必要时，或需要额外灵活性时，使用大语言模型评分器；再审慎地使用人工评分器做进一步验证。 一种常见直觉，是检查 Agent 是否遵循了非常具体的步骤，例如是否按正确顺序调用了一串工具。我们发现，这种方式过于僵硬，会产生非常脆弱的测试，因为 Agent 经常找到评估设计者没有预料到的有效路径。为了避免无谓地惩罚创造性，通常最好评价 Agent 产出了什么，而不是它走了哪条路。 对于由多个部分组成的任务，要允许部分得分。一个能够正确识别问题、验证客户身份，却没能处理退款的客服 Agent，显然比一开始就失败的 Agent 更好。评估结果需要体现任务完成了多少，而不只是区分完全成功和彻底失败。 模型评分往往需要认真迭代，才能验证准确性。「大语言模型即裁判」（LLM-as-judge）评分器应该与人类专家的判断紧密校准，让你有信心认为人工评分与模型评分之间没有太大偏差。为了避免幻觉，要给大语言模型留一条退路，例如要求它在信息不足时返回「Unknown」。创建清晰、结构化的评分标准，分别评价任务的各个维度，也会有帮助；然后为每个维度使用独立的大语言模型裁判，而不是让同一个裁判评价全部维度。系统足够稳健后，只需偶尔进行人工审查即可。 一些评估存在隐蔽的失败模式：即使 Agent 表现很好，也会得到低分，因为评分缺陷、Agent Harness 的约束或歧义，阻止了它完成任务。即便是经验丰富的团队，也可能漏掉这些问题。例如，Opus 4.5 最初在 CORE-Bench 上只得到 42%，直到一位 Anthropic 研究员发现了多项问题：僵硬的评分逻辑会在预期答案为「96.124991…」时，惩罚「96.12」这样的答案；任务描述存在歧义；还有一些随机性任务根本无法精确复现。修复缺陷，并换用约束更少的支撑框架后，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 式评估框架，才更清晰地看到了进展。 > 译者注：原文在前面的“编程 Agent 评估”一节与此处给出了不同的起始分数，却没有说明两处对比的条件是否一致。译文保留原数字；这两处不能直接当作同一组前后对比。 我们的一项原则是：在有人深入查看评估细节，并阅读部分执行记录之前，不会直接按表面分数下结论。如果评分不公平、任务含糊、有效方案受到惩罚，或者 Harness 限制了模型，就应该修订评估。 #### 步骤 8：通过开放贡献与持续维护，让评估套件长期保持健康 评估套件是一份持续演进的产物，需要不断关注，并明确由谁负责，才能持续发挥作用。 在 Anthropic，我们尝试过多种评估维护方式。最有效的方法，是建立专门的评估团队，负责核心基础设施；同时由领域专家和产品团队贡献大多数评估任务，并自行运行评估。 对 AI 产品团队而言，负责并迭代评估，应该像维护单元测试一样日常。团队可能花上数周开发某项 AI 功能，它在早期测试中「能用」，却未能满足那些没有明说的预期；设计良好的评估，本来可以早早揭示这些预期。定义评估任务，是对产品要求进行压力测试、判断其是否足够具体、能否开始开发的最佳方式之一。 我们建议践行评估驱动开发：在 Agent 还无法实现计划中的能力之前，先构建评估来定义这些能力，再持续迭代，直到 Agent 表现良好。在内部，我们经常开发一些今天只能做到「足够好」的功能，押注模型在几个月后的能力。初始通过率较低的能力评估，会具体呈现我们期待模型今后获得的能力。新模型发布时，运行套件就能快速看出哪些押注得到了回报。 最接近产品要求和用户的人，最适合定义成功。以目前的模型能力，产品经理、客户成功经理或销售人员，都可以使用 Claude Code，通过拉取请求（PR）贡献一项评估任务。让他们参与吧！更好的做法，是主动帮助他们做到这一点。 > **原文图注**：创建有效评估的过程。 ## 结合其他方法，全面理解 Agent 自动化评估可以在不部署到生产环境、不影响真实用户的情况下，对 Agent 运行数千项任务。但这只是理解 Agent 表现的多种方法之一。完整的图景还包括生产监控、用户反馈、A/B 测试、人工执行记录审查，以及系统化的人工评估。 **理解 AI Agent 表现的主要方法** | 方法及说明 | 优点 | 局限 | |---|---|---| | **自动化评估**：通过程序运行测试，不需要真实用户。 | 迭代更快。
完全可复现。
不影响用户。
每次提交都可以运行。
无需部署到生产环境，就能大规模测试场景。 | 前期构建投入较大。
需要随产品和模型演进持续维护，避免偏移。
如果与真实使用模式不符，可能产生虚假的信心。 | | **生产监控**：追踪线上系统中的指标与错误。 | 大规模揭示真实用户行为。
捕捉合成评估遗漏的问题。
为 Agent 的实际表现提供真实依据。 | 属于被动响应：你知道问题之前，用户已经受到影响。
信号可能充满噪声。
需要投入监测与数据采集建设。
缺少可用于评分的标准答案。 | | **A/B 测试**：通过真实用户流量比较不同版本。 | 衡量真实用户结果，例如留存与任务完成情况。
控制混杂因素。
可扩展，并具有系统性。 | 缓慢：需要数天或数周才能达到统计显著性，而且需要足够的流量。
只能测试已经部署的改动。
如果无法充分审查执行记录，就较难理解指标变化背后的原因。 | | **用户反馈**：点踩、缺陷报告等明确信号。 | 揭示事先没有想到的问题。
附带来自真实用户的实际案例。
反馈往往与产品目标相关。 | 稀疏，而且由用户自行选择是否反馈。
偏向严重问题。
用户很少解释为什么失败。
无法自动化。
主要依赖用户发现问题，可能给用户带来负面影响。 | | **人工执行记录审查**：由人阅读 Agent 对话。 | 建立对失败模式的直觉。
捕捉自动检查遗漏的细微质量问题。
帮助校准什么算「好」，并理解细节。 | 耗时。
难以规模化。
覆盖不一致。
审查者疲劳或不同审查者的差异，会影响信号质量。
通常只能提供定性信号，无法给出清晰的定量评分。 | | **系统化人工研究**：由受过训练的评分者，对 Agent 输出进行结构化评分。 | 多位人工评分者提供金标准级别的质量判断。
能够处理主观或含糊的任务。
为改进基于模型的评分器提供信号。 | 相对昂贵，反馈周期较长。
难以频繁开展。
评分者间的分歧需要协调。
法律、金融、医疗等复杂领域，需要人类专家参与研究。 | 这些方法对应 Agent 开发的不同阶段。自动化评估在上线前，以及持续集成／持续交付（CI/CD）中尤其有用，可以在每次 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**，一项在 Phoenix 基础上扩展规模化运行、优化和监控能力的软件即服务（SaaS）产品。 许多团队会组合多种工具，自行构建评估框架，或者仅以简单评估脚本作为起点。我们发现，虽然框架有助于加快进展、建立标准，但最终效果仍然取决于你放进去的评估任务。通常最好的做法，是快速选择一个适合工作流的框架，然后把精力投入评估本身，持续迭代高质量的测试用例与评分器。 --- ## 译注 - **Eval**：evaluation 的简称，本文统一译为「评估」。**Agent** 与 **Harness** 保留英文。 - **Task、trial、grader、transcript、outcome**：分别译为「任务」「试验」「评分器」「执行记录」「最终结果」。执行记录描述过程；最终结果描述环境中实际留下的状态，两者不能相互替代。 - **Rubric**：译为「评分标准」，指用于判断输出质量的一组明确维度与规则。**Ground truth** 根据语境译为「标准答案」「真实依据」或「真实情况」。 - **pass@k 与 pass^k**：前者关注 k 次尝试中至少成功一次，后者关注 k 次全部成功。若假设各次试验独立、每次成功概率均为 p，两者分别为 `1 - (1 - p)^k` 和 `p^k`。原文图注中接近 100% 和 0% 的描述用于说明走势，具体数值取决于成功率和试验次数。 - 两段 YAML 沿用原文字段、路径和英文断言，均为说明评估设计的示意配置，未作为可运行系统进行验证。 - 所提供文本不含原文配图，本文翻译并保留了图注；图示及原文中的外部资料链接，请参阅[原文页面](https://www.anthropic.com/engineering/demystifying-evals-for-ai-agents)。 原文著作权归原作者及 Anthropic 所有。本文为非官方中文译文；如需核对技术细节或措辞，请以原文为准。