揭秘AI智能体的评估方法

2026年1月9日 发布 Anthropic工程团队

让AI智能体具备实用价值的那些能力，也让其评估工作变得极具挑战性。能在实际部署中落地的评估策略，需要结合多种技术手段，才能匹配所测系统的复杂程度。

引言

完善的评估体系能让研发团队更有信心地推出AI智能体。缺少评估，团队很容易陷入被动的问题解决循环——只有在生产环境中才发现问题，而修复一个故障又可能引发新的问题。评估能在问题影响用户前，就让其暴露出来，同时让智能体的行为变化变得可感知，其价值会在智能体的全生命周期中持续累积。

正如我们在《构建高效AI智能体》一文中所阐述的，智能体的运行涉及多轮交互：调用工具、更新状态，并根据中间结果调整行为。正是这些让AI智能体具备实用价值的能力——自主性、智能性和灵活性，使其评估工作难度大增。

通过内部研发实践，以及与身处智能体开发前沿的客户合作，我们总结出了设计更严谨、更实用的智能体评估体系的方法。以下是经各类智能体架构和实际落地场景验证的有效实践。

评估的构成体系

评估，即对AI系统的测试：向AI输入信息，再通过评分逻辑对其输出结果进行评判，以此衡量任务完成的成功率。本文聚焦于自动化评估，这类评估可在研发阶段独立运行，无需真实用户参与。

单轮评估的流程十分直观：输入提示词、获取模型响应、通过评分逻辑评判。早期大语言模型的评估主要采用这种单轮、非智能体式的评估方法。随着AI能力的提升，多轮评估的应用越来越广泛。

在简单的评估中，智能体处理提示词后，评估器会检查其输出是否符合预期。而在更复杂的多轮评估中，代码智能体将获得工具、任务（如搭建MCP服务器）和运行环境，执行“智能体循环”（工具调用与逻辑推理），并通过实际开发更新环境状态。后续评估则会通过单元测试验证搭建的MCP服务器是否可正常运行。

AI智能体的评估则复杂得多。智能体会在多轮交互中持续调用工具，在环境中修改状态并动态调整行为——这意味着错误会不断传播和叠加。前沿模型还可能找到超出静态评估体系限定的创新解决方案。例如，Opus 4.5在解决τ2基准测试中的机票预订问题时，发现了政策中的一个漏洞。从评估规则来看，它的解法属于“失败”，但实际上它为用户提供了更优的解决方案。

在构建智能体评估体系时，我们采用以下定义：

• 任务（也可称问题、测试用例）：一项独立的测试，包含明确的输入要求和成功判定标准。
• 尝试：针对某一任务的单次执行过程。由于模型输出存在随机性，需通过多次尝试获得更稳定的评估结果。
• 评估器：对智能体某方面表现进行评分的逻辑体系。一个任务可搭配多个评估器，每个评估器包含多项断言（也可称检查项）。
• 记录文本（也可称轨迹）：一次尝试的完整记录，包括输出结果、工具调用、逻辑推理、中间结果及其他所有交互行为。对于Anthropic API而言，这是评估结束后生成的完整消息数组，包含评估过程中所有的API调用和返回响应。
• 结果状态：一次尝试结束后，环境的最终状态。例如，机票预订智能体的记录文本中可能显示“机票已完成预订”，但实际结果状态需以环境的SQL数据库中是否存在预订记录为准。
• 评估框架：端到端运行评估的基础设施，负责下发指令、提供工具、并发执行任务、记录所有步骤、对输出评分并汇总结果。
• 智能体框架（也可称脚手架）：让模型具备智能体能力的系统，可处理输入、协调工具调用并返回结果。我们评估“某一智能体”时，实际是评估智能体框架与模型的协同表现。例如，Claude Code是一款灵活的智能体框架，我们通过智能体开发工具包（Agent SDK）调用其核心原语，搭建了长时运行的智能体框架。
• 评估套件：用于衡量特定能力或行为的一系列任务集合，套件内的任务通常围绕一个核心目标设计。例如，客户服务评估套件可包含退款、取消订单、问题升级等测试任务。

