获取开发者通讯
产品更新、操作指南、社区聚焦等更多内容。每月发送至您的收件箱。
良好的评估能帮助团队更有信心地交付 AI 智能体。没有评估，团队很容易陷入被动循环——只有在生产环境中才发现问题，而修复一个故障又会引发其他故障。评估能在问题影响用户之前使其可见，其价值在智能体的整个生命周期中不断累积。
正如我们在构建高效智能体中所述，智能体在多轮交互中运行：调用工具、修改状态，并根据中间结果进行调整。这些让 AI 智能体变得有用的能力——自主性、智能性和灵活性——同时也让它们更难被评估。
通过我们的内部工作以及与处于智能体开发前沿的客户合作，我们学会了如何为智能体设计更严谨、更有用的评估。以下是在实际部署中，跨多种智能体架构和用例行之有效的方法。
评估（“eval”）是对 AI 系统的测试：给 AI 一个输入，然后对其输出应用评分逻辑来衡量成功与否。在本文中，我们关注的是可在开发过程中运行、无需真实用户参与的自动化评估。
单轮评估很直接：一个提示、一个响应和评分逻辑。对于早期的 LLM，单轮、非智能体评估是主要的评估方法。随着 AI 能力的进步，多轮评估变得越来越普遍。
智能体评估则更为复杂。智能体在多轮交互中使用工具，修改环境中的状态并随之调整——这意味着错误可能传播和累积。前沿模型还能找到超越静态评估限制的创造性解决方案。例如，Opus 4.5 通过发现策略中的漏洞，解决了一个关于预订航班的 𝜏2-bench 问题。它按评估标准“失败”了，但实际上为用户想出了一个更好的解决方案。
在构建智能体评估时，我们使用以下定义：
当团队刚开始构建智能体时，通过手动测试、内部试用和直觉的组合，他们能取得令人惊讶的进展。更严谨的评估甚至可能看起来像是拖慢交付的开销。但在早期原型阶段之后，一旦智能体投入生产并开始扩展，没有评估的构建就开始崩溃。
临界点往往出现在用户反馈智能体在变更后感觉更差，而团队“盲目飞行”，除了猜测和检查之外无法验证。没有评估，调试是被动的：等待投诉、手动复现、修复错误，然后祈祷没有其他东西退化。团队无法区分真正的退化和噪声，无法在发布前自动针对数百个场景测试变更，也无法衡量改进。
我们已经多次见证了这一演进过程。例如，Claude Code 最初基于 Anthropic 员工和外部用户的反馈进行快速迭代。后来，我们加入了评估——先是针对简洁性和文件编辑等狭窄领域，然后是针对过度工程等更复杂的行为。这些评估有助于发现问题、指导改进，并聚焦研究-产品协作。结合生产监控、A/B 测试、用户研究等，评估为 Claude Code 在扩展过程中持续改进提供了信号。
在智能体生命周期的任何阶段，编写评估都是有用的。早期，评估迫使产品团队明确智能体成功的含义，而后期它们有助于维持一致的质量标准。
Descript 的智能体帮助用户编辑视频，因此他们围绕成功编辑工作流的三个维度构建了评估：不破坏东西、做我要求的事、做好它。他们从手动评分发展到由产品团队定义标准并由 LLM 评分器进行评分，并定期进行人工校准，现在定期运行两个独立的套件，用于质量基准测试和回归测试。Bolt AI 团队在已经有了广泛使用的智能体之后才开始构建评估。在 3 个月内，他们构建了一个评估系统，该系统运行其智能体并通过静态分析对输出进行评分，使用浏览器智能体测试应用，并采用 LLM 评判员评估指令遵循等行为。
有些团队在开发开始时创建评估；其他团队则在规模扩大后，当评估成为改进智能体的瓶颈时才添加。评估在智能体开发初期特别有用，可以明确编码预期行为。两名工程师阅读相同的初始规范，可能会对 AI 应如何处理边缘情况产生不同的解释。评估套件解决了这种模糊性。无论何时创建，评估都有助于加速开发。
评估还影响你采用新模型的速度。当更强大的模型出现时，没有评估的团队面临数周的测试，而拥有评估的竞争对手可以快速确定模型的优势，调整提示，并在几天内升级。
一旦有了评估，你就可以免费获得基线和回归测试：延迟、令牌使用、每任务成本和错误率可以在静态任务库上跟踪。评估还可以成为产品和研究团队之间最高带宽的沟通渠道，定义研究人员可以优化的指标。显然，评估除了跟踪回归和改进之外，还有广泛的好处。它们的复合价值很容易被忽视，因为成本是前期可见的，而收益是后期积累的。
我们今天看到几种常见类型的智能体已大规模部署，包括编码智能体、研究智能体、计算机使用智能体和对话智能体。每种类型可能部署在广泛的行业中，但可以使用类似的技术进行评估。你不需要从头发明评估。以下各节描述了针对几种智能体类型的经过验证的技术。将这些方法作为基础，然后扩展到你的领域。
智能体评估通常结合三种类型的评分器：基于代码的、基于模型的和人工的。每个评分器评估转录或结果的一部分。有效评估设计的一个基本组成部分是为工作选择合适的评分器。
基于代码的评分器
| 方法 | 优势 | 劣势 |
|---|---|---|
| • 字符串匹配检查（精确、正则、模糊等） • 二元测试（失败转通过、通过转通过） • 静态分析（lint、类型、安全） • 结果验证 • 工具调用验证（使用的工具、参数） • 对话记录分析（轮次、token 使用量） | • 快速 • 低成本 • 客观 • 可复现 • 易于调试 • 验证特定条件 | • 对不精确匹配预期模式的有效变体脆弱 • 缺乏细微差别 • 在评估某些更主观的任务时受限 |
基于模型的评分器
| 方法 | 优势 | 劣势 |
|---|
人工评分器
| 方法 | 优势 | 劣势 |
|---|
对于每个任务，评分可以是加权的（组合评分器分数必须达到阈值）、二元的（所有评分器必须通过）或混合的。
能力或“质量”评估问的是：“这个智能体擅长什么？”它们应该从低通过率开始，针对智能体难以处理的任务，给团队一个需要攀登的山坡。
回归评估问的是：“智能体是否仍然处理它过去能处理的所有任务？”并且应该具有接近 100% 的通过率。它们防止倒退，因为分数下降表明某些东西坏了，需要改进。当团队在能力评估上攀登时，同时运行回归评估也很重要，以确保更改不会在其他地方引起问题。
在智能体启动并优化后，高通过率的能力评估可以“毕业”成为持续运行的回归套件，以捕捉任何漂移。曾经衡量“我们到底能不能做到？”的任务，然后衡量“我们还能可靠地做到吗？”
编码智能体编写、测试和调试代码，像人类开发者一样浏览代码库并运行命令。现代编码智能体的有效评估通常依赖于明确指定的任务、稳定的测试环境以及对生成代码的彻底测试。
确定性评分器对编码智能体来说很自然，因为软件通常很容易评估：代码能运行吗？测试通过了吗？两个广泛使用的编码智能体基准测试，SWE-bench Verified 和 Terminal-Bench，遵循这种方法。SWE-bench Verified 给智能体来自流行 Python 仓库的 GitHub 问题，并通过运行测试套件来评分解决方案；只有当解决方案修复了失败的测试而不破坏现有测试时，它才通过。LLM 在这个评估上仅一年内就从 40% 进步到 >80%。Terminal-Bench 走了一条不同的路线：它测试端到端的技术任务，例如从源代码构建 Linux 内核或训练 ML 模型。
一旦你有一套用于验证编码任务关键结果的通过或失败测试，通常也很有用去评分对话记录*。*例如，基于启发式的代码质量规则可以根据通过测试之外的标准评估生成的代码，而具有明确评分标准的基于模型的评分器可以评估智能体如何调用工具或与用户交互等行为。
示例：编码智能体的理论评估
考虑一个编码任务，智能体必须修复一个认证绕过漏洞。如下面的示例 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
请注意，此示例展示了所有可用的评分器，仅用于说明。在实践中，编码评估通常依赖单元测试来验证正确性，并使用 LLM 评分标准来评估整体代码质量，仅在需要时添加额外的评分器和指标。
对话式智能体在支持、销售或辅导等领域与用户交互。与传统聊天机器人不同，它们维护状态、使用工具，并在对话中途采取行动。虽然编码和研究智能体也可能涉及与用户的多轮交互，但对话式智能体提出了一个独特的挑战：交互本身的质量就是你评估的一部分。有效的对话式智能体评估通常依赖于可验证的最终状态结果和评分标准，这些标准既涵盖任务完成情况，也涵盖交互质量。与大多数其他评估不同，它们通常需要第二个 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 元素属性。
浏览器使用代理需要在令牌效率和延迟之间取得平衡。基于 DOM 的交互执行迅速，但消耗大量令牌；而基于截图的交互速度较慢，但更节省令牌。例如，当要求 Claude 总结维基百科时，从 DOM 中提取文本更为高效。而在亚马逊上寻找新的笔记本电脑包时，截图更为高效（因为提取整个 DOM 会消耗大量令牌）。在我们的 Claude for Chrome 产品中，我们开发了评估来检查代理是否为每个上下文选择了正确的工具。这使我们能够更快、更准确地完成基于浏览器的任务。
无论代理类型如何，代理行为在不同运行之间会有所变化，这使得评估结果比初看起来更难解读。每个任务都有自己的成功率——可能一个任务的成功率为 90%，另一个为 50%——而一个在某个评估运行中通过的任务可能在下一个运行中失败。有时，我们想要衡量的是代理成功完成任务的频率（即成功试验的比例）。
两个指标有助于捕捉这种细微差别：
pass@k 衡量代理在
pass^k 衡量
这两个指标都有用，使用哪个取决于产品需求：对于一次成功就足够的工具，使用 pass@k；对于需要一致性的代理，使用 pass^k。
本节列出了我们从无评估到可信评估的实用、经过实地测试的建议。可以将其视为评估驱动代理开发的路线图：尽早定义成功，清晰地衡量它，并持续迭代。
步骤 0. 尽早开始
我们看到团队因为认为需要数百个任务而推迟构建评估。实际上，从真实失败中提取的 20-50 个简单任务就是一个很好的开始。毕竟，在代理开发的早期，系统的每次更改通常都有明显、显著的影响，而这种大的效应量意味着小样本量就足够了。更成熟的代理可能需要更大、更困难的评估来检测较小的效应，但最好在开始时采用 80/20 方法。等待的时间越长，构建评估就越困难。早期，产品需求自然转化为测试用例。等待太久，你就是在从实时系统中逆向工程成功标准。
步骤 1. 从你已经手动测试的内容开始
从你在开发过程中运行的手动检查开始——你在每次发布前验证的行为以及最终用户尝试的常见任务。如果你已经投入生产，请查看你的错误跟踪器和支持队列。将用户报告的失败转化为测试用例，确保你的测试套件反映实际使用情况；按用户影响确定优先级，有助于你将精力投入到关键之处。
步骤 2：编写带有参考解决方案的明确任务
确保任务质量比看起来更难。一个好的任务是两位领域专家能够独立得出相同的通过/失败结论的任务。他们自己能通过这个任务吗？如果不能，任务就需要改进。任务规范中的模糊性会成为指标中的噪声。基于模型的评分器的标准也是如此：模糊的评分标准会产生不一致的判断。
每个任务都应能被正确遵循指令的智能体通过。这一点可能很微妙。例如，对 Terminal-Bench 的审计发现，如果任务要求智能体编写脚本但未指定文件路径，而测试却假定脚本位于特定文件路径，智能体可能会在并非自身过错的情况下失败。评分器检查的所有内容都应在任务描述中清晰明了；智能体不应因规格模糊而失败。对于前沿模型而言，在多次试验中通过率为 0%（即 pass@100 为 0%）通常表明任务本身有问题，而非智能体能力不足，这也是需要仔细检查任务规格和评分器的信号。对于每个任务，创建一个参考解决方案很有用：一个已知能通过所有评分器的有效输出。这证明了任务可解，并验证了评分器配置正确。
步骤 3：构建平衡的问题集
既要测试行为应该发生的情况，也要测试不应该发生的情况。单方面的评估会导致单方面的优化。例如，如果只测试智能体在应该搜索时是否搜索，最终可能会得到一个几乎什么都搜索的智能体。尽量避免类别不平衡的评估。我们在为 Claude.ai 构建网络搜索评估时亲身学到了这一点。挑战在于防止模型在不该搜索时进行搜索，同时保留其在适当时候进行广泛研究的能力。团队构建了覆盖两个方向的评估：模型应该搜索的查询（如查找天气）和应该基于已有知识回答的查询（如“谁创立了苹果？”）。在触发不足（该搜索时不搜索）和触发过度（不该搜索时搜索）之间取得恰当平衡很困难，需要对提示词和评估进行多轮改进。随着更多示例问题的出现，我们持续添加评估以扩大覆盖范围。
步骤 4：构建具有稳定环境的稳健评估框架
评估中的智能体必须与生产环境中使用的智能体功能大致相同，且环境本身不应引入额外噪声。每次试验都应通过从干净环境开始来“隔离”。运行之间不必要的共享状态（残留文件、缓存数据、资源耗尽）可能导致因基础设施不稳定而非智能体性能引起的相关故障。共享状态也可能人为地抬高表现。例如，在一些内部评估中，我们观察到 Claude 通过检查之前试验的 git 历史，在某些任务上获得了不公平的优势。如果多个不同的试验因环境中的同一限制（如 CPU 内存有限）而失败，这些试验就不是独立的，因为它们受到同一因素的影响，评估结果在衡量智能体性能时就变得不可靠。
步骤 5：精心设计评分器
如上所述，优秀的评估设计涉及为智能体和任务选择最佳评分器。我们建议在可能的情况下选择确定性评分器，在必要时或为了额外灵活性选择 LLM 评分器，并审慎使用人工评分器进行额外验证。
人们有一种常见的本能，就是检查智能体是否遵循了非常具体的步骤，比如按正确顺序执行一系列工具调用。我们发现这种方法过于僵化，会导致测试极其脆弱，因为智能体经常会找到评估设计者未曾预料到的有效方法。为了不无谓地惩罚创造力，通常更好的做法是评估智能体产出了什么，而不是它走了哪条路径。
对于包含多个组成部分的任务，要设置部分得分。 一个正确识别了问题并验证了客户身份、但未能处理退款的客服智能体，明显优于一个一开始就失败的智能体。在结果中体现这种成功程度的连续性很重要。
模型评分通常需要仔细迭代才能验证其准确性。LLM 作为评判者的评分器应与人类专家密切校准，以确信人类评分与模型评分之间几乎没有分歧。为避免幻觉，要给 LLM 一条退路，比如提供一条指令，让它在信息不足时返回“Unknown”。创建清晰、结构化的评分标准来评估任务的每个维度，然后用一个独立的 LLM 作为评判者分别评估每个维度，而不是用一个 LLM 评判者评估所有维度，这也会有所帮助。一旦系统足够稳健，只需偶尔使用人工审核即可。
有些评估存在微妙的失败模式，即使智能体表现良好也会导致低分，因为智能体由于评分缺陷、智能体运行框架的限制或任务歧义而未能解决任务。即使是经验丰富的团队也可能忽略这些问题。例如，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 测试、人工对话记录审查以及系统性人工评估。
理解 AI 智能体表现的方法概览
| 方法 | 优点 | 缺点 |
|---|---|---|
| 自动化评估以编程方式运行测试，无需真实用户 | ||
| 生产监控跟踪线上系统中的指标和错误 | ||
| A/B 测试用真实用户流量比较不同版本 | ||
| 用户反馈如点踩或错误报告等显式信号 | ||
| 人工记录审查人工阅读智能体对话记录 | ||
| 系统性人工研究由训练有素的评分者对智能体输出进行结构化评分 |
这些方法对应智能体开发的不同阶段。自动化评估在发布前和 CI/CD 中特别有用，在每次智能体变更和模型升级时运行，作为质量问题的第一道防线。生产监控在发布后启动，以检测分布漂移和未预料到的现实世界故障。一旦有足够的流量，A/B 测试可验证重大变更。用户反馈和记录审查是持续进行的实践，以填补空白：不断分类反馈，每周抽样阅读记录，并根据需要深入挖掘。将系统性人工研究保留用于校准 LLM 评分器或评估主观输出，其中人类共识作为参考标准。
最有效的团队会结合这些方法：自动化评估用于快速迭代，生产监控用于获取真实情况，定期人工审查用于校准。
没有评估的团队会陷入被动循环——修复一个故障，又产生另一个，无法区分真正的回归和噪声。早期投入的团队则相反：随着故障变成测试用例，测试用例防止回归，指标取代猜测，开发加速。评估为整个团队提供了一个明确的目标，将“智能体感觉更差了”变成可操作的事项。价值会累积，但前提是你将评估视为核心组件，而非事后补充。
模式因智能体类型而异，但此处描述的基本原理是不变的。尽早开始，不要等待完美的测试套件。从你看到的故障中提取现实任务。定义明确、稳健的成功标准。精心设计评分器并组合多种类型。确保问题对模型来说足够困难。迭代评估以提高其信噪比。阅读记录！
AI 智能体评估仍是一个新兴且快速发展的领域。随着智能体承担更长的任务、在多智能体系统中协作，并处理日益主观的工作，我们将需要调整我们的技术。随着我们了解更多，我们会继续分享最佳实践。
由 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 共同开发评估实践的集体努力。
一些开源和商业框架可以帮助团队实施智能体评估，而无需从头构建基础设施。正确的选择取决于你的智能体类型、现有技术栈，以及你需要离线评估、生产可观测性，还是两者都需要。Harbor 专为在容器化环境中运行智能体而设计，提供跨云提供商大规模运行试验的基础设施，以及用于定义任务和评分器的标准化格式。像 Terminal-Bench 2.0 这样的流行基准测试通过 Harbor 注册表发布，使得运行既有基准测试和自定义评估套件变得容易。Braintrust 是一个将离线评估与生产可观测性和实验跟踪相结合的平台——对于需要在开发期间迭代并监控生产质量的团队很有用。其 autoevals 库包含用于事实性、相关性及其他常见维度的预构建评分器。LangSmith 提供追踪、离线和在线评估以及数据集管理，并与 LangChain 生态系统紧密集成。Langfuse 作为自托管的开源替代方案，为有数据驻留要求的团队提供类似能力。
Arize 提供 Phoenix，一个用于 LLM 追踪、调试以及离线或在线评估的开源平台，以及 AX，一个扩展 Phoenix 以实现规模化、优化和监控的 SaaS 产品。
许多团队结合使用多种工具，自建评估框架，或者仅使用简单的评估脚本作为起点。我们发现，虽然框架可以成为加速进展和标准化的宝贵方式，但其效果取决于你通过它们运行的评估任务。通常最好快速选择一个适合你工作流程的框架，然后通过迭代高质量的测试用例和评分器，将精力投入到评估本身。
产品更新、操作指南、社区聚焦等。每月发送到你的收件箱。