Rules of prompt caching

提示缓存 (Prompt Caching) 核心概念

• 基本原理
• 初始请求 (Initial Request): CLOD 对首次发送的消息进行处理，并将处理结果保存到临时缓存中。
• 后续请求 (Follow-up Request): 如果后续请求包含与初始请求完全相同的消息，CLOD 不会重新处理，而是直接从缓存中加载已完成的工作。
• 适用场景: 适用于反复发送相同内容的场景。

• 缓存限制与激活
• 时效性: 缓存数据并非永久存储，有效期仅为 5 分钟。
• 启用方式: 缓存功能默认未开启，必须手动在消息块内添加“缓存断点” (Cache Breakpoint) 才能激活。
• 最小内容要求: 缓存内容必须达到至少 1024 个 Token 才能被写入缓存。

• 技术实现要点
• 格式要求: 要添加缓存控制字段，文本块必须使用“长格式” (Long Form) 编写（即：内容字段 → 列表 → 字典 → 文本类型/文本字段）。短格式无法添加缓存控制。
• 缓存范围: 缓存的范围是从断点开始，到断点为止（包括断点本身）的所有内容。
• 适用对象: 缓存断点不仅可以设置在消息块上，还可以设置在几乎所有类型的块上，包括：
• 消息块 (Message Blocks)
• 工具使用 (Tool Use)
• 工具结果 (Tool Result)
• 工具方案 (Tool Schemas)
• 系统提示 (System Prompts)

• 缓存结构与管理
• 处理顺序: CLOD 在处理请求时，内部的顺序是：工具 → 系统提示 → 消息列表。
• 多断点设置: 最多可以设置 4 个缓存断点。
• 缓存粒度: 缓存是分段的。例如，如果只在最后一个工具方案上设置断点，则工具方案会被缓存，但系统提示和消息列表不会被缓存。
• 缓存失效: 如果后续请求中，断点之前的任何内容发生变化，则该部分缓存将被失效，CLOD 需要重新处理。

Takeaways

• 提示缓存用于处理重复的初始请求，通过保存处理结果来避免重复计算。
• 缓存功能默认未开启，必须手动添加“缓存断点”激活，且数据有效期仅为 5 分钟。
• 启用缓存需满足两个条件：文本块必须使用“长格式”编写，且内容量需达到至少 1024 个 Token。
• 缓存是分段的，如果后续请求中断点之前的任何内容发生变化，该部分缓存将失效。