一个处理日活 1000 万次对话的 Shopify 级商户助手，如果未经优化，月度开支约为 210 万美元；若经过优化，这一数字可压低至 45 万美元。这 78% 的成本差距并非源于某种算法突破，而是归功于缓存、路由策略以及一些工程规范——大多数团队往往等到账单寄来时才意识到这一点。
AI Agent 并非只是多了几步操作的聊天机器人。单一用户请求会触发规划、工具筛选、执行、验证，甚至频繁的重试循环——这会消耗大约比直接聊天交互多 5 倍的 Token。如果运行 10 个周期的 ReAct 循环，其 Token 消耗量更是单次通过的 50 倍。在顶格模型定价面前，这笔账很快就会变成沉重的负债。
本文将深入探讨 Agent 成本构成的底层机制，以及那些真正能起作用的具体技术手段——附带数据支撑。
为何 Agent 成本有别于普通聊天机器人
首先必须认清输出 Token 的溢价问题。在主流供应商中，输出 Token 的定价通常是输入 Token 的 3 到 8 倍，因为生成过程是序列化的，而输入处理则是并行的。对于侧重推理的模型，这一比例甚至能达到 8:1。当你的 Agent 生成冗长的工具调用反馈、详尽的推理轨迹或长篇总结时，你都在为每一个输出 Token 支付高昂的溢价。
上下文长度进一步加剧了这一问题。由于注意力计算的二次方成本，处理一个 128K Token 的上下文大约是处理 8K 上下文成本的 64 倍。Agent 系统自然会堆积上下文：系统提示词、工具定义、对话历史、检索到的片段以及工具反馈。每一轮交互都会增加上下文负载。大多数团队在预发环境中会发现这一点：原本在简短测试中单次任务成本仅 0.05 美元的 Agent，在接入真实文档库后成本飙升至 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 提供折扣，OpenAI 则在符合条件的请求上自动应用 50% 的折扣。
对于 Agent 系统而言，这意味着你需要精心构造 Prompt：将静态内容置于顶部。系统提示词、工具定义、少样本示例、政策文档——所有这些都应构成稳定的前缀。动态内容（即实际的用户消息、当前轮次检索到的上下文）则置于末尾。这并非为了美观，而是直接决定了缓存是否生效。
在实际应用中，Claude Code 达到了 92% 的缓存命中率，从而带来了 81% 的处理成本降幅。固定的 10,000 Token 系统提示词在首次请求之后几乎零成本。一个客服应用将产品目录从动态插入改为缓存前缀后，在未改变输出质量的情况下，API 账单每月减少了 12,000 美元。
除了降低成本，缓存还削减了延迟。在长前缀激活缓存时，平均响应延迟从 800 毫秒降至 350 毫秒，因为模型跳过了对稳定部分的注意力矩阵重计算。
其工程开销极小：缓存窗口的 TTL（生存时间）范围从 5 分钟（Anthropic）到约 1 小时（OpenAI）。对于服务于重复用户会话的 Agent，热缓存几乎随时可用。对于批处理流水线，则应构建作业，使批次内的请求共享前缀。
模型路由与级联：将成本与复杂度匹配
并非每个查询都需要顶格模型。关键在于如何判定——答案取决于三个维度：推理复杂度、质量敏感度以及上下文长度。
在典型的生产环境 Agent 工作负载中，分布大致如下：
- 60% 的任务属于直接操作：提取、分类、格式化、模板化回复。这些在每百万成本低于 1 美元的模型上即可流畅运行。
- 25% 需要中等程度推理：多跳问答、代码生成、结构化分析。中端模型（每百万 0.80-4 美元）能很好地处理。
- 12% 涉及真正的复杂性：指令模糊、长周期规划、跨异构源综合。高级模型在此处物有所值。
- 3% 需要顶格推理能力：新颖问题、高风险决策、突发行为。
实施良好的路由系统能在典型的 Agent 部署中实现 30-60% 的成本削减，顶级实现甚至能达到 87%。
针对 Agent 系统的实用模式是将编排与执行分离。在规划层使用昂贵的模型——它读取相对较短的任务描述并做出路由决策，因此其 Token 消耗是可控的。在执行步骤中使用廉价模型：总结、提取、格式转换、检索排序。由 Claude Haiku 执行工具调用，而 Sonnet 或 Opus 负责规划整体策略，这是一种常见且有效的分工。
模型级联则更进一步：从最便宜的层级开始处理每个请求，根据标准（置信度、格式有效性、若有检索源则核查事实依据）对响应打分，若分数低于阈值则升级。级联带来的额外延迟通常是值得的——大多数请求在第一层就完成了，升级仅在少数困难情况下触发。
基于置信度的路由需要一些校准。如果你自己构建，对于开源模型，logprob 熵是一个可用的信号。对于专有 API，你需要一个代理评估器（通常是一个更小、更快的模型，用于检查初次响应是否达标）。代理增加的成本通常仅占路由节省成本的 5% 不到。
上下文压缩：减少输入量
上下文中的每一个 Token 都有直接成本。上下文压缩的做法是将上下文剥离至任务所需的最小值。
滚动总结 是基线技术。不再传递完整的对话历史，而是每 N 轮（通常 5-10 轮）进行一次总结。总结内容向后传递；完整记录则归档。这将上下文增长限制在随总结频率线性增长，而非随轮次线性增长。其代价是早期轮次的细粒度细节将不可用——这对于大多数用例是可以接受的，但对于需要记住每个决策的代码审查 Agent 则不可接受。
工具输出掩蔽 常被忽视。当 Agent 调用网页抓取器、API 或数据库查询时，原始响应通常包含头信息、元数据以及与当前任务无关的字段。在插入上下文之前剥离这些内容，可以将工具输出的 Token 减少 60-80%。为每种工具类型编写后处理器，仅提取模型真正需要的字段。
学习型压缩 工具（如 LLMLingua）使用较小的模型来压缩 Prompt，通过识别并移除低信息量的 Token。据报道，客服 Prompt 从 800 个 Token 减少到 40 个（减少 95%），且保持了可接受的准确性。陷阱在于：压缩本身需要一次 LLM 调用，增加了延迟和 Token 成本。只有当压缩后的 Prompt 在大量请求中复用，或者压缩器的成本远低于主模型成本时，这笔账才算得过来。
检索的相关性过滤 很简单：不要传递所有检索到的块，只传递那些余弦相似度高于阈值的部分。将此阈值从 0.7 提高到 0.8，通常能减少 40-60% 的检索 Token，同时还能减少那些原本会稀释模型注意力的噪音。
语义缓存：彻底消除调用
语义缓存根据输入的嵌入对 LLM 响应进行索引存储。当新查询到达时，将其嵌入与缓存的查询进行比较——如果相似度超过阈值，则直接返回缓存响应，无需调用 API。
在典型的生产工作负载中，约有 31% 的 LLM 查询具有足够高的语义相似度，可从中受益。缓存命中在毫秒级返回（相比秒级），且 API 费用完全为零。对于支持聊天机器人、FAQ 系统以及查询分布呈现聚集状的应用，语义缓存可以直接削减 20-40% 的 API 调用。
权衡在于对新鲜度的敏感度。对于答案频繁变化的应用，数据陈旧是一种风险。根据你的内容领域变化速度来配置 TTL。对于静态知识库，激进的 TTL 是合适的。对于实时数据查询，则应针对这些查询类型完全禁用语义缓存。
硬性限额不可或缺
最廉价的优化手段是防止失控循环。一起有据可查的生产事故是：一个 Agent 在一个周末向一个损坏的数据源发起了 847,000 次 API 调用，在账户被暂停前累积了 3,847 美元的费用。另一个例子：一个 Agent 在五分钟内调用了 400 次抓取工具，因为该工具返回了“可能有更多结果”——Agent 将其解读为继续获取的邀请。
每个 Agent 在部署前都需要设定三个硬性限额：
- 单任务最大迭代次数。 设定为预期平均值的 2-3 倍。大多数 Agent 框架（LangGraph、AutoGen、CrewAI）都将此作为一等配置项暴露出来。
- 单任务最大 Token 花费。 设定为预发环境中观察到的 P95 花费的 3 倍。将其作为中间件实现，在每次模型调用前检查累积成本。
- 最大墙钟时间。 用于捕获那些通过反复进行快速、廉价调用从而绕过 Token 预算的无限循环。
模棱两可的工具反馈是造成失控循环的最常见原因。如果一个工具能返回可能被解读为“继续”的信号，Agent 就会一直继续下去。在工具输出架构中要明确：包含一个 is_complete 布尔值或 next_action_required 字段，而不是依赖模型去推断终止条件。
FinOps：上线前必备的监控工具
成本的可视化是闭环的关键。没有它，优化只是盲猜，异常则是惊吓。
最小可行的监控层应追踪：
- 每次追踪的成本。 每次 Agent 运行都应向你的可观测性系统发送其总成本（输入 Token × 价格 + 输出 Token × 价格，按模型层级细分）。
- 缓存命中率。 如果此指标低于基线，说明你的 Prompt 结构或请求模式发生了变化。
- 输出 Token 比率。 输出 Token /（输入 + 输出）Token。该比率上升通常意味着你的 Agent 过于啰嗦——通常可以通过在系统提示词中添加“简洁回复”来修复（这通常能减少 15-25% 的输出 Token）。
- 每次完成的步数。 步数增加表明任务变难或 Agent 陷入了困境。无论哪种情况都值得调查。
像 Langfuse、Helicone 和 Portkey 这样的工具在 API 网关层面提供了每请求的成本跟踪和预算控制。为了检测异常，可设置相对于滚动基线的 2σ 偏差警报——如果你关注这个信号，大多数成本事故在几分钟内就能被检测到。
同一个 Agent 在未优化与良好优化的部署之间，成本差异可达 30-200 倍。这是目前大多数 AI 团队能获得的最高 ROI 的工程工作。
实操优先级顺序
如果你从零开始，请按以下顺序应用这些技术，一旦达到成本目标即可停止：
- Prompt 缓存。 如果你的框架支持，无需代码更改。将静态内容移至前缀。立竿见影。
- 硬性限额。 防止导致其他一切努力变得毫无意义的尾部风险（即失控事故）。
- 输出 Token 控制。 在系统提示词中加入“简洁回复”。监控输出 Token 比率，看着它下降。
- 工具输出掩蔽。 为你最高频使用的工具编写后处理器。
- 模型路由。 按复杂度对任务分类并路由至相应层级。先从简单的基于规则的分类器开始；如果体量证明合理，再升级为学习型路由器。
- 上下文压缩。 为长运行会话实施滚动总结。
- 语义缓存。 如果你的查询分布具有足够的聚集性，则添加此功能。
默认状态下 Agent 系统的成本与经过良好工程化后的成本之间的差距并非微不足道。这正是项目能否上线、能否在预算审查中存活下来的关键区别。