Agent 烧钱太快？我用一张「预算卡」把 token 消耗管起来

副标：换档保续接，执行保透明，预算保可控——三张卡撑起 Agent 系统稳定性

一、成本失控的三种典型场景

凌晨一点，我盯着后台账单傻了眼。

上周写的 Agent 脚本，跑了一个自动调研任务，调用了一次外部数据源，token 消耗直接飙到正常情况的四十倍。不是 bug，不是崩溃，是它"想得太多了"——多调了三轮 API，每轮还带了超长上下文，最后算出来一个答案，花费够付半个月服务器费用。

朋友说：你这哪是 Agent，你这是碎钞机。

我之前两篇文章讲了「续接卡」和「观测卡」，解决了"断了怎么接"和"跑着怎么看"两个问题。但今天这篇文章，要解决第三个问题——花多了怎么停。

场景一：递归调用失控

Agent 需要调研某个话题，于是它调用了搜索工具。搜索结果不够满意，它又调用了搜索。搜了七次，才停下来。每次搜索都带着完整的历史对话上下文，越搜越贵，越贵越停不下来。

真实代价：单次任务 token 消耗从预估的 5000 升至 42000，超出预算 8.4 倍。来源：内部实盘记录，2026-10-25，编号【未核实】。

场景二：长上下文累积

每一次工具调用、每一次 API 响应，都追加到对话历史里。十轮交互后，上下文可能已经膨胀到十万 token。后续的每一次推理，都在为前文的"历史包袱"付费。

有一个读者反馈：他的 Agent 做了二十轮对话后，单次推理费用比第一轮贵了三倍。原因是第二轮到第二十轮的上下文全部累积在第 21 轮的输入里。来源：公开社区反馈，具体链接【未核实】。

场景三：并发任务叠加

同时跑五个 Agent 实例，每个都在默默消耗。没有全局预算视图，你以为只花了一点点，实际账单来了才惊出一身冷汗。

二、预算卡：一张卡片管住所有开销

什么是预算卡？不是花钱的限制，而是花钱的仪表盘。

它包含四个核心字段：

预算卡的结构（Markdown 模板）

## 预算卡

– 任务名称：auto_research_weekly

– 预算上限：20000 tokens

– 已消耗：6420 tokens（32.1%）

– 剩余配额：13580 tokens

– 熔断阈值：18000 tokens（90%）

– 当前状态：✅ 运行中

– 预估完成：还需约 8000 tokens，可安全完成

这张卡的关键不是"记录花了多少"，而是每次调用前后都查询剩余量。当 spent_so_far 接近 circuit_breaker 阈值时，强制终止当前任务，返回已有结果。

三、三层熔断机制

光有卡不够，要有自动熔断的逻辑。我设计了三层：

第一层：单步熔断

每次工具调用前，检查本次调用的预估成本。如果 spent_so_far + 本次预估 > budget_limit，跳过该工具调用，返回错误提示。

实现方式：在工具调用函数入口加入 cost 预估逻辑。预估来源可以是 LLM 自身的 token 计数，也可以是调用方预先声明的成本上限。来源：【未核实】。

第二层：轮次熔断

每完成一轮 Agent 循环（思考→调用→观察），更新 spent_so_far。如果超过阈值，立即终止，并将剩余上下文摘要返回给用户。

这一层的意义是：宁可返回不完整的答案，也不要耗尽预算。

第三层：全局熔断

当多个任务并行运行时，维护一个全局 total_spent 计数器。任何单任务触发熔断后，检查全局状态，如果全局也接近上限，则暂停新任务的启动。

实际案例：我的生产环境曾经同时跑三个调研任务。其中一个触发了单步熔断，另外两个还在继续。全局熔断层在第三分钟介入，暂停了新任务并让正在运行的两个完成任务后退出。总消耗控制在预算的 85%，避免了超支事故。来源：内部实盘记录，2026-10-26，编号【未核实】。

四、预算卡 vs 无预算控制：一次对比实验

数据来源：同一套 Agent 系统，在两周周期内的对比测试结果。实验期间控制变量：相同任务集、相同 LLM 模型、相同工具链。唯一差异：是否启用预算卡。来源：内部测试记录，2026-10-27，编号【未核实】。

结果很直观：预算卡把不可控的支出变成了可预测的运营。

五、预算卡的局限与边界

局限一：预估算不准

成本预估依赖对 LLM 行为的经验判断，而 LLM 本身具有不确定性。有时候一个看似简单的工具调用，可能产生意外的长输出。

应对策略：不要在预估上死磕，而是在熔断阈值上留余量。建议将熔断阈值设为预算上限的 80%-90%，给意外留出缓冲空间。

局限二：上下文历史不可压缩

预算管理管的是"流入量"，但上下文历史的累积是一个独立问题。即使你严格控制了每次调用的成本，历史对话本身仍在膨胀。

应对策略：配合「压缩卡」（压缩上下文历史的工具）使用。在触发熔断前，先尝试对历史上下文进行摘要压缩，释放 token 空间。这属于进阶话题，留待后续文章展开。

局限三：业务价值与成本的权衡

有时候，多花点钱换来更准确的结果，是值得的。预算卡的目的是防止失控，而不是压低每一分钱。

正确姿势：给不同任务设定不同预算等级。高优先级任务给宽松预算，低优先级任务给紧缩预算。不要一刀切。

六、落地建议：三步走

第一步：加卡片

在你的 Agent 系统里，为每个任务实例附加一张预算卡。格式参考上面的 Markdown 模板，字段用代码对象实现即可。

第二步：加监控

在每次工具调用前后，记录 spent_so_far 的变化量。这些日志是你后续优化预算参数的依据。

注意：日志本身也要控制大小。不要把所有 token 明细都记下来，只记汇总数字即可。来源：【未核实】。

第三步：调阈值

先用默认阈值跑一周，看实际消耗分布。然后根据分布情况调整 budget_limit 和 circuit_breaker 的位置。目标是不触发熔断、也不留太多余量——找到那个平衡点。

七、系列结语

续接卡让我学会了"断了怎么接"，观测卡让我学会了"跑着怎么看"，预算卡让我学会了"花多了怎么停"。

三张卡，三种能力，一个完整的服务运维框架：

• 稳（续接卡）—— 系统不断
• 看（观测卡）—— 过程透明
• 省（预算卡）—— 成本可控

如果你正在搭建或维护一个 Agent 系统，这三张卡值得你花十分钟配好。它们不会让你的 Agent 变聪明，但会让你的 Agent 变得可控。

可控，才是稳定的开始。