这两天看Prompt Cache相关讨论我越来越确定一件事很多人以为自己在讨论一个“省钱功能”但大家真正碰到的是 Agent 的上下文管理问题。表面上看Prompt Cache说的是 token 成本、请求加速和缓存命中率。但再往前走一步它逼着我们重新回答一个更根本的问题一个要连续运行几十分钟、甚至几小时的 Agent到底该怎么组织自己的上下文上下文成本最后会反过来塑造 Agent 的架构。所以这里不想把Prompt Cache写成一篇原理课。更想聊的是为什么它看起来像一个优化点最后却会落到架构纪律上。先把结论放在前面。先别把它看成“省钱技巧”Akshay Pachaar 那篇文章里有一句话我觉得抓得很准Agent 每走一步都在交一次“上下文税”。因为它把一件平时很容易被忽略的事讲得足够直白。我们在和 Agent 交互时体感通常只盯着两样东西• 它回得够不够快• 它做得够不够对但在模型真正运行时还有一个经常被藏在背后的成本项每一轮请求系统都要重新处理那一大段并没有变化的上下文。系统提示词没变。工具定义没变。项目背景没变。一些常驻规则也没变。问题是只要我们还是按普通请求去发模型就还是得把这些内容从头再走一遍。拿 OpenClaw 的/context detail输出举例一个系统提示词可能占到 9600 token仅工具 schema 就要 8000 tokenSkills 列表再占 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 的上下文预算拆成三层大致的成本结构长这样层级构成特征缓存友好度固定开销系统提示词、工具 schema、Skills 列表还没开始干活预算已花掉⭐⭐⭐ 最适合缓存半固定开销CLAUDE.md / AGENTS.md、Memory、项目契约每次会话加载低频变化⭐⭐ 保持稳定则可缓存动态开销对话历史、文件内容、工具输出天然增长每轮都不同⭐ 无法缓存需主动治理前两层越稳定缓存命中率越高。第三层越大系统越容易变慢变贵。前几天我们一直在讲的也是这个道理不是所有信息都该常驻上下文。有些东西必须长期稳定存在。有些东西只需要按需加载。有些东西看完就应该压缩。还有一些东西最好根本不要进主会话。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 CodeOpenClaw 是怎么做的原始素材里反复提 Claude Code不只是因为它热。更重要的是它刚好把这些问题都集中暴露了出来。但如果只看 Claude Code 一个产品视野容易变窄。OpenClaw 作为一套开源的 Agent 运行时在同一组问题上做了一套完整的工程方案拆开看更有参考价值。一个长会话 Agent 产品有几个很典型的特征• 会连续执行很多轮• 会反复调用工具• 会不断引入新的终端输出• 会在主线程和子线程之间来回传递结果• 很容易在长任务里把上下文越堆越厚如果没有缓存、压缩和隔离这类产品会很快遇到三个问题成本上来旧上下文反复重算账单非常直接。延迟变差每一轮都得重新处理一大段前缀会话越来越拖。注意力变散该保留的和不该保留的都混在一起模型越来越难抓重点。OpenClaw 为此建了一整套上下文治理管线每一层解决的问题不同机制做什么解决什么问题系统提示词固定结构每次运行由系统重建固定顺序保持前缀稳定利好缓存Skills 按需加载系统提示词只放列表元数据指令 read 时才加载避免固定开销膨胀Session Pruning在 LLM 调用前修剪旧工具结果软修剪 硬清除缓存 TTL 过期后减少 cacheWrite 成本Compaction将早期对话总结为紧凑摘要保持近期消息不变窗口逼近上限时释放空间压缩前记忆刷写在压缩前触发静默轮次将持久笔记写入磁盘避免压缩丢失重要信息多 Agent 隔离每个 Agent 独立工作区 会话 认证高噪音调查不污染主会话其中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 使用promptModeminimal的精简系统提示词省略 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、加规则。这些手段不是不能用但如果上下文结构本身就乱它们很容易越补越重。先看前缀是不是稳定。再看工具是不是漂移。再看历史是不是该压缩。最后才看模型能力是不是瓶颈。这个顺序通常会更省力。下面这张决策图可以当作快速排查参考一张表对齐该把什么放哪里如果把缓存友好作为一个额外的维度加进上下文分层决策这张表可以直接当内部对齐材料层级应该放什么缓存影响治理原则系统提示词工具列表、Safety、运行时元数据⭐⭐⭐ 最稳定缓存收益最高由系统拥有不手动修改引导文件构建命令、项目契约、必须遵守的边界⭐⭐ 保持精短则稳定控制在 2-3K token别写成百科Skills / rules任务型工作流、路径级约束⭐⭐ 列表稳定内容按需系统提示词只放元数据记忆层每日日志、长期决策、用户偏好⭐ 按需检索不占前缀写入磁盘语义搜索取回对话历史用户消息 助手回复增长部分无法缓存适时 compact修剪旧工具结果子 Agent大量探索、并行研究、高噪音调查完全隔离不影响主缓存只回传摘要不保留过程这套分层一旦不清楚最常见的结果就是什么都往一个地方堆。堆到最后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%免费】
Prompt Cache深度解析教程（非常详细），Agent架构纪律从入门到精通，收藏这一篇就够了！
发布时间：2026/5/19 14:38:27
这两天看Prompt Cache相关讨论我越来越确定一件事很多人以为自己在讨论一个“省钱功能”但大家真正碰到的是 Agent 的上下文管理问题。表面上看Prompt Cache说的是 token 成本、请求加速和缓存命中率。但再往前走一步它逼着我们重新回答一个更根本的问题一个要连续运行几十分钟、甚至几小时的 Agent到底该怎么组织自己的上下文上下文成本最后会反过来塑造 Agent 的架构。所以这里不想把Prompt Cache写成一篇原理课。更想聊的是为什么它看起来像一个优化点最后却会落到架构纪律上。先把结论放在前面。先别把它看成“省钱技巧”Akshay Pachaar 那篇文章里有一句话我觉得抓得很准Agent 每走一步都在交一次“上下文税”。因为它把一件平时很容易被忽略的事讲得足够直白。我们在和 Agent 交互时体感通常只盯着两样东西• 它回得够不够快• 它做得够不够对但在模型真正运行时还有一个经常被藏在背后的成本项每一轮请求系统都要重新处理那一大段并没有变化的上下文。系统提示词没变。工具定义没变。项目背景没变。一些常驻规则也没变。问题是只要我们还是按普通请求去发模型就还是得把这些内容从头再走一遍。拿 OpenClaw 的/context detail输出举例一个系统提示词可能占到 9600 token仅工具 schema 就要 8000 tokenSkills 列表再占 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 的上下文预算拆成三层大致的成本结构长这样层级构成特征缓存友好度固定开销系统提示词、工具 schema、Skills 列表还没开始干活预算已花掉⭐⭐⭐ 最适合缓存半固定开销CLAUDE.md / AGENTS.md、Memory、项目契约每次会话加载低频变化⭐⭐ 保持稳定则可缓存动态开销对话历史、文件内容、工具输出天然增长每轮都不同⭐ 无法缓存需主动治理前两层越稳定缓存命中率越高。第三层越大系统越容易变慢变贵。前几天我们一直在讲的也是这个道理不是所有信息都该常驻上下文。有些东西必须长期稳定存在。有些东西只需要按需加载。有些东西看完就应该压缩。还有一些东西最好根本不要进主会话。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 CodeOpenClaw 是怎么做的原始素材里反复提 Claude Code不只是因为它热。更重要的是它刚好把这些问题都集中暴露了出来。但如果只看 Claude Code 一个产品视野容易变窄。OpenClaw 作为一套开源的 Agent 运行时在同一组问题上做了一套完整的工程方案拆开看更有参考价值。一个长会话 Agent 产品有几个很典型的特征• 会连续执行很多轮• 会反复调用工具• 会不断引入新的终端输出• 会在主线程和子线程之间来回传递结果• 很容易在长任务里把上下文越堆越厚如果没有缓存、压缩和隔离这类产品会很快遇到三个问题成本上来旧上下文反复重算账单非常直接。延迟变差每一轮都得重新处理一大段前缀会话越来越拖。注意力变散该保留的和不该保留的都混在一起模型越来越难抓重点。OpenClaw 为此建了一整套上下文治理管线每一层解决的问题不同机制做什么解决什么问题系统提示词固定结构每次运行由系统重建固定顺序保持前缀稳定利好缓存Skills 按需加载系统提示词只放列表元数据指令 read 时才加载避免固定开销膨胀Session Pruning在 LLM 调用前修剪旧工具结果软修剪 硬清除缓存 TTL 过期后减少 cacheWrite 成本Compaction将早期对话总结为紧凑摘要保持近期消息不变窗口逼近上限时释放空间压缩前记忆刷写在压缩前触发静默轮次将持久笔记写入磁盘避免压缩丢失重要信息多 Agent 隔离每个 Agent 独立工作区 会话 认证高噪音调查不污染主会话其中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 使用promptModeminimal的精简系统提示词省略 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、加规则。这些手段不是不能用但如果上下文结构本身就乱它们很容易越补越重。先看前缀是不是稳定。再看工具是不是漂移。再看历史是不是该压缩。最后才看模型能力是不是瓶颈。这个顺序通常会更省力。下面这张决策图可以当作快速排查参考一张表对齐该把什么放哪里如果把缓存友好作为一个额外的维度加进上下文分层决策这张表可以直接当内部对齐材料层级应该放什么缓存影响治理原则系统提示词工具列表、Safety、运行时元数据⭐⭐⭐ 最稳定缓存收益最高由系统拥有不手动修改引导文件构建命令、项目契约、必须遵守的边界⭐⭐ 保持精短则稳定控制在 2-3K token别写成百科Skills / rules任务型工作流、路径级约束⭐⭐ 列表稳定内容按需系统提示词只放元数据记忆层每日日志、长期决策、用户偏好⭐ 按需检索不占前缀写入磁盘语义搜索取回对话历史用户消息 助手回复增长部分无法缓存适时 compact修剪旧工具结果子 Agent大量探索、并行研究、高噪音调查完全隔离不影响主缓存只回传摘要不保留过程这套分层一旦不清楚最常见的结果就是什么都往一个地方堆。堆到最后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%免费】
