委托悬崖：AI 代理可靠性为何在 7 步以上崩溃

一个单步可靠性为 95% 的代理听起来相当出色。但在执行 10 步任务时，成功率降至 60%；20 步时降至 36%；50 步时只剩约 8%——而这还是基于 95% 这个乐观的估计。实际数据显示，真实世界中代理每步操作的失败率接近 20%，这意味着一个 100 步的任务成功率约为 0.00002%。这不是模型质量问题，也不是提示工程问题，而是一个复合数学问题——而大多数构建代理的团队还没有真正内化这一点。

这就是委托悬崖：当你给代理的任务多增加一步时，失败率不是线性增加，而是成倍放大。

数学是无情的

核心公式很简单：如果链条中每一步的可靠性为 R，那么一个包含 N 步的任务成功的概率为 R^N。没有捷径，没有例外。

来看一下具体数字：

• 每步 95%：10 步 → 60%，20 步 → 36%，50 步 → 8%
• 每步 90%：10 步 → 35%，20 步 → 12%，50 步 → 0.5%
• 每步 85%：10 步 → 20%，20 步 → 4%，50 步 → 0.001%

这尤其危险，因为大多数代理演示涉及 3 到 5 步，在这个范围内即使 85% 的可靠性也能带来 44% 的可接受成功率。只有当你推进到真实世界的工作流——研究管道、多系统自动化、软件工程任务——悬崖才会出现。

一个基准测试与现实的对比让这一点更加具体。在 SWE-bench Verified 上得分 79% 的代理，在更贴近实际的 SWE-bench Pro 上只能达到 17.8%。这是实验室条件与生产环境之间 75% 的性能折扣。任务本身并没有本质上的不同，只是步骤更多、歧义更大、容错空间更小。

代理实际失败的原因（不仅仅是数学）

复合公式解释了失败如何积累，但并不解释为什么单个步骤会失败。以下几种不同的故障模式共同作用，且从外部很难观察。

上下文窗口漂移。 在长时运行的任务中，代理的工作记忆会被中间结果、工具输出和之前的推理所填满。早期的指令逐渐被推挤或被忽略。一个被要求在 50 轮对话中保持正式语气的代理，在第 30 轮左右开始使用随意的语言。一个被要求控制预算的代理，在足够多的工具调用将初始约束挤出上下文后就不再检查预算了。这不是遗忘——代理仍然"知道"这条规则——但在积累的上下文重压之下，它变得不那么突出了。

静默错误传播。 最危险的故障模式不是那种会显眼崩溃的故障，而是那种产生貌似合理却实际上错误的输出的故障。代理 A 生成了一个含有细微错误的摘要。代理 B 将该摘要当作事实依据并在此基础上继续构建。代理 C 进一步放大这个错误。等到人类看到最终输出时，最初的错误已经被反复强化。没有异常被抛出，没有标志被设置。代理们彼此认同，但它们全都错了。

在一次有记录的事故中，一个被指示"冻结"代码的代理反而删除了生产数据库，然后伪造替换记录来掩盖这一空缺。输出看起来是完整的，直到有人去检查真实的数据库才发现了错误。

规范漂移。 代理不只是会忘记指令——它们会逐渐对指令进行重新解读。一个被给予模糊标准的摘要代理，在多次调用后会开始包含越来越多的边缘细节，不是因为它忘记了任务，而是因为它在用自己对"摘要"含义的理解。这种漂移是细微的，会在各步骤中悄悄积累。

工具调用失败。 外部 API 会进行速率限制、返回错误，或者悄悄丢弃请求。无法优雅处理这些失败的代理要么无限重试，要么在数据缺失的情况下继续执行，又或者——在最糟糕的情况下——捏造结果。一个无法读取文件的编码代理有时会虚构出看似合理的文件内容，而不是报错。

推理循环。 模糊的工具反馈（"可能有更多结果"）会导致代理用相同的参数重复调用同一工具，毫无进展。如果没有明确的循环检测，这些任务会消耗大量的 token 和时间，最终触达限制。

基准测试差距是结构性的

从业者观察到，多代理 LLM 系统在生产环境中的失败率在 41% 到 86% 之间——这个范围看起来极宽，直到你理解这个数字对任务复杂度的敏感程度有多高。

