目录引言核心解析一、请求发出之前七种压缩机制的协同作战二、Prompt Cache字节级前缀匹配的缓存哲学三、会话关闭之后从磁盘恢复的指针链深度洞察三重视角的统一屏幕历史、API视图与磁盘逻辑链对 Agent 架构设计的启示与竞品方案的对比思考总结与展望引言如果你用过 Claude Code 写一个稍微复杂点的项目你一定经历过这样的场景对话进行了几十轮上下文已经长得离谱但它依然能准确地记得你最初定下的架构约定响应速度也没有明显变慢。这背后的技术实现远比大多数人想象的要精妙。大语言模型的上下文窗口是一个固定大小的舞台——对于 Claude 来说这个舞台大约是 200K token。当 Agent 持续运行时工具调用结果、代码片段、对话历史会像潮水一样涌入迅速填满这个空间。如何在有限的上下文窗口中维持尽可能多的有效信息同时控制成本和延迟这是每一个严肃的 AI Agent 系统都必须面对的核心工程挑战。本文将从 Claude Code 的实际实现出发深入剖析它的上下文管理策略。这不是一篇泛泛而谈的概念科普而是从字节级的缓存匹配到会话链的指针恢复拆解一个工业级 Agent 系统是如何在省 token和保信息这对矛盾中找到精妙平衡的。请求发出之前的压缩策略 会话关闭之后的恢复机制核心解析一、请求发出之前七种压缩机制的协同作战Claude Code 的上下文管理并不是一个简单的满了就截断策略。在每一次请求发送给 API 之前系统会经过一套精密的压缩流水线。根据视频中的梳理这套流水线包含七种不同的机制它们分别作用在不同的维度上。七种上下文压缩机制总览从工具结果外置到响应式压缩覆盖交互历史、接口视图、逻辑链和服务器端四个维度工具结果外置是最基础的一步。当 Agent 调用工具比如读取一个文件、执行一条命令时返回结果往往非常冗长。Claude Code 不会把这些原始结果一直留在上下文中而是将大段的工具输出外置存储上下文中只保留一个精简的引用。这就像你在写论文时不会把参考文献全文抄进正文而是放一个引用标记。在此基础上上下文折叠Context Folding和Snip 机制负责处理对话历史中的冗余。折叠是将较早的对话轮次压缩成摘要而 Snip 则更激进——它直接裁剪掉某些对当前任务已经不再 relevant 的中间步骤。这两种机制的关键区别在于折叠保留了信息的骨架而 Snip 是判断某些信息已经完全不需要了。全量压缩和会话记忆压缩则是在更高层面运作的。当上下文接近窗口上限时系统会触发全量压缩将整段历史浓缩为一份结构化的摘要。而会话记忆压缩更进一步它提取的不是简单的文本摘要而是目标—进展—关键结论这样的结构化笔记确保即使上下文被大幅压缩Agent 仍然知道我在做什么、做到了哪一步、得到了什么结论。最后是响应式压缩这是一种按需触发的机制。当系统检测到某些特定的模式比如重复的工具调用、循环的对话模式时会主动对相关部分进行压缩。二、Prompt Cache字节级前缀匹配的缓存哲学如果说压缩机制解决的是放什么进上下文的问题那么 Prompt Cache 解决的就是怎么让重复的内容少花钱的问题。这里有一个极其重要但常被误解的技术细节Claude 的 Prompt Cache 是基于字节级前缀匹配的。Prompt Cache 的前缀匹配机制第N轮缓存的内容在第N1轮、N2轮中按字节精确匹配复用这意味着什么假设你在第 N 轮对话时发送了一段 50000 token 的上下文系统将其缓存。到了第 N1 轮你新增了 2000 token 的内容系统会从头开始逐字节比对——如果前 50000 token 与缓存完全一致一个字节都不差那么这部分就直接命中缓存只需要为新增的 2000 token 付费。但这里有一个极其关键的推论改一个字后面的缓存整段作废。因为前缀匹配是从头开始的一旦在某个字节上出现不一致从这个位置开始的所有内容都无法命中缓存。这就解释了为什么 Claude Code 的压缩策略有一条铁律——宁可多花 token也不改一个已经发出去的字。整套设计的核心矛盾在省 token和保缓存之间找平衡这句话道出了整个上下文管理系统的设计哲学。你可能会想既然有压缩机制为什么不把历史内容压缩得更短省下 token问题在于一旦你修改了已经发送过的内容哪怕只是删除一个逗号后续所有轮次的缓存都会失效。省下的那一个 token 的费用远远比不上缓存全部作废后重新计算的成本。所以 Claude Code 的策略是对已发送的内容只做追加不做修改。压缩只发生在还没发出去的部分或者通过新增一个压缩摘要的方式来替代旧内容而不是直接修改旧内容本身。这种设计思路与我们日常理解的压缩有本质区别。它不是在同一个位置反复优化而是在追加的约束下做信息密度的最大化。这是一种典型的面向缓存友好的不可变设计与函数式编程中不可变数据的理念异曲同工。三、会话关闭之后从磁盘恢复的指针链上下文压缩解决的是对话进行中的问题但现实场景中用户经常会关闭终端、切换项目、甚至重启电脑。当会话关闭后再次打开Claude Code 如何恢复到之前的状态答案是基于指针链的会话恢复机制。Claude Code 将每一轮对话都存储在磁盘上并通过指针将它们串联成一条逻辑链。每个节点都包含该轮的完整内容以及指向前一个节点的指针。当你选择 Resume恢复时系统沿着这条链重新加载历史重建上下文。Resume 与 Fork 的区别Resume 是沿着同一条链继续Fork 是另开一条新链并分配新的 Session ID但这里有一个精妙的设计Session Notes会话笔记。在漫长的会话中系统会持续维护一份结构化的笔记记录三个维度的信息当前目标是什么、进展到了哪一步、得到了哪些关键结论。这份笔记不是简单的文本摘要而是带有轮次标记的结构化数据——它知道自己在第 4 轮、第 6 轮、第 9 轮分别得出了什么结论。当会话恢复时这份笔记就是 Agent 快速回忆的关键。即使完整的对话历史因为上下文长度限制无法全部加载笔记本身就能提供足够的信息让 Agent 理解我之前在做什么、做到哪了。这就像你开会时做的笔记——即使录音丢了笔记还在你就能快速接上思路。除了 Resume还有Fork模式。Fork 会从当前节点分叉出一条全新的逻辑链分配一个新的 Session ID但保留对父节点的引用。这让你可以在不破坏原有会话的前提下探索不同的方向。如果说 Resume 是在同一条路上继续走那 Fork 就是在路口选一条新路但记住你从哪来的。深度洞察三重视角的统一屏幕历史、API视图与磁盘逻辑链理解 Claude Code 上下文管理的一个关键认知是同一个会话存在三个不同版本的历史。用户在屏幕上看到的交互历史、发送给 API 的实际内容视图、以及磁盘上存储的逻辑链这三者并不完全相同。屏幕历史是用户视角的它展示完整的对话过程包括被折叠和裁剪的部分。API 视图是经过压缩流水线处理后的最终版它决定了模型实际看到什么。磁盘逻辑链则是最完整的记录保存了每一轮的原始数据是会话恢复的基础。这种三层分离的设计带来了一个重要的工程优势每一层都可以独立优化。你可以改变压缩策略影响 API 视图而不影响用户的屏幕体验你可以修改存储格式影响磁盘逻辑链而不影响正在进行的对话。这种解耦是大型 Agent 系统能够持续演进的关键。对 Agent 架构设计的启示Claude Code 的上下文管理策略给我们带来了几个重要的架构启示。首先是不可变前缀原则的普适价值。在任何需要维护长上下文的 Agent 系统中对已发送内容保持只追加不修改的策略都能带来缓存效率的巨大提升。这个原则不仅适用于 Claude 的 Prompt Cache对于任何有类似缓存机制的 LLM API 都成立。其次是结构化笔记优于文本摘要。会话记忆压缩不是简单地把长文缩短而是提取出目标、进展、结论这样的结构化信息。这让我们想到在 Agent 系统中信息的形状比信息的长度更重要。一段 500 token 的结构化笔记可能比 5000 token 的完整摘要更有价值。最后是压缩时机的选择比压缩算法本身更重要。Claude Code 的七种压缩机制并不是同时触发的而是在不同的时机、针对不同的场景分别激活。微压缩在每次请求前静默执行全量压缩在接近上限时触发响应式压缩在检测到特定模式时启动。这种分层、分时的策略远比一刀切的压缩方案更加优雅和高效。与竞品方案的对比思考对比其他 AI 编程助手的上下文管理策略可以看到不同的设计取舍。有些工具选择简单地截断历史对话实现简单但信息损失大有些采用滑动窗口策略保留最近 N 轮对话但会丢失早期的重要约定还有些使用向量检索来回忆历史信息但检索的准确性和延迟都是问题。Claude Code 的方案之所以更精巧在于它不是在某一个维度上做优化而是在缓存友好性、信息保留度、计算成本三个维度上同时寻找平衡点。七种压缩机制各有分工Prompt Cache 的字节级匹配确保了缓存效率指针链的会话恢复保证了持久性——这是一个系统工程的胜利而不是某个单一算法的突破。总结与展望Claude Code 的上下文管理系统给我们展示了工业级 Agent 系统的一个重要切面在有限的上下文窗口中如何通过精密的压缩策略和巧妙的缓存设计实现信息密度和成本效率的最优平衡。核心要点回顾七种压缩机制各司其职从工具结果外置到响应式压缩覆盖了上下文管理的全生命周期Prompt Cache 的字节级前缀匹配催生了不可变前缀的设计哲学即宁可多花 token 也不修改已发送内容会话恢复通过指针链和结构化笔记实现了可靠的持久化和快速恢复。对于正在构建 AI Agent 系统的开发者有三个可以直接借鉴的实践第一将上下文视为只增不减的不可变序列来设计缓存策略第二用结构化的笔记替代纯文本摘要来保存关键信息第三将压缩机制分层分时部署而不是依赖单一策略。这些看似简单的原则背后是对 LLM 系统特性的深刻理解也是从工程实践中提炼出的宝贵经验。随着模型上下文窗口的持续扩大GPT-4 Turbo 的 128K、Claude 的 200K、Gemini 的 1M有人可能会问上下文管理还重要吗答案是不仅重要而且更重要了。更大的窗口意味着更多的信息涌入对压缩和缓存的效率要求更高。上下文管理不是一个会被窗口扩大消灭的问题而是一个会随规模增长变得更加复杂的问题。理解 Claude Code 的设计思路就是为应对这个持续增长挑战做好准备。