記憶系統的三個工程取捨：Claude Code 的設計告訴我們什麼
Claude Code 的記憶架構設計揭示了三個工程取捨：索引層的維護成本、非同步濃縮的同步延遲、以及身份隔離的架構投入。沒有免費的午餐，關鍵是在你的場景下選對取捨。
索引層不是免費的
大多數開發者在設計 LLM 記憶系統時，第一反應是把所有歷史堆進 context。但 Claude Code 的設計揭示了一個實用的取捨：用輕量索引駐留在 context 裡（大約 150 字/行），實際內容按需載入。
這解決的是兩個具體問題。第一，token 預算。如果每次互動都載入完整歷史，成本會隨時間線性增長。第二，檢索速度。索引層讓模型快速定位相關資訊，而不是掃描整個記憶庫。
但代價呢？索引層的維護需要嚴格的寫入規律。索引和實際內容必須保持同步，否則檢索會失效。這不是技術難度高的問題，而是一個容易被忽視的運維成本。一旦索引損壞，修復會很麻煩。
問題變成：這個複雜度值不值得？對於長時間運行的 agent 或需要頻繁查詢歷史的場景，答案可能是值得。但如果你的記憶生命週期短，或查詢不頻繁，簡單地丟進 context 可能更划算。
記憶不應該只在互動時更新
autoDream 是一個後台無人監督的進程，定期整合矛盾、刪除過時資訊。這挑戰了一個直覺的做法：每次用戶互動時實時更新記憶。
實時更新的問題在於，它被動地反應當下的輸入。如果記憶裡有矛盾的資訊，實時更新會堆積矛盾，而不是解決矛盾。如果有過時的資訊，它會一直躺在那裡。
autoDream 的做法是主動進化。定期讓模型回顧整個記憶庫，找出矛盾、過時、冗餘的部分，做濃縮和清理。這帶來的好處是記憶聚焦，壞處是引入了延遲和失同步的風險。
關鍵取捨是：濃縮帶來的聚焦效率，值不值得記憶在某個時間窗口內可能不是最新的？對於需要快速反應的場景，這個延遲可能不可接受。對於長期運行的 agent，可能反而是必要的。
身份隔離是架構問題，不是提示詞問題
Undercover Mode 解決的是一個實務問題：當 AI 在公開倉庫工作時，如何防止內部身份洩露？
簡單的做法是在提示詞裡加一句「不要暴露你的身份」。但這不夠。Anthropic 的做法是在架構層做身份檢測和提示詞注入機制，確保即使模型被誘導，也無法洩露身份資訊。
這說明生產級 AI 工具的安全設計不能只依賴提示詞。多租戶場景或公私混合場景下，你需要：
- 角色感知的系統設計——系統知道當前在哪個身份上下文執行
- 架構層的隔離——不同身份的記憶和權限物理隔離，而不是邏輯隔離
- 檢測機制——能識別試圖跨越身份邊界的請求
簡單的 prompt 控制對內部工具可能夠用。但一旦 AI 工具暴露在不可信的環境，這些防線就必要了。
這些取捨的共同點
索引層、非同步濃縮、身份隔離，看起來是三個不同的問題。但它們都指向同一個原則：記憶系統的設計必須面對現實的約束。
沒有一個方案是完美的。索引層增加維護成本，非同步濃縮引入延遲，身份隔離需要架構投入。但如果你的系統要在生產環境長期運行，這些成本是避免不了的。問題不是要不要付出，而是在你的具體場景下，哪個取捨最合理。
我是江中喬，一位具有 TPM 與產品管理背景的 AI 系統建構者，目前專注於 AI 認知增強系統與多 Agent 協作架構的設計與實踐。