掌握AI代理评估的路线图

在AI代理的开发中，许多团队仍然沿用评估大语言模型的方法：运行几个任务，检查最终输出，然后假设一切正常。然而，这种方法往往忽略了最重要的失败点。模型可能选择了不合适的工具或生成了错误的工具参数，代理系统可能无法妥善处理工具失败或遵循了低效的行动序列。仅评估最终响应很难识别这些失败发生在哪里。

代理评估正是为了解决这一差距而设计的。它不只关注结果，而是检查完整的执行过程——代理如何推理、决策、使用工具以及随着任务展开而适应。这提供了更准确的可靠性、效率和整体性能图景，帮助团队在问题进入生产环境之前发现它们。

评估的第一步是理解为什么代理评估很重要。当代理失败时，本能的反应是将其视为提示问题：系统提示需要更清晰。但很多时候，失败是测量问题：评估没有设计来捕捉问题所在。AI代理在多个层上运行，这些层可能独立失败：推理层（由语言模型驱动）负责规划、任务分解和工具选择；行动层（由工具调用和外部系统响应驱动）负责执行。一个代理可以正确推理该做什么，然后调用正确的工具但参数格式错误。将代理评估视为单一的端到端准确率检查会遗漏这两个失败面。

有用的代理评估在两个范围内运行：组件级评估（单独测量推理质量和工具调用准确性）和端到端评估（测量任务完成和执行效率）。80%的任务完成率并不能告诉你20%的失败来自糟糕的规划、错误的工具选择、错误的参数还是工具基础设施故障。步骤级跟踪——记录每次工具调用、其参数、结果以及随后的模型决策的日志——是进行诊断所必需的。没有跟踪，调试生产故障就是猜测。

第二步是定义代理评估成功的标准。评估的好坏取决于其成功标准。一个格式良好的评估任务是两个领域专家独立工作也能得出相同通过/失败判定。从明确的规格说明和参考解决方案开始——已知正确的输出能通过所有评分器。它们证明任务可解决，并验证评分逻辑配置正确。在评分运行之前，你需要为评估定义以下内容：任务（代理接收的输入、预期行为和环境状态）、成功标准（不仅是最终答案，还有中间结果：是否调用了正确的工具？状态是否正确更新？响应是否基于检索的上下文？）、以及负例（单侧评估导致单侧优化。平衡的数据集——涵盖行为应该发生和不应该发生的情况——防止代理对某项能力过度触发或触发不足）。从实际使用中的失败中提炼的一组良好规格任务，比等待完美的数据集更好的起点。评估越晚构建就越困难。

第三步是使用基于代码的检查来评分代理的行动层。确定性评分器——无需模型参与评分的代码——是代理评估堆栈中最快、最便宜且最可重复的选项。对于行动层，它们应始终是起点：工具调用验证（代理是否按正确顺序调用了正确的工具）、参数验证（输入是否具有正确的类型、所需参数和有效值）、结果验证（环境是否处于预期状态）、以及记录分析（步数、令牌消耗和延迟）。这些通常快速、客观且易于调试，但脆弱。检查“confirmation_code”: “CONF-789”的评分器会错过以不同格式呈现相同数据的正确响应。

第四步是使用基于模型的评判来评分代理的推理和输出质量。某些代理评估维度难以用确定性检查——输出质量、语调、对检索上下文的忠实度、适当的同理心。对于这些，使用语言模型作为评判（LLM-as-a-Judge）是合适的工具：灵活且能处理开放式输出，但会引入非确定性和校准漂移。以下实践可保持基于模型的评分器可靠：编写结构化评估标准（“评估响应是否有帮助”会产生噪声，而指定响应必须回答用户问题、基于检索上下文、避免超出范围建议的评估标准会产生信号。对每个维度进行独立判断）、定期对照人类判断进行校准（在分歧出现时，评估标准几乎总是问题所在。给评分器一个明确的“无法确定”选项，避免强制判断模糊情况）、对多组件任务构建部分学分（一个能正确识别问题并验证客户但未能处理退款的客服代理，比第一步就失败的代理有意义得多。二元通过/失败掩盖了代理实际崩溃的地方）。

第五步是将评估策略与代理类型相匹配。编码代理编写、测试和调试代码。软件在很大程度上是确定性的：代码运行吗？测试通过吗？修复是否在不破坏现有功能的情况下关闭了问题？基准如SWE-bench Verified和Terminal-Bench遵循这种通过/失败方法，并辅以基于评估标准的质量检查（安全性、可读性、边界情况处理）。对话代理在支持、销售和辅导工作流中与用户交互。交互质量本身也是评估的一部分——不仅工单是否解决，还包括语调是否合适以及解决是否清晰解释。这需要第二个语言模型模拟用户；τ-bench正是模拟了这一点，其评分器评估任务完成和交互质量。研究代理收集和综合跨来源的信息。基于性检查验证声明是否由检索来源支持，覆盖范围检查定义好答案必须包含的内容，来源质量检查确认代理咨询了权威材料。

第六步是处理代理评估结果中的非确定性。代理行为因运行而异；相同任务、相同输入、相同代理可能产生不同的工具选择、推理路径和结果。单次试验评估因此可能误导，因为它隐藏了简单准确率指标无法捕捉的变异性。这是由于代理系统非确定性的直接后果。随机模型输出、工具延迟、部分失败和自适应决策都引入了运行间的变异性。因此，评估代理需要对结果分布进行推理，而不是单一执行轨迹。常见的指标包括pass@k（至少一次成功）和pass^k（所有尝试都成功）。例如，单次成功率75%的代理在三次尝试中全部成功的概率仅为42%，显示了可靠性在重复运行中的快速下降。选择这些指标最终是产品决策而非纯粹技术决策。

第七步是区分能力评估和回归测试套件。能力评估旨在回答前瞻性问题：这个代理能做之前不能做的事吗？因此，它们应从相对较低的通过率开始，专注于系统仍有挑战性的任务。当能力评估达到非常高的分数（例如90%）时，它通常不再测量能力，而只是确认已解决问题上的可靠性。回归评估则不同：它们问的是代理是否仍能执行之前能做的所有事情。这些测试应接近100%运行，作为防止性能退化的保障。任何有意义的分数下降都是某物损坏的信号，应在发布前调查。随着时间的推移，能力评估自然变得更容易。通过率上升且性能稳定后，这些任务可以升级到回归套件。但一旦套件完全饱和，它对真正改进的敏感性就会降低——意味着有意义的进步可能作为噪声出现。因此，应在现有套件饱和之前引入新的、更具挑战性的评估，而不是之后。

第八步是将代理评估扩展到生产监控。开发评估捕捉你预期会失败的东西；生产揭示实际失败的东西。真实用户引入输入、边界情况和上下文在合成测试套件中很少出现，使生产监控成为评估的必要延伸。一个完整的评估系统结合多种互补信号：自动化评估（每次提交运行，覆盖已知失败模式，但可能产生虚假信心）、生产监控（跟踪延迟、错误率、工具失败和令牌使用，但通常在发生后才发现）、用户反馈（突出显示代理指标正确但用户意图失败的情况，稀疏但高度信息丰富）、以及手动记录审查（提供对推理、工具使用和决策路径的定性洞察，帮助验证自动评分器是否测量了正确行为）。这些层共同形成更完整的代理性能视图。