一个死循环烧掉一万美元：按量计费的 AI 时代，得给成本装保险丝
结论先行
一个项目的 Cloudflare Durable Object alarm 陷入死循环，读写累计约 6 万亿次，账单约一万美元。这件事真正的教训不是「小心写循环」，而是故障的形态变了：过去死循环最坏不过是机器挂掉，现在云会自动扩容、继续干活、继续计费——失败从「停摆」变成了「账单」。
为什么会集中爆发
三个条件叠在一起：
- 按调用量计费：用得越多越贵，而且没有天然上限；
- 自动扩容：系统不会因为压力大而停下来，反而更卖力地工作；
- 无人值守的智能体：会重试、会自愈，于是把一次错误放大成持续消费；
- 可观测性滞后：用量往往到账单日才显形，而事件发生在几周之前，中间没有任何提醒。
更隐蔽的一类
死循环只是最显眼的版本，真正日常的是「慢性超额」：定时任务跑得比预期频繁一点、重试策略太激进、日志里每一次失败都触发一次模型调用。单次都不贵，一个月下来就是一张意外账单。它们不会报错，只会静静地计费。
五道保险丝
- 硬预算与告警：给账号设日/月上限，超阈值直接告警甚至熔断；
- 重试上限：所有自动重试都带
max_iterations与指数退避； - 缓存与去重：相同请求不要重复打穿下游；
- 把「调用次数/循环次数」当监控指标，而不是只看延迟和错误率；
- 上线前用沙箱账号跑一遍限额，先在便宜的地方把坑踩完。
一句实操
给任何「AI 自动跑」的任务至少加一句 max_iterations，再在账单系统挂一个 24 小时阈值告警。这两行配置，可能比一次架构评审更省钱。把成本当成一个需要被持续监控的指标，而不是月底才去面对的结果。
参考来源
- 小北（@frxiaobei）谈 Cloudflare 账单与 Vibe Coding 成本控制：原帖
延伸阅读：按量计费该默认有「硬上限」：Agent 时代最贵的一课 · 每天 50 万美元查一次事故：Agent 安全的成本第一次有了锚点