AI Agent 代币经济学：在不牺牲质量的前提下降低成本

一个 Shopify 规模的商户助手，每天处理 1,000 万次对话，在不进行优化的前提下每月成本高达 210 万美元 —— 而经过优化后，成本仅需 45 万美元。这 78% 的差距并非源于算法上的突破，而是来自缓存、路由以及一些大多数团队在收到账单前都会忽略的工程规范。

AI Agent 并不只是多了几个步骤的聊天机器人。单次用户请求会触发规划、工具选择、执行、验证，通常还有重试循环 —— 消耗的 token 数量大约是直接对话交互的 5 倍。一个运行 10 个周期的 ReAct 循环，其 token 消耗量可能是单次交互的 50 倍。在顶级模型的价格体系下，这种计算开销很快就会变成一项财务负担。

这篇文章将涵盖 Agent 成本的来源机制，以及能够真正产生影响的具体技术（附带数据支持）。

为什么 Agent 的成本与聊天机器人不同

首先要深刻理解输出 token 的溢价。在各大供应商中，输出 token 的价格通常是输入 token 的 3 到 8 倍，因为生成过程是序列化的，而输入处理可以并行化。对于重推理的模型，这个比例甚至达到了 8:1。当你的 Agent 生成冗长的工具调用响应、详细的推理过程或长篇总结时，你正在为每一枚输出 token 支付溢价。

上下文长度使问题变得更加复杂。由于注意力计算的平方级成本，处理 12.8 万 token 的上下文所需的成本大约是 8,000 token 上下文的 64 倍。Agent 系统会自然地积累上下文：系统提示词、工具定义、对话历史、检索到的片段以及工具响应。每一轮对话后，上下文都会增长。大多数团队在预发布阶段就会发现这一点 —— 在简短测试中每项任务仅需 0.05 美元的 Agent，在面对真实的文档语料库时，单次任务成本会突然飙升至 1.50 美元。

目前，最便宜和最昂贵模型选项之间的价差约为 60 倍。Gemini Flash-Lite 的价格约为每百万输入/输出 token 0.075 美元 / 0.30 美元，而顶级推理模型的价格为每百万 15 美元 / 60 美元。这种价差意味着机遇 —— 但前提是你要进行有意识的路由。

Prompt 缓存：最唾手可得的省钱方案

Prompt 缓存的工作原理是：当新请求与之前的请求具有公共前缀时，复用之前请求中计算出的键值（KV）注意力张量。Anthropic 为缓存的输入 token 提供 90% 的折扣（0.30 美元/百万 vs 3.00 美元/百万），Google 提供 75% 的折扣，而 OpenAI 则会对符合条件的请求自动应用 50% 的折扣。

对于 Agent 系统来说，这具有重大意义：请结构化你的提示词，使静态内容排在前面。系统提示词、工具定义、few-shot 示例、策略文档 —— 所有这些都应该构成稳定的前缀。动态内容（实际的用户消息、该轮交互检索到的上下文）放在最后。这不仅是为了美观，它直接决定了缓存是否能生效。

Claude Code 在实践中实现了 92% 的缓存命中率，使处理成本降低了 81%。一个固定的 10,000 token 系统提示词在第一次请求之后，实际成本几乎为零。一家客户支持应用将其产品目录从动态插入改为缓存前缀，在不改变输出质量的情况下，每月削减了 12,000 美元的 API 账单。

除了成本之外，缓存还能降低延迟。当长前缀启用缓存时，平均响应延迟从 800 毫秒降至 350 毫秒，因为模型跳过了对稳定部分注意力矩阵的重新计算。

工程开销极小：缓存窗口的 TTL 从 5 分钟（Anthropic）到大约 1 小时（OpenAI）不等。对于服务于重复用户会话的 Agent，热缓存几乎总是可用的。对于批处理流水线，应结构化作业，使批处理内的请求共享前缀。

模型路由与级联：将成本与复杂度匹配

并非每个查询都需要顶级模型。问题在于如何确定哪些查询需要 —— 答案取决于三个维度：推理复杂度、质量敏感度和上下文长度。

在典型的生产环境 Agent 工作负载中，分布大致如下：

