一个达到 Shopify 规模的商家助手，每天处理 1000 万次对话，如果未做优化，每月费用高达 210 万美元；而经过优化后，仅需 45 万美元。这 78% 的成本差距并非源于算法突破，而是归功于缓存、路由以及几项通常被团队忽视的工程规范——直到账单到来时才追悔莫及。

AI Agent 绝非仅仅是多走了几步的聊天机器人。单一用户的请求便会触发规划、工具选择、执行、验证，甚至重试循环——其消耗的 Token 大约是直接聊天的 5 倍。一个运行 10 个循环的 ReAct 机制，其 Token 消耗量甚至是单次传递的 50 倍。若按前沿模型的定价计算，这笔开销很快就会变成巨大的负债。

本文将深入剖析 Agent 成本的来源，并介绍那些能真正起到降本作用的实战技术——附带数据支撑。

为何 Agent 成本不同于聊天机器人​

首先要理解的是输出 Token 的溢价。主流服务商的输出 Token 定价通常是输入 Token 的 3-8 倍，因为生成过程是串行的，而输入处理可以并行。对于侧重推理的模型，这一比例甚至达到 8:1。当你的 Agent 生成冗长的工具调用回复、详细的推理轨迹或长篇总结时，你都在以溢价费率支付每一个输出 Token。

上下文长度加剧了这一问题。由于注意力计算存在二次方成本，处理 128K Token 的上下文成本大约是 8K 上下文的 64 倍。Agent 系统会自然堆积上下文：系统提示词、工具定义、对话历史、检索到的片段以及工具响应。每一轮交互，上下文都在增长。大多数团队在预发布阶段会注意到这一点：原本在简短测试中仅需 0.05 美元/次的任务，面对真实文档语料库时，成本突然飙升至 1.50 美元。

最便宜与最昂贵的模型选项之间，目前价差约为 60 倍。以 Gemini Flash-Lite 为例，其每百万输入/输出 Token 约为 0.075/0.30 美元，而前沿推理模型则高达 15/60 美元。这种价差是机遇——前提是你必须有意识地进行路由选择。

Prompt 缓存：唾手可得的收益​

Prompt 缓存的原理是复用先前请求中计算出的键值注意力张量，前提是新请求与旧请求拥有相同的前缀。Anthropic 为缓存的输入 Token 提供 90% 的折扣（0.30 美元/M 对比 3.00 美元/M），Google 提供 75% 的折扣，而 OpenAI 则对符合条件的请求自动应用 50% 的折扣。

对于 Agent 系统，这意味着重要的架构调整：将静态内容置于 Prompt 的开头。系统提示词、工具定义、少量示例、策略文档——所有这些都应构成稳定的前缀。动态内容（实际的用户消息、当前轮次检索到的上下文）则置于末尾。这不仅仅是为了美观，更直接决定了缓存是否生效。

Claude Code 在实践中实现了 92% 的缓存命中率，从而降低了 81% 的处理成本。固定的 10,000 Token 系统提示词在首次请求后几乎零成本。某客户支持应用将其产品目录从动态插入改为缓存前缀，在未改变输出质量的情况下，每月节省了 12,000 美元的 API 账单。

除了降低成本，缓存还能减少延迟。在长前缀上启用缓存时，平均响应延迟从 800ms 降至 350ms，因为模型跳过了对稳定部分注意力矩阵的重新计算。

这方面的工程投入极少：缓存窗口的 TTL 范围从 5 分钟（Anthropic）到大约 1 小时（OpenAI）不等。对于服务于重复用户会话的 Agent，热缓存几乎总是可用。对于批量管道，应构建作业结构，使批次内的请求共享前缀。

模型路由与级联：匹配复杂度与成本​

并非每个查询都需要前沿模型。关键在于如何辨别——答案取决于三个维度：推理复杂度、质量敏感度和上下文长度。

在典型的生产级 Agent 工作负载中，分布大致如下：

• 60% 的任务是直截了当的：提取、分类、格式化、模板化回复。这些在低于 1 美元/M 的模型上运行即可。
• 25% 需要中等程度的推理：多跳问答、代码生成、结构化分析。中端模型（0.80-4 美元/M）足以应对。
• 12% 涉及真正的复杂性：模棱两可的指令、长期规划、跨异构源的综合。高级模型在这里物有所值。
• 3% 需要前沿推理：新颖问题、高风险决策、突发行为。

实施良好的路由系统在典型的 Agent 部署中可节省 30-60% 的成本，顶级实现甚至能达到 87%。

Agent 系统的实用模式是将编排与执行分离。使用昂贵的模型用于规划层——它读取相对较短的任务描述并做出路由决策，因此其 Token 消耗是有限的。使用便宜的模型用于执行步骤：总结、提取、格式转换、检索排序。Claude Haiku 执行工具调用，而 Sonnet 或 Opus 规划整体策略，这是一种常见且有效的分工。

模型级联更进一步：每个请求都从最便宜的层级开始，根据标准（置信度、格式有效性、若有检索源的事实依据）对响应打分，若分数低于阈值则升级。级联带来的额外延迟通常是值得的——大多数请求在第一层级完成，只有少部分困难请求才会触发升级。

基于置信度的路由需要一些校准。如果你自己构建，对数概率熵是开源模型可用的信号。对于专有 API，你需要一个代理评估器（通常是一个更小、更快的模型，用于检查首次响应是否满足你的质量标准）。代理增加的成本通常仅占路由节省成本的不到 5%。

上下文压缩：精简输入内容​

上下文中的每个 Token 都有直接成本。上下文压缩就是将上下文剥离到任务所需的最低限度的实践。

