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