揭开 AI 智能体评估的神秘面纱

引言

良好的评估有助于团队更自信地交付 AI 智能体。没有它们，很容易陷入被动应对的循环——只在生产环境中发现问题，而修复一个故障又会引发其他问题。评估能在问题和行为变化影响用户之前使其变得可见，其价值会随着智能体的生命周期不断累积。

正如我们在 Building effective agents 中所述，智能体会在多个轮次中运行：调用工具、修改状态，并根据中间结果进行调整。正是这些使 AI 智能体变得有用的能力——自主性、智能性和灵活性——也让它们更难评估。

通过我们的内部工作以及与处于智能体开发前沿的客户的合作，我们学到了如何为智能体设计更严谨、更有用的评估。以下是跨多种智能体架构和实际部署用例中行之有效的方法。

评估的结构

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

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

智能体评估则更加复杂。智能体在多个轮次中使用工具，修改环境中的状态并随之调整——这意味着错误可能会传播并累积。前沿模型还能找到超越静态评估限制的创造性解决方案。例如，Opus 4.5 通过发现政策中的漏洞，解决了 𝜏2-bench 中关于预订航班的问题。它按照既定规则“失败”了评估，但实际上为用户想出了更好的解决方案。

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

• 任务（又称为问题或测试用例）是具有明确定义的输入和成功标准的单个测试。
• 对任务的每次尝试称为一次试验。由于模型输出在不同运行之间存在差异，我们会运行多次试验以产生更一致的结果。
• 评分器是对智能体表现的某些方面进行打分的逻辑。一个任务可以有多个评分器，每个评分器包含多个断言（有时称为检查）。
• 记录（也称为追踪或轨迹）是一次试验的完整记录，包括输出、工具调用、推理、中间结果以及任何其他交互。对于 Anthropic API，这是评估运行结束时的完整 messages 数组——包含评估期间对 API 的所有调用和所有返回的响应。
• 结果是试验结束时环境中的最终状态。一个航班预订代理可能会在对话记录结束时说“您的航班已预订”，但结果是指环境的 SQL 数据库中是否存在预订记录。
• 评估框架是端到端运行评估的基础设施。它提供指令和工具，并发运行任务，记录所有步骤，对输出进行评分，并汇总结果。
• 代理框架（或脚手架）是使模型能够充当代理的系统：它处理输入、编排工具调用并返回结果。当我们评估“一个代理”时，我们评估的是框架和模型协同工作的效果。例如，Claude Code 是一个灵活的代理框架，我们通过 Agent SDK 使用其核心原语构建了我们的长时间运行代理框架。
• 评估套件是为衡量特定能力或行为而设计的任务集合。套件中的任务通常共享一个宽泛的目标。例如，一个客户支持评估套件可能会测试退款、取消和升级处理。

为什么要构建评估？

当团队刚开始构建智能体时，通过手动测试、自食其力（dogfooding）和直觉的结合，他们往往能走得很远。更严格的评估甚至可能被视为拖慢发布速度的负担。但在早期原型阶段之后，一旦智能体投入生产并开始扩展，没有评估的构建方式就开始失效。

崩溃点通常出现在用户反馈智能体在更改后感觉变差，而团队“盲目飞行”，除了猜测和检查之外没有其他验证方式的时候。没有评估，调试是被动的：等待投诉、手动复现、修复缺陷，并希望没有其他东西回归。团队无法区分真正的回归和噪音，无法在发布前自动针对数百个场景测试更改，也无法衡量改进。

我们已经多次看到这种发展过程。例如，Claude Code 最初基于 Anthropic 员工和外部用户的反馈进行快速迭代。后来，我们添加了评估——首先是针对简洁性和文件编辑等狭窄领域，然后是针对过度工程化等更复杂的行为。这些评估帮助识别问题、指导改进，并聚焦研究与产品的协作。结合生产监控、A/B 测试、用户研究等，评估为 Claude Code 在扩展过程中持续改进提供了信号。

在智能体生命周期的任何阶段，编写评估都是有用的。早期，评估迫使产品团队明确智能体的成功标准，而后期它们有助于维持一致的质量标准。

