自主任务连跑三夜，账单翻了一倍：我们给 token 花销立了一本账

这个月头，我们的自主交付任务连着跑了三个通宵。早上看账单，本月日均 token 消耗是上个月的接近两倍。

具体的事故不长：一个子任务在给定的接口契约上反复失败，模型自己重试了一小时二十一发调用，每次调用还带着四万多 token 的上下文——前几次失败的备注被塞回了 prompt，越重试上下文堆得越厚。结果任务还是红的，token 烧完了。

复盘的结论很直接：模型没有跑偏，是循环上根本没有账本。成本只在项目层面估过一遍，单任务想花多少就花多少；重试逻辑没有上限；过程消耗没有任何告警。最麻烦的是「单次失败很便宜」这个错觉——一次四万 token 的调用单看不过几十块，一天几百次叠起来，凌晨就很难被任何人拦下。任何一个通宵任务，都只是在等一张丑账单。

之后我们搭了一套「三棍」护栏，三棍对应三笔学费。

**第一棍：每个任务发饭票，消耗按 API 返回值计，不按自估。**

自主任务启动前必须申领单任务预算：能烧多少 token。调度器另外给全天定一个总闸。两层账本：任务账和日账，哪层先撞哪层说了算。日总闸不是任务预算的简单倍数——我们定在当天全部预算之和的一点五倍。多点说明排产本身乱了，该叫醒的是人，不是账单。

自估这一点我们栽过跟头。第一版按字符数估算成本，还自发压缩 prompt 想省钱，结果 API 实际计费口径和我们的估算能差两成。后来干脆只求值于 API 响应里的 usage 字段。估算只用在启动前申请预算那一步，任务一旦跑起来，记账的是 API。

**第二棍：撞线就停，不是撞线通知你。**

第一版做得很客气：预算达八成，发告警，任务继续跑。想着通知了自然会人来。结果是夜里十一点告警，无人看，任务又自己跑到第二天早上七点，预算打穿三成。改完之后：八成发告警，百分百拒调、结束任务，失败原因记入账本。

这是最狠的一条，也是最容易被自己人动刀的一条：护栏必须有让任务失败的权力。只通知不刹车的不叫护栏，叫告示牌。一个不能让自己失败的任务，不具备过夜资格。

**第三棍：重试是同一个人，账按任务记，不按 attempt 记。**

我们还有一个旧习惯：上次 attempt 超支，重试一次就清零。失控任务靠反复重启就能绕过节流。现在账本的唯一键是任务 ID，attempt 复用同一张饭票，不会重新拨款；另加单次 attempt 上限，约为任务预算的三分之一，一次尝试烧不完一个下午。超预算任务进评审队列，人工核验后重新发预算再启动，绕不过去。

数字：护栏八月十五日前后定型。之后两周，没有任何任务的单次超花发生在八十告警点之前；告警共触发四次，每次十分钟以内闭环。日均消耗回落到事前水平的七成左右。我更看重的是另一件小事：「这个任务该不该花这么多」这个问题，以前要在凌晨两点靠人想，现在任务启动的那一刻就有答案，答案写在账本里。

预算不是节约工具，它是自主任务被允许自治的入场券。