滚动总结是基线技术。与其传递完整的对话历史，不如每 N 轮（通常是 5-10 轮）总结一次。总结向前传递，完整记录被归档。这将上下文增长限制为随总结频率线性增长，而不是随轮次线性增长。其权衡在于，早期轮次的细节将不可用——这对大多数用例是可以接受的，但对于需要记住每个决策的代码审查 Agent 来说则不行。

工具输出掩蔽经常被忽视。当 Agent 调用网页抓取器、API 或数据库查询时，原始响应通常包含与当前任务无关的标头、元数据和字段。在插入上下文之前剥离这些内容，可以将工具输出 Token 减少 60-80%。为每种工具类型编写后处理器，仅提取模型实际需要的字段。

习得式压缩工具如 LLMLingua，使用较小的模型来识别并去除低信息 Token，从而压缩 Prompt。据报告，客服 Prompt 从 800 Token 减少到 40 Token（减少 95%），且保持了可接受的准确性。缺点是：压缩本身需要 LLM 调用，增加了延迟和 Token 成本。只有当压缩后的 Prompt 被多次请求复用，或压缩器的成本远低于主模型成本时，这笔账才算得过来。

检索的相关性过滤很简单：不要传递所有检索到的块，只传递那些余弦相似度高于阈值的块。将此阈值从 0.7 提高到 0.8，通常能将检索到的 Token 减少 40-60%，同时减少了否则会稀释模型注意力的噪音。

语义缓存：彻底消灭调用​

语义缓存根据输入的 Embedding 索引来存储 LLM 响应。当新查询到达时，将其 Embedding 与缓存的查询进行比较——如果相似度超过阈值，则返回缓存的响应而无需调用 API。

在典型的生产工作负载中，大约有 31% 的 LLM 查询具有足够高的语义相似度，可从中受益。缓存命中在毫秒级返回（相比秒级），且 API 费用完全为零。对于支持聊天机器人、FAQ 系统以及查询分布聚集的应用，语义缓存可以直接消除 20-40% 的 API 调用。

其权衡在于新鲜度敏感性。对于答案频繁变化的应用，存在陈旧风险。根据内容域的变化速度配置 TTL。对于静态知识库，激进的 TTL 是合适的。对于实时数据查询，则应对这些查询类型完全禁用语义缓存。

硬性限制并非可选项​

最便宜的优化方式是防止失控循环。有记录在案的生产事故：一个 Agent 在一个周末向损坏的数据源发起了 847,000 次 API 调用，累积了 3,847 美元的费用，直到账户被暂停。另一起：一个 Agent 在五分钟内调用了抓取工具 400 次，因为工具返回“可能有更多结果”——Agent 将其解释为继续获取的邀请。

每个 Agent 在部署前都需要设定三个硬性限制：

1. 每个任务的最大迭代次数。 设定为预期平均值的 2-3 倍。大多数 Agent 框架（LangGraph, AutoGen, CrewAI）都将此作为一级配置暴露。
2. 每个任务的最大 Token 花费。 设定为预发布阶段观察到的 P95 花费的 3 倍。将其实现为中间件，在每次模型调用前检查累积成本。
3. 最大实际执行时间。 用于捕获通过反复进行快速、廉价调用而保持在 Token 预算之内的无限循环。

模棱两可的工具反馈是失控循环最常见的原因。如果工具可以返回一种被解释为“继续”的信号，Agent 就会继续下去。在工具输出模式中要明确：包含一个 is_complete 布尔值或 next_action_required 字段，而不是依赖模型推断终止条件。

FinOps：上线前必备的监控手段​

成本可见性是闭环的关键。没有它，优化只是猜测，异常则是惊吓。

最低限度的可行监控层应跟踪：

• 每次 Trace 的成本。 每次 Agent 运行都应向可观测性系统发出其总成本（输入 Token × 价格 + 输出 Token × 价格，按模型层级细分）。
• 缓存命中率。 如果此值低于基线，说明你的 Prompt 结构或请求模式发生了变化。
• 输出 Token 比率。 输出 Token /（输入 + 输出）Token。比率上升通常意味着你的 Agent 太啰嗦了——通常可以通过在系统提示词中添加“简洁”来解决（这通常会减少 15-25% 的输出 Token）。
• 每次完成的步数。 步数增加表明任务更难了或者 Agent 卡住了。无论哪种情况都值得调查。

Langfuse、Helicone 和 Portkey 等工具在 API 网关层面提供了每次请求的成本跟踪和预算控制。对于异常检测，设定相对于滚动基线 2σ 偏差的消费警报——如果你关注此信号，大多数成本事故在几分钟内即可检测到。

同一个 Agent 在未优化和良好优化之间的部署成本差异可达 30-200 倍。这是目前大多数 AI 团队能获得的最高 ROI 的工程工作。

实战优先级顺序​

如果你从零开始，请按以下顺序应用这些技术，达到成本目标后即可停止：

1. Prompt 缓存。 如果你的框架支持，无需更改代码。将静态内容移至前缀。立竿见影。
2. 硬性限制。 防止使其他一切变得无关紧要的失控尾部风险。
3. 输出 Token 控制。 在系统提示词中添加“简洁回复”。监控输出 Token 比率并观察其下降。
4. 工具输出掩蔽。 为你最高频的工具编写后处理器。
5. 模型路由。 按复杂度分类任务并路由到适当的层级。从简单的基于规则的分类器开始；如果量级证明合理，再升级为学习型路由器。
6. 上下文压缩。 为长时间运行的会话实施滚动总结。
7. 语义缓存。 如果你的查询分布具有足够的聚集性，则添加此项。

Agent 系统默认成本与良好工程成本之间的差距并非微不足道。这正是项目能否上线、或者是否会在预算审查中被砍掉的区别所在。