任务翻一倍，失败翻两番

整整一年被推销的那个梦想，是能替你干满一整天的 agent——你早上 9 点交给它一个目标，它埋头干八个小时， 你回来就能拿到一份完成的活儿。Sequoia 甚至给它定了个日期：可靠的 8 小时工作日 agent「到 2026 年底」。 我也很想要这个。但数学对此有意见。

复利之墙

一个由许多步骤组成的任务，只有在 每一 步都成功时才会成功。这是乘积，不是求和。所以误差不是相加—— 是相乘。2026 年的一篇论文《The Long-Horizon Task Mirage》 给出了数字：把任务长度翻倍，会让失败率大约翻两番，而不是翻一倍。区区 每步 2% 的误差，在仅仅 20 个相互依赖的步骤里，就变成 33% 的概率把整个任务搞砸。

在十个模型和四档长度上测量，整体 pass@1 从短任务的 76.3% 跌到超长任务的 52.1%——24 个百分点的 超线性下滑。而且问题不只是每步的误差：在 25–30 次工具调用之后，即便是 200K token 的上下文窗口也会跟丢线索 ——模型忘掉早先的结果，把已经做完的步骤又重做一遍。

可靠性不是模型的属性。它是「在没有检查点的情况下，有多少件事必须接连做对」这件事的属性。

为什么更好的模型救不了你

这就是「只要等下一个模型」里的陷阱。把每步误差从 2% 压到 1%，在 20 步里，你还是会有约 18% 的概率失败。 把误差率减半并不能把痛苦减半，因为它在跟一个指数搏斗。在可预见的将来，没有哪个模型好到能让一条天真的 100 步链条变得可靠。曲线赢。

解决办法是架构，不是耐心

那 25% 的 agent 真正跑到生产环境的团队，并不是在跑更长的链条。他们跑的是 更短 的链条，外面裹着结构：

• **拆解。**把八小时的活儿拆成短的、能独立检查的任务。十个 10 步任务组成的链条、每个之间夹一个检查点， 比一次跑 100 步要强——强得多。
• **设检查点。**在步骤之间保存已验证的状态，让一次失败只损失一个任务，而不是一整天。别让第 90 步依赖于 模型是否还记得第 3 步。
• **先验证，再继续。**在每一阶段设一道便宜的检查——确定性的结果、第二个模型、一个 schema——在下一阶段 建立在它之上之前。在那 2% 复利叠加之前就抓住它。
• **保持窗口干净。**更多回合并不等于更多思考。过了约 30 次工具调用，context rot 就开始了；一个新鲜、 聚焦的上下文，胜过一个塞满 90 步历史的臃肿上下文。

这是我从不同方向反复得出的同一个教训： 一个什么都做的 agent，什么都做不好，还有 编排才是真正的架构。长时程的可靠性，就是拿着秒表的编排。

结论

任务翻一倍，失败翻两番——这不是模型的缺陷，是算术。全天候的自主 agent 之所以到来，不是因为某个实验室 发布了更聪明的大脑；而是因为你不再要求一个大脑把 100 件事接连做对。

别去造一条更长的链。造一条更短的，在每一个环节都检查过。