这波 DeepSeek 涨价、各家免费窗口陆续关闭之后，越来越多跑智能体的人开始回头算账。但账一摊开，很多人发现问题跟想的不一样：账单里的大头，往往不是模型单价，而是自己配置里几个一直在悄悄漏钱的"漏点"。
BCG 有个说法挺扎心：你在账单上看到的"答案"，其实只占 token 成本的大约 5%，剩下 95% 都沉在水下——是智能体一遍遍重读上下文、反复调工具、来回重试花掉的。小红书换句话说，你付的很大一块不是"结果的钱"，是"过程的钱"。行业里流传过一个企业案例，智能体账单从 8000 一路飙到 12 万、再到 47 万，财务去问 IT，IT 说"模型就是这么贵"，去问业务，业务说"我们也没多用"。其实双方都没说谎，钱就是从中间的过程里漏掉的。
为什么智能体花钱是"非线性"的？跟聊天不一样，智能体每往前推一步，通常都要把已有的上下文整个再喂给模型一次。轮次越多，输入滚得越大，而输出 token 又普遍比输入贵 4 到 10 倍。小红书所以一个会"反复读、反复调、反复试"的智能体，账单是滚雪球式的，不是线性加的。有经验的开发者晒账单时都会把输入（Prompt）和输出（Completion）拆开看，两条曲线的走势往往完全不同，钱花在哪一段一眼就能对上。今日头条
那钱具体从哪漏？把最近各平台跑智能体的人反复吐槽的点归一下，基本就是三个：
漏点一：上下文越滚越长。把全部对话历史、一股脑读进来的文件每次都塞给模型，输入越滚越大。Claude 官方做过一个对照实验：同一个编码任务，熟练的老手直接定位目标文件、改完就走，新手一通乱搜、读了十几个根本不相关的文件，最后两边 token 消耗差了好几倍。小红书同一个活儿，会不会"挑着读"，成本能差出几倍。
漏点二：工具调用循环和重复重试。智能体每多一轮工具调用，就多一次完整计费。小红书一旦撞上反复重试、甚至死循环，token 是哗哗地烧。很多"一觉醒来账单爆了"的情况，就是夜里某个任务卡在循环里空转。微信公众号
漏点三：没必要的多智能体。每个 agent 各算各的账，成本翻倍起步。小红书但说句实在的，绝大多数场景根本用不上多 agent，不少人是为了"看起来高级"才上的。能用一条工作流解决的事，别拆成一群 agent。下面这张对比图把账算得很直白：单 Agent 是一份账单，多 Agent 是 N 份账单叠着来。
不过得先分清一件事：账单高不等于一定漏了。有人一个月实打实跑了 132.76 亿 token、总花费 1028.33 元，这是正常的高强度用量，不是漏。小红书高盛对各类代理工作负载做过测算，一个典型的编程代理每天大约消耗 700 万个 token，呼叫中心代理约 200 万，数据录入类能到 2500 万——常驻型智能体本来就是吃 token 的大户。微信公众号判断是不是漏，看一个信号就够了：如果单价正常、用法没明显变多，但总额就是失控往上冲，那多半是配置在漏，而不是模型在涨价。
确认是漏之后，堵的优先级建议这么排：
第一步，先把缓存用起来。提示词缓存、KV 缓存开起来，让重复的上下文别再重复计费。已经有开发者靠减少"缓存未命中"的 token，把成本压到普通方案的 40%，工具调用越密集的场景省得越明显。小红书
第二步，给上下文瘦身。只把这一轮真正要用的内容喂给模型，历史该压缩压缩、该丢丢，别什么都整包带上。
第三步，给循环上"闸"。设置最大轮次、超时自动停，别让一个卡住的任务无限烧下去。挂机跑任务之前，尤其要先把这个设好。
第四步，能工作流就别多 agent。把"真需要多个脑子"和"其实一条线就够"分清楚。
最后留几个可以持续盯的信号：缓存命中率有没有上去、单个任务的平均轮次有没有降下来、账单里输入和输出各占多少。现在社区里已经有开源的账单追踪工具，能把这些信号直接摊在一块屏上——命中率、重试率、单次调用成本、每轮平均工具调用数，哪个指标在漏一目了然。微信公众号
涨价是让你回头算账的理由，但不该是账单高的全部理由。先把自家这几个漏点堵上，再决定要不要换供应商，这笔账才算得明白。
