深入理解 AI Agent 评估

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

发布日期： 2026年1月9日

来源： Anthropic 工程博客

作者： Mikaela Grace、Jeremy Hadfield、Rodrigo Olivares 和 Jiri De Jonghe（感谢其他贡献者）

---

引言

高质量的评估能让团队更有把握地发布 AI Agent。缺少评估时，团队容易陷入被动循环：问题只能在生产环境暴露，修复一个故障又可能引入新的问题。评估能在影响用户前揭示问题与行为变化，其价值会伴随 Agent 的整个生命周期持续累积。

正如 Anthropic 之前在"构建有效 Agent"帖子中所描述的，Agent 跨多个轮次工作——调用工具、修改状态并基于中间结果进行调整。这些使 Agent 有用的特性（自主性、智能、灵活性）也使评估变得复杂。本文分享了 Anthropic 在内部和客户合作中关于设计严格 Agent 评估所学到的经验。

评估的结构

评估被描述为对 AI 系统的测试：提供输入，然后应用评分逻辑来衡量成功。本文重点关注在开发期间运行、无需真实用户的自动化评估。

单轮评估很直接——提示、响应、评分逻辑。随着 AI 能力的进步，多轮评估变得越来越普遍。

Agent 评估更为复杂。Agent 在多个轮次中使用工具，修改状态并进行调整，这意味着"错误可以传播和累积。"前沿模型也可能找到超越静态评估限制的创造性解决方案。例如，Opus 4.5 通过发现策略漏洞解决了 τ2-bench 航班预订问题——它技术上"失败"了评估但实际上找到了更好的用户解决方案。

关键定义

文章为 Agent 评估定义了以下术语：

• 任务（又称问题/测试用例）：具有定义的输入和成功标准的单个测试
• 试验（trial）：对一个任务的一次尝试；由于模型输出存在波动，多次试验可以得到更稳定的结论
• 评分器：对性能的某个方面进行评分的逻辑；一个任务可以有多个评分器，每个包含多个断言或"检查"
• 执行记录（transcript，也称 trace/trajectory）：一次试验的完整过程，包括输出、工具调用、推理和中间结果
• 结果：试验结束时环境的最终状态（例如，无论 Agent 说了什么，数据库中是否实际存在预订）
• 评估 Harness：端到端运行评估的基础设施——提供指令/工具、并发运行任务、记录步骤、评分输出、聚合结果
• Agent Harness（运行框架/脚手架）：让模型以 Agent 方式工作的系统，负责处理输入、编排工具调用并返回结果。评估“一个 Agent”时，实际评估的是 Harness 与模型的组合
• 评估套件：衡量特定能力或行为的任务集合，通常共享一个广泛的目标

为什么要构建评估？

在 Agent 开发早期，团队可以通过手动测试、内部使用和直觉取得惊人进展。但在扩展到生产后，这种方法就会崩溃。

当用户反馈某次变更导致性能下降，团队往往才会发现自己缺少判断依据。没有评估，调试只能被动地等待投诉、手动复现、修复 bug，并祈祷没有引入其他回归。团队既无法区分真实回归与噪声，也无法在发布前针对数百个场景验证改动。

文章以 Claude Code 为例：它开始时基于 Anthropic 员工和外部用户反馈进行快速迭代，然后首先为狭窄领域（简洁性、文件编辑）添加评估，然后为更复杂的行为（过度工程化）添加评估。这些评估帮助识别问题、指导改进，并聚焦研究-产品协作。

案例研究

• Descript 围绕三个编辑工作流维度构建了评估："不要破坏东西，做我要求的事，并且做好。"他们从手动评分发展到带有产品团队定义标准和定期人工校准的 LLM 评分器，为质量基准测试和回归测试运行独立的套件。

• Bolt 在已经拥有广泛使用的 Agent 后开始构建评估。在3个月内，他们构建了一个系统，运行他们的 Agent，用静态分析评分输出，使用浏览器 Agent 测试应用，并使用 LLM 评判器评估指令遵循等行为。

