提示缓存，清晰解析

克劳德如何实现92%缓存命中率的案例研究

每当你使用AI智能体执行一步操作，你都要支付一笔“税收“。

它会从头重新读取所有内容。

系统指令。工具定义。它三回合前已经加载过的项目上下文。全部内容。每一回合都是如此。

这就是“上下文税“。对于运行时间较长的智能体工作流，这往往是你整个AI基础设施中最昂贵的开销项。

以下是计算：一个包含20,000个token的系统提示，运行50个回合，意味着100万个token的冗余计算，按全价收费，却没有产生任何新价值。

解决方案是提示缓存。但要有效使用它，你需要了解底层实际发生的情况。

从什么改变、什么不变开始

在优化任何东西之前，你需要清晰地思考智能体提示（上下文）的结构。

每个智能体发送的请求都包含两个截然不同的部分：

静态前缀： 包括系统指令、工具定义、项目上下文、行为指南。这部分内容在整个会话的每一回合中都完全相同。

动态尾部： 用户消息、工具输出、终端观察。这部分每个请求都是独特的，并且随着对话的进行而增长。

这个区别至关重要。静态前缀是你毫无理由重复计算的高昂部分。动态尾部才是唯一真正需要全新计算的部分。

提示缓存的原理是存储静态前缀的数学状态，使得未来的请求可以完全跳过重新计算。你为处理该前缀付费一次。后续每一回合都从内存中读取。

为什么这有效：Transformer实际做了什么

要真正理解缓存为何如此有效，你需要了解模型读取提示时内部发生的情况。

每个LLM推理请求都有两个阶段：

阶段1：预填充 (Prefill)

模型处理你的完整输入提示。这个阶段是计算密集型的，意味着它在上下文中的每个token上运行密集的矩阵乘法。模型读取所有内容并建立起它的表示。这是缓慢且昂贵的阶段。

阶段2：解码 (Decode)

模型逐个生成输出token。这个阶段是内存密集型的，而不是计算密集型的，因为模型大部分时间用于读取之前计算好的状态，而不是运行繁重的计算。

在预填充阶段，transformer为每个token构建三个向量：查询 (Query)、键 (Key) 和值 (Value)。注意力机制利用这些向量来计算每个token与序列中其他所有token之间的关系。

关键在于：键和值向量仅依赖于它们之前的token。 一旦为给定前缀计算完成，它们就永远不需要改变。

下面的插图直观地解释了刚才讨论的内容：

没有缓存时，这些键值张量在请求完成的那一刻就被丢弃了。下一个请求从头开始，再次为所有20,000个token重新计算。

KV缓存的解决方案就是存储这些张量。 基础设施将它们保留在推理服务器上，并通过输入文本的加密哈希值进行索引。当一个新的请求到来时，如果包含相同的前缀，哈希匹配，张量立即被检索，模型跳过所有这些计算。

这将每次生成token的计算复杂度从O(n²)降低到O(n)。对于在50个回合中重复使用的20,000 token前缀，这是一个巨大的减少。

经济学

理解定价结构是使这一架构决策如此重要的原因。

以下是Anthropic在其模型系列中为缓存定价的方式：

需要牢记的三个数字：

• 缓存读取成本为基础输入价格的10%，从缓存中读取的每个token享受90%折扣

• 缓存写入成本比基础输入价格高出25%，这是存储KV张量的小额溢价

• 延长至1小时的缓存成本为基础价格的两倍

只有你的缓存命中率保持高位，这个算数才成立。这就引出了实践中最好的例子。

Claude Code：一次30分钟会话的试走

Claude Code完全围绕一个目标构建：保持缓存“热“。

要具体理解这意味着什么，我们来追踪一次典型的30分钟编码会话，并精确记录哪些被收费、哪些没有。

第0分钟：会话开始

Claude Code加载其系统提示和工具定义。它还读取项目根目录下的CLAUDE.md文件，该文件描述了代码库和约定。这个负载通常超过20,000个token。

这是整个会话中最昂贵的时刻。每个token都是新的。但你在整个会话中只需支付这一次成本。

第1至5分钟：首批命令

你输入第一条指令，比如“查看认证模块并提出改进建议“。

