让 Agent 每晚自动跑之前，给它一笔能停下来的预算

白天手动运行的研究助手，改成每晚自动执行后，多了分页搜索、摘要、重试和子任务。等早上看到费用告警，调用已经发生了。要让它在预算前停下来，需要把限制放在发起下一次调用的位置，而不只在结果页显示一个总数。

本文于 2026 年 11 月 13 日核对 Anthropic 当前限制文档与本站企业空间说明。下面是应用层预算设计和离线算例，没有部署真实调度器，也没有验证任何供应商在并发边界上的精确停费行为。教学金额不是模型价格，也不是本站产品新增功能。

告警、限速和额度各管一件事

先把容易混用的设置分开：

设置	能回答什么	不能据此推断什么
费用告警	到某个观察值时通知谁	收到通知前不会继续调用
请求或 Token 限速	一段时间内允许多快	一整晚最多花多少
应用任务预算	这个任务还能不能发起新步骤	所有外部费用都会自动入账
Key 或服务账户额度	该凭据或账户的可用范围	每个工作流拥有独立预算

Anthropic 当前文档明确区分支出限制和速率限制，并分别描述组织与 workspace 的范围。它的状态码和控制台设置属于该服务，不能直接当成所有兼容服务的行为。

本站企业文档则说明：企业 Key 额度和 Owner 钱包是两个条件，调用费用从 Owner 钱包扣除。按用途建立独立 Key 有助于限制和核对范围，但企业空间当前没有部门、成本中心等能力，不应写成已经支持按任意业务任务自动分账。

并发任务要先预留，再开始

只在请求完成后累加费用，会漏掉正在运行的工作。假设某个教学任务允许使用 10 个预算单位，已经确认用了 6 个，两个并发步骤各需预留 3 个。它们如果同时只看“还剩 4 个”，就可能一起出发，总承诺达到 12 个。

把已确认支出和未完成预留一起计算：

可分配余额 = 任务预算 - 已确认支出 - 未完成预留
10 - 6 - 3 = 1

第一个步骤预留后，第二个需要 3 个单位的步骤就不能再启动。这里实际计算的是准入承诺，不是发明了一种新的服务计价方式。

在数据库中，检查与预留应是同一个原子操作；多进程只靠本地变量无法保证这个结果。金额用最小计价单位的整数或合适的十进制表示，避免浮点比较漂移。

预留多少，需要根据具体步骤可约束的输入、输出、工具次数及最新计价规则决定。若某项外部操作成本无法可靠限定，就不能把估算当成硬保证；可以降低单步规模、禁用不受控路径，或先让人工处理。模型写一句“最多花十块”不构成服务端限制。

超时的请求，先保留“待核对”

收到确认结果后，把对应预留转换成实际支出，再释放未使用部分。若客户端超时，却不知道上游是否执行，不能直接按零支出释放全部预留并重发。

给这类操作保留稳定的操作 ID、请求时间、状态及可用的查询引用，在确认结果前标记为待核对。只有供应商明确提供任务查询时才用它续查；普通同步聊天请求未必有可查询的任务 ID。

重试也会占用预算，写入订单、通知等动作还可能重复执行。具体恢复顺序见n8n 失败后的副作用核对；图片或视频异步任务可参考等待与取消，不要把所有超时都处理成“再来一次”。

一次日报可以从小范围开始

先限定资料来源、最多处理的条目、每条内容长度、允许的模型与工具、重试次数、并行数量和总运行时长。到达任一上限时，保存已经完成的内容和未完成清单，停止发起新调用。超时保护能阻止本地继续等待，不保证已经提交的远端工作也被取消。

给不同用途单独建 Key，并按实际产品支持配置额度、过期时间和模型范围。不要让日常交互与无人值守任务共用一把长期、不限额度的凭据；具体保存方式见Key 安全。这属于用途隔离，不等于自动获得每个任务的精确费用。

验收时用模拟回执覆盖四种情形：两个工作同时抢预算、费用回执迟到、请求超时结果不明、程序重启后恢复预留。检查新调用有没有被挡住，既有工作有没有被重复发出，待核对记录是否仍在。没有做过这些检查，就不要向团队承诺绝不会超预算。

最后把模型、搜索、工具和存储费用分开列，按实际可取得的记录归集。客户端用量和服务账单的范围可以参考一次 Agent 任务的费用。把“何时停止接新工作”和“何时确认最终费用”区分开，自动任务才有可解释的停止与恢复方式。