Agent 跑着跑着账单失控：几个常见原因
数据截至 2026-07，价格与限额以各官网为准。
Agent 的账单失控，几乎从来不是”模型太贵”造成的，而是同一段上下文被重复送进模型很多次。单次调用的钱是可以估的，可怕的是循环次数、上下文长度、重试次数这三个量互相相乘——它们任何一个失控，账单都是按倍数走，不是按比例走。所以止血的正确方向不是换更便宜的模型，而是先找出哪一段在被反复重放。
有个很常见的误解：以为把主力模型换成便宜档位就能把成本压下来。这在纯问答场景大致成立，在 Agent 场景经常不成立，甚至会更贵——便宜模型一次做不对，Agent 就会多绕几轮，多绕的每一轮又要把越来越长的历史再送一遍。换模型是调”单价”，而失控的通常是”次数乘长度”这一项。下面按钱漏出去的口子逐条说。
一、循环没有硬性终止条件
Agent 相对普通调用最大的区别，就是它自己决定还要不要再来一轮。只要没有外部约束，“再检查一下""再搜一次确认”这种行为可以一直持续下去，而每一轮都是一次完整的付费调用。
最容易出问题的是带反馈环的任务：写代码→跑测试→失败→改代码→再跑。逻辑上很漂亮，但如果模型改不对，这个环不会自己停，它会一直在”我再试一次”里转。开发时你在旁边看着，转两圈就手动中断了；上线以后没人看着，它可能转到超时或者转到额度耗尽为止。
可落地的做法有几条：
- 给每个循环设最大轮次上限，不是为了让任务成功，是为了让失败以固定成本收场。上限到了就退出并留下现场，比无声地烧下去好。
- 同时设一个 token 预算上限，因为轮次相同、长度不同时消耗差得很远。两个闸门一起挂才拦得住。
- 检测原地打转。如果连续两轮的动作和参数几乎一样，说明它没有取得进展，继续下去多半只是重复付费，此时应该直接中断转人工。
- 区分”任务失败”和”预算耗尽”两种退出码，否则你在日志里根本分不清是能力不够还是被闸门拦下的。
这类循环控制在不同框架里的难易程度差别不小。第三方对比的普遍看法是，带反馈环的循环任务上 LangGraph 更占优势，CrewAI 技术上支持循环但调试比较痛苦——这是第三方实测口径，各项目能力以官方文档当前版本为准。
二、上下文滚雪球，每一步都把前面全带上
第二个大口子是上下文长度随步数增长。很多实现图省事，每一步都把完整历史（系统提示、全部工具调用记录、全部返回内容）原样拼进去。于是第一步送进去的是一小段，第十步送进去的可能是前九步的总和。
这里的关键是消耗不是线性增长的。步数每加一步，这一步的输入就比上一步更长，累计下来接近平方级。一个二十步的任务，光是”把历史重放”这件事就可能占掉大部分开销，而真正的新信息只有最后那几句。
控制上下文增长的手段：
- 明确区分”必须一直带着的”和”用完就能丢的”。任务目标、约束条件属于前者；某次工具调用的原始返回体大多属于后者。
- 中间结果落到状态里，而不是留在对话里。把结构化数据存进状态字典，下一步需要时再取需要的字段，比把整段对话滚下去省得多。
- 超过阈值就做一次压缩，把前面若干步压成一段结论再继续。压缩本身要花一次调用，但通常比继续背着全量历史便宜。
- 稳定前缀放在最前面。系统提示和长期不变的说明放在开头且不要频繁改动，这样才有机会命中缓存；一旦前缀中间某处变了，后面的缓存就整体失效。具体的缓存计费倍率以各家官方定价页为准。
把控制流显式画出来的框架在这件事上更好办——节点带什么进去是你写死的，不是模型自由发挥的。这也是第三方对比里认为 LangGraph 的 token 效率相对更好的主要原因，同一份口径里 AutoGen 的开销被认为最大。这个排序来自第三方对比而非官方基准，看看方向就好，别当成精确结论。
三、多 agent 互相对话，是最贵的协作方式
让若干个 agent 互相交谈来达成共识，在演示里非常有说服力，但它是所有协作范式里最费 token 的一种：每个 agent 发言前都要读一遍别人说过的话，人数越多、轮数越多，重复阅读量增长得越快。三个 agent 聊五轮，产生的实际调用量往往远超直觉。
这不是说对话式协作没价值。需要多方观点碰撞、需要辩论出结论的场景，它确实合适。但如果你的流程本质上是”研究→撰写→审核”这种线性流水线，用对话去实现就是在为不需要的协商付费——角色明确、顺序固定的流水线，用串行编排更省。
另外有一条选型信息值得放在这里：微软已把重心转向更大的 Agent Framework，AutoGen 的主要新功能开发停止、进入维护模式，仍有 bug 修复和安全补丁。有实践者据此认为 2026 年不宜把它作为新项目的起点。存量项目不必恐慌迁移，但新项目选型时应该知道这件事。相关取舍可以看多智能体框架怎么选和 CrewAI 的 Flows。
四、工具返回体原样塞回模型
这一条最容易被忽略，因为它在代码里只有一行。工具执行完拿到结果，直接把结果字符串塞进消息里返回给模型——如果这个结果是一个网页全文、一份完整的 JSON 响应、一段几千行的日志，那么你等于用真金白银让模型读了一遍它大概率用不上的内容，而且这段内容之后每一步都还会被重放。
处理办法很直接：
- 在返回给模型之前先裁剪。只回传模型做决策真正需要的字段，其余留在你自己的存储里。
- 给工具返回设长度上限，超长就截断并附一句”已截断，可按 X 方式取剩余部分”。
- 对搜索、抓取这类天然返回大块文本的工具，加一层摘要，用便宜档位的模型压缩后再交给主模型。
- 把大对象换成引用。返回一个 ID 或路径，需要时再按需读取具体片段。
五、失败与重试的成本是隐形叠加的
超时、限流、格式校验不通过，这些情况下的重试很少被算进成本估算里，但它们花的是实打实的钱。更麻烦的是几种叠加：SDK 层自带重试、你自己的业务层又包了一层重试、外层工作流失败后整个任务重跑——三层套起来，一次失败可能对应七八次实际计费调用。
需要做的是把重试摊开看清楚：确认每一层各自的重试次数，避免嵌套放大；对确定不会因重试而变好的错误（参数错误、鉴权失败）直接放弃而不是继续试；任务级重跑要从检查点续跑而不是从头再来，长流程尤其如此，Agent 的检查点与长任务续跑讲的就是这件事。
六、开发调试期本身就是一笔不小的账
上线前的调试阶段常被当成”不算钱”，但 Agent 调试的特点是每验证一次改动就要把整个流程跑一遍，一天跑几十遍很正常。这笔钱在项目早期占比可能比生产环境还高。
省这笔钱的办法不复杂：把工具调用的返回录下来做回放，调编排逻辑时不必真的再调一次外部服务；用便宜档位的模型跑通流程骨架，只在验证效果时切回主力模型；给开发环境单独一把密钥和单独的预算上限，免得调试把生产预算吃掉。
七、可能你根本不需要多智能体
最后一条属于架构层面的省钱。如果你的场景是单个 agent 调一两个工具，那么多智能体框架带来的编排开销、角色间的信息传递、额外的协调轮次，全都是不产生业务价值的成本。第三方实践者的普遍建议是，这类场景在 2026 年直接用 OpenAI Agents SDK 或 Anthropic Claude Agent SDK 往往是更快的路径。先确认自己真的需要多个 agent，再谈框架选型，可以看 Agent SDK 和多智能体框架怎么选。
八、把账真正量出来
上面这些原因，光看是找不出自己项目里到底哪条在漏钱的，得测。三个动作按顺序做：
- 在调用层统一埋点，每次请求记下所属任务、所属步骤、输入输出 token、是否命中缓存。没有这一层，后面都是猜。
- 按任务维度聚合，而不是按调用维度。你真正要知道的是”完成一个任务平均花多少”和”最贵的那个任务花了多少”，而不是总调用数。分布的尾部往往才是问题所在。
- 盯住每任务的调用次数和平均输入长度这两个指标。它们比总花费更早暴露问题——总花费上涨可能是量涨了，这两个指标上涨则说明结构出了问题。
具体埋点方式可以参考Token 统计怎么做和 API 成本怎么监控。
说清楚局限
有几点必须坦白。第一，本文引用的框架间效率排序来自第三方实战对比，不是官方基准测试，不同任务类型下结论可能翻转，各项目能力以官方文档当前版本为准。第二，本文刻意没有给任何具体的价格、倍率、节省百分比——这类数字随各家调价变动很快，写死了反而误导，要算钱请以你实际使用的服务商当前定价页为准。第三，上面这些做法都是在成本和效果之间做交换：压缩上下文可能丢信息，设轮次上限可能让本来能做成的任务提前退出，裁剪工具返回可能裁掉关键字段。哪种交换划算，取决于你的任务对失败的容忍度，没有通用答案。
小结
Agent 的账单是”轮次 × 上下文长度 × 重试次数”这个乘积撑起来的，换便宜模型只动了其中最小的一项。最先该查的是有没有无上限的循环，其次是上下文有没有每步全量重放，再次是工具返回体有没有原样塞回模型。多 agent 对话是最费的协作方式，只在真需要多方碰撞时才用；线性流程用串行编排，单 agent 场景可能连框架都不需要。所有判断都要建立在按任务维度的埋点数据上，凭感觉优化通常会优化错地方。