Anthropic 详解如何为 AI 智能体设计评测

引言

好的评估能帮助团队更有信心地交付 AI 智能体。没有评估，团队很容易陷入被动反应的循环——只有在生产环境中才发现问题，而修复一个故障又会引发其他故障。评估能在问题与行为变化影响用户之前将其暴露出来，而且其价值会随着智能体生命周期的推进不断累积。

正如我们在构建高效智能体中所描述的，智能体要经历许多轮次：调用工具、修改状态，并根据中间结果进行调整。让 AI 智能体变得有用的这些能力——自主性、智能性和灵活性——同时也让它们更难被评估。

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

评估的结构

评估（“eval”）是对 AI 系统的一种测试：给 AI 一个输入，然后对其输出应用评分逻辑来衡量成功与否。在本文中，我们聚焦于可在开发期间运行、无需真实用户参与的自动化评估。

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

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

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

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

为什么要构建评估？

当团队刚开始构建 agent 时，他们可以通过手动测试、dogfooding 和直觉的组合取得惊人的进展。更严格的评估甚至可能看起来像是拖慢交付的开销。但在早期原型阶段之后，一旦 agent 进入生产环境并开始扩展，没有评估的构建就开始崩溃。

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

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

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

Descript 的 agent 帮助用户编辑视频，因此他们围绕成功编辑工作流的三个维度构建了评估：不破坏东西、做我要求的事、做好它。他们从手动评分演变为由产品团队定义标准并定期进行人工校准的 LLM 评分器，现在定期运行两个独立的套件，分别用于质量基准测试和回归测试。Bolt AI 团队较晚才开始构建评估，当时他们已经有了一个广泛使用的 agent。在 3 个月内，他们构建了一个评估系统，该系统运行他们的 agent 并通过静态分析对输出进行评分，使用浏览器 agent 测试应用，并采用 LLM 评判器来评估指令遵循等行为。

有些团队在开发开始时创建评估；另一些团队则在规模扩大后、评估成为改进 agent 的瓶颈时才添加。评估在 agent 开发开始时特别有用，可以明确编码预期行为。两个工程师阅读相同的初始规范可能会对 AI 应如何处理边缘情况得出不同的解释。评估套件解决了这种模糊性。无论何时创建，评估都有助于加速开发。

评估还决定了你能多快地采用新模型。当更强大的模型出现时，没有评估的团队要花数周时间测试，而拥有评估的竞争对手能迅速判断模型的优势、调整提示词，并在几天内完成升级。 

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

如何评估 AI 智能体

如今我们看到多种常见类型的智能体已大规模部署，包括编码智能体、研究智能体、计算机使用智能体和对话智能体。每种类型都可能部署在众多行业中，但它们可以用相似的技术来评估。你不需要从零开始发明一套评估方法。下面各节介绍了针对几种智能体类型的经过验证的技术。将这些方法作为基础，再扩展到你的领域。

智能体的评分器类型

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

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

能力评估与回归评估

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

回归评估问的是：“这个智能体还能处理它过去处理的所有任务吗？”其通过率应接近 100%。它们防止倒退，因为分数下降意味着某处出了问题、需要改进。当团队在能力评估上攀登时，同时运行回归评估也很重要，以确保改动不会在别处引发问题。

在智能体上线并优化后，通过率高的能力评估可以“毕业”成为持续运行的回归测试套件，以捕捉任何漂移。曾经衡量“我们到底能不能做到这件事？”的任务，此后衡量的是“我们还能可靠地做到这件事吗？”

评估编码智能体

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

确定性评分器对编码智能体来说很自然，因为软件通常很容易评估：代码能运行吗？测试能通过吗？两个广泛使用的编码智能体基准——SWE-bench Verified 和 Terminal-Bench——就采用这种方法。SWE-bench Verified 向智能体提供来自热门 Python 仓库的 GitHub issue，并通过运行测试套件来给解决方案评分；只有修复了失败的测试且不破坏现有测试的解决方案才算通过。LLM 在这一评估上的成绩仅一年内就从 40% 提升到 >80%。Terminal-Bench 走的是另一条路线：它测试端到端的技术任务，例如从源码构建 Linux 内核或训练一个 ML 模型。

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

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

考虑一个编码任务，智能体必须修复一个认证绕过漏洞。如下面的示例 YAML 文件所示，可以使用评分器和指标来评估该智能体。 

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

评估对话智能体

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

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

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

考虑一个客服任务，智能体必须为一位沮丧的客户处理退款。

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

评估研究智能体

研究型智能体负责收集、综合和分析信息，然后产出答案或报告等成果。与编码智能体不同——后者可通过单元测试获得二元的通过/失败信号——研究质量只能相对于具体任务来评判。什么算“全面”、“来源可靠”，甚至“正确”，都取决于具体情境：市场扫描、收购尽职调查和科学报告各自需要不同的标准。

研究类评估面临独特挑战：专家可能对一份综合报告是否全面存在分歧；随着参考内容不断变化，基准事实也会随之变动；而更长、更开放式的输出则为错误留下了更多空间。例如，BrowseComp 这类基准测试考察 AI 智能体能否在开放网络中大海捞针——其问题被设计成易于验证但难以解答。

构建研究型智能体评估的一种策略是组合多种评分器。事实依据检查验证各项主张是否有检索到的来源支撑；覆盖度检查界定一份好答案必须包含的关键事实；来源质量检查确认所参考的来源具有权威性，而非仅仅是首先检索到的内容。对于有客观正确答案的任务（“X 公司第三季度营收是多少？”），精确匹配即可奏效。LLM 可以标记缺乏支撑的主张和覆盖缺口，同时也能验证开放式综合内容的连贯性与完整性。

