Prompt Cache深度解析教程（非常详细），Agent架构纪律从入门到精通，收藏这一篇就够了！

这两天看Prompt Cache相关讨论，我越来越确定一件事：

很多人以为自己在讨论一个“省钱功能”，但大家真正碰到的，是 Agent 的上下文管理问题。

表面上看，Prompt Cache说的是 token 成本、请求加速和缓存命中率。
但再往前走一步，它逼着我们重新回答一个更根本的问题：

一个要连续运行几十分钟、甚至几小时的 Agent，到底该怎么组织自己的上下文？

上下文成本，最后会反过来塑造 Agent 的架构。

所以这里不想把Prompt Cache写成一篇原理课。
更想聊的是，为什么它看起来像一个优化点，最后却会落到架构纪律上。

先把结论放在前面。

先别把它看成“省钱技巧”

Akshay Pachaar 那篇文章里有一句话，我觉得抓得很准：

Agent 每走一步，都在交一次“上下文税”。

因为它把一件平时很容易被忽略的事，讲得足够直白。

我们在和 Agent 交互时，体感通常只盯着两样东西：

• • 它回得够不够快
• • 它做得够不够对

但在模型真正运行时，还有一个经常被藏在背后的成本项：

每一轮请求，系统都要重新处理那一大段并没有变化的上下文。

系统提示词没变。
工具定义没变。
项目背景没变。
一些常驻规则也没变。

问题是，只要我们还是按普通请求去发，模型就还是得把这些内容从头再走一遍。

拿 OpenClaw 的/context detail输出举例：一个系统提示词可能占到 9600+ token，仅工具 schema 就要 8000 token，Skills 列表再占 500+，注入的工作区文件（AGENTS.md、SOUL.md、TOOLS.md 等）又是几千 token。你还没开始干活，固定开销已经先花掉一万多 token。一个会话跑五十轮，这部分的重复成本就非常可观了。

原因很少是模型输出太多，更多是在反复重算那些其实已经看过的东西。

这就是为什么Prompt Cache一出来，很多工程团队会立刻有感觉。

它解决的不是边角问题。
它碰的恰好是 Agent 产品里最容易被低估、但又最稳定存在的一项支出。

说得再直接一点：

很多 Agent 越跑越贵，根源就在这里：它在一遍又一遍为旧上下文付费。

这时候，Prompt Cache的意义就不只是“便宜一点”了。
它在提醒我们：系统里哪些信息该稳定保留，哪些内容不该反复重算，哪些设计会让每一轮请求都从零开始。

真正被缓存的，不是文字，而是已经算过的状态

如果只用一句话解释Prompt Cache，我会这样说：

它不是把提示词文本简单存起来，而是把模型已经算过的前缀状态保留下来。

原文里用了static prefix和dynamic tail这两个词，我觉得这个分法很值得保留。

一个 Agent 请求，大致可以拆成两部分：

• •静态前缀
  系统指令、工具定义、项目规则、长期不变的背景资料
• •动态尾部
  用户消息、工具输出、终端观察结果、这轮新增的上下文

真正贵的，通常是前面那一大段静态前缀。

因为模型每次都要先经历一遍预处理，也就是把整段输入读进去、建立内部表示。
这部分计算量大，成本也高。

Prompt Cache干的事，就是尽量别让模型反复做这段已经做过的工作。
前缀不变，就直接复用。
只把这轮新增的动态尾部继续往后算。

听起来偏底层，但放到工程里会一下子清楚很多。

因为它把上下文第一次真正拆成了两类资源：

• • 一类是应该尽量稳定的
• • 一类是天然会增长的

有了这个分法，很多系统设计上的取舍就有了依据。

如果把一个 Agent 的上下文预算拆成三层，大致的成本结构长这样：

前两层越稳定，缓存命中率越高。第三层越大，系统越容易变慢变贵。

前几天我们一直在讲的，也是这个道理：

不是所有信息都该常驻上下文。

有些东西必须长期稳定存在。
有些东西只需要按需加载。
有些东西看完就应该压缩。
还有一些东西，最好根本不要进主会话。

