提醒不算上限：给 vibe 项目的 agent 花费装一个到线就停的硬上限

先划清界线：这篇不是“怎么看账单”，而是“怎么让账单停下来”

本站 cycle92 发过一篇《别让 AI 编程工具吃掉你的利润：vibe 开发者的 AI 账单实战》，那篇讲的是看懂定价、算清成本、按量选套餐。本篇讲的是另一层：当成本已经失控时，有什么机制能让它在到达你设定的线之前就停下来，而不是事后在账单里发现。看懂账单是记账，硬上限是刹车。两者缺一不可，但不能互相代替：一份再清楚的账单，也拦不住一个半夜陷入循环的 agent；一个没有成本基线的硬上限，设多高都是拍脑袋。所以读本篇之前，先默认你已经知道自己每个月大概花多少、钱主要花在哪个模型和哪个任务上——如果还不知道，先回 cycle92 那篇把账盘清楚，再回来设限。

同样要划清的邻居还有 cycle100 的两篇指南：Agent 数据访问护栏管的是“agent 能碰哪些数据”，毒依赖 containment 管的是“出事之后 90 分钟怎么收拾”。本篇管的是“agent 能花多少钱”，三者是同一套“给 agent 立规矩”思路在不同维度的落地，互不重复。

什么是硬上限：到线就停，而不是到线就提醒

先把定义钉死，否则后面全是模糊账。软上限是：花到 X 元，发一封邮件、弹一条通知，任务继续跑。硬上限是：花到 X 元，正在跑的任务被暂停或拒绝新的调用，返回一个明确的错误，恢复需要一次有记录的人工审批。Simon Willison 在 2026 年 10 月 3 日的文章《We're going to need default hard budget caps on pretty much everything》里就是这个定义，并且主张硬上限应该是默认值，客户要超支得显式 opt-out，而不是反过来。他的论据很简单：大多数人宁愿服务暂停一下，也不愿收到一张上万美元的意外账单。这个论点在 10 月被广泛转述，不是因为它新颖，而是因为它说中了所有被 agent 半夜烧过钱的人的共同体验：提醒邮件是早上才看到的，钱是半夜就花完的。

云厂商其实已经在往这个方向走了，只是都没做到“默认”这一步。Google Cloud 在 2026 年 7 月推出了 Spend Caps，对项目里的特定服务设月度金额上限，目前还是公开预览、一次只覆盖一个项目和一个服务。AWS 在 2026 年 9 月 16 日前后推出了 spending limits：给项目设月度支出上限，到线后该项目当月暂停，同样还在有限推送中。两家的功能都存在，但都不是默认开启，也都覆盖不全。所以对独立开发者来说，指望厂商替你默认兜底是不现实的：你自己的运行器里必须有一道自己的上限，厂商侧的上限只是第二道。

三层上限：任务级、会话级、月级，缺一层都会漏

只设一个月度总上限是最常见的偷懒设法，也是最容易漏的：一个任务可以在一天之内把整月预算烧光，月度上限要到月底才触发，等于没设。反过来只设任务级上限也不够：十个并行任务各花各的，每单个都没超线，加起来早就翻了倍。所以上限要分三层，各自管不同的失控形态：

• 任务级上限：单个任务最多花多少 token 或多少钱。管的是“某一次任务陷入循环、反复重试、上下文越滚越大”这种单点失控。数值倒推法：取你过去三个月里最贵的正常任务成本，乘以 1.5 到 2 倍，就是任务级上限的起点；低于这个数会误杀正常任务，高于这个数等于没设。
• 会话/日级上限：一天之内、一个项目之内累计最多花多少。管的是“并行任务乘以 N”和“一天内反复开新会话”这两种任务级上限看不见的失控。并行任务数要算进公式里：日上限至少要除以你常开的并行任务数，再反推每个任务的日内配额。
• 月级/组织上限：整个账号、整个项目一个月最多花多少。管的是“长期缓慢超支”和“多人共用一个池子互相不知情”。团队场景下还要再分一层：按人、按项目、按客户分账，共享池只给公共部分，客户项目各用各的池子，避免一个客户的失控任务吃掉所有人的预算。