为何要构建评估体系？

团队在开发智能体的初期，通过人工测试、内部试用和经验判断，往往能取得不错的初期进展。此时，更严谨的评估甚至会被视为拖慢上线进度的额外工作。但当智能体完成早期原型开发、投入生产并开始规模化落地后，缺乏评估体系的开发模式便会暴露出诸多问题。

问题的爆发点通常出现在：用户反馈智能体在更新后表现变差，而团队却“两眼一抹黑”，除了反复试错，没有任何有效手段验证问题。缺少评估体系，调试工作只能被动进行：等待用户投诉、人工复现问题、修复漏洞，再祈祷不会引发新的问题。团队无法区分真实的性能退化和随机波动，无法在上线前针对数百种场景自动测试更新内容，也无法量化评估智能体的性能提升。

我们多次见证过这一发展过程。例如，Claude Code最初依靠Anthropic员工和外部用户的反馈快速迭代，后续才逐步引入评估体系——先针对简洁性、文件编辑等细分场景，再扩展到过度工程化等更复杂的行为。这些评估体系帮助团队发现问题、指导优化方向，并推动研发与产品团队的协作。结合生产环境监控、A/B测试、用户研究等手段，评估体系为Claude Code的规模化迭代优化提供了关键依据。

在智能体生命周期的任何阶段，构建评估体系都具有重要价值。开发初期，评估能倒逼产品团队明确智能体的成功标准；后期则能帮助团队维持稳定的质量基准。

Descript公司的智能体助力用户进行视频编辑，该团队围绕视频编辑工作流的三个核心维度构建了评估体系：不破坏原有内容、完成用户指令、高质量完成任务。其评估方式从人工评分，逐步演进为结合产品团队制定的评判标准、并经人工定期校准的大语言模型评分模式，目前还会定期运行两套独立的评估套件，分别用于质量基准测试和回归测试。Bolt AI团队则是在其智能体已广泛落地后，才开始构建评估体系，仅用3个月就搭建了一套完整的评估系统：通过静态分析运行智能体并评分，借助浏览器智能体测试应用，同时利用大语言模型评估智能体的指令遵循能力等行为。

部分团队在开发初期就搭建评估体系，也有团队在智能体规模化落地、评估成为性能优化瓶颈时才着手建设。开发初期构建评估体系的优势尤为明显，能将预期的智能体行为明确编码为测试标准。两名工程师阅读同一初始需求文档，对AI如何处理边缘场景可能会有不同理解，而评估套件能有效消除这种歧义。无论在哪个阶段构建，评估体系都能加速智能体的开发进程。

评估体系还能大幅提升团队对接新模型的效率。当更强大的模型发布时，没有评估体系的团队需要数周时间开展测试，而拥有评估体系的竞争对手能快速识别新模型的优势、调优提示词，并在数天内完成模型升级。

一旦搭建好评估体系，团队就能免费获得性能基准和回归测试能力：可基于固定的任务库，持续跟踪延迟、令牌使用量、单任务成本和错误率等指标。评估体系还能成为产品与研发团队之间最高效的沟通渠道，为研发团队明确需要优化的核心指标。显然，评估体系的价值远不止于跟踪性能退化和提升，其长期累积的价值往往容易被忽视——因为搭建成本是显性的，而价值会在后续逐步体现。

如何评估AI智能体？

目前规模化落地的AI智能体主要包括代码智能体、研究智能体、计算机操作智能体和对话智能体等类型。尽管这些智能体的应用行业各不相同，但评估方法具有共通性，无需从零开始设计评估体系。以下介绍经验证的各类智能体评估技巧，可将其作为基础，结合具体业务场景扩展优化。

智能体的评估器类型

智能体评估通常结合三种类型的评估器：代码型、模型型和人工型。每种评估器都会针对记录文本或结果状态的特定部分进行评判。设计高效评估体系的核心，是为具体任务选择合适的评估器。

代码型评估器