鉴于研究质量的主观性，基于 LLM 的评分标准应经常对照专家人工判断进行校准，才能有效评估这些智能体。

计算机使用型智能体

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

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

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

无论哪种 agent 类型，agent 的行为在不同运行之间都会有所差异，这使得评估结果比表面上看起来更难解读。每个任务都有自己的成功率——也许某个任务是 90%，另一个是 50%——而某次评估运行中通过的任务，下一次可能就会失败。有时，我们想衡量的是 agent 在某个任务上成功的频率（即成功试验所占的比例）。

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

pass@k 衡量的是 agent 在 k 次尝试中至少得到一次正确解的可能性。随着 k 增大，pass@k 分数会上升：更多“射门机会”意味着至少成功 1 次的概率更高。pass@1 为 50% 意味着模型在评估中首次尝试就能成功完成一半的任务。在编程场景中，我们通常最关心 agent 能否在第一次尝试时就找到解法——即 pass@1。在其他情况下，只要有一个方案可行，提出多个方案也是合理的。

pass^k 衡量的是全部 k 次试验都成功的概率。随着 k 增大，pass^k 会下降，因为要求在更多试验中保持一致是更难达到的标准。如果你的 agent 每次试验的成功率为 75%，而你运行 3 次试验，那么三次全部通过的概率是 (0.75)³ ≈ 42%。这一指标对面向客户的 agent 尤为重要，因为用户期望它每次都能可靠地表现。

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

从零到一：为 agent 构建优秀评估的路线图

本节阐述我们从实践中总结、经过实地检验的建议，帮助你从没有评估走向可信赖的评估。可以把它看作以评估驱动 agent 开发的路线图：尽早定义成功、清晰地衡量成功，并持续迭代。

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

第 0 步：尽早开始

我们看到一些团队迟迟不构建评估，因为他们认为自己需要数百个任务。实际上，从真实失败中提取的 20-50 个简单任务就是一个很好的起点。毕竟在 agent 开发的早期，系统的每一次改动往往都会带来明显、可察觉的影响，而这种较大的效应量意味着小样本量就足够了。更成熟的 agent 可能需要更大、更难的评估才能检测到较小的效应，但一开始最好采用 80/20 方法。等待越久，评估就越难构建。在早期，产品需求会自然而然地转化为测试用例。如果等得太久，你就只能从运行中的系统逆向推导成功标准。

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

从你在开发过程中执行的手动检查开始——即每次发布前你验证的行为，以及最终用户常尝试的常见任务。如果你已经上线，就查看你的缺陷跟踪系统和支持队列。把用户报告的失败转化为测试用例，可以确保你的测试套件反映实际使用情况；按用户影响排序，有助于你把精力投入到最关键的地方。

第 2 步：编写带有参考解的无歧义任务

把任务质量做对，比看起来更难。一个好的任务，是两位领域专家能够独立得出相同通过/失败判定的任务。他们自己能通过这个任务吗？如果不能，这个任务就需要改进。任务描述中的歧义会变成指标中的噪声。基于模型的评分器的评分标准也是如此：含糊的评分细则会产生不一致的判定。

每个任务都应当能被一个正确遵循指令的 agent 通过。这一点可能很微妙。例如，在审计 Terminal-Bench 时发现，如果某个任务要求 agent 编写一个脚本，但没有指定文件路径，而测试却假定脚本位于某个特定文件路径，那么 agent 可能会在并非自身过错的情况下失败。评分器检查的所有内容都应当能从任务描述中清楚地看出来；agent 不应因为规格含糊而失败。对于前沿模型来说，在多次试验中通过率为 0%（即 pass@100 为 0%）通常更多是任务本身有问题的信号，而不是 agent 能力不足，也是需要复核任务规格和评分器的信号。对于每个任务，创建一个参考解是很有用的：一个已知能通过所有评分器的工作输出。这可以证明任务是可解的，并验证评分器配置正确。

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

既要测试行为应该发生的情况，也要测试行为不应该发生的情况。单方面的评估会导致单方面的优化。例如，如果你只测试 agent 在应该搜索时是否搜索，最终可能会得到一个几乎什么都搜索的 agent。尽量避免类别不均衡的评估。我们在为 Claude.ai 构建网页搜索评估时亲身学到了这一点。挑战在于防止模型在不该搜索时进行搜索，同时保留其在适当时进行大量研究的能力。团队构建了覆盖两个方向的评估：模型应该搜索的查询（比如查天气）和模型应该用已有知识回答的查询（比如“谁创立了 Apple？”）。在触发不足（该搜索时不搜索）和过度触发（不该搜索时搜索）之间取得恰当平衡很困难，需要对提示词和评估进行多轮改进。随着更多示例问题出现，我们会继续补充评估以改进覆盖范围。

设计评估框架和评分器

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

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

第 5 步：精心设计评分器

如上所述，优秀的评估设计包括为 agent 和任务选择最合适的评分器。我们建议在可能的情况下选择确定性评分器，在必要或需要额外灵活性时选择 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，这是一个 SaaS 产品，扩展了 Phoenix 以支持规模化、优化和监控。

许多团队会组合使用多种工具、自建评估框架，或者只是从简单的评估脚本开始。我们发现，虽然框架是加速进展和实现标准化的宝贵方式，但它们的价值取决于你通过它们运行的评估任务。通常最好的做法是快速选择一个适合你工作流程的框架，然后通过迭代高质量的测试用例和评分器，将精力投入到评估本身。