2026 AI Agent Memory Wars：三大流派的技術對決

你的 AI Agent 記不住你昨天說過什麼。

這不是 bug，是結構性缺陷。LLM 天生是 stateless 的——每次對話都是一張白紙。Context window 就是它的全部記憶，關掉視窗就什麼都沒了。

2025 年，大家的解法是 RAG：把對話歷史塞進 Vector DB，需要時撈出來。但 RAG 的問題是——你怎麼知道該撈什麼？

2026 年，三個截然不同的答案同時出現了。

為什麼「記憶」突然成了兵家必爭之地

如果你有在用 AI coding agent，你一定經歷過這種場景：

週一你跟 AI 說「我們的專案用 Kotlin，遵循 Clean Architecture，Dispatcher 要用 DI 注入」。AI 表現完美。

週二你開新 session，它又開始寫 Dispatchers.IO。你再解釋一次。

週三，同樣的事情再來一遍。

你的 AI 是那個每天早上都要重新自我介紹的同事。

這個問題在 2025 年被視為「可以忍受的不便」。但到了 2026 年，當 Agent 開始承擔更複雜的任務——跨 session 的 debugging、長期專案維護、多人協作——「記不住」就從不便變成了致命傷。

於是，三個團隊各自給出了截然不同的答案：

這篇文章會拆開每個流派的設計哲學、技術架構、和 trade-off——不只是「是什麼」，更重要的是「為什麼這樣設計」，以及「什麼時候該用哪個」。

流派一：Graph-based — 把記憶變成知識圖譜

設計哲學

Graph-based 的核心信念是：記憶不是一堆孤立的事實，而是有結構的知識網路。

「使用者喜歡 Kotlin」是一個事實。但「使用者喜歡 Kotlin，在某個專案中使用 Clean Architecture，而且要求 Dispatcher 必須用 DI 注入」——這三個事實之間的關係才是真正有價值的記憶。

Vector DB 能存事實，但存不了關係。用「Kotlin」去搜，可能找到第一個，但不會自動帶出後面兩個。Graph DB 可以——因為它把 Entity 存成 Node，Relation 存成 Edge，一次 traversal 就能撈出整個 context。

代表一：Mem0 — 兩階段提取 Pipeline

Mem0 是這個流派的先行者，2025 年拿到 $24M Series A，並成為 AWS Agent SDK 的獨家記憶供應商。

架構：

