一个处理量级达到 Shopify 的商家助手，如果不做优化，每天处理 1000 万次对话的月度开销约为 210 万美元；而经过优化后，这个数字可以压低至 45 万美元。这 78% 的差距并非源于算法层面的突破，而是归功于缓存、路由策略以及一些容易被团队忽略的工程技巧——直到账单寄到时，他们才意识到这一点。
AI Agent 绝不仅仅是多走了几步的 Chatbot。单一的用户请求会触发规划、工具筛选、执行、校验，甚至重试循环——这大约会消耗比直接对话互动多 5 倍的 Token。如果一个 ReAct 循环运行 10 个周期，其 Token 消耗量可能是单次处理的 50 倍。在 Frontier 模型（前沿模型）的定价体系下，这种算数逻辑很快就会变成负债。
本文将深入探讨 Agent 成本的来源机制，并介绍那些真正能发挥作用的、附带具体数据的实战技巧。
为何 Agent 的成本不同于 Chatbot
首先需要理解的是输出 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 美元，而 Frontier 推理模型则高达 15/60 美元。这种价差是一个机遇——前提是你必须进行有针对性的路由。
Prompt Caching：唾手可得的收益
Prompt Caching（提示词缓存）的工作原理是复用先前请求中已计算出的键值注意力张量，前提是新请求与旧请求拥有共同的前缀。Anthropic 对缓存的输入 Token 提供 90% 的折扣（0.30 美元/M vs 3.00 美元/M），Google 提供 75% 的折扣，而 OpenAI 则在符合条件的请求上自动应用 50% 的折扣。
对于 Agent 系统而言，这意味着你需要精心构建 Prompt 结构：将静态内容置于首位。系统提示词、工具定义、少样本示例、策略文档——所有这些都应构成稳定的前缀。动态内容（实际的用户消息、当前轮次的检索上下文）则置于末尾。这并非为了美观，而是直接决定了缓存能否被触发。
在实践中，Claude Code 实现了 92% 的缓存命中率，从而带来了 81% 的处理成本削减。一个固定的 10,000 Token 系统提示词，在首次请求之后，其边际成本几乎为零。某客户支持应用将其产品目录从动态插入改为缓存前缀后，在未改变输出质量的前提下，将 API 账单每月削减了 12,000 美元。
除了降低成本，缓存还能减少延迟。当长前缀启用缓存时，平均响应延迟从 800ms 降至 350ms，因为模型跳过了对稳定部分注意力矩阵的重新计算。
工程层面的开销微乎其微：缓存窗口的 TTL（生存时间）从 5 分钟（Anthropic）到大约 1 小时不等。对于服务重复用户会话的 Agent 来说，热缓存几乎总是可用的。对于批处理管道，应构建作业以确保批次内的请求共享前缀。
Model Routing and Cascading：将成本与复杂度匹配
并非每个查询都需要动用 Frontier 模型。问题的关键在于如何甄别——答案取决于三个维度：推理复杂度、质量敏感度以及上下文长度。
在典型的生产级 Agent 工作负载中，分布大致如下：
- 60% 的任务直截了当：提取、分类、格式化、模板化回复。这些在价格低于 1 美元/M 的模型上运行即可。
- 25% 需要中等程度的推理：多跳问答、代码生成、结构化分析。中端模型（0.80-4 美元/M）足以应对。
- 12% 涉及真正的复杂性：模糊指令、长周期规划、跨异构源的综合。此时 Premium 模型才物有所值。
- 3% 需要前沿推理能力： novel 问题（新颖问题）、高风险决策、突发行为。
实施得当的路由系统在典型的 Agent 部署中可实现 30-60% 的成本降低，而顶级的实现甚至能达到 87%。
Agent 系统的实战模式是将编排与执行分离。在规划层使用昂贵的模型——它只需读取相对简短的任务描述并做出路由决策，因此 Token 消耗是有限的。在执行步骤中使用廉价模型：摘要、提取、格式转换、检索排序。Claude Haiku 执行工具调用，而 Sonnet 或 Opus 规划整体策略，这是一种常见且有效的分工。
模型级联更进一步：从最便宜的层级开始处理每个请求，根据标准（置信度、格式有效性、如有检索源则基于事实基础）对响应打分，若分数低于阈值则升级。级联带来的额外延迟通常是值得的——大多数请求在第一层级就完成了，只有小部分困难请求才会触发升级。
基于置信度的路由需要一些校准。如果你是自己构建，logprob 熵（对数概率熵）是开源模型的一个可用信号。对于专有 API，你需要一个代理评估器（通常是一个更小、更快的模型，用于检查首次响应是否满足你的质量标准）。代理增加的成本通常只占路由节省成本的不到 5%。
Context Compression：精简输入
上下文中的每一个 Token 都有直接的代价。上下文压缩是指将上下文削减至任务所需的最小限度。
滚动摘要是基准技术。不再传递完整的对话历史，而是每 N 轮（通常是 5-10 轮）进行一次摘要。摘要向前传递，完整记录被归档。这使得上下文增长随摘要频率线性增加，而不是随轮次线性增加。权衡在于无法获取早期轮次的细粒度细节——这对大多数用例是可以接受的，但对于需要记住每个决策的代码审查 Agent 来说则不可接受。
Tool output masking（工具输出掩码）经常被忽视。当 Agent 调用网页抓取器、API 或数据库查询时，原始响应通常包含与当前任务无关的标头、元数据和字段。在将它们插入上下文之前剥离这些内容，可以减少 60-80% 的工具输出 Token。为每种工具类型编写后处理器，仅提取模型实际需要的字段。
Learned compression（习得式压缩）工具如 LLMLingua，利用较小的模型来压缩提示词，识别并剔除低信息量的 Token。据报道，客服提示词从 800 Token 减少到 40 Token（减少 95%），同时保持了可接受的准确性。陷阱在于：压缩本身需要调用 LLM，增加了延迟和 Token 成本。只有当压缩后的提示词在大量请求中复用，或者压缩器的成本远低于主模型成本时，这笔账才算得过来。
Relevance filtering for retrieval（检索相关性过滤）很直观：不要传递所有检索到的切片，只传递那些余弦相似度高于阈值的切片。将此阈值从 0.7 提高到 0.8，通常能削减 40-60% 的检索 Token，同时减少那些本会分散模型注意力的噪音。
Semantic Caching：彻底消灭调用
语义缓存基于输入的嵌入来存储 LLM 的响应。当新查询到达时，计算其嵌入并与缓存查询进行比较——如果相似度超过阈值，则直接返回缓存响应，无需调用 API。
在典型的生产工作负载中，约有 31% 的 LLM 查询具有足够高的语义相似度，可从中受益。缓存命中在毫秒级返回（相比之下 API 调用需秒级），且 API 费用为零。对于支持 Chatbot、FAQ 系统以及查询分布具有聚类特征的应用，语义缓存可以直接消除 20-40% 的 API 调用。
权衡在于对新鲜度的敏感性。对于答案频繁变动的应用，存在数据过时的风险。根据内容领域的变化速度配置 TTL。对于静态知识库，激进的 TTL 是合适的。对于实时数据查询，针对这些查询类型完全禁用语义缓存。
Hard Limits：非配不可的兜底方案
最廉价的优化手段是防止失控循环。曾有一份 documented 的生产事故：一个 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 caching。 如果框架支持，无需更改代码。将静态内容移至前缀。立竿见影。
- Hard limits。 防止那种让一切其他优化都变得无关紧要的失控事故风险。
- Output token control。 在系统提示词中加入“回复简洁”。监控输出 Token 比率并观察其下降。
- Tool output masking。 为你最高频的工具编写后处理器。
- Model routing。 按复杂度分类任务并路由至相应层级。从简单的基于规则的分类器开始；如果量级证明有必要，再升级为学习型路由器。
- Context compression。 为长运行会话实施滚动摘要。
- Semantic caching。 如果查询分布具有足够的聚类特征，则添加此项。
Agent 系统默认的成本与经过良好工程化后的成本之间的差距并非微不足道。这正是项目能否顺利投产，或者在预算审查时被砍掉的分水岭。