在 Agent 落地的过程中，我们很快会遇到一个现实问题：效果还没跑出来，账单先跑出来了。
本文基于我们在agent项目中的真实实践，从基础认知到架构优化，系统梳理 6 个 Token 节省手段。简单方法立省 50%，高级方法降幅可达 90%+。
先搞懂 Token：你的钱到底花在哪了
Token 是 LLM 处理文本的最小单位，不是字数，也不是单词数。LLM 不直接处理文字，而是先把文本切分成 Token，再转成向量进行计算。
中文和英文的 Token 效率差异较大，同样的信息量，中英文消耗的 Token 天然不同。
原因有三：
- 1. BPE 合并频率低：中文在训练数据中占比小，常用字符组合被合并的次数更少，分词后 Token 数更多
- 2. UTF-8 编码成本：一个汉字占 3 字节，英文只占 1 字节，字节层面就是 3 倍差距
- 3. 无词间分隔符：英文有空格帮助分词，中文没有，分词器更难”猜”出边界
计费公式：四类 Token 构成总成本
Agent 的计费由四类 Token 构成，理解它们是优化的前提：
| Token类型 | 说明 | 价格水平 |
|---|---|---|
| 输入Token | 用户发送给模型的文本消耗 | 基准价 |
| 输出Token | 模型生成的回复文本消耗 | 最贵(通常是输入的3~6倍) |
| 缓存命中Token | 命中Prompt缓存时的优惠计费 | 最低（可低至输入的 10%） |
| 缓存创建Token | 首次创建缓存时的正常计费 | 与输入持平 |
Token计费
总费用 = 输入Token × 输入单价 + 输出Token × 输出单价 + 缓存命中Token × 缓存单价 + 缓存创建Token x 缓存创建单价
核心结论：输出 Token 单价最贵且无法缓存，通常是成本占比最高的部分；缓存命中是最便宜的，要想尽一切办法让更多 Token 走缓存。
简单优化：三招立省 50%，零架构改造
1 前缀匹配
LLM 的 Prompt 缓存采用前缀匹配机制：只有当本次请求的前 N 个 Token 与之前某次完全一致时，缓存才能命中。
这听起来简单，但很多团队的第一版 Agent 都踩了这个坑，把用户数据放在最前面，固定内容放在后面，结果缓存完全失效。
正确的 Token 顺序：
System Prompt（固定）→ 工具描述（固定）→ 历史对话（半固定）→ 用户消息（变化）错误的顺序：
用户消息（变化）→ System Prompt（固定）→ 工具描述（固定）顺序一颠倒，哪怕有几千个 Token 的固定内容，缓存一个都命中不了。反过来，把固定内容全部前置，缓存命中率能轻松做到 70%~90%，相当于这部分 Token 直接打一折。
2 模型分层路由:不是所有任务都需要旗舰模型
这是性价比最高的优化手段，没有之一。
核心思路：根据任务复杂度匹配不同价位的模型。 简单任务用便宜模型，复杂任务才上旗舰模型。
在我们的判责 Agent 中：
- • 主 Agent：负责调用数据读取脚本、识别诉点、分发任务给子 Agent、生成判责报告——任务偏流程化，用 Qwen3.5 足够
- • 子 Agent：负责核心的逻辑推理和判责——任务复杂度高，用 Qwen3.7-plus
主 Agent 承担了大部分交互和流程调度，用便宜模型后，这部分成本直接下降一个数量级。而真正需要推理能力的判责环节，依然保持旗舰模型的质量。
估算一下：如果主 Agent 占 60% 的调用量，模型价格差 5 倍，那光这一项就能省 50% 以上的总成本。
3 语言匹配：中文任务用中文原生模型
这一条容易被忽略，但效果惊人。
英文任务用英文语料训练的模型，中文任务用中文语料优化的模型。 这不是性能问题，而是成本问题；中文原生模型的分词器对中文的压缩效率高得多。
选择中文原生模型（Qwen、DeepSeek、GLM 等）可省 30%~50% Token 数量，再叠加单价优势，总成本可降至 GPT 系列的 1/5 左右。
原理很简单：中文原生模型在训练数据中中文占比高，BPE 合并频率更高，同样的中文文本能被压缩成更少的 Token。
本章小结：三个简单方法——前缀匹配利用缓存省 50%~70%，分层路由按复杂度匹配模型省 50%+，语言匹配通过分词器效率省 30%~50%。叠加使用，成本砍半起步。
高级优化：从架构层面降本，降幅 90%+
下面三个方法需要一定的架构改造，但收益也更大。
1 脚本优先原则——AI 是大脑，不是手
结构化任务永远不要让大模型来做。
定时检查、数据获取、API 调用、数据处理、排版格式化——这些任务脚本比大模型更便宜、更快、更稳定。
在我们的判责 Agent 中，数据读取和判责报告排版全部用脚本完成，效果如下：
- • 成本：脚本执行 0 Token 消耗，成本几乎为零
- • 稳定性：用大模型通过 MCP 读取数据时，有约 15% 的概率失败；改用脚本后，这个问题彻底消失
- • 速度：脚本读取数据 1~2 秒完成，比大模型调用快得多
判断标准很简单：如果一件事能用 if-else 和正则搞定，就别让 LLM 插手。 LLM 应该只做它真正擅长的——理解、推理、生成。
2.Workflow 编排——按需加载，拒绝全量上下文
传统的 Agent 工作流是静态的：每次请求都加载全部工具定义、全部记忆文件、全部上下文，不管当前任务是否需要。
Dynamic Workflow 的核心思想是：按需加载、动态编排。 只把当前步骤真正需要的资源注入上下文。
在判责 Agent 中，我们发现主 Agent 的工作完全是流程化的：
读取数据 → 识别诉点 → 分发任务给子 Agent → 接收结果 → 整理成报告这种流程化的调度，用 Workflow（一个 .js 文件）完全可以替代主 Agent，主 Agent 的 Token 消耗直接降为 0。
Workflow 只做三件事：
- 1. 根据关键词判断场景类型
- 2. 把数据传给对应场景的子 Agent
- 3. 汇总子 Agent 的结果，生成报告
整个过程零 LLM 调用，零 Token 消耗。
3 信息检索增强——全量塞上下文是最大的 Token 黑洞
当 Agent 需要访问大量文档（知识库、代码库、笔记）时，传统的”全量塞进上下文”是 Token 消耗的最大黑洞。
举个例子：MEMORY.md 超过 2000 tokens，如果 Agent 每次查询都全量读取，50 次查询就是 10 万 tokens。而真正相关的内容可能只有几十字。
解决方案：用检索增强（RAG）替代全量读取。
我们使用的是 QMD（Quantum Memory Database）——一个本地语义搜索引擎，专为 Markdown 文件设计，完全本地运行，零 API 成本。
核心架构是三层混合搜索管线：
- 1. BM25 全文搜索：精确关键词匹配，~10-50ms
- 2. 向量语义搜索：理解语义相似性，~50-200ms
- 3. LLM 重排序：交叉编码器精选最终结果，~100ms
通过 RRF 融合排序合并结果，只返回 Top-5 最相关的片段。
效果：从”全量读取”到”精准检索”，Token 消耗降幅可观。
总结：看懂 Token 优化全景
Token 优化不是玄学，核心思路就三条：减少输入、多命中缓存、减少输出。
推荐的实施优先级（从易到难、从高 ROI 到低 ROI）：
- 1. 先做监控：没有度量就没有优化。先把每次调用的模型、输入/输出 Token、成本、功能模块都记下来，找到成本大头
- 2. 简单方法先上：前缀匹配 + max_tokens + 响应缓存，半天搞定，通常能省 30%~50%
- 3. 模型路由：按任务复杂度分级选模型，性价比最高的一步
- 4. 架构改造：脚本优先 + Workflow ，根据业务场景选做
- 5. 极致优化：批量处理、自托管、量化、推测解码，量大了再考虑
最后一句话：Token 优化的本质是资源的精准配置——该花的地方不省，该省的地方不花。把昂贵的 LLM 算力用在真正需要推理和理解的环节，其余一切能脚本化就脚本化、能缓存就缓存、能检索就检索。
本文作者@货拉拉技术，原文链接：https://mp.weixin.qq.com/s/JTdwHzjZN8jke0tjiks8nQ