10 月 3 日，Simon Willison 发了一篇不到千词的短文，标题是一句近乎呐喊的判断：「We’re going to need default hard budget caps on pretty much everything」——几乎所有东西都需要默认硬预算上限。两天内它在 Hacker News 冲到 584 分。这不是一篇「AI 危言耸听」文，恰恰相反，它冷静地指出了 Agent 浪潮里最容易被忽视的结构性风险：当部署一段会花钱的代码的成本趋近于零，账单的失控概率就趋近于一。
一、失控的机制：摩擦消失，账单失守
先把 Willison 描述的风险链条完整推一遍。
编程 Agent 的工作方式是接受一句自然语言指令，然后自主完成写代码、装依赖、调 API、部署上线的全流程。这条流水线里藏着三类按量计费的敞口：
第一类是调用敞口。 Agent 写的代码可能接了付费 API——搜索、地图、支付、其他模型。功能验证阶段也许每天只花几分钱，但一旦代码里有个死循环、重试逻辑写错，或者服务意外被爬虫发现，费用曲线可以在几小时内变成竖直线。
第二类是资源敞口。 Agent 在云上开的虚拟机规格、数据库容量、对象存储桶，都是按量计费。人类工程师开资源时会犹豫「这个规格是不是太大了」，Agent 没有犹豫的习惯，它只对任务目标负责。
第三类是无人值守敞口。 这是最危险的。Agent 部署的东西往往在用户睡觉时持续运行。Willison 给出的画面很有画面感：你被一封凌晨发出的预算告警邮件吵醒，打开控制台，发现你那个失控的服务在你睡觉的几个小时里已经又烧掉了几百甚至几千美元。告警邮件只负责告诉你坏消息，不负责止损。
传统的风险控制手段——代码评审、成本审批、资源规格确认——全部建立在「有一个人类在关键节点上」的前提上。Agent 把这些关键节点一个个抹掉了。摩擦的消失是双向的：上线的摩擦消失了，失控的摩擦也消失了。
二、解法：把「默认安全」带进账单
Willison 提出的原则只有一条，但足够锋利：按量计费的服务和 API 都应该默认配备硬预算上限——达到阈值，服务熔断，返回错误。要关闭它，必须显式勾选一个免责声明。
他甚至把那个勾选框的文案都拟好了：
「移除预算上限。我的应用在超出配置的预算额度后不会被关闭，后续费用由我自行承担。」
这个设计里有三个值得展开的产品思维。
第一，为什么必须是「硬」的。 软上限（超支后发警告邮件）在人类主导的世界里尚且经常被忽略——告警疲劳是运维界的经典顽疾——在 Agent 主导的世界里更是形同虚设：你睡觉的时候谁来读那封邮件？硬上限的本质是把风险从「事后补救」（依赖人类及时响应）转移到「事前封顶」（系统自动执行），后者才不依赖任何人的注意力。
第二，为什么必须是「默认」的。 安全工程里的经典结论：可选项永远不会被大多数人设置。默认值才是产品真正的安全策略。把「裸奔」从默认状态改成需要主动勾选免责声明的例外状态，行为经济学上叫改变默认锚点，效果上等价于把最危险的路径变成最麻烦的路径。
第三，为什么反对意见是可反驳的。 商家最自然的反对是：业务系统因为触顶开始报错，中断损失可能比省下的钱更大。Willison 的回应直击要害——绝大多数个人开发者和中小企业面对「可控的报错」与「不可控的一万美元账单」时，会选择前者。真正有 SLA 压力的业务当然应该能关掉上限，但那必须是一个深思熟虑的、显式的、留痕的动作，而不是一条从未被检查过的默认路径。
三、云厂商跟进了多少：一张现状地图
有意思的是，Willison 的呼吁其实已经部分落地——他在文中承认，AWS 几周前刚悄悄上线了相关功能。
AWS 在 9 月 16 日的公告《New AWS experience helps builders get started and ship faster》中推出了项目级消费限额：为项目设置月度支出上限，达到限额后项目当月自动暂停。这正是「硬熔断」语义。但有一个关键限定：官方文档明确写着该体验「目前正向有限数量的客户分批发布」——对存量账户全面生效还需时日。多年来，无数人因为「听说有人在 AWS 上被失控账单烧穿」而不敢把它用于个人项目，这个功能普及的那天会改变很多人的默认决策。
Google Cloud 走得更早：七月上线了名为 Spend Caps 的功能，可以按项目内的具体服务设置月度资金上限。粒度更细，这对多服务项目是实质利好——你可以给实验性的 API 配额设上限，同时不限制数据库。
其他平台的差距更大。按量计费的 AI 原生服务——模型 API、向量数据库、Agent 托管平台——绝大多数还停留在「告警邮件」阶段。这个真空地带正是未来几个月的产品机会。
四、更深一层：Agent 应该成为成本治理的一部分
文章结尾，Willison 提了一个我认为比功能清单更有远见的观点：Agent 自己应该参与成本治理。
具体说，就是让 Agent 在为用户推荐和部署方案时，优先推荐带硬预算上限的服务商，并在部署方案中主动输出成本预估。设想一下这个对话：用户说「帮我做个周报摘要服务」，Agent 返回的方案里不仅有架构图，还有一段「本方案预估月成本 X 美元，所选服务商支持硬预算上限，已默认为你配置 Y 美元熔断线」。这才叫把成本意识写进了 Agent 的价值观，而不是留给事故后的复盘报告。
反过来说，这也是 Agent 平台层的机会：一个能在部署前自动扫描所有按量计费依赖、生成成本敞口清单、一键配置熔断的「Agent 财务顾问」，可能比再多一个编码 Agent 更解决真问题。
五、写给现在就要上手的你
在平台全面默认硬上限之前，下面这套组合拳今天就能落地。核心思路是隔离 + 封顶 + 留痕：
1. 每个 Agent 项目一个独立子账户 / 独立 API key
- 爆炸半径被限制在单个项目内，且可一键撤销
2. 账户层能设的限额全部设上
- 云厂商消费限额、模型 API 的用量上限、支付渠道的单笔限额
3. 审查 Agent 生成代码里的每个计费依赖
- 重点：自动扩缩容配置、无人值守定时任务、重试逻辑的上限次数
4. 把成本审查写进流程
- 要求 Agent 在部署方案中输出月度成本预估
- code review 清单里加一条：这段代码每月最多能烧多少钱Willison 这篇文章的价值不在于提出多深的技术方案，而在于它把一个所有人隐隐担忧、却没人说破的结构性问题，变成了一句可以被产品经理写进需求文档的话：默认硬上限，超额即熔断，裸奔须显式。Agent 让软件的生产成本趋近于零，但软件运行的账单不会消失——治理账单的方式，必须跟上生产账单的速度。