1. 事故现场一通普通的Agent任务账单却像在烧钱1.1 事故还原从简单任务到天价账单先说结论上个月我跑了一个听起来特别简单的Agent任务——让Agent去调研三个竞品的技术架构然后输出一份对比报告。预估最多几美元结果月底拉账单一看光这个任务就烧掉了差不多400美元。按任务实际运行时长来算高峰期每分钟接近10块钱人民币的成本而且大部分钱花在了我完全看不见的地方。这不是模型贵的问题而是整条Agent链路在漏钱。当时我用的平台支持多步骤编排Agent会自己规划任务、调用搜索工具、读取网页内容、反复推理、最终汇总。表面上看它每一步都走得很正常日志也没报错输出质量甚至还挺好。但恰恰是这种正常让成本问题被完美隐藏了。很多朋友对Agent平台的成本没有概念觉得不就是调几次API嘛。实际情况是一个Agent任务尤其是多工具、多步骤、带记忆的长任务Token消耗量是单次Chat对话的几十倍甚至上百倍。我这里不是危言耸听后面会把这个账单拆开给你看。1.2 数字震惊每分钟10块钱是怎么算出来的先做一个简单的算术题。以某个主流旗舰模型为例输入价格大约每百万Token 30美元输出价格每百万Token 60美元。一个Agent任务往往会经历规划→搜索→阅读→推理→再搜索→再推理→输出的长链条每一轮工具调用都要把前面全部的历史记录重新发给模型。假设一次任务中上下文从几千Token膨胀到5万TokenAgent循环了20轮每轮都带着完整的5万Token历史去调用模型那么单轮输入就是5万Token20轮下来光输入就是100万Token。这一项成本就是30美元折合人民币200多块。如果中间还穿插多次输出输出Token再累积2~3万又是十几美元。算下来一个任务几十美元很轻松折合到运行时长平均每分钟烧掉10块人民币完全不是夸张。关键问题在于这些Token消耗不是一次性的而是每一轮循环都在重复支付。你在界面上看到的是Agent思考了一会儿背后其实是整段历史记录被反复计费。这个机制不搞清楚换哪个平台都照样漏钱。2. 钱到底烧在哪Agent平台的五大隐形成本黑洞2.1 黑洞一上下文滚雪球历史消息无限膨胀这是最隐蔽、也最烧钱的一个点。刚开始接触Agent开发时我习惯把所有对话历史原封不动地传给模型觉得保留完整上下文Agent才能记得住前面做了什么。结果就是上下文像滚雪球一样越滚越大。举个例子Agent第一轮读了一篇3000字的网页第二轮搜索到5条结果第三轮开始写结论。如果你每轮都把原始网页全文5条搜索结果中间推理过程全部塞给模型到第五轮时上下文可能已经冲到2万Token以上。整个任务跑完20轮历史记录越堆越多可真正对最终决策有用的可能只有10%。这就是典型的用钱买记忆。模型确实什么都能看到但它每看一遍你就要付一遍钱。我之前见过一个团队把搜索引擎返回的整页HTML直接喂给Agent一个任务跑下来仅输入Token就消耗了300多万。这个习惯不纠正优化其他部分都是白搭。2.2 黑洞二重试与循环失控一次失败成本翻倍第二个坑是重试机制。Agent在调用外部工具时经常遇到超时、返回格式不对、解析报错这类问题。很多平台的默认策略是失败自动重试而且重试次数设得还不低。有一次我的Agent调一个网页抓取工具那个网站的响应特别慢连续超时了3次每次超时等待30秒然后重新发起请求。这还不算完每次重试之前Agent还要反思一下把失败原因、猜测、下一步计划全部写进上下文。于是本来一次能完成的操作变成了调用→失败→反思→再调用→再失败→再反思。每多一次重试成本和耗时都成倍往上翻而这一切都发生在你看不见的后台。最坑的是有些平台的自动修复逻辑会反复尝试同一类错误。比如某个工具返回的JSON字段名和你预设的不一致Agent每次都会按同一个错误模板去反思永远得不到正确答案却一直在支付推理费用。这就是一个无限循环烧钱机。2.3 黑洞三工具调用的空转成本第三个黑洞是工具调用本身。现在主流的Agent框架都内置了工具选择机制模型可以自主决定调用哪些工具、按什么顺序调。这看起来很灵活但也意味着模型经常做一些无效动作。我实测过在一次竞品调研任务中Agent连续三次调用了同样的搜索接口只因为第一次返回结果里没有它想要的价格信息。它没有选择用已有结果做推断而是选择一遍又一遍地重新搜索。每次搜索都要把工具描述、参数说明、搜索历史重新发给模型算下来一次空转搜索的成本足够我手动跑十次同类搜索。还有一类更隐蔽的空转模型为了确保准确会把一个明明可以拆成两步的任务拆成十步每步都调一次工具每步都带着全部历史重新计费。表面上看起来Agent很勤劳实际上每一份勤劳都在转化成账单上的数字。2.4 黑洞四模型选型杀鸡用牛刀不少平台默认把所有任务都路由给最强模型不管任务是简单的文本提取还是复杂的多步推理。这就像用搬家卡车去运一箱牛奶能到但成本离谱。具体来说我踩过的坑是在一套Agent流程里让旗舰模型去执行从网页中提取发布日期这种纯规则操作。一次两次没感觉但Agent一个任务可能执行几十次类似操作累积下来就非常可观。后来我把这类简单任务切成子任务路由给便宜的小模型成本直接降了一个数量级。很多刚接触Agent的朋友会有个误区觉得越强的模型Agent能力越强。这话没错但能力强的模型用在简单环节上并不会让简单环节的产出更好只会让你的钱包更瘪。合理的做法是把任务拆成简单环节和复杂环节分别路由给不同档位的模型。2.5 黑洞五日志、中间产物与Prompt的隐性消耗最后一个坑可能很多人到现在都没意识到系统提示词System Prompt和日志记录也在持续烧钱。我之前在一个Agent平台上做开发系统提示词写得特别长把所有工具的使用说明、限制条件、示例全部塞进去。这个Prompt本身可能就有3000多Token而且每一轮调用都要带上它。20轮下来光是系统提示词就贡献了6万Token的消耗。如果Prompt里还包含工具返回的完整文档、上一步的完整输出、各种调试信息那消耗就更夸张了。还有一类隐性消耗来自调试输出。有些框架在开发模式下会在上下文中插入大量调试信息比如正在调用工具X参数为Y工具X返回状态码200。这些信息对排查问题有用但对最终结果没有任何帮助。上线前如果不把这些东西从Prompt里清掉它们就会变成永久的成本负担。3. 事故复盘我是怎么一步步定位到成本黑洞的3.1 第一步账单拆分锁定消耗大头发现账单异常后我做的第一件事不是改代码而是把平台的费用明细导出来按任务和按时间维度拆分。这一步非常关键因为表面上看起来每个任务都只要几美元但如果你按小时聚合会发现某些时段的任务密集触发成本瞬间拉高。我用的方法是在平台后台导出所有API调用的计量数据包括每次调用的模型、输入Token数、输出Token数、时间戳和任务ID。拿到这份数据后先用脚本按任务ID汇总算出每个任务的累计Token消耗再按时间段聚合找出成本尖峰出现的具体时段。这一步做完我立刻发现两个异常一是某个调研任务的消耗是其他任务的5倍以上二是在任务运行的某个20分钟窗口里Token消耗速率异常高正好对应了每分钟10块钱的那个峰值。有了这个定位后面就好追查了。如果你用的平台不提供明细导出也不要偷懒。至少要做到在代码里给每次API调用加上日志记录模型、Token数和任务ID。否则等账单出来后你根本无从下手。我后来专门写了个轻量级的Token记录中间件每笔调用都会落一条日志到本地文件成本可追溯是这个领域的第一铁律。3.2 第二步日志审计还原完整调用链路定位到具体任务后我开始还原这个任务的完整调用链路也就是把每次模型调用之前发生了什么、之后返回了什么全部捋一遍。这里推荐一个习惯给Agent框架加上结构化日志每次工具调用都记录输入参数摘要、返回结果长度、是否重试、触发原因。不要记全量内容只记摘要就够了否则日志本身也会变成成本黑洞。我通过日志发现问题最大的环节出在网页内容读取上。Agent每搜索一次就会尝试读取搜索结果里的前两个链接的全文。这些网页动辄几千上万字而且Agent读取完之后并没有真正用到多少。更糟的是每次读取完网页它还会把页面正文完整地保留在上下文里继续参与后续所有轮次的推理。这个发现让我很震惊一个调研任务里可能有60%的Token消耗都用在了读取网页正文这件事上而真正有价值的产出只占那点Token里的一小部分。日志审计的价值就在这里你不去看每一步的实际消耗永远不知道钱是怎么没的。3.3 第三步Token剂量分析量化各个环节的消耗占比最后一步我把一个完整任务的Token消耗按环节拆开算出了各环节的占比。这里给出一组我实测的数据非常有参考意义。在我那个竞品调研任务里完整跑完后的Token消耗结构大致是系统提示词与基础框架占12%工具选择和任务规划占18%搜索调用与结果处理占15%网页正文读取占42%最终报告生成占13%。你可以看到网页正文读取这一项超过了报告生成的三倍还多。算到这我就明白了这个任务的优化空间根本不在生成报告这个环节而在于如何让Agent少读网页、读更有用的网页、读了以后不把全文留在上下文里。Token剂量分析的价值就是让你从感觉哪里贵变成明确知道哪里贵然后针对性地下药。4. 止血与优化一套立竿见影的成本控制方案4.1 模型分层让每一分钱花在刀刃上第一个优化动作是把所有任务按复杂度拆成三个档位轻量任务、中等任务、复杂任务。轻量任务包括文本提取、关键词识别、格式转换直接用便宜的小模型中等任务包括总结、分类、单轮推理用性价比款模型复杂任务才轮到旗舰模型比如多步规划、长文分析、代码生成。实操时要注意路由判断本身也要有策略。我用的方案是先让规则引擎根据任务类型做硬路由比如凡是fetch网页后提取标题、发布时间的操作直接走轻量模型如果任务里明确包含对比分析给出方案这类动词才路由到复杂模型。还有一种更聪明的做法是动态路由先让模型自己判断复杂度但这会多一次调用在小成本优化场景里并不划算。做完模型分层之后我这个调研任务的整体Token费用直接降了约50%。因为最贵的部分——网页正文处理——全部走便宜模型了旗舰模型只负责最后汇总和推理。4.2 上下文治理压缩、截断、摘要三板斧第二个优化也是效果最明显的是对上下文做治理。核心思路就一句话不让Agent拿着一个膨胀到离谱的历史记录去做每一步决策。压缩是第一步。我写了一个上下文裁剪模块在每个Agent循环结束之后把历史记录中超过一定长度的工具返回内容替换成摘要。比如网页正文本来有8000字读取完成并提取关键信息后就把它替换成一段200字的摘要然后继续参与后续循环。这样既保留了关键信息又大幅降低了后续轮次的Token消耗。截断是第二步。针对那些只对当前步骤有用、对未来没有参考价值的内容比如搜索结果的原始列表、中间调试信息直接不写入长期上下文。实现方式很粗暴在把消息送入下一轮之前按消息类型做过滤只保留推理结论工具结果摘要用户目标三类内容。摘要则是第三步。对于必须保留的长文本我会定期触发一次历史摘要生成让模型把前面N轮的对话压缩成一个结构化的状态描述然后用这个描述替换掉原始历史。这一步也能顺带提升长任务的质量因为模型不会被大量无关细节干扰。这三板斧做完同类型任务的Token消耗直接降到了原来的三分之一。最明显的体验是任务结束时的账单从吓人变成了可以接受。4.3 重试策略与熔断机制停止无效的自我修复第三个优化是针对重试和循环失控的。现在我的所有Agent任务重试策略统一改成最多重试1次且重试前必须改变策略。这个规则是我在踩了很多次坑之后总结出来的。具体做法是每次调用外部工具之前先把上一次失败的原因传入Prompt并且明确要求模型不得使用与上次相同的参数和方式重试。如果第二次仍然失败直接放弃该子任务进入降级流程——要么跳过这一步要么用默认值代替要么把问题标记为需要人工介入。另外我给所有长任务加了一个循环熔断机制如果Agent在某个子任务上循环超过5轮或者连续3轮产出的结论没有实质变化就强制终止这个分支并输出当前已获得的最佳结果。不要小看这个机制它在跑长任务时是真正的救火队员能拦住大量无意义的口袋支出。4.4 预算告警与配额管理在失控之前喊停最后一道防线是预算告警和配额管理。我现在的做法很简单每个任务启动前先根据任务类型估算一个Token预算比如这个竞品调研任务预算是15万Token约合人民币70块。然后在每次调用之后用累计Token数和预算做对比如果超过预算的80%就让Agent进入省电模式——只保留必要调用关闭所有非关键工具甚至主动缩短最终报告的长度。这里还有一个很实用的技巧给Agent设置任务时间戳级别的告警阈值。在代码里实现一个计数器按任务维度统计Token消耗每消耗1万Token就输出一条进度日志。不要小看这个动作它让我能实时看到成本增长的趋势而不是月底才知道自己烧了多少。平台自带的预算限制功能也要用上。主流Agent平台一般都支持设置单任务Token上限和日消耗上限上线前一定要配好。我曾经见过一个团队没配这个一个失控的Agent任务连跑了几个小时账单出来的时候整个季度预算都没了。5. 常见问题与排查技巧实录5.1 常见问题速查表我把调试Agent平台成本问题时遇到的高频问题整理成了一张速查表方便大家直接对照排查。现象大概率原因快速排查方法止损动作单任务Token消耗异常大上下文未做压缩历史无限膨胀查看每轮调用前的Token数变化加入摘要替换与消息过滤耗时翻倍但产出没变重试次数过多且策略不变搜索日志中的重试关键字限制重试次数强制变更策略工具调用次数远高于预期模型自主规划时拆分过细统计单任务内工具调用次数限制工具选择范围关闭低频工具简单任务也走旗舰模型路由规则未做分级查看每笔调用的模型版本按任务类型做模型分层系统Prompt过长导致每轮都烧Prompt内塞了太多说明与示例统计每笔调用的Prompt Token精简Prompt把长说明移到工具手册长任务跑到后半段越来越慢上下文累计导致计算量上升监控后半段Token输入量阶段性生成历史摘要并替换5.2 独家避坑技巧第一条上线之前一定要跑一次成本预演。做法是选一个典型任务开着Token统计跑一遍完整流程记录总消耗和各环节占比。我就是在预演里发现某些看起来不起眼的子任务摊到整个流程里成本占比高得吓人。预演出问题比上线后出问题好处理一百倍。第二条警惕免费工具的隐性成本。很多Agent平台上集成的工具比如搜索引擎、网页抓取器本身是免费的。但它们返回的内容会以Token的形态计入模型上下文这部分成本全部挂在你账上。所以选工具的时候建议优先选返回结构化摘要而不是返回全文的工具。如果只能用全文工具那就一定要在读取后立刻做摘要替换别让全文留在上下文里。第三条定期拉一次成本体检报告。我每个月底都会把当月所有Agent任务的Token消耗按类型汇总和上月做对比看看哪些任务变贵了、哪些环节的占比在上升。这个习惯能让你在成本失控之前就发现苗头。平台通常自带统计报表但维度往往不够细建议自己在代码侧埋点拿到一手数据。第四条给Agent任务加预算字段。所有任务在创建时都带一个预算上限就像给项目设定费用红线超出就自动触发降级流程。这招看着简单但能拦住大多数动态成本失控的场景。6. 写在最后成本意识应该长在架构里这次事故复盘到最后我最深的体会是Agent平台的成本问题不是靠事后查账单解决的而是要把成本意识从一开始就埋进架构里。我自己理顺之后现在新写的每个Agent任务都默认带上这么几个组件Token计量中间件、上下文治理模块、重试熔断开关、模型路由器和预算告警器。这套东西加起来可能一天的工作量但它能全年无休地替你把钱盯住。还有一个小技巧分享一下我在做上下文摘要的时候会把摘要生成本身也纳入Token计量因为这个操作虽然消耗不大但做得太频繁也会有累积效应。我的做法是每5轮才触发一次摘要而不是每轮都做。这样既保住了上下文的精简又不会为了省钱反而多花钱。最后想跟所有做Agent开发的朋友说一句话Agent能力再强也扛不住成本失控。把这个维度纳入每一次架构讨论和技术选型你写出来的东西才真正能在生产环境里活着而且活得久。别等账单出来再惊讶那时候什么都晚了。
