Anthropic深度解析：AI智能体评估完全指南，从入门到实践

Anthropic团队详解AI智能体评估体系，强调评估对提升AI系统可靠性的关键作用。文章系统介绍了评估结构、评分器类型及针对不同智能体(编码、对话、研究、计算机使用)的评估方法，并提出处理非确定性的pass@k和pass^k指标。通过从零到一的评估路线图，指导团队如何尽早构建评估体系，结合自动化评估、生产监控和人工审查等多层次方法，确保AI智能体质量与持续改进。

Anthropic发布了一篇blog《揭秘AI Agents评估》，细节满满！

原文略微有点长，整理了一张脑图，要点精髓：

良好的评估（evaluations）能帮助团队更有信心地发布AI智能体。没有评估，很容易陷入被动循环——只在生产环境中发现问题，修复一个故障又会引发其他问题。评估能在问题影响用户之前让问题和行为变化变得可见，其价值在智能体的整个生命周期中不断累积。

通过Anthropic内部工作以及与处于智能体开发前沿的客户合作，已经学会了如何为智能体设计更严格和有用的评估：

一、评价的结构

评估（“eval”）是对AI系统的测试：给AI一个输入，然后对其输出应用评分逻辑来衡量成功。在本文中，我们专注于自动化评估，可以在开发过程中无需真实用户即可运行。

单轮评估很简单：一个提示、一个响应和评分逻辑。对于早期的LLM，单轮、非智能体评估是主要的评估方法。随着AI能力的提升，多轮评估变得越来越常见。

在简单的评估中，智能体处理一个提示，评分器检查输出是否符合预期。对于更复杂的多轮评估，编码智能体接收工具、任务（在此案例中是构建MCP服务器）和环境，执行"智能体循环"（工具调用和推理），并用实现更新环境。然后使用单元测试来验证工作的MCP服务器。

智能体评估更加复杂。智能体在多轮中使用工具，修改环境中的状态并进行适应——这意味着错误可能会传播和累积。前沿模型还能找到超越静态评估限制的创造性解决方案。例如，Opus 4.5通过发现政策中的漏洞解决了一个τ2-bench关于预订航班的问题。它"未能"通过所写的评估，但实际上为用户提出了更好的解决方案。

在构建智能体评估时，使用以下定义：

任务（也称为问题或测试用例）是具有定义输入和成功标准的单个测试。

每个任务的尝试是一个试验。由于模型输出在运行之间会有所不同，我们运行多个试验以产生更一致的结果。

评分器是对智能体某些方面表现进行评分的逻辑。一个任务可以有多个评分器，每个评分器包含多个断言（有时称为检查）。

记录（也称为跟踪或轨迹）是试验的完整记录，包括输出、工具调用、推理、中间结果和任何其他交互。对于Anthropic API，这是评估运行结束时完整的messages数组——包含评估期间对API的所有调用和所有返回的响应。

结果是试验结束时环境的最终状态。预订航班的智能体可能在记录结束时说"您的航班已预订"，但结果是在环境的SQL数据库中是否存在预订。

评估框架是端到端运行评估的基础设施。它提供指令和工具，并发运行任务，记录所有步骤，对输出进行评分，并汇总结果。

智能体框架（或脚手架）是使模型能够作为智能体运行的系统：它处理输入，编排工具调用，并返回结果。当我们评估"一个智能体"时，我们是在评估框架和模型一起工作。例如，Claude Code是一个灵活的智能体框架，我们通过Agent SDK使用其核心原语来构建我们的长运行智能体框架。

评估套件是为测量特定能力或行为而设计的任务集合。套件中的任务通常共享广泛的目标。例如，客户支持评估套件可能测试退款、取消和升级。

二、为什么要构建评估？

初期靠手动测试和直觉可快速推进智能体，但上线后若无评估，团队只能被动等投诉，难辨回归与噪声。早期或规模化阶段引入评估，都能明确成功定义、自动覆盖百种场景、加速迭代。Claude Code、Descript、Bolt AI的实践显示：评估指导研究-产品协作、支持 A/B 测试与成本基线，并助团队在新模型发布数天而非数周内完成升级，长期收益远超前期投入。

三、如何评估AI智能体

展示几种智能体类型的成熟技术

智能体评分器类型

智能体评估通常结合三种类型的评分器：基于代码的、基于模型的和人类。每个评分器评估记录或结果的某些部分。有效评估设计的重要组成部分是为工作选择合适的评分器。

基于代码的评分器

基于模型的评分器

人类评分器

对于每个任务，评分可以是加权的（组合评分器分数必须达到阈值）、二进制的（所有评分器必须通过）或混合的。

能力与回归评估

能力评估聚焦“能做什么”，从低通过率起步，推动团队挑战难题。回归评估确保“仍能做旧任务”，通过率应近100%，防止倒退。能力评估达标后可转为回归套件，持续监控漂移，从“能否做到”转为“是否仍可靠”。

评估编码智能体