三层之间要有明确的优先级：任务级先触发就先停任务，日级触发就停当天的所有新任务，月级触发就停当月的所有非关键任务。触发时返回的错误信息要让 agent 和人都能看懂：“任务预算已用尽（上限 X，已用 Y），任务已暂停，等待人工审批恢复”——而不是一句含糊的“调用失败”，否则 agent 会把它当成普通错误重试，重试本身又在烧钱。

执行点必须在调用之前：提示词里的“别花太多”不算控制

这是本篇最重要的一条技术判断：预算控制必须发生在实际调用之前（pre-flight），由运行器或网关强制执行，而不是写在提示词里、写在 agent 的系统指令里、或者事后对账时发现。提示词里的“请注意成本、不要浪费 token”对模型只是一种建议，模型在任务压力下会优先完成任务而忽略它；事后对账再清楚，也追不回已经花出去的钱。真正有效的执行点有三个，按可靠性排序：第一，供应商侧的上限（AWS spending limits、Google Spend Caps、模型厂商自己的用量上限），由账单方执行，最难绕过，但覆盖不全、粒度不一定够细；第二，你自己的调用网关或运行器，在每次调用前查剩余预算，超了直接拒绝并返回结构化错误，这是最值得投入的一层，因为它覆盖所有模型和所有入口；第三，agent 框架自身的配置（比如每个任务的最大步数、最大 token 数），作为补充，不能作为唯一防线。

一个最小可用的 pre-flight 检查长这样（伪代码，不依赖任何特定厂商 SDK，因为各家接口不同，照搬某家写法反而容易错）：在发起调用前，读取本次任务已用成本、当日已用成本、当月已用成本；三者任一达到上限，拒绝调用并返回“预算耗尽”错误，同时写一条带任务 ID、触发层级、已用/上限数值的审计日志；未达到上限但超过 70% 或 90% 阈值时，调用照常进行，但同时发一条告警，让人在白天看到、而不是在月底账单里看到。70% 和 90% 这两个阈值要分开：70% 是“注意”，90% 是“准备停”，100% 是“已经停”。只设 100% 一个阈值，等于把预警和刹车合并成了一件事。

熔断器的三态：断开之后怎么回来，比怎么断开更重要

从电路里借一个成熟模型：熔断器有闭合、断开、半开三种状态。闭合是正常通行；断开是到线后拒绝一切新调用；半开是恢复时只放行一个探测任务，探测通过了再逐步恢复，探测失败了重新断开并延长等待。很多团队的上限设计只有前两种状态，没有半开，结果就是：人工点一下“恢复”，失控任务原地满血复活，半小时后再次触发上限，如此循环。半开状态的具体做法是：恢复审批通过后，先只放行一个最小的探测任务（比如一次只读的、低成本的调用），确认成本计量正常、任务行为正常，再把其余排队任务按优先级逐个放行；同时把触发上限的那个任务单独挂起，不自动续跑——让它续跑之前，人必须先看一眼它到底在循环什么。

恢复审批本身也要有规矩：谁可以批、批一次放行多少、批完的有效期是多久，都要写下来。最常见的坑是恢复按钮没有审批、或者审批人就是触发任务的人自己，等于上限可以由花钱的人自己随时解除。独立开发者场景下，“审批人”就是你自己，那规矩就简化成一条：恢复前必须先看触发任务的日志和成本明细，确认失控原因已消除（比如修掉了循环、换掉了有问题的提示词、关掉了并行），再点恢复。没有看日志的恢复，和没有上限没有区别。

团队版与独立版的区别：分账，而不是共用一个池子

独立开发者用三层上限加 pre-flight 就够了；一旦涉及多人或多客户，要多做三件事。第一，分账：按人、按项目、按客户分别设池子，共享池只覆盖公共开销；否则一个人的失控任务会吃掉所有人的预算，而受害者要到月底才知道。第二，预留：每月预算里先扣掉一笔“不可停任务”的预留（比如已经承诺给客户的交付任务），剩下的才是可被熔断的部分；否则月级上限一触发，连已经承诺的交付也一起停了。第三，关账节奏：每月固定一天做成本复盘，对照上月的任务级、日级、月级触发记录，调一次数值——上限不是设一次就不用管的常量，它应该跟着你的任务规模和模型价格一起变。模型降价了，上限可以跟着降；任务变复杂了，任务级上限要跟着涨；一成不变的上限，半年后要么误杀、要么失效。