Descript的智能体帮助用户编辑视频，因此他们围绕成功编辑工作流的三个维度构建了评测：不要破坏内容、按要求执行、执行得当。他们从人工评分演进到由产品团队定义标准、并定期进行人工校准的 LLM 评分，如今会定期运行两套独立的评测，分别用于质量基准测试和回归测试。Bolt AI 团队开始构建评测的时间较晚，是在他们已经拥有一个被广泛使用的智能体之后。在 3 个月内，他们构建了一套评测系统，该系统运行其智能体并使用静态分析对输出进行评分，使用浏览器智能体测试应用程序，并采用 LLM 评判者来评估指令遵循等行为。

有些团队在开发初期就创建评测；另一些团队则在规模扩大后才添加评测，此时评测已成为改进智能体的瓶颈。评测在智能体开发初期尤其有用，可以明确编码预期行为。两位工程师阅读同一份初始规格说明，可能会对 AI 应如何处理边缘情况得出不同的解读。评测套件可以消除这种歧义。无论何时创建，评测都有助于加速开发。

评测还决定了你采用新模型的速度。当更强大的模型发布时，没有评测的团队需要数周的测试，而拥有评测的竞争对手可以快速确定模型的优势、调整提示词，并在几天内完成升级。

一旦有了评测，你就能免费获得基准和回归测试：延迟、token 用量、每任务成本和错误率都可以在固定的任务库上进行跟踪。评测还可以成为产品团队与研究团队之间带宽最高的沟通渠道，定义研究人员可以优化的指标。显然，评测的好处远不止跟踪回归和改进。由于成本是预先可见的，而收益是后期累积的，其复利价值很容易被忽视。

如何评估 AI 智能体

我们看到目前大规模部署的几种常见智能体类型，包括编码智能体、研究智能体、计算机使用智能体和对话智能体。每种类型可能部署在各种各样的行业中，但可以使用类似的技术进行评估。你无需从头发明评估方法。以下章节介绍了针对几种智能体类型的成熟技术。以这些方法为基础，然后将其扩展到你的领域。

智能体评估的评分器类型

智能体评估通常结合三种类型的评分器：基于代码的、基于模型的和人工的。每个评分器评估对话记录或结果的某一部分。有效评估设计的一个关键要素是为任务选择合适的评分器。

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

能力评估与回归评估

能力或“质量”评估会问：“这个智能体能做好什么？”它们的初始通过率应该较低，针对智能体表现吃力的任务，给团队一个需要攀登的坡度。

回归评估会问：“智能体是否仍然能处理它过去能处理的所有任务？”其通过率应接近 100%。它们用于防止退步，因为分数下降意味着某些地方出了问题，需要改进。随着团队在能力评估上不断攀登，同时运行回归评估也很重要，以确保更改不会在其他地方引发问题。

智能体启动并优化后，通过率高的能力评估可以“毕业”成为回归测试套件，持续运行以捕捉任何性能漂移。曾经衡量“我们能否做到？”的任务，现在衡量的是“我们能否仍然可靠地做到？”

评估编码智能体

编码智能体编写、测试和调试代码，像人类开发者一样浏览代码库并运行命令。针对现代编码智能体的有效评估通常依赖于明确规范的任务、稳定的测试环境以及对生成代码的全面测试。

确定性评分器非常适合编码智能体，因为软件的评估通常很直接：代码能否运行？测试能否通过？两个广泛使用的编码智能体基准测试 SWE-bench Verified 和 Terminal-Bench 都采用了这种方法。SWE-bench Verified 向智能体提供来自流行 Python 仓库的 GitHub issue，并通过运行测试套件对解决方案进行评分；只有当解决方案修复了失败的测试且没有破坏现有测试时，才算通过。大语言模型在这一评估上的成绩在短短一年内从 40% 提升到了 >80%。Terminal-Bench 则采取了不同的路线：它测试端到端的技术任务，例如从源代码构建 Linux 内核或训练机器学习模型。

一旦你有了一组通过/失败的测试来验证编码任务的关键结果，通常也有必要对交互记录进行评分。例如，基于启发式规则的代码质量规则可以根据通过测试之外的更多维度来评估生成的代码，而带有明确评分标准的基于模型的评分器可以评估诸如智能体如何调用工具或如何与用户交互等行为。

示例：编码智能体的理论评估

考虑一个编码任务，智能体必须修复一个身份验证绕过漏洞。如下方的示例 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

请注意，此示例为了演示展示了所有可用的评分器。在实践中，编码评估通常依赖单元测试来验证正确性，依赖 LLM 评分标准来评估整体代码质量，其他评分器和指标仅在需要时添加。

评估对话式智能体

