你每天都让 AI 做同一个项目。
但每一次都重新丢：
公司规则。
产品说明。
工作流程。
20 页背景文档。
工具定义。
再加上今天的新问题。
看起来很完整。
问题是：
AI 可能每天都在重新读一大堆根本没有变的东西。
Claude Fable 5.1 把 Prompt Cache Read 价格大幅降低后，
今天只学一个动作：
把 Prompt 先拆成「固定背景」和「今天添加」。
不要每次把所有数据重新搅成一包。
先说清楚：这篇主要是给 API／Agent 工作流程
如果你只是打开一般 Claude App：
聊天。
写文章。
问问题。
你不需要自己去找一个：
「Prompt Cache」
开关。
今天谈的 Prompt Caching，
主要是 Claude API 与开发者创建 Agent、App、自动化工作流程时使用的能力。
也就是：
你的系统每次都要调用 Claude，
而且很多背景数据会反复出现。
这种情况才特别值得管 Cache。
为什么 Fable 5.1 让这件事突然更值得注意？
Fable 5.1 的一般 Input 价格是：
每百万 Token 10 美元。
但是已经命中的 Cache Read，
现在只要：
每百万 Token 0.25 美元。
相较 Fable 5 原本的 1 美元，
下降：
75%。
但注意：
不是你用了 Fable 5.1，
所有 Input 就自动便宜 75%。
只有真正：
从 Cache 重复读到的那部分 Context
才适用 Cache Read 价格。
所以第一个问题不是：
「我要不要开 Cache？」
而是：
「我的 Prompt 里，哪些东西其实一直没有变？」
第一步：先找出「固定背景」
假设你正在做一个客服 Agent。
每一次请求都需要知道：
公司的品牌语气。
退款规则。
商品信息。
客服禁止事项。
Tool Definitions。
五组回答范例。
这些东西可能：
今天一样。
明天一样。
下一位客人进来还是一样。
这就是：
固定背景。
先把它们集中在 Prompt 前面。
不要散落在今天的新问题之间。
第二步：把「今天添加」留到后面
接着才放：
这位客人的问题。
这次的新订单数据。
今天添加的文档。
这一次真正要完成的任务。
例如：
固定背景：
品牌规则。
商品规格。
退款制度。
工具说明。
客服范例。
今天添加：
「客人表示商品收到时破损，订单数据如下……」
这样结构就变成：
前面很大一段长期不变。
后面只有今天的新数据。
这正是 Prompt Cache 比较容易产生价值的结构。
为什么顺序很重要？
Anthropic 的 Prompt Caching 是：
Prefix Cache。
Prefix 就是：
前缀。
系统会从 Prompt 前面开始，
判断之前是不是已经处理过相同的内容。
所以如果你的 Prompt 是：
固定规则。
固定文档。
固定范例。
今天的新问题。
下一次又是：
固定规则。
固定文档。
固定范例。
明天的新问题。
前面那一大段就有机会被重复使用。
但如果你每次都把：
日期。
用户名。
今天的订单。
放到最前面，
后面的固定数据即使完全一样，
也可能比较难形成你原本期待的稳定 Prefix。
最简单的整理方式
你可以先不用想程序。
拿一张纸写：
固定背景：
角色。
长期规则。
Tool Definitions。
大型参考资料。
固定范例。
项目背景。
今天添加：
新问题。
新数据。
新文档。
本次输出要求。
只要这一步做清楚，
后续工程师才知道：
哪一段值得 Cache。
第三步：固定背景不要每次偷偷改一点
这一点非常重要。
假设你的固定背景原本是：
产品文档 A。
产品文档 B。
产品文档 C。
下一次你只是把：
B 和 C 的顺序交换。
对人类而言：
数据还是一样。
但对 Prefix Cache 而言，
前面的内容已经改变。
Anthropic 官方说明：
Cache Entry 是依照 Prompt Prefix 创建。
如果 Cache Breakpoint 以前的内容改变，
下一次就可能产生不同的 Cache。
所以：
想重复使用，就真的让重复部分保持稳定。
不要为了漂亮，每次重排 Prompt
很多人创建 Agent 时，
会动态产生 Prompt。
例如今天：
规则 → 文档 →范例。
明天：
范例 → 规则 → 文档。
甚至每次把文档依名称重新排序。
内容看起来都一样。
但 Cache 的重复利用可能因此变差。
所以可以多一条工作规则：
固定内容固定顺序。
真正会变的东西，
集中放后面。
第四步：API 怎么知道前面要 Cache？
Claude API 现在有两种主要方式。
第一种比较简单：
Automatic Caching。
在 Request 打开 Cache Control，
系统会自动处理适合的 Cache Prefix。
第二种是：
Explicit Cache Breakpoint。
你明确告诉系统：
「到这里以前是我要重复使用的固定内容。」
如果你的 Prompt 结构非常清楚，
例如：
前面 8 万 Token 永远都是项目背景。
最后只有今天的新问题会变。
Explicit Breakpoint 就可以更加精准。
初学者先记一个原则就够
不要先研究所有 Cache 参数。
先把数据结构整理对。
也就是：
不变的放前面。
会变的放后面。
等到这个结构稳定，
才谈：
Automatic Cache。
Breakpoint。
5 分钟 TTL。
1 小时 TTL。
否则就算 Cache 功能打开，
Prompt 每次都乱变，
效果也可能不好。
Cache 可以放哪些东西？
Anthropic 官方目前支持 Cache 的内容很多。
包括：
Tool Definitions。
System Messages。
一般文字消息。
图片。
文档。
Tool Use。
Tool Results。
所以 Prompt Cache 并不只等于：
「缓存一句 System Prompt。」
真正大型 Agent 里，
最有价值的可能反而是：
很长的 Tool Definitions。
项目文档。
大量固定背景。
以及一路累积的对话 Context。
那是不是什么东西都应该 Cache？
也不是。
如果一份数据每一次都会变，
例如：
今天股价。
实时库存。
新的客户消息。
本次订单。
今天的新闻。
硬要把它当成固定 Context，
意义不大。
真正适合的是：
重复。
稳定。
够大。
三个条件。
只有 20 个字的固定 Prompt，
即使想 Cache，
省下来也可能没有实际意义。
Cache 第一次使用其实不是最便宜
这也是容易误会的地方。
第一次创建 Cache，
系统还是要先：
读取。
处理。
再创建 Cache。
而 Cache Write 本身有成本。
Anthropic 目前的 5 分钟 Cache Write，
是一般 Input 价格的：
1.25 倍。
所以第一次：
不一定比较便宜。
真正省钱的是：
后续再次命中同一份 Cache。
这就像办会员卡。
如果办完只去一次，
不一定划算。
如果会反复使用，
价值才开始出来。
预设 Cache 可以留多久？
Anthropic Prompt Cache 预设 TTL 是：
5 分钟。
TTL 就是：
Time To Live。
可以理解成：
这份 Cache 有效多久。
每次成功使用，
有效时间会再刷新。
如果你的工作间隔比较长，
Anthropic 也提供：
1 小时 Cache。
但 1 小时 Cache Write 成本更高。
所以不是：
时间愈长愈好。
而是要看你的 Agent：
多久会再次使用同一份背景。
什么情况 5 分钟就够？
例如一个 Agent 正在：
连续做 Code Review。
连续处理一批客服案件。
反复查同一份文档。
一个多步骤工作里不停调用模型。
这些工作几分钟内就会一直重复使用相同 Context。
5 分钟很合理。
什么情况可能考虑 1 小时？
例如：
研究 Agent。
一个 Side Agent 要跑很久。
用户平均每 20～30 分钟才回一次。
每隔一段时间才处理下一批工作。
而每次都要重新使用同一大段 Context。
这种情况才比较值得评估 1 小时 Cache。
不是因为：
「1 小时比较高级。」
第五步：不要猜 Cache 有没有成功，要看 Usage
设置完成后，
真正重要的一步是：
检查。
Claude API 的 Usage 数据会提供：
Cache Creation Input Tokens。
以及：
Cache Read Input Tokens。
如果第二次调用后：
Cache Read Input Tokens 开始出现，
代表真的有从 Cache 读到内容。
如果一直都是：
0。
就不要自己安慰自己：
「应该有 Cache 吧。」
可能原因包括：
Prompt 太短。
Prefix 改变。
Breakpoint 放错。
已经超过 TTL。
或其他设置造成 Cache Miss。
所以成本优化不能只看总帐单
假设今天模型帐单：
100 美元。
明天：
80 美元。
你还不知道真正原因。
可能是：
使用量少了。
Output 变短。
模型换了。
Cache Hit 增加。
工作失败变多。
所以比较好的做法是把：
Input Tokens。
Cache Read Tokens。
Output Tokens。
完成率。
人工修改量。
一起看。
便宜但一直做错，并不是真的便宜。
一个最简单的实际例子
假设你的 Agent 每次需要：
8 万 Token 的固定产品数据。
今天新问题只有：
2,000 Token。
以前每次都重新处理：
82,000 Token 左右。
如果固定的 8 万 Token 能成功从 Cache Read，
真正按照一般 Input 价格重新处理的，
就主要剩下：
新的那一小段内容。
注意：
实际帐单还会受到：
Cache Write。
Output。
模型。
TTL。
以及其他设置影响。
这里只是说明：
为什么固定背景与添加数据分开后，Cache 才有机会发挥价值。
最容易犯的错：为了 Cache 把旧数据永远留下
也不要走到另一个极端。
如果：
产品规则已经改版。
公司政策改了。
文档过期。
Tool Definition 更新。
就应该更新固定背景。
即使这会造成新的 Cache。
不要为了省几个 Token，
继续让 AI 读：
已经错的旧规则。
正确性永远比 Cache Hit Rate 重要。
所以真正要固定的是「有效版本」
固定背景不代表：
永远不能改。
而是：
在版本没有改变期间保持稳定。
例如：
客服规则 v3。
只要 v3 还有效，
保持相同顺序与内容。
正式更新成 v4，
就创建新的固定 Context。
这样你既能：
重复利用 Cache。
也不会把过期数据永久锁住。
今天只做一件事
如果你有一个 Claude API 或 Agent 工作流程，
先不要急着改程序。
打开现在的 Prompt。
把每一段标记成：
固定。
或：
添加。
然后重新排列成：
固定规则。
固定工具。
固定背景文档。
固定范例。
────────
今天的新数据。
今天的新问题。
今天要的输出。
只要做到这一步，
你就已经开始从：
「每次重新请 AI 理解整个世界」
改成：
「背景已经知道，今天只处理新的事情。」
这才是 Prompt Cache 真正值得使用的地方。
不是让 AI 少思考。
而是：
不要一直付钱让 AI 重读同一份背景。
今天，和 AI 一起进步一点。
每天学会一个 AI 技巧。
每天节省一点时间。
每天提升一点能力。
SasaDaily，陪你一起成长。
推荐阅读
AI 一分钟教学｜2026/08/10：别只记 AI 成本，每次结果先标成「可用、需修改、失败」
今日 AI 工具｜2026/08/10：Langfuse，把 AI 每次花多少钱、跑多久、结果好不好记下来，不再只看总帐单
