規則檔之後，作者 @wquguru 把記憶分成兩個容易被混為一談、實則該嚴格拆開的層：每輪都要重新載入的「常駐畫像」，與平時躺在磁碟、要用才撈的「歷史召回」。這篇把原文的第二、三層併在一起談，因為它們的核心張力是同一個——什麼值得每輪付 token 稅，什麼不值得。
第二層：常駐畫像——每輪都要付 token 稅的東西
作者用 Hermes Agent 當範例：它內建 MEMORY.md（agent 自己的高密度筆記：環境事實、專案約定、學到的經驗）與 USER.md（用戶畫像：偏好、溝通風格、長期期待），兩個檔在 session 啟動時直接注入 system prompt，而且有嚴格長度上限——超限不是靜默壓縮，是直接報錯，逼 agent 自己去合併、替換、刪除。
作者欣賞這個設計的「克制」：常駐記憶不是越多越好，它每輪都要付 token 稅，而且位置越靠前越容易影響模型判斷。把大量未整理的歷史塞進常駐記憶，agent 會變得又貴又混亂。他主張常駐記憶只放三類東西：身份（這個 agent 是誰、長期職責）、偏好（用戶穩定地喜歡/不喜歡什麼）、不變量（環境中反覆成立、下次必然有用的事實）。他舉自己的 garden memory 為例，只記「公開 handle 用 wquguru」「AGENTS.md 與 .agents/skills 是 symlink」「garden deploy 走 Cloudflare Pages + Access」這類下次必然用得上的事實。第二條設計原則：常駐記憶應該短、硬、高密度；歷史不該常駐，只有壓縮後的身份、偏好與不變量才值得常駐。
第三層：歷史召回——大部分記憶不該常駐，但必須能被找到
那不該常駐的歷史放哪？作者的答案是按需召回：需要時搜出來，不需要時安靜待在磁碟上。他列了三套做法：
- Hermes 用 SQLite FTS5 保存所有 CLI 與 messaging session，提供
session_search，完整保留原始訊息、無摘要折損，還能沿 session 前後滾動看上下文。 - OpenClaw 把 workspace 設計得像檔案系統記憶：
MEMORY.md是精煉層、memory/YYYY-MM-DD.md是日常筆記、DREAMS.md存離線思考產出；memory_search／memory_get負責召回，配了 embedding provider 後能做 vector + keyword 混合搜索。 - Codex 的 Memories 走同一路子：把舊線程裡穩定的偏好、工作流、技術棧、專案約定、已知坑轉成本地 memory files，未來任務按需帶入。
作者的歸納很傳神：常駐記憶像索引頁（很短），歷史召回像資料庫（很大），搜索負責在需要時把資料庫裡的局部片段精準拿出來。第三條設計原則：歷史記憶應該可搜索、可追溯、可局部讀取，而不是全部常駐上下文。
業界脈絡與客觀補充
「常駐 vs 召回」的拆分對應到學術界 Stanford Generative Agents（Park et al., 2023）的 memory stream 設計：所有觀察、計畫、反思都以自然語言＋時間戳＋存取紀錄寫進一條 memory stream，再用 recency（時間衰減）× importance（LLM 給的重要度）× relevance（embedding 相似度） 三者加權的檢索分數，挑出當下該載入的記錄。作者口語化的「索引頁 vs 資料庫」，在學術上就是「常駐 working context vs 帶評分函數的長期記憶檢索」。
需要持平指出的是：作者把這寫成幾條乾淨原則，但「多短才算短」「該用 FTS5、向量、還是混合檢索」並無放諸四海的答案。向量召回擅長語意相似與近期事實，卻在「多跳關係」與「精確時序」上吃虧；FTS5／BM25 這類關鍵字檢索在精確比對上反而穩。實務多採混合檢索，而最佳權重高度依賴資料分布與任務——這部分屬於工程取捨，不是定論。
延伸
- 歷史記憶光記「結論」不夠，得記「憑什麼」→ 證據鏈與治理記憶
- 全景與閱讀路徑 → AI memory 專欄首頁