把前面五層放回真實工具裡，作者 @wquguru 用一張對照表收束全文，並推介一個他認為「踩中方向」的工程起點 EverOS。這篇同時補上 MemGPT／Letta／mem0 等業界記憶層的對照，並對 EverOS 的利益關係做必要揭露。
作者的四層應用對照
把 Claude Code、Codex、OpenClaw、Hermes 放在一起，作者主張應用層 memory 正分化為四層：
- 規則層：
CLAUDE.md/AGENTS.md，放必須遵守的專案約定。 - 常駐層：
MEMORY.md/USER.md，放高密度的身份、偏好與不變量。 - 歷史層：session search、daily notes、topic files，放大量事實、證據與過程。
- 進化層：dreaming、reflection、skills，把歷史經驗轉成未來行動的預設能力。
他強調成熟的 agent memory 是這四層的組合，沒有單一檔案或單一向量庫能獨力撐起，「就像你不能指望只用一種資料結構管理作業系統的全部狀態」。
作者推介的 EverOS（含利益揭露）
利益揭露：EverOS 由作者所屬團隊 EverMind-AI 開發。原文末段直接推介此 repo，因此這篇文章在綜述之外，也帶有為自家產品定調的立場。以下先轉述作者主張，再標示可佐證的部分。
作者主張 EverOS 把 memory 設計成 developer-facing runtime——開發者能直接讀寫、除錯、版本化，而不是隔著 API 猜一個黑盒召回層存了什麼。他列的設計與前述分層對照：Markdown as source of truth（記憶落盤為可讀、可 grep、可 Git 版本化的檔案）、SQLite + LanceDB（Markdown 是真源、SQLite 管狀態、LanceDB 管向量/BM25/scalar filters）、dual-track memory（user 與 agent 記憶分開）、multimodal ingestion、self-evolution（真實 cases 沉澱為 skills）、orthogonal retrieval（按 user/agent/app/project/session 維度檢索）。他的核心論證是：若 memory 只在遠端黑盒，開發者永遠不知道 agent 記住了什麼、為什麼召回這條、何時該刪、哪些已過期；若 memory 是 Markdown，你至少能打開它、讀它、diff 它、改它、放進 Git、交給另一個 agent。他自己也說「這不是最終答案，但是目前最好的工程起點」。
可獨立佐證的部分：EverOS 確為 GitHub 上 EverMind-AI/EverOS 的開源專案，README 自述為「local-first、Markdown-native、user-owned、self-evolving」的可攜記憶層，採 Markdown + SQLite + LanceDB 三件式儲存、無需外部服務、支援 BM25/向量/scalar 混合檢索，並宣稱相容 Claude Code、Codex、OpenClaw、Hermes 與 MCP。這些是 repo 與官網可見的事實；而「是不是目前最好的工程起點」則是作者的價值判斷，並非中立結論。
業界對照：EverOS 不是唯一路線
把 EverOS 放回更大的記憶層生態，至少有三條主流路線值得對照：
- mem0：把記憶當「服務」——你用它的 SDK 包住自己的 LLM 呼叫，它從對話抽取事實、存進向量庫、在未來 prompt 注入相關記憶。記憶治理在 agent 迴圈之外，是一組 CRUD API。適合架構未定、驗證期先上手。
- Letta（MemGPT 演化而來）：是一個 agent runtime，把記憶治理放進 agent 迴圈之內——agent 自己推理該記什麼、該換頁什麼、該歸檔什麼，走的是「context 像虛擬記憶」的 OS 式路線。適合 agent pattern 已驗證、長程記憶價值明確時。
- EverOS：與上述黑盒/服務化路線不同，強調 Markdown 為真源 + 本地檔案系統 + 可 Git 化，把長期記憶從遠端黑盒拉回可讀可 diff 的檔案。
這三者的根本分歧在於：記憶該是 agent 自己推理的對象（Letta），還是 agent 呼叫的外部服務（mem0），還是開發者直接讀寫的檔案（EverOS）。沒有絕對優劣，取決於團隊要的是召回品質、可控性，還是可審計性。作者顯然押在「可審計的本地檔案」這一邊，這是立場，也是 EverOS 的賣點。
延伸
- 為什麼作者反覆強調「別把 memory 簡化成向量庫存對話」→ 客觀檢視：作者主張 vs 業界共識
- 全景與閱讀路徑 → AI memory 專欄首頁