大模型 API 费用居高不下？问题不在模型本身，而在每次请求都在重复计算已经算过的内容。这篇文章把 Token 优化拆成两个维度——API 层的 Prompt Caching 和 Context 层的工程管控，给出每条路径的核心原理和具体做法。

API 账单从 ¥3000 到 ¥300：Token 优化的正确打开方式

用大模型 API 的人都有这种体验：月初充了 ¥3000，月中见底。看账单才发现，大头不在模型回答本身——而是每次请求都在重新计算已经算过的内容。

这叫 Prompt Caching 问题。但它只是故事的一半。

另一半更隐蔽：当你用 AI Agent 写代码时，Agent 自己跑 npm install、grep 整个仓库、读几百行日志。如果没人告诉它"长输出别全读进上下文"，300 行的构建日志一轮就烧掉 15k tokens——不是多花钱，是 Agent 直接忘了你十分钟前说过什么。

这篇文章把 Token 优化的两个维度拆开，给出每条路径的核心思路和具体做法。

一、两个维度，别搞混

聊 Token 优化时，人们经常把两件完全不同的事混在一起：

简单说：API 缓存让 Provider 少收你钱，Context 管控让你的 Agent 脑子不被垃圾塞满。 两者互补，但机制完全不同。

二、API 层：让 Provider 少收钱

2.1 Prompt Caching 是什么？一个"开卷考试"的比喻

想象一场开卷考试。老师允许你带课本进去。

没有缓存的 AI：老师每问你一道题，你都必须把课本从头翻到尾读一遍，再回答。问 100 道题，就读 100 遍。每次翻书的时间都是算钱的。

有缓存的 AI：你第一次把课本读了一遍，在脑子里记住了重点。接下来老师问 100 道题，你直接用脑子里的记忆回答，不需要再翻书了。

这就是 Prompt Caching：对于 AI 读过的内容，只要没变，第二次就直接调用记忆，不再重新读一遍。

技术上说，模型第一次处理你的 prompt 时，会把它编码成一组中间计算结果，叫 KV Cache。如果下一次请求的前半部分和上次一模一样，模型直接复用上次的 KV Cache，跳过重复计算——你也跳过那部分费用。

能省多少？以 Anthropic 为例：

• 普通输入价格：$3.00 / 百万 Token
• 缓存读取价格：$0.30 / 百万 Token（打 1 折）

意思是：如果你在一份长文档上进行多轮对话，除了第一次需要付全价，后面每一次都只要原来十分之一的钱。

2.2 黄金规则：让固定的东西排在最前面

缓存有一个苛刻的条件：前缀必须在字节级别完全一样。 一个空格、一个时间戳、一行换行符不同——整个缓存报废。

打个比方：

✅ 能命中缓存：
[固定的系统提示词] + [用户问题 A]
[固定的系统提示词] + [用户问题 B]
→ 系统发现前半段一样，直接复用

❌ 命中不了：
[用户问题 A] + [固定的系统提示词]
→ 开头变了，后面全废

所以最重要的规则只有一条：稳定的放前面，变化的放后面。 把系统提示词、工具定义、参考文档这些不容易变的内容放在 prompt 开头，用户输入、时间戳、会话 ID 放在末尾。

两个最常见的翻车：

翻车 1：system prompt 第一行写了 当前时间：2026-07-02 00:03:47。每次请求第一行都不同，缓存命中率 = 0%。正确做法：时间戳放 user message 末尾。

翻车 2：每轮对话动态增删 tools——这轮只允许查天气，下轮加了发邮件。工具列表变了 → 前缀全废。正确做法：工具列表固定不变，用 allowed_tools 控制每轮权限。

2.3 具体做法

隐式缓存（DeepSeek / OpenAI）：什么都不用写，但需要做一次前缀稳定性检查——确保系统提示词、记忆索引、工具定义的内容和顺序每次会话一致，把时间戳、随机 ID 等动态内容挪到末尾，消除重复条目。

显式缓存（Anthropic 等）：在 system prompt 最后加一个 cache_control 断点标记，断点前的内容全部走缓存读取（~0.02× 原价），只对每篇不同的用户输入付全价。

