评估 AI Agent：为什么只看结果会误导你

你构建的一个智能体在最终输出评估中获得了 82% 的分数。你发布了它。两周后，你的支持队列里塞满了用户的投诉，抱怨智能体获取了错误的数据，使用了错误的参数调用 API，并且在错误的中期工作基础上生成了听起来很自信的回复。你回头查看追踪记录（traces）—— 发现智能体在 40% 的查询中路由都是错误的。最终输出评估从未捕捉到这一点，因为智能体往往还是误打误撞地得到了正确答案。

这是智能体评估中的核心陷阱：仅衡量最后输出的结果，无法告诉你智能体是如何到达那里的，而“到达那里”的过程正是大多数失败发生的地方。

为什么智能体评估在结构上有所不同

评估标准的 LLM 调用相对直接。你给它输入，它产生输出，你给输出评分。非确定性虽然令人讨厌，但并不是根本性的障碍。

智能体同时在多个维度上打破了这种模式。一个执行研究任务的智能体可能需要 12 个步骤：检索上下文、决定下一步搜索什么、合成部分结果、调用外部 API，并在工具返回意外结果时循环返回。每一步都是一个决策点。第 3 步的一个错误转向可能会在第 4 步到第 12 步中产生静默的级联反应，但最终仍然产生一个看起来合理的输出。

传统的软件测试假设行为是确定性的。传统的机器学习（ML）评估假设输入-输出对是固定的。智能体系统同时打破了这两个假设。智能体的行为会根据工具返回的内容、它检索到的信息以及它决定采取的路径而变化 —— 而这些都是你事先没有指定的。

这产生了两个截然不同的评估问题。首先，你需要评估最终结果：智能体完成任务了吗？其次，你需要评估轨迹（trajectory）：它是否以正确的方式、使用正确的工具、在可接受的成本内且不违反任何政策的情况下完成了任务？纯粹的结果指标会让那些运气好的智能体通过。纯粹的轨迹指标则会惩罚有效的替代方案。你需要两者结合，并根据风险大小给予不同的权重。

评分器光谱：将工具与问题匹配

并非所有的智能体行为都能以同样的方式进行评估，尝试对所有内容使用同一种评分器类型会导致评估结果要么太死板，要么太不一致而无法信任。

基于代码的评分器（Code-based graders） 是基石。它们评估二元条件：智能体是否调用了正确的工具？是否传递了必需的参数？数据库的最终状态是否反映了该操作？输出是否包含所需的字段？基于代码的评分器快速、廉价、确定且可调试。如果评分器判定失败，你确切地知道原因。它们的弱点在于脆弱性 —— 它们会惩罚有效的替代方案，并且难以处理任何需要解释的内容。

LLM 评委（LLM-as-judge graders） 覆盖了代码无法触及的领域：连贯性、客户互动中的同理心、研究摘要是否真正回答了原始问题、生成的计划在逻辑上是否合理。它们很灵活并能捕捉细微差别，但它们自身也引入了非确定性。一个 LLM 评委在多次运行中可能会得出不一致的结论，在你信任它的评分之前，需要针对人类专家的判断进行仔细校准。带有明确维度标准的结构化评分标准（rubric）在表现上明显优于开放式的“这好吗？”之类的提示词。

人工评分器（Human graders） 仍然是处理高风险或真正模糊内容的金标准。它们昂贵且缓慢，但它们是校准另外两种评分器的唯一方法。如果没有定期对智能体追踪记录进行人工复核，你就无法知道你的自动评分器是否真的在衡量你认为它们在衡量的内容。来自大规模构建这些系统的从业者的经验法则是：在有人真正深入研究过样本记录之前，永远不要对评估分数听之任之。

一个实用的评估系统会将这三者分层。使用基于代码的评分器作为第一道防线 —— 快速、便宜，并能捕捉明显的失败。使用 LLM 评委处理主观质量维度。定期引入人工复核来校准并捕捉系统性的盲点。这些层级相互补偿弱点，就像重叠的安全控制措施一样。

为“过程”评分，而不只是“结果”

智能体评估思维中最重要的转变是从仅关注结果的评分转向轨迹评分。可以这样想：当你评估一个学生的考试时，你想看到他们的解题过程，而不仅仅是最终答案。答案是“42”可能是正确的，也可能是一个幸运的猜想；过程能告诉你到底是哪一种。

一份记录（也称为追踪，trace）是智能体所做操作的完整记录：每一次工具调用、每一个中间结果、每一个推理步骤、每一个决策点。评估轨迹意味着询问：智能体是否在正确的时间调用了正确的工具？当工具返回意外结果时，它是否优雅地处理了错误？它是否使用了最少的步骤，还是在冗余的检索上浪费了 token？它在整个过程中是否保持在政策边界内？

对于不同的智能体架构，轨迹评估的形式也不尽相同。路由智能体需要“路由准确性”（RouteAccuracy）评分器 —— 它是否将查询发送到了正确的下游处理程序？提示词链管道需要“分步准确性”（StepByStepAccuracy）评分器 —— 链条中的哪个阶段失败了？编排器-执行器（orchestrator-worker）系统需要“子任务覆盖率”（SubtaskCoverage）评分器 —— 编排器是否完全分解了任务，以及每个执行器的输出是否得到了妥善合成？

僵化的轨迹评分有其自身的失效模式：当智能体采取一条有效的替代路径达到正确结果时，会对智能体进行惩罚。如果基于规则的轨迹评估拒绝了与测试集中的“黄金轨迹”不同的有效轨迹，它就会持续低估成功率。解决方法是在轨迹级别对结果进行评分 —— 验证关键检查点是否被触发以及最终状态是否正确 —— 而不是要求完全复刻参考追踪记录的每一个步骤。