评估方法	优势	劣势
字符串匹配检查（精确匹配、正则匹配、模糊匹配等） 二元测试（失败/成功） 静态分析（代码检查、类型校验、安全检测） 结果状态验证 工具调用验证（调用的工具、参数） 记录文本分析（交互轮数、令牌使用量）	速度快 成本低 结果客观 可复现 易调试 能验证特定条件	对未完全匹配预期模式的有效变体兼容性差 缺乏细节考量 对主观性较强的任务评估能力有限

模型型评估器

评估方法	优势	劣势
基于评分标准的打分 自然语言断言 两两对比 基于参考答案的评估 多评估器共识判定	灵活性高 可规模化 能捕捉细节差异 适配开放式任务 支持自由格式输出	结果非确定性 成本高于代码型评估器 需结合人工评估校准以保证准确性

人工型评估器

评估方法	优势	劣势
领域专家评审 众包判定 随机抽样检查 A/B测试 标注者间一致性校验	黄金标准级别的评估质量 匹配专业用户的判断标准 可用于校准模型型评估器	成本高 速度慢 规模化落地需大量领域专家

针对单个任务，评分方式可采用加权制（各评估器得分总和达到阈值即为通过）、全通制（所有评估器均判定通过）或混合制。

能力评估与回归评估

能力评估（也叫质量评估） 旨在回答“这款智能体擅长完成哪些任务？”。这类评估的初始通过率应设定在较低水平，聚焦于智能体现阶段难以完成的任务，为团队设定明确的优化目标。

回归评估 旨在回答“智能体是否仍能完成所有原本擅长的任务？”，其通过率应接近100%。这类评估用于防止智能体性能退化，一旦评分下降，即表明系统出现故障，需要优化。团队在推进能力评估目标的同时，必须同步开展回归评估，确保优化不会引发其他环节的问题。

当智能体上线并完成优化后，原本高通过率的能力评估任务可“升级”为回归评估套件，持续运行以捕捉性能漂移。这些任务的评估目标也会从“我们能否完成这项任务？”转变为“我们能否稳定可靠地完成这项任务？”。

代码智能体的评估

代码智能体可完成代码编写、测试和调试，能像人类开发者一样浏览代码库、执行命令。评估现代代码智能体的有效方式，通常依赖定义清晰的任务、稳定的测试环境和对生成代码的全面测试。

代码智能体天然适合采用确定性评估器，因为软件的评估标准十分明确：代码能否运行？测试是否通过？SWE-bench Verified和Terminal-Bench是两款广泛使用的代码智能体基准测试工具，均采用这一评估思路。SWE-bench Verified向智能体提供主流Python仓库中的GitHub问题，通过运行测试套件评判解决方案，只有在修复故障测试且不破坏原有功能的情况下，解决方案才会被判定为通过。仅一年时间，大语言模型在该评估中的通过率就从40%提升至80%以上。Terminal-Bench则采用不同思路，聚焦端到端的技术任务，例如从源码编译Linux内核、训练机器学习模型等。

在为代码任务设计了一系列成功/失败的验证测试后，对记录文本进行评分也能带来重要价值。例如，基于启发式规则的代码质量标准，可从超越“测试通过”的维度评估生成代码；结合清晰评分标准的模型型评估器，可评估智能体的工具调用方式、与用户的交互行为等。

示例：代码智能体的理论评估方案

以修复身份验证绕过漏洞的代码任务为例，可通过如下YAML文件所示的方式，结合多种评估器和指标对智能体进行评估：

task:
  id: "fix-auth-bypass_1"
  desc: "修复密码字段为空时的身份验证绕过漏洞……"
  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

本示例为展示评估器的完整类型而设计，实际的代码评估中，通常仅通过单元测试验证代码正确性，并通过大语言模型评分标准评估整体代码质量，仅在需要时才添加其他评估器和指标。

对话智能体的评估

对话智能体主要在客户支持、销售、辅导等领域与用户交互，与传统聊天机器人不同，它能维持会话状态、调用工具，并在对话过程中执行操作。尽管代码智能体和研究智能体也会与用户进行多轮交互，但对话智能体的评估存在独特挑战：交互过程本身的质量也是评估的核心维度。

