Prompt Cache 为什么变成了商业瓶颈
原因一：上下文长度的军备竞赛
Gemini 2M、DeepSeek V4 的 1M、Llama 4 的 10M 标称——背后都是 KV 缓存的工程问题。一个 70B 模型在 128K 上下文下，未经压缩的 KV 缓存能占几十 GB 显存，比模型参数本身还重。没有架构层的压缩方案，"百万上下文"只是 PPT 数字。
原因二：Agent 应用的结构性需求
ReAct 循环、多轮工具调用、Computer Use、Claude Code 这类工作流都是"前缀长、追加短"的模式：同一段 system prompt + 历史对话被反复送进模型。Prompt Cache 由此成为可计价资源——四家头部厂商都把缓存命中部分单独定价，命中折扣从 1 折到 5 折不等，直接重写了 Agent 应用的单位经济模型。
原因三：缓存命中率 = 成本放大器
一位开发者对 Claude Code 一周使用数据的追踪显示：正常情况下 91% 的 Token 来自缓存命中，缓存命中价格只有标准输入价格的十分之一。如果缓存全部失效，Input 成本会暴涨到原来的 5.7 倍。
这是一个惊人的杠杆。缓存命中率不是"性能优化指标"，而是直接的利润指标。91% vs 0% 的命中率差距，意味着同一个工作流，成本可以是 5-10 倍的差别。
2026年2月的"缓存命中率争议"
2026 年 2 月，Claude Code 的一次更新导致第三方平台的缓存命中率大幅下降。随即有人质疑 Anthropic 是否故意破坏第三方模型的缓存。
一位工程师用 AI 工具下载了 Claude Code v2.1.0 到 v2.1.41 共 11 个版本的源码，逐一分析。结论是：代码中不存在针对第三方模型的蓄意破坏逻辑。但从 v2.1.23 开始，Claude Code 引入了 Claude 专属的分块缓存机制，"跨 session 全局共享、1 小时有效期"这些优化改变了 system prompt 的结构，第三方模型的 API 无法识别这些标记，只能依赖最基础的前缀匹配，而前缀恰恰因为版本号、构建时间、A/B 测试变量的持续变化而高度不稳定。
用通俗的话说：Anthropic 没有主动"投毒"，但它在优化自家模型效率的过程中，作为副作用，破坏了第三方模型原本依赖的缓存条件。
这件事暴露了一个深层问题：缓存命中率不是纯技术问题，而是厂商博弈的战场。当头部厂商把缓存机制内嵌到产品层时，第三方平台和开发者面临的不仅是技术适配问题，而是信息不对称和定价权丧失。
---
> 核心发现：Prompt Cache 已完成从"技术优化"到"商业基础设施"的转移。Agent 应用的经济模型正在被它重写——过去算成本用"每百万 Token 多少钱"，2026 年要用"每百万缓存命中 Token 多少钱"。