执行摘要
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 及类似技术利用一个小型、快速的模型来对每个 Token 的重要性进行打分，并在提示词发送给主模型之前移除低信息量的 Token。在冗长的文档输入上，已实现了高达20倍的压缩率，同时保持了任务性能。
成本算术很直观：压缩器模型成本（微小） + 压缩后的推理成本 << 未压缩的推理成本。
上下文窗口作为成本驱动因素
一种不那么显而易见的提示词压缩形式，是对长期运行 Agent 的严格上下文管理。随着 Agent 在多轮交互中积累工具调用结果，如果每一轮都重发完整历史记录，上下文带来的 Token 成本将呈二次方增长。
有效的策略包括：
迭代式摘要。 当上下文接近阈值时，较早的轮次会被总结为紧凑的表示。完整记录被归档在内存中，但不会在每次调用时重发给 LLM。
工具结果压缩。 Agent 的工具输出往往非常冗长。一个返回500行的数据库查询不需要将全部500行发送给 LLM——Agent 应提取并仅转发相关的子集。
结构化内存交接。 在多 Agent 管道中，Agent 应传递结构化摘要，而非完整的对话历史。下游 Agent 需要的是结论和关键数据点，而非产生这些结论的推理路径。
Cloudflare 的代码模式架构（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%处设置警报，并配套升级响应机制：监控、审查、熔断。
- 按用户和功能的配额。 将支出按用户群体和功能领域细分，能在成本异常复合之前使其显性化。
让预算...
来源：查看原文