很多团队看模型报价表，会产生一个错觉：API 单价降了，Agent 成本也该跟着降。
实际账单经常不是这么走的。尤其是客服、代码助手、数据分析这类长链路 Agent，一旦接入多轮对话、检索、工具调用和纠错，Token 消耗很容易从“单次请求成本”变成“整条链路成本”。价格表上便宜的是每个 Token，账单里贵的是被反复发送、反复推理、反复重试的 Token。
张文鈿在 Facebook 上转述过一个判断：常听到“模型每年会便宜 10 倍”，但便宜的往往是旧模型。新模型发布后，如果它成为 SOTA，大量需求会立刻迁移过去；前沿模型的价格并不会因为旧模型降价而同步消失。更关键的是，Token 单价不等于总价。Agent 用了更强模型、更长上下文、更复杂推理链，总账单仍然可能上升。
这也是很多开发者困惑的地方：明明 LLM 在降价，为什么产品里的 AI 成本没降？答案通常不在模型厂商的报价页，而在 Agent 的调用链路里。
Token 是怎么被链路放大的
单次聊天请求还比较好算：输入多少、输出多少，后台账单大致能看懂。
Agent 不一样。一个常见的业务 Agent，可能先由调度器判断意图，再调用检索模块查知识库，接着把候选内容交给另一个模型整理，最后再生成回复。如果结果不满意，还会进入纠错或重试。每一步都可能重新携带历史消息、系统提示词、工具说明和中间结果。
麻烦就在这里：上下文不是只传一次。它会在节点之间被复制、扩写、再包装。
比如同一段用户历史，在意图识别里出现一次，在检索改写里出现一次，在答案生成里又出现一次。如果框架默认全量透传历史消息，Agent 越多，重复 Token 越多。账单看起来像是“模型贵”，实际可能是上下文管理粗糙。
虎嗅网转载的集智俱乐部文章讨论过一篇论文：《How Do AI Agents Spend Your Money? Analyzing and Predicting Token Consumption in Agentic Coding Tasks》。论文发布在 arXiv，时间是 2026 年 4 月 24 日，研究对象是 Agentic Coding Tasks。这个问题问得很直接：Agent 到底是怎么花掉你的钱的？
对开发者来说，这个问题比“哪个模型更便宜”更有操作价值。因为在 Agent 系统里，同一个任务的 Token 消耗，既受模型影响，也受框架、提示词、工具设计、重试策略影响。
推理模型多了一层“思考成本”
推理模型普及后，账单又多了一层不透明。
这类模型在给出最终答案前，会进行更长的内部推理。用户看到的输出可能不长，但模型实际消耗的 Token 不一定少。对需要规划、写代码、查错、比对方案的 Agent 来说，这种“先想一大圈”的能力很有用；但如果任务本身并不复杂，推理 Token 就可能变成额外成本。
新浪财经在 2026 年 6 月 4 日的一篇文章里提到，Northwestern、O2 AI Lab、Stanford 等机构的研究团队提出了 BAGEN（Budget-Aware Agents），把“预算意识”单独定义为一种 Agent 能力。文章里的结论很扎心：会做任务，不代表知道自己要花多少钱。
同篇文章还引用了两个极端案例：一家企业因为开通企业授权却忘了设用量上限，一个月烧掉 5 亿美元的 Claude 账单；Uber 的工程师只用 4 个月就烧光了全年的 AI 预算。案例很极端，但暴露的是同一个问题：Agent 如果没有预算边界，长链任务会把成本控制交给运气。
知乎上也有开发者讨论过类似现象：某些 Agent 在任务上消耗了高得多的 Token，效果却未必明显更好。这里不能简单归因于“模型好坏”，更像是模型行为习惯不同。有的模型倾向于多走几步、多试几种路径；有的模型更直接。前者在复杂任务上可能有优势，在普通任务上就可能只是贵。
固定订阅为什么越来越难扛
歸藏（guizang.ai）在 X 上提到过一个判断：AI Agent 时代，任何“固定费率 + 高 Token 消耗”的订阅模式都难以为继。他还把 Cursor 涨价、Claude Code 涨价放在同一个背景下看：LLM 单价在降，但综合使用成本可能在变贵。
这解释了为什么很多 AI 产品一开始愿意做包月，后来又开始限量、分层、调价。只要用户把 Agent 当成自动化劳动力使用，调用次数和上下文长度就很难稳定。固定订阅面对高 Token 消耗，很容易变成平台和重度用户之间的成本拉扯。
对企业内部团队也一样。预算不是按“模型降价预期”花的，而是按真实调用链路花的。一个没有限制的重试循环，一个默认携带全量历史的节点，一个过长的 system prompt，都可能比模型单价更影响账单。
先别急着换模型，先把账单拆开
优化 Agent 成本，第一步不是换更便宜的模型，而是把账单拆到调用级别。
至少要记录这些字段：哪个 Agent 发起调用、用了哪个模型、输入 Token、输出 Token、是否有推理 Token、会话 ID、工具调用次数、重试次数。只看 API 后台的总 Token 数，像只看总电费，不看空调、冰箱、服务器分别耗了多少。
拆开后，常见问题会很快浮出来：
- 检索 Agent 每次都带完整历史消息；
- 多个节点重复发送同一段系统提示词；
- 纠错循环没有上限；
- 工具调用失败后自动重试，但没有判断失败原因；
- 长对话没有摘要，也没有截断策略；
- 低价值任务用了高推理成本模型。
这些问题不需要等模型厂商继续降价才能解决。它们属于工程设计问题。
缓存、截断和预算上限，比口号管用
Agent 成本优化可以从几个小动作开始。
先做上下文截断。不是所有历史都值得带进下一轮。客服场景里，最近几轮对话通常比很久之前的寒暄更重要；代码场景里，相关文件和错误栈比完整聊天记录更重要。把“全量历史”改成“必要历史 + 摘要 + 当前任务”，往往比换模型更直接。
再做缓存。重复出现的系统提示词、工具说明、知识库片段、固定背景信息，不应该每次都原样塞进模型。能在应用层缓存的，就不要让它一遍遍进入计费上下文。不同平台对缓存支持不同，即使用不上模型侧缓存，也可以先在业务层减少重复拼接。
还要限制重试。Agent 最烧钱的状态，往往不是正常回答，而是卡在失败循环里：工具调用失败、格式校验失败、答案不满意，然后继续请求模型“再试一次”。重试可以保留，但要有次数上限、失败分类和人工兜底。
最后是预算上限。BAGEN 这类研究把“预算意识”单独拿出来，是因为 Agent 本身不会天然替你省钱。产品侧需要给任务设成本边界：超过多少 Token 停止、超过多少轮转人工、低价值任务切到便宜模型、高价值任务才允许调用前沿模型。
框架默认值也会影响账单
很多团队选 Agent 框架时，先看插件数量、可视化编排、模型接入是否方便。这些当然重要，但还不够。
更该看的，是框架怎么处理上下文：节点之间是否默认全量透传？历史消息有没有摘要机制？工具调用失败后会不会自动重试？是否方便插入缓存、日志和预算控制？
如果一个框架默认把所有历史消息、检索结果和中间推理都传给每个节点，后面再怎么抠模型单价，账单也很难好看。Agent 的成本，很多时候在架构层就已经被决定了一半。
模型降价仍然是好事，但它救不了粗放的 Agent 链路。真正要盯的不是“每 Token 多少钱”，而是“完成一个任务到底花了多少 Token”。
把账单拆细，砍掉重复上下文，限制重试，给任务设预算，再决定哪些环节值得用前沿模型。这样做不性感，但比等下一轮降价更可靠。
