解密AI Agent的评估

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

正如我们在《构建有效 agent》中所述，agent 在多个回合中运作：调用工具、修改状态、并根据中间结果进行调整。正是这些使 AI agent 有用的能力——自主性、智能性和灵活性——也让它们更难被评估。

通过内部工作以及与处于 agent 开发前沿的客户合作，我们学会了如何为 agent 设计更严谨、更有用的评估。以下是在实际部署中，针对一系列 agent 架构和用例行之有效的方法。

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

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

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

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

当团队刚开始构建 agent 时，通过手动测试、内部试用和直觉的结合，他们可以取得令人惊讶的进展。更严谨的评估甚至可能看起来像是拖慢交付速度的额外负担。但在早期原型阶段之后，一旦 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 应如何处理边缘情况产生不同的理解。一个评估套件可以解决这种歧义。无论何时创建，评估都有助于加速开发。

评估还会影响你采用新模型的速度。当更强大的模型问世时，没有评估的团队将面临数周的测试，而拥有评估的竞争对手可以快速确定模型的优势、调整 prompt，并在几天内完成升级。

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

我们观察到目前大规模部署的几种常见 agent 类型，包括编码 agent、研究 agent、计算机使用 agent 和对话 agent。每种类型可能部署在各种各样的行业中，但可以使用类似的技术进行评估。你不需要从头发明一种评估方法。以下部分描述了针对几种 agent 类型的行之有效的技术。将这些方法作为基础，然后扩展到你的领域。

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

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

能力或“质量”评估问的是：“这个 agent 能做好什么？”它们应该从较低的通过率开始，针对 agent 难以处理的任务，给团队一个攀登的目标。

回归评估问的是：“agent 是否仍然能处理它过去能处理的所有任务？”并且应该具有接近 100% 的通过率。它们可以防止性能倒退，因为分数的下降表明某些东西出了问题需要改进。当团队在能力评估上攀登时，同时运行回归评估以确保变更不会在其他地方引起问题也很重要。

在 agent 启动并优化后，具有高通过率的能力评估可以“毕业”成为回归套件，持续运行以捕捉任何漂移。曾经衡量“我们到底能不能做到？”的任务，现在则衡量“我们还能可靠地做到吗？”。

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

确定性评分器对于编码 agent 来说很自然，因为软件通常很容易评估：代码能运行吗？测试能通过吗？两个广泛使用的编码 agent 基准测试，SWE-bench Verified 和 Terminal-Bench，都遵循这种方法。SWE-bench Verified 向 agent 提供来自流行 Python 仓库的 GitHub issue，并通过运行测试套件来评分解决方案；一个解决方案只有在修复了失败的测试且不破坏现有测试的情况下才算通过。LLM 在这一评估上的得分在短短一年内从 40% 提升到了 80% 以上。Terminal-Bench 则采取了不同的路线：它测试端到端的技术任务，例如从源代码构建 Linux 内核或训练 ML 模型。

一旦你有一套通过/失败测试来验证编码任务的关键结果，通常也很有用对对话记录进行评分。例如，基于启发式的代码质量规则可以基于不仅仅是测试通过来评估生成的代码，而带有清晰评分标准的基于模型的评分器可以评估 agent 如何调用工具或与用户交互等行为。

示例：编码 agent 的理论评估

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

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

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

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

示例：对话 agent 的理论评估

考虑一个支持任务，agent 必须处理一位沮丧客户的退款请求。

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

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

研究评估面临独特的挑战：专家可能对综合是否全面存在分歧，随着参考内容不断变化，事实真相也在变化，而更长、更开放式的输出为错误创造了更多空间。例如，像 BrowseComp 这样的基准测试，测试 AI agent 是否能在开放的互联网上找到“大海捞针”——这些问题设计成易于验证但难以解决。

构建研究 agent 评估的一种策略是结合评分器类型。基础性检查验证声明是否得到检索来源的支持，覆盖范围检查定义了一个好的答案必须包含的关键事实，来源质量检查确认所咨询的来源是权威的，而不仅仅是首先检索到的。对于有客观正确答案的任务（“X 公司第三季度收入是多少？”），精确匹配有效。LLM 可以标记无支持的声明和覆盖范围的空白，同时也可以验证开放式综合的连贯性和完整性。

鉴于研究质量的主观性，基于 LLM 的评分标准应经常根据专家人工判断进行校准，以有效评估这些 agent。

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

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

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

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

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

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

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

本节列出了我们实用、经过现场验证的建议，帮助你从没有评估到拥有可以信赖的评估。将其视为评估驱动的 agent 开发路线图：尽早定义成功，清晰衡量，并持续迭代。

第 0 步：尽早开始

