AI 智能体评估就绪清单

大多数构建 AI 智能体的团队犯了同一个错误：他们在理解失败是什么样子之前，就开始着手评估基础设施。他们构建仪表盘、选择指标、连接评估器——然后发现他们的评估完全测量错了东西。六周后，他们得到了一份绿色的记分卡，但智能体却是坏的。

解决方法不是更多的工具。它是一系列特定的步骤，在你自动化任何事情之前，将你的评估建立在现实基础之上。以下就是这些步骤。

在你接触评估基础设施之前

手动阅读 20-50 个真实的智能体轨迹。这是任何评估程序中最重要的一个步骤，也是最常被跳过的一个。

如果没有手动轨迹审查，你就是在盲目地构建评估。你不知道智能体是在推理、工具选择、参数构建还是更微妙的地方失败了——比如默默地假设了一个任务从未保证的前提条件。你无法为你尚未观察到的失败模式设计有用的评估器。

审查轨迹后，用明确的语言写下你的成功标准。“智能体应该正确完成任务”不是一个成功标准。“智能体使用有效参数调用正确的 API 端点，并且数据库的最终状态与预期模式匹配”才是。这种差异很重要，因为你的评估器需要精确地将这些标准操作化——如果标准模糊，评估器也会模糊。

在编写任何评估代码之前，还需要明确两件事：

• 将能力评估与回归评估分开。 能力评估回答“智能体到底能否完成 X？”回归评估回答“经过这次更改后，它是否仍能完成 X？”将它们混淆意味着你的回归测试套件将无限增长，而你的能力差距则会保持不可见。
• 指定单一负责人。 当评估由委员会负责时，其质量会下降。一名有权拒绝不良评估的领域专家，胜过五名工程师讨论评估标准设计。

最后，在指责模型之前，请验证你的基础设施。工具调用失败、环境重置和模拟数据不匹配常常伪装成推理失败。令人惊讶的是，很大一部分“智能体很笨”的 bug 实际上是“API 返回了意外错误”。

三个评估层次

智能体评估在三个粒度层次上进行。大多数团队应该从中层开始，然后向外扩展。

运行级别（单步）： 智能体是否选择了正确的工具？是否构建了有效的调用？这些是狭窄、有针对性的检查——运行成本低，对调试特定失败模式很有用。但它们只见树木不见森林。一个即使每个单独调用都正确的智能体，仍然可能未能完成任务。

轨迹级别（完整轮次）： 大部分评估工作都应该集中在这里。轨迹级别评估同时评估三个维度：

1. 最终响应的正确性 — 输出是否满足任务要求？
2. 轨迹的合理性 — 步骤序列是否合理？
3. 状态变化的验证 — 世界是否确实按预期方式改变了？

第三个维度至关重要，但却被广泛忽视。智能体经常报告成功的结果——电子邮件已发送、文件已创建、记录已更新——但这些结果实际上并未发生。验证状态变化意味着检查实际系统，而不是智能体对其的声称。

线程级别（多轮）： 评估跨对话的行为，包括错误恢复和内存。只有在轨迹级别评估扎实之后，才应在此投入。一个有用的技术是：N-1 测试，你取一个包含 N 轮的生产对话前缀，并在给定先前上下文的情况下，评估智能体在第 N 轮的行为。

构建你的数据集

评估数据集不是性能基准——它是一个行为规范。其中的每个示例都应该有一个明确的成功标准和一个评估器可以对照检查的参考解决方案。

质量始终胜过数量。 二十个具有严格成功标准的手动审查示例，胜过两百个通过提示另一个模型生成的合成示例。一旦你的评估框架校准完成，合成数据对于快速扩展很有用，但它绝不应该在初期替代基于事实的人工判断。

你的初始示例可以来自三个地方：

• 内部测试的失败 — 你的团队运行的真实任务中，智能体出错的案例
• 改编的外部基准 — TerminalBench、BFCL 及类似的任务套件，筛选出与你的部署环境匹配的任务
• 手写的行为测试 — 旨在探测特定能力和边缘情况的场景，包括负面案例（智能体不应表现出的行为）

根据你的智能体类型调整数据集构成。编码智能体受益于确定性测试套件，其中正确性是二元的。对话式智能体需要多维度评估标准，分别评估连贯性、有用性和事实性。研究型智能体需要扎实性检查，以根据原始材料验证其主张。

评估器设计

四种评估器类型涵盖了大多数评估需求：

类型	最佳用途
基于代码	确定性检查 — API调用结构、输出模式、状态验证
LLM作为评判者	基于评分标准的质量评估、开放式回复
人类	校准、边缘情况、评估器验证
成对比较	并排比较代理的两个版本

一些让评估器可靠的设计原则：

