面试官问我：“你了解Claude Code的缓存机制？”，我：“何止了解，我深入研究过”，面试官：“先入职，后面细聊！！”

这篇文章看标题像是在讲“缓存优化”。但如果你真这么理解那就浅了。它真正讲的是一个长期运行的 Agent 产品不能把 Prompt Cache 当成后期优化而要从第一天就围着缓存设计。Claude Code 为什么能在一个长会话里反复读代码、调用工具、跑命令还不至于每一轮都慢到离谱、贵到离谱核心就是 Prompt Cache。不是普通意义上的“把结果缓存起来”。而是把每次请求里稳定不变的前缀缓存起来让下一轮请求不用重新计算前面那一大坨上下文。这件事听起来简单。但 Anthropic 这篇文章最有价值的地方在于它把几个反直觉的工程结论讲出来了系统提示词不能随便动工具定义不能随便增删Plan Mode 不能靠换工具集实现MCP 工具多了不能靠动态删工具省 token模型中途切换可能反而更贵上下文压缩也要复用父会话缓存这些不是细枝末节。这些决定了一个 Agent 产品到底是“能演示”还是“能长期用”。一、先搞清楚Prompt Cache 缓存的不是答案很多录友一听缓存第一反应是是不是用户问过的问题下次直接把答案拿出来不是。Prompt Cache 缓存的不是模型回答。它缓存的是模型处理输入上下文时的中间计算。你可以这么理解。Claude Code 每一轮跟模型交互并不是只把你刚输入的那句话发过去。它要把一整套东西重新发给模型系统提示词工具定义CLAUDE.md 里的项目规则当前项目上下文前面所有对话消息工具调用结果你这一轮的新输入模型本身并不会在两次 API 请求之间“记住”上一次聊到哪了。所以每一轮请求都要带上完整上下文。如果没有缓存那长会话越聊越贵越聊越慢。这也是为什么很多 Agent demo 一开始看起来很丝滑但跑一会儿就开始变慢。它不是突然变笨了。是上下文越来越长每次都在重算。Prompt Cache 解决的就是这个问题前面已经算过、下一轮又完全一样的部分就不要再算一遍。但这里有一个关键限制。它靠的是前缀匹配。不是“这段内容大概一样”。也不是“这个文件之前读过”。而是从请求开头开始连续一段内容必须一致才能命中缓存。Prompt Cache 命中依赖请求前缀连续一致所以 Claude Code 的请求组织方式很讲究第一层静态系统提示词和工具定义。这部分最好全局稳定不同项目都能复用。第二层CLAUDE.md 和项目上下文。这部分在同一个项目里稳定。第三层会话上下文。这部分在同一个会话里稳定。第四层对话消息和工具结果。这部分会随着聊天增长。第五层本轮新增输入。每一轮只让最后一点点内容变化。这样前面大部分内容都能命中缓存。静态内容放前面动态内容放后面。这是做 Agent 产品时最朴素、也最容易被忽略的缓存原则。二、为什么“改一个小东西”也会让缓存断掉Prompt Cache 最反直觉的地方在这里。很多人觉得我只是改了一下系统提示词里的时间。我只是调整了一下工具顺序。我只是把某个工具参数更新了一下。应该没什么大问题吧有问题。因为它会让前缀发生变化。前缀一变后面的缓存就接不上。Anthropic 在原文里提到他们也踩过类似坑比如把详细时间戳放进静态系统提示词、工具定义顺序不是确定的、更新工具参数等。这些变化看着都不大。但从缓存角度看都是前缀污染。Prompt Cache 前缀断点会导致后续缓存失效这就像你在一个大项目里改构建缓存 key。你可能只改了一行配置。但缓存系统看到的是不一样了。那就重新构建。对 Agent 也是一样。如果系统提示词每轮都带一个实时日期或者工具定义每轮顺序都不稳定那缓存命中率就会很难看。所以做 Agent 不能只问这段 Prompt 对模型有没有帮助还要问这段内容是不是应该出现在稳定前缀里如果它每轮都变那就别放前面。放到消息里。三、动态信息别改系统提示词放进消息里Agent 运行过程中确实会遇到很多动态信息。比如当前时间变了用户改了文件权限状态变了进入了某种工作模式某个工具结果需要提醒模型直觉上你可能想更新系统提示词。比如把“当前时间是 2026 年 5 月 28 日”写进系统提示词。或者用户改了文件就把“某文件已修改”更新到项目上下文里。这在功能上没问题。但在缓存上很差。因为系统提示词和项目上下文都在前面。你一改后面全断。Claude Code 的做法更聪明动态信息尽量通过下一轮消息追加进去而不是修改前面的稳定前缀。例如文件变化可以在下一条用户消息或工具结果里追加一个系统提醒告诉模型“这个文件已经变了需要时重新读取”。这样做的好处是前面的系统提示词、工具定义、CLAUDE.md 都不动。只是末尾多了一条新消息。缓存还能继续命中。这也是为什么我们前面讲 CLAUDE.md 时反复强调CLAUDE.md 适合放长期稳定规则。不要把一次性任务、临时状态、当前进度都塞进去。长期规则进 CLAUDE.md临时变化进消息。这个分流不只是为了上下文清爽。也是为了缓存稳定。动态信息应该追加到消息末尾而不是修改稳定前缀四、不要中途切模型可能更贵这点也很反直觉。很多人会想复杂问题用强模型。简单问题切便宜模型。听起来很合理。但在长会话里不一定省钱。因为 Prompt Cache 是按模型隔离的。你在 Opus 里聊了 100k token上下文已经缓存好了。这时候你觉得下一个问题很简单切到 Haiku。从单次输出价格看Haiku 便宜。但 Haiku 没有 Opus 的缓存。它要重新处理整段上下文。这就可能出现一个很尴尬的情况为了省一点输出成本反而付出一大笔未缓存输入成本。所以 Anthropic 的建议是不要在同一个长会话中随便换模型。如果确实需要换模型更好的方式是用 subagent。主会话继续保持自己的模型和缓存。子 Agent 用另一个模型处理局部任务。然后把结果返回给主会话。这其实又回到一个原则不要破坏主会话的稳定前缀。主会话是主干。子 Agent 是分支。分支可以另起缓存。但不要让主干为了一个小任务把整个缓存掀掉。长会话中途切模型会失去原模型缓存五、Plan Mode 为什么不能靠“删掉写入工具”实现Claude Code 的 Plan Mode录友应该不陌生。进入 Plan Mode 之后Claude Code 会先读代码、分析问题、给计划不直接改文件。很多人如果自己设计这个功能第一反应大概是计划模式只保留只读工具。编辑工具、写文件工具、执行危险命令的工具都先移除。听起来很安全。但这会破坏缓存。因为工具定义是前缀的一部分。你一进入 Plan Mode就把工具集合换了。退出 Plan Mode又换回来。每次模式切换都在动前缀。这就很亏。Plan Mode 的关键是保持工具定义稳定只追加模式状态Claude Code 的设计更有意思。它不是通过“换工具集合”来表达 Plan Mode。而是始终保留完整工具集。同时把 EnterPlanMode 和 ExitPlanMode 也设计成工具。当用户进入 Plan Mode 时系统在消息末尾追加说明当前处于计划模式要探索代码库不要编辑文件计划完成后调用退出计划模式。注意重点工具定义没变。变化发生在对话末尾。所以缓存前缀还能命中。这就是工程产品和普通 demo 的差别。普通 demo 可能只关心“功能能不能实现”。Claude Code 这种产品还要关心这个功能会不会让每一次模式切换都变贵、变慢更妙的是因为 EnterPlanMode 本身也是工具模型在遇到复杂任务时还可以自己判断进入计划模式。功能更灵活。缓存也没被破坏。六、MCP 工具多了不能每轮动态删工具现在大家做 Agent很容易接一堆 MCP。GitHub 一个。数据库一个。浏览器一个。文件系统一个。内部平台再接几个。工具越来越多。然后就会遇到一个问题每次请求都把几十个工具的完整 schema 发给模型太贵了。那怎么办很多人的第一反应是本轮用不到的工具就删掉。比如这轮只需要读文件那数据库工具、浏览器工具都先不发。听起来省 token。但这又踩中了缓存雷区。因为工具集合变了。工具定义顺序变了。缓存前缀就变了。所以 Claude Code 的思路不是“动态删工具”而是“延迟加载工具详情”。MCP 工具多时用稳定工具目录和按需加载 schema它可以先在稳定前缀里放轻量 stub。也就是工具名、很少的元信息、以及 defer_loading 这样的标记。完整工具 schema 先不塞进去。当模型真的需要某个工具时再通过 tool search 发现并加载完整 schema。这样有两个好处第一稳定前缀不会因为工具删来删去而变化。第二不常用工具的完整定义不会每轮都占 token。所以 MCP 工具管理的核心不是我这一轮到底要不要给模型这个工具而是哪些工具信息必须稳定存在哪些工具详情可以按需展开这个思路对我们自己做 Agent 也很重要。不要一上来就把所有系统能力、所有接口文档、所有工具参数全塞进 Prompt。先给工具目录。需要时再展开详情。七、上下文压缩不是另起一个总结请求长会话跑久了一定会遇到上下文窗口不够的问题。Claude Code 里常见的处理方式就是 compact。把前面的对话总结成一段摘要然后用摘要替换原来的长历史继续往下做。这看起来很简单。但从缓存角度看这里面也有坑。最容易想到的做法是单独发一个请求给模型。系统提示词写“请总结下面这段对话”。不带工具。把完整历史塞进去。让模型返回摘要。这当然能跑。但很贵。因为这个总结请求的系统提示词、工具定义、上下文结构和父会话完全不一样。从第一个 token 开始就不匹配。父会话前面攒下来的缓存全用不上。更糟的是越是需要 compact说明对话越长。对话越长单独总结请求越贵。这就是典型的“问题越严重解决问题越贵”。Claude Code 的做法是缓存友好分叉。上下文压缩应该复用父会话前缀再追加 compact 指令它在做压缩时使用和父会话一样的系统提示词、用户上下文、系统上下文和工具定义。先带上父会话的消息。然后在末尾追加一条压缩指令。从 API 视角看这个请求和父会话上一次请求非常像。前面大段前缀都一样。只有末尾的压缩指令是新的。这样就能复用父会话缓存。当然这也带来另一个工程要求系统必须预留压缩缓冲区。不能等上下文窗口真的塞满了再想着“现在总结一下吧”。那时候已经没空间放压缩指令和摘要输出了。所以成熟 Agent 产品会在上下文还没彻底满之前就留出 compact buffer。这点对我们自己做 Agent 也很关键。不要把 compact 当成最后一刻的急救。它应该是上下文生命周期管理的一部分。八、缓存命中率要像服务可用性一样监控Anthropic 在原文里有个细节很值得注意Claude Code 团队会监控 Prompt Cache 命中率。命中率太低会触发告警甚至当成事故处理。这个态度很说明问题。很多团队做大模型应用只监控这些指标QPS延迟错误率token 消耗单次请求成本这些当然要看。但做 Agent还要看缓存。尤其是长会话 Agent。缓存命中率一掉延迟和成本会一起变差。用户体感就是怎么突然变慢了怎么同样的任务今天额度掉得特别快而研发侧如果只看请求成功率可能完全看不出问题。因为请求都成功了。只是每次都在重算。所以做 Agent 要多看两类 tokencache creation input tokens本轮写入缓存的输入 token。cache read input tokens本轮从缓存读取的输入 token。Prompt Cache 命中率需要纳入 Agent 监控闭环如果 read 很高creation 很低说明缓存用得好。如果 creation 连续很高说明你的前缀可能一直在变。这时候不要先怀疑模型。先查系统提示词是不是每轮都变工具定义顺序是不是不稳定MCP 工具是不是动态增删是否中途切了模型compact 是否另起了一个请求是否把时间、文件变化、模式状态写进了前缀很多 Agent 性能问题不是模型问题。是上下文组织问题。九、这篇文章对普通开发者有什么用可能有录友会说这些都是 Claude Code 团队做产品的细节我只是用 Claude Code 或者做一点大模型应用有必要关心吗有必要。因为这篇文章其实告诉我们一个大趋势Agent 工程不是只会调 Prompt也不是只会接几个工具。真正要做稳要懂上下文结构、缓存策略、工具边界、模型切换、长会话生命周期。如果你只是日常使用 Claude Code可以记住这几条第一别在长任务中频繁切模型。切一次模型下一轮可能会明显变慢因为缓存要重建。第二CLAUDE.md 改完不一定立刻生效。它属于会话开头加载的项目上下文中途改了不一定会影响当前会话。要么重新开会话要么在当前对话里明确补充。第三MCP 不要边做任务边频繁接入、断开。MCP 工具定义会影响缓存最好在一个任务开始前就把需要的 MCP 配好。第四compact 最好放在自然断点。比如一个子任务完成后再压缩而不是在关键编辑中间突然压缩。第五别把所有临时要求都塞进项目规则文件。稳定规则写进 CLAUDE.md。临时要求直接在当前对话里说。如果你是做 Agent 产品的那要再进一步Prompt 结构按稳定性分层工具定义顺序必须确定工具集合尽量会话内稳定动态状态用消息追加多模型用 subagent 隔离工具详情用延迟加载compact 走父会话缓存友好分叉缓存命中率纳入监控这不是优化清单。这是架构清单。十、最后说一句缓存不是省钱小技巧是 Agent 的地基现在很多人讲 Agent喜欢讲规划、记忆、工具调用、多 Agent 协作。这些都重要。但如果底层上下文每轮都在重算工具集合每轮都在变系统提示词每轮都不一样模型动不动就切。那这个 Agent 越跑越贵、越跑越慢是迟早的事。所以 Anthropic 这篇文章的价值不在于告诉你“Prompt Cache 可以省钱”。而在于告诉你Agent 产品的功能设计要服从缓存约束。Plan Mode 是这样。MCP 工具加载是这样。上下文压缩也是这样。很多看起来是产品交互的问题背后其实是缓存架构问题。这也是 Claude Code 值得研究的地方。它不是只把一个强模型塞进 CLI。它是在模型之外做了一整套能长期运行的 Agent harness。而 Prompt Cache就是这套 harness 里最容易被低估的一根主梁。录友如果想做 AI 编程工具或者想做真正可用的 Agent 系统这篇原文建议认真读。别只看它怎么省 token。要看它怎么把缓存变成产品设计原则。这才是重点。学AI大模型的正确顺序千万不要搞错了2026年AI风口已来各行各业的AI渗透肉眼可见超多公司要么转型做AI相关产品要么高薪挖AI技术人才机遇直接摆在眼前有往AI方向发展或者本身有后端编程基础的朋友直接冲AI大模型应用开发转岗超合适就算暂时不打算转岗了解大模型、RAG、Prompt、Agent这些热门概念能上手做简单项目也绝对是求职加分王给大家整理了超全最新的AI大模型应用开发学习清单和资料手把手帮你快速入门学习路线:✅大模型基础认知—大模型核心原理、发展历程、主流模型GPT、文心一言等特点解析✅核心技术模块—RAG检索增强生成、Prompt工程实战、Agent智能体开发逻辑✅开发基础能力—Python进阶、API接口调用、大模型开发框架LangChain等实操✅应用场景开发—智能问答系统、企业知识库、AIGC内容生成工具、行业定制化大模型应用✅项目落地流程—需求拆解、技术选型、模型调优、测试上线、运维迭代✅面试求职冲刺—岗位JD解析、简历AI项目包装、高频面试题汇总、模拟面经以上6大模块看似清晰好上手实则每个部分都有扎实的核心内容需要吃透我把大模型的学习全流程已经整理好了抓住AI时代风口轻松解锁职业新可能希望大家都能把握机遇实现薪资/职业跃迁这份完整版的大模型 AI 学习资料已经上传CSDN朋友们如果需要可以微信扫描下方CSDN官方认证二维码免费领取【保证100%免费】