评估在任何阶段都有用。早期，它们迫使团队明确成功的含义；后期，它们维持一致的质量标准。它们还加速新模型的采用——拥有评估的团队可以在几天内确定模型的优势、调优提示并升级，而不是几周。

一旦评估存在，基线和回归测试就是免费的：延迟、Token 使用量、每任务成本和错误率可以在静态任务库上跟踪。评估可以成为"产品和研究团队之间最高带宽的沟通渠道。"

如何评估 AI Agent

当今常见的 Agent 类型包括编码 Agent、研究 Agent、计算机使用 Agent 和对话 Agent。每种都可以使用类似的技术进行评估——下面的方法作为扩展到你领域的基础。

评分器类型

Agent 评估通常组合三种类型：

基于代码的评分器包括字符串匹配、二元测试（从失败到通过、从通过到通过）、静态分析、结果验证、工具调用验证和转录分析。优点：快速、廉价、客观、可重现、易于调试。缺点：对有效变化脆弱、缺乏细微差别、对主观任务有限。

基于模型的评分器包括按评分标准打分、自然语言断言、成对比较、参考答案评估和多评审模型共识。优点是灵活、可扩展，能处理细微差别和开放式任务；缺点是结果具有非确定性，成本高于代码评分器，且需要与人工评分进行校准。

人工评分包括领域专家审查、众包判断、抽样检查、A/B 测试和标注者间一致性分析。它最接近专家判断，可用于校准基于模型的评分器；但成本高、速度慢，而且常常需要大规模获取领域专家的参与。

评分可以是加权的（组合分数达到阈值）、二元的（所有评分器必须通过）或混合的。

能力评估与回归评估

能力（或质量）评估回答的是 Agent 目前能做好什么。它们应从较低通过率的难题开始，为团队提供明确的改进目标。

回归评估询问 Agent 是否仍然能处理以前工作的任务，应该保持接近100%的通过率。它们防止倒退。随着团队在能力评估上的改进，回归评估确保更改不会在其他地方引起问题。

在发布并持续优化后，通过率很高的能力评估可以转入持续运行的回归测试套件，用于捕捉能力漂移。

评估编码 Agent

编码 Agent 编写、测试和调试代码，导航代码库并运行命令。有效的评估依赖于明确指定的任务、稳定的测试环境和彻底的测试。

确定性评分器是自然的，因为"软件通常很直接地可以评估：代码能否运行，测试能否通过？"两个基准测试说明了这一点：

• SWE-bench Verified 给 Agent 来自流行 Python 仓库的 GitHub issue，通过运行测试套件来评分——解决方案必须修复失败的测试而不破坏现有的测试。LLM 在一年内从40%进步到>80%。
• Terminal-Bench 测试端到端的技术任务，如从源代码构建 Linux 内核或训练 ML 模型。

除通过/失败测试外，也常常需要评估执行记录：可以用启发式代码质量规则，以及带有清晰评分标准的模型评分器，判断工具使用、与用户交互等行为是否合适。

文章给出一个用于修复认证绕过漏洞的 YAML 示例，其中结合了确定性测试、LLM 评分标准、静态分析、状态检查和工具调用验证，并记录轮次、工具调用次数、Token 和延迟等指标。实践中，编码评估通常以单元测试验证正确性、以 LLM 评分标准评估代码质量，仅在确有需要时再加入额外评分器。

评估对话 Agent

对话 Agent 在支持、销售或辅导等领域与用户交互。与传统聊天机器人不同，它们维护状态、使用工具并在对话中采取行动。它们提出了一个独特的挑战："交互本身的质量是你正在评估的一部分。"

成功通常是多维度的：工单是否已解决（状态检查）、是否在少于 10 轮内完成（执行记录约束）、语气是否得体（LLM 评分标准）。两个体现这种多维度性的基准是 τ-Bench 和 τ2-Bench：其中一个模型扮演用户角色，Agent 则在真实感场景中完成任务。

