转：又是 agent memory

aidj

📌 最近 Agent Memory 的討論很熱，光 GitHub 上就有 12 個開源專案在解同一道題。框架越開越複雜：向量資料庫、知識圖譜、混合檢索、時序推理⋯新手很容易以為「做記憶系統就是上向量資料庫」。

但小編這幾週讀了不少資料後，越來越覺得：大多數做 agent 的人，其實根本不需要向量檢索。

理由很簡單 — 目前最成熟、用戶最多的幾個記憶產品 (ChatGPT 的記憶功能、Claude Code 的記憶設計、Claude API 的 Memory 功能) 都沒有用向量檢索。

——

🧠 先建立框架：記憶到底是什麼？

▸ 記憶不是 LLM 內建的能力，是工程上刻意設計進去的
▸ 最高層次分類：上下文內 (短期) vs 上下文外 (長期)
▸ CoALA 的四種記憶 (Working/Semantic/Episodic/Procedural) 適合通用框架，專門場景未必合用
▸ 四個核心操作：ADD、UPDATE、DELETE、NOOP
▸ Hot path (即時) vs Background (背景) 兩種更新時機
▸ 記憶設計是場景導向，沒有萬用解
▸ 三大挑戰：相關性、記憶膨脹、需要遺忘

——

🤖 ChatGPT 的記憶系統，沒有 RAG

逆向工程顯示 ChatGPT 的上下文就四層：

▸ Session Metadata (環境資訊，session 結束就丟)
▸ User Memory (長期事實，~33 條)
▸ Recent Conversations Summary (~15 個對話輕摘要)
▸ Current Session Messages (滑動視窗)

沒有向量資料庫、沒有 RAG、沒有跨歷史對話的向量檢索。新訊息進來不去搜尋過去訊息，純粹靠固定注入。

——

📁 Claude Code 的記憶：檔案系統 + 索引

▸ 記憶是索引，不是儲存：MEMORY.md 永遠載入但只是指標
▸ 三層設計：索引常駐、主題檔案按需載入、原始紀錄只用 grep
▸ 嚴格寫入紀律：先寫檔案、再更新索引
▸ 背景做「記憶重寫」：合併、去重、移除矛盾、積極修剪
▸ 可推導的東西不存 (程式碼結構、log、PR 歷史)

——

🔧 Claude API 的 Memory Tool，也是檔案系統

Memory Tool 就是一個檔案系統，agent 透過 view/create/str_replace 等指令直接讀寫 /memories 目錄。沒有向量檢索、沒有相似度搜尋。Cookbook 三種範本 (SimpleMemory、CompactifyMemory、FileBasedMemory) 也都跟向量無關。

——

✈️ OpenAI cookbook 也選狀態式記憶

旅遊管家 agent 範例明確選擇狀態式記憶 (state-based) 而非檢索式。整個架構就是一個 TravelState 資料類別：

▸ profile (從 CRM 帶入的結構化資料)
▸ global_memory.notes (長期偏好)
▸ session_memory.notes (一次性筆記)
▸ trip_history (最近旅行紀錄)

整個系統就是 JSON + Python list，連 SQLite 都沒用。

——

🏆 Mastra 的 Observational Memory：SOTA 不靠向量

LongMemEval 拿到 94.87% (GPT-5-mini)，目前可驗證的最高分。它的開頭一句話：

「沒有向量資料庫、沒有圖資料庫、沒有壓縮機制。只有兩個背景 agent 跟一個簡單的想法：觀察重要的東西，讓其餘的褪去。」

對話 30k tokens 觸發一次觀察，最多壓到 5-40 倍。這就是 SOTA 的做法，沒有任何向量檢索。

——

⚙️ 真正難的不是檢索，是「治理」

▸ 寫入：該記不該記？寫髒比讀錯更致命
▸ 整理：合併去重、衝突調解、版本替換、衰減歸檔
▸ 讀取：優先順序規則 (用戶當下訊息 > session 記憶 > 全域記憶)
▸ 遺忘：不會忘的系統會被舊版本困住

LangChain 的 Agent Builder 團隊有一個人全職在做記憶相關的 prompt 設計 — 記憶行為的問題幾乎都是改 prompt 解決的，不是改檢索演算法。

——

💡 Memory as Reasoning：很有啟發的觀點

Plastic Labs 的核心主張：不要把記憶看成「資料儲存問題」，要看成「推理與脈絡建模問題」。

▸ 不要只存「事實」，要存「可追溯的推論」
▸ 寫入記憶不該只是抽取，而應該是推理步驟
▸ 召回不該只是相似度搜尋，而是「針對當前任務選擇可用的推論」
▸ 意外與矛盾要觸發記憶調解，不直接覆蓋

精神：記憶不是「把過去塞回上下文」，而是「從過去推理出這次該怎麼做」。

——

🎯 那什麼時候需要向量檢索？

▸ 真的要做通用記憶框架 (mem0、Letta 那類基礎設施)
▸ 跨用戶大規模知識共享 (企業多租戶 agent)
▸ 記憶量真的爆掉 (萬條等級的長期客服)

但大多數人在做的是專用 agent — 寫週報、做 PR review、處理客服單。這類 agent 的記憶量永遠不會大到需要向量檢索。

——

📝 小結

ChatGPT、Claude Code、Claude API、OpenAI cookbook、Mastra 全都不用向量檢索。一旦場景明確，「結構化的小型知識 + 檔案系統 + 適當的注入策略」就足夠了。

但「不需要向量」不等於「不需要設計」。真正要花心力的是：

▸ 我的 agent 要記住什麼？
▸ 什麼算「持久」值得長期保留，什麼是「一次性」？
▸ 怎麼合併、整理、讓舊記憶退場？(這比寫入更難)
▸ 注入策略是什麼？優先順序規則怎麼設？
▸ 更新是 hot path 還是 background？

真正難的從來不是容量，而是判斷：留下什麼、刪掉什麼、相信什麼，又允許什麼繼續影響現在。

更多完整版請見 Blog 文章 (相關文章連結都放在留言)