AI 從 Stateless 到 Stateful，Memory 系統設計整張地圖長這樣——從認知科學引入、到 representation 演進、到 library 落地，整理一條完整的生態系脈絡。
LLM 是 stateless 的——每次 API call 都是全新的。既然 AI / LLM 不會記得任何東西，為什麼我們今天用 ChatGPT、用 Claude，感覺它好像「記得」上次聊過什麼？因為記憶不在 LLM 裡，記憶在外面。Application layer 在每一次 call 時把外部資訊重新塞回去——也就是「inject」這個動作。
而過去兩年，「外面那一層」已經發展成一整片生態。各種 library、各種 representation、各種 retrieval 策略——多到眼花撩亂😵💫。這篇想把這張地圖畫出來。
一、認知科學引入 — 定義 Memory 開始
學界討論 agent memory 的時候，多半從認知心理學引入。1972 年 Tulving 提出 Episodic vs Semantic 的區分，後來慢慢擴展成三類：
- Semantic — 我知道什麼（事實、知識、偏好；我是誰，我喜歡什麼）
- Episodic — 發生過什麼（有時間戳的具體事件；我上週看了一場電影）
- Procedural — 怎麼做（工作流程、SOP；我坐捷運上班）
這個三分法在 2023 年的 CoALA 論文（Princeton）被正式帶進 LLM agent 領域，之後：
- 2023 年 AAAI Fall Symposium 的《Memory Matters》
- 2025 年 8 月的 MemP（procedural memory 的代表作）
- 2025 年 12 月 position paper《Episodic Memory is the Missing Piece》
- 2026 年 2 月的《Anatomy of Agentic Memory》
——這條 timeline 把學界對 agent memory 的理解一步步推到今天。
之前在 Meta《HyperAgents》聊過第四類——Strategic Memory（或叫 Operational Knowledge）——三分法裝不下的「實驗結果 + 因果推論」這種決策知識。Strategic Memory 工程界早就在做了。Martin Fowler 在他的部落格寫過 ADR（Architecture Decision Record）的觀念——記錄做了什麼決策、考慮過哪些替代方案、為什麼選這個。Code comment 也是同類載體。這些都是工程版的 strategic memory，學界沒給它正式分類。
二、另一種視角 — Memory 的存取階層
除了「內容類型」這個視角，還有另一種來自 OS 的視角——Letta（前 MemGPT）團隊提出的：
- Core memory — 永遠在 context 裡，像 RAM
- Archival memory — 存在外部，要 retrieve 才能用，像 disk
- Recall memory — conversation history，最近的對話紀錄；或是需要時提取 / 丟棄
這個視角為什麼重要？因為它直接決定 retrieval 怎麼做：
- Core 不需要 retrieve（永遠都在）
- Archival 才需要 retrieve（外部存儲，要主動去找）
- Recall 是 sliding window（最近的留著、舊的壓縮或丟）
同一筆記憶可以同時用「類型」和「階層」兩個維度描述——例如「user 偏好 dark mode」是 Semantic + Core，「上週討論了 code review framework」是 Episodic + Archival。
三、所有 memory 系統做的，本質都是同一個動作
無論你用 Mem0、Letta、Zep、agentmemory，做的本質動作就一個——把外部資訊 inject 進 context window。差別只在三件事：
- 呈現形式（Representation）
- 消化方式（Synthesis timing）
- 誰主動（Agency）
一個一個來看。
四、Representation — 從 Vector 到 Knowledge Graph
最早期的記憶系統用 vector——把文字轉成向量，靠語意相似度去找相關內容。簡單、好實作、適合「找跟這個問題相關的內容」。但 vector 有個天生侷限——它只能告訴你「A 和 B 語意相似」，沒辦法告訴你「A 怎麼跟 B 相關」。
舉個例子，問「賈伯斯的接班人是哪裡人？」這種問題：
- Vector 能找到「賈伯斯」「庫克」「Apple」這些相關詞，但拼不出答案
- Knowledge Graph 可以直接走「賈伯斯 → 接班人 → 庫克 → 出生於 → Alabama」這條路徑
這種「關係性的查詢」就是 vector 解決不了的問題——也是 KG 開始被引進 memory 系統的原因。
Knowledge Graph 的起源其實要追溯到 2012 年 Google 發表的《Introducing the Knowledge Graph: things, not strings》——那是 KG 這個概念主流化的關鍵時刻。從那之後，各大廠 Service 都做了自己的 KG，到 2020 年代 LLM 興起，KG 跟 LLM 的結合變成熱門研究。
之後 Zep 又再加了一層——Temporal Knowledge Graph，每條 edge 都帶「有效時間」。這樣就能回答「前一版實作我們用什麼？」「上週這個關係還在嗎？」這種時序推理。
到了 2026 又出現 Multi-strategy retrieval——代表作是 Hindsight（vectorize.io, 2026/03），四個策略並行：semantic search、BM25 keyword、entity graph traversal、temporal filtering，最後用 cross-encoder 重排。在 LongMemEval 上拿到 91.4%。Mem0 2026 版本也走類似路線，把 semantic + BM25 + entity 三種訊號融合成單一 score。
（簡單補充：semantic 是 embedding 語意搜尋；BM25 是字串比對；Entity 是記憶做 tagging，搜尋 tag。）
演進路線是：Vector → Knowledge Graph → Temporal KG → Multi-strategy。不同的 representation 對應不同的 retrieval 策略——這也是為什麼 representation 的選擇這麼重要。
五、Synthesis Timing — 什麼時候動用LLM 消化
第二個關鍵差異是——LLM synthesis 發生在什麼時候？
- Retrieval-time synthesis（傳統 RAG） — 每次 query 都讀 raw、現場 LLM 合成答案
- Ingest-time synthesis（2026 主流） — 一次性處理 raw、之後 query 直接打已經處理好的 derived layer
2026 主流的 memory 系統（Mem0、Zep、Cognee、agentmemory）幾乎都走 ingest-time synthesis，RAG 變成 fallback，不是核心。為什麼？因為 bookkeeping cost 比 retrieval cost 低很多倍——每次 retrieval 就要花一次 LLM 整理資訊，讀的次數預期比寫多很多。而且 cross-reference 在 ingest 時就建好的話，之後 query 可以多次受惠。
六、Memory Digestion — 不吃 vs 消化
Inject 是動作，但 memory 不會自動變好，要主動「消化」它。兩種完全不同的動作拆開來看：
- Compaction — 為了不爆 context 而做的壓縮（被動）。代表：Anthropic / OpenClaw auto-compact
- Consolidation — 為了重組知識而做的蒸餾（主動）。代表：A-MEM 的 memory evolution、OpenClaw 的 Dreaming、MemP 的 procedural distillation
兩者本質差很多。如果只是純文本記憶，做 inject 層級的調整就夠了——該丟的丟、該留的留，這是 compaction。但如果要做真正的「forget 機制」、要讓 memory 之間產生新的連結、要從 episodic 慢慢蒸餾成 strategic——就需要 consolidation（也可以真正解決 memory conflict 的問題）。
Compaction 是為了不脹——排掉吃不下的；Consolidation 是為了變聰明——吸收成養分。
七、Agency — 誰主動管理記憶
最後一個差異是「誰主動」？三種設計哲學：
- Transparent — LLM 不知情，application layer 在背後 inject（mem0 風格）
- Agent-aware — Agent 主動 call tool 管理 memory（Letta 風格，memory 操作是 tool）
- Meta-managed — Meta agent 在更高層 orchestrate（MIRIX 風格）
mem0 為什麼能成為最廣泛採用的方案？因為它選了 Transparent——任何 LLM 都能用，不需要 LLM 配合，掛個 browser extension / Claude Code Hook 就能提取記憶、修改記憶。Letta 選 Agent-aware——控制力強，但他幾乎是設計一個 Agent，並不只是讓你外掛記憶，所有記憶操作都被封裝在 agent 裡。根據對於記憶抓手的深度來看，決定管理的層級。
八、Library 落地的三個層級
從前面這幾個維度（representation、synthesis、agency）展開，現在可以看整個 library 生態：
- Developer 層（個人開發、自架、coding agent） → mem0、Cognee、Zep、agentmemory、OpenClaw、LLM Wiki
- Agent Product 層（產品級、multi-tenant） → Letta、mem0 cloud (可搭配 Supabase)、Zep cloud
- Self-improving 層 → MIRIX、HyperAgents、Hindsight、Hermes Agent、OpenClaw
Developer 層的四個我都試過了，給點個人推薦：
- Mem0 — 最簡單，掛 extension / Hook 就能用。如果你只是想讓 Claude Code 記得你的偏好、或產品使用者偏好，Mem0 幾乎是最容易上手。
- Cognee — 想做 local 的話很容易上手。完整本地部署、自動 ontology 生成，私人場景的好選擇。
- Zep — Knowledge Graph 的設計很漂亮，bi-temporal model 對時序推理很有用。我用下來覺得它在「institutional knowledge」這種需要關係性查詢的場景很強。
- agentmemory — 本質上是 Karpathy 的 LLM Wiki 概念的延伸實作。如果你不想搞懂 LLM Wiki 那篇 gist 在做什麼，直接裝 agentmemory 是最快的捷徑（但需要 LLM API key）。
Self-improving 那層的 MIRIX 跟 HyperAgents 還在研究階段，目前 production-ready 的還不多。但這個方向就是——不只是「用 memory」，而是「memory policy 本身可以被學習、被優化——meta cognitive」。
九、怎麼把這張地圖用起來
整個 conceptual map 的意義不是「哪個 library 最好」——而是讓你看到每個選擇背後的差異化：
- 選 Mem0 vs Letta，本質是選 Transparent vs Agent-aware
- 選 vector vs KG，本質是選「語意相似」vs「關係性推理」
- 選 retrieval-time vs ingest-time，本質是選 per-query LLM cost vs per-ingest LLM cost
- 選 self-host vs cloud，本質是選 data sovereignty vs scale
每個 library 都隱含一組 use case 差異，根據這組差異來選擇適合的 library。
What Now?
- 純粹搞懂 AI memory 怎麼運作
- 找個 library 試試看，串 Coding Agent w. Cross Platform
- 評估自架 vs SaaS，搭設 Product 記憶服務
- 為自己的 agentic workflow 設計記憶層
都可以從這張 conceptual map 出發——找到對應的 library，動手裝來試看看哪個最適合你的環境。我自己做的事就是把整個生態系畫成這張地圖，然後跑了幾個工具確認 framework 的個別優勢。
Memory 這塊還在快速演進中——我目前的體感是 2026 是 ingest-time synthesis 變成主流的一年，KG 開始挑戰 vector 的主導地位，self-improving 慢慢從學界走向 production。
Have Fun. 😑