二元通过/失败优于数字评分。 5分中的3.7分是不可操作的，并且随着参考集的变化，数字评分会随着时间的推移引入校准漂移。二元判断强制清晰：究竟要满足什么条件才能通过？这个问题令人不适，但回答它能同时改进评估和代理。

在信任LLM评判者之前对其进行校准。 使用20–100个人工标注的例子来运行你的LLM评估器，并衡量一致性。没有校准，你就是在信任一个黑盒来评估另一个黑盒。分歧通常揭示的是评分标准含糊不清，而不是代理本身有问题。

评估结果，而非确切路径。 代理可以合理地通过不同路径达到相同结果。如果评估要求特定的工具调用序列，它将导致有效解决方案失败，并侵蚀对评估系统的信任。在可能的情况下，检查最终状态而非中间步骤。

分解为专业评估器。 一次性评估正确性、语气、效率和安全性的大型评估器是不可靠且难以调试的。为每个维度构建一个评估器并进行聚合。这使得识别是哪个维度导致了失败变得容易。

实际衡量可靠性的指标

非确定性代理的标准指标：

• Pass@k — k次独立尝试中至少有一次成功。乐观的；适用于能力评估。
• Pass^k — 所有k次独立尝试都成功。悲观的；适用于可靠性评估。

单次运行的基准测试本质上是嘈杂的。进行多次试验并报告分布情况，而非点估计。一个80%时间都能通过的代理与一个100%时间都能通过的代理有本质区别，但单次运行的评估无法区分它们。

除了正确性之外，还要跟踪运营指标：token使用量、延迟、对话轮次、每个任务的工具调用次数。效率比率——观察到的步骤除以理想步骤——揭示了那些成功但在此过程中浪费大量资源的代理。

错误分析作为核心实践

将你评估工作的60-80%用于错误分析，而不是构建更多评估。评估的目标是改进代理。从评估失败到代理改进的路径在于理解它为何失败。

结构化的错误分析过程：

1. 收集一组具有代表性的失败轨迹
2. 与领域专家一起审查它们，随之编码失败模式 — 无需预设类别
3. 聚类形成一个分类体系：提示设计问题、工具定义问题、模型局限性、环境故障、数据缺失
4. 迭代直到不再出现新类别

这个分类体系会告诉你需要修复什么。如果60%的失败是提示设计问题，那么解决方案是更好的提示，而不是更大的模型。如果失败集中在特定的工具定义上，那就重新设计这些工具。评估分数是一个滞后指标；错误分类体系才是领先信号。

一个关键区别：任务失败与评估失败。 当评估失败时，首先检查评估器本身是否出错。LLM评判者会犯错。评分标准有边缘情况。评估失败——即有效解决方案被错误地惩罚——很常见，并会损害对整个评估系统的信任。每个失败的轨迹都值得进行简短的人工检查，以确认评估器的裁决。

将评估与生产环境连接

评估不是一个预部署的关卡。它是一种持续的实践，在部署前、部署后以及系统运行期间都在后台进行。

离线评估（预部署）负责发布门控。在CI中对提示、工具或模型版本的每一次实质性更改运行它们。

在线评估（生产流量）捕获离线评估遗漏的退化——分布变化、数据集中不存在的边缘情况以及只在规模化时出现的紧急故障模式。

临时评估（探索性）用于响应用户报告或监控标记的异常，调查特定行为。

将成熟的代理系统与脆弱的系统区分开来的飞轮效应是：

1. 生产环境中的失败被捕获为轨迹
2. 轨迹被审查并添加到评估数据集
3. 在更新的数据集上运行新的评估
4. 改进在部署前得到验证
5. 成功的性能评估被提升到回归测试套件中
6. 循环重复

这个循环要求提示和工具定义与代码一起进行版本控制。如果你的提示保存在电子表格或维基中，你无法可靠地将评估变化归因于特定的修改。将提示视为软件制品。

就绪标准

在你从评估角度宣布代理已准备好投入生产之前，请验证：

• 20多个经过人工审查的轨迹，为你的成功标准提供依据
• 数据集中每个评估都有明确的通过/失败标准
• 包含正向和负向测试用例
• 每个基准进行多次试验（而非单次运行估计）
• LLM评判者已根据人工标签进行校准
• 基于真实失败构建的错误分类体系
• 离线评估已集成到CI中，并设有自动化质量门
• 在线评估基础设施已准备好处理生产流量
• 将生产失败反馈到数据集中的流程

这些项目都没有技术难度。挑战在于纪律——在发布压力将评估变成一个复选框而非一种实践之前，按正确的顺序完成它们。

在生产环境中表现稳定的代理，并非拥有最佳基准分数的代理。它们是由在编写第一个评估器之前就已理解其故障模式的团队所构建的代理。