很多人理解 AI 编程工具时，第一反应是模型能力、工具调用、代码搜索、终端执行和编辑体验。但 Anthropic 在复盘 Claude Code 的经验时，给出的重点反而更底层：prompt caching 是一切的基础。
这并不难理解。一个代码 Agent 和普通聊天机器人不同，它每一轮都可能带上大量重复内容：系统提示词、工具定义、项目结构、用户偏好、历史操作、文件片段、错误日志、计划和中间结论。如果这些内容每次都从零处理，成本会很高，延迟也会被拉长。
Prompt caching 要解决的就是这个问题：让模型复用前面已经处理过的稳定上下文，只为新增加的部分付出主要计算成本。
为什么 Claude Code 特别依赖缓存
Claude Code 的典型工作流是多轮、长上下文、工具密集型的。用户不是简单问一句“这段代码什么意思”，而是会让它浏览项目、修改文件、运行测试、分析报错，然后继续根据结果调整。
这类任务有三个特点：
- 上下文越来越长。
- 大量前缀内容在多轮之间保持不变。
- 每一轮真正新增的信息通常只占一小部分。
如果没有缓存，每次调用模型都要重新处理完整上下文。哪怕只是新增一条测试报错，也要重新读一遍系统提示词、工具 schema、之前的执行记录和项目背景。对于一个需要连续工作十几轮的 Agent 来说，这会直接影响产品体验。
Prompt caching 的价值就在这里：它不是一个锦上添花的优化，而是长上下文 Agent 能不能跑得顺的前提。
核心原则：稳定内容放前面，变化内容放后面
最值得记住的一条经验是：缓存依赖稳定前缀。
也就是说，提示词越前面的部分越应该稳定。系统提示词、工具定义、长期规则、固定格式要求，这些内容适合放在最前面；用户本轮输入、工具返回结果、临时状态、最新错误日志，则应该放在后面。
可以把一次 Agent 调用理解成这样的结构：
稳定系统提示词
稳定工具定义
稳定开发规则
较稳定的项目背景
较新的对话摘要
最近几轮消息
本轮用户输入
本轮工具结果
前面的内容越稳定，缓存命中率越高。反过来，如果你把一个每轮都会变化的时间戳、随机 ID、临时状态塞到系统提示词前部，就等于主动破坏缓存。
工具定义也要当成缓存资产
AI Agent 往往有很多工具：读取文件、搜索代码、编辑文件、运行命令、提交 patch、打开网页等。每个工具都有名称、描述、参数 schema 和使用约束，这些定义本身就会占用不少 token。
Claude Code 的经验是，工具定义不只是“告诉模型有哪些能力”，它们也是需要精心管理的缓存资产。
实践上可以注意几件事：
- 工具名称和参数结构尽量稳定，不要频繁动态生成。
- 工具描述不要混入每轮都会变化的运行状态。
- 工具列表要有确定顺序，避免同一组工具每次排列都不同。
- 把用户本轮意图和工具定义分开，不要为了“更智能”而在工具 schema 里塞临时上下文。
很多 Agent 应用慢，并不是模型真的慢，而是提示词组织方式导致缓存持续失效。
缓存边界其实是架构边界
做普通 Web 应用时，我们会区分静态资源、接口数据、会话状态和临时 UI 状态。做 LLM 应用时也一样，只是边界变成了 prompt 的组织方式。
一个健康的上下文结构，通常应该能回答这几个问题：
- 哪些 token 在很多轮里都不会变？
- 哪些 token 只在当前任务里相对稳定？
- 哪些 token 每一轮都会变化？
- 哪些内容值得进入长期上下文，哪些应该只作为短期工具结果？
- 压缩后的摘要应该放在哪个层级，避免每轮重写导致缓存失效？
Prompt caching 逼着开发者把这些问题想清楚。它看起来是性能优化，实际上会反过来塑造 Agent 的架构。
上下文压缩不能替代缓存
长任务一定会遇到上下文膨胀，所以很多 Agent 会引入 compaction，也就是把前面的对话和操作压缩成摘要。
但压缩不是缓存的替代品。压缩解决的是“上下文太长”的问题，缓存解决的是“重复上下文太贵”的问题。两者应该配合使用。
更合理的做法是分层：
- 系统提示词和工具定义保持高度稳定。
- 项目背景、开发约定等内容尽量少变。
- 压缩摘要只在必要时更新。
- 最近几轮原始消息保留在尾部。
- 本轮输入和工具结果永远放在最后。
如果每一轮都重写摘要，并且把摘要放在很靠前的位置，就会把后面的缓存也一起打碎。看似上下文变短了，实际延迟和成本未必更好。
给普通 AI 应用开发者的启发
即使你不做 Claude Code 这种复杂代码 Agent，prompt caching 的思路也很值得借鉴。
第一，把 prompt 当成数据结构，而不是一段字符串。
不要把所有东西拼成一大坨文本。系统规则、工具定义、业务背景、用户输入、检索结果、临时状态，应该分层组织。
第二，避免无意义的变化。
时间戳、随机排序、每轮变化的说明文字、动态生成但内容等价的 schema，都会影响缓存命中。能稳定就稳定。
第三，先优化前缀，再优化局部。
很多人一上来就压缩用户输入或减少工具返回，当然这也有用。但对长任务来说，更关键的是让大块稳定前缀可复用。
第四，把缓存指标纳入调试。
只看总 token 数是不够的，还要看缓存创建和缓存读取的比例。一个 8 万 token 的调用，如果 7 万 token 都能从缓存读，体验可能比一个反复失效的 2 万 token 调用更好。
一个可套用的提示词结构
如果你正在做 Agent，可以先从这个结构开始：
[System]
- 产品身份
- 行为边界
- 输出规范
- 安全规则
[Tools]
- 稳定的工具列表
- 稳定的参数 schema
- 稳定的工具使用约束
[Project Context]
- 项目结构
- 代码规范
- 用户长期偏好
[Task Memory]
- 当前任务目标
- 已完成步骤
- 重要中间结论
[Recent Messages]
- 最近几轮用户和助手消息
[Current Turn]
- 本轮用户请求
- 本轮检索结果
- 本轮工具输出
这里的顺序很重要。越靠前，越要稳定；越靠后，越可以变化。
总结
Claude Code 的经验说明，Agent 产品的关键不只是“接入一个更强的模型”，而是要认真设计上下文的生命周期。
Prompt caching 能降低延迟和成本，但它不会自动发生在混乱的 prompt 结构上。你需要主动把稳定内容放到前面，把变化内容放到后面，让工具定义保持确定性，并让压缩摘要和最近消息各司其职。
对于正在构建 AI 编程助手、客服 Agent、数据分析 Agent 或内部自动化 Agent 的团队来说，这可能是最值得优先打磨的一层基础设施。
关于
关注我获取更多资讯
