缓存命中率98%：长对话智能编程的成本控制实践

在高强度使用智能编程助手进行日常开发时，很多开发者会遇到一个共同的困惑：为什么同样是一整天的编码任务，有的人花费不菲，有的人却能把成本压到极低？除了模型本身的定价差异之外，一个常被忽视但影响巨大的变量，就是输入缓存命中率。

近期在开发者社区中，有不少同行反馈，在长时间对话、工具调用密集的场景下，模型表现会逐渐不稳定，工具调用失误率上升，缓存命中率下降，最终导致费用快速攀升。而与此同时，也有一些开发者通过一系列工程手段，把缓存命中率长期稳定在 96% 以上，甚至达到 98.45% 的水平。对于一整天高强度、甚至并发多开的 C++ 开发来说，总花费可以控制在二十几元人民币左右。

这篇文章将系统性地拆解这套方法背后的设计思路，重点讨论三个层面：系统提示词的稳定性设计、工具集的最小化与模糊匹配能力，以及记忆与上下文压缩的正确处理方式。这些手段并不依赖某个特定平台的独有能力，而是通用的工程实践，任何使用大模型进行长对话开发的团队都可以参考。

---

一、为什么缓存命中率决定了你的账单

在讨论具体做法之前，有必要先理解缓存命中率为什么如此关键。

大模型的推理成本主要由输入 token 和输出 token 两部分构成。在智能编程这类场景中，输出 token 往往只占很小一部分，真正的大头是每一轮对话都要重新传入的上下文。随着对话轮次增加，上下文会不断累积：系统提示词、工具定义、历史消息、文件内容、工具返回结果……这些内容每一轮都要被重新计算。

如果没有任何缓存机制，第 N 轮对话的成本会随着上下文线性增长。而输入缓存的核心思想是：如果相邻两轮请求的前缀部分完全一致，那么这部分内容可以直接复用之前的计算结果，只需要为新增部分付费。缓存命中的部分通常价格极低，甚至只有正常输入价格的十分之一左右。

这就意味着一个简单的结论：

缓存命中率每提升 10 个百分点，长对话的整体成本可能下降数倍。

而缓存能否命中，取决于一个非常苛刻的条件：请求的前缀必须逐字节一致。任何一处微小的改动——哪怕只是系统提示词里多了一个空格、工具列表顺序变了、或者压缩后的摘要被塞进了系统提示词——都会导致从改动点开始的所有内容缓存失效。

理解了这一点，后面的所有实践就都顺理成章了。

---

二、系统提示词：只有一个要求，尽可能短且从不变

2.1 稳定前缀是缓存的基石

缓存机制匹配的是请求的前缀。也就是说，从请求的第一个 token 开始，一直到某个位置完全一致，这部分才能命中缓存。系统提示词和工具定义通常位于请求的最前面，因此它们构成了缓存的“基座”。

一旦系统提示词发生变化，整个缓存基座就会崩塌，后面所有内容都无法复用。这就是为什么第一条原则是：

系统提示词有且只有一个要求：尽可能短，并且从来不变。

“从来不变”指的是在同一个项目、同一段工作流中保持稳定。跨项目时，由于需要注入项目级的说明文件（例如项目约定、技能清单等），系统提示词可以不同，但在单个项目的整个会话周期内，它应该是一个常量。

2.2 不要把压缩摘要塞进系统提示词

这是很多智能编程工具容易犯的一个错误：当上下文过长需要压缩时，把压缩后的摘要信息打包进系统提示词。

从功能上看，这似乎很合理——把重要信息放在最显眼的位置。但从缓存角度看，这是灾难性的做法。因为系统提示词一旦改变，整个前缀缓存全部失效，效果不亚于直接开了一个全新的对话，完全放弃了之前累积的缓存。对话越长，这种损失越严重。

正确的做法是：系统提示词保持原样不动，把压缩后的记忆信息通过 system reminder 注入到 user prompt 中。这样，系统提示词 + 工具定义这段“基座”始终稳定，缓存可以持续命中，只有新增的 user 消息部分需要重新计算。

2.3 项目级文件：只注入路径，不注入内容

对于项目级的技能清单、约定文件等，策略同样要服务于缓存稳定性：

• 技能类文件：永远只注入路径，不注入内容。需要时由模型主动读取，读取结果作为工具返回值进入对话，而不是固化在系统提示词里。
• 项目约定文件：只在内容非常少（例如整体不超过 4000 token）时才注入内容。超过这个阈值，就应该改为按需读取。

这样做的代价是模型可能需要多一次工具调用去读取文件，但换来的是系统提示词长期稳定，缓存命中率大幅提升。从总成本看，这笔账非常划算。

---

三、工具设计：少、短、能容忍错误

工具定义同样位于请求前缀中，因此工具集的设计直接决定了缓存基座的大小和稳定性。核心原则有三条。

3.1 工具数量尽可能少

大模型本质上是概率模型，工具越多，它在选择工具时的决策空间就越大，调用错误的概率也越高。更麻烦的是，工具列表越长，前缀越大，缓存失效时的重算成本也越高。

实践中，核心工具数量控制在 10 个以内是比较理想的状态。像计划模式、任务分解这类高级功能，完全可以放在对话层面之外实现，而不是作为工具暴露给模型。例如，计划模式可以由外层框架在特定阶段切换系统提示词来实现，而不是让模型在对话中自行决定是否进入计划模式。

