复合精度问题：为什么你的 95% 精确率 Agent 会失败 40% 的时间
你的 Agent 在隔离测试中表现完美。你对每个步骤都做了基准测试，测量得到每步精确率为 95%。向利益相关者演示时效果很好。然后你上线了，用户反映几乎有一半时间它都会失败。
这个失败不是任何单个组件的 bug，而是数学。
一个每步成功率为 95% 的 10 步流水线，整体成功率为 0.95^10 = 59.9%。不是 95%，甚至不是 80%，只有 60%。而且这还是乐观估计——它假设错误是独立的、可恢复的和可见的。在真实的生产系统中，这些假设一个都不成立。
这就是复合精度问题，理解它会从根本上改变你设计 Agent 系统的方式。
那个应该让你警觉的算术
公式很简单：如果 n 个顺序步骤中每步的精确率为 p，那么端到端的成功率为 p^n。不直观的是这个值崩溃得有多快：
| 每 步精确率 | 5 步 | 10 步 | 20 步 |
|---|---|---|---|
| 99% | 95.1% | 90.4% | 81.8% |
| 95% | 77.4% | 59.9% | 35.8% |
| 90% | 59.0% | 34.9% | 12.2% |
| 85% | 44.4% | 19.7% | 3.9% |
在每步精确率为 90%（听起来很高）的情况下，一个 10 步流水线只有 35% 的时间能成功。你会拒绝这样的产品。但团队通常会交付具有这些特征的流水线，因为他们孤立地测量步骤精确率，并假设整个系统继承了它。
这不是新发现。可靠性工程学至少从 1960 年代就知道这一点，称为卢塞尔定律（Lusser's Law）：链条的可靠性等于其各链接可靠性的乘积。这是在火箭故障后正式提出的——每个组件测试都没问题，但集成系统却不断爆炸。我们正在用 LLM 重新发现它。
实证研究证实了这个数学。关于多步问答的研究显示，精确率从 2 步问题的 78% 下降到 8 步问题的 31%。WebShop 交易任务在多步链中 68% 的时间都会失败。在长周期软件工程基准测试中，前沿模型在需要修改大型代码库中多个文件的任务上，只有 15–24% 的成功率——尽管相同的模型在单个子任务上表现出色。
为什么问题比公式暗示的更严重
公式 p^n 假设了三件事，而这些在生产中几乎从不成立：错误是独立的、错误是可见的、错误是可恢复的。
错误是相关的。 在相似数据上训练的 LLM 会以相似的方式失败。如果你运行同一模 型的三个实例，希望多数投票能捕捉错误，你可能会发现所有三个实例都自信地同意了错误答案。它们共享相同的幻觉、相同的盲点、相同的训练分布。触发一个的 bug 会触发所有。这使得共识投票远不如它看起来有价值——你获得的不是独立性，而是相关的置信度。
错误是粘性的。 在第 2 步产生看似合理但错误输出的 Agent，不会导致第 3 步响亮地失败。第 3 步消费了错误的输出，产生另一个看似合理但错误的输出，错误无声地复合。到第 7 步时，你已经远离了应该在的地方，但没有抛出任何异常。这种"失败粘性"是伤害团队的生产失败模式：系统看起来运行成功，但交付的是垃圾结果。
错误在步骤间不均匀。 关于 Agent 工作流可靠性的研究表明，终端步骤（流水线中的最后步骤）和初始步骤不成比例地负责失败。初始失败会级联——所有下游都建立在破碎的基础上。终端失败最难捕捉，因为流水线已经提交了资源才到达那里。中间步骤单独影响较小，但会放大早期错误。
真实企业任务的实际有效每步精确率通常是 60–80%，而不是 95%。当你将这个数字代入公式时，一个五步流水线不到一半时间能成功。这不是可靠性问题。这是一个不起作用的产品。
真正有效的架构应对方案
以下任何缓解措施都不是银弹。每种措施在失败曲线的不同部分起作用。
带错误隔离的任务分解
最重要的架构决策不是使用哪个模型——而是如何分解任务。当一个长任务被编码为单个 Agent 提示时，任何地方的失败都需要重新启动所有内容。当每个逻辑步骤是自己独立的单元，具有明确的输入和输出时，第 4 步的失败意味着你重试第 4 步，而不是整个流水线。
积极的分解也创造了更好的检查点机会，使失败变得可见。在内部链的第 7 步失败的整体 Agent 告诉你"它失败了"。分解的流水线告诉你"第 4 步接收了正确的输入并产生了错误的输出——这是差异"。那是可调试的。
关键洞察：在你能编写清晰输入/输出模式的粒度上分解，而不是在子任务感觉像自然人类任务边界的粒度上。LLM 任务需要比人类预期的分解得更小。
置信度门控的提前退出
不是所有输出都值得同等的置信度。模型真正不确定的输出不应该继续到下一步——它应该重试、标记供人工审查，或调用回退路径。
挑战在于原始模型置信度分数校准很差。高 logit 概率并不意味着答案是正确的。你需要校准过的置信度：模型声明的置信度是否实际上预测了保留数据上的正确性？在大多数生产系统中，这种校准工作被跳过了，所以置信度分数作为门控几乎没用。
更好的替代方案：输出一致性检查（用不同的提示对同一步骤运行两次并比较）、约束验证（输出是否满足它应该 满足的领域约束？）以及行为不变量测试（输出是否通过应该始终为真的健全性检查？）。这些比原始模型置信度更可靠。
当步骤未通过这些检查时，正确的响应并不总是重试。对错误进行分类很有帮助：
- 瞬态错误（解析失败、超时）：带退避重试
- 可修复错误（违反约束但输出可修复）：将错误暴露给模型并要求其纠正
- 永久错误（语义上不可能的请求）：升级或提前中止
通过将错误消息注入回上下文来重试可修复错误——Try-Rewrite-Retry 模式——以低成本恢复了相当一部分失败。
战略性验证放置
在长流水线的每一步之后添加验证步骤是昂贵的。关于验证引导的 Agent 工作流的研究表明，不是所有验证步骤都提供同等价值。
最高价值的验证点是：
- 在第一步之后（在级联之前捕获早期失败）
- 在分支点（错误使流水线走向完全错误路径的地方）
- 在不可逆操作之前（发送电子邮件、修改记录、付款）
- 在最终输出综合步骤之前
在线性链中间进行验证通常只是增加延迟而不提高结果可靠性，因为捕获错误的验证步骤仍然需要从错误点重试——而如果中间步骤是流水线中抗错误的部分，你就是在错误的节点上浪费资源。
一个实用的优化：投机执行。在验证异步运行的同时继续下一步。如果验证失败，回滚。如果通过，你已经摊销了延迟。当步骤回滚成本低时这有效，这 也是另一个默认将步骤设计为可逆的原因。
在正确位置设置人工检查点
人工审查有效，但前提是检查点基于风险而非节奏放置。每 N 步一个检查点是任意的。在任何不可逆操作之前、在输出方差超过阈值的任何步骤之前，或当累积置信度下降到某个下限时——这些检查点才能捕捉实际失败。
机械要求：检查点必须将整个 Agent 状态（所有上下文、所有中间输出、计划的下一步操作）以人工审查员能在两分钟内实际理解的形式序列化。如果状态转储需要阅读 40k 个 token 的 Agent 草稿才能评估，审查员将盲目批准。那不是监督——那是表演。
为人类理解设计状态表示，而不是为技术完整性。Agent 已做什么、准备做什么以及为什么不确定的摘要，对审查员比原始上下文转储更有用。
通过多样性减少相关失败
如果你需要多 Agent 共识来提高可靠性，Agent 的多样性比数量更重要。三个相同模型的实例投票很少优于两个。更可靠的方法：
- 对同一底层任务使用不同的提示表述
- 使用来自不同提供商或训练运行的模型
- 使用独立的验证模型（不同的基础模型、不同的提示），而不是在克隆间多数投票
对于更高风险的应用，架构多样性——不同的推理方法（思维链 vs. 直接回答 vs. 结构化分解）——可以暴露同质集成所遗漏的相关失败模式。
成功率数学告诉你关于流水线长度的什么
复合公式给你一个设计约束：给定目标端到端可靠性，你需要什么样的每步精确率，这是否可以实现？
对于一个以 90% 整体成功为目标的 5 步流水线，你需要 98% 的每步精确率。对于一个以 90% 整体成功为目标的 10 步流水线，你需要 98.9% 的每步精确率。这两个数字都处于生产 LLM 系统在明确定义任务上能达到的边缘，对于模糊任务则不可能实现。
这意味着超过 5–7 步后，你无法单独通过步骤精确率达到 90% 的可靠性。你必须添加错误恢复机制。流水线结构必须假设失败会发生，并有处理它的路径——重试逻辑、回退策略、人工升级——而不是仅仅假设步骤会成功。
从经验上看，生产研究设置中的长周期流水线（10+ 步）在没有显式错误恢复架构的情况下只有 15–30% 的成功率。在复杂任务上达到 80%+ 成功的系统都有共同特征：积极分解、显式检查点、错误分类和重试，以及针对高不确定性决策的人工升级。
错误恢复的反直觉结果
这里有一个改变 你应该如何优先考虑可靠性工程的反直觉结果：减少失败粘性（错误在恢复前传播多少）通常比提高每步精确率更重要。
一个每步精确率为 90% 但有 50% 错误恢复能力（一半错误被捕获并纠正）的流水线，显著优于一个没有恢复的 96% 精确率流水线。这是因为恢复阻止了复合。在第 2 步被捕获和纠正的错误不会感染步骤 3–10。在第 2 步无声传播的错误会让你损失整个流水线。
对工程优先级的影响：在花费精力将每步精确率从 93% 推高到 96% 之前，检查你是否有任何错误恢复。对失败检测进行仪表化、在可修复错误上添加重试逻辑，以及实现基本的置信度阈值供人工审查，可能比在提示优化上花费同等工程努力更能改善整体流水线可靠性。
这也意味着每步精确率对于复杂流水线来说是错误的主要指标。正确的指标是端到端任务完成率，在代表性真实输入样本上测量——而不是精心挑选的测试用例。
从哪里开始
如果你正在构建或维护一个多步 Agent 系统，进行一个简短的诊断：
- 你当前在真实输入上的端到端任务完成率是多少？如果你不知道，那是第一个问题。
- 你的流水线有多少个顺序步骤？将公式应用于你测量的每步精确率。预测的端到端率是否与你所看到的一致？
- 当一步失败时，流水线是响亮地失败（异常、空输出）还是无声地失败（看似合理的错误输出）？无声失败是危险的。
- 你有任何错误恢复吗？你能在不重启整个流水线的情况下重试单个步骤吗？
- 你的检查点 在哪里？它们是在高风险操作之前，还是任意的？
复合精度问题没有单一的解决方案。它是从一开始就塑造架构的约束：任务如何分解、输出如何验证、错误如何分类和恢复，以及在哪里插入人类判断。将其视为部署问题而非设计约束的团队将在生产中不断重新发现它。
60% 的成功率不是模型的错。这是算术。