评估对话智能体的有效方式，通常依赖可验证的最终状态结果，以及能同时捕捉任务完成度和交互质量的评分标准。与其他类型的评估不同，对话智能体的评估通常需要借助第二个大语言模型模拟用户行为。我们在对齐审计智能体中就采用了这一方法，通过长时间的对抗性对话，对模型进行压力测试。

对话智能体的成功标准具有多维性：工单是否解决（状态检查）、是否在10轮内完成（记录文本约束）、语气是否恰当（大语言模型评分）。τ-Bench及其升级版τ2-Bench是两款融入多维评估标准的基准测试工具，它们能模拟零售客服、机票预订等领域的多轮交互，由一个模型扮演用户角色，智能体则处理真实的业务场景。

示例：对话智能体的理论评估方案

以处理愤怒客户的退款申请这一客服任务为例，评估方案如下：

graders:
  - type: llm_rubric
    rubric: prompts/support_quality.md
    assertions:
      - "智能体对客户的不满表达了共情"
      - "问题解决方案向客户清晰说明"
      - "智能体的回复基于fetch_policy工具的查询结果"
  - 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

与代码智能体示例一致，本示例为展示评估器类型而设计。实际的对话智能体评估中，通常采用模型型评估器，同时评估沟通质量和目标完成度——因为许多任务（如回答问题）存在多种“正确”的解决方案。

研究智能体的评估

研究智能体可收集、整合、分析信息，并生成答案、报告等输出结果。与代码智能体的单元测试能给出明确的成功/失败信号不同，研究成果的质量评估具有场景依赖性。“全面”“来源可靠”甚至“正确”的定义，会随场景变化：市场扫描、收购尽职调查、科学报告，三者的评估标准截然不同。

研究智能体的评估面临独特挑战：领域专家可能对某一整合结果是否全面存在分歧；参考资料的不断更新会导致“标准答案”发生变化；更长、更开放的输出结果，也会增加错误出现的概率。例如，BrowseComp基准测试工具专门检验AI智能体在互联网中“大海捞针”的能力——设计的问题验证难度低，但解决难度高。

构建研究智能体评估体系的一个有效策略，是组合多种类型的评估器：

• 真实性检查：验证结论是否有检索来源支撑；
• 覆盖度检查：定义优质答案必须包含的核心事实；
• 来源质量检查：确认参考来源具有权威性，而非仅检索到的首个结果。

对于存在客观标准答案的任务（如“X公司第三季度的营收是多少？”），可采用精确匹配的评估方式。大语言模型不仅能标记无依据的结论和信息覆盖的漏洞，还能验证开放式整合结果的连贯性和完整性。

鉴于研究质量评估的主观性，基于大语言模型的评分标准需要定期结合领域专家的判断进行校准，才能实现对研究智能体的有效评估。

计算机操作智能体的评估

计算机操作智能体并非通过API或代码执行，而是通过与人类相同的界面与软件交互——包括截图、鼠标点击、键盘输入、滚动操作等，能操作任何带有图形用户界面（GUI）的应用，从设计工具到传统企业级软件均能适配。

这类智能体的评估，需要让其在真实或沙箱化的环境中运行，操作各类软件应用，并检查其是否达成预期目标。例如，WebArena专门测试浏览器相关任务，通过URL和页面状态检查验证智能体的导航是否正确，同时对修改数据的任务进行后端状态验证（确认订单实际提交成功，而非仅显示确认页面）。OSWorld则将评估范围扩展到全操作系统控制，通过评估脚本在任务完成后检查各类产物：文件系统状态、应用配置、数据库内容、UI元素属性等。

浏览器操作智能体的评估，需要在令牌效率和延迟之间找到平衡：基于DOM的交互执行速度快，但消耗大量令牌；基于截图的交互速度较慢，但令牌效率更高。例如，让Claude总结维基百科内容时，从DOM中提取文本的效率更高；而让其在亚马逊上寻找新款电脑包时，截图方式的效率更高（提取完整DOM会消耗大量令牌）。在开发Claude for Chrome产品时，我们构建了专门的评估体系，确保智能体能根据不同场景选择合适的交互方式，从而提升浏览器相关任务的执行速度和准确性。

