注意：OpenClaw 6 月版本会干掉 DeepSeek 缓存命中

写在前面

我是 OpenClaw 用户，跑了半年多没出啥大事。6月22日手贱升了个级，然后 DeepSeek 的账单就不对劲了。

简单说：升级到 6月版本后，DeepSeek 缓存命中率暴跌，原来能缓存的请求全不中了。

数据对比

同一台机器、同一个工作流，升级前后的 token 消耗对比：

升级前 — 2026-06-10（5月稳定版）

总消耗：113,081,049 tokens
✅ 输入命中缓存：108,882,816 tokens
输入未命中缓存：3,870,472 tokens
模型输出：327,761 tokens
命中率 96.6%，缓存极其充分

升级后 — 2026-06-22（6月版本）

总消耗：114,824,887 tokens
✅ 输入命中缓存：80,983,808 tokens
输入未命中缓存：33,538,748 tokens
模型输出：302,331 tokens
命中率 70.5%，未命中从 3.8M 飙升到 33.5M，翻了 8.6 倍

升级前后总 token 量差不多（113M vs 114M），但未命中从 3.8M 涨到 33.5M，这些多出来的全部被重复计费。

排查过程

开始我以为是 DeepSeek 那边改了策略，去查了官方文档，对方说没动过。然后就去翻 OpenClaw 的 Release Note。

6月版本的 changelog 里有一行被我一扫而过的改动：

• 压缩上下文 — 说是为了省 token，减少冗余上下文传递
• 请求体优化 — 调整了传给 LLM 的请求格式

看上去都是好事对吧？

问题就在于：DeepSeek 的缓存命中依赖请求体的精确匹配。你只要在请求体里改一个空格、一个换行，甚至字段顺序变了，缓存就算不上。

OpenClaw 6月版本做了上下文压缩和请求结构优化，虽然省了传输量，但把请求体改得跟之前不一样了，DeepSeek 那边就认不出来了。

说白了：省了几 KB 的传输，废了几百倍的缓存。

从数据上看，升级前输入未命中只有 3.8M，升级后膨胀到 33.5M。这些多出来的未命中 token 全都被重复计费，一天多出的成本非常可观。

我的建议

如果你在用 OpenClaw + DeepSeek，并且依赖缓存来省成本和加速：

• 别急着升 6月版本。蹲一下社区反馈，等官方修了再升
• 已经升了的，可以试试回滚到 5月稳定版。我是直接降回来了，命中率立刻恢复
• 或者，在 OpenClaw 配置里关掉上下文压缩（如果支持的话），但我不确定这样能完全恢复缓存命中

一点看法

压缩缓存是个好的优化方向，但要分场景。对 OpenAI 这种按 token 计费、不依赖请求体哈希缓存的模型，压缩可能很香。但对 DeepSeek 这种靠请求体精确匹配来命中缓存的模型，压缩就是在拆缓存。

建议官方加一个开关，让用户自己选要不要压缩，而不是一刀切。

降级见。