Prompt Cache 总是没命中？先检查前 100 个字符

我做了两个最小请求：系统角色、工具列表和输出 Schema 共 94 个字符，动态日期与用户问题各不相同。把动态内容放在最后，两次请求有 112 个连续相同的开头；把日期挪到最前面，相同前缀只剩 18 个字符。

这不是一次真实计费 API 压测，也不能代表平台 Token 数；它只验证字符串结构。缓存系统看到的是从开头开始能复用多远，“整体内容差不多”没有用，前面一处分叉就会截断后面的复用。

OpenAI 官方文档明确写着：缓存命中只可能发生在精确前缀匹配时，静态指令与示例应放前面，用户信息等变量放后面；图片和工具也要保持一致。符合条件的近期模型会自动使用缓存，应用应通过 `cached_tokens` 观察读取量；GPT-5.6 及以后还可结合 `cache_write_tokens` 看写入成本。

工具定义换序、Schema 字段重排、系统提示插入当前日期，都可能让命中点提前。缓存键能帮助路由相同前缀的请求，却不能把不同前缀变成相同。

我会把请求分成四层：系统规则、工具和输出 Schema；项目术语与公共资料；会话里已经确认的决定；最后才是用户问题、时间戳、权限信息和实时检索结果。越稳定、复用越多的内容越靠前。

JSON 也要稳定序列化。对象语义相同而字段顺序不同，在字节层面仍是不同前缀；工具列表不要每次由无序集合生成。版本号可以放在稳定层，但只有规则真正变化时才更新。

Claude 支持自动缓存，也允许用 `cache_control` 在内容块上设置显式断点；适合在大段静态资料后接持续变化的问题。Gemini 同时提供隐式与显式 Context Caching，支持模型、最低 Token 和有效期会变化。

三个平台都奖励复用，却在写入方式、门槛、有效期和用量字段上不同。跨平台封装时，不要只抽象一个 `cache: true`；至少保留平台策略、缓存前缀版本与实际读取量。

一份只调用一次的长报告，前缀再稳定也不会产生第二次读取；很短的提示可能达不到平台门槛；大量请求同时冷启动，也不能假定第一条尚未建立的缓存已经可用。缓存不会减少输出 Token，更不会修复糟糕的任务拆分。

上线前连续发送两次只有末尾问题不同的请求，记录模型、前缀版本、输入量、缓存读取量与时间。命中下降时先比较工具、Schema 和系统提示，而不是凭“好像变慢了”猜缓存失效。

如果前 100 个字符每次都在变，先别研究高级参数。把变化移到后面，往往就是最有效的第一步。