对于一家处理日千万级对话的 Shopify 规模商家助手而言，未经优化的月度开销高达 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 倍。Agentic 系统天生就会积累上下文：系统提示词、工具定义、对话历史、检索的片段以及工具响应。每一轮对话，上下文都在增长。大多数团队在预发布环境会注意到这一点：原本在简短测试中仅需 0.05 美元的任务，在面对真实文档库时成本突然飙升至 1.50 美元。
目前，最廉价与最昂贵模型选项之间的差距已达 60 倍。以每百万输入/输出 Token 约 0.075/0.30 美元的 Gemini Flash-Lite 为例，对比定价 15/60 美元的尖端推理模型。这种差距既是机遇，但也仅当你进行有意的路由时才能利用。
Prompt 缓存：唾手可得的收益
Prompt 缓存通过复用先前请求中计算出的键值注意力张量来工作，前提是新请求与之前的请求共享共同的前缀。Anthropic 提供缓存输入 Token 90% 的折扣（0.30 美元/M vs 3.00 美元/M），Google 提供 75% 的折扣，而 OpenAI 则在符合条件的请求上自动应用 50% 的折扣。
对于 Agentic 系统，其意义重大：你需要构建 Prompt 结构，将静态内容置于前部。系统提示词、工具定义、少样本示例、策略文档——所有这些都应构成稳定的前缀。动态内容（即实际的用户消息、当前轮次检索到的上下文）则置于末尾。这关乎美学；它直接决定了缓存是否生效。
在实际应用中，Claude Code 达到了 92% 的缓存命中率，从而降低了 81% 的处理成本。固定的 10,000 Token 系统提示词在首次请求后几乎不再产生费用。某客户支持应用将其产品目录从动态插入转为缓存前缀，在未改变输出质量的情况下，每月节省了 12,000 美元的 API 账单。
除了降低成本，缓存还能削减延迟。当长前缀启用缓存时，平均响应延迟从 800 毫秒降至 350 毫秒，因为模型跳过了对稳定部分的注意力矩阵重新计算。
工程开销极小：缓存窗口的 TTL（生存时间）从 5 分钟（Anthropic）到大约 1 小时（OpenAI）不等。对于服务重复用户会话的 Agent，热缓存几乎总是可用的。对于批处理管道，应构建任务以确保批次内的请求共享前缀。
模型路由与级联：将成本与复杂度匹配
并非每个查询都需要尖端模型。关键在于如何判断——答案取决于三个维度：推理复杂度、质量敏感性和上下文长度。
在典型的生产级 Agentic 工作负载中，分布大致如下：
- 60% 的任务直截了当：提取、分类、格式化、模板化响应。这些在每百万 Token 1 美元以下的模型上即可流畅运行。
- 25% 需要中等程度的推理：多跳问答、代码生成、结构化分析。中端模型（0.80-4 美元/M）能很好地处理这些任务。
- 12% 涉及真正的复杂性：模棱两可的指令、长周期的规划、跨异构源的综合。高级模型在这里物有所值。
- 3% 需要尖端推理： novel problems、高风险决策、突发行为。
实施良好的路由系统在典型的 Agentic 部署中可实现 30-60% 的成本降低，顶级实现甚至能达到 87%。
对于 Agent 系统，实用的模式是将编排与执行分离。使用昂贵的模型进行规划层——它读取相对较短的任务描述并做出路由决策，因此其 Token 消耗是受限的。使用廉价模型执行具体步骤：摘要、提取、格式转换、检索排序。由 Claude Haiku 执行工具调用，而 Sonnet 或 Opus 规划整体策略，这是一种常见且有效的拆分方式。
模型级联更进一步：从最便宜的层级开始每个请求，根据标准（置信度、格式有效性、如有检索来源的事实依据）对响应打分，若分数低于阈值则升级。级联带来的额外延迟通常是值得的——大多数请求在第一层级完成，升级仅针对少数困难请求触发。
基于置信度的路由需要校准。如果你自建路由，logprob 熵是开源模型的一个可用信号。对于专有 API，你需要一个代理评估器（通常是一个较小、快速的模型，用于检查首次响应是否达到质量标准）。代理的额外成本通常远低于路由节省的成本。
上下文压缩：精简输入内容
上下文中的每个 Token 都直接产生费用。上下文压缩的做法是将上下文精简至任务所需的最低限度。
滚动摘要是基线技术。不再传递完整的对话历史，而是每隔 N 轮（通常 5-10 轮）进行一次摘要。摘要向前传递；完整记录则被归档。这将上下文增长限制为随摘要频率线性增长，而非随轮次线性增长。权衡之处在于，早期轮次的细粒度细节将不可用——这对大多数用例是可以接受的，但对于需要记住每个决策的代码审查 Agent 则不可。
工具输出屏蔽经常被忽视。当 Agent 调用网页抓取器、API 或数据库查询时，原始响应通常包含与当前任务无关的标头、元数据和字段。在插入上下文之前剔除这些内容，可将工具输出 Token 减少 60-80%。为每种工具类型编写后处理器，仅提取模型真正需要的字段。
习得式压缩工具如 LLMLingua 使用较小的模型来压缩 Prompt，识别并移除低信息量的 Token。据报道，客服 Prompt 从 800 个 Token 减少到 40 个（减少 95%），并保持了可接受的准确性。 catch 在于：压缩本身需要调用 LLM，增加了延迟和 Token 成本。只有当压缩后的 Prompt 在大量请求中被复用，或者压缩器的成本远低于主模型成本时，这笔账才算得过来。
检索时的相关性过滤直截了当：不要传递所有检索到的片段，只传递那些超过余弦相似度阈值的片段。将此阈值从 0.7 提高到 0.8，通常能将检索到的 Token 减少 40-60%，同时降低否则会稀释模型注意力的噪声。
语义缓存：彻底消除调用
语义缓存通过输入的嵌入对 LLM 响应进行索引存储。当新查询到达时，将其嵌入与缓存的查询进行比较——如果相似度超过阈值，则返回缓存的响应，无需调用 API。
在典型的生产工作负载中，大约 31% 的 LLM 查询具有足够高的语义相似度，可从中受益。缓存命中在毫秒级返回，而非秒级，且 API 费用为零。对于支持聊天机器人、FAQ 系统以及查询分布呈集群状的应用，语义缓存可 outright 消除 20-40% 的 API 调用。
权衡在于对新鲜度的敏感度。对于答案频繁变化的应用，陈旧是一种风险。根据你内容域的变化速度配置 TTL。对于静态知识库，激进的 TTL 是合适的。对于实时数据查询，针对这些查询类型完全禁用语义缓存。
硬性限制不可或缺
最廉价的优化是防止失控的循环。有记录在案的生产事故：一个 Agent 在周末针对损坏的数据源发起了 847,000 次 API 调用，在被暂停之前累积了 3,847 美元的费用。另一个例子：一个 Agent 在五分钟内调用了 400 次抓取工具，因为该工具返回“可能有更多结果”——Agent 将其解读为继续获取的邀请。
每个 Agent 在部署前都需要设定三个硬性限制：
- 每个任务的最大迭代次数。 将其设定为预期平均值的 2-3 倍。大多数 Agent 框架都将其作为一级配置公开。
- 每个任务的最大 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 团�获得的最高投资回报率的工程工作。
实用的优先级顺序
如果你从零开始，请按以下顺序应用技术，达到成本目标时即可停止：
- Prompt 缓存。 如果你的框架支持，无需更改代码。将静态内容移至前缀。立竿见影。
- 硬性限制。 防止使其他一切变得无关紧要的失控事故的尾部风险。
- 输出 Token 控制。 在系统提示词中添加“简洁回复”。监控输出 Token 比率并观察其下降。
- 工具输出屏蔽。 为你最高频的工具编写后处理器。
- 模型路由。 按复杂度分类任务并路由至相应层级。从简单的基于规则的分类器开始；如果业务量证明合理，再升级为学习型路由器。
- 上下文压缩。 为长时间运行的会话实施滚动摘要。
- 语义缓存。 如果你的查询分布具有足够的集群性，则添加此功能。
Agentic 系统默认成本与良好工程化成本之间的差距并非微不足道。这直接决定了项目是能投入生产，还是在预算审查时被砍掉。