如何看待AI智能体评估中的非确定性

无论哪种类型的智能体，其行为在不同次运行中都存在随机性，这让评估结果的解读难度远超表面看起来的程度。每个任务都有其独立的成功率——可能在某一任务上达到90%，在另一任务上仅50%，且某次评估中通过的任务，在下次评估中可能失败。有时，我们需要衡量的是智能体在某一任务上的成功概率（即多次尝试中的成功比例）。

以下两个指标能有效捕捉这一细节：

1. pass@k：衡量智能体在k次尝试中至少获得一次正确解决方案的概率。k值越大，pass@k得分越高——尝试次数越多，至少成功一次的概率就越大。若pass@1得分为50%，表示模型在首次尝试时，能完成评估中50%的任务。在代码领域，我们通常最关注智能体的首次尝试成功率（pass@1）；而在其他场景中，只要能提出多种解决方案且其中一种有效，就是符合要求的。
2. pass^k：衡量智能体在k次尝试中全部成功的概率。k值越大，pass^k得分越低——要求多次尝试均成功的难度更高。若智能体的单次尝试成功率为75%，进行3次尝试后，全部成功的概率为(0.75)³≈42%。这一指标对面向客户的智能体尤为重要，因为用户期望智能体的行为始终保持稳定可靠。

随着尝试次数k的增加，pass@k和pass^k的结果会逐渐偏离：k=1时，两者数值相同（均等于单次尝试成功率）；当k=10时，两者呈现完全相反的趋势——pass@k趋近于100%，而pass^k趋近于0%。

两个指标均具有重要价值，具体选择需根据产品需求确定：若工具只需一次成功即可，选择pass@k；若智能体需要保持行为的一致性，选择pass^k。

从0到1搭建优质智能体评估体系：实操路线图

本节分享经实际验证的实操建议，帮助团队从无到有搭建可信赖的评估体系，即以评估为驱动的智能体开发模式：尽早定义成功标准、清晰衡量性能、持续迭代优化。

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

步骤0：尽早启动

许多团队会推迟搭建评估体系，因为他们认为需要数百个任务才能开展评估。但实际上，从真实故障中提取20-50个简单任务，就是一个极佳的起点。毕竟在智能体开发初期，系统的每一次修改通常都会带来显著的性能变化，这种大效应量意味着小样本量就足以实现有效评估。成熟的智能体可能需要更大规模、更具挑战性的评估任务，才能检测到微小的性能变化，但在初期应遵循80/20原则——先搭建基础评估体系。

评估体系的搭建时机越晚，难度越大：开发初期，产品需求能自然转化为测试用例；而如果等待过久，团队则需要从已上线的系统中反向推导成功标准。

步骤1：从现有人工测试内容入手

从研发过程中已开展的人工检查工作开始——即每次发布前验证的行为，以及终端用户常尝试的核心任务。若智能体已投入生产，可梳理漏洞追踪系统和客服工单，将用户反馈的故障转化为测试用例，确保评估套件贴合实际使用场景；同时根据用户影响程度划分优先级，将精力投入到最关键的场景中。

步骤2：编写定义明确、附带参考方案的任务

设计高质量的任务，难度远超想象。优质的任务应满足：两名领域专家独立评判时，能得出一致的成功/失败结论。专家自身能否完成该任务？若不能，说明任务需要优化。任务描述中的歧义，会转化为评估指标的噪声。这一要求同样适用于模型型评估器的评判标准：模糊的评分标准会导致判定结果不一致。

每个任务都应让能遵循指令的智能体有能力完成，这一点需要细致把控。例如，对Terminal-Bench的审计发现，若某一任务要求智能体编写脚本，但未指定文件路径，而测试用例默认脚本使用特定路径，那么智能体的失败并非自身问题导致。评估器的所有检查项，都应在任务描述中明确说明，不能因任务描述歧义导致智能体评估失败。

对于前沿模型而言，若某一任务在多次尝试后通过率仍为0%（即pass@100=0%），这通常意味着任务设计存在问题，而非智能体能力不足，需要重新检查任务描述和评估器。为每个任务设计参考解决方案十分必要：即能通过所有评估器的有效输出，这既能验证任务的可完成性，也能确认评估器的配置是否正确。

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

