Claude Code 省 Token 指南：模型、MCP、CLAUDE.md 和 Skills 怎么影响缓存

Mon, 18 May 2026 18:30:24 +0800

Claude Code 长任务里，Prompt Cache 命中率会直接影响成本和速度。很多人只知道“缓存能省 Token”，但不清楚哪些操作会让缓存突然失效。

理解它并不难：每次请求都可以看成一条从左到右的上下文链条：

`1`	`tools -> system -> CLAUDE.md / skills -> messages`

越靠左的内容越稳定，缓存收益越大；越靠左的内容一变，后面的缓存也更容易跟着失效。反过来，越靠右的内容变化，影响范围越小。

所以优化 Claude Code 的 Prompt Cache，不是靠玄学，而是靠一个原则：任务开始前把模型、MCP、Skills、CLAUDE.md 等基础上下文准备好，任务中途尽量不要改。

Prompt Cache 缓存的不是文字本身

Prompt Cache 不是简单地把提示词字符串存起来。对 Transformer 模型来说，更关键的是前缀上下文经过注意力层计算后的 Key/Value 状态，也就是常说的 KV cache。

这意味着两个事实：

同一段上下文，只要前缀保持稳定，就可以在后续请求中复用一部分计算结果。
如果模型、工具定义、系统提示词或前缀消息发生变化，之前的缓存就可能无法复用。

Anthropic 官方文档也把失效层级概括为 tools -> system -> messages。工具定义变化会影响整段缓存，系统层变化会影响 system 和 messages，messages 层变化则主要影响消息缓存。

Claude Code 里还会额外涉及 CLAUDE.md、Skills、MCP、插件和子代理等上下文，所以实际使用时更容易踩到缓存失效点。

缓存杀手一：中途切换模型

切模型是影响最大的操作。

Prompt Cache 是按模型隔离的。Opus、Sonnet、Haiku 这类模型的结构和权重不同，同一段文本算出来的 KV cache 也不同。你在 Opus 里跑了很长上下文，再切到 Sonnet，并不能让 Sonnet 复用 Opus 的缓存。

这会带来一个反直觉结果：中途为了省钱切模型，可能反而让前面已经积累的缓存全部失效。原本可以按 cache read 价格读取的上下文，需要重新写入和计算。

更稳妥的做法是：

主对话尽量固定一个模型。
需要便宜模型处理支线任务时，用 subagent 隔离出去。
让支线代理完成搜索、探索、整理，再把结果摘要交回主对话。

这样主对话的长上下文尽量不动，缓存命中率更稳定。

缓存杀手二：中途新增 MCP 或重载插件

MCP 会向 Claude Code 提供工具。新增 MCP 服务器后，工具列表会变化，而工具定义处在上下文链条最左侧。

从 Prompt Cache 的角度看，工具列表一变，后面的 system 和 messages 都可能需要重新计算。尤其是 MCP 很多时，工具定义本身就可能占用大量 Token，缓存失效的代价会很明显。

不过有一个细节：Claude Code 通常在会话启动时读取 MCP 配置。你中途改了配置，当前 session 不一定立刻受影响。真正需要小心的是触发重新加载的动作，例如重启、恢复会话、重新加载插件或让工具列表重新组装。

建议是：

开始长任务前，一次性装好需要的 MCP。
不要做一半才发现缺工具，再安装并重载。
对大型 MCP 工具集，优先考虑按需加载或减少默认启用数量。
不常用的 MCP 不要长期挂在默认配置里。

如果工具定义稳定，Prompt Cache 才有长期命中的基础。

缓存杀手三：中途修改 CLAUDE.md

CLAUDE.md 是 Claude Code 的项目记忆文件，适合放构建命令、测试命令、架构约定、代码风格和项目注意事项。

它对 Claude Code 很有用，但也会进入上下文。官方帮助文档说明，CLAUDE.md 会在 session 开始时读取，并作为用户消息提供给 Claude；它也会使用 Anthropic 的 Prompt Cache。首次请求会按完整输入计费，后续请求如果在缓存有效期内命中，就按更低的 cache read 成本处理。

问题在于：CLAUDE.md 是内容寻址的。你一改文件内容，旧缓存就对不上了。

