95% 可靠性幻觉：为什么你的 10 步 Agent 在 40% 的情况下会失败

在几乎每一个智能体（agent）项目评审中，都有一个会让谈话戛然而止的时刻。有人画了一张小图表：y 轴是端到端任务成功率，x 轴是工具使用的步骤数。曲线急剧下降。全场陷入沉默，因为屋子里的每个人之前都在争论提示词（prompt）、模型和检索策略——而这张图表在告诉大家，所有的这些争论，都抵不过一个简单的事实：这条链条上的环节太多了。

这一数学原理是可靠性工程中最古老的结论之一，如今被移植到了一个自以为是的新领域。如果流水线中的每一步都以概率 p 独立成功，那么 n 个串联步骤的成功概率就是 p 的 n 次方。代入一些在进度报告中听起来还不错的数字：单步可靠性 95%，十个步骤，端到端成功率就只有 60%。二十步降至 36%。三十步则降至 21%。那个“95% 的时间都能正常工作”的智能体，实际上在三分之一的真实用户请求中都会失败，因为真实的用户请求绝非只有单个步骤。

这就是 95% 可靠性幻觉。在单元测试中，每个环节看起来都毫无问题；但端到端的追踪（trace）却是一团糟。问题不在于提示词，而在于链条本身。

你在第一天就该算的账

这种复利效应既非新鲜事，也不微妙。分布式系统工程师在第一次将两个服务连接在一起时就深刻理解了这一点：对一个“五个九”可用性的后端进行两次 HTTP 调用，你的可靠性就只剩“四个九”了。假设调用次数达到 50 次——这在具备检索、规划、多工具使用和后处理能力的现代智能体中并不罕见——那么 1% 的单次调用失败率就会复合为大约 40% 的端到端失败率。这些数字之所以令人不安，正是因为单个组件的指标听起来非常靠谱。

智能体系统在两个方面让情况变得更糟，而这是分布式系统无需面对的。

第一，“成功”并不是布尔值。传统服务要么返回 200，要么不返回。而 LLM 调用返回的是一个可能存在细微错误的字符串：格式正确、语气到位，甚至表面上的事实也是对的，但却包含了一个虚构的标识符或排序错误的参数列表。下游步骤会像对待正确结果一样使用该字符串，规划器（planner）据此进行自信的推理，错误便以一种布尔可靠性计算无法捕获的形式在链条余下的部分中传播。实际的单步失败率比你的评测（evals）结果要高，因为你的评测给那些看起来不错的输出打了高分。

第二，错误是相关的。如果你的检索器（retriever）返回了一份陈旧的文档，那么后续引用该文档的每一步都会继承这种陈旧性。 “独立性”是数学为了便于计算而假设的一种虚构情况。现实中的智能体失败往往集中在糟糕的上下文窗口、模糊的用户输入以及规划器无法理解的工具目录上——这意味着实际的端到端分布是双峰的（bimodal）：大多数追踪是成功的，而失败的那些则在同一条追踪的多个步骤中接连失败。你不能通过假装每一步的失败都相互独立来弥补缺失的考量。

最近的衡量工作证实了从业者的猜想：在多次运行中表现一致的智能体准确率能达到 80–92%，而表现不一致的智能体则落在 25–60% 的区间内，且分歧很早就出现了——通常在第二步。路径长度本身就是一个可靠性信号。链条越长，轨迹分叉到评测集从未覆盖路径的机会就越多。

检查点的位置决定一切

一旦团队接受了某些步骤需要验证，下一个问题就是验证哪些步骤。验证每一步的代价是昂贵的——最近的测量显示，完全验证的工作流延迟成本高达未验证版本的 28.9 倍，资金成本高达 53.2 倍——而不验证任何步骤则会让你回到最初的问题。放置位置的选择属于架构设计，而非简单的调优开关。

以下是三种占主导地位的放置模式，它们适用于不同的失败模式：

