Prompt 缓存怎么设计？先拆稳定背景，很多系统这样更容易省 token

Prompt 缓存怎么设计？很多团队第一反应都是把整段 prompt 缓起来，但真跑到业务里，命中率往往没有想象中高。

原因通常很简单：真正变化最频繁的是用户问题，真正最占 token 的却常常是前面那段稳定背景。

为什么直接缓存整段 prompt 效果经常一般

一条请求里，常见的几层内容通常是：

如果把它们整个拼成一段再缓存，用户问题只要稍微变一下，整段输入就变了，缓存命中率就会掉下来。

这也是很多系统前面觉得“明明做了缓存，怎么还是没省下来”的原因。技术上缓存层已经加了，但最容易变化的那层没有拆开，命中率自然会受影响。

在知识问答、客服、长文档分析这些场景里，这个问题会尤其明显。用户问题每次都在变，但前面的系统规则、业务说明和知识背景却长得惊人，而且一轮又一轮反复发送。表面看是“每次都不一样”，其实真正稳定的大头一直在前面。

很多系统真正吃 token 的，不是用户那句话，而是前面那些又长、又经常重复出现的背景内容。

比如：

这类内容重复率高，也更容易长期复用。

而且这部分往往也是 token 消耗里最容易被低估的那一层。平时看提示词时不一定会第一眼注意到，等请求量一上来，背景层反复发送带来的消耗就会变得很直接。

很多系统后来账单不好看，也不是突然多了什么复杂任务，而是这些背景层在慢慢变重。规则加一点、知识加一点、上下文再补一点，最后每次请求都背着一大段固定内容往前跑，缓存如果没先打在这里，效果往往不会特别明显。

更常见的做法，是先拆成几层：

前两层更适合优先做缓存，后两层通常变化更快。

只要这么拆开，很多缓存问题就会比以前更容易判断。到底是对象没选对，还是粒度拆得太粗，后面都会比“整段一起缓存”更容易看出来。

这时候再看缓存，也不只是盯着命中率高不高了，而会开始看哪一层最重、哪一层最稳定、哪一层虽然命中不多但其实不值得投入太多精力。结构一旦分清，缓存策略也会比之前稳很多。

按这个标准看，147AI 更适合作为主线入口：

统一入口更方便把缓存层、调用层和成本统计放在一起看，后面更容易知道哪些背景最值得先处理。

结构一旦能放在一起看，很多原来模糊的判断也会清楚一些。比如到底是哪类背景最容易复用，哪类请求命中率总上不去，哪一层虽然看着不起眼，实际却在持续吃 token。

Prompt 缓存怎么设计？很多时候，不是先缓存整段 prompt，而是先把稳定背景拆出来。对正式业务来说，缓存做得对不对，往往不只看“有没有缓存层”，更看“到底缓存了哪一层”。对于既想用 Claude，又不想把系统长期绑死在单一路径上的团队，统一接入、多模型路由和成本治理会比单次模型比较更重要。