文章给出一个处理愤怒客户退款的客服任务 YAML 示例，结合 LLM 评分标准、状态检查、工具调用验证和执行记录约束。实践中，对话 Agent 评估通常用基于模型的评分器衡量沟通质量与目标达成，因为很多任务并不只有一种“正确”解法。

评估研究 Agent

研究 Agent 收集、综合和分析信息，产生答案或报告。与编码 Agent 不同，单元测试提供二元信号，"研究质量只能相对于任务来判断。"

独特挑战包括：专家可能对完整性有不同意见，基础事实不断变化，更长的输出产生更多出错空间。BrowseComp 基准测试测试 Agent 是否能在开放网络上大海捞针——问题易于验证但难以解决。

一种策略结合了多种评分器类型：接地性检查验证声明得到来源支持，覆盖性检查定义好答案必须包含的关键事实，来源质量检查确认权威来源，精确匹配适用于客观正确的答案。LLM 可以标记不受支持的声明、差距，并验证综合的连贯性和完整性。

鉴于研究任务的主观性，基于 LLM 的评分标准应经常与专家人工判断校准。

计算机使用 Agent

这些 Agent 通过与人类相同的界面与软件交互——截图、鼠标点击、键盘输入、滚动——而不是 API 或代码执行。它们可以使用任何 GUI 应用，从设计工具到遗留企业软件。

WebArena 使用 URL 和页面状态检查以及后端状态验证测试基于浏览器的任务。OSWorld 扩展到完整的操作系统控制，评估脚本检查各种制品：文件系统状态、应用配置、数据库内容和 UI 元素属性。

浏览器使用 Agent 需要平衡 Token 效率和延迟：基于 DOM 的交互执行快速但消耗许多 Token，而基于截图的交互较慢但更节省 Token。在 Claude for Chrome 产品中，Anthropic 开发了评估来检查 Agent 是否为每种上下文选择了正确的工具。

Agent 评估中的非确定性

Agent 行为在不同运行之间变化，使结果更难解释。每个任务有自己的通过率，一个任务在一次运行中通过可能在下一次失败。

两个指标捕捉了这种细微差别：

pass@k 衡量在 k 次尝试中至少得到一个正确解的概率。随着 k 增加，pass@k 会提高。编码任务通常最看重 pass@1；而其他任务中，只要多份方案中有一份可用，尝试多次也可能是合理的产品策略。

pass^k 衡量 k 次试验全部成功的概率。随着 k 增加，pass^k 会下降。若单次试验成功率为 75%，连续 3 次全都成功的概率为 (0.75)^3 ≈ 42%。对面向客户、要求每次都稳定可靠的 Agent，这个指标尤其重要。

在 k=1 时，两个指标相同。到 k=10 时，它们讲述了相反的故事：pass@k 接近100%而 pass^k 降至0%。使用哪个取决于产品需求。

从零到一：路线图

文章提供了从头构建评估的实战建议。

步骤0：尽早开始

团队常因以为必须先准备数百个任务而推迟建设评估。实际上，从真实故障中抽取 20 到 50 个简单任务，就足以成为很好的起点。开发早期，每次改动带来的影响较明显，小样本已能提供有效信号；成熟 Agent 才需要更大的评估集来识别较小的变化。拖得越久，评估越难补建。

步骤1：从你已经手动测试的内容开始

从开发期间运行的手动检查开始。如果已经在生产中，查看 bug 跟踪器和支持队列。将用户报告的失败转换为测试用例可确保套件反映实际使用情况。

步骤2：编写带有参考解决方案的明确任务

一个好任务应当让两位领域专家独立得出相同的通过/失败结论；规格中的歧义会直接变成指标噪声。每个任务都应能被正确执行的 Agent 完成。对于前沿模型，如果大量试验仍是 0% 通过率（0% pass@100），通常说明任务本身有问题，而不是 Agent 缺乏能力。应为每个任务准备能通过所有评分器的参考解，以证明任务可解，并验证评分器配置。

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