对话式智能体在客服、销售或辅导等领域与用户交互。与传统聊天机器人不同，它们会维护状态、使用工具，并在对话过程中采取行动。虽然编码和研究智能体也可能涉及与用户的多轮交互，但对话式智能体带来了一个独特的挑战：交互本身的质量就是你评估内容的一部分。针对对话式智能体的有效评估通常依赖于可验证的最终状态结果，以及能够同时捕捉任务完成情况和交互质量的评分标准。与大多数其他评估不同，它们通常需要第二个大语言模型来模拟用户。我们在对齐审计智能体中采用了这种方法，通过长时间的对抗性对话对模型进行压力测试。

对话代理的成功可能是多维度的：工单是否已解决（状态检查）、是否在 <10 轮内完成（转录约束），以及语气是否恰当（LLM 评分标准）？包含多维度的两个基准是 𝜏-Bench 及其后继者 τ2-Bench。它们模拟了零售支持和机票预订等领域的多轮交互，其中一个模型扮演用户角色，而代理则在真实场景中进行导航。

示例：对话代理的理论评估

考虑一个支持任务，代理必须为一位愤怒的客户处理退款。

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

与我们的编码代理示例一样，此任务展示了多种评分器类型以作说明。在实践中，对话代理评估通常使用基于模型的评分器来评估沟通质量和目标完成度，因为许多任务——如回答问题——可能有多个“正确”解决方案。

评估研究代理

研究代理收集、综合和分析信息，然后生成答案或报告等输出。与单元测试提供二元通过/失败信号的编码代理不同，研究质量只能相对于任务来判断。什么算作“全面”、“来源可靠”甚至“正确”取决于上下文：市场扫描、收购尽职调查和科学报告各自需要不同的标准。

研究评估面临独特挑战：专家可能对综合是否全面存在分歧，随着参考内容不断变化，基准真相也会随之改变，而更长、更开放式的输出会带来更多出错的空间。例如，BrowseComp 这样的基准测试 AI 代理是否能在开放网络中大海捞针——这些问题被设计为易于验证但难以解决。

构建研究代理评估的一种策略是结合多种评分器类型。有据可查性检查验证主张是否得到检索来源的支持，覆盖度检查定义好答案必须包含的关键事实，来源质量检查确认所查阅的来源是权威的，而不仅仅是第一个检索到的。对于具有客观正确答案的任务（“X 公司第三季度的营收是多少？”），精确匹配即可。LLM 可以标记无依据的主张和覆盖缺口，但也可以验证开放式综合的连贯性和完整性。

鉴于研究质量的主观性，基于 LLM 的评分标准应经常与专家的人类判断进行校准，以便有效地对这些代理进行评分。

计算机使用代理

计算机使用智能体通过与人类相同的界面与软件交互——截图、鼠标点击、键盘输入和滚动——而不是通过 API 或代码执行。它们可以使用任何具有图形用户界面（GUI）的应用程序，从设计工具到遗留企业软件。评估需要在真实或沙盒环境中运行智能体，使其能够使用软件应用程序，并检查其是否达到了预期结果。例如，WebArena 测试基于浏览器的任务，使用 URL 和页面状态检查来验证智能体是否正确导航，对于修改数据的任务还会进行后端状态验证（确认订单确实已下达，而不仅仅是确认页面出现了）。OSWorld 将此扩展到完整的操作系统控制，评估脚本会在任务完成后检查各种产物：文件系统状态、应用程序配置、数据库内容和 UI 元素属性。

浏览器使用智能体需要在 token 效率和延迟之间取得平衡。基于 DOM 的交互执行速度快但消耗大量 token，而基于截图的交互速度较慢但更节省 token。例如，当要求 Claude 总结维基百科时，从 DOM 中提取文本更高效。当在亚马逊上寻找新的笔记本电脑包时，截取截图更高效（因为提取整个 DOM 需要大量 token）。在我们的 Claude for Chrome 产品中，我们开发了评估来检查智能体是否为每个上下文选择了正确的工具。这使我们能够更快、更准确地完成基于浏览器的任务。

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

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

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

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

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

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

从零到一：打造卓越智能体评估的路线图

本节介绍我们经过实践检验的实用建议，帮助你从没有评估到建立可信赖的评估。可将其视为评估驱动的智能体开发路线图：尽早定义成功、清晰衡量，并持续迭代。

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

第 0 步：尽早开始

