CMU隆博士解读：ClaudeCode 7层记忆机制troyhua
许多技术大神进行了超详细的解析，发现一个不超过 200 行的 MEMORY.md 文件竟是解决记忆问题的关键！
众所周知，上下文窗口有限——LLM难为了无数开发者的致命痛点随着 CloudeCode完整代码在被迫开源之后，被给出解决方案了！
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）
压缩后修复：重新注入最近读的文件、技能内容、计划附件等关键上下文
