我的知識庫

AI · 2026-07-15

閱讀時間約 11 分鐘

2026 年,AI 代理記憶(agentic memory)正式從實驗性功能變成一個獨立的架構層,擁有自己的標準化評測(LoCoMo、LongMemEval、BEAM)與完整的生態系統。Mem0 在四月發布的新演算法,把 LoCoMo 準確率推到 92.5 分、LongMemEval 推到 94.4 分,而且平均每次檢索只用約 6,900 個 token,相較於把整段對話塞進 context window 動輒兩萬多 token,效率差距是好幾倍。Red Hat 團隊六月的技術文章直接點名一個公式:代理能力不等於模型權重,而是「模型 + harness + 記憶 + 環境 + 進化」的總和——同一顆中等大小的模型配上好的記憶系統,實測可以打贏參數量更大、但缺乏記憶的模型。這篇來拆解記憶系統實際上怎麼運作、為什麼純向量檢索不夠用,以及目前業界公認還沒解決的難題。

📖 學(核心)

為什麼把對話塞進 context window 不夠用

LLM 推論本質上是無狀態的:每一次輸入產生一次輸出,模型本身不會因為這次對話而改變,也不會記得任何事。這種無狀態性帶來幾個實際問題。第一,計算沒效率——每次都要把整段歷史重新算一次注意力,同樣的資訊被反覆處理。第二,長對話會出現「context rot」與注意力誤差,context 越長,模型抓重點的能力反而下降,KV cache 的運算與記憶體成本也跟著暴增。第三,模型無法從部署經驗中自我改進,除非重新訓練;多個 agent 之間更沒有共享知識、形成群體智慧的機制。RAG、快取、壓縮這類 context engineering 技巧能緩解症狀,但treat 的是表面問題,沒有解決「agent 沒有持久知識庫」這個根本缺口——這正是獨立的記憶層要處理的事。

記憶的三種類型:情節、語意、程序

業界目前把記憶分成三類。情節記憶(episodic memory)記錄「發生過什麼事」,例如使用者上次聊到的專案進度、上一輪對話的結論。語意記憶(semantic memory)記錄「已知的事實」,例如使用者的職稱、偏好的程式語言。程序記憶(procedural memory)則是最容易被忽略但生產環境最需要的一種——記錄「事情該怎麼做」,像是一個 coding agent 該記住團隊的 PR 規範、上線前要跑哪些測試指令、release note 怎麼寫。這不只是單一偏好,而是需要持續套用的流程知識。目前多數框架的情節與語意記憶工具已經成熟,程序記憶的專屬管理工具還在早期階段。

多信號檢索與實體連結:從純向量相似度到融合排序

早期的記憶系統幾乎都用向量相似度做檢索,問題是相似度高不代表順序對、也抓不住「誰跟誰有關係」這種結構性資訊。Mem0 在 2026 年的新架構做了兩個關鍵改動:一是「單次 ADD-only 抽取」,把 agent 自己產生的推論或建議,也當成一等公民存進記憶,跟使用者明講的事實同樣重要,補齊過去只記使用者說的話這個覆蓋率缺口。二是「多信號檢索」——同時跑語意相似度、BM25 關鍵字比對、實體比對三條路徑,再把三個分數融合成一個排序分數,單一訊號的表現都比不上融合後的結果。實體連結(entity linking)取代了外部圖資料庫:寫入記憶時順便抽取實體存進一個平行的實體集合,查詢時比對實體再拉高相關記憶的分數,不用另外維護一個 Neo4j 之類的圖資料庫,但代價是不能再像圖資料庫一樣做任意的關聯式查詢。

背景維護與「作夢」(dreaming):寫入之後還要整理

記憶系統不是寫進去就結束。Red Hat 與 OpenClaw 都提到一種背景流程,業界口語稱作「dreaming」——定期把短期、瑣碎的筆記合併、去重、淘汰過時內容,甚至從舊記憶推導出新的關聯知識。這類維護通常跟對話本身分開執行,避免拖慢即時回應。與此同時,「記憶過時」(staleness)是公認最難的問題之一:一則被高頻檢索的記憶,例如使用者的雇主,只要對方換了工作,這則記憶就從「可信」變成「有自信地講錯」,而且系統很難自動判斷它已經失效。BEAM 評測從 100 萬 token 規模擴大到 1000 萬 token 規模時,分數掉了將近四分之一,說明記憶系統的時間推理能力,在規模拉大之後還有很大進步空間。

🧠 記

  • LoCoMo、LongMemEval、BEAM 是目前記憶系統的標準評測,BEAM 專門測試 100 萬到 1000 萬 token 規模下的表現,無法靠單純擴大 context window 解決
  • Mem0 新演算法在 LoCoMo 拿到 92.5 分、LongMemEval 拿到 94.4 分,平均每次檢索約 6,900 token,遠低於把全文塞入 context 動輒兩萬六千 token 的做法
  • 記憶分三種:情節記憶(發生過什麼)、語意記憶(已知的事實)、程序記憶(該怎麼做,例如團隊的 PR 流程與部署步驟)
  • 檢索不能只靠向量相似度,要融合語意相似度、關鍵字比對(BM25)、實體比對三種訊號的分數
  • 多代理系統需要「歸屬」(actor-aware memory),清楚分辨一則記憶是使用者說的,還是某個 agent 自己推論出來的
  • 記憶過時(staleness)是最棘手的開放問題:高相關性的記憶一旦現實改變(換工作、搬家),系統很難自動判斷它已失效
  • 跨 session 的身分辨識(同一人換裝置、匿名 session)目前還沒有公認的標準解法

✍️ 實踐

  1. 幫正在開發的 agent 專案定義好記憶範圍(scope):user_id、agent_id、session_id、org_id 四層分清楚,不要全部塞進同一個 collection
  2. 挑一個現成記憶層(Mem0 開源自架、OpenMemory MCP 本地優先、或框架內建如 LangGraph / CrewAI 的記憶模組),先跑一次 LoCoMo 或自己專案的小樣本評測,量清楚 token 成本與準確率
  3. 針對程序記憶(專案慣例、coding style、部署步驟)另外建一份可版本控管的記憶檔案,不要跟情節式的對話記憶混在一起
  4. 設計記憶寫回(write-back)流程時,標記清楚這則記憶是「使用者陳述」還是「agent 推論」,避免多代理系統互相污染彼此的記憶
  5. 排一個定期跑的背景整理(consolidation/dreaming)任務:合併重複記憶、淘汰過時事實、標記 staleness 高風險項目
  6. 導入 metadata filtering(例如 {"context": "healthcare"}),讓同一個記憶庫可以依專案或情境做範圍查詢,避免跨場景資料外洩

🔗 延伸學習

💬 問 AI

我正在打造一個{agent 類型,例如:客服機器人 / coding agent / 個人助理}的代理系統,想幫它加上跨 session 的記憶功能。

請幫我:
1. 依照這個使用情境,建議適合的記憶範圍(scope)設計,說明 user_id / agent_id / session_id 該怎麼分層
2. 比較{方案 A,例如:Mem0 開源自架}和{方案 B,例如:OpenMemory MCP}兩種方案的優缺點,包含成本與維運複雜度
3. 列出我該優先儲存哪些「情節記憶」和「程序記憶」,並給出可以直接套用的資料結構範例(JSON 或 schema)
4. 提醒我常見的記憶污染、過時(staleness)風險,並建議對應的定期維護機制

我的技術背景是:{描述,例如:熟悉 Python,主要用 LangGraph 開發}

反向連結