Prompt Cache把这个问题从“写作习惯”变成了“工程现实”。
因为一旦不做区分，代价会立刻出现在账单、延迟和会话质量上。

缓存为什么会反过来塑造系统结构

很多人第一次接触缓存，直觉上会觉得它只是底层基础设施的事。
用得上当然好，用不上也无非就是贵一点。

但真正做过长任务 Agent 之后，我们会发现不是这样。

缓存命中率，最后会倒逼整个系统往更稳定、更克制的结构上收。

原因很简单。

缓存不是靠“意思差不多”来命中的。
它依赖的是前缀稳定。

顺序变了，可能就失效。
工具集合变了，可能就失效。
模型切了，通常也会失效。

这背后对应的是三条很朴素、但很硬的工程规律。

1. 会话中途频繁改前缀，缓存很难稳定

如果系统提示词、规则区块、上下文结构一直在变，缓存本来就很难稳定工作。

很多团队一开始喜欢把各种运行时状态塞回系统提示词里，想让模型“记住现在进入哪个阶段了”。
这样做短期内也许看起来方便，但它有个副作用：

最适合缓存的那部分内容，会先变成最不稳定的部分。

OpenClaw 在系统提示词设计上就有意识地做了这件事。它的系统提示词每次运行时由系统重建，结构固定：Tooling → Safety → Skills 列表 → Workspace → Runtime → 注入的引导文件。时间部分也做了特殊处理：只包含时区信息，不包含动态时钟，就是为了保持提示词缓存稳定。需要当前时间时，模型通过session_status工具按需获取。

更稳的做法，是把状态放在后面的用户消息、计划状态、外部记忆或结构化文件里，保持前缀不动。

2. 工具越随意，缓存越难热起来

工具定义本身也是上下文的一部分。
今天加一个，明天删一个，后天再换个描述，前缀自然也就跟着飘。

工具要小而清晰，职责边界要稳，别让它们在会话里处于持续漂移状态。

前一阵子 Thariq 提到过一个非常现实的背景：MCP server 可能会带来50+ tools的规模。
工具一多，问题就不再只是“模型会不会用”，而是：

这些工具会不会把上下文挤爆，会不会让前缀越来越难稳定。

这也是为什么工具和 Skills 是两回事。工具是有副作用的动作能力（执行、读写、网络），每一个工具的 schema 都是固定上下文成本。而 Skills 只在系统提示词里放一个紧凑的列表条目（名称 + 描述 + 位置），指令本身按需加载，模型需要时才去read对应的 SKILL.md。这种"轻列表 + 重按需"的设计，本身就是在保护前缀稳定性。

3. 长任务不是靠“多塞点上下文”就能解决

这点尤其值得说。

很多团队一碰到长任务，第一反应是再补点背景、再加点规则、再给点示例。
但 Agent 跑到一定长度之后，问题往往不是信息不够，而是信息没有被分层。

缓存命中不起来，只是其中一个症状。
另一个更常见的表现是：

• • 会话越来越慢
• • 模型开始抓不住重点
• • 工具输出越来越像噪音
• • 后面几轮的推理质量明显下降

这时候，如果我们还在同一条主会话里无限加料，系统只会越来越重。

所以从这个角度看，缓存其实很诚实。
它会把系统里那些原本被掩盖的问题，提前暴露出来。

从 Prompt Engineering 走到 Context Engineering

如果只看Prompt Cache，很容易把它理解成一个点状能力。
但把最近一段时间 Anthropic 的几篇文章放在一起看，结论会更完整。

他们在 2025 年 9 月 29 日发布的《Effective context engineering for AI agents》里，已经把这条路线讲得很清楚。

文章里有几句话，我觉得非常值得工程团队反复看：

• • 上下文是有限资源，不是越多越好
• • 真正重要的是保留最小、最高信号密度的一组 token
• • 很多信息不该预先全部塞进去，而应该在运行时按需取用
• • 长任务需要压缩、记笔记和多 Agent 隔离，而不是硬顶着一条大上下文往前跑