既测试行为应该出现的地方，也测试不应该出现的地方。单方面的评估会产生单方面的优化。避免类别不平衡的评估。

文章分享了 Anthropic 为 Claude.ai 中的 Web 搜索构建评估的经验——挑战是在不适当的时候阻止搜索同时保留广泛的研究能力。团队构建了涵盖两个方向的评估：需要搜索的查询（天气）和可以从知识中回答的查询（"谁创立了 Apple？"）。找到正确的平衡需要多轮改进。

步骤4：构建具有稳定环境的健壮评估 Harness

评估 Agent 的行为应与生产大致相同，环境不应引入噪声。每次试验都应从干净的环境开始。运行之间不必要的共享状态可能导致来自基础设施不稳定而非 Agent 性能的相关失败。在一些内部评估中，Claude 通过检查之前试验的 Git 历史获得了不公平的优势。受相同环境限制（如有限内存）影响的试验不是独立的。

步骤5：深思熟虑地设计评分器

尽可能选择确定性评分器，必要时使用 LLM 评分器，谨慎使用人类评分器进行验证。

一种常见做法是检查 Agent 是否遵循了非常具体的步骤序列。文章指出，这种做法往往过于死板，会让测试变得脆弱，因为 Agent 经常能找到评估设计者未预料到的有效路径。通常更应评估 Agent 交付了什么结果，而非它具体走了哪条路径。

对于多组件任务，构建部分分数——一个正确识别问题并验证客户但未能处理退款的支持 Agent 比立即失败的 Agent 有意义地更好。

模型评分需要仔细迭代。LLM-as-a-judge 应与领域专家密切校准；为降低幻觉风险，应允许信息不足时返回“未知”。评分标准应清晰、结构化，并让相互独立的 LLM 评审分别判断不同维度，而不是由一个评审包办所有维度。体系稳定后，只需定期进行人工抽查。

一些评估有微妙的失败模式。文章引用了 Opus 4.5 最初在 CORE-Bench 上得分42%，直到 Anthropic 研究人员发现多个问题：僵化的评分在期望"96.12"时惩罚了"96.124991..."、模糊的任务规格，以及无法精确重现的随机任务。修复后，分数跳升到95%。类似地，METR 在他们的时间范围基准测试中发现了配置错误的任务，惩罚了像 Claude 这样遵循声明指令的模型，同时奖励了忽略声明目标的模型。

评分器还应具备抵御投机取巧的能力：任务与评分规则必须确保，只有真正解决问题才能通过。

步骤6：检查转录

如果不阅读大量试验的执行记录和评分，就无法确认评分器是否正常工作。Anthropic 为查看评估执行记录投入了专门工具，并定期审阅。任务失败时，这些记录能帮助判断 Agent 是确实犯错，还是评分器错误地否定了有效解法。合理的失败应当清楚说明 Agent 错在哪里、为什么错；审阅记录正是验证评估是否测到了真正重要问题的方法。

步骤7：监控能力评估饱和

通过率 100% 的评估仍能发现回归，却不再提供改进信号。评估饱和是指 Agent 已通过所有可解任务。SWE-bench Verified 的得分曾从 30% 起步，如今前沿模型已接近 80% 以上，正逐渐饱和。评估饱和后，剩下的往往只有最难任务，因而会掩盖进步：能力显著提升，在分数上却可能只表现为很小的增量。

文章引用了 Qodo，一家代码审查初创公司，最初对 Opus 4.5 印象不深，因为一次性编码评估没有捕捉到复杂任务上的收益。他们开发了一个新的 Agent 评估框架，提供了更清晰的图景。

"我们不会只看评估分数的表面价值，除非有人深入研究评估的细节并阅读一些转录。"

步骤8：长期保持评估套件健康

评估套件是一项需要持续维护并明确责任归属的长期资产。Anthropic 发现，最有效的组织方式是由专门的评估团队负责核心基础设施，同时由领域专家和产品团队贡献任务、运行评估。