Claude Code分派一个探索子智能体。它遍历代码库，打开文件，运行grep命令，并构建相关代码的概览。所有这些都会被附加到动态尾部。

那20,000 token的静态基础？已经在缓存中。以0.30/百万token的价格读取，而不是3.00/百万token。你只需为新的工具输出和你的消息付费。

第6至15分钟：深度工作

规划子智能体接收来自探索子智能体的发现。而不是逐字传递原始结果（这会使动态尾部不必要地膨胀），Claude Code传递一个简洁的摘要。这保持了后缀的可管理性和缓存的高效性。

规划器生成一个结构化的实现计划。你审查它、批准它，然后Claude Code开始进行修改。这个循环中的每一回合都从缓存中读取20,000 token的前缀。每次缓存命中重置TTL（生存时间），使缓存为后续回合保持“温暖“。

第16至25分钟：迭代

你要求调整。Claude Code修改其方法。更多的工具调用，更多的终端输出。动态尾部在增长，但它只代表本次会话中新的、独特的内容。

此时，会话已处理了总计数十万个token。但20,000 token的基础每回合都从缓存中读取。

第28分钟：运行/cost

没有缓存，这样一次会话很容易超过200万个token。按Sonnet 4.5的费率，大约6.00美元。

而缓存高效运行时：

• 绝大多数token以$0.30/百万token从缓存读取

• 只有新的动态尾部token是全新计算的

实际上，单一任务上预计可实现80%以上的成本降低。再乘以每个用户、每一天。

总结一下，随着会话的进行，系统提示布局如下所示（图表略）：

打破一切的规则

以下是关于提示缓存最反直觉的一点。

1 + 2 = 3。但2 + 1是缓存未命中。

基础设施对提示进行哈希。哈希是一种加密标识符。如果顺序中任何内容发生变化（即使两个元素的顺序互换），哈希就会改变。缓存为空。整个前缀以全价重新计算。

由此得出的三条规则：

• 不要在会话中添加或删除工具。缓存的前缀包含工具。更改工具会使之后的所有内容无效。

• 不要在会话中间切换到其他模型。缓存是模型特定的。在对话中途切换到更便宜的模型需要重建整个缓存。

• 不要通过更改前缀来改变状态。相反，Claude Code会在下一条用户消息中添加一个标签来提醒系统。前缀永远不会改变。

这对你意味着什么

以上解释了Claude Code如何处理缓存。如果你自己构建智能体，同样的规则也适用。

以下是如何构造你的提示：

• 顶部是系统指令和规则。不要在中间更改。

• 提前加载你需要的所有工具。不要添加或删除它们。

• 之后是检索到的上下文和文档。在这段持续时间内保持静态。

• 底部是对话历史和工具输出。

启用自动缓存后，随着对话的进行，断点会自动前移。

Claude Code管理自己的缓存。Anthropic刚刚在其API中添加了自动缓存，因此你也可以为自己的智能体做同样的事情。

没有自动缓存时，你必须记住token边界在哪里。错误的边界意味着无法命中缓存。

使用缓存安全的分叉来压缩以适应上下文限制。使用相同的系统提示、工具和对话，然后将压缩指令作为新消息添加。

压缩调用看起来几乎与上一次一样。缓存的前缀再次被使用。唯一作为新内容计费的是压缩指令。

要检查API是否正常工作，请密切关注每个响应中的这三个字段：

• cache_creation_input_tokens：被存入内存的token数量

• cache_read_input_tokens：从内存读取的token数量

• input_tokens：照常处理的token数量

你的缓存效率分数是比较读取token与创建token的数量。像监控正常运行时间一样密切关注它。

关键要点

提示缓存不是一个你需要开启的功能。它是一种你需要围绕其构建的架构纪律。

Claude Code是该领域大规模实践的最佳示例。

缓存命中率92%。成本降低81%。

如果你正在构建智能体，这就是蓝图。你无法忽视“上下文税“；它确实存在。唯一重要的是你是在为它付费，还是在消除它。

参考资料：

• https://www.dailydoseofds.com/p/kv-caching-in-llms-explained-visually/

• https://x.com/trq212/status/2024574133011673516?s=20

• https://manus.im/blog/Context-Engineering-for-AI-Agents-Lessons-from-Building-Manus