缓存

当提示词的开头很长且会重复出现时，提示词缓存会有帮助：

• 一段包含规则和示例的长系统提示词，会被每个用户反复使用。
• 一份大型文档（手册、合同、代码库），你要围绕它提出很多问题。
• 智能体在长任务的每一步都携带的一组工具列表。
• 一段不断增长的对话：每一轮都会重新发送整个历史记录，而历史记录正是重复的部分。

如果每个请求都很短且彼此不同，或者重复的部分位于提示词的末尾，它就帮不上忙。

响应缓存适用于常见问题类流量：同样的几个问题被反复提出，且可以接受略微过时的答案。

在聊天应用和智能体工具中，你通常什么都不用做。以 Claude Code 为例，它会自动缓存。

在使用 API 时，你需要标出提示词中稳定部分的结束位置。在 Claude API 中，这是通过在系统提示词或某条消息的某个块上添加 cache_control 标记来实现的：

{
  "system": [
    { "type": "text", "text": "...long rules and documents...",
      "cache_control": { "type": "ephemeral" } }
  ],
  "messages": [{ "role": "user", "content": "Today's question" }]
}

第一次调用会写入缓存（费用比普通调用略高）。之后以相同文本开头的调用会读取缓存，输入价格大约是普通价格的十分之一。缓存条目在最后一次被使用后会保留几分钟，对于突发流量还有一个更长的选项。非常短的提示词根本不会被缓存；具体的最低长度要求请查阅服务商的文档。

响应缓存本质上就是你自己应用里的一张查找表：键是问题，值是答案，并带有过期时间。

• 把永远不变的内容放在最前面（规则、工具、文档），把每次都会变的内容（用户的问题、今天的日期）放在最后。
• 检查数字。API 返回值会报告从缓存中读取了多少 token。如果第二次调用时这个值为零，说明前缀中有内容发生了变化。
• 常见原因包括：系统提示词中的时间戳、随机 ID，以及工具列表顺序不一致。
• 对大多数应用来说，在稳定部分的末尾设置一个缓存标记就足够了。
• 对于响应缓存，请设置过期时间，并将模型名称包含在缓存键中，这样切换模型后就不会返回旧的答案。

• 任何改动都会破坏匹配。 标记前多一个空格，整个缓存就会未命中，而且不会显示任何错误。
• 写入会额外收费。 缓存一个只用一次的提示词，花费反而比不缓存更多。
• 它会过期。 缓存在几分钟内没有被使用就会消失。每小时运行一次的突发任务可能永远命中不了它。
• 过期答案。 响应缓存会欣然返回上周的价格。只缓存可以接受过期风险的内容。
• 个人数据。 绝不能把一个用户的缓存答案提供给另一个用户。把用户或账户纳入缓存键中。

缓存是控制成本的三个杠杆之一：你发送了什么（上下文）、每部分花费多少（token），以及是否需要重复付费（缓存）。