为什么你的模型账单每个月都在悄悄地涨
Agent 的计费方式和聊天机器人不一样。心跳、越滚越大的上下文、重试、失效的缓存——每一项单次都近乎免费,一个月加起来就很贵。这篇讲钱到底花在了哪。
聊天机器人的账单很好理解:你发一条消息,你为一条消息付钱。Agent 的账单不是这样,而这个差别会以一种很具体的方式把人绊倒——数字每个月都在涨,明面上什么都没改,而且没有哪一条明细看起来是不对的。
原因是:Agent 在你没有敲键盘的时候也在花钱。
「单次调用成本」是个错误的单位
打开任何一家服务商的价格页,你会看到一个「每百万 token」的价格。乘上你一次典型对话的长度,得到一个小到可以忽略的数字。这个算术没错,但几乎没用——因为它假设「调用只在你要求的时候发生」。
真正能预测你账单的单位,是**「这个 Agent 单纯活着,每天花多少钱」**。一个单次调用只要几分之一分钱、但每五分钟就调一次、还没人看着的 Agent,是一份你并不知情就订下的订阅。每小时 12 次,每天 288 次,一个月大约 8600 次——而这还是在你没拿它干任何事的前提下。
换到这个单位上,四种常见的漏点就一目了然了。
漏点一:心跳与空转循环
很多 Agent 配置里都有一个周期性的 tick——检查新消息、轮询渠道、跑一个定时提示词、判断有没有事情要做。每一次 tick 都是一次模型调用,而这些调用通常都带着 Agent 的系统提示词和一部分上下文。
这是最让人意外的一个漏点,因为它的开销和你的使用量完全脱钩。你可以休假一周,花费照样以同样的速度往上走。如果你的账单不管你用得多还是少都差不多平,那你看到的就是这个。
该查什么: Agent 里所有基于时间间隔的配置——轮询频率、心跳、保活、定时检查。在判断「这个还好」之前,先乘上一个月的天数。
漏点二:越滚越大的上下文
第二个漏点更隐蔽,因为它看上去就是正常运作。输入 token 是按次计费的,而一个不断累积对话历史的 Agent,每一次发出去的输入都更多。
一个从 2000 token 上下文起步、在一次长时间工作中涨到 4 万 token 的会话,不是「在结尾时贵了二十倍」——而是「这个会话里剩下的每一次调用都贵了二十倍」。长期不做裁剪的会话是典型元凶;把大文档或整棵文件树「作为上下文」塞给 Agent、并在每一轮重发一遍,也是。
该查什么: 你的会话到底有没有上下文窗口策略——截断、摘要,或者干脆定期重置。一个已经开了三周的会话是个成本问题,不管它变得多好用。
漏点三:重试与死循环
Agent 会重试。工具调用失败了,模型再试一次;返回格式不对,重新请求一遍;一个 Agent 完不成的任务,可能会被反复尝试直到某个环节放弃。
每一次尝试都在计费。更糟的是,重试循环最容易在你没看着的时候触发——某个 API 从半夜开始返回错误、某个工具的凭据过期了、某个任务在某种微妙的意义上根本不可能完成。
该查什么: 日志里有没有反复出现的近乎相同的调用,以及你的 Agent 有没有重试上限。一个可以无限重试的 Agent,账单也是无上限的。
漏点四:你没注意到的缓存失效
服务商提供提示词缓存,它对重复的输入是一个很大的折扣——通常是「每次调用都为一段很长的系统提示词付全价」和「只付其中一小部分」之间的差别。
缓存也脆弱得很容易被忽视。它一般要求被缓存的前缀逐字节相同,并且在一个时间窗口内被复用。任何让提示词开头产生变化的东西——一个时间戳、一个会话 ID、一份顺序不稳定的动态工具清单——都可能悄悄让它失效。不会报错,你的成本只是回到了没有折扣的价位。
该查什么: 你的提示词开头附近有没有任何会变的东西,以及服务商的用量报告里缓存命中率是不是你预期的那个数。
为什么你总是很晚才发现
这四个漏点有一个共同性质:它们造成的是缓慢平滑的上升,而不是尖峰。不存在某个「明显坏掉」的时刻。而服务商的控制台主要展示的是你已经花掉的钱,这意味着最早的自然信号就是账单本身——等它来的时候,这个月已经过完了,钱也已经花了。
你真正需要的是一个外推:不是「你目前花了 34 美元」,而是「按当前速度,你这个月会以 210 美元收尾,而你的预算是 100」。这是同一份底层数据,但是完全不同的信息。前者是历史,后者是一个你还来得及做的决定。
这个算术不难——已花费用,除以已过天数,乘上当月总天数。它之所以没发生,是因为没人会在每个月 10 号想起来算一遍,而 10 号恰恰是唯一算了有用的那天。
具体该做什么
先去服务商那里设一个硬上限。 大多数服务商都支持月度消费上限或预算告警。这是唯一一个不会被你自己这边的配置失误撤销掉的控制手段,而且两分钟就能设好。不管你还打算做什么,先做这个。
审一遍所有的时间间隔。 找出每一个周期任务,问它是不是真的需要跑这么勤。从五分钟一次改成三十分钟一次,这一项就降了 83%,而对多数「看看有没有事」的用途来说,这不是有意义的损失。
给会话定个寿命。 截断、摘要,或者重置。无上限的上下文就是无上限的成本。
给重试封顶。 一个尝试次数上限,能把一次无界的失败变成有界的。
查一下缓存命中率。 如果你有一段很长的系统提示词却没有缓存命中,修好这一条通常是能拿到的最大单笔节省。
做外推,别做复盘。 不管你用什么工具,每个月值得回答的问题是「这样下去会落到哪」,而不是「已经花到哪了」。
最后这一条正是 GambaOS 里有成本管家的原因:你设一个月度预算,它按当前速度外推月末花费,并在你设的阈值上提醒你——那时候还剩着一个月可以改点什么。这份清单上其余的事,你今天就可以手工做一遍,而且你大概真该做一遍。