• 60% 的任务很简单：提取、分类、格式化、模板化响应。这些任务在成本低于 1 美元/百万 token 的模型上运行良好。
• 25% 的任务需要中等程度的推理：多跳问答、代码生成、结构化分析。中端模型（0.80 - 4 美元/百万）可以很好地处理这些任务。
• 12% 的任务涉及真正的复杂度：模糊的指令、长程规划、跨异构源的综合分析。顶级模型在这些任务中物有所值。
• 3% 的任务需要顶级推理能力：新颖的问题、高风险的决策、涌现行为。

在典型的 Agent 部署中，实现良好的路由系统可降低 30-60% 的成本，而最优秀的实现方案甚至能达到 87%。

Agent 系统的实用模式是将编排与执行分离。在规划层使用昂贵模型 —— 它只读取相对较短的任务描述并做出路由决策，因此其 token 消耗是有上限的。在执行步骤中使用廉价模型：总结、提取、格式转换、检索排序。使用 Claude Haiku 执行工具调用，同时由 Sonnet 或 Opus 规划整体策略，是一种常见且有效的组合。

模型级联则更进一步：从最便宜的层级开始处理每个请求，根据标准（置信度、格式有效性、如果有检索源则检查事实依据）对响应进行评分，如果得分低于阈值，则进行升级。级联带来的额外延迟通常是值得的 —— 大多数请求在第一层就能完成，只有极少数困难请求才会触发升级。

基于置信度的路由需要一些校准。如果你是自己构建，logprob 熵对于开源模型来说是一个可用的信号。对于闭源 API，你需要一个代理评估器（通常是一个更小、更快的模型，用于检查第一个响应是否达到你的质量标准）。代理评估器的额外成本通常不到路由节省金额的 5%。

上下文压缩：缩小输入规模

上下文中的每个 token 都有直接成本。上下文压缩（Context compression）是指将上下文剥离到完成任务所需的最小限度的实践。

滚动摘要（Rolling summaries） 是最基础的技术。与其传递完整的对话历史，不如每隔 N 轮（通常为 5-10 轮）进行一次总结。摘要向下传递，完整的对话记录则被存档。这使得上下文的增长与摘要频率呈线性关系，而不是随轮数线性增长。权衡之处在于，早期轮次的细粒度细节将无法获取 —— 这对大多数用例来说是可以接受的，但对于需要记住每个决策的代码审查智能体（Agent）来说则不可接受。

工具输出屏蔽（Tool output masking） 经常被忽视。当智能体调用网页爬虫、API 或数据库查询时，原始响应通常包含与当前任务无关的标头、元数据和字段。在将这些内容插入上下文之前进行剥离，可以将工具输出的 token 减少 60-80%。为每种工具类型编写后处理器，仅提取模型真正需要的字段。

学习型压缩（Learned compression） 工具（如 LLMLingua）使用较小的模型来识别并移除低信息量的 token，从而压缩提示词（Prompt）。据报道，客户服务提示词从 800 个 token 减少到 40 个 token（减少了 95%），同时保持了可接受的准确性。注意：压缩本身需要调用一次 LLM，这会增加延迟和 token 成本。只有当压缩后的提示词在多个请求中重复使用，或者压缩器的成本远低于主模型成本时，这种方案在经济上才划算。

检索的相关性过滤（Relevance filtering for retrieval） 非常直接：不要传递所有检索到的分块（Chunks），只传递余弦相似度超过阈值的部分。将此阈值从 0.7 提高到 0.8 通常可以将检索到的 token 减少 40-60%，同时减少可能稀释模型注意力机制的噪声。

语义缓存：彻底消除调用

语义缓存（Semantic caching）存储 LLM 的响应，并以输入的向量嵌入（Embedding）作为索引。当新查询到来时，其嵌入会与缓存的查询进行比较 —— 如果相似度超过阈值，则直接返回缓存的响应，无需进行 API 调用。

在典型的生产负载中，大约 31% 的 LLM 查询表现出足够高的语义相似度，可以从中受益。缓存命中的返回时间以毫秒计，而 API 调用则需数秒，且 API 费用完全为零。对于支持类聊天机器人、常见问题解答（FAQ）系统以及查询分布高度集中的应用，语义缓存可以直接消除 20-40% 的 API 调用。

