指南
提示缓存
提示缓存会在重复使用相同提示段时降低重复上下文成本和延迟。实际上，主要工作在于提示设计：稳定的前缀比不断变化的提示更容易复用。
提示缓存会在重复使用相同提示段时降低重复上下文成本和延迟。实际上，主要工作在于提示设计：稳定的前缀比不断变化的提示更容易复用。
本指南关注应用设计。精确缓存行为、可用条件和节省幅度可能因模型家族、账号设置、供应商路径和套餐而异，所以请以实际用量指标为准。
适用场景
- 稳定的系统提示
- 重复的长文档
- 可复用的指令块
- 团队共享的提示模板
什么时候值得为缓存做设计
| 场景 | 为什么有帮助 |
|---|---|
| 很多请求共享同一段策略或系统提示 | 稳定前缀可以在多次调用中复用 |
| 用户围绕同一份长参考资料提出不同问题 | 参考资料可以放在易变用户输入之前 |
| Agent 复用同一批工具或 schema 指令 | 工具描述和输出约束可以保持稳定 |
| 团队维护一份批准过的提示模板 | 变更可控，而不是每次请求重新拼装 |
实用指南
- 保持可复用的上下文稳定
- 将静态指令与用户特定内容分离
- 将大量共享上下文放在易变的用户输入之前
- 监控实际使用数据，而不是假设所有模型都适用固定折扣
一个良好的提示布局
- 静态策略和指令。
- 可复用的长篇参考资料。
- 工具定义或 schema 指令。
- 请求特定的用户内容。
示例布局
SYSTEM:
稳定的产品策略、语气和安全规则。
REFERENCE:
被多次请求复用的共享文档、schema 或长上下文。
TOOLS OR OUTPUT CONTRACT:
稳定的工具定义或 JSON 形状要求。
USER:
当前用户的问题、文件、图片或任务特定数据。什么会破坏复用
- 在静态前缀中注入时间戳或随机值
- 每次请求都以略有不同的顺序重建提示
- 把缓存内容和未缓存内容混合成一个不稳定的整体
- 每次请求用不同格式渲染同一份参考资料
- 将用户特定文本放在共享可复用上下文之前
如何衡量
| 指标 | 对比什么 |
|---|---|
| 延迟 | 稳定提示前缀前后，相似请求的耗时变化 |
| 成本 | 重复工作负载的真实账单用量，而不是理论折扣 |
| 缓存适用性 | 是否持续使用同一模型家族和提示布局 |
| 质量 | 分离静态和动态内容后，输出行为是否变化 |
常见错误
| 错误 | 更好的做法 |
|---|---|
| 在系统提示里加入当前时间戳 | 将易变数据放到请求特定用户内容附近 |
| 从无序对象重新拼装提示 | 使用确定性的提示组装顺序 |
| 在验证质量前先优化缓存 | 先证明提示有效，再稳定可复用部分 |
| 假设每个模型都有相同节省幅度 | 查看你实际使用 route 和账号的用量指标 |