处理非确定性：pass@k vs pass^k

当你运行两次同一个 agent 任务时，可能会得到两个不同的结果。这不是 bug —— 这是概率系统的基本属性。但这使得评估比在确定性软件中更难。

两种指标处理这种情况的方式不同，目的也不同。

pass@k 衡量 k 次尝试中至少有一次成功的概率。如果你运行 agent 三次，只要有任何一次尝试成功，它就通过了。这适用于能力评估 —— 你在问“这个 agent 到底能不能做到这件事？”在 75% 的单次尝试成功率下，90% 的 pass@3 成功率告诉你该能力是存在的。

pass^k 衡量所有 k 次尝试都成功的概率。这是一个可靠性指标，而且它的要求要苛刻得多。同样是 75% 的单次尝试成功率，pass^3 仅为 42%。如果你的 agent 运行在生产环境中，每次用户交互只有一次机会，那么 pass^k 才是关键。一个在 25% 的时间内都会失败的 agent 对于高风险工作流是不可接受的，即使它“通常”能正常工作。

大多数评估基础设施默认进行单次尝试运行。这会产生乐观的数据，无法反映生产环境的可靠性。对于任何注重一致性的场景 —— 自动化工作流、高风险决策、面向用户的交互 —— 请为每个任务运行多次尝试，并明确报告这两个指标。

构建可扩展的评估系统

评估系统本身需要像生产基础设施一样进行设计，而不是事后才考虑。

从 20-50 个取自真实失败案例的任务开始。 不要根据你认为会失败的情况从第一性原理出发设计评估。看看生产日志、用户反馈和手动测试中实际发生了什么失败 —— 并围绕这些场景构建任务。早期基于真实失败构建的评估比对假设性边缘情况的全面覆盖具有更高的信号价值。

编写明确的任务规范。 如果两个领域专家在独立工作的情况下，对 agent 是否通过任务得出了不同的结论，那么这个任务规范就是糟糕的。包含证明任务可解的参考方案。如果你自己都无法解决它，你就无法可靠地评判 agent 是否解决了它。

区分你的离线和在线评估策略。 离线评估（在开发期间针对精选数据集运行）可以在部署前捕获回归，并让你系统地比较 agent 版本。在线评估（在生产环境中异步对真实用户交互进行评分）揭示了真实的用户行为和现实世界输入的分布，而这些输入永远不会与你的测试集完美匹配。两者都是必要的。大约 52% 的团队运行离线评估；只有 37% 的团队使用在线评估监控生产环境。这个差距正是隐性回归滋生的地方。

对输出和结果评分，而不是路径。 规定正确的结果是什么样的，而不是确切的实现路径。如果一个评估因为 agent 检索文档的顺序与黄金轨迹（golden trace）不同而判定其失败，那么这个评估就衡量错了东西。一个检查最终数据库状态是否反映了正确交易的评估，衡量的才是正确的东西。

监控饱和度。 当一个评估套件达到 100% 的通过率时，它就不再提供信号了。你衡量的是 agent 已经解决的问题，而不是它挣扎的地方。更新该套件，或者将其转为回归测试套件，并构建针对下一个性能水平的新能力评估。

扼杀评估项目的陷阱

在从业者构建、运行一段时间后最终不再信任的评估系统中，有几种失败模式会重复出现。

模糊的任务规范 是最常见的。当规范说明不足时，agent 会在它本应通过的任务上失败 —— 问题不在于 agent，而在于测试。团队会失去对评估套件的信任并停止使用它。

非预期绕过 发生在 agent 找到了在不真正解决问题的情况下满足评分器的方法时。一个学会生成在模式上匹配“正确”输出、却没做底层工作的 agent 在生产环境中是毫无价值的。评分器需要检查实际结果，而不是输出的表面特征。

过度规范 会惩罚有效的替代方案。如果你的评分器检查特定的工具调用序列，而 agent 通过不同的序列正确解决了问题，你就会得到一个虚假的失败。这在团队将单元测试习惯移植到 agent 评估中时尤为常见 —— 断言确切行为的冲动对于确定性代码是有意义的，但在概率系统中会产生积极的误导。

评分 bug 非常普遍且会系统性地扭曲结果。当正确答案是 "96.124991" 时，一个判定 "96.12" 失败的评分器产生的是噪音而非信号。浮点数比较、空格敏感性和顺序假设是常见的罪魁祸首。阅读失败的运行记录。如果失败看起来不公平，那么问题出在评分器上。

评估项目在组织层面的成败因素

仅有技术上的合理性是不够的。那些确实能随着时间推移改进 agent 的评估项目共享一些组织属性。

所有权（Ownership）是明确的。有人负责评估套件 —— 维护任务、校准评分器、增加新能力的覆盖范围、移除饱和的评估。没有所有者的评估套件会退化。任务会过时。评分器的校准会发生漂移。套件继续运行并产生数字，但这些数字已不再具有原来的意义。

领域专家贡献任务。理解 agent 在上下文中应该做什么的工程师，比理解评估工具的基础设施工程师能写出更好的评估任务。最好的项目将贡献评估视为产品和领域团队的职责，基础设施团队则提供脚手架。

拥有强大评估基础设施的团队采用模型升级的速度明显更快 —— 几天而不是几周 —— 因为他们可以验证新模型不会导致现有行为的回归。评估套件是将研究能力转化为生产信心的机制。没有它，每一次改动都是一场猜测。

评估不是你在交付前完成的一个阶段。它是一个持续的反馈机制，告诉你三个月前部署的 agent 是否仍像部署时那样运行。真实的用户行为、新的边缘情况和模型漂移都会改变 agent 的表现，而这些是任何部署前测试都无法完全预见的。能够持续工作的 agent，是那些拥有时刻关注评估的所有者的 agent。