委托悬崖：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 和时间，最终触达限制。
