在 2026 年初,Anthropic 的工程团队在分析生产环境的 Agent 部署情况时,发现了一个令资深 AI 从业者都感到意外的模式:推理成本不仅仅是云端账单上的最大支出项目——它甚至吞噬了超过 85% 的企业 AI 总预算。罪魁祸首并非每个 Token 的价格(这一价格已大幅下降),而是 Agent 工作流所产生的海量 Token 吞吐量。
一个原本只需简单聊天机器人调用一次 LLM 就能完成的单一 Agent 任务,现在会触发 10 到 20 次连续的模型调用——包括规划、工具选择、执行、验证、错误恢复以及响应生成。当规模扩大时,这种算术逻辑会将原本可控的 API 成本演变成基础设施危机。
Agent 的倍增难题
AI Agent 的底层经济逻辑与标准 LLM 应用存在显著差异,大多数团队直到面对每月五位数的账单时,才真正意识到这一点。
聊天机器人与 Agent 的 Token 消耗对比:
| 任务类型 | LLM 调用次数 | 平均 Tokens/任务 | 成本 ($15/M tokens) |
|---|---|---|---|
| 简单聊天查询 | 1 | ~800 | $0.012 |
| 基础 RAG 流水线 | 2-3 | ~3,000 | $0.045 |
| 编程 Agent (修复 Bug) | 8-15 | ~18,000 | $0.27 |
| 研究 Agent (多步骤) | 12-20 | ~35,000 | $0.53 |
| 客服 Agent (复杂) | 5-10 | ~10,000 | $0.15 |
一个使用 Claude Sonnet 处理所有步骤且未做任何优化的客服工单解决 Agent,每项任务成本高达 $1.60。按此频率每月处理 10,000 张工单,仅 LLM 推理费用(不计入基础设施、监控和维护)就需要 $16,000。
隐藏的倍增因子加剧了这一问题:
- RAG 臃肿:检索了过多的上下文,导致上下文窗口中充斥着低相关性内容,这增加了成本却未能提升答案质量。
- 全天候监控:Agent 运行持续的背景检查,即使在低活动期间也在消耗算力,全天候 24/7 不间断。
- 工具调用开销:在重度使用工具的工作流中,一旦计入付费的 MCP 服务器、地理编码 API 和外部搜索费用,LLM 推理成本往往只占总任务成本的一半不到。
- 错误恢复循环:遇到故障的 Agent 会重新提示模型,有时会使单个任务的 Token 消耗翻倍。
2025 年上半年,企业 LLM 支出达到了 84 亿美元,近 40% 的企业每年在语言模型上的投入超过 25 万美元。那些率先进行优化的团队已经制定了一套系统性的操作手册,现正被其他团队纷纷效仿。
策略 1:模型路由——杠杆率最高的手段
目前最有效的优化手段是智能模型路由。前提很简单,但实施细节很关键:并非 Agent 工作流中的每个子任务都需要使用前沿模型的智能。
加州大学伯克利分校、Anyscale 和 Canva 的研究(发表于 ICLR 2025)表明,经过训练的路由系统(如 RouteLLM)可以在保持 GPT-4 95% 性能的同时,实现 85% 的成本削减。核心洞察在于,一个小型的分类器模型可以决定调用哪个模型池——将大部分流量路由到更小、更便宜的替代模型,而在这些任务上不会造成可感知的质量下降。
生产环境中的实用分层:
| 流量层级 | 查询类型 | 模型层级 | 成本/M tokens | 流量占比 |
|---|---|---|---|---|
| 第一层 | 简单分类、路由、格式化 | 小型 (<7B) | $0.10-0.50 | 70% |
| 第二层 | 中等推理、代码补全 | 中层 | $1-5 | 20% |
| 第三层 | 复杂推理、架构、规划 | 前沿 | $15-60 | 10% |
这种 70/20/10 的分布与单一模型架构相比,将平均每次查询的成本降低了 60-80%。在 2025-2026 年的企业部署记录中,智能路由将昂贵模型的流量减少了 75-90%,转而路由至成本低于每百万 Token $1 的模型。
一项被路由到前沿推理模型的任务,其成本可能比由快速小型模型处理同一任务高出 190 倍。在规模化场景下,这种价差并非微不足道的误差——它是产品盈利与 margins 被摧毁的区别。
随着价格通缩,优化的计算逻辑也发生了转变。LLM API 价格在 2025 年初至 2026 年初期间下降了约 80%,但 Agent 的复杂性扩展得更快。那些早期构建了路由架构的团队,现在即使任务复杂性增加,每个工作流支付的代价也仅为原来的一小部分。
策略 2:提示词缓存——消除冗余计算
每个 Agent 工作流都包含大量的重复操作。系统提示词、工具定义、安全指令和对话历史在每次调用时都会重新发送给模型——即使它们没有任何变化。提示词缓存可以在基础设施层面消除这种浪费。
工作原理: 缓存存储了先前计算的重复提示词前缀的键值注意力张量。当后续请求与缓存的前缀匹配时,模型会跳过重新计算,并以极低的成本提供缓存的激活值。
提供商定价(2026):
| 提供商 | 新鲜输入 | 缓存输入 | 折扣 |
|---|---|---|---|
| Anthropic (Claude) | $3.00/M | $0.30/M | 90% |
| OpenAI | 默认开启 | 50% 折扣 | 50% |
| Google (Gemini) | 变化 | 变化 | ~75% |
对于重度依赖工具的 Agent,系统提示词和工具定义可能占用每次请求 Token 预算的 40-60%,缓存这些前缀直接转化为成本节省。Redis LangCache 记录显示,在高重复性工作负载中成本可降低 高达 73%,且缓存命中返回时间为毫秒级,而新鲜推理则需要秒级。
2026 年初发表的关于“Agent 计划缓存”的研究将这一概念扩展到系统提示词之外,延伸至规划输出本身——即缓存可以在类似任务结构中重用的中间推理步骤。该方法在保持任务性能的同时,实现了 50.31% 的成本降低和 27.28% 的延迟改善。
实际影响因工作流类型而异:
- 编程 Agent:系统提示词和代码库上下文高度重复 → 节省 40-60%
- 客服 Agent:工具目录和政策文档在所有会话中重复 → 节省 30-50%
- 研究 Agent:前缀重复率较低,但多轮对话上下文累积受益于对话缓存 → 节省 20-35%
根据 Mavik Labs 2026 年的分析,结合语义缓存(匹配语义相似的查询)和预算感知路由,可在生产环境中实现 47% 的支出减少。
策略 3:上下文工程——遏制 RAG 臃肿
大多数团队最初处理上下文管理的方法是最大化上下文:尽可能发送相关信息,让模型去判断什么重要。这不仅昂贵,而且往往适得其反。
2026 年的上下文工程讲究的是 精准度,而非体量。
天真填充上下文的核心问题:
- 长上下文推理的成本是非线性增长的——上下文翻倍,成本往往增加两倍以上
- 当上下文包含过多噪音时,模型在任务上的精准度会下降
- RAG 流水线经常检索出高分但低相关性的文档,占用了 Token 预算却无助于提升答案质量
架构解决方案:
检索的固定 Token 预算:不要检索可变数量的文档,而是强制执行严格的预算(例如,检索上下文限制为 4,000 Tokens)。这会强制进行相关性优先排序,并防止上下文无限制增长。
xMemory 风格的分层检索:xMemory 的方法通过精确的自顶向下检索构建了一个更小、高度针对性的上下文窗口,将 Token 使用量从每个查询超过 9,000 个降至大约 4,700 个——仅在该组件上就实现了近 2 倍的推理成本削减。
观察记忆与 RAG 的对比:像 Mastra 的观察记忆这样的系统使用两个后台 Agent(观察者 Observer 和反思者 Reflector)将对话历史压缩为带日期的观察日志,而不是原始记录存储。这种方法在长上下文基准测试中得分为 84.23%,而 RAG 为 80.05%,同时使用的 Token 大幅减少——这是成本降低和质量提升难得一致的罕见案例。
提示词压缩:像 LLMLingua 这样的工具通过消除冗余来压缩提示词,同时保留语义内容,将上下文长度减少 20-50%,而质量几乎无下降。在规模化应用中,这与缓存和路由节省相辅相成,效果显著。
一位从业者记录到,通过结合 RAG 优化、提示词压缩和上下文修剪,将 LLM Token 成本降低了 90%——将生产环境的 Agent 从每次会话 100 多美元降至 10 美元以下。
复合效应:叠加优化
这些策略中的每一个都能带来独立的节省,但真正的杠杆作用来自于将它们组合起来:
| 优化手段 | 独立节省 |
|---|---|
| 模型路由 | 60-80% |
| 提示词缓存 | 40-90% |
| 上下文/RAG 优化 | 30-60% |
| 提示词压缩 | 20-50% |
| 组合(典型) | 净节省 60-80% |
交互效应是不可忽视的。提示词缓存在前缀稳定时效果最好——而上下文优化通过减少上下文变动实现了这一点。模型路由决策受益于知道缓存的 Token 很便宜,从而允许在少数缓存前缀调用中更激进地路由到大型模型。这些策略相互 reinforcement。
一个具体的例子:一个处理 50,000 次月度交互的客服 Agent,未经优化时成本为 $1.60/任务,总费用 $80,000/月。应用路由(将 70% 的简单意图分类路由到 $0.10/M 的模型)、提示词缓存(缓存系统提示词+工具目录)和上下文预算强制执行后,相同工作负载的运行成本为 $14,000-$22,000/月——减少了 72-83%。
新指标:超越 Token 支出
2026 年,最成熟的团队已不再将原始 Token 支出作为主要的 AI 成本指标。Token 支出是投入;业务价值是产出。新兴的治理框架转向效率比率:
已解决工单成本:在没有人工升级的情况下完全解决一个客户问题需要多少 LLM 推理(和工具成本)?在跟踪成本的同时跟踪质量。
人工等效时薪:与被其替代的人工角色相比,Agent 劳动的有效小时成本是多少?以财务团队理解的术语来描述 AI 支出。
每次 AI 工作流的收入:对于产生收入的 Agent(销售、追加销售),工作流返回的价值是否超过了其在推理成本上的消耗?
任务完成成本比:将 LLM 支出除以成功完成的任务数量。比率下降意味着每美元完成的任务更多;比率上升则表示失败率增加或上下文臃肿。
这些指标并不取代 Token 跟踪——它们为原始支出数字增加了一个分母。一个成本高出两倍但可靠性高出三倍的 Agent 具有更优的单位经济效益,而原始支出跟踪会完全忽略这一点。
基础设施地平线
除了软件层面的优化,2026 年的硬件趋势正在大幅降低推理的底价。NVIDIA 的 Vera Rubin 平台相比 Blackwell 将每个 Token 的成本降低了 10 倍,而 NVIDIA Groq 3 LPU 结合起来提供了 35 倍的 Token 效率提升。对于规模足够大的团队,在高吞吐量情况下自托管已经比 API 定价便宜 60-80%,随着硬件效率的提高,盈亏平衡点还在不断下降。
企业部署的最佳架构正日益混合化:云 API 用于突发容量和前沿模型访问,本地或私有云用于基础负载的可预测工作负载,在这些地方 Token 体量证明了固定基础设施成本的合理性。
Token 效率是新的竞争前沿
在 Agent AI 时代的前 18 个月,竞争差异化主要在于原始能力:哪个 Agent 能解决最难的问题,在 SWE-bench 上得分最高,处理最复杂的工作流。这种竞争并未消失。
但第二个竞争维度现在对于生产可行性同样重要:你能以零头的 Token 成本交付相同的能力吗? 2026 年交付盈利 AI 产品的团队不仅仅是构建有能力的 Agent——他们构建的是 高效 的 Agent。
通过模型路由、提示词缓存和上下文优化实现的 60-80% 成本降低并非理论。它们在客户服务、编程和研究 Agent 类别的生产部署中得到了证实。工具已经成熟。路由框架已经存在。缓存 API 默认开启。那些每月支付 $80,000 的团队与那些为相同产出支付 $16,000 的团队之间的区别,主要在于六个月前做出的架构决策。
Token 效率架构不再是上线后的一次性优化步骤。它是从一开始就构建的设计约束。