我们看到团队因为认为需要数百个任务而推迟构建评估。实际上，从真实失败中提取的 20-50 个简单任务就是一个很好的开始。毕竟，在早期的 agent 开发中，对系统的每次更改通常都会产生清晰、明显的影响，这种大的效应量意味着小样本量就足够了。更成熟的 agent 可能需要更大、更难的评估来检测较小的效应，但最好在开始时采用 80/20 的方法。你等待的时间越长，评估就越难构建。早期，产品需求自然转化为测试用例。等待太久，你就需要从实时系统中逆向工程出成功标准。

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

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

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

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

每个任务都应该能被正确遵循指令的 agent 通过。这可能很微妙。例如，审计 Terminal-Bench 发现，如果一个任务要求 agent 编写一个脚本但没有指定文件路径，而测试假设脚本有一个特定的文件路径，那么 agent 可能会因非自身原因而失败。评分器检查的所有内容都应在任务描述中明确说明；agent 不应因模糊的规范而失败。对于前沿模型，多次试验中 0% 的通过率（即 0% pass@100）通常表明任务有问题，而不是 agent 能力不足，并且是重新检查任务规范和评分器的信号。对于每个任务，创建一个参考解决方案很有用：一个已知有效的、能通过所有评分器的输出。这证明了任务是可解的，并验证了评分器配置正确。

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

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

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

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

第 5 步：精心设计评分器

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

有一种常见的直觉是检查 agent 是否遵循了非常具体的步骤，例如按正确顺序调用工具。我们发现这种方法过于僵化，会导致测试过于脆弱，因为 agent 经常会找到评估设计者未预料到的有效方法。因此，为了不无谓地惩罚创造性，通常最好评估 agent 产生的结果，而不是它采取的路径。

对于具有多个组件的任务，建立部分得分。一个正确识别问题并验证客户但未能处理退款的客服 agent，明显比一个立即失败的 agent 要好。在结果中体现这种成功的连续体很重要。

模型评分通常需要仔细迭代以验证准确性。LLM-as-judge 评分器应与人类专家密切校准，以确保人工评分和模型评分之间的差异很小。为了避免幻觉，给 LLM 一条出路，例如提供一条指令，当它没有足够信息时返回“未知”。创建清晰、结构化的评分标准来评估任务的每个维度，然后使用独立的 LLM-as-judge 来评估每个维度，而不是使用一个来评估所有维度，这也会有所帮助。一旦系统健壮，偶尔进行人工审查就足够了。

一些评估存在微妙的失败模式，即使 agent 性能良好也会导致低分，因为 agent 由于评分错误、agent 框架限制或歧义而无法解决任务。即使是经验丰富的团队也可能错过这些问题。例如，Opus 4.5 最初在 CORE-Bench 上得分为 42%，直到一位 Anthropic 研究员发现了多个问题：僵化的评分标准惩罚了“96.12”而期望的是“96.124991…”，模糊的任务规范，以及无法精确复现的随机任务。在修复错误并使用限制较少的框架后，Opus 4.5 的得分跃升至 95%。类似地，METR 在其时间范围基准测试中发现了一些配置错误的任务，这些任务要求 agent 优化到指定的得分阈值，但评分要求超过该阈值。这惩罚了像 Claude 这样遵循指令的模型，而忽略指定目标的模型获得了更好的分数。仔细仔细检查任务和评分器有助于避免这些问题。

让你的评分器能够抵抗绕过或黑客攻击。agent 不应该能够轻易地“欺骗”评估。任务和评分器的设计应确保通过确实需要解决问题，而不是利用意外的漏洞。

第 6 步：检查对话记录

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

失败应该看起来是公平的：清楚 agent 哪里错了以及为什么错。当分数不上升时，我们需要确信这是由于 agent 性能问题，而不是评估问题。阅读对话记录是你验证评估是否衡量了真正重要内容的方式，也是 agent 开发的一项关键技能。

第 7 步：监控能力评估饱和

100% 的评估可以跟踪回归，但不提供改进的信号。当 agent 通过了所有可解的任务，没有改进空间时，就会发生评估饱和。例如，SWE-bench Verified 的分数今年开始时为 30%，前沿模型现在接近饱和，达到 >80%。随着评估接近饱和，进展也会放缓，因为只剩下最困难的任务。这可能会使结果具有欺骗性，因为大的能力提升可能只表现为分数的小幅增长。例如，代码审查初创公司 Qodo 最初对 Opus 4.5 印象不深，因为他们的一次性编码评估没有捕捉到在更长、更复杂任务上的收益。作为回应，他们开发了一个新的 agent 评估框架，提供了更清晰的进展图景。