最常见的六个坑

• 只在 UI 层设限，API 直通：前端按钮上写了“每月最多花 X”，但直接调 API 的脚本、CI 里的任务、其他人写的调用代码都不走这个 UI，上限形同虚设。执行点必须在网关或运行器，不在界面。
• 缓存与重试重复计费：失败重试、缓存未命中、上下文重传都会产生额外调用，预算计量要按实际发生的调用算，而不是按“计划调用”算。
• 并行任务乘以 N：任务级上限乘以并行数就是实际的日内风险敞口，日级上限必须按并行数打折。
• 测试与生产共用一个池子：测试任务的失控不应该停掉生产任务，反之亦然；两个池子分开，测试池子的上限可以设得更紧。
• 恢复按钮无审批：见上文熔断器一节，恢复必须有一次看日志的人工确认。
• 只算模型 token，不算其他成本：沙箱、向量库、搜索 API、浏览器自动化、CI 分钟数都可能成为 agent 任务的附带成本；预算口径要覆盖任务的全部外部调用，不只模型账单。

一周落地计划：从盘点到演习

最后给一个可以直接照做的落地节奏。第一天，盘点所有调用入口：列出你的 agent 任务到底从哪几个入口花钱（编辑器插件、CLI、CI、后台服务、他人脚本），执行点要覆盖全部入口，漏一个等于没设。第二天，开供应商侧上限：把 AWS、Google Cloud 或模型厂商已有的上限功能打开，作为第二道防线。第三天，给自己的运行器或网关加上 pre-flight 检查：三层上限、70%/90% 告警、100% 拒绝、审计日志，缺一不可。第四天，设告警通道：70% 发到你白天一定会看的地方（不是一个没人看的邮箱文件夹），90% 发到手机能收到的地方。第五天，做一次熔断演习：故意把任务级上限临时调得很低，跑一个正常任务，看它是不是真的在到线时停下来、错误信息清不清楚、恢复流程走不走得通。演习通过的那天，你的硬上限才算真正上线；演习之前，它只是一份写在文档里的愿望。

数字怎么定：一张可以直接填的预算起草表

前面讲了三层上限的原理，这里给一张可以直接填的起草表。填之前先准备三个数：过去三个月里单个任务的最高正常成本、你常开的并行任务数、以及你一个月能接受的总预算。填表时按这个顺序：先填任务级上限（最高正常任务成本 × 1.5 到 2 倍），再填日级上限（月预算 ÷ 30，再除以并行任务数后乘回并行数——换句话说，日级上限是月预算的日均值，但要留出周末与波峰的余量，通常取日均值的 1.5 倍作为日上限、月上限作为最终兜底），最后填月级上限（就是你能接受的总预算本身，不要再乘系数）。举个例子帮你校准量级（数字是示例算法，不是任何厂商的报价）：假设你过去最贵的正常任务花了 20 元，月预算是 3000 元，常开 3 个并行任务，那么任务级上限起步就是 30 到 40 元，日级上限大约 150 元，月级上限就是 3000 元。任务级 40 元、日级 150 元、月级 3000 元这三个数之间是互相制衡的：任务级太松，日级会频繁触发；日级太松，月级会在月底前被击穿；月级太松，整个上限体系就等于没设。

填完表还要做一次“压力测试”：假设一个任务陷入循环，按你设的任务级上限，它最多烧多少钱？假设三个并行任务同时失控，日级上限多久会被击穿？假设一个月里有两天是高峰，月级上限还剩多少余量？这三个问题的答案，就是你的真实风险敞口。如果答案让你睡不着觉，说明上限设得太松；如果答案是“正常任务都会被误杀”，说明设得太紧。调上限不是一次性的工作，每月复盘时对照触发记录调一次：触发次数为零的月份，未必是上限设得好，也可能是任务量本身就小；触发频繁的月份，要先分清是正常任务变复杂了（该涨上限），还是真的有失控任务（该修任务）。