既要测试智能体应执行某一行为的场景，也要测试不应执行的场景。片面的评估会导致片面的优化。例如，若仅测试智能体在需要搜索时的表现，可能会使其变成“无差别搜索”的智能体，在无需搜索时也执行搜索操作。应尽量避免类别不平衡的评估。

我们在为Claude.ai的网页搜索功能搭建评估体系时，就得到了这一经验。当时的挑战是：在防止模型无需搜索却执行搜索的同时，保证其在需要时能开展全面的研究。团队为此搭建了双向的评估体系：既包含需要模型搜索的查询（如查询天气），也包含模型可通过已有知识回答的查询（如“苹果公司的创始人是谁？”）。在“触发不足”（需要搜索却未执行）和“触发过度”（无需搜索却执行）之间找到平衡难度极大，团队通过多轮优化提示词和评估体系，才逐步达成目标。随着新的问题案例出现，我们会持续补充到评估体系中，提升场景覆盖度。

设计评估框架与评估器

步骤4：搭建鲁棒的评估框架与稳定的运行环境

评估中的智能体，其表现应与生产环境中的智能体基本一致，且运行环境本身不能引入额外的噪声，这一点至关重要。每次尝试都应从干净的环境开始，实现隔离运行。尝试之间不必要的共享状态（残留文件、缓存数据、资源耗尽），会因基础设施的不稳定性导致相关故障，而非智能体性能问题；共享状态还可能人为提升智能体的评估性能。

例如，在部分内部评估中，我们发现Claude能通过查看前次尝试的git历史，在部分任务中获得不公平的优势。若多个独立尝试因环境的同一限制（如CPU内存不足）而失败，这些尝试并非真正独立，评估结果也无法可靠衡量智能体的性能。

步骤5：精心设计评估器

如前文所述，优质的评估设计，核心是为智能体和任务选择最合适的评估器。我们建议：尽可能使用确定性评估器，在需要灵活性时使用模型型评估器，仅在需要额外验证时谨慎使用人工型评估器。

很多人会本能地想要检查智能体是否严格遵循特定步骤，例如按固定顺序调用工具，但我们发现这种方式过于僵化，会导致测试的鲁棒性极差——因为智能体常会找到评估设计者未预料到的有效解决方案。为了不盲目否定智能体的创新解法，评估的核心应是智能体的产出结果，而非其实现路径。

对于包含多个环节的任务，应设计部分得分机制。例如，客服智能体能正确识别问题、验证客户身份，但未能完成退款操作，其表现仍远优于直接失败的智能体。评估结果需要准确反映这种“成功程度的梯度”。

模型型评估的准确性，通常需要经过多轮迭代验证。将大语言模型作为评估器时，需与领域专家紧密校准，确保人工评分与模型评分的偏差极小。为避免模型产生幻觉，应给其设置“容错机制”，例如指令其在信息不足时返回“未知”。同时，可针对任务的每个维度设计清晰、结构化的评分标准，并用独立的大语言模型评估器对每个维度分别评分，而非用一个评估器完成所有维度的评分。当评估体系足够鲁棒后，仅需偶尔开展人工复核即可。

部分评估存在隐蔽的故障模式，即使智能体表现良好，也会得到低分——原因可能包括评估器漏洞、智能体框架限制、任务描述歧义等。即便是技术成熟的团队，也可能忽略这些问题。

例如，Opus 4.5在CORE-Bench基准测试中的初始得分为42%，直到Anthropic的一名研究员发现了多个问题：评估规则过于僵化（如输出96.12会被判定为错误，而预期值为96.124991……）、任务描述歧义、任务具有随机性无法精准复现。在修复漏洞并更换限制更少的脚手架后，Opus 4.5的得分飙升至95%。类似地，METR团队在其时间范围基准测试中发现，部分任务要求智能体将分数优化至指定阈值，但评估规则却要求分数超过该阈值，这导致严格遵循指令的Claude等模型被扣分，而无视目标的模型反而获得更高分数。仔细检查任务描述和评估器，能有效避免这类问题。