所以不要在长任务中途频繁改 CLAUDE.md。更好的方式是：

任务开始前先检查 CLAUDE.md 是否够用。
把稳定规则写进去，把临时指令放在当前对话里。
如果只是一次性任务，不要为了临时需求修改长期记忆文件。
如果必须改，最好在一个阶段结束后再开始新 session。

CLAUDE.md 应该是稳定的项目说明，而不是每轮任务都改的便签。

缓存杀手四：中途安装或更新 Skills

Skills 也是上下文的一部分。安装新 Skill、更新 Skill，或者让 Skill 列表发生变化，都会让注入到会话里的上下文不同。

这类变化通常不会在当前 session 里立刻完整生效，而是在重新加载、恢复会话或新开会话时体现出来。问题是，一旦重新组装 messages，旧缓存就可能命中不了。

建议和 MCP 类似：

开始任务前先确认需要哪些 Skills。
同一类任务尽量固定 Skill 集合。
不要在一个长任务中途边做边装 Skill。
如果安装了新 Skill，最好把它当成新阶段的开始。

对经常做内容生产、代码审查、部署、翻译的工作流，可以把常用 Skills 固定下来，让上下文结构尽量稳定。

缓存杀手五：空闲时间超过 TTL

Prompt Cache 不是永久保存。常见默认有效期是几分钟级别，Anthropic 文档和 Claude Code 相关说明里都提到过 5 分钟左右的缓存窗口。超过 TTL 后，即使你发送完全一样的请求，服务端也可能已经清掉缓存。

这也是很多长任务用户的体感来源：刚才还很省，去喝杯咖啡回来，再发下一步，Token 又突然涨上去了。

长任务尤其容易遇到这个问题。你可能要看 Claude Code 的输出、检查文件、跑测试、思考下一步，这些操作一不小心就超过 5 分钟。

如果你的使用环境支持，可以在长任务前启用 1 小时 Prompt Cache TTL：

`1`	`export ENABLE_PROMPT_CACHING_1H=1`

在 Windows PowerShell 里可以写成：

`1`	`$env:ENABLE_PROMPT_CACHING_1H="1"`

需要注意的是，1 小时缓存写入成本通常会高于 5 分钟缓存写入成本。它不适合所有短任务，但对大型代码库、长对话、复杂多步骤开发任务，往往比频繁缓存过期更划算。

怎么安排一次更省 Token 的 Claude Code 长任务

比较稳的流程可以这样做：

任务开始前选定模型，不要中途频繁切换。
提前启用需要的 MCP，不用的 MCP 先关掉。
检查 CLAUDE.md，只保留稳定、关键、长期有效的规则。
提前准备好本次任务需要的 Skills。
如果是复杂任务，考虑启用 1 小时 TTL。
把大任务拆成几个阶段，但每个阶段内部尽量保持上下文结构稳定。
需要探索支线问题时，用 subagent 或单独 session，不要污染主对话。

这套做法的目标不是绝对不让缓存失效，而是避免那些代价最高、最容易被忽略的失效。

一个简单判断标准

你可以用一句话判断某个操作是否危险：

这个操作会不会改变模型、工具定义、系统上下文或会话开头的固定消息？

如果答案是会，那它大概率会影响 Prompt Cache。越靠近上下文链条左侧，影响越大。

常见操作可以这样理解：

切模型：高风险，模型缓存隔离。
新增 MCP 或重载插件：高风险，工具列表变化。
修改 CLAUDE.md：中高风险，项目记忆变化。
安装 Skills：中高风险，注入上下文变化。
普通对话继续追问：低风险，主要追加 messages。
空闲超过 TTL：高风险，服务端缓存过期。

小结

Claude Code 的 Prompt Cache 优化，关键不是背参数，而是让会话前缀稳定。

模型不要随便切，MCP 和 Skills 不要边做边装，CLAUDE.md 不要当临时草稿频繁改，复杂任务尽量延长 TTL。只要这些基础动作稳定下来，Claude Code 在长任务里的 Token 成本和响应速度都会更可控。

最实用的一句话是：开始前配好，开始后少动。

Token优化 on KnightLi的博客