Claude Prompt Caching 实战：5 分钟与 1 小时缓存怎么选

本文基于 Anthropic 官方 Prompt Caching 文档整理，聚焦可直接用于生产的设计原则。

长 system prompt、大段产品文档、固定工具定义会在每次请求中重复占用输入处理时间。Prompt Caching 的核心做法，是缓存一段稳定的提示词前缀，后续请求只处理变化部分。

自动缓存还是显式断点

自动缓存适合持续增长的多轮对话：在请求顶层启用 cache_control，系统会把断点推进到最后一个可缓存块。

显式断点适合结构稳定、边界明确的场景，例如：

• 固定 system prompt
• 大型工具定义集合
• 很少变化的知识背景
• 多个请求共享的 few-shot 示例

response = client.messages.create(
    model="claude-sonnet-4-6",
    max_tokens=800,
    cache_control={"type": "ephemeral"},
    system=LONG_SYSTEM_PROMPT,
    messages=[{"role": "user", "content": question}],
)

5 分钟和 1 小时如何选

默认缓存 TTL 是 5 分钟，每次命中会刷新有效期。高频客服、连续 Agent 循环和活跃对话通常用默认 TTL 即可。

如果相邻请求经常间隔超过 5 分钟，但通常不会超过 1 小时，可以使用 ttl: "1h"。一小时缓存写入成本更高，适合低频长对话、长耗时子 Agent 或对首 token 延迟非常敏感的流程。

同一请求混合 TTL 时，长 TTL 的块必须放在短 TTL 块之前。一个容易理解的布局是：

1. 1 小时：产品手册、政策、稳定背景。
2. 5 分钟：当前会话摘要和近期工具结果。
3. 不缓存：本轮用户问题。

命中率低的常见原因

• 在稳定前缀前插入时间戳或随机 ID。
• 工具定义顺序每次变化。
• JSON 序列化字段顺序不稳定。
• 把用户问题放在缓存断点之前。
• 流式响应耗时过长，下一轮开始时默认 TTL 已接近结束。

上线后不要只看总 token，应分别监控缓存写入、缓存读取、首 token 延迟和真实费用。缓存并非免费：第一次写入更贵，只有前缀能被复用时才划算。

原文：Anthropic — Prompt caching