按量计费该默认有「硬上限」：Agent 时代最贵的一课
观点：按量计费的服务与 API，默认就该带一个硬性预算上限
Simon Willison 撰文提了一个很朴素、但被普遍忽略的要求：按用量计费的服务与 API 应该默认提供硬性预算上限——超出额度直接切断并返回错误，而不是只发一封警告邮件。
他的理由指向一个具体变化：编程智能体把"部署付费代码"的门槛降到了极低。写一个会调用付费 API 的循环，现在只需要一句话；而一个写错的循环，可以在你睡觉时把额度跑穿。
三个要点
- 警告邮件对程序无效。 人不看邮件会心疼钱，程序不看邮件；重试逻辑只会把错误吃掉继续跑。
- 默认值就是安全基线。 "默认无限、需要自己去设上限"等于把风险交给最不了解账单的人。
- 止损要发生在链路上游。 在网关或账户层切断，比在每个应用里写判断可靠得多。
一个容易踩的顺序问题：先跑通再设限额。正确顺序要反过来——先设一个很小的上限把链路跑通，再逐步放开。
对读者的实际建议
- 一个项目一个 key，一个 key 一个额度。 混用 key 是账单失控最常见的原因。
- 给 Agent 循环加三重保险： 最大步数、单次运行时长、单次运行花费上限，缺一不可。
- 把消费告警接到你会看到的地方。 告警只发邮箱大概率等于没发，要接到聊天工具或手机通知。
- 预算按"最坏情况乘重试次数"估。 不是按平均单次成本估——峰值永远出现在失控的那一次。
结论：Agent 让"写代码"变便宜的同时，也让"写错的代码"变贵。硬上限不是不信任开发者，而是承认任何人都算不清重试次数。
参考来源
- Simon Willison 博客：simonwillison.net
- 素材索引：AI HOT（aihot.news）