这篇的核心主张是什么？

Simon Willison 在 2026 年 10 月 3 日的文章里主张：按用量计费的服务应当允许用户设定硬性预算上限 —— 到额度后服务直接停止并返回错误。他明确说「软上限」（也就是发一封提醒邮件）不够。

为什么智能体让这件事变急了？

因为智能体把摩擦抹掉了。编码智能体和「个人智能体」让人很容易就把会调用付费 API、或开托管服务的代码跑起来，于是错误决策的成本来得更快，而且是在没人看着的时候跑掉的。

有：企业不希望自己的托管应用因为「超出预算」就开始报错。Willison 的回应是，多数企业和个人宁可看到报错，也不愿收到一张上万块的意外账单。

硬上限默认开启，取消上限必须是显式选择 —— 他的说法是放一个显眼的复选框，写「移除预算上限」。

Simon Willison 提出：按用量计费的服务应当默认提供硬性预算上限——到额度就报错停止，而不是只发提醒。对在桌面上跑编码/个人智能体的人来说，这是一项花钱安全功能，这篇给出今天就能落地的替代做法。

按用量计费的服务应当默认带上硬性预算上限 —— 到额度就直接断掉并报错，而不是发一封凌晨没人看的邮件。这是 Simon Willison 在10 月 3 日的文章里的主张，也是本周最实用的一条 agent 安全建议：他描述的风险不是「智能体被劫持」，而是「账单」。

项目	内容
回答的问题	智能体该有「默认硬性预算上限」，而不是半夜发封警告邮件
简答	Simon Willison 提出：按用量计费的服务应当默认提供硬性预算上限——到额度就报错停止，而不是只发提醒。对在桌面上跑编码/个人智能体的人来说，这是一项花钱安全功能，这篇给出今天就能落地的替代做法。
阅读时长	~3 分钟
最后更新	2026-10-05

核心是区分两件听起来相似、行为完全不同的东西：

Willison 的说法很直接：「这些必须是硬限制。」他想防的场景是：服务悄悄跑掉几百甚至几千美元，第一个信号是半夜收到一封「已超出限额」的邮件。

他也点出了反对意见并做了回应：产品方不愿意加硬上限，是因为客户不希望托管应用因为撞到预算线而开始失败。他的回答说，多数企业/个人宁可看到一次报错，也不愿收到那种量级的意外账单。他提出的默认值是：上限默认开启，取消必须显式勾选 —— 一个显眼的复选框，大意是「移除预算上限」。

计量计费不是大模型发明的，但智能体改变了「一个人多快能走到计费」这件事。编码智能体，以及更友好的「个人智能体」外壳，把「有个想法」和「跑起代码」之间的距离压到很短。而那些代码可以调用付费 API、开通托管基础设施，或者写入按 GB 计费的存储。

以下是分析，不是文章里的事实：这种设置的风险特征在于时间上的不对称。人在电脑前试东西，跑出昂贵循环几分钟就能发现；凌晨三点在循环里重试失败调用的智能体不会。最烧钱的那一次运行，恰好是没人看着的那一次 —— 这就是为什么上限必须由平台强制，而不能靠自觉。

你没法逼每家服务商立刻加这个功能，但可以在桌面智能体周围先把大部分防护搭出来：

按用途拆开 API Key。 一个智能体/项目一个 key，等于一个可以单独归零的预算，某个 key 陷入循环也掏不空你其他用途的额度。
能用服务商限额就用。 一些服务商提供按项目或按账号的用量限额；撞上限就报错的限额，是市面上最接近硬上限的东西。
给智能体自己的循环设上限。 最大迭代次数、单任务最大工具调用数、超时时间，都很便宜，却能在模型跑偏时把成本框住。
凡是「开通资源」都要确认。 创建基础设施、升级套餐、启动付费任务，应该是明确批准，而不是静默副作用。
看单次运行成本，不只是月度总额。 按任务设定预算，才能在跑飞的那天就发现。
把浪费型环节放到本地跑。 那些本来要按 token 计费的重复工作 —— 读文件夹、总结文档、重试一次转换 —— 模型跑在自己硬件上时，每次调用都不产生费用。

最后一点正是「本地优先」在隐私之外的意义。MOOGH 把智能体跑在你的机器上，任务里那些因为重复而昂贵的环节，可以在不挂账单的情况下完成。可以下载后先看看一个任务实际消耗多少，再决定要不要把它排进定时任务。

「加个硬上限」是一句话的功能请求，收益却被严重低估，而且它不会在所有平台第一天就出现。在那之前：拆 key、用服务商限额、给循环设界、开通资源前确认、重复环节放本地。然后，给那些你按月付钱的工具发个邮件，把那个复选框要出来。

相关阅读：