提示缓存
用缓存降低成本与延迟，以及它如何影响上下文的结构设计。
一句话理解：提示缓存让模型复用“与上次完全相同的开头部分”的计算结果，从而大幅降低成本与首字延迟；代价是你必须把上下文排成“稳定的在前、变化的在后”。
一个订单售后诊断 Agent 每次调用都要带上约 2 万 Token 的固定内容：系统指令、十几个工具定义、问题分类标准。一次排查要跑 20 到 30 步，每一步都把这 2 万 Token 重新发送、重新计费、重新处理。用户多了之后，这部分“重复劳动”往往是账单里最大的一块。
提示缓存（Prompt Caching）解决的就是这个问题。它不是一个“打开开关就好”的优化，而会反过来影响上下文的结构设计：同样的内容，排列顺序不同，缓存命中率可能天差地别。 这正是产品经理需要理解它的原因。
直觉：只算一次开头
模型处理输入时，会对每个 Token 做大量计算。如果这一次请求的开头部分和几分钟前的某次请求 一模一样，服务端就可以直接复用那部分的计算结果，只处理后面新增的内容。
关键规则只有一条：缓存按前缀匹配。 从开头开始逐段比较，一旦某个位置出现差异，从那个位置往后的内容都无法复用。哪怕只改了系统指令里的一个字，排在它后面的全部内容都要重新计算。
机制与价格（以 Claude API 为例）
下面的信息来自 Claude 官方文档，截至本课更新时有效；价格与规则可能调整，落地前请以官方文档为准。
| 项目 | 说明 |
|---|---|
| 前缀顺序 | 工具定义 → 系统指令 → 消息，缓存按这个顺序构成层级 |
| 如何开启 | 在内容块上标记缓存断点（每次请求最多 4 个）；也可以在请求顶层开启自动缓存，断点会随对话增长自动后移 |
| 默认有效期 | 5 分钟；每次命中会免费刷新有效期 |
| 可选有效期 | 1 小时，写入价格更高 |
| 写入价格 | 5 分钟缓存为基础输入价的 1.25 倍；1 小时缓存为 2 倍 |
| 读取价格 | 基础输入价的 0.1 倍（个别模型更低） |
| 最小长度 | 低于门槛的内容无法缓存，门槛因模型而异，从数百到数千 Token 不等 |
| 隔离 | 不同组织之间从不共享缓存；Claude API 上还按工作区隔离 |
| 如何确认 | 响应的 usage 中会分别返回缓存写入与缓存读取的 Token 数 |
其他模型厂商也有类似能力，但机制不同。例如 OpenAI 官方文档说明其提示缓存对支持的模型默认自动启用，缓存命中部分按未缓存价格的 0.1 倍计费，同样建议把稳定的指令和共享资料放在前面。具体的最小长度、有效期等细节各家不同，也在持续变化，使用时查对应文档即可。
两个容易误解的点：
- 缓存改变的是 价格和延迟，不改变上下文占用。被缓存的 Token 仍然计入上下文窗口，仍然会引起上下文腐化。
- 缓存写入比普通输入 更贵。如果一个前缀写入之后在有效期内没有被再次读取，反而多花了钱。
算一笔账
假设售后 Agent 的固定前缀为 2 万 Token，一次排查连续调用 30 次，每次间隔都在 5 分钟内。只看这 2 万 Token 的前缀部分，用“基础输入价 × Token 数”作为单位：
不使用缓存：30 次 × 20,000 = 600,000 单位
使用缓存： 第 1 次写入 20,000 × 1.25 = 25,000 单位
后 29 次读取 29 × 20,000 × 0.1 = 58,000 单位
合计 = 83,000 单位
前缀部分的输入成本下降约 86%实际节省比例还取决于前缀在总输入中的占比、对话历史是否也被缓存、调用间隔是否超过有效期等。但方向很明确：Agent 的调用次数越多、固定前缀越长，缓存越值钱。 完整的单任务成本估算方法见 成本模型。
缓存如何约束上下文设计
理解了“前缀匹配”，就能推出一系列设计规则。这些规则经常与其他需求冲突，需要产品和研发一起权衡。
1. 稳定的放前面，变化的放后面。
当前时间、用户姓名、请求 ID 这类每次都变的信息，应该放到稳定前缀之后，例如放进用户消息里。
2. 不要在会话中途改变工具列表。 工具定义排在最前面，增删或修改任何一个工具，整个缓存都会失效。“根据任务阶段动态切换工具集”在效果上也许合理，但在成本上很昂贵。如果工具很多，更好的方式是工具搜索：Claude 官方文档说明，被延迟加载的工具不进入前缀，搜到后以引用的形式追加到对话中，因此不破坏缓存（参见 渐进式披露）。
3. 一些参数变化也会让部分缓存失效。 例如在 Claude API 中，修改 tool_choice、切换思考相关的配置、增删图片，都会导致消息部分的缓存失效。同一会话内保持这些参数稳定。
4. 上下文清理与压缩会破坏缓存。 删除旧工具结果、用摘要替换历史，都改变了前缀。这是一个真实的权衡：清理能对抗腐化、节省窗口，但会触发一次重新写入。因此清理应当“攒一批再清”，而不是每步都清一点（参见 长任务的上下文管理）。
5. 按调用节奏选择有效期。 用户交互式的 Agent，两次调用之间可能隔好几分钟（用户在看结果、在审批），5 分钟缓存可能频繁过期。这时 1 小时缓存虽然写入更贵，整体可能更划算。后台批处理连续调用，5 分钟通常足够。
6. 把命中率当作一个监控指标。 在看板上跟踪“缓存读取 Token ÷ 总输入 Token”。一次看似无害的指令修改（比如在开头加了一行日期），可能让命中率骤降、成本翻倍。
常见误区
- “开了缓存就自动省钱。” 前缀不稳定时，缓存几乎不命中，还要额外支付写入溢价。先检查上下文的排列顺序。
- “缓存了就不占上下文。” 缓存只影响计费和延迟，被缓存的内容依然占用窗口，依然会稀释注意力。
- “为了缓存，什么都不能动。” 缓存是成本优化，不应凌驾于效果之上。该清理的上下文照样清理，只是要有节奏、有批量。
设计要点
- 画出上下文的排列顺序图，标出每一段的稳定程度（全局不变 / 按用户不变 / 每步变化）。
- 系统指令和工具定义中不出现时间戳、随机 ID 等每次变化的内容。
- 会话内保持工具列表、工具选择策略与思考配置稳定；工具多时优先考虑工具搜索。
- 根据真实调用间隔选择缓存有效期，并用数据验证。
- 监控缓存命中率，把它纳入每次 Prompt 或工具变更后的回归检查。
练习
拿订单售后诊断 Agent（或你自己的 Agent）的一次完整运行做分析：
- 列出每次调用的上下文组成，按“全局不变 / 按用户不变 / 每步变化”三类标注。
- 找出至少一处破坏前缀稳定性的设计（例如开头的时间戳、动态工具列表），写出修改方案。
- 用上文的方法，估算这次运行在不使用缓存、使用 5 分钟缓存、使用 1 小时缓存三种情况下，前缀部分的相对成本。假设用户在第 10 步后停顿了 8 分钟去审批。
延伸阅读
- Claude 文档：Prompt caching
- OpenAI 文档：Prompt caching
- Claude 文档：Tool search tool
下一步
Context Engineering 模块到这里结束。下一个模块从「RAG 全流程」开始，讲 Agent 如何使用企业自己的知识：文档如何被切分、检索、引用，并进入上下文。