我们看到许多团队推迟构建评估，因为他们认为需要数百个任务。实际上，从真实故障中提取的 20-50 个简单任务就是一个很好的起点。毕竟，在智能体开发早期，对系统的每次改动通常都有清晰、显著的影响，这种大效应量意味着小样本量就足够了。更成熟的智能体可能需要更大、更难的评估来检测较小的影响，但一开始最好采用 80/20 法则。等待越久，评估就越难构建。早期，产品需求自然会转化为测试用例。等待太久，你就得从线上系统反向推导成功标准。

第 1 步：从你已有的手动测试开始

从开发过程中进行的手动检查开始——每次发布前验证的行为以及最终用户尝试的常见任务。如果你已经上线，请查看你的 bug 追踪系统和客服队列。将用户报告的故障转化为测试用例，可确保你的测试套件反映实际使用情况；按用户影响进行优先级排序，有助于你将精力投入到关键之处。

第 2 步：编写无歧义的任务并提供参考解答

确保任务质量比看起来更难。一个好的任务是两位领域专家能独立得出相同通过/不通过结论的任务。他们自己能完成该任务吗？如果不能，任务就需要改进。任务规格中的歧义会成为指标中的噪音。这对基于模型的评分器的标准同样适用：模糊的评分标准会产生不一致的判断。

每个任务都应能由正确遵循指令的智能体完成。这可能很微妙。例如，对 Terminal-Bench 的审计发现，如果任务要求智能体编写脚本但未指定文件路径，而测试又假定脚本位于特定文件路径，智能体可能会因非自身过错而失败。评分器检查的所有内容都应从任务描述中清晰可知；智能体不应因规格模糊而失败。对于前沿模型，多次试验中 0% 的通过率（即 0% pass@100）通常表明任务本身有问题，而非智能体无能，也提示你应仔细检查任务规格和评分器。对于每个任务，创建参考解答很有用：一个已知可行、能通过所有评分器的输出。这能证明任务可解，并验证评分器配置正确。

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

测试行为应该发生和不应该发生的两种情况。单方面的评估会导致单方面的优化。例如，如果你只测试智能体在应该搜索时是否搜索，你可能会得到一个几乎对所有事情都进行搜索的智能体。尽量避免类别不平衡的评估。我们在为Claude.ai构建网络搜索评估时亲身学到了这一点。挑战在于防止模型在不该搜索时进行搜索，同时保留其在适当时进行广泛研究的能力。团队构建了涵盖两个方向的评估：模型应该搜索的查询（比如查找天气）和它应该根据现有知识回答的查询（比如“谁创立了苹果公司？”）。在触发不足（应该搜索时没有搜索）和触发过度（不该搜索时却搜索了）之间取得恰当的平衡是困难的，并且需要对提示和评估进行多轮改进。随着更多示例问题的出现，我们不断将其添加到评估中以提高覆盖率。

设计评估框架和评分器

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

评估中的智能体其运行方式与生产环境中使用的智能体大致相同至关重要，而且环境本身不应引入额外的噪声。每次试验都应通过从干净的环境开始来实现“隔离”。运行之间不必要的共享状态（残留文件、缓存数据、资源耗尽）可能会因基础设施不稳定而非智能体性能导致关联性故障。共享状态也可能人为地提升性能。例如，在一些内部评估中，我们观察到 Claude 通过检查之前试验的 git 历史记录在某些任务上获得了不公平的优势。如果多个不同的试验因为环境中的同一限制（如 CPU 内存有限）而失败，这些试验就不是独立的，因为它们受到同一因素的影响，评估结果在衡量智能体性能方面就变得不可靠。

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

如上所述，优秀的评估设计涉及为智能体和任务选择最佳的评分器。我们建议尽可能选择确定性评分器，在必要时或为了额外的灵活性选择 LLM 评分器，并审慎地使用人工评分器进行额外验证。

人们有一种常见的直觉，即检查智能体是否遵循了非常具体的步骤，比如按正确顺序进行一系列工具调用。我们发现这种方法过于僵化，会导致测试过于脆弱，因为智能体经常会找到评估设计者未曾预料到的有效方法。为了避免不必要地惩罚创造性，通常更好的做法是对智能体的产出进行评分，而不是它所走的路径。

对于包含多个组成部分的任务，要设置部分得分。一个正确识别问题并验证客户但未能处理退款的支持智能体，比一个立即失败的智能体要好得多。在结果中体现这种成功程度的连续性很重要。