• 当前置失败会产生连锁反应时，应优先进行前置验证。 如果第一步是“将用户意图解析为结构化任务”，而智能体的其余部分都基于该任务进行推理，那么这里的错误会污染后续的每一个步骤。在第十步才发现错误的代价，是丢弃九个步骤的工作量，再加上误导用户的成本。在输出结果影响范围（blast radius）最大的前端，设置一个强大的验证器——一个独立的模型调用、一个模式（schema）检查，或者一次向用户的澄清询问。

• 当失败可以在事后检测到时，应采用后置验证。 如果智能体正在撰写邮件、生成代码或生成数据库查询，那么最终产物就是自然的验证表面：对其进行 lint 检查、试运行、类型检查，或者发送给评论模型（critic model）。中间步骤噪声更多，且难以单独评分。将验证预算花在即将提交的输出上，比花在规划追踪上能捕获更多真实的错误。

• 在影响范围最大的步骤进行中置验证。 某些步骤既不是第一步也不是最后一步，但它们会不可逆地触碰外部状态：发送邮件的工具调用、扣款的 API 调用、更新客户记录的写入操作。这些步骤值得进行与其出错危害成正比的检查，而非与其在链条中的位置成正比。在执行任何有副作用的工具调用之前，询问“这是用户真正要求的操作吗”的验证器，是智能体所能拥有的最高杠杆检查之一。

做得好的团队很少会对每一步都运行统一的验证。他们查看追踪数据，识别出故障实际起源或造成实际伤害的两个或三个关键步骤，并将验证预算集中在那里。而做得不好的团队要么验证一切（结果交付了成本飙升 28 倍的产品），要么什么都不验证（结果交付了 40% 的失败率）。

改变曲线的冗余模式

验证是在错误发生后捕捉它们。冗余则是在一开始就降低错误发生的频率。两者并非替代关系，而是互补关系——在智能体（agent）系统中奏效的冗余模式，大多是从其他可靠性学科引入的，而智能体相关的文献正重新发现这些模式。

并行采样与多数投票（Parallel sampling with majority vote）。 以非零温度（non-zero temperature）运行相同步骤三次，取最常见的答案。对于具有离散答案的任务（例如：属于哪一类、调用哪个工具、选择哪个分支），这种方法可以消除许多因采样噪声而非能力差距导致的单步失败。其正式名称为“自我一致性（Self-consistency）”；它对多步推理的实证提升已有详尽记录，且往往超过模型升级带来的收益。

在高杠杆步骤设置验证者智能体。 使用第二个模型（通常是一个较小的模型）根据明确的准则对主智能体的输出进行评分。验证者不需要比生成器更聪明；它只需要足够“不同”，使两者的失败模式不会完全相关。验证者的分步评估在错误检测方面的表现比端到端（end-of-chain）整体评分高出多达 15% 的相对 AUC-ROC，因为在第三步发现错误比在第十步发现错误后的恢复成本更低。

链条内部的自我一致性探测。 定期要求智能体重述其对当前任务的理解，然后与原始简报进行对比。两者之间的偏差是一个领先指标，表明链条在产生明显错误输出之前就已经偏离了轨道。这是智能体版本的“心跳（heartbeat）”机制：单次探测成本低、频率高、信息量小，但当发散最终出现时，其价值极高。

恢复分支，而非重试。 如果只是简单地在相同上下文中重新运行失败步骤的“天真重试循环”，通常会产生相同的错误答案，因为模型是无状态的，且输入没有改变。有效的恢复意味着改变某些变量——重新构思提示词（prompt）、询问澄清问题、回滚到先前的检查点，或者升级到更强大的模型。没有任何改变的“失败后重试”与其说是干预，不如说是空操作（no-op）。

这些模式并不罕见。它们在生产环境中出现得参差不齐，是因为每增加一个模式都会增加延迟和成本，且需要团队预先决定哪些步骤值得投入预算。那些在关键杠杆步骤中加入冗余（且仅在这些步骤中加入）的团队，其表现优于那些盲目在所有地方加入冗余或完全忽略冗余的团队。

成本-可靠性边界

