Anthropic 详解 AI Agent 评测方法：从 grader 设计到落地路线图

引言

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

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

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

评估的结构

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

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

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

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

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

为什么要构建评估？

当团队刚开始构建代理时，他们通过手动测试、内部试用和直觉的组合，往往能取得出人意料的进展。更严格的评估甚至可能看起来像是拖慢交付的额外开销。但在早期原型阶段之后，一旦代理进入生产环境并开始规模化，没有评估的构建就会开始崩溃。

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

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

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

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

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

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

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

如何评估 AI agents

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

agent 的评分器类型

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

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

能力评估 vs. 回归评估

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

回归评估问的是：“这个 agent 还能处理它以前处理的所有任务吗？”并且应该有接近 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 总结 Wikipedia 时，从 DOM 中提取文本更高效。在 Amazon 上寻找新的笔记本电脑保护套时，截图更高效（因为提取整个 DOM 非常消耗 token）。在我们的 Claude for Chrome 产品中，我们开发了评估来检查智能体是否为每种情境选择了正确的工具。这使我们能够更快、更准确地完成基于浏览器的任务。

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

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

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

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

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

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

从零到一：为智能体打造优秀评估的路线图

本节阐述我们从无评估到建立可信评估的实用且经过实地检验的建议。可以把它看作评估驱动型智能体开发的路线图：尽早定义成功、清晰地衡量成功，并持续迭代。

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

第 0 步：尽早开始

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

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

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

第 2 步：编写带有参考解决方案的明确任务

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

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

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

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

设计评估框架和评分器

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

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

第 5 步：精心设计评分器

如上所述，出色的评估设计包括为智能体和任务选择最合适的评分器。我们建议在可能的情况下选择确定性评分器，在必要或需要额外灵活性时使用 LLM 评分器，并审慎使用人工评分器进行额外验证。

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

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

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

有些评估存在微妙的失败模式，即使 agent 表现良好也会导致低分，因为 agent 因评分 bug、agent harness 约束或歧义而未能解决任务。即使是成熟的团队也可能遗漏这些问题。例如，Opus 4.5 最初在 CORE-Bench 上得分 42%，直到一位 Anthropic 研究员发现了多个问题：僵化的评分在期望“96.124991…”时却对“96.12”扣分、任务规格含糊不清，以及无法精确复现的随机性任务。在修复 bug 并使用约束更少的 scaffold 后，Opus 4.5 的得分跃升至 95%。同样，METR 发现其时间跨度基准中有若干配置错误的任务，这些任务要求 agent 优化到某个声明的分数阈值，但评分却要求超过该阈值。这惩罚了像 Claude 这样遵循指令的模型，而忽略既定目标的模型反而获得了更好的分数。仔细复核任务和评分器有助于避免这些问题。

让你的评分器能够抵御绕过或作弊行为。agent 不应能轻易“欺骗”评估。任务和评分器的设计应确保通过评估真正需要解决问题，而不是利用意外的漏洞。

长期维护并使用评估

第 6 步：检查对话记录

除非你阅读大量试验的对话记录和评分，否则你不会知道评分器是否运作良好。在 Anthropic，我们投入建设了用于查看评估对话记录的工具，并定期花时间阅读它们。当任务失败时，对话记录会告诉你 agent 是犯了真正的错误，还是你的评分器拒绝了有效的解决方案。它还经常揭示关于 agent 和评估行为的关键细节。

失败应当看起来是公平的：清楚 agent 错在哪里以及为什么错。当分数不再攀升时，我们需要确信这是由于 agent 的表现而非评估本身。阅读对话记录是你验证评估是否在衡量真正重要之事的方式，也是 agent 开发的一项关键技能。

第 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 产品。

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