翻成更口语一点的话，大概就是：

Agent 的关键能力，已经不只是“怎么把一句 Prompt 写好”，而是“怎么把上下文管好”。

CLAUDE.md放什么。
记忆放什么。
什么应该进规则层。
什么应该变成 Skill。
什么必须交给 Hook。
什么时候该 compact。
什么时候该开子 Agent。

这些看起来像不同话题，实际上都在回答同一个问题：

哪些信息该常驻，哪些该按需，哪些该压缩，哪些该隔离。

到这里，Prompt Cache就不再只是一个“缓存能力”了。
它更像是一面镜子。

它让我们看到，真正成熟的 Agent 系统，通常都有几个共同特征：

• • 主前缀稳定
• • 工具集合克制
• • 检索尽量按需
• • 长历史会主动压缩
• • 噪声调查交给子 Agent
• • 主 Agent 只保留高信号结果

如果说 Prompt Engineering 更像是在雕一句提示词，
那 Context Engineering 更像是在设计一套上下文供应链。

用一张图来看，Agent 的上下文其实在经历一个完整的生命周期：

这也是本文最想讲清楚的一个变化。

不止 Claude Code：OpenClaw 是怎么做的

原始素材里反复提 Claude Code，不只是因为它热。
更重要的是，它刚好把这些问题都集中暴露了出来。

但如果只看 Claude Code 一个产品，视野容易变窄。OpenClaw 作为一套开源的 Agent 运行时，在同一组问题上做了一套完整的工程方案，拆开看更有参考价值。

一个长会话 Agent 产品有几个很典型的特征：

• • 会连续执行很多轮
• • 会反复调用工具
• • 会不断引入新的终端输出
• • 会在主线程和子线程之间来回传递结果
• • 很容易在长任务里把上下文越堆越厚

如果没有缓存、压缩和隔离，这类产品会很快遇到三个问题：

1. 成本上来
   旧上下文反复重算，账单非常直接。
2. 延迟变差
   每一轮都得重新处理一大段前缀，会话越来越拖。
3. 注意力变散
   该保留的和不该保留的都混在一起，模型越来越难抓重点。

OpenClaw 为此建了一整套上下文治理管线，每一层解决的问题不同：

其中Session Pruning的设计和缓存的关系非常直接：Anthropic 的提示缓存有 TTL 限制，会话空闲超过 TTL 后，下一个请求会重新缓存完整提示。如果不先修剪旧的工具结果，这次 cacheWrite 的体量就会很大。OpenClaw 的做法是在 TTL 过期后的第一个请求前，先把旧工具结果做软修剪（保留头尾，中间用...替代）或硬清除（直接替换为占位符），降低重新缓存的成本。修剪完后 TTL 窗口重置，后续请求又可以命中新缓存。

修剪的目的，是控制"缓存失效后重建的代价"。

也正因为这样，长任务 Agent 一直在给我们一个很重要的提示：

长任务产品拼到后面，真正决定体验上限的，往往是上下文在多轮运行里有没有被管住。

后来出现的compaction、子 Agent、Tool Search，本质上都在做同一件事：让上下文流动得更干净。

比起原理，工程上更该先做这 8 个动作

读懂原理之后，回到自己的 Agent 系统里，我更建议从下面这 8 个动作开始。

1. 先把常驻前缀收短、收稳

系统提示词、工具定义、长期项目规则，尽量稳定。
能不在运行时改的，就别在运行时改。

前缀越飘，缓存越难热起来。
前缀越稳定，后面很多优化才有意义。

2. 把“状态变化”往动态尾部放

当前阶段、任务进度、临时提醒、这轮观察结果，不要都塞回系统提示词。
让它们留在消息层、计划层、外部文件或记忆层，通常更干净。

OpenClaw 的记忆系统就是这个思路：每日日志写在memory/YYYY-MM-DD.md，长期决策存在MEMORY.md，工作区引导文件（AGENTS.md、SOUL.md 等）负责常驻契约。记忆是持久化到磁盘的 Markdown 文件，不是塞在系统提示词里的一大段文本。模型需要时通过memory_search（语义搜索）或memory_get（精确读取）按需获取。

