内容提要
2025年上半年，企业级 LLM 支出已攀升至 84 亿美元，近四成企业年均在语言模型上的投入超过 25 万美元——且高达 96% 的企业表示实际开销超出了最初的预算预期。具体到 AI Agent 领域，经济压力尤为严峻：相比简单的聊天机器人，Agent 调用 LLM 的次数要高出 3 到 10 倍；若缺乏约束，一个处理软件工程任务的 Agent 仅 API 费用就可能高达每笔任务 5 至 8 美元。
值得欣慰的是，关于 AI Agent 成本优化的技术体系已日趋成熟。那些全面应用了“智能模型路由”、“多层缓存机制”、“提示词压缩”、“批推理调度”以及“预算治理”等策略的团队，均报告在未牺牲输出质量的前提下，将 Token 消耗削减了 60% 至 80%。本文将深入剖析这一技术栈的各个层级，探讨其中涉及的各种工程权衡，以及在规模化场景下维持成本纪律所需的组织实践。
生产环境 Agent 的隐性成本
为何 Agent 成本会在规模扩张中失控
单次 Agent 对话平均产生的 Token 成本若为 0.14 美元，看似微不足道。但若将其放大到 3000 名员工，每人每天触发 10 次，日成本将达 4200 美元，年成本则高达 150 万美元。这正是所谓的“Token 成本陷阱”：在演示阶段看似合理的单体经济模型，一旦进入生产环境便变得难以为继。
以下结构性因素加剧了这一难题：
递归式工具调用的开销。 Agent 并非每项任务只调用一次 LLM——它们会不断迭代。每次工具调用的结果都会被追加到上下文中，并在下一轮完整重发。一个包含 10 个步骤的 Agent 任务可能会将累积的完整上下文传输 9 次，这意味着初始 2000 个 Token 的提示词在任务完成时可能膨胀为数万个输出 Token。
系统提示词的反复计费。 大多数生产环境下的 Agent 每次调用都会携带 2000 至 8000 个 Token 的系统提示词。若缺乏前缀缓存，这将构成一笔巨大的固定开销，且每次 API 调用都会单独计费。
多 Agent 系统的 Token 洪流。 当 Agent 之间相互通信时，一种常见的反模式是传递完整的对话历史而非摘要。流水线中的推理 Agent 并不需要检索 Agent 的完整活动记录——它只需结构化的输出结果。缺乏显式的上下文管理，随着 Agent 数量的增加，多 Agent 系统的成本将呈指数级上升。
失控的循环。 2025 年 11 月，两个基于 LangChain 的 Agent 陷入了无限对话循环，在问题被发现前持续运行了 11 天，产生了 4.7 万美元的账单。这个极端案例生动地说明了当 Token 预算被视作事后考虑而非设计约束时会发生什么。
价格版图解析
理解不同模型层级之间的成本差异，是制定任何优化策略的基石。截至 2026 年初：
| 层级 | 代表模型 | 价格区间 |
|---|---|---|
| 高端推理型 | GPT-4, Claude Opus | 每百万 Token 30–60 美元 |
| 中端能力型 | GPT-4 Turbo, Claude Sonnet | 每百万 Token 10–15 美元 |
| 轻量极速型 | GPT-3.5, Claude Haiku | 每百万 Token 0.50–2 美元 |
| 小型专用型 | Mistral 7B, Phi-3 | 每百万 Token 0.10–0.50 美元 |
高端模型与小型模型之间 100 到 300 倍的成本差价，是所有优化策略的主要切入点。工程挑战在于，如何精准识别出究竟有多少比例的查询真正需要昂贵的模型层级。
模型路由：将复杂度与能力相匹配
核心原则
模型路由——即根据复杂度信号为每个请求动态选择 LLM 的做法——在 2025 至 2026 年间已成为行业标准。OpenAI 的 GPT-4o 架构明确根据查询复杂度在快速高效模型与深度推理模型之间进行路由。更广泛的市场也紧随其后。
采用系统化路由的组织报告称成本降低了 30% 至 70%。一个实施良好的级联系统，若能将 90% 的查询导向廉价模型，而将昂贵层级留给真正复杂的任务，便能在基础设施支出上实现 87% 的成本削减。
路由信号
高效的路由器利用多种信号来对请求复杂度进行分类：
输入特征。 查询长度、是否存在多跳推理需求、结构化与非结构化输出的预期、代码生成与自然语言的区别，以及是否包含特定领域术语，这些都与所需的模型能力相关。
任务类型分类。 简单的事实查询、文档摘要和意图分类通常不需要前沿模型。而数学推理、复杂的代码生成以及需要细微判断的调用则往往需要。
历史表现。 对于生产系统中的重复性任务，基于各模型层级成功率的实证数据可指导路由决策。若在 A/B 测试中 Claude Haiku 有 94% 的时间能正确处理某项任务，那么就无需动用 Claude Opus。
延迟要求。 交互式用例（用户等待响应）与后台处理流水线对模型延迟的容忍度不同。批处理流水线可以在非高峰时段路由至更高质量的低成本模型。
实现方案
模型路由的生态系统已显著成熟。LiteLLM、Portkey 和 OpenRouter 等工具均提供了开箱即用的多模型路由和故障转移配置。这些网关还带来了一项附加红利：供应商冗余。当 OpenAI 在 2025 年发生服务中断时，使用路由器的应用通过自动切换至 Anthropic 或 Google 而保持了在线。
一种实用的级联架构包含三个决策点：
- 语义缓存检查 — 若存在语义相似的先前请求，则直接返回缓存响应（节省 100% 成本）
- 复杂度分类 — 将简单任务路由至轻量级模型，复杂任务路由至中端模型
- 失败升级机制 — 若廉价模型的输出未通过质量检查，则使用上一层级模型重试
这种级联模式将昂贵的推理视为最后手段，而非默认选项。
多层缓存：在推理运行前拦截成本
为何缓存未被充分利用
研究表明，31% 的 LLM 查询与先前的请求存在语义相似性。若缺乏缓存设施，这意味着三分之一的推理支出在结构上是浪费的——即针对本质上相同的问题重复计算。然而，许多生产系统即使实现了缓存，也只是将其视为补丁。
第一层：精确响应缓存
最简单的形式是基于精确的提示词文本缓存完整的 LLM 响应。缓存命中能带来 100% 的成本节省和接近零的延迟。这适用于确定性工作流——批处理摘要、文档分类以及模板化生成任务，即相同输入确实会重复出现的场景。
实施相对直接：利用 Redis 或类似的键值存储保存响应，并配置可调整的 TTL（生存时间）。挑战在于动态上下文中的缓存失效，因为底层数据可能会发生变化。
第二层：语义缓存
语义缓存将精确匹配扩展到了利用嵌入相似度进行的近似匹配。当新查询的嵌入向量与缓存查询处于设定阈值内时，直接返回缓存响应或将其作为起点。
工程上的权衡在于嵌入计算（廉价但非零）与推理成本（昂贵）之间。对于高吞吐量的生产系统，这种权衡强烈倾向于语义缓存。GPTCache 等类似库将其实现为 LLM API 调用前的插入层。
第三层：前缀 / KV 缓存
前缀缓存运作于基础设施层。当连续的 API 调用共享一个共同的提示词前缀（如系统提示词）时，现代服务基础设施可以复用先前请求中的键值（KV）计算，而无需重新计算。
Anthropic 的前缀缓存在长提示词上实现了 90% 的成本降低和 85% 的延迟减少。OpenAI 的自动缓存实现了 50% 的成本节省。当提示词被结构化，将稳定内容（系统提示词、工具定义、文档上下文）置于可变内容（用户轮次、查询）之前时，该机制对应用代码是透明的。
一个关键的工程洞察：在 Agent 系统中，前缀缓存最高价值的用途是缓存工具架构定义。一个拥有 30 多个工具定义的生产 Agent 每次调用可能携带 8000 至 15000 个 Token 的工具架构，且在每次调用中完全相同。若没有前缀缓存，这会在每一轮中被重新计费。
第四层：KV 缓存 disaggregation（分离）
先进的生产部署使用 LMCache 和 Mooncake 等系统，在 GPU、CPU 和 SSD 存储之间实现多层 KV 缓存复用。这些系统允许为某个请求计算的 KV 张量被后续具有匹配前缀的请求检索和复用，甚至跨越不同的服务实例。
SpeCache（2025）进一步扩展了这一概念，引入推测性 KV 缓存预取：系统预测下一个 Token 可能关注哪些 KV 对，并主动将其从 CPU 内存加载到 GPU，从而消除内存带宽瓶颈。
对于对成本敏感的部署的实际影响：组织可以在相同的 GPU 容量上运行更大的批次，将每个 Token 的成本降低 40% 至 70%。
提示词压缩：在发送前减少 Token 数量
LLMLingua 与压缩流水线
并非所有 Token 都承载着同等的语义权重。针对自然语言的研究表明，人类撰写的文本包含大量冗余——填充词、冗长的措辞以及语言模型可以从周围文本推断出的重复上下文。
LLMLingua 及类似技术利用一个小型、快速的 LLM 来评估每个 Token 的重要性，并在提示词发送至主模型之前移除低信息量的 Token。在冗长的文档输入上，已展示了高达 20 倍的压缩率，同时保持了任务性能。
成本计算很简单：压缩器模型成本（极低） + 压缩后的推理成本 << 未压缩的推理成本。
上下文窗口作为成本驱动力
提示词压缩的一种不太明显的形式是对长期运行 Agent 进行严格的上下文管理。随着 Agent 在多轮对话中累积工具调用结果，若每一轮都重发完整历史，上下文带来的 Token 成本将呈二次方增长。
有效的策略包括：
迭代摘要。 当上下文接近阈值时，较早的轮次会被摘要为紧凑的表示形式。完整的记录被归档，但不会在每次调用时重发给 LLM。
工具结果压缩。 Agent 工具的输出往往非常冗长。返回 500 行的数据库查询不需要将所有 500 行都发送给 LLM——Agent 应仅提取并转发相关的子集。
结构化记忆交接。 在多 Agent 流水线中，Agent 应传递结构化摘要，而非完整的对话历史。下游 Agent 需要的是结论和关键数据点，而非产生这些结论的推理轨迹。
Cloudflare 的 Code Mode 架构（2026 年 2 月）展示了这一原则的极端应用：将 2500 多个 API 端点折叠为两个工具，仅消耗约 1000 个 Token——而传统的 MCP 服务器则需要 117 万个 Token。
批推理：将成本与延迟解耦
批次大小的经济学
实时推理以牺牲吞吐量效率为代价来优化延迟。批推理则反其道而行之：通过一起处理多个请求，GPU 计算和内存带宽的使用效率大大提高。在受控基准测试中，将 32 个请求一起批处理可将单 Token 成本降低 85%，而延迟仅增加 20%。
许多 API 提供商现在提供双层定价模型：
- 实时层：低延迟（毫秒到秒），溢价定价
- 批处理层：较高延迟（分钟到小时），折扣 50% 或更多
对于生产环境下的 Agent 工负载，很大一部分任务本质上是异步的，可以容忍批处理延迟。文档处理、内容生成、数据充实、定时分析——这些都不需要亚秒级的响应。
自托管部署中的连续批处理
运营自身推理基础设施（vLLM, TensorRT-LLM）的组织受益于连续批处理：当前批次中的序列一旦完成，新请求会立即插入，无需等待整个批次结束。结合 PagedAttention 的高效内存分配，连续批处理相比静态批处理实现了高达 23 倍的改进，显著提高了 GPU 利用率并降低了单 Token 成本。
预算治理：FinOps 层面
从成本意识到成本管控
技术优化降低了推理的单位成本。而预算治理则防止总成本无论单位效率如何都无限增长。
组织现实情况是：96% 的企业报告 AI 成本超出初始预测，且只有 44% 的企业建立了财务护栏。实施预算治理既需要工具，也需要组织的承诺。
硬限制与熔断机制
生产环境的 Agent 应在框架或网关层面强制执行严格的 Token 预算限制。实用的控制措施包括：
- 单任务最大迭代次数。 一个进行了 50 次工具调用仍未完成任务的 Agent，几乎肯定陷入了死循环，而非“工作细致”。
- 单次追踪的 Token 预算。 每次任务执行都有明确的 Token 预算。若预算耗尽，Agent 应返回部分结果，而非继续计费。
- 多阈值成本警报。 在预测月度支出的 50%、80% 和 100% 处设置警报，并采取升级响应：监控、审查、停止。
- 按用户和按功能的配额。 按用户群体和功能领域细分支出，能在成本异常恶化之前使其可见。