告警文案与熔断演习剧本：写下来、跑一遍

上限机制里最容易被忽视的两样东西是告警文案和演习剧本，因为它们不直接产生代码，却决定了机制在真实失控时管不管用。告警文案要分三档写，每档写清楚“发生了什么、还剩多少、该做什么”：70% 的文案是“注意：本月预算已用 70%，剩余约 X 元，按当前速度预计 Y 日用尽，请检查是否有异常任务”；90% 的文案是“准备：本月预算已用 90%，非关键任务将在到线时暂停，请确认哪些任务可以停”；100% 的文案是“已触发：预算已用尽，非关键任务已暂停，恢复需要查看触发任务日志并审批”。文案里必须带数字、带任务 ID、带剩余量——一句“预算告警”不带任何数字的通知，等于没发。

熔断演习的剧本可以按这个顺序跑：第一步，把任务级上限临时调到一个很低的值（比如正常值的十分之一）；第二步，跑一个已知的正常任务，确认它在到线时真的停下来，而不是继续跑完；第三步，检查错误信息是不是“预算耗尽”而不是含糊的“调用失败”，检查审计日志里有没有任务 ID、触发层级、已用与上限数值；第四步，走一次恢复流程：看触发任务的日志、确认失控原因、点恢复、确认半开探测任务先跑、再逐步放行其余任务；第五步，把上限调回正常值，写一份演习记录（触发是否及时、错误信息是否清晰、恢复流程有没有卡住）。演习记录要留下来，下一次真失控时，它就是操作手册；没有演习记录的上限机制，真失控时所有人都会凭感觉操作。

预算口径清单：除了模型 token，还要算进哪些成本

前面“六个坑”里有一条是“只算模型 token”，这里把它展开成一份完整的口径清单，因为预算口径漏一项，上限就虚一分。第一类是模型之外的 AI 调用：向量库查询、重排序、搜索 API、图片与语音模型、评审模型（比如让第二个模型检查第一个模型的输出），这些调用很多都不走主模型的账单，却都算在任务成本里。第二类是执行环境的成本：沙箱与虚拟机的按时计费、浏览器自动化的会话时长、CI 的分钟数、测试环境的云资源——agent 任务越长，这些成本越高，而且它们通常按时间而不是按 token 计费，失控任务烧起来的速度不比 token 慢。第三类是数据与存储的成本：任务过程中产生的中间文件、快照、日志、向量索引写入，有些按量计费，有些按存储时长计费，短期看不起眼，长期跑下来同样可观。第四类是重试与浪费：失败重试、缓存未命中导致的重复调用、上下文重传——这些不是“业务成本”，却是失控任务最常见的成本放大器，预算计量必须按实际发生的调用算，而不是按计划调用算。

口径定下来之后，执行上要做两件事。第一，统一计量口：所有成本项汇总到同一个预算账本里，不要让模型账单、云账单、搜索账单各算各的——分开算的账本，永远对不上总数。第二，给每一类成本设一个“哨兵指标”：比如每周看一次非模型成本占总成本的比例，如果这个比例突然从一成涨到三成，说明有任务在模型之外大量花钱，值得单独查一次，而不是等到月度上限触发时才发现。很多团队的预算失控，根源不是模型太贵，而是模型之外的成本从来没进过预算表。把口径清单贴在预算文档的第一页，每次接新的外部服务时，先问一句“它的成本进哪个口径”，再接——这个习惯比任何事后复盘都省钱。

一句话收尾：软上限告诉你钱花完了，硬上限保证钱花不完。Agent 越能干，这个区别就越重要——因为能干的 agent 失控起来也更快，而你睡觉的时候，它还在工作。

图注： 配电箱里一排断路器开关的实拍照片，比喻“到线就跳闸”的硬上限机制——配图为通用电气照片，并非任何厂商的计费界面截图。