3. 工具别堆得太满

工具多不一定是能力强。
如果一组工具本身职责重叠、返回结果冗长、描述还在不断改，模型的选择成本会升高，前缀也会持续变重。

工具设计最好问两个问题：

• • 这个工具是不是必要的
• • 这个工具返回的信息是不是足够短、足够清楚

4. 能按需取的，尽量别预先全塞

这条特别重要。

Anthropic 在 context engineering 那篇文章里反复强调just in time的上下文策略。
文件路径、查询结果、网页链接、外部存储，这些都可以先保留引用，真正需要的时候再取。

很多系统越做越重，根源在于太急着把所有数据一次性搬进上下文。

同样的逻辑也适用于工作区引导文件。TOOLS.md 如果太大，OpenClaw 会按bootstrapMaxChars（默认 20000 字符）截断，并加上标记提醒模型"需要完整内容时再 read 原文件"。信息照给，只是不一次性全塞。

5. 长任务通常离不开 compaction

历史越长，噪声越多。
如果不主动压缩，主线程会越来越像日志堆场，而不是工作区。

压缩的目标是保留真正影响后续行动的部分：

• • 已经确定的架构决策
• • 还没解决的关键问题
• • 必须保留的约束
• • 最近正在操作的关键对象

OpenClaw 的压缩在会话接近上下文窗口时自动触发。它会先跑一轮静默的记忆刷写，提醒模型把重要笔记写入磁盘文件，然后才对旧历史做摘要。摘要持久化到会话的 JSONL 记录中，后续请求使用的是"压缩摘要 + 近期消息"，而不是完整的原始历史。

对 Claude Code 用户来说，操作更直接：/compact手动触发压缩，配合Compact Instructions指定哪些信息绝对不能丢（架构决策、已修改文件、验证状态、未完成事项），这是防止长会话"失忆"的关键动作。

6. 重调查任务，尽量交给子 Agent

子 Agent 真正值钱的地方，不只是并行。
更重要的是它可以把大量探索过程隔离在自己的上下文窗口里，最后只回传摘要。

这对主 Agent 很重要。
因为主 Agent 最该保存的是高密度结论，不是十几轮原始搜索记录。

OpenClaw 的多 Agent 架构把这件事做到了工程级别：每个 Agent 拥有独立的工作区、独立的会话存储、独立的认证配置。子 Agent 使用promptMode=minimal的精简系统提示词，省略 Skills、Memory Recall、Heartbeats 等对子任务不必要的部分，进一步控制上下文开销。

这个可以看看我们的往期文章,关于OpenClaw的分析。

7. 看缓存指标，别只盯总 token

官方文档里已经把几个字段给得很明确了：

• •cache_creation_input_tokens
• •cache_read_input_tokens
• •input_tokens

如果系统已经接了缓存，但命中一直不高，这往往不是统计问题，而是结构问题。

工程上可以直接用工具来排查：

• •/context list→ 查看窗口有多满、每个注入文件的大小
• •/context detail→ 深入看每个工具 schema、每个 Skills 条目的 token 占用
• •/usage tokens→ 每次回复后附加使用量明细
• •/status→ 包含会话 token 数和估算费用

8. 缓存不热时，先看结构，再看模型

很多团队一碰到结果不稳，第一反应还是换模型、补 Prompt、加规则。
这些手段不是不能用，但如果上下文结构本身就乱，它们很容易越补越重。

先看前缀是不是稳定。
再看工具是不是漂移。
再看历史是不是该压缩。
最后才看模型能力是不是瓶颈。

这个顺序，通常会更省力。

下面这张决策图可以当作快速排查参考：

一张表对齐：该把什么放哪里

如果把"缓存友好"作为一个额外的维度加进上下文分层决策，这张表可以直接当内部对齐材料：

这套分层一旦不清楚，最常见的结果就是"什么都往一个地方堆"。堆到最后，Agent 往往不是能力不够，而是分不清现在最重要的是什么，缓存也永远热不起来。

学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%免费】