【万字长文】LLM 缓存这笔账，藏着多少猫腻？
工作目录：分章节讨论，最终合并成公众号/博客成稿。 当前状态：结构稿。 更新时间：2026-06-02。
标题
【万字长文】LLM 缓存这笔账，藏着多少猫腻？
备选副标题：
从 Claude、OpenAI、DeepSeek 到 Claude Code、中转站和 AI Agent 成本黑箱
写作目标
这篇不写成单纯的“缓存机制科普”，而是从真实使用场景出发，把缓存命中率和成本、模型选择、Agent 框架、中转站计费放在一条线上讲清楚。
核心问题：
- 为什么同样是长上下文，有人后续请求很便宜，有人每轮都像重新付费？
- 为什么 Claude Code / OpenCode / Hermes / OpenClaw 这类 Agent 工具容易出现缓存命中率不稳定？
- Claude 的 5 分钟缓存和 1 小时缓存分别适合什么场景？
- Claude 新增的 mid-conversation system messages 为什么和缓存有关？
- OpenAI、DeepSeek、Claude 的缓存机制差异在哪里？
- 中转站可能在哪里吞掉缓存收益，或者因为路由策略降低命中率？
- 用户怎么判断自己有没有被缓存、计费和模型路由坑到？
目标读者
- 正在用 Claude Code / Cursor / OpenCode / OpenClaw / Hermes 的开发者
- 用中转站接 Claude / GPT / DeepSeek 的个人和团队
- 做 AI Gateway、模型网关、企业 AI 成本治理的技术负责人
- 关注模型成本、长上下文、Agent 工程化的人
文章风格
- 技术细节要准，引用官方字段和机制。
- 少讲抽象概念，多讲“为什么账单会变贵”。
- 保留现场感，像一个长期用 Agent 的人把账拆开。
- 不用过度阴谋论，但中转站问题要讲透。
- 避免泛泛而谈，具体到 cache 字段、TTL、breakpoint、路由、workspace、tool schema。
主线
一句话主线：
LLM 缓存不是省钱小技巧，它是 AI Agent 成本结构的地基。缓存命中率低，意味着模型每一轮都在重新读取大量上下文；中转链路不透明，意味着缓存省下的钱未必省给用户。
章节拆分
0. 开场：你以为只问了一句，模型可能又读了一遍全场
目的：建立异常感。
要讲：
- AI 编程工具里，“继续”“修一下”“再跑一遍”看起来很短。
- 实际每轮请求可能带着 system prompt、tools、项目规则、历史对话、工具结果、MCP schema。
- 如果缓存命中，这些重复上下文可以低价读取。
- 如果缓存没命中，每一轮都接近重新付费。
- 文章要拆的是“缓存这笔账”。
1. 缓存到底缓存了什么
目的：讲清 prompt caching 和普通“记忆”的差别。
要讲：
- 缓存不是语义相似，不是“模型还记得”。
- 更接近 prompt prefix 的复用。
- 静态内容放前面，动态内容放后面。
- tools / system / messages 的顺序影响命中。
- 输出仍然每次生成，缓存只影响输入侧预填充成本和延迟。
关键例子：
[tools][system][project rules][history][new user message]
只要前面有一点变了，后面都可能跟着失效。
2. Claude 的缓存：强控制，也容易被自己打碎
目的：细讲 Claude。
要讲：
- Claude 需要 cache_control。
- automatic caching 与 explicit breakpoint。
- 默认 5m TTL，1h TTL 额外成本。
- 5m write = base input 1.25x；1h write = 2x；cache read = 0.1x。
- 最多 4 个 breakpoints。
- lookback window 20 blocks。
- 最小 cacheable tokens。
- usage 字段：cache_creation_input_tokens / cache_read_input_tokens / input_tokens。
- cache diagnostics beta。
核心观点：
- 自动缓存适合连续多轮。
- 显式断点适合稳定前缀 + 动态后缀。
- 把时间戳、当前状态、用户问题放进缓存前缀，会让缓存变成“每次写、很少读”。
3. 5 分钟和 1 小时：不是越长越好
目的：讲 TTL 选择。
要讲：
- 5m 适合高频连续会话、Agent 工具调用、Claude Code 连续执行。
- 1h 适合用户中途停顿、side agent 跑很久、恢复长会话、延迟敏感预热。
- 1h 写入贵，内容只用一次不划算。
- 5m 命中会刷新，不一定需要 1h。
- 混用 TTL 时，长 TTL 要在短 TTL 前面。
4. Mid-conversation system messages：为什么它是缓存相关功能
目的：解释用户关心的新功能。
要讲：
- 传统 top-level system 在最前面，改一句就打碎后面缓存。
- 新功能允许在 messages 中追加 role=system。
- 前面 prefix 不变，所以历史缓存还能读。
- 适合中途新增策略、权限、工具状态、用户插话、自动模式提示。
- 只支持 Claude Opus 4.8；Claude API 和 Claude Platform on AWS；Bedrock/Vertex/Foundry 不支持。
- 不要把工具结果、网页内容等不可信内容塞进 system message。
5. OpenAI 的缓存：自动省心，但控制感弱
目的：对比 OpenAI。
要讲：
- 自动开启，无需 cache_control。
- 1024 tokens 以上。
- exact prefix match。
- cached_tokens 字段。
- prompt_cache_key 可影响路由，提高共享长前缀命中。
- in-memory 通常 5-10 分钟不活跃失效，最长约 1 小时。
- extended retention 部分模型最长 24h。
- cached tokens 仍计入 TPM。
- 成本最高可降 90%，延迟最高可降 80%。
6. DeepSeek 的缓存：硬盘缓存和极端价差
目的：讲国产模型尤其 DeepSeek。
要讲：
- Context Caching on Disk 默认开启。
- prompt_cache_hit_tokens / prompt_cache_miss_tokens。
- fully match cache prefix unit。
- 请求边界、common prefix detection、固定 token 间隔持久化。
- best-effort，不保证 100%。
- cache construction 需要几秒。
- 几小时到几天自动清理。
- hit/miss 价格差非常大。
重点表达：
DeepSeek 的 cache hit 不是省一点钱，它可能直接决定这一轮输入是正常价格，还是接近白送。
7. Claude Code 最近的缓存相关变化
目的：讲具体工具动态。
要讲：
- Claude Code 成本来自 API token consumption。
- prompt caching、auto-compaction、context management 是核心成本优化。
- /usage 可看 token 和 cost。
- 新增/修复相关：
- ENABLE_PROMPT_CACHING_1H
- FORCE_PROMPT_CACHING_5M
- 1h TTL 曾被静默降级成 5m 的修复
- Bedrock/Vertex 1h caching 400 修复
- /model 切换会提示下一轮重新读取完整历史
- –exclude-dynamic-system-prompt-sections 改善跨用户缓存
- lean system prompt 默认化
- MCP tool definitions deferred
- sub-agent progress summaries cache_creation reduction
观点：
Claude Code 最近不少变化，本质都在围绕“让稳定前缀更稳定，让动态内容晚一点出现”。
8. 为什么 Agent 框架天然容易缓存命中率不高
目的：把 OpenClaw / Hermes / OpenCode 放进来。
要讲：
- Agent prompt 不只是用户消息。
- 动态 system prompt：时间、cwd、git branch、token budget、工具状态、平台上下文。
- 工具定义变化：MCP server、tool schema、顺序、描述。
- tool result 很大且每次不同。
- subagent 各自加载上下文，成本倍增。
- compaction 改写历史，缓存链断掉。
- provider-agnostic 框架难以为单一模型做到极致优化。
核心句：
越智能的 Agent，越容易制造动态上下文；越动态的上下文，越难命中缓存。
9. 中转站猫腻：缓存省下的钱到底给了谁
目的：文章爆点。
要讲：
- 不透传 usage 字段。
- cached input 按普通 input 收费。
- 抹掉 cache read/write/miss 字段。
- 多 key / 多 workspace / 多 region / 多上游轮询打散缓存。
- 模型别名背后切不同版本或不同供应链。
- 上游命中，用户账单不命中。
- 用户看到 token 单价，看不到缓存账本。
可靠中转站应该：
- 透传 usage。
- 区分 cache read/write/miss。
- 明确 cached input 计费方式。
- 同会话尽量粘住上游 workspace/key/region。
- 不随意改 system prompt、tool schema、model alias。
- 支持请求级账单导出。
10. 怎么判断自己有没有被缓存坑到
目的：给实用 checklist。
要讲：
- 看 usage 字段。
- 连续两三轮相同长前缀压测。
- 对比直连官方与中转站。
- 观察同一会话长上下文下 cached token 比例。
- 记录模型、key、base url、workspace、时间间隔。
- 改一个动态字段，看是否全量 miss。
- 不要只看总 token，要看 read/write/miss。
11. 模型选择和工程建议
目的：收束到选型和实践。
要讲：
- Claude：控制强，适合 Agent 和长会话，但要管好 breakpoint/TTL。
- OpenAI：自动化好，适合产品化流量，注意 prompt_cache_key。
- DeepSeek：价格敏感、长输入复用有优势，关注 hit/miss。
- 中转站：不要只看标价，要看缓存字段和计费策略。
- Agent 框架：稳定系统提示、稳定工具 schema、动态内容后置、压缩策略明确。
12. 结尾：缓存是 AI Agent 的成本地基
目的：升维。
要讲：
- 模型价格只是表层。
- 真正长期决定成本的是上下文组织方式、缓存命中率、链路透明度。
- 一个成熟 AI Gateway / Agent 框架，需要把缓存作为一等成本指标。
- 用户要从“看模型单价”升级到“看真实调用账本”。
资料来源待合并
已核实的官方信息：
- Anthropic Prompt Caching 文档
- Anthropic Mid-conversation system messages 文档
- Anthropic Cache diagnostics 文档
- Claude Code Costs 文档
- Claude Code Changelog
- OpenAI Prompt Caching 文档
- DeepSeek Context Caching 文档
- DeepSeek Models & Pricing 文档
协作方式
每次只讨论 1-2 个章节。
流程：
- 先确认章节要表达的观点。
- 写章节讨论稿。
- 用户指出删改方向。
- 修改后落入章节文件。
- 最后统一合并、顺稿、补图、生成公众号版。