3.10 实践指南：如何高效利用 KV Cache

理解了前缀缓存架构，反过来看：作为用户，哪些习惯能最大化缓存命中率（响应更快、成本更低），哪些操作会无意中"打碎"缓存？

缓存友好的使用习惯

1. 保持对话连续性，避免长时间中断

普通用户的缓存 TTL 是 5 分钟（付费订阅用户是 1 小时）。这意味着如果你离开超过 5 分钟再回来发消息，服务端的 KV Cache 已经过期——整个前缀（system + tools + 所有历史消息）需要从头计算。你会明显感觉到第一次回复变慢。

实践建议：如果需要短暂离开思考，尽量控制在 5 分钟内回来继续对话。如果预计要离开较久，接受回来后第一轮会稍慢——这是 TTL 过期的正常现象，后续轮次会立即恢复正常速度。

2. 如果是具有相关性的任务下，长对话优于频繁新建会话

每次新建会话都是一次完全的冷启动——50-100K token 的系统提示词和工具定义需要从头处理。而在同一个会话中继续对话，这些前缀都已经在缓存中了，每轮只需处理新增的消息。

实践建议：尽量在同一个会话中完成相关工作，而不是为每个小任务都新开一个会话。如果你同时有多个 Claude Code 会话，会话之间的缓存也是独立的——它们不能共享消息历史的 KV Cache（系统提示词部分的缓存可以跨会话共享）。

3. 让自动压缩替你管理上下文

Claude Code 内置了五级压缩流水线，会在上下文接近窗口限制时自动触发。你不需要手动干预——系统知道最佳的压缩时机和策略。

实践建议：看到上下文使用率警告时不必紧张，让系统自动处理即可。只在你明确想"重新开始一段相关的对话逻辑"时才手动使用 /compact，如果相关的逻辑可以直接 /clear。

4. 精简 MCP 工具安装

这是很多用户不知道的：只要有 MCP 工具实际渲染进工具数组（未被 defer_loading 延迟加载），整个系统提示词的缓存就会从 global（全球共享）降级为 org（组织内共享）。这意味着你无法享受全球数百万用户共享的系统提示词缓存——每次冷启动都需要独立计算。（被 Tool Search 延迟加载的 MCP 工具不会触发降级，见 3.6。）

实践建议：只安装你真正在用的 MCP server。如果某个 MCP server 只是偶尔用一次，考虑用完后移除。MCP 工具越少，缓存效率越高。

频繁切换模型

不同模型在服务端使用不同的 KV Cache 空间。如果你在同一个会话中频繁切换模型（比如从 Opus 切到 Sonnet 再切回来），每次切换都无法命中之前模型的缓存。

实践建议：在一个会话中尽量使用同一个模型。如果需要切换，可以考虑开一个新会话。

缓存效率的心智模型

最后，用一个简单的心智模型来总结：

你的每次请求 = [已缓存的前缀] + [新增的内容]
                ~~~~~~~~~~~~     ~~~~~~~~~~~~
                免费（已有 KV Cache）   需要计算（消耗时间和成本）

你的目标是最大化"已缓存的前缀"部分。做到这一点的核心原则就是保持稳定性——保持会话连续、避免不必要的重置、减少会改变前缀的操作。前缀越稳定，缓存命中率越高，响应越快，成本越低。