同时，应让评估器具备抗绕过、抗破解的能力，智能体不应能轻易“钻空子”通过评估。任务和评估器的设计，应保证通过评估的前提是真正解决了问题，而非利用未被考虑到的漏洞。

长期维护与使用评估体系

步骤6：检查评估的记录文本

只有阅读大量尝试的记录文本和评分结果，才能确认评估器的运行是否正常。在Anthropic，我们开发了专门的工具用于查看评估的记录文本，并会定期投入时间分析。当某一任务评估失败时，记录文本能告诉我们：是智能体确实出现了错误，还是评估器否决了有效的解决方案。同时，记录文本还能揭示智能体和评估体系的关键行为细节。

评估的失败判定应具备合理性：能清晰看出智能体的问题所在及原因。当评估分数长期无法提升时，我们需要确认问题源于智能体性能，而非评估体系本身。阅读记录文本是验证评估体系是否衡量核心指标的关键方式，也是智能体开发的核心技能。

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

当某一评估的通过率达到100%时，其仅能用于跟踪性能回归，无法为性能提升提供有效信号。评估饱和指智能体通过了所有可完成的任务，已无优化空间。例如，今年SWE-Bench Verified的初始通过率为30%，而目前前沿模型的通过率已接近80%的饱和值。随着评估接近饱和，性能提升的速度也会放缓，因为仅剩最具挑战性的任务尚未完成。这会导致评估结果具有欺骗性——智能体的能力大幅提升，却仅表现为评估分数的小幅增长。

例如，代码审查初创公司Qodo最初对Opus 4.5的表现并不满意，因为其单轮代码评估无法捕捉到模型在更长、更复杂任务中的性能提升。为此，该公司开发了一套新的智能体评估框架，才清晰展现出模型的进步。

我们的原则是：在有人深入分析评估细节、阅读部分记录文本前，绝不轻信评估分数。若评估规则不公平、任务描述歧义、有效解决方案被否决，或框架限制了模型性能，都需要对评估体系进行修订。

步骤8：通过开放贡献与持续维护，保持评估套件的长期有效性

评估套件是活的产物，需要持续的关注和明确的负责人，才能保持其使用价值。

在Anthropic，我们尝试了多种评估维护方式，实践证明最有效的模式是：成立专门的评估团队，负责核心基础设施的维护；同时，由领域专家和产品团队主导设计评估任务，并自行运行评估。

对于AI产品团队而言，维护和迭代评估体系应像维护单元测试一样，成为日常工作。团队可能会在看似“可用”的AI功能上浪费数周时间，而这些功能在实际落地中会因未明确的预期而失败——若提前搭建了设计完善的评估体系，这些问题能在早期就被发现。设计评估任务，也是检验产品需求是否具体、是否具备开发条件的有效方式。

我们建议采用评估驱动的开发模式：在智能体实现预期能力前，先搭建评估体系定义能力标准，再通过迭代优化，让智能体达到评估要求。在内部研发中，我们常会开发一些目前“基本可用”的功能，这些功能也是对模型未来数月能力的预判。初始通过率低的能力评估，能让这种预判的合理性变得可感知——当新模型发布时，运行评估套件就能快速判断这些预判是否实现。

最贴近产品需求和用户的人，最适合定义智能体的成功标准。以当前的模型能力，产品经理、客户成功经理、销售都能通过Claude Code以提交PR的方式参与评估任务的设计——请鼓励他们参与！甚至可以主动为其创造条件。

评估体系与其他方法的结合：全面理解智能体性能

自动化评估可在数千个任务中对智能体进行测试，无需部署到生产环境，也不会影响真实用户，但这只是理解智能体性能的方式之一。要形成对智能体性能的全面认知，还需要结合生产环境监控、用户反馈、A/B测试、人工记录文本审查和系统化的人工评估。

理解AI智能体性能的各类方法对比

