卡內基梅隆博士ClaudeCode 7層記憶機制神解讀！僅200行代碼文件竟然是記憶關鍵！網友...

來源：市場資訊

（來源：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 編碼助手時，遇到過最嚴重的問題是什么？

歡迎在評論區分享補充！