对于 AI 产品团队，维护并迭代评估应像维护单元测试一样成为常规工作。定义评估任务，是检验产品需求是否已具体到可以开始构建的最佳方式之一。

文章推荐评估驱动开发：在 Agent 能够满足之前构建评估来定义计划的能力，然后迭代直到 Agent 表现良好。当新模型发布时，运行套件可以快速揭示哪些赌注得到了回报。

产品经理、客户成功经理和销售人员都可以借助 Claude Code 以 PR 形式贡献评估任务。最贴近产品需求和用户的人，通常最适合定义什么才算成功。

评估如何与其他方法配合

自动化评估可以在不部署到生产的情况下针对数千个任务运行。但它们只是了解 Agent 性能的一种方式。完整图景包括生产监控、用户反馈、A/B 测试、手动转录审查和系统化的人类评估。

文章提供了六种方法的详细比较表：

方法	描述	优点	缺点
自动化评估	无需真实用户以编程方式运行测试	更快迭代、完全可重现、无用户影响、可在每次提交时运行、大规模测试	需要前期投资、持续维护、可能产生虚假信心
生产监控	在实时系统中跟踪指标和错误	揭示真实用户行为、捕获合成评估遗漏的问题、基础事实	被动、噪声信号、需要仪表化投资、缺乏评分的基础事实
A/B 测试	用真实用户流量比较变体	衡量实际用户结果、控制混杂因素、可扩展	缓慢（达到显著性需要数天/数周）、只测试已部署的更改、对底层"为什么"信号较少
用户反馈	如踩下或 bug 报告等显式信号	暴露未预料到的问题、真实示例、与产品目标相关	稀疏且自选择、偏向严重问题、用户很少解释原因、非自动化
手动转录审查	人类阅读 Agent 对话	建立对失败模式的直觉、捕获微妙的质量问题、帮助校准	耗时、无法扩展、覆盖不一致、审查者疲劳
系统化人类研究	由训练有素的评分者进行结构化评分	黄金标准判断、处理主观任务、改进基于模型的评分器	昂贵且缓慢、难以频繁运行、评分者间分歧、复杂领域需要专家

这些方法映射到不同的开发阶段。自动化评估在发布前和 CI/CD 中特别有用。生产监控在发布后启动。A/B 测试用足够的流量验证重大更改。用户反馈和转录审查是持续的差距填充者。系统化人类研究保留用于校准 LLM 评分器或评估主观输出。

文章借用了安全工程中的瑞士奶酪模型：任何单一评估层都无法覆盖所有问题，但组合多种方法后，穿透一层防线的故障有机会被另一层发现。最有效的团队会将这些方法组合使用。

结论

没有评估的团队容易陷入被动循环。及早投入评估的团队通常会发现开发节奏更快：故障转化为测试用例，测试用例防止回归，指标取代猜测。评估为团队提供清晰的改进目标，也能把模糊的投诉转化为可行动的信号。

基本原则在各种 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 团队等。

附录：评估框架

几个开源和商业框架帮助实现 Agent 评估：

• Harbor：专为在容器化环境中运行 Agent 设计，具有跨云提供商大规模运行试验的基础设施以及任务和评分器的标准化格式。Terminal-Bench 2.0 等流行基准测试通过其注册表发布。

• Braintrust：将离线评估与生产可观察性和实验跟踪相结合。其 autoevals 库包含用于事实性、相关性等维度的预构建评分器。

• LangSmith：提供与 LangChain 生态系统集成的跟踪、离线/在线评估和数据集管理。Langfuse 提供类似功能，作为满足数据驻留要求的自托管开源替代方案。

• Arize：提供 Phoenix（用于 LLM 跟踪、调试和评估的开源平台）和 AX（扩展 Phoenix 以实现规模、优化和监控的 SaaS）。

许多团队组合多个工具，自己构建框架，或使用简单的评估脚本作为起点。虽然框架可以标准化和加速进展，"但它们只和你通过它们运行的评估任务一样好。"建议是快速选择一个适合你工作流程的框架，然后将精力投入到高质量的测试用例和评分器中。