Prompt Caching vs 工具结果替换

很多人在做 Agent 成本优化时，都会同时想到两件事：

1. 利用 prompt caching
2. 把很长的工具结果替换成更短的占位符

问题是，这两件事并不是天然兼容的。

Cache 省钱的前提，是前缀别变

以 Claude 或 OpenAI 这类前缀缓存为例，它的核心逻辑可以概括成一句话：只有当前缀逐字节一致时，缓存才容易命中。

请求 A:
[system][msg1][msg2][msg3][msg4]
-> 首次请求，全量计费并写入缓存

请求 B:
[system][msg1][msg2][msg3][msg4][msg5][msg6]
-> 前缀命中缓存，通常只有新增部分全价

正常聊天历史本来就容易命中缓存

因为自然对话的形态，本来就是不断在旧历史后面追加新消息。

第 1 轮: [system][user1]
第 4 轮: [system][user1][assistant2][tool3][assistant4]
第 5 轮: [system][user1][assistant2][tool3][assistant4][user5]
第 8 轮: [system][user1][assistant2][tool3][assistant4][user5][assistant6][tool7]

每一轮请求都保留了前一轮的完整前缀，所以缓存命中的基础条件通常是成立的。

一旦替换工具结果，旧前缀就变了

关键在于：你修改了历史消息。

例如你把一个很长的工具结果替换成短占位符：

替换前:
[system][user1][assistant2][tool3_完整内容][assistant4][user5]

替换后:
[system][user1][assistant2][tool3_短占位符][assistant4][user5]

从被替换的位置开始，后面的字节序列已经变了。也就是说，后续请求不再拥有和旧请求完全一致的前缀。

这会直接破坏原有的 prompt cache 命中条件。

这两种方法省的不是同一笔钱

它们各自在优化不同的东西：

策略 A：保留历史不动，依赖 Prompt Caching

• 优点：前缀稳定，缓存命中率高
• 代价：完整工具结果会持续留在上下文中，token 总量膨胀更快

策略 B：压缩或替换工具结果

• 优点：直接减少上下文里的 token 总量
• 代价：会打断缓存前缀，下一轮可能要重新按全价处理更多内容

所以它们经常互相拉扯，没法简单叠加。

到底该选哪种，主要看两个变量

判断时主要看：

1. 工具结果本身有多大
2. 后续还会有多少轮对话

可以先按这个经验去看：

如果工具结果特别大，后面还有很多轮，替换通常更划算；如果结果不大，或者对话已经快结束了，保留历史去吃缓存往往更值。