来源：市场资讯
（来源：51CTO技术栈）
作者 | troyhua
众所周知，上下文窗口有限——LLM难为了无数开发者的致命痛点随着 CloudeCode完整代码在被迫开源之后，被给出解决方案了！
许多技术大神进行了超详细的解析，发现一个不超过 200 行的 MEMORY.md 文件竟是解决记忆问题的关键！
X上一位卡内基梅隆博士大佬@troyhua对Claude Code进行了一场深度分析，与之前网络上流传的全代码拆解不同，troyhua则选择了解读Claude Code最精彩、也最复杂的、也是外界最难复刻的：7层记忆架构！
它像人类大脑一样，分层管理记忆：从毫秒级的轻量清理，到“做梦机制”巩固长期记忆，层层递进。
这套系统工程之精妙，堪称当前Agentic AI的教科书级设计。
来，一起拆解这套“AI永生记忆系统”！
01 核心问题：上下文窗口是LLM的“金鱼记忆”
LLM有一个基本约束：固定的上下文窗口，Claude Code默认200K token窗口（加[1m]后缀可到1M）。但一次真实coding：读几个大文件 + grep全仓库 + 几轮编辑 = 轻松超标。
它的解决方案？不是简单扩窗，而是7层渐进式记忆管理：每层成本递增、能力递增，层层防护，避免下一层触发。
Token 计数的底层基础是tokenCountWithEstimation（）函数：优先使用上次 API 返回的精确 input_tokens，再对新增消息做粗估（普通文本约 4 bytes/tokens，JSON 更省，图片/文档固定 2000 tokens）。还预留了约 20K tokens 作为输出缓冲，绝不把窗口用满，避免压缩时自己都塞不下。
上下文窗口解析优先级也很讲究：模型后缀 [1m] → 模型能力查询 → Beta Header → 环境变量 → 默认 200K。
02 7层记忆架构详解：从便宜到昂贵
这套架构像一座防御金字塔，越往上越强大但也越贵。系统设计的核心是“预防为主”，尽可能防止N+1层触发。
第1层：工具结果存储——“日常清洁工”
单次 grep 可能返回 100KB+ 文本，大文件 cat 也可能 50KB。这些内容如果直接塞进上下文，不仅浪费 Token，还很快就会过时。
而Claude code 的解决方案是：每个工具的结果在进入上下文前都会经过预算系统，超过其阈值时：
完整结果写到磁盘（tool-results//.txt）
上下文里只放前 ~2KB 预览，用<持久输出>标签包裹
模型如果需要，可以后续用 Read 工具读取完整版
而且，一个关键之处：内容替换状态：一旦决定用预览，就把这个决定“冻结”。后续所有 API 调用都用同样的预览，确保 Prompt 前缀字节完全一致，最大化缓存命中率。这个状态甚至会持久化到会话记录里，支持 resume。
同时，每个工具的阈值可以通过 tengu_satin_quoll 功能标志远程调节——使 Anthropic 能够在无需代码部署的情况下调整特定工具的持久性阈值。
第2层：微压缩——每轮对话前的“日常保洁”
这是最轻量级的上下文清理，几乎不花 API 成本，每轮 API 调用前都会执行。
微压实不会总结任何内容——只是清除那些不太可能用到的旧工具结果。
拥有三种不同的机制：
a） 基于时间
如果距离上次助手消息超过阈值（默认 60 分钟），因为服务器端 Prompt Cache TTL 约 1 小时，缓存已过期，可以放心清理旧工具结果，替换为 “[Old tool result content cleared]”，但保留最近 N 条。
配置（通过GrowthBook tengu_slate_heron）：
b） 缓存微型压缩
这是技术上最有趣的机制。用 cache_edits 在服务器端删除旧工具结果，而本地消息不变，避免破坏缓存前缀。工具结果会注册到全局 CachedMCState，超过阈值就选最旧的删。
关键点：只运行主线。如果分支的子代理（session_memory、agent_summary等）修改了全局状态，就会破坏主线程的缓存编辑。
c） API级上下文管理
一种较新的服务器端方法，使用 context_management API 参数：直接让 API 处理部分清理。
第3层：会话记忆——最聪明的一层！
最不是等上下文满了再慌张总结，而是实时维护结构化笔记。
每个会话都会获得一个标记文件，
地址为：
~/.claude/projects//.claude/session-memory/.md
带有结构化模板：
触发条件：Token 增长达到阈值 +（工具调用次数达标 或 上轮无工具调用）。
当自动压缩触发时，它首先尝试trySessionMemoryCompaction（）：
检查会话内存是否有实际内容（而不仅仅是空模板、使用会话内存标记作为压缩摘要——无需调用 API、计算哪些最近消息要保留（从最后一个SummarizedMessageId向后扩展以达到最低要求、返回一个压缩结果，会话内存为摘要+保留的近期消息
当需要压缩时，直接注入这个现成总结——零额外API调用，成本极低！
第4层：全压缩——上下文快满时的“紧急刹车”
当 tokenCountWithEstimation（） 超过自动压缩阈值（有效窗口 - 13K）且 Session Memory 不可用时触发。
压缩流程超级严谨：
预处理：执行用户 PreCompact hook，去除图片、技能附件等
生成摘要：系统通过详细提示向摘要代理分支，要求提供9个部分的摘要：先写<分析>草稿思考，再输出<摘要>正文（草稿会被剥离，不占最终 Token）
打开网易新闻 查看精彩图片压缩后修复：重新注入最近读的文件、技能内容、计划附件等关键上下文
插入 SystemCompactBoundaryMessage 标记压缩点
还有 只压缩部分消息和提示本身过长恢复机制（分组丢弃最旧消息，重试 3 次）！
第5层：自动记忆提取——构建跨会话的长期知识库
每任务结束时，提取跨会话的持久知识，存到~/.claude/projects/.../memory/目录。
拥有四种记忆类型，每种都有特定条件和格式：
同时，还有 MEMORY.md 索引文件，它是一个索引文件，最多 200 行或 25KB，超出自动截断，每个条目应为一行低于~150字符。
第6层：做梦机制——进行跨会话记忆巩固
这可能是整篇文章里最让人惊艳的部分。它会在积累足够会话后触发，像人脑睡眠时巩固记忆一样：回顾过去会话日志，组织、整合、清理长期记忆。
并且门控序列设计非常聪明：从最便宜的检查开始，大部分情况会早早退出。
用锁文件（.consolidate-lock）实现互斥：包含 PID 和时间戳，支持崩溃恢复和 stale 检测。
四个阶段：
第一阶段标定位置：扫描 memory 目录，读 MEMORY.md，避免重复
第二阶段收集：只 grep 怀疑重要的片段，检查矛盾记忆
第三阶段合并：合并新信号到现有文件，删除矛盾事实，把相对日期转为绝对日期
第四阶段整理与索引：更新 MEMORY.md，删除过时条目，解决文件间矛盾
Dream Agent 工具受严格限制：Bash 只读，Edit/Write 只限 memory 目录。
在 UI 上会显示为后台任务，用户可以从后台任务对话框中终止，锁会回滚方便下次重试。
第7层：跨代理沟通——多 Agent 协作的基础
几乎所有后台操作（Session Memory、Dreaming 等）都基于分支代理模式 模式。
分支代理时状态隔离（克隆 LRU 缓存、abortController 等），但通过 CacheSafeParams 和相同前缀共享 Prompt Cache，实现高效;Agent Tool 支持多种模式，SendMessage Tool 实现 Agent 间实时通信（支持广播、跨会话等;还有 Agent Summary：每 30 秒用最便宜的 Haiku 模型生成 3-5 词进度快照，用于协调。
代理工具支持多种生成模式：
代理可以在三个范围内的调用间维持持久内存：
03 代码细节：层层推进，超级完善
这套 7 层架构之所以牛，不只是分层，还有非常多细节：
分层防御，先用最便宜
每个上下文管理层都设计为防止下一层更昂贵的层触发
提示缓存保存
几乎每一个设计决策都考虑了即时缓存的影响。
隔离但共享
分叉的代理获得克隆可变状态（防止交叉污染），但共享提示缓存前缀（防止成本爆炸）
到处都是阻断
3 次失败自动阻断、锁文件 PID 检测、互斥检查......防止小问题变成大灾难。
GrowthBook 远程特征开关
几乎所有系统都被GrowthBook的功能标志所限制，关键功能随时可以回滚，工程成熟度极高。
在这篇分析中，你可以清晰的看到 CloudeCode 的细节控，似乎不再是一个简单的代码补全工具，而更像一个会思考、会记忆、会“睡觉巩固知识”的真正编程伙伴。
你最近在使用 Claude Code、Cursor 或其他 AI 编码助手时，遇到过最严重的问题是什么？
欢迎在评论区分享补充！
热门跟贴