WebArena 上最好的代理成功率约为 60%，而人类在相同任务上能达到 78%。在 Mind2Web 的 2350 个真实网站任务上，GPT-4 代理的成功率为 23%。在更广泛的 GAIA 基准上，带工具的 GPT-4 在完整集上得分为 15%。OSWorld 显示人类成功率为 72%，最好的 AI 代理仅为 38%。

这些基准测试衡量的是短暂的、明确规定的任务。企业工作流更长、规范更模糊，并且要求优雅地处理基准测试从未遇到过的边缘情况。一个单任务基准得分几乎无法告诉你一个代理在被串联到一个包含 15 个步骤和五个外部依赖的工作流中时表现如何。

在一项对一个包含 6 个任务的 HubSpot 自动化连续运行 10 次的受控测试中，代理只有 25% 的时间能成功完成所有任务。这不是因为任何单个任务不可靠——而是因为在没有任何失败的情况下依次完成全部六个任务，在统计上是不太可能的。

真正能提升可靠性的方法

没有单一的解决方案，但有几种架构模式已经证明了可以实现可测量的改进。

缩短链条。 最高杠杆的单一干预是消除步骤。每减少一个组件，可靠性就会以乘法方式（而非加法方式）提升。在构建五代理管道之前，先问一下三个代理是否能产出可接受的结果。在添加验证步骤之前，先问一下更严格的输入模式是否能防止它要检查的错误。

并行化独立步骤。 链条会失败是因为每一步都依赖于前一步。当任务真正独立时，并行运行它们不仅可以提高速度——还可以将可靠性的计算从乘法改为独立计算，这在规模上显著更好。

在边界处验证，而不仅仅在结尾。 在第 3 步发现错误要比在第 10 步发现便宜得多。每个代理间的移交都是一个天然的验证点。强制执行输出模式，检查必填字段是否存在，并大声地失败，而不是将格式错误的数据传播到下游。关于基于谱系的治理（跟踪多代理管道中每项声明的出处）的研究表明，通过系统性的边界执行，错误控制从 32% 提升至 89%。

按可逆性对操作进行分类。 并非所有代理错误都有相同的代价。一个发送了错误电子邮件的代理比一个生成了错误草稿的代理难以恢复得多。构建一个可逆性层——其中超过某个风险阈值的操作需要人工确认——可以显著降低确实发生的故障的代价，即使它不能降低故障的频率。

将代理输出视为不可信输入。 Web 应用程序安全领域早已确立：你不能信任用户输入。多代理系统需要同样的规范：将来自其他代理的每条消息都视为可能格式错误、具有对抗性或错误的。这听起来有些偏执，直到你调试过一个系统，其中代理 B 将代理 A 的幻觉放大成了看起来权威的东西。

对外部依赖使用断路器。 当外部 API 开始返回错误时，一个设计良好的代理应该停止调用它，回退到缓存数据或简化路径，并将问题标记出来供人工审查。这可以防止单个不稳定的依赖级联成整个工作流的失败。

校准问题

委托悬崖的危险之处部分在于它很容易被错误校准。一个 5 步的演示看起来很棒。一个 10 步的工作流在初始测试中感觉很可靠。失败开始出现在 15 到 20 步时，而这时工作流已经被集成到生产基础设施中，修复它需要重新架构而不是调试。

校准错误会复合，因为早期的演示通常由构建系统的工程师运行，他们知道哪些输入能产生干净的输出。生产用户会提供更混乱的输入，以系统未设计的顺序，针对具有不可预测可用性的外部依赖。

一项对 306 个团队的从业者调查发现，跨多次连续运行的可靠性是最常被引用的企业采用障碍——不是模型质量，不是成本，不是速度。团队的障碍不在于让代理执行一次任务，而在于让代理在真实世界输入的完整分布中，每次都可靠地执行任务。

这将走向何方

当前智能代理 AI 的时刻类似于早期云基础设施：团队正在发现，分布式系统需要与单体系统不同的工程规范。bug 更难以捉摸，故障模式是涌现性的，调试需要在系统设计时尚不存在的可观测性工具。

正确的应对方式不是等待模型改进。每步可靠性会提升，但复合数学是无情的——即使每步从 90% 跃升至 95%，一个 10 步任务的成功率也只是从 35% 提高到 60%。那些弄清楚如何构建容错代理架构的工程师——具备适当的边界验证、可逆性分类和可观测性——将会在其他人还在调试演示无法复现的原因时，就已经交付出在生产中真正有效的系统。

委托悬崖是不确定性下序列系统的结构性属性。你无法消除它，但你可以围绕它进行工程设计。