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