增加更多的检查并非免费，且曲线会迅速变平。在噪声较大的步骤中增加第一个验证者通常能将端到端成功率提高 10 到 20 个百分点；在同一步骤增加第三个验证者可能只增加 0.5 个百分点。第 11 次检查的成本可能超过了它所防止的失败损失。成本-可靠性边界是真实存在的，它的形态与任何其他工程权衡（tradeoff）一样。

诚实的做法是计算失败的预期成本（退款、负面公关、手动清理、流失）以及增加一次额外检查的边际成本，并在后者超过前者时停止增加检查。大多数团队从未进行过这种明确的计算。他们不断增加验证，因为在单次智能体运行的延迟预算超过 5 秒、产品团队开始质疑为什么助手感觉很慢之前，每一次新的检查看起来都是审慎的。

在缺乏完整成本模型的情况下，有两个启发式方法（heuristics）会有所帮助。首先，优先验证那些在变得“昂贵”之前处于“不可见”状态的步骤失败。例如，CRM 更新中错误的工具调用在客户三周后发现错误记录之前是无声的——即使错误写入的金钱成本很小，该步骤也值得验证，因为发现延迟放大了成本。其次，验证那些恢复成本低廉的步骤，并跳过那些无论如何恢复成本都很高昂的步骤。如果捕捉到错误意味着必须重做整个链条，那么验证者能带给你的价值微乎其微。

随着模型能力的提高，边界会发生移动。去年需要“三选二”多数投票的步骤，今年可能完全不需要了，因为单步可靠性本身已足够高。每当底层模型更换时，都应重新评估可靠性预算，但大多数团队并没有这样做——他们保留了一年前的验证支架，并为此支付永久的代价。

有人终于把图画出来的架构评审

在实践中最有效的干预措施往往是最简单的。抽取样本查看最近的智能体追踪记录（traces）。对于每条记录，统计两个数字：经历了多少次工具调用步骤，以及最终是否成功。画出成功率随步骤数变化的曲线。曲线不会是平的。根据智能体的不同，在 5 到 15 个步骤之间，曲线会急剧下降。

图表展示后的讨论才是真正可靠性工作的开始。三个问题往往能带来最大的改变。

这条链条能否更短？ 大多数智能体设计之所以会累积步骤，是因为每增加一个新功能就增加了一个新工具，而规划器（planner）现在必须按顺序遍历所有工具。删除工具、合并步骤或让一个工具完成两个工具的工作，是目前影响最大的可靠性干预手段。一个单步可靠率为 95% 的 12 步链条，其最终成功率仅为 54%；而同样可靠率的 8 步链条成功率则为 66%。没有任何验证或模型升级能像删除 4 个步骤那样为你带来 12 个百分点的提升。

哪一步的失败造成的伤害最大？ 在失败的记录中，哪一步最常是出错的源头？将验证、冗余和提示词优化集中在该步骤上，通常比将同样的精力分散到整个链条中更能提升端到端的数据。

我们愿意承诺的底线是多少？ 假装智能体的成功率是 95% 比承认它是 60% 更危险。产品界面、支持流程、客户预期和回滚路径都需要根据真实数字进行设计。在内部发布乐观的单步可靠性指标的团队，最终会被支持请求量吓到；而发布诚实的端到端数字的团队，最终会构建出正确的安全网。

可靠的智能体究竟是什么样的

那些在生产环境中经得起考验的智能体，并非拥有最巧妙提示词或最大模型的那些。相反，它们是在仍能完成有用工作的前提下链路最短的智能体，是在确实容易出错的步骤上设置了最周全验证的智能体，并且其背后的团队对乘法概率数学有深刻理解，足以在提议增加新步骤的功能面前据理力争。他们会定期绘制成功率随步骤数变化的图表，而不只是将其作为一次性的产物。他们将路径长度视为其应有的架构变量。

解决 95% 可靠性幻觉的方法就是拒绝被它愚弄。数学原理很简单，杠杆也是已知的，而这种纪律主要在于在正确的时刻关注正确的数字。调取追踪数据，绘制图表，并针对链路展开讨论——在链路与你的用户“对话”之前。