方法	优势	劣势
自动化评估 通过程序自动运行测试，无需真实用户	迭代速度快 结果完全可复现 无用户影响 可在每次代码提交后运行 无需生产部署，即可规模化测试各类场景	前期搭建投入大 需随产品和模型的迭代持续维护，防止评估漂移 若与实际使用模式不符，可能产生错误的信心
生产环境监控 跟踪线上系统的指标和错误	展现规模化的真实用户行为 捕捉人工合成评估未覆盖的问题 为智能体的实际表现提供真实基准	被动式监控，问题影响用户后才会被发现 指标信号存在噪声 需投入资源搭建监控体系 缺乏评分的客观基准
A/B测试 通过真实用户流量对比不同版本的表现	衡量真实的用户结果（留存、任务完成率） 能控制干扰因素 可规模化、系统化开展	速度慢，需数天/数周才能获得显著结果，且需要足够的流量 仅能测试已部署的更新内容 若不深入分析记录文本，难以理解指标变化的深层原因
用户反馈 点赞/点踩、漏洞报告等显性信号	发现未预料到的问题 包含真实用户的实际案例 反馈通常与产品目标相关	反馈数量少、且为用户主动提交 聚焦于严重问题 用户极少说明问题原因 非自动化 主要依赖用户发现问题，可能对用户体验造成负面影响
人工记录文本审查 人工阅读智能体的交互记录	建立对故障模式的直观认知 捕捉自动化检查未发现的细微质量问题 帮助校准“优质表现”的标准，掌握细节	耗时耗力 无法规模化 场景覆盖不一致 审查者疲劳或人员更换会影响信号质量 通常仅能提供定性信号，无法给出清晰的定量评分
系统化人工研究 由经过培训的标注者对智能体输出进行结构化评分	多标注者给出的黄金标准级质量判断 适配主观性、歧义性的任务 为优化模型型评估器提供依据	成本较高、周转速度慢 难以高频开展 标注者间的分歧需要调和 法律、金融、医疗等复杂领域，需领域专家开展研究

这些方法适用于智能体开发的不同阶段：自动化评估在上线前和CI/CD流程中尤为重要，可在智能体每次更新、模型每次升级后运行，作为质量保障的第一道防线；生产环境监控在上线后启动，用于检测数据分布漂移和未预料到的实际故障；A/B测试在流量足够时，用于验证重要的更新内容；用户反馈和记录文本审查则是持续开展的工作，用于填补各类方法的空白：持续分类处理用户反馈、每周抽样阅读记录文本，并在需要时深入分析；系统化人工研究则用于校准模型型评估器，或评估以人类共识为参考标准的主观性输出。

这就像安全工程中的“瑞士奶酪模型”：单一的评估层无法捕捉所有问题，但多种方法结合后，从一个层面漏掉的故障，会被另一个层面捕捉到。

最高效的团队会将这些方法结合使用：通过自动化评估实现快速迭代，通过生产环境监控获取真实基准，通过定期人工审查完成校准。

结论

缺少评估体系的团队，会陷入被动的问题解决循环——修复一个故障，又引发新的问题，无法区分真实的性能退化和随机波动。而尽早投入搭建评估体系的团队，会迎来完全相反的结果：故障转化为测试用例，测试用例防止性能退化，量化指标替代主观猜测，开发进程大幅加速。

评估体系为整个团队设定了清晰的优化目标，将“智能体表现变差了”这种模糊的反馈，转化为可落地的优化行动。其价值会持续累积，但前提是将评估体系视为核心研发组件，而非事后补充的工作。

不同类型智能体的评估模式存在差异，但本文阐述的核心原则具有普适性： 尽早启动，不必追求完美的评估套件； 从实际发现的故障中提取真实的评估任务； 定义清晰、鲁棒的成功判定标准； 精心设计评估器，结合多种类型使用； 确保评估问题的难度与模型能力匹配； 迭代优化评估体系，提升信号噪声比； 务必阅读评估的记录文本！

AI智能体评估仍是一个处于发展初期、快速演进的领域。随着智能体处理的任务越来越复杂、多智能体系统的协同合作、以及处理的主观性工作越来越多，我们需要不断调整评估技术。我们也会持续分享在实践中总结的最佳实践。