作为一条规则，我们不会在有人深入研究评估细节并阅读一些对话记录之前，就轻易相信评估分数。如果评分不公平、任务模糊、有效解决方案受到惩罚或框架限制了模型，则应修改评估。

第 8 步：通过开放贡献和维护，长期保持评估套件的健康

评估套件是一个活的工件，需要持续的关注和明确的所有权才能保持有用。

在 Anthropic，我们尝试了各种评估维护方法。最有效的是建立专门的评估团队来拥有核心基础设施，而领域专家和产品团队贡献大部分评估任务并自己运行评估。

对于 AI 产品团队来说，拥有并迭代评估应该像维护单元测试一样成为常规。团队可能会在 AI 功能上浪费数周时间，这些功能在早期测试中“有效”，但未能满足未明确说明的期望，而一个设计良好的评估本可以及早发现这些期望。定义评估任务是压力测试产品需求是否足够具体以开始构建的最佳方法之一。

我们建议实践评估驱动的开发：在 agent 能够满足计划能力之前构建评估来定义它们，然后迭代直到 agent 表现良好。在内部，我们经常构建今天“足够好”的功能，但这是对未来几个月模型能力的赌注。从低通过率开始的能力评估使这一点变得可见。当新模型发布时，运行套件会迅速揭示哪些赌注得到了回报。

最接近产品需求和用户的人最适合定义成功。凭借当前的模型能力，产品经理、客户成功经理或销售人员可以使用 Claude Code 以 PR 的形式贡献一个评估任务——让他们去做吧！或者，更好的是，积极赋能他们。

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

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

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

没有评估的团队会陷入被动循环——修复一个失败，又产生另一个，无法区分真正的性能退化与噪音。早期投资的团队会发现相反的情况：随着失败变成测试用例，测试用例防止回归，指标取代猜测，开发速度加快。评估为整个团队提供了一个清晰的攀登目标，将“agent 感觉更差了”变成了可操作的事情。价值会复合增长，但前提是你将评估视为核心组件，而不是事后想法。

模式因 agent 类型而异，但这里描述的基本原则是恒定的。尽早开始，不要等待完美的套件。从你看到的失败中获取现实的任务。定义明确、稳健的成功标准。精心设计评分器并组合多种类型。确保问题对模型来说足够困难。迭代评估以提高信噪比。阅读对话记录！

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

作者：Mikaela Grace, Jeremy Hadfield, Rodrigo Olivares, 和 Jiri De Jonghe。我们还要感谢 David Hershey, Gian Segato, Mike Merrill, Alex Shaw, Nicholas Carlini, Ethan Dixon, Pedram Navid, Jake Eaton, Alyssa Baum, Lina Tawfik, Karen Zhou, Alexander Bricken, Sam Kennedy, Robert Ying 等人的贡献。特别感谢我们通过评估合作学习到的客户和合作伙伴，包括 iGent, Cognition, Bolt, Sierra, Vals.ai, Macroscope, PromptLayer, Stripe, Shopify, Terminal Bench 团队等。这项工作反映了多个团队在 Anthropic 共同发展评估实践的集体努力。

有几个开源和商业框架可以帮助团队实现 agent 评估，而无需从头构建基础设施。正确的选择取决于你的 agent 类型、现有技术栈，以及你是否需要离线评估、生产可观测性，或两者兼而有之。Harbor 专为在容器化环境中运行 agent 而设计，提供跨云提供商大规模运行试验的基础设施，以及用于定义任务和评分器的标准化格式。流行的基准测试如 Terminal-Bench 2.0 通过 Harbor 注册表发布，使得运行既定基准测试和自定义评估套件变得容易。Braintrust 是一个将离线评估与生产可观测性和实验跟踪相结合的平台——对于需要在开发过程中迭代并在生产中监控质量的团队很有用。其 autoevals 库包含用于事实性、相关性和其他常见维度的预构建评分器。LangSmith 提供跟踪、离线和在线评估以及数据集管理，并与 LangChain 生态系统紧密集成。Langfuse 作为自托管开源替代方案，为有数据驻留要求的团队提供类似功能。

Arize 提供 Phoenix，一个用于 LLM 跟踪、调试以及离线或在线评估的开源平台，以及 AX，一个扩展 Phoenix 以实现规模化、优化和监控的 SaaS 产品。许多团队组合使用多种工具，构建自己的评估框架，或者仅使用简单的评估脚本作为起点。我们发现，虽然框架可以成为加速进展和标准化的宝贵方式，但它们的好坏取决于你通过它们运行的评估任务。通常最好快速选择一个适合你工作流程的框架，然后将精力投入到评估本身，通过迭代高质量的测试用例和评分器来实现。