深夜十二点我提交了一个Agent任务想着第二天早上起来看结果。结果早上打开账单整个人直接清醒了——就跑了四个多小时烧掉两千多块。算下来差不多每分钟十块钱比打车还贵。我知道Agent平台调用大模型不便宜但没想到会贵到这种程度。更郁闷的是任务本身没跑出什么结果钱全耗在了一堆看不见的地方。这篇文章就当一次事故复盘。我会把账单里那些“隐形消耗”逐项拆开讲清楚包括token是怎么被吃掉的、工具调用为什么这么贵、上下文膨胀有多可怕以及我现在做Agent开发时用来“保命”的预算控制手段。不管你是在用云平台搭Agent还是自己写代码调API这篇都值得看完再动手。1. 事故现场账单是怎么在四个小时里爆掉的1.1 那个让我后背发凉的账单明细先说下背景。当时我在做一个数据处理类的Agent任务是从一批文档里抽取结构化信息然后按规则汇总成表格。按我的预估这活儿大概需要跑两小时调用大模型API的token消耗在一百万到两百万之间预算控制在两千以内应该够。结果实际跑完账单是三千七。我打开云平台的费用明细逐行对账发现大头根本不在“核心任务”上。真正的消耗分布是这样的消耗项目金额占比我原本预估主模型输入token23%35%主模型输出token18%40%工具调用与结果回传12%5%重试与异常恢复调用31%5%上下文整理与摘要重塑16%15%看到没重试和异常恢复占了将近三分之一这是我最没想到的。表面上看任务只跑了一轮实际上模型在后台悄悄重试了二十多次每次都带着一个越来越大的上下文窗口重新读一遍资料费用自然成倍往上翻。1.2 第一直觉排查时踩的坑账单爆掉之后我的第一反应是“是不是模型选太大了”。于是我把模型从旗舰版切换到了标准版重新跑了一遍小规模测试。结果单次调用成本确实降了但总费用还是高得离谱。后来才反应过来问题根本不在单价而在调用次数和上下文体积。这个排查方向错了浪费了我一个下午。真正应该看的是三个指标总调用次数、平均每次调用的token数、以及重试频率。如果这三个数字里有一个异常那你换什么模型都没用费用照样失控。我当时的平均调用token数是预估的三倍重试频率是预估的六倍这才是真相。2. 你的Agent平台到底把钱花在了哪些看不见的地方2.1 Token消耗是最显眼的黑洞但很少人算得准先说最直观的部分token。很多人以为token就是“输入字数加输出字数”其实完全不是。大模型API计费时系统提示词、工具定义、函数签名、历史对话记录、中间推理过程全都算token。尤其是现在很多Agent平台默认给你包装了一套复杂的系统提示词光这个可能就占了几千甚至上万token。每次调用都得把这些带上算下来就是一笔不小的固定开销。更坑的是有些平台会把“工具定义”和“工具返回值”都算进输入token。如果你的Agent挂了五六个工具每个工具的描述和参数schema写得很详细为了模型能正确调用确实得写详细那每次调用光工具定义就多出两三千token。这些消耗在单次测试时看不出什么但在循环执行里会被放大几十上百倍。我自己做过一次统计一个不算复杂的Agent系统提示词加工具定义加一轮对话历史基础输入就有一万二token。如果这个Agent需要跑二十轮才能完成一个任务那光“固定开销”就是二十四万token。很多人预估token消耗时根本不把这些算进去预算就是这么爆的。2.2 重试、循环和自我纠正才是真正的吞金兽如果你只是简单调用一次API费用其实很可控。但Agent和普通API调用的最大区别是它会循环。模型判断“当前结果不满足要求”之后会自己调整策略重新调用工具重新读文档重新生成答案。这个循环一旦进入死胡同就会变成无限自我纠正钱就哗哗地流。我那次事故里模型在一个数据格式转换的环节反复失败。它每次失败后的处理方式是把当前结果加上报错信息重新作为输入让模型再试一次。这听起来很合理但问题是报错信息一次比一次长上下文一次比一次膨胀导致每轮重试的成本其实在增长。到了第十几次重试时单次调用的token数已经是第一轮的三倍。还有个容易被忽略的环节是“反思模式”。很多Agent框架默认开启了自我反思和自我批评模型会主动审视自己的输出“哪里不够好”然后重写。这功能听起来很高端但对某些任务来说完全是浪费。有一次我测试一个只要从网页里提取标题的任务Agent硬是“反思”了五次每次都把全文重新处理一遍。我后来直接把反思轮数限制成一次费用立刻降了四成。2.3 模型选择背后的成本差异比你想象的大同样跑一个任务用不同模型的费用差距不是一两倍而是几十倍。举个例子某个旗舰版模型每百万输出token要六十美元而一个标准版模型只要十美元。如果你的任务只需要标准版就够那用旗舰版就是在纯烧钱。但这里有个容易踩的坑不是所有任务都能用便宜模型。我试过用标准模型做复杂推理结果它老是在中途“犯迷糊”最后触发大量重试综合算下来反而比旗舰版更贵。所以正确的做法不是“一律用便宜模型”而是按任务难度分层简单抽取和格式化用标准模型复杂推理和工具编排用旗舰模型然后再通过路由机制分派。另外还有一个成本差异来自供应商的定价策略。有的平台按输入输出分开计价有的平台把缓存命中和未命中分开计价。如果你完全不看定价文档就乱用很可能每百万token多花五到十美元还不知道钱去哪了。3. 核心细节拆解为什么真的会“每分钟烧十块钱”3.1 循环调用是怎么把费用滚雪球式放大的要理解“每分钟烧十块钱”得先看懂Agent的执行循环。一个比较典型的循环是模型接收任务 → 决定调用某工具 → 工具返回结果 → 模型把结果纳入上下文 → 继续决策 → 再调用工具 → ……直到模型认为任务完成。在这个循环里每一次迭代都要向模型发送全部上下文。这带来的直接后果是上下文长度随循环次数线性增长而计费也随上下文长度线性增长。两者叠加起来总费用就是循环次数的平方级增长。也就是说如果任务本来应该跑十轮但因为某种原因跑了三十轮那费用不是三倍而是九倍。我那次事故从日志里数了一下总共循环了六十二轮其中只有十七轮是在干活剩下四十五轮都在“重试、反思、纠错”。而有效循环消耗的token大约九十万无效循环消耗的token反而有一百六十万。三分之二的成本都花在了“没干成事”上这个比例你想不烧钱都难。3.2 上下文膨胀看不见的隐形杀手上下文膨胀是Agent费用失控里最隐蔽的因素。它不像重试那样容易从日志里发现因为每个循环都在正常执行每一步看起来都很有道理。但如果你把每一轮的token数打印出来看就能看到一条不断上升的曲线。膨胀主要来自三个方面。第一是工具返回的原始数据比如你让Agent读一个网页它把整个网页正文带回上下文第二是历史对话的完整保留每一轮都带着之前所有轮次的内容第三是模型自己生成的中间分析尤其是开了“思维链”或“详细推理”模式后输出token会爆炸式增长。解决上下文膨胀的标准做法是引入“摘要机制”每执行几轮就让模型把当前进度压缩成一段摘要之后只保留摘要而非完整历史。这个做法能省五成以上的token。代价是会丢失部分细节和上下文精度因此需要在压缩策略上做一些折中设计比如给关键信息单独存缓存摘要只管流程状态。3.3 工具调用的隐性成本一个函数也是钱工具调用本身是不直接计费的平台通常只按token计费但它带来的token开销非常可观。每个工具调用都会产生三段token消耗模型生成“调用决策”的token、工具定义反复随请求上传的token、工具返回结果再次进入上下文的token。举个例子我的Agent里有一个“查询数据库”的工具。工具定义里写明参数、返回格式、注意事项这部分约八百token。每次Agent决定调用它时模型要输出一段JSON格式的参数约两百token。然后数据库返回五十行结果约三千token。这三部分加起来一次工具调用的成本约为四千token。如果跑一百次就是四十万token。你光听着可能没感觉但乘以模型单价费用就非常可观了。还有一类更隐性的成本模型判断“需不需要调用工具”这件事本身也在消耗token。当你的工具列表里有十几个工具时模型每轮都要把所有工具名和描述过一遍然后挑选合适的那个。这个过程没法省唯一的优化路径是减少工具数量或者把工具按任务拆到不同的子Agent里让每个子Agent只面对少量工具。3.4 并行度和计费规则是怎么叠加出天价账单的很多Agent平台支持并行执行多个子任务。你可能觉得“反正模型是并发调用的总时间没变长费用也不会变多”。但这想法有个漏洞并行调用不会降低总token数它只是把相同数量的调用压缩在更短时间里完成。如果你的平台是按“生成token数”计费那并行与否总数一样但如果平台按“并发时长”或“实例运行时长”额外收费那并行可能直接让费用翻倍。另外一个容易忽略的点是“重放”机制。有些平台会在任务中断后自动重放整个日志把之前的所有调用重新执行一遍为了保证状态一致。这时候你不仅要为“重放掉的历史调用”付费还得为“重放后新产生的调用”付费。我那次事故里就有两次重放多烧了至少三十万token。平台的计费规则到底怎么写的在开始跑大批量任务前一定要读清楚。建议先跑一个小样本对比账单和你的估算确认没有隐藏收费项再放大规模。4. 实操经验防止Agent账单失控的四个保命设置4.1 预算限制和“熔断开关”怎么设才靠谱现在主流Agent平台基本都支持设置预算上限。我吃过亏后现在只要跑任务第一件事就是设两道保险总预算上限和单次调用上限。总预算用来看住全局单次调用用来看住单轮循环防止某一次调用异常膨胀直接打穿预算。具体怎么设我一般把总预算设为预估费用的1.5倍同时设置“连续N次调用超时/失败就自动熔断”。这个熔断规则很重要。很多平台的默认策略是“失败后延迟重试”但如果延迟时间不够或者重试次数没限制它就会变成无限重试。所以我自己的默认配置是连续失败三次就停止整个任务并向日志里写入一条告警。还有一个实用技巧给关键任务单独设一个“低预算快速模式”。在这个模式里因为模型被要求“不要过度分析、不要反复确认”所以每轮调用的token数会显著下降。代价是任务准确率可能会掉几个点但对于“先跑通、再优化”的阶段来说这个取舍非常值得。4.2 架构层省钱模型路由和上下文缓存搭配使用架构层面的省钱空间比平台设置更大。我现在做Agent时会强制拆分“执行模型”和“决策模型”。决策模型负责任务规划、工具选择和工作流调度通常用较强的推理模型执行模型只做具体的格式化、抽取、转写用便宜的小模型。这样单次任务的综合成本可以降一半以上。另外一定要利用上下文缓存。主流大模型平台基本都提供“提示词缓存”能力相同的系统提示词和工具定义如果内容一致在指定时间内重复使用会有很大折扣。代价是缓存未命中时写入缓存本身会增加一些费用但对于“固定系统提示词多次调用”的Agent场景来说缓存几乎是稳赚不赔的。我自己的一个固定做法是把系统提示词、工具定义、以及少部分高频参考文档全部放进缓存区然后在代码里确保这些内容的序列化结果完全一致连一个空格都不要变。这样缓存命中率能到九成以上平台账单里输入token的费用会明显好转。4.3 日志和监控你得知道钱是在哪个环节消失的只看最终账单是不够的因为账单只告诉你“总共花了多少”不会告诉你“哪个环节出了问题”。我自己现在会在Agent执行过程中把每一轮的token数和成本估算写入结构化日志。别嫌麻烦等到出问题的时候这份日志就是你的救命稻草。日志里至少要包含这几个字段轮次编号、调用模型、输入token、输出token、调用的工具、返回状态、累计成本。跑完后写一个小脚本汇总可以直接看出哪一轮消耗异常。相信我这个脚本一次性写好后面每次跑Agent都能用到非常值得投入时间。监控报警的阈值我也建议设低一点。比如“连续三轮输入token超过基线值”就告警或者“单轮调用成本超过预估上限”就暂停任务。宁可误报不要漏报。误报最多浪费你几分钟看一眼数据漏报直接就是一张天价账单。4.4 工具链选择开源本地模型能不能省钱如果你觉得云端API太贵也可以考虑自建模型本地部署。现在很多开源模型在普通任务上的表现已经能打平中端商业模型。对于数据脱敏要求高的场景本地部署几乎是唯一选择。不过本地部署也有坑。第一是显卡成本一张够用的显卡能买好几百万token的API调用额度第二是运维成本包括模型更新、并发压测、推理加速第三是效果差距开源模型的工具调用准确率往往低于商业闭源模型而这恰恰是Agent场景最核心的能力。一旦工具调用不准就会频繁重试成本又回去了。所以我的建议是不是所有Agent场景都适合本地部署。如果任务复杂度低、调用量大、对数据隐私要求高本地部署值得考虑如果任务是高复杂度推理或者花式工具编排老老实实用商业API加预算控制反而更稳。5. 常见问题速查表我在Agent成本踩坑路上的总结5.1 三个必查指标和对应的排查方向碰到费用异常我建议你按下面这个表格的顺序排查。不要一上来就怀疑“模型太贵”先看调用模式有没有问题。优先排查项正常范围异常特征常见原因总调用次数与任务步骤数量级一致远超步骤数重试循环、自我反思、重复调度平均单次token数与输入内容大小相关持续走高上下文膨胀、历史未裁剪工具调用占比低于30%高于50%工具设计过碎、模型“乱试”工具如果你在日志里发现这三项里有任何一项异常不要犹豫先暂停任务修完再跑。继续跑下去只会让账单在错误路径上越走越远。5.2 哪些“省钱技巧”我试过之后发现并不靠谱网上有不少人分享“省钱秘籍”我试过一些有些真的有效有些纯粹是误导。第一个不靠谱的是“用便宜模型代替一切”。前面也说了模型能力不够会导致重试爆炸综合费用更高。第二个不靠谱的是“把历史对话全部删掉只保留最近一条”。这样确实省token但Agent会忘记任务目标然后开始执行错误动作最后重试成本更高得不偿失。正确做法应该是“压缩历史而非删除历史”用摘要保留关键状态。第三个不靠谱的是“用正则或简单规则冻结Agent”。有的团队为了省钱把Agent的思考和决策环节全部砍掉只留下固定的规则模板。这完全抹掉了Agent的适应能力稍微遇到一点输入格式变化就崩。省钱的前提是保持任务成功率如果任务完成率从九成掉到五成那省下的token费用根本弥补不了重做人力的损失。还有一个容易忽略但非常有效的省钱点是睡觉前不要跑大批量任务尤其不要以“让它自己跑一夜”的心态提交。夜间出错没有任何人盯着一个简单的bug就能让Agent疯狂重试一整晚等到第二天上班账单已经没法看了。我那次两千多的教训就是“它自己跑了一夜”的产物。5.3 给刚开始做Agent开发的人三条忠告第一次做Agent成本控制的话我建议你把以下三条原则刻在脑子里。第一任何Agent平台给你展示的“单次调用成本预估”都不可信因为它默认你的Agent会按理想状态执行而真实世界永远有异常、重试、工具返回超时。你在估预算时至少按预估的三倍来留余地。第二成本控制要从项目第一天就做。等到平台账单爆了再回来优化架构你会发现自己已经被昂贵的调用记录绑住了重构成本远高于一开始就设计好。我那个事故项目最后重构了执行链路成本降到了原来的五分之一但中间交的学费已经够买一台不错的开发机了。第三用小样本先验证再放量。任何Agent任务上线前先拿三个样本数据跑完整流程盯一下每一轮调用的token记录确认没有异常循环后再扩大数据集。这个小步骤花费的时间不超过二十分钟但它能救回你的预算。6. 一次复盘带来的长期改变那次“每分钟烧十块钱”的事故之后我做了一个决定所有Agent项目跑批之前强制走一遍我自己写的“成本影响面检查”包括估算token消耗上限、设置双保险熔断、开启缓存、写结构化日志。这个检查现在已经成了我团队里的固定流程每个新项目进来第一步就是做它。我也养成了一个小习惯每次Agent跑完后随手扫一眼日志里的“累计调用次数”和“平均上下文token”两张曲线图。正常任务的曲线应该是一条平缓的坡如果看到指数式上扬那不用怀疑一定有什么逻辑在空转。这比等平台邮件来通知你“账单异常”要快得多。如果你现在正准备跑一个新Agent项目或者已经吃过账单的亏我建议你花半天时间把平台账单生成的逻辑彻底读一遍再对照我上面说的几个点做一次自查。这笔时间投入比任何优化技巧都值钱。最后再分享一个小经验吧别把Agent当成“免费劳动力”。它本质上是按用量付费的虚拟员工会加班、会犯错、会在没人看管的时候偷偷绕远路。你给它划清楚边界、设好预算和熔断它才是好用的工具你完全放养它那账单就是它留给你的“惊喜”。我以后宁可在开始前多花半小时做这些枯燥的配置也不愿意再在凌晨收到那种吓人的费用通知了。