模型评分通常需要仔细迭代以验证准确性。LLM-as-judge 评分器应与人类专家进行密切校准，以确信人类评分与模型评分之间几乎没有差异。为避免幻觉，应给 LLM 留有余地，例如提供指令，让其在信息不足时返回“Unknown”。创建清晰、结构化的评分标准来对任务的每个维度进行评分，然后使用独立的 LLM-as-judge 对每个维度分别评分，而不是用一个评分器对所有维度进行评分，也会有所帮助。一旦系统足够稳健，只需偶尔进行人工审核即可。

有些评估存在微妙的失败模式，即使智能体表现出色也会得到低分，因为智能体由于评分错误、智能体框架限制或任务描述模糊而未能解决任务。即使是经验丰富的团队也可能忽略这些问题。例如，Opus 4.5 在 CORE-Bench 上最初得分 42%，直到一位 Anthropic 研究人员发现了多个问题：僵化的评分在期望“96.124991…”时对“96.12”进行了惩罚、模糊的任务规格，以及无法精确复现的随机任务。修复错误并使用限制更少的框架后，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 测试、人工转录审查和系统性的人工评估。

这些方法对应智能体开发的不同阶段。自动化评估在发布前和 CI/CD 中尤其有用，每次智能体变更和模型升级时都会运行，作为防范质量问题的第一道防线。生产环境监控在发布后启动，用于检测分布漂移和意料之外的真实世界故障。A/B 测试在拥有足够流量后用于验证重大变更。用户反馈和转录审查是持续进行的实践，用于填补空白：持续对反馈进行分类，每周抽样阅读转录，并根据需要深入挖掘。将系统性的人工研究保留用于校准 LLM 评分器，或评估以人类共识为参考标准的主观输出。

最有效的团队会结合这些方法：自动化评估用于快速迭代，生产环境监控用于获取真实情况，定期人工审查用于校准。

结论

没有评估的团队会陷入被动应对的循环——修复一个故障，又制造出另一个，无法区分真正的回归和噪声。早期投入的团队则会发现相反的情况：随着故障变成测试用例，测试用例防止回归，指标取代猜测，开发速度会加快。评估让整个团队有了明确的目标，将“智能体感觉变差了”转化为可操作的事项。其价值会不断累积，但前提是你要将评估视为核心组成部分，而非事后补充。

不同类型的智能体，其模式各不相同，但这里描述的基本原则是不变的。尽早开始，不要等待完美的测试套件。从你看到的故障中获取现实的任务。定义明确、稳健的成功标准。精心设计评分器并结合多种类型。确保问题对模型来说足够难。不断迭代评估以提高其信噪比。阅读转录！

AI 智能体评估仍是一个新兴且快速发展的领域。随着智能体承担更长的任务、在多智能体系统中协作，并处理越来越主观的工作，我们将需要调整我们的技术。随着我们了解更多，我们会继续分享最佳实践。

附录：评估框架

有几个开源和商业框架可以帮助团队实施智能体评估，而无需从头构建基础设施。正确的选择取决于你的智能体类型、现有技术栈，以及你是否需要离线评估、生产环境可观测性，或两者都需要。

Harbor 专为在容器化环境中运行智能体而设计，提供了跨云提供商大规模运行试验的基础设施，以及用于定义任务和评分器的标准化格式。像 Terminal-Bench 2.0 这样的流行基准测试通过 Harbor 注册表发布，使得在运行自定义评估套件的同时运行既定基准测试变得容易。

Braintrust 是一个将离线评估与生产环境可观测性和实验跟踪相结合的平台——适用于既需要在开发期间迭代又需要在生产环境中监控质量的团队。其 `autoevals` 库包含用于事实性、相关性及其他常见维度的预构建评分器。

LangSmith 提供追踪、离线和在线评估以及数据集管理，并与 LangChain 生态系统紧密集成。Langfuse 作为自托管的开源替代方案，提供类似的功能，适用于有数据驻留要求的团队。

Arize 提供 Phoenix，一个用于 LLM 追踪、调试以及离线或在线评估的开源平台，以及 AX，一个扩展 Phoenix 以实现规模化、优化和监控的 SaaS 产品。

许多团队会组合使用多种工具、自行构建评估框架，或仅使用简单的评估脚本作为起点。我们发现，虽然框架可以成为加速进展和实现标准化的有价值方式，但它们的好坏取决于你通过它们运行的评估任务。通常最好的做法是快速选择一个适合你工作流的框架，然后将精力投入到评估本身，通过迭代高质量的测试用例和评分器来提升效果。