承昨日談代理執行期的安全護欄(runtime guardrails),今天把鏡頭轉向另一個決定代理長期表現的地基:記憶系統(memory system)。護欄管的是「這一步能不能做」,記憶管的則是「代理跨越多次對話、多個任務後,還記不記得你是誰、上次做到哪、你偏好什麼」。前四天講的工具、追蹤、評測、護欄,全都建立在「代理知道自己在幹嘛」這個假設上;而記憶,正是那個假設能不能成立的關鍵。
📖 學
2026 年最大的觀念轉變,是把記憶當成一個獨立的架構元件,而不是塞進 context window 的附屬品。 早期做法是把歷史對話一股腦全丟回模型,靠長 context 硬撐;但這既貴又慢,而且模型在超長脈絡裡「中間段落容易失焦」的老問題並沒有消失。今年業界逐漸收斂到一個共識:記憶要有自己的儲存層、檢索邏輯與寫入策略,和模型的 context window 分開管理。context window 是短期的工作記憶(working memory),記憶系統則負責跨 session 的持久化。
短期記憶與長期記憶的分工，是理解整套架構的第一刀。 短期記憶像人的工作記憶,只存在於當下這段 session,裝著最近幾輪對話、當前任務狀態、剛呼叫過的工具結果。長期記憶則跨越 session 邊界:它把使用者偏好、過往任務軌跡、事實知識寫進資料庫、向量儲存(vector store)或知識圖譜(knowledge graph),讓代理下週、下個月回來時還認得你。少了長期記憶,再聰明的代理每次都是失憶的陌生人。
再往下切,長期記憶又分成三種認知型態,這套分類今年幾乎成了產業通用語。 一是情節記憶(episodic memory),記錄「發生過什麼」——某次對話、某個具體事件的完整軌跡;二是語意記憶(semantic memory),抽取出來的事實與知識,例如「這位使用者是左撇子、住台北、討厭開會」;三是程序記憶(procedural memory),關於「怎麼做」的技能與慣例,例如某個工作流程該按什麼順序執行。這三層對應了幾十年的認知科學研究,也剛好對得上工程實作:情節記憶適合存事件流,語意記憶適合放進向量庫做相似度檢索,程序記憶則常固化成規則或提示模板。
Letta(前身是 MemGPT 研究專案)提供了一個很好懂的心智模型:把 LLM 的記憶當作作業系統的記憶階層在管。 它分三層——core memory 永遠在 context window 裡,像 RAM;recall memory 是可搜尋的對話歷史,像磁碟快取;archival memory 則是需要時才查詢的冷儲存。代理透過 function call 主動「換頁」,決定什麼該調進 context、什麼該寫回外部。這個比喻的價值在於:它把「context window 放不下」這件事,從限制變成了可以工程化管理的分頁問題。
檢索(retrieval)是整套系統效能的真正瓶頸,也是今年進步最明顯的地方。 新 session 開始時,系統要從龐大的記憶庫裡撈出「這次真正用得上」的片段注入 context。2026 的做法不再單靠向量相似度,而是把語意相似度、關鍵字比對、實體匹配(entity matching)融合成單一評分。以 Mem0 公布的數字為例,他們在 LOCOMO 記憶基準上做到約 92.5% 準確率,較全脈絡做法把 p95 延遲降了約九成(1.44 秒對 17.12 秒),每次查詢約 6,900 tokens,而全脈絡動輒兩萬五到十萬 tokens。這組數字很能說明問題:好的記憶系統不是記得更多,而是只把最相關的那一小撮找回來——省下的是延遲、成本,還有模型的注意力。
🧠 記
- 記憶 ≠ 長 context:2026 的共識是把記憶做成獨立架構元件,有自己的儲存、寫入、檢索邏輯,別再靠把全部歷史塞回 context window 硬撐。
- 短期 vs 長期:短期記憶(工作記憶)活在單一 session;長期記憶跨 session 持久化,才讓代理「認得你」。
- 長期記憶三型態:情節(episodic,發生過什麼)、語意(semantic,抽取的事實)、程序(procedural,怎麼做)。
- OS 比喻(Letta/MemGPT):core=RAM、recall=磁碟快取、archival=冷儲存,靠 function call 主動換頁。
- 檢索是瓶頸:融合語意相似度+關鍵字+實體匹配,只撈最相關片段;好的記憶省的是延遲、token 成本與注意力,而非記更多。
✍️ 實踐
先別急著上知識圖譜或花俏框架,拿一個你手邊的代理專案做最小可行版:把「短期」和「長期」硬性分開。第一步,列出你的代理現在把哪些東西塞進 context window——多半你會發現一堆根本用不到的歷史對話。第二步,定義三個問題:哪些資訊只在這次 session 有效(留短期)?哪些是關於使用者的穩定事實(寫進語意記憶)?哪些是需要整段回放的事件(存成情節記憶)?
接著實作一個最陽春的「寫入 + 檢索」迴圈:每輪對話結束後,用一次小模型呼叫把「值得記住的事實」抽出來、存進一個向量庫(或甚至先用 SQLite 加一個 embedding 欄位);新 session 開始時,用當前 query 去檢索最相關的三到五條,注入 system prompt。跑個一週,把注入的記憶量與回答品質對照昨天講過的離線評測——你會很快看到「檢索太多」和「檢索太少」各自的病徵。記住一個判準:如果加了記憶反而讓延遲變兩倍、成本翻倍卻沒明顯提升品質,那你多半是撈回了雜訊,該回頭調檢索,而不是繼續加記憶。
🔗 延伸學習
- State of AI Agent Memory 2026(Mem0 基準報告)
- 2026 Token Optimization Playbook:把記憶成本砍 3–4 倍(Mem0)
- What Is AI Agent Memory?(IBM Think)
- Memory in the Age of AI Agents:論文清單(GitHub)
💬 問 AI
我想幫我的 AI 代理加上記憶系統,但不確定該從哪層下手。
請根據以下情境,建議一套最小可行架構:
【我的代理用途】(例:客服 / 個人助理 / 程式協作)：______
【使用頻率】(例:同一使用者會跨天多次回來嗎)：______
【現在怎麼存脈絡】(例:每次把全部對話塞回 context)：______
請針對這個情境:
1. 判斷我最該先做短期還長期記憶,理由是什麼
2. 建議情節/語意/程序三型態裡,我先實作哪一種
3. 給我一個最陽春的「寫入 + 檢索」迴圈設計(含技術選型)
4. 提醒我哪些常見錯誤會讓記憶反而拖慢、拉高成本卻沒提升品質