揭开 AI Agent 评估的神秘面纱

发布日期： 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 评估定义了以下术语：

• 任务（又称问题/测试用例）：具有定义的输入和成功标准的单个测试
• 试验：对任务的每次尝试；多次试验由于输出变化产生更一致的结果
• 评分器：对性能的某个方面进行评分的逻辑；一个任务可以有多个评分器，每个包含多个断言或"检查"
• 转录（跟踪/轨迹）：试验的完整记录，包括输出、工具调用、推理和中间结果
• 结果：试验结束时环境的最终状态（例如，无论 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 需要更大的评估来检测更小的效果，但80/20方法最初有效。等待越久，评估越难构建。

步骤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 作为评判器的评分器应与人类专家密切校准。为了避免幻觉，给 LLM 一个退出方式（在信息不足时返回"未知"）。创建清晰、结构化的量规，用隔离的 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）。

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