Happy Path 是你的 Agent 评估测试过的唯一路径

看看大多数智能体（Agent）评测集是从哪里来的。有人构建了智能体，向团队演示，演示成功了，于是演示脚本就变成了评测套件。那些通过评审的案例，正是有人已经亲眼看到它们运行成功的案例。评测集在构建之初，几乎就是“快乐路径”（Happy path）的录音——即在截屏当天成功运行的那一段工具调用序列。

所以，当仪表盘显示智能体得分为 94% 时，它实际上是在说：它通过了我们能想象到的案例。它完全没有提及搜索 API 在多步计划中途返回 429 错误的情况，或者用户推翻了两轮前设定的约束的情况，亦或是检索结果为空，智能体必须在胡乱猜测和承认不知道之间做出选择的情况。这些情况并非没有通过你的评测。它们压根就没在评测里。

这就是黄金路径偏见（Golden-path bias），除非你刻意对抗，否则它就是智能体评测套件的默认形态。解决方法不是增加案例数量，而是增加不同种类的案例——这些案例应根据失败模式（Failure mode）来选择，从生产环境中收集，并针对刻意引入的故障进行压力测试。

为什么评测集会向演示脚本靠拢

这种偏见并非源于懒惰，而是评测编写过程中自带的“阻力最小路径”。

当你坐下来构思测试案例时，你会写下你能想象到的场景。你想象用户提出了一个清晰的问题，智能体调用了正确的工具，工具返回了干净的数据，智能体组织出了正确的答案。这是一个连贯的故事，所以很容易写下来。至于那种用户提问含糊不清、得到部分答案、重新调整表述，而智能体必须在三轮对话中跟踪这些更正的情况——这很难想象，所以就不会被写下来。

生产数据也有同样的偏差，但原因不同。历史对话记录偏向快乐路径，是因为体验糟糕的用户通常直接离开了。他们不会提交工单，也不会给对话评分。他们直接放弃，而那段追踪记录躺在你的日志里，看起来就像任何其他短会话一样。如果你均匀地对对话记录进行抽样，你就会过度抽样那些进行得顺利的交互，因为那些进行得糟糕的交互由于幸存者效应（Survivorship）而悄无声息地被低估了。

而且一旦评测套件存在，它就会僵化。它变成了回归测试的门槛。每一项改动都必须通过它，所以没有人愿意增加那些会导致绿色数字下降的难题。本该衡量质量的套件变成了一个你需要维护的东西。在生产中发现的新失败模式在提示词中得到了修补，却从未回到评测集中，因为加入它们会让分数看起来更难看。

结果就是，评测套件在一种特定条件下运行同一个工具序列数千次，并将其报告为覆盖率。

“通过”意味着“通过了我们想象中的案例”

对一份合格评测的诚实解读其实很窄。在黄金路径套件上 94% 的通过率告诉你，智能体擅长处理那些已经有人想到并写下来的情况。对于除此之外的一切，它都保持沉默。

这很重要，因为真实用户不会留在快乐路径上。他们会离题，会在对话中途改变话题，会自相矛盾。他们会粘贴格式错误的内容，一次问三个问题，并在中途放弃最初的目标。伯克利（Berkeley）的 MAST 多智能体失败分类法（Cemri et al., 2025）编录了 14 种不同的系统级失败模式——任务偏离、步骤间信息截留、过早终止——其中惊人数量的模式在单个干净请求的层面上是不可见的。它们只有在事情出错时才会出现。

“通过评测”与“在生产中运行良好”之间的差距，恰恰是评测从未涵盖的那组场景。你可以弥补这一差距，但不是通过更多次地运行快乐路径套件。在错误的分布上堆砌数量，只会得到一个更自信的错误答案。一个包含 500 个黄金路径案例的套件并不比 50 个更可靠——它只是以更多的代码位数测量了同样的盲点。

第一步是停止统计案例数量，转而统计失败模式。

覆盖率意味着失败模式，而非案例数量

重新审视这个问题。不要问“我们有多少个测试案例”，而要问“这个智能体有哪些失败方式，以及评测套件实际演练了其中哪些方式”。

将列表明确化。对于典型的使用工具的智能体，它包括以下内容：

• 工具错误 —— 工具返回了 429、500、超时或格式错误的负载，而不是干净的数据。
• 空结果 —— 检索或搜索返回空结果，智能体必须在推诿、询问澄清问题或产生幻觉之间做出选择。
• 矛盾 —— 用户设定了一个约束，几轮之后又设定了一个不兼容的约束。
• 歧义 —— 请求确实存在多种解读，正确的做法是询问，而非猜测。
• 超出范围的请求 —— 用户要求的某些事情，智能体应该拒绝而非尝试。
• 多步偏离 —— 第三步失败了，智能体必须重新规划，而不是守着过时的计划蛮干。
• 长上下文漂移 —— 当对话变长后，早期给出的指令被忽略了。

加载中…