對話 → [LLM #1: Extraction] → 提取 entities + relations
                                      ↓
                              [LLM #2: Update] → 決定新增/更新/刪除
                                      ↓
                              Vector DB + Graph DB (Neo4j)

每次對話結束後，Mem0 用兩次 LLM call 處理記憶：第一次提取資訊，第二次決定如何更新。這個 pipeline 的好處是結構化程度高——你最後得到的是乾淨的知識圖譜，不是一坨壓縮過的文字。

Mem0ᵍ（Graph Memory） 是它的進階版，支援 Neo4j、Memgraph 等多種 graph backend，把 Entity 存為 Node、Relation 存為 Edge，搭配 vector embedding 做混合搜尋。

數據（來自 arXiv:2504.19413）：

• 比 OpenAI Memory 準確度提升 26%（LOCOMO benchmark）
• P95 延遲降低 91%
• Token 成本節省 90%

代表二：Zep — 時間軸知識圖譜

Zep 用了一個更精巧的設計：bi-temporal knowledge graph。

普通的知識圖譜是靜態的——「使用者喜歡 Python」就是一個永恆的事實。但現實世界的事實會變化。三個月前使用者喜歡 Python，上個月轉向 Rust，這週又在考慮 Zig。

Zep 的 Graphiti 引擎為每個 edge 記錄兩條時間軸：

當新事實與舊事實矛盾時（「使用者現在喜歡 Rust」），Zep 不會刪除舊 edge，而是 invalidate 它——設定 t_invalid 標記。這意味著你可以做 point-in-time query：「三個月前使用者的偏好是什麼？」

Retrieval 的設計也值得看：

Query → [Cosine 語義搜尋] ─┐
      → [BM25 關鍵字搜尋]  ├→ 混合排序 → LLM Reranking → Context
      → [BFS 圖遍歷]      ─┘

根據 Zep 官方描述，Graphiti 支援結合「time, semantic, full-text, and graph algorithm」的混合查詢。三種搜尋策略並行，最後用 LLM reranking 組裝最終 context。

數據（來自 arXiv:2501.13956）：

• LongMemEval 準確度提升 18.5%（GPT-4o）
• 中位延遲 2.58s vs 全文 baseline 28.9s（降低 90%）
• Context 只用 baseline 的 1.4% token（1.6k vs 115k）

Graph-based 的 Trade-off

優勢：

• 結構化程度最高——知識有明確的 entity/relation 結構
• 支援複雜查詢（多跳推理、時間推理）
• 適合多使用者共享記憶

代價：

• Ingestion 需要 LLM call——每次對話都要跑 extraction pipeline，有成本和延遲
• Graph 維護複雜——entity deduplication、edge invalidation 都需要精心設計
• 過度結構化的風險——不是所有記憶都適合被壓成 entity-relation 格式

流派二：OS-inspired — 讓 Agent 自己管記憶

設計哲學

Letta（前 MemGPT）的核心信念是：別幫 Agent 管理記憶，讓它自己管。

這個想法直接來自作業系統設計。你的 OS 不需要你手動決定哪些資料放 RAM、哪些放硬碟——它有 virtual memory 機制自動管理。Letta 把同樣的思路套到 LLM 上：

三層記憶階層

Tier 1：Core Memory（永遠在 context 中）

Core memory 是一組結構化的文字區塊，直接嵌入 system prompt，Agent 每次推理都能看到。預設有兩個 block：

• persona：Agent 的身份、行為模式
• human：使用者的偏好、歷史、context

關鍵設計：Agent 可以自己修改這些 block。 Letta 提供 core_memory_append 和 core_memory_replace 工具，Agent 決定什麼時候更新、更新什麼。

# Agent 自主決定記住這個偏好
core_memory_replace(
    block="human",
    old="Uses Python for most projects",
    new="Recently switched from Python to Rust for systems work"
)

Tier 2：Archival Memory（語義搜尋）

放不進 core memory 的長期知識——過去的對話摘要、學到的 pattern、專案歷史。Agent 透過 archival_memory_search 主動搜尋。

Tier 3：Recall Memory（對話歷史）

完整的事件紀錄，包括所有 message、tool call、reasoning trace。超過容量時自動做 recursive summarization。

Letta Code：記憶驅動的 Coding Agent

2026 年 2 月，Letta 推出了 Letta Code——一個基於記憶架構的 coding agent，在 Terminal-Bench 上拿到 model-agnostic 開源框架第一名。

它的祕密武器是 Skill Library：Agent 把學到的 pattern 存成 .md 檔案（API migration 步驟、dashboard 建立流程、常見 bug 修法），下次遇到類似問題時自動調用。

更值得注意的是 Context Repositories——用 Git 來做記憶的版本控制。Agent 的記憶可以被 commit、branch、甚至 rollback。

OS-inspired 的 Trade-off

優勢：

• 自主性最高——Agent 控制自己的記憶生命週期
• 可解釋性好——你可以直接看到 Agent 的 core memory 內容，理解它「記住了什麼」
• 持續學習——Agent 隨時間累積經驗，越用越好

代價：

• Context window 固定成本高——system prompt + tool definitions + core memory，在對話開始前就吃掉 ~2,000 tokens
• Self-editing 有風險——Agent 可能誤刪重要記憶，或寫入錯誤資訊
• Page Fault 代價高昂——就像真實的 OS 一樣，當 Agent 發現需要的記憶不在 Core Memory 中，就必須去 Archival Memory 搜尋（一次 RAG + 一次 LLM inference）。這個「page fault」的延遲在講求 real-time 回應的場景是致命傷
• 有趣的自我矛盾——Letta 自己的研究發現，在 LoCoMo benchmark 上，用基本檔案系統操作的 Agent（74.0%）打敗了用 Mem0 graph memory 的 Agent（68.5%）

最後一點值得深思。Letta 團隊的結論是：「現在的 Agent 非常擅長使用工具，尤其是訓練資料中常見的工具（如 filesystem 操作）」。這暗示了一個可能性——最好的記憶系統也許不需要特殊架構，只需要讓 Agent 用它最熟悉的工具。

流派三：Observational — 全部壓縮，塞進 Context

設計哲學

Mastra 的 Observational Memory 是三個流派中最激進的：不做 retrieval，不用外部資料庫，把所有記憶壓縮成純文字塞進 context window。

這聽起來很蠢。Context window 有限，你怎麼塞得下所有東西？

答案是：壓縮比你想像的有效。

雙 Agent 壓縮架構

Mastra 的 context window 分成兩個區塊：

Context Window
├─ Observations（壓縮後的記憶）        ← 穩定，可被 cache
│    結構化文字筆記，帶日期 + 優先級
│    超過 40k tokens → Reflector 清理
│
├─ Raw Messages（原始對話）            ← Append-only
│    未壓縮的最近對話
│    超過 30k tokens → Observer 壓縮

兩個背景 Agent 負責記憶管理：

Observer（觀察者）：當原始對話超過 30k tokens，Observer 把對話壓縮成結構化的觀察筆記，帶有日期和優先級標記：

🔴 2026-03-02 使用者的 Android 專案使用 Clean Architecture
  - Dispatcher 必須用 DI 注入（lint rule 強制）
  - 不使用 Dispatchers.IO，改用 @Dispatcher annotation

🟡 2026-03-01 使用者正在寫 AI Agent Memory 系列文章
  - 目標讀者：L5+ 工程師
  - 要求技術深度 + 實戰 trade-off

Reflector（反思者）：當觀察筆記超過 40k tokens，Reflector 對筆記進行「垃圾回收」——合併重複項、移除過時資訊、保留高優先級記憶。

為什麼這能打敗 RAG？

傳統 RAG：

Query → Embedding → Vector Search → Reranking → Context Assembly → LLM

每一步都有資訊損失。Embedding 不精確、搜尋結果不完整、reranking 可能漏掉關鍵 context。

Observational Memory：

Messages → Observer 壓縮 → 直接在 Context 中 → LLM

沒有 retrieval gap。 所有相關記憶永遠在 context 中——不存在「該搜什麼」的問題。

而且更便宜。 因為 Observation block 很穩定（只在壓縮時才改變），它可以被 prompt caching 完美利用。根據 Mastra 的說法，多數 model provider 對 cache hit 提供 4-10x 的 token 費用折扣。

壓縮效率

舉個例子來感受一下：

原始對話（~5,000 tokens）：
User: "SF 天氣怎樣？"
Tool: {"location": "San Francisco", "temp": 65, "conditions": "sunny" ...1k JSON}
Agent: "SF 現在 65°F，晴天"
User: "明天呢？"
Tool: {"location": "San Francisco", "temp": 68, ...1k JSON}
Agent: "明天 68°F，部分多雲"

壓縮後觀察（~150 tokens）：
🟡 2026-03-02 使用者查詢 SF 天氣
  - 今天：65°F 晴天
  - 明天：68°F 部分多雲

壓縮比：33x。 Tool call 越多，壓縮效益越大。

數據

LongMemEval 94.87%（GPT-5-mini）——目前的 SOTA。作為對比，同一個 benchmark 上 GPT-4o 搭配 Mastra 拿到 84.23%，而傳統 RAG 搭配 GPT-4o 只有 80.05%。

更值得注意的是 scaling 特性：從 GPT-4o（84.23%）到 GPT-5-mini（94.87%），Mastra 的分數提升了超過 10 個百分點。模型越強，壓縮記憶的效益越大。

Observational 的 Trade-off

優勢：

• 零基礎設施——不需要 Vector DB、Graph DB、任何外部系統
• Deterministic——同樣的觀察筆記，每次產生同樣的結果（不像 retrieval 有隨機性）
• Debug 友好——直接讀 Observation block 就知道 Agent「記住了什麼」
• 成本最低——prompt caching（多數 provider 提供 4-10x 折扣）+ 無 retrieval 開銷

代價：

• 同步阻塞——Observer 觸發時對話會暫停，直到壓縮完成（async 模式已在開發中）
• 壓縮是有損的——Observer 可能把十次失敗的 API call 壓縮成「嘗試呼叫 API 失敗」。日常對話沒問題，但如果你的 Coding Agent 正在 debug，那十次失敗的 error trace 才是破案關鍵——壓掉就真的「失憶」了
• 不適合大型知識庫——只能壓縮對話歷史，不能取代 document corpus 的 RAG
• 單一對話限定——沒有跨使用者、跨 Agent 的共享記憶機制
• Multi-session 天花板——LongMemEval 的 multi-session 子項只有 87.2%，是明顯的弱點

三大流派正面對決

Benchmark 比較

† Zep 重新跑 LOCOMO 並指出 Mem0 原始評測有配置問題（user model 錯誤、timestamp 處理不當） ‡ Letta 用基本 filesystem 操作的結果，非 Mem0 integration

重要 caveat：

這些 benchmark 不能直接橫向比較——每家測的 task 類型、模型、配置都不同。而且 benchmark 本身也有爭議：

• LOCOMO 的問題：對話平均只有 16k-26k tokens，在現代 LLM 的 context window 內就能處理。Zep 指出，把完整對話直接塞進 context（不用任何 memory 系統）就能拿到 ~73%——比 Mem0 的 68.5% 還高。這讓人質疑 LOCOMO 是否真的在測「記憶」能力。
• LongMemEval 是目前更嚴格的 benchmark（平均 115k tokens），但只有 Zep 和 Mastra 跑過。

這裡有一個值得停下來想的洞察：在 Context Window 已經飆升到 1M 甚至 2M 的 2026 年，很多時候「暴力的 Context 覆蓋」比「優雅的檢索」更有效。 這也解釋了為什麼 Mastra 的 Observational approach——把所有東西壓縮後直接塞進 context——能在 LongMemEval 上拿到 SOTA。

趨勢仍然明確：Observational 在長對話記憶上領先，Graph-based 在結構化知識和跨 session 上更有優勢。

架構哲學比較

成本比較（50 輪對話估算）

選型決策框架

聊了這麼多架構，回到最實際的問題：你該用哪個？

場景一：長期個人助理（記住使用者偏好、歷史）

推薦：Mem0 或 Letta

需要跨 session 記憶、使用者 profile 管理。Mem0 的結構化知識圖譜適合「記住事實」，Letta 的 self-editing 適合「記住行為模式」。

場景二：Coding Agent（記住專案 context、coding style）

推薦：Letta Code 或 Observational

Letta Code 的 Skill Library 正是為這個場景設計的。如果不需要跨 session，Mastra 的零基礎設施方案更簡單。

場景三：客服機器人（大量使用者、需要審計）

推薦：Zep

Temporal knowledge graph 的 bi-temporal 模型天生支援審計追蹤。能回答「使用者三個月前說了什麼」這類 compliance 問題。

場景四：高吞吐量、成本敏感

推薦：Observational

零基礎設施 + prompt caching = 最低成本。但要接受 multi-session 的限制。

場景五：企業級知識管理

推薦：Mem0（managed）或 Zep（managed）

需要 SOC 2、HIPAA compliance、multi-tenant 支援。兩者都有 managed service。

Quick Decision Tree

你的 Agent 需要跨 session 記憶嗎？
├─ 不需要 → Observational（最簡單、最便宜）
└─ 需要
   ├─ 需要時間推理（事實會變化）？
   │  └─ 是 → Zep（temporal KG）
   └─ 不需要
      ├─ Agent 需要自主學習嗎？
      │  └─ 是 → Letta（self-editing memory）
      └─ 不需要
         └─ Mem0（結構化 extraction，最快上線）

結語：沒有銀彈，但不再是無解

研究完這三個流派之後，老實說，沒有哪一個讓我覺得「就是它了」：

• Graph-based 結構漂亮，但每次對話都要跑 extraction pipeline，成本擺在那
• OS-inspired 理念很酷，但 Agent 的 self-management 能力還沒到位——連 Letta 自己都發現 filesystem 操作打敗了 graph memory
• Observational 數據最漂亮，但一旦要跨 session 就露出短板

最後大概會走向某種 hybrid——session 內用 Observational 壓縮，跨 session 用 Graph 持久化。但那是以後的事。

現在要做的很簡單：看你的場景，從上面的 decision tree 選一個，先上線，再迭代。 完美方案不存在，但等下去只會讓你的 Agent 繼續失憶。

如果你只記得一件事：

RAG 不是唯一的答案了。2026 年，AI Agent 的記憶問題有了三個認真的解法，各自在特定場景下碾壓純 RAG。差別只在你願不願意去試。

下一篇會深入 Mem0 的架構——extraction pipeline 怎麼跑、Graph Memory 的實作細節、以及論文中 26% accuracy boost 背後的真實方法論。

參考資料

1. Mem0: Memory Layer for AI Agents (arXiv:2504.19413) — Mem0 核心論文，26% accuracy boost 數據來源
2. Zep: A Temporal Knowledge Graph Architecture for Agent Memory (arXiv:2501.13956) — Zep/Graphiti 論文，bi-temporal KG 架構詳解
3. MemGPT: Towards LLMs as Operating Systems (arXiv:2310.08560) — Letta 前身 MemGPT 原始論文
4. Mastra: Observational Memory — Observational Memory 官方 blog
5. Mastra Research: Observational Memory — LongMemEval 94.87% 基準測試詳情
6. Letta Code Announcement — Context Repositories + Terminal-Bench 排名
7. Letta: Benchmarking AI Agent Memory — 「Filesystem 打敗 Graph Memory」的研究
8. Mem0 Series A ($24M) — Mem0 商業化進展 + AWS 合作
9. Zep: State of the Art Agent Memory — Zep 官方 benchmark 分析
10. Zep: Is Mem0 Really SOTA in Agent Memory? — Zep 對 Mem0 benchmark 方法論的質疑

這是「AI Agent 架構實戰」系列文章。上一篇：Cursor 的 $29B 秘密：被刪除的 Shadow Workspace 技術解密。下一篇：Mem0 深度剖析——從 arXiv 論文到 Production 實戰