Agent記憶框架怎麼選？5大Agent Memory項目工程級橫向對比，哪一種才是未來Agent記憶的標準答案 ？

大家好,今天我們開一個新系列 專門聊一個特別重要 但很多人一直沒搞透的話題 Agent的記憶 我相信你一定碰到過這種情況 昨天剛和AI聊完半小時的項目背景 今天打開新對話 他又把你當陌生人 一切從頭再來 這不是Bug 這是今天大多數LLM Agent的默認形態 無狀態 而要讓Agent真正長期為你工作 記憶就是繞不開的核心模塊 本集講這五個 他們代表了當前記憶框架的主流範式 這一集的目標是 讓你聽完之後 對Agent的記憶到底該怎麼設計這件事 建立一個完整的認知框架 好,我們開始 我想先從一個可能很多人沒聽過 但我覺得特別有意思的項目講起 他叫Text to MEM 為什麼第一個講他 因為他做的事情非常基礎 也非常野心大 他不是在做一個記憶系統 而是在給所有記憶系統定義一套通用的操作語言 你想想現在這個場景 你對Agent說一句 把我上週提到的那個會議紀要 標記成重要的 30天後自動歸導 這句話對人來說很清楚 但對一個記憶系統來說 問題就來了 上週是哪一段時間 那個會議紀要 對應數據庫裡的哪一條 標記成重要的 到底是改權重 改標籤 還是加提醒 Text to MEM的解法非常乾脆 他在LLM和存儲之間插一層AR 也就是中間表示層 你可以把它類比成CPU的指令集架構 Text to MEM把所有記憶操作收斂到12個原址操作 分成三個階段 ENC階段只有ENCODE 負責記憶的誕生 RET階段兩個操作 Retrieve是純數據返回 Summarize是讓LLM再生成一次摘要 STO階段九個操作 覆蓋記憶整個生命週期 我自己最欣賞的一個細節是 他把Retrieve和Summarize分開了 因為工程上他們完全不是一回事 Retrieve幾十毫秒就返回 而Summarize背後是一次完整的LLM推理 延遲是上千倍 分成兩個操作 執行引擎就可以用完全不同的超時 緩存降級策略 Text to MEM把所有操作都收斂成一段JSON 它是一個五元結構 第一個是階段 第二個是操作名 第三個是目標 第四個是參數 第五個是原數據 這五個字段合在一起 就像一張記憶操作的標準公文 其中最能體現工程成熟度的 是原數據裏藏的兩個安全字段 Dry Run和Confirmation 你想一種極端場景 LLM抽風給你生成一條JSON 說把所有記憶全部刪除 Text to MEM在這裏卡了一道硬性規則 你要麼先用Dry Run模擬一次 要麼顯示的把Confirmation設成True 二選一少一個都不讓過 光有安全閥還不夠 Text to MEM還上了兩層驗證 外層查的是格式和結構 走JSON Schema標準 裏層查的是業務邏輯 靠Predantic做攔截 比如Promote操作的絕對值和相對值 必須恰好有一個圍空 這種不信任LLM 但能兜住LLM的設計哲學 纔是Text to MEM真正值得學的地方 Text to MEM最有意思的設計點 是它的Log操作 四種模式 Read Only完全凍結 No Delete禁刪 Append Only只允許追加 Custom完全可編程 最喜歡的是Reviewer機制 本質上是RBAC風格的索繞過 當然Text to MEM目前還有明顯短板 存儲只有SQLite參考實現 沒有HTTP API 向量以JSON文本存在Text列裏 但它真正的價值是 它在幫整個行業定義記憶操作語言長什麼樣 講完了DG 我們進入更偏實戰的部分 第二個要講的是 目前開源社區裏熱度最高的 AI記憶開源框架之一 MEM0 它是VC孵化的項目 Github上的Star數已經是幾萬級別 為什麼這麼多人選MEM0 原因很直接 上下文窗口有限 長對話裏早期用戶偏好會丟 每次新繪畫都要重新介紹自己 不同繪畫之間沒有繼承關係 MEM0官方給出的數據是 相比直接用OpenAI Memory 準確率高26% 響應快91% Token省90% MEM0整體是三層 最上面是Memory API 中間是LLM推理加向量檢索的邏輯層 下面是存儲層 真正能體現工程成熟度的 是中間的五個工廠模式 LLM Factory支持17家個LLM提供商 Embedder Factory支持11家個Embedding模型 VectorStore Factory支持22家種 上量存儲 GrabStore Factory支持4種圖存儲 Reanchor Factory支持5種Reanchor 更妙的是 它用ImportLib做動態加載 你沒裝PanCom包也沒關係 只要用的不是PanCom就不會掛 MEM0在代碼裏顯示定義了三種記憶類型 語意記憶是抽象的事實性知識 情景記憶是具體事件 程序記憶對應Agent執行的完整步驟 程序記憶要求逐字保留 因為它真正的使用場景是 Agent崩潰後恢復執行狀態 幾個我覺得最值得學的設計 第一個 UUID幻覺處理 LLM對長UUID字幅串處理能力很差 會幻覺 MEM0的做法是 把LLM看到的記憶ID 臨時映射成0,1,2這樣的簡單整數 LLM只需要決定對第三條記憶執行update 然後系統再把整數映射回真實UUID 第二個 雙存儲並行 向量存儲負責語意相似搜索 圖存儲負責關係推理 兩條路徑用threadpool executor並行跑 結果合併返回 第三個 雙prompt策略 MEM0有兩個記憶抽取prompt user memory extraction prompt只看用戶消息 agent memory extraction prompt只看助手消息 這是一個很聰明的職責分離 防止AI助手的自我表達污染用戶記憶 同時也允許AI助手自己積累 我是一個什麼樣的AI的自我認知 第四個 多層級作用域隔離 用戶隔離 agent隔離 運行式隔離 三層隔離 直接支持多用戶多agent繪畫隔離的複雜場景 MEM0很強 但它有一個很真實的成本瓶頸 每次add調用 完整模式下會調用2-5次LLM 更麻煩的是 隨著用戶歷史記憶的增多 token數會隨記憶規模線性增長 這就意味著 MEM0不適合高頻實時寫入的場景 它更適合用戶維度 對話力度 中低頻寫入 比如AI對話助手 客服系統 醫療健康追蹤這一類 所以說 MEM0真正強的地方不是某一項黑科技 而是工程化的全家桶 第三個我想重點講的是letter 如果說MEM0是把g層做成了成熟的中間件 那letter是在做一件更酷的事情 把操作系統的虛擬內存思想 完整地搬進agent架構裏 很多同學應該記得 2023年10月那篇論文MEM GPT 2024年9月正式更名為letter letter的核心是一個三層記憶架構 Core Memory 核心內存 直接嵌在系統prompt裏 每次推理LLM都看得到 就像CPU能直接訪問的RAM Archival Memory 歸檔內存 容量無限 走向量檢索 就像磁盤 Recall Memory 召回內存 存放所有歷史對話消息 就像操作系統的日誌系統 Core Memory的每個block 是一個三元組 Label是路徑命名空間 Description告訴agent 這個block是幹什麼的 Value是實際內容 Limit是字符上限 這個limit默認十萬字符 它是一種強制的信息壓縮約束 逼迫agent主動做信息徵流 當上下文窗口快滿了 觸發summarizer 默認驅逐30%的消息 被驅逐的消息寫進Recall Memory 仍然可以通過conversation search 再被檢索出來 被驅逐的消息不是真的消失了 他們只是從in context 移到了out of context 這纔是真正意義上的虛擬內存 無損分層 Lata有一個在同類項目裡 完全獨樹一幟的設計 Gate Enabled Block Manager 它把真正的gate 引入了agent記憶管理 雙存儲 Gate是真實來源 PG數據庫是快速讀緩存 每一次記憶變更 都會產生一次Gate commit 攜帶agent ID 時間戳 變更原因 這樣的好處非常多 不可變性 內容尋址 存儲 防止寂寞損壞 完整歷史 每一次記憶修改都能回溯 並發安全 多個sleep time agent 可以用Gatewalk tree隔離修改 可審計 每個commit 就是一條審計記錄 再配合Memfs 記憶會被組織成一棵真正的目錄樹 一個目錄放agent的人格設定 一個放用戶偏好和事實知識 一個放學到的技能和經驗 每一份記憶 都是一個獨立的markdown文件 另一個很妙的設計是 sleep time agent 在用戶不交互的時候 agent也在持續自我改進 主agent只負責推理和回覆 低延遲 每五步觸發一次sleep time agent 他在後臺讀最近的對話 分析更新memory block 三個好處 主路徑低延遲 後臺可以用更大token預算 做深度反思 充分利用空閒時間 lata是目前開源裏 記憶自製能力最強的系統 但代價也很明顯 認知成本高 數據庫強依賴 80多個依賴包 總結 如果mem0是中間鍵 lata就是系統 第四個項目來自阿裏巴巴的 agentscope團隊 叫Remy Remy最核心的理念 文件及記憶 傳統做法記憶全存數據庫裏 你想知道AI記住了你什麼 必須通過API去查 整個記憶是個黑盒 Remy反過來 記憶直接存成markdown文件 你打開就能看見 可以直接編輯 可以git版本控制 這把記憶的控制權和透明度 還給了用戶 Remy內部有兩套系統 Remy Lite是文件記憶 用於短期工作記憶 Remy本體是像量記憶 用於長期語意記憶 兩套系統的時間維度是錯開的 第一個技術亮點 Delta Firewall 增量監控 當記憶文件累積到幾十KB後 每次變更都重新處理整個文件 是對embedding API的巨大浪費 Remy先檢測文件 是不是純追加模式 如果是就只處理新增部分 節省92%的API的調用 第二個亮點 Win2Use和Content分離 它把像量嵌入建在Win2Use上 而不是Content上 由於用戶查詢和Win2Use 天然語意接近 大幅提升召回率 第三個 AI自主記憶管理 把文件操作工具給AI 讓AI自己決定如何組織記憶 Remy的性能數據 千問三8B加Remy後 綜合得分超過了沒有記憶的千問34B 好的記憶系統 可以讓小模型打過大模型 Remy是目前開源裡 最對人友好的記憶系統 最後一個要講的是 整個上集裡範式最激進的項目 叫MemU 它的slogan 24小時常駐主動出擊的Agent記憶系統 前面四個項目的記憶系統 有一個共同點 本質上都是被動的 用戶說一句話 系統纔去add一條記憶 用戶問一個問題 系統纔去設置一次 MemU想做的是另一個方向 讓記憶系統不再等 自己主動跑 用戶沒說話的時候 他在看 甚至在用戶下一句話 還沒發出來之前 他已經預測到 你大概會問什麼 然後把相關上下文提前加載好了 MemU實現主動性的方式 是雙Agent架構 MemAgent幹老本行 聽用戶說話 調工具 生成回覆 MemUBot只負責記憶這件事 持續盯著每一次交互 後臺提取 整理 分類 代碼實現其實很實在 MemUBot 就是用Python的asyncSIO.createTask 起的一個異步後臺任務 靠共享Conversation Messages列表通信 這個設計的精妙之處在於 簡單到不像創新 MemU的文件系統 是一個概念隱喻 底層是數據庫 文件夾對應Category 文件對應MemoryItem 符號鏈接對應交叉引用 掛載點對應Resource 和Remy的用法完全不一樣 Remy是給人看的透明文本 MemU是Bot自己維護的 結構化目錄術 一個偏用戶主權 一個偏Bot自制 MemU在V1.4版本 引入了一個我很喜歡的機制 叫Salience Over Memory 顯著性感知記憶 具體做法是 每條MemoryItem 都帶一個Reinforcement Count計數器 每當被檢索一次 計數就加1 下次排序時 根據強化次數加權 越常用的記憶 越容易被再次召回 這在模擬人類記憶的 一個本質特性 你越經常想到的事情 就越容易想起 我願意把它叫做 給記憶加了一層肌肉記憶 MemU在Pokemon基準上 跨所有推理任務的平均準確率 是92.09% 這正是Mem0當年 用來打OpenAI Memory的 同一個基準 兩個框架 站在同一把尺子前面比 MemU給出了 非常有競爭力的數字 MemU最適合 需要長期陪伴 長期學習的場景 個人AI助手 企業級客服 DevOps Agent 研究型助手 前面四個項目 Text-to-Mem 在做記憶的語言 Mem0 在做記憶的中間件 Leta 在做管理記憶的Agent Remy 在做人能看見的記憶 它們的共同點是 記憶始終是一個 被使用的對象 MemU 把這個關係反過來 記憶自己 成為了一個Agent 如果讓我給上一集 挑一句 最想留給觀眾思考的話 就是這一句 從Agent有記憶 到記憶本身 是一個Agent 好 今天這集 就先聊到這裡 我們回頭捋一下 這五個項目的位置 Text-to-Mem 是最底層的記憶操作語言 12個操作加5元 Jason契約 Mem0 是當下最流行的 記憶中間件 三種記憶 五大工廠 雙存儲 並行 Lata 是記憶自製 做得最徹底的 三層記憶 Gate版本化 Sleeptime Agent Remy走的是 完全相反的哲學 文件及記憶 把控制權 交還給用戶 MemU 把記憶本身 變成一個 24×7 主動運行的Bot 想快速給產品 加記憶層 看Mem0 想做真正 有狀態的Agent 看Lata 想要記憶 能主動預測用戶 看MemU 想要記憶透明可見 看Remy 做研究 定義自己的記憶操作語言 看Text to Mem 下一集 我們會聊更前沿的五個項目 MemOS Open Viking Hindsight SecondMe MetaMem 如果今天這集讓你有收穫 請一鍵三連支持一下 下集的五個項目 一個比一個硬核 我們下期見