2026 年的 agent memory 生態已經分化成六條互不相容的技術路線：自我編輯的 memory block（Letta）、LLM 抽取更新管線（Mem0）、雙時間軸知識圖（Zep/Graphiti）、ECL 圖譜管線（Cognee）、框架內建的分型記憶儲存（LangMem/LangGraph），以及以 Markdown 檔案為真源的檔案原生記憶（OpenClaw、Hermes、Claude 的 memory 目錄）。它們對「記憶是什麼」的答案不同，因此不能互相替換，也不能靠比較分數選型。
這個專欄的目的是可重新套用：讀完之後，你應該能把一套記憶架構搬到一個新的 AI 專案上，而且知道每個設計決策換掉會付什麼代價。因此重心不在框架導覽，而在 從六個框架抽出的共通模式與參考架構，以及 可以直接照抄的介面與資料結構草案。框架逐一拆解的部分，每一篇都以「可抽取的模式」收尾——那才是搬得走的東西。
與既有 AI memory 專欄的關係
站內已有 AI memory（Agent Memory 架構），它以 @wquguru 的〈Agent Memory 架构全景〉為一手來源，處理的是分層概念與治理原則：規則記憶、常駐畫像、證據鏈、反思與技能沉澱，以及那篇文章的立場檢視。
這個專欄是它的續篇，分工明確：
- 舊專欄回答「記憶該分成哪幾層、為什麼」——概念框架與治理原則，以及對單一作者主張的客觀檢視。
- 這個專欄回答「2026 年有哪些具體框架、各自怎麼實作、我要在新專案裡怎麼組一套」——機制拆解、橫向比較、可複用藍圖、介面草案、選型決策樹。
兩者刻意不重複。舊專欄已完整處理的長上下文 vs RAG 分工、規則檔（CLAUDE.md/AGENTS.md）的定位、EverOS 的設計與利益揭露，這裡只在需要對照時引用，不再展開。如果你還沒讀過舊專欄的 長上下文、RAG 與記憶的分工，建議先讀那一篇——它解釋了為什麼 context window 變大並不會讓這整個問題消失。
三個能力階段
一、建立共同語彙
不同框架用同一個詞指不同的東西（Letta 的 archival memory 與 Mem0 的 long-term memory 不是同一個概念）。沒有統一詞彙，比較就沒有意義。
二、拆解各框架的實際機制
每一篇的結構相同：核心機制 → 儲存後端 → 寫入策略 → 召回策略 → 優缺點 → 適合場景 → 可抽取的模式。
- Letta（MemGPT）：memory block、self-editing 與 sleep-time compute
- Mem0：extract-update 管線與 ADD／UPDATE／DELETE／NOOP
- Zep／Graphiti：雙時間軸知識圖與事實失效
- Cognee：ECL 管線、ontology 與圖＋向量混合檢索
- LangMem／LangGraph：checkpointer、Store 與 hot path vs background
- Claude 的 memory tool 與 context engineering、ChatGPT 的 saved memories 與 Dreaming
- 檔案原生路線：OpenClaw 與 Hermes Agent
三、組出自己的架構
- 橫向比較：儲存、寫入時機、召回方式、遺忘、成本、可觀測性
- 可複用架構藍圖：決策樹、參考架構與五條管線
- 介面與 schema 草案：語言中立定義 ＋ TypeScript 具體實作
- 評測與可觀測性：LoCoMo／LongMemEval 的用處與極限，以及自建 eval
- 實作陷阱與解法：記憶污染、召回不準、無限膨脹、PII、多 agent 共享、一致性
- 選型指南：依專案類型給建議
- 客觀檢視：主張 vs 可佐證、待解問題與延伸資源
「我想在新專案做到…」索引
| 我想達成的目標 | 去哪一篇 |
|---|---|
| 統一團隊對「記憶」的用詞 | 記憶分類學 |
| 決定要不要自己做記憶層 | 選型指南、決策樹 |
| 從零設計一套記憶架構 | 可複用藍圖 |
| 拿到可以直接照抄的介面定義 | 介面與 schema 草案 |
| 設計寫入管線（該記什麼、怎麼去重） | 寫入管線、Mem0 的四種操作 |
| 設計召回管線（怎麼選要注入什麼） | 召回管線 |
| 處理「舊事實被新事實取代」 | 雙時間軸與事實失效 |
| 讓記憶不要無限膨脹 | 壓縮與遺忘、無限膨脹 |
| 讓 agent 自己決定記什麼 | self-editing、periodic nudge |
| 讓多個 agent 共用記憶 | block 共享、多 agent 共享 |
| 做多跳推理（跨事實串接） | 時序知識圖、Cognee |
| 讓記憶可被人類讀、可 diff、可進 Git | 檔案原生路線 |
| 控制記憶的 token 成本 | 成本欄、context engineering |
| 建立記憶品質的量測 | 評測與可觀測性 |
| 防記憶投毒與 PII 洩漏 | 陷阱與解法 |
| 從一個框架搬到另一個 | 介面草案（抽象層） |
| 判斷 RAG 夠不夠、需不需要 memory | 分類學、舊專欄：長上下文、RAG 與記憶的分工 |
「我卡在…」問題索引
| 我遇到的問題 | 去哪一篇 |
|---|---|
| 記憶越存越多，召回品質反而下降 | 無限膨脹與召回不準 |
| agent 記住了錯的事，而且改不掉 | 記憶污染、事實失效 |
| 同一件事有新舊兩個版本，agent 用了舊的 | 雙時間軸 |
| 記憶注入吃掉太多 token，成本失控 | 成本、預算分配 |
| 不知道 agent 到底記住了什麼 | 可觀測性、檔案原生 |
| benchmark 分數很高但實際用起來很差 | benchmark 的極限 |
| 選了一個框架，之後想換但綁太深 | 抽象層設計 |
| 多個 agent 各記一套，彼此矛盾 | 一致性 |
| 使用者要求刪除自己的資料，但不知道存在哪 | PII 與可刪除性 |
怎麼用這個專欄
要在新專案做技術選型：01 → 09 → 14 → 10。先建立詞彙，直接看比較表與選型建議，再回到藍圖確認細節。不需要讀完六篇框架拆解——選定之後再讀對應的那一篇。
要自己實作記憶層：01 → 10 → 11 → 13 → 12。藍圖給結構、介面草案給程式碼起點、陷阱篇給防呆、評測篇給驗收標準。框架拆解在這條路上的用途是抄設計，不是抄相依。
已經有記憶層但效果不好：13 → 12 → 09。先用陷阱篇對照症狀，再建立量測，最後才考慮換框架。換框架很少是第一步的正確答案。
要理解概念全貌：先去舊專欄 AI memory（Agent Memory 架構），那裡的分層框架比這裡完整。
這個領域移動得很快。框架的 API 會變、benchmark 分數會被刷掉、預設值會調整；但記憶層次、寫入管線的四個階段、雙時間軸這些結構性的東西不會。 這個專欄刻意把重量放在後者，前者一律標明版本與日期。
與其他專欄的連結
- AI memory（Agent Memory 架構） — 前導專欄，概念分層與治理原則。
- AI Agentic SaaS — 怎樣實際用 AI 建造服務 — orchestration、RAG、結構化輸出可靠性的工程實作；記憶層是它的一個子系統，兩邊的可靠性紀律相通。
- Engineering AI Coding Methodology — 記憶架構的取捨本質上是介面設計問題，「規格先行、小步可驗證」直接適用。
- Design Pattern 高級詳解 — 本專欄的「可抽取模式」與 Pattern Language 的作法同構：從多個具體實作中抽出可命名、可重用的解法。
- Problem Framing ＋ Spec-Driven Development — 「這個專案真的需要記憶嗎、需要哪一種」是典型的問題框定工作，先框定再選型。
- Thoughtworks 2026：AI 工作流與方法論 — Context Engineering 在資深工程視角下的定位。
🔍 待解問題 / 持續追蹤
- 記憶層的可攜性幾乎不存在。 六個框架的資料模型互不相容，遷移基本上等於重跑一次寫入管線。有沒有可能出現一個中立的交換格式？目前沒有任何跡象。
- benchmark 與實用性的落差被公開量化了，但沒有被解決。 在 LoCoMo 上接近滿分的方案，在需要「用記憶做決策」的評測上掉到 40–60%。這個落差的成因是 benchmark 只測被動召回，還是這些方案真的只做得到被動召回？
- 「該記什麼」目前沒有理論。 所有框架都用一個 LLM prompt 判斷重要性（Mem0 的 extraction、Hermes 的 periodic nudge、Letta 的 sleep-time agent）。這是把問題丟給模型，不是解決它。rate-distortion 視角的研究剛出現，還沒有可落地的判準。
- 遺忘幾乎沒有人認真做。 多數框架的「遺忘」是覆寫或標記失效，不是真的移除。長跑數年的 agent 的儲存成長曲線與召回品質衰減曲線，沒有公開資料。
- 多 agent 共享記憶的一致性模型是空白的。 分散式系統有成熟的一致性層級定義，agent memory 沒有對應的討論；Letta 的 block 共享是最接近的實作，但它沒有處理併發寫入的語意。
- 記憶投毒的防禦目前都在讀寫兩端做過濾，沒有處理「合法來源寫入了語意上有害的內容」這個核心情況。OWASP 在 2026 年把它列入 Agentic AI Top 10（ASI06），這代表問題被承認，不代表被解決。
- 成本結構不透明。 幾乎所有框架都在寫入路徑上呼叫 LLM（抽取、判斷、圖譜化），這使記憶的成本與對話量成正比而非與召回量成正比。這個成本在多數比較文章中沒有被量化。
🕒 更新紀錄
- 2026-09-04 — 專欄建立。hub ＋ 15 篇原子筆記，分「共同語彙／框架拆解／組出自己的架構」三階段。涵蓋 Letta(MemGPT)、Mem0、Zep/Graphiti、Cognee、LangMem/LangGraph、Claude memory tool 與 context engineering、ChatGPT saved memories/Dreaming、OpenClaw、Hermes Agent 共九個實體。核心產出為 可複用架構藍圖 與 介面／schema 草案。定位為 既有 AI memory 專欄 的續篇，概念分層不重複展開。全程區分官方文件事實、論文結果、廠商自我宣稱與我的設計主張，分級表見 主張 vs 可佐證。