工具越少，模型的决策越聚焦，调用成功率越高，前缀也越短，缓存越稳定。

3.2 工具描述尽可能短

很多工具定义会写一大段提示，例如：

ReadFile：读取文件内容。
提示：可以读取文本文件，也可以读取图片。
读取时请注意行数，不要一次性读取过多内容，建议分段读取……

这些内容真的有必要吗？

对于主流模型来说，读取文件、注意行数、分段读取这些行为，早已在供应商的后训练数据中出现过，模型在思维链里自然会考虑这些因素。如果这些基础行为都需要靠提示词反复强调，那这个模型本身的可用性就值得怀疑了。

因此，工具描述应该精简到只说明“这个工具做什么、参数是什么”。例如：

{
  "name": "read_file",
  "description": "读取指定路径的文件内容",
  "parameters": {
    "path": "文件路径",
    "start_line": "起始行，可选",
    "end_line": "结束行，可选"
  }
}

描述越短，前缀越小，缓存越容易命中，同时也减少了模型被无关信息干扰的可能。

3.3 工具必须具备模糊匹配能力

即使是当前最先进的模型，也有相当概率在调用工具时传错参数：路径少一个斜杠、行号写成了字符串、字段名拼写有细微差异……这是概率模型无法完全避免的问题。

与其期望模型永远不犯错，不如在工具实现层面做好容错：

• 参数类型自动转换：字符串形式的数字自动转为整数；
• 路径归一化：统一处理相对路径、多余分隔符、大小写差异；
• 字段别名兼容：常见拼写变体都能识别；
• 缺失参数使用合理默认值。

这套思路可以称为 Harness 工作——在模型之外构建一层稳健的适配层，把概率性输出的不确定性吸收掉。在“概率机器”真正进化为可靠的通用智能之前，这种工程化的容错设计始终是必要的。

---

四、记忆与上下文压缩的正确姿势

长对话不可避免地会遇到上下文长度上限。此时需要压缩，但压缩方式直接决定了缓存能否延续。

4.1 压缩不应该破坏前缀

如前所述，压缩后的摘要不应该写回系统提示词。正确的做法是：

1. 保留原始系统提示词和工具定义不变；
2. 将需要长期保留的关键信息（例如已确认的需求、已修改的文件列表、待办事项）提取为结构化摘要；
3. 把这份摘要作为 system reminder 注入到下一轮的 user 消息中。

这样，请求的前缀部分（系统提示词 + 工具定义）始终一致，缓存持续命中；只有 user 消息部分是新的，需要重新计算。相比把摘要塞进系统提示词导致全量失效，这种做法能把压缩带来的成本冲击降到最低。

4.2 记忆注入的粒度控制

记忆注入也不是越多越好。注入内容越多，user 消息部分越长，虽然不影响前缀缓存，但会增加每轮的新增计算量。建议：

• 只注入与当前任务强相关的信息；
• 使用结构化格式（列表、键值对）而非大段自然语言；
• 定期清理已经完成或不再相关的记忆条目。

4.3 跨项目场景的处理

跨项目时，系统提示词确实需要变化，因为项目约定、技能清单不同。此时缓存基座会重建，这是不可避免的。但可以通过以下方式减少损失：

• 尽量让不同项目的系统提示词结构一致，只替换少量项目相关字段；
• 项目切换时，尽量开启新的会话，避免在旧会话中混入新项目信息导致前缀反复变化。

---

五、一套可复用的检查清单

把上述实践总结成一份可操作的清单，方便在日常开发中逐项核对：

系统提示词层面

• 系统提示词是否已经精简到最小必要集？
• 同一项目内，系统提示词是否在整个会话周期保持不变？
• 压缩摘要是否被错误地写入了系统提示词？
• 技能类文件是否只注入路径而非内容？
• 项目约定文件是否只在体量很小时才注入内容？

工具层面

• 核心工具数量是否控制在 10 个以内？
• 工具描述是否去掉了冗余的使用提示？
• 工具是否具备参数类型转换、路径归一化等容错能力？
• 高级功能是否被错误地实现为工具，而非放在对话层面之外？

记忆与压缩层面

• 压缩后的记忆是否通过 system reminder 注入 user 消息？
• 记忆注入是否做到了结构化、按需、定期清理？
• 跨项目切换时，是否开启了新会话以避免前缀反复变动？

---

六、结语

缓存命中率看起来只是一个计费层面的指标，但它实际上反映的是整个智能编程系统设计的合理性。系统提示词是否稳定、工具集是否精简、记忆管理是否得当，这些决策最终都会体现在缓存命中率和账单上。

把缓存命中率从 60% 提升到 98%，靠的不是某个神奇技巧，而是一系列朴素但需要严格执行的工程原则：稳定的前缀、精简的工具、外置的记忆、健壮的容错。这些原则不依赖特定平台，任何团队都可以在自己的智能编程工作流中落地。

在模型能力快速迭代的今天，工程层面的优化空间往往被低估。而恰恰是这些看似琐碎的细节，决定了你能否用可接受的成本，让智能编程助手真正成为日常开发的可靠伙伴。