权衡之处在于对新鲜度的敏感性。对于答案频繁变化的应用，数据陈旧是一个风险。根据你的内容领域变化速度来配置 TTL（生存时间）。对于静态知识库，可以采用激进的 TTL；对于实时数据查询，应针对这些查询类型完全禁用语义缓存。

强制限制不是可选项

最廉价的优化是防止失控循环。一个有记录的生产事故：一个智能体在一个周末针对一个损坏的数据源进行了 847,000 次 API 调用，在账户因欠费被停用前累计产生了 3,847 美元的费用。另一个案例：一个智能体在五分钟内调用了 400 次爬虫工具，因为该工具返回了“可能还有更多结果” —— 智能体将其理解为继续抓取的邀请。

每个智能体在部署前都需要设置三个强制限制：

1. 每个任务的最大迭代次数。 将其设置为预期平均值的 2-3 倍。大多数智能体框架（LangGraph、AutoGen、CrewAI）都将其作为首选配置项。
2. 每个任务的最大 token 支出。 设置为在测试环境中观察到的 P95 支出的 3 倍。将其实现为中间件，在每次模型调用前检查累计成本。
3. 最大实际运行时间（Wall-clock time）。 捕捉那些通过反复进行快速、廉价的调用而保持在 token 预算内的无限循环。

模棱两可的工具反馈是导致失控循环最常见的原因。如果一个工具返回的信号可以被解释为“继续进行”，智能体就会一直运行下去。在工具输出模式（Schema）中要明确：包含一个 is_complete 布尔值或 next_action_required 字段，而不是依靠模型来推断是否终止。

FinOps：发布前必备的监测手段

成本可视化是实现闭环的关键。没有它，优化只是猜测，异常则是意外。

最小可行化的监测层应追踪以下指标：

• 单次追踪成本（Cost per trace）。 每次智能体运行都应向你的可观测性系统发送其总成本（输入 token × 单价 + 输出 token × 单价，按模型层级拆分）。
• 缓存命中率。 如果该指标低于基准值，说明你的提示词结构或请求模式发生了变化。
• 输出 token 占比。 输出 token / (输入 + 输出) token。占比上升通常意味着你的智能体过于啰嗦 —— 往往可以通过在系统提示词中加入“言简意赅”来修复（这通常能减少 15-25% 的输出 token）。
• 完成步数（Steps per completion）。 步数上升表示任务变难了，或者智能体卡住了。两者都值得调查。

Langfuse、Helicone 和 Portkey 等工具在 API 网关层面提供单次请求的成本追踪和预算控制。对于异常检测，应将支出警报设置为滚动基准值的 2σ（标准差）偏离 —— 如果你关注这个信号，大多数成本事故都可以在几分钟内检测到。

同一个智能体在未优化和深度优化后的部署方案之间，成本差异可达 30 到 200 倍。这正是目前大多数 AI 团队能做的投资回报率（ROI）最高的工程工作。

实际的优先级顺序

如果你从零开始，请按照以下顺序应用这些技术，直到达到你的成本目标为止：

1. 提示词缓存（Prompt caching）。 如果你的框架支持，则无需更改代码。将静态内容移至前缀。立竿见影。
2. 硬限制（Hard limits）。 防止出现失控事件的尾部风险，否则其他一切努力都会变得毫无意义。
3. 输出 Token 控制。 在你的系统提示词中加入“简洁回复”。监测输出 Token 比例并观察其下降。
4. 工具输出屏蔽（Tool output masking）。 为调用频率最高的工具编写后处理器。
5. 模型路由（Model routing）。 按复杂程度对任务进行分类，并将其路由到适当的层级。从简单的基于规则的分类器开始；如果业务量足够大，再升级到基于学习的路由（Learned router）。
6. 上下文压缩（Context compression）。 为长时间运行的会话实现滚动摘要。
7. 语义缓存（Semantic caching）。 如果你的查询分布具有足够的聚类特征，请添加此项。

智能体系统（Agentic systems）的默认成本与经过良好工程化后的成本之间的差距并非微乎其微。这关系到一个项目是能够投入生产，还是在预算审查阶段就被取消。