编码智能体写、测、调代码，评估依赖明确任务与稳定测试。SWE-bench Verified用GitHub问题+测试评分，通过率一年从40%升至80%。Terminal-Bench测构建内核等任务。除结果测试，还可评代码质量与行为记录，确保工具调用与交互规范。

评估对话智能体

对话智能体在支持、销售等场景交互，需评状态维护、工具使用与语气。成功维度含状态达成、轮次控制与语气合规。τ-Bench与τ2-Bench模拟多轮交互，一模型扮用户，一模型扮智能体，评任务完成与交互质量，覆盖零售、航空等场景。

评估研究智能体

研究智能体收集、综合、输出信息，质量依赖上下文：市场扫描、尽调、科研标准各异。评估需结合基础检查、覆盖验证、来源质量与连贯性评分。BrowseComp测“大海捞针”式搜索。LLM评分需与专家校准，确保综合全面、来源权威、结论可信。

计算机使用智能体

计算机使用智能体通过GUI操作软件，评估需在真实或沙盒环境中验证结果。WebArena测浏览器任务，查URL与后端状态；OSWorld扩展至操作系统级，评文件、配置、数据库与UI变化。需平衡令牌效率与延迟，选DOM或截图交互，确保任务准确完成。

如何思考智能体评估中的非确定性

无论智能体类型如何，智能体行为在运行之间都会有所不同，这使得评估结果比最初看起来更难解释。每个任务都有自己的成功率——一个任务可能是90%，另一个任务可能是50%——而在一次评估运行中通过的任务可能在下次失败。有时，我们想要测量的是智能体多频繁（试验成功的比例）成功完成一个任务。

两个指标有助于捕捉这种细微差别：

pass@k衡量智能体在k次尝试中至少获得一个正确解决方案的可能性。随着k的增加，pass@k分数上升——更多的"射门次数"意味着至少一次成功的几率更高。50%的pass@1分数意味着模型在第一次尝试时成功完成了一半的评估任务。在编码中，我们通常最关心智能体在第一次尝试时找到解决方案——pass@1。在其他情况下，提出许多解决方案是有效的，只要有一个有效。

**pass^{k**衡量**所有k次试验**成功的概率。随着k的增加，pass}k下降，因为要求在更多试验中保持一致是更难达到的标准。如果您的智能体每次试验成功率为75%，并且您运行3次试验，通过所有三次的概率是(0.75)³ ≈ 42%。这个指标对于用户期望可靠行为的面向客户智能体尤其重要。

随着试验次数的增加，pass@k和pass^{k出现分歧。在k=1时，它们是相同的（都等于每次试验的成功率）。到k=10时，它们讲述了相反的故事：pass@k接近100%，而pass}k下降到0%。

两个指标都很有用，使用哪个取决于产品要求：对于工具一次成功重要的用pass@k，对于一致性至关重要的智能体用pass^k。

四、从零到一：通往优秀智能体评估的路线图

收集初始评估数据集的任务

第0步：尽早开始

20–50个真实失败案例即可起步；拖得越久越难补。

第1步：从现成手动测试与工单里挖用例

按用户影响排序，直接转成任务。

第2步：写“双专家可复判”的明确任务

模糊规范=噪声；0%通过率先查任务/评分器，而非模型。

第3步：正负样本平衡

只测“该做”会过度优化；同步覆盖“不该做”场景。

设计评估框架和评分器

第4步：隔离干净环境

禁残留文件/缓存/资源泄漏，防止“git偷看”类假阳性。

第5步：评结果不评路径

多给部分分；LLM-as-judge须与人拉齐，留“未知”出口；防阈值/格式等评分 Bug。

长期维护和使用评估

第6步：定期读日志

确认失败公平，排除评分器甩锅。

第7步：监控饱和

分数>80%时换更难任务，避免“小步美化”掩盖真实提升。

第8步：持续贡献与所有权

核心 infra 归评估团队，业务方像写单元测试一样提任务；PR 式开放提交，评估先行再开发。

评估如何与其他方法配合，全面了解智能体

自动化评估可以在不影响生产环境或影响真实用户的情况下，针对智能体运行数千个任务。但这只是了解智能体性能的众多方法之一。完整的图景包括生产监控、用户反馈、A/B测试、手动记录审查和系统的人工评估。

了解AI智能体性能的方法概述

这些方法映射到智能体开发的不同阶段。自动化评估在发布前和CI/CD中特别有用，在每次智能体更改和模型升级时作为抵御质量问题的第一道防线运行。生产监控在发布后启动，以检测分布漂移和未预料到的现实世界故障。A/B测试在您有足够流量时验证重大更改。用户反馈和记录审查是填补空白的持续实践——不断分类反馈，每周抽样阅读记录，并根据需要深入挖掘。保留系统的人工研究，用于校准LLM评分器或评估主观输出，其中人类共识作为参考标准。

与安全工程中的[瑞士奶酪模型]一样，没有单一的评估层能捕捉到每个问题。结合多种方法，一个层漏掉的故障会被另一个层捕捉到。

最有效的团队结合这些方法——用于快速迭代的自动化评估、用于真相的生产监控，以及用于校准的定期人工审查。