三、Context 管控：别让 AI 脑子被垃圾塞满

API 缓存帮你省了钱，但还有另一个更头疼的问题。

AI Agent 的"工作记忆"是有限的。200k 的上下文窗口看起来很大，但系统提示词吃几万、工具定义吃几万、记忆索引吃几千——再跑几轮工具调用，很快就满了。

更糟的是：上下文被垃圾填满后，AI 开始"忘事"——它不记得你十分钟前让它干什么。这不是多花钱的问题，是直接变蠢了。

打个比方：你的办公桌就那么大。如果每次开工都把昨天的报纸、喝完的咖啡杯、不用的文件夹全堆在上面，真干活的时候连键盘都没地方放。

Context 管控就是帮你清理桌面。三条规则。

规则 1：工具的"废话"别全看

Agent 跑 npm install 能输出 300 行，grep 整个仓库能返回 500 行——但 90% 的内容跟你当下的任务无关。

做法：重定向到文件，只看摘要。 就跟你看日报只看标题和摘要一样，感兴趣再点进去看全文。

效果：单次长命令省 5-20k tokens 的上下文空间，整体约省 20-30%。

规则 2：工具挂载多了，脑子就不够用了

AI Agent 用的每个工具，它的说明书都占上下文。挂 20 个工具全开，200k 的窗口实际可用只剩 70k。

做法很简单：装可以装很多，但干活时只开需要的。 设定硬上限——同时开不超过 10 个工具。始终在线的只留几个核心的。需要部署时再开部署工具，用完不关但下次任务重新判断。

还有一个容易被忽略的：能一句话搞定的事，别走工具封装。就像你想查时间，直接看手表就行，不用打开手机 → 解锁 → 天气 App → 下滑看时间。

规则 3：记忆别记废话

Agent 的跨会话记忆也不是免费的——下次启动时它要先读完所有记忆索引。记太多跟没记一样糟糕。

存入前先问一句："这件事下次 AI 自己搜代码 / 跑 git log 就能知道吗？"如果是，别存。

外加一个时效：7 天以上的记忆加载时提醒"可能过时了"，30 天以上的自动归档。记忆是历史快照，不是真理。

四、进阶：基础扎实后还能做什么

三套规则落地后，如果 token 消耗不再下降，可以再往上加两层。

语义任务记忆：把历史 session 的内容提取关键词，构建一个 TF-IDF 倒排索引（Python 标准库即可，不需要向量数据库）。之后遇到问题先搜一下之前有没有解决过。关键细节：索引按"追加不重排"维护，确保索引本身也是缓存的稳定前缀。

上下文预算可视化：从 transcript 文件大小实时估算 token 数（文件字节数 / 4），显示使用百分比。60% 提醒，80% 强制 compaction。关键设计：compaction 前把文件变更、任务目标、关键决策序列化保存，新 session 自动注入——compaction 不再等于永久遗忘。

五、一个核心认知

Token 优化很容易陷入"攒技巧"的陷阱——学了一堆缓存策略、压缩工具、阈值调参，但忘了本质。

本质是两条纪律：

1. 前缀稳定性是地基。 不管你用的是隐式缓存还是显式缓存，如果你连 prompt 前缀的确定性都保证不了，花再多精力调缓存参数都是白费。
2. 不进上下文的信息才是最好的优化。 最省 token 的办法不是"压缩后再进"，而是"根本不让它进"。工具输出截断、记忆禁令、MCP 限流——这些规则的价值不在于技术实现有多精巧，而在于它们在你每次操作时都在起作用。

反过来，这两条都不是工具问题，是习惯问题。Stable prefix 靠的是不手贱在开头加时间戳。Context 管控靠的是每次跑命令习惯加重定向。记忆瘦身靠的是写入前多问一句"grep 能查到吗"。

工具能帮你执行。但真正决定 Token 消耗的，是你有没有把这些原则变成每次操作的默认行为。

写到这里差不多了。如果你读完有收获，动动手指点个赞和在看，转发给正在为 API 账单头疼的朋友，说不定正好帮他省下一笔。还没关注的，可以顺手星标一下⭐，下次更新第一时间收到。

我们下篇文章见。

作者：Hookoon