MemoryOS：把作業系統的記憶體分層搬進 LLM 代理

MemoryOS 想解決的是對話中斷後的人格流失

一般 LLM 應用的上下文只活在單次請求裡。對話一關，使用者上週說過的偏好、稱呼方式、正在進行的專案，全部消失。把歷史訊息整段塞回 prompt 是最直覺的補救，但 token 成本隨輪數線性上升，而且模型對長上下文中段資訊的取用本來就不穩定。MemoryOS 針對的就是這個缺口：它把代理的記憶拆成短期、中期、長期三層，讓對話結束後仍有結構化的使用者側寫與知識留存。README 引用的論文摘要寫得很清楚，目標是「透過階層式儲存、動態更新、檢索與生成，改善長對話中的連貫性與個人化」。

適用對象因此相當明確：做陪伴型代理、個人助理、需要記住使用者長期偏好的客服或教育應用的開發者。反過來說，如果你的場景是單次檢索問答、或使用者之間完全不需要隔離記憶，這套分層機制帶來的複雜度沒有對應回報。它是一套要跑起來的服務，不是一個可以 import 進去就忘掉的函式庫。

四個模組與三層儲存如何串成一條資料流

README 把架構拆成四個核心模組：Storage、Updating、Retrieval、Generation。命名直接借用作業系統的記憶體管理概念，實際運作方式是把對話內容依時間尺度分層存放，短期層承接當前會話，中期層彙整成段落級的摘要，長期層則沉澱成使用者側寫與知識。

Updating 模組負責在對話推進時決定哪些內容要從短期往中期、從中期往長期搬移，這是整套設計裡最需要調參的部分。Retrieval 在使用者發出新訊息時，從各層取回相關片段，交給 Generation 模組與當前輸入一起組成送進 LLM 的上下文。V1.2 的 release note 提到加入 ChromaDB 向量資料庫支援，並修掉其中固定 LLM 呼叫的問題，這暗示檢索路徑原本綁定了特定的向量後端，現在才把儲存引擎抽換出來。README 也把「可插拔的記憶模組，包含儲存引擎、更新策略與檢索演算法」列為主要特色，但文件沒有逐一列出目前實際可插拔的邊界在哪裡，這點需要讀原始碼確認。

值得一提的是 V1.1 之後加入的 similarity_threshold 參數。它出現在更新流程上，用來判斷新內容與既有記憶的相似程度，決定是合併還是新增。這個閾值調得太高，記憶會不斷增生、檢索時互相干擾；調得太低，新資訊會被判定為重複而被丟棄。官方把它列為獨立的新聞條目，說明它是實際使用時最常需要動的旋鈕。

從 PyPI 到 MCP Server 的兩條安裝路徑

MemoryOS 提供兩種使用方式。第一種是當作 Python 套件直接整合進自己的程式，README 提到 PyPI 上有對應的發行版本，並支援 BGE-M3 與 Qwen3 的 embedding。第二種是透過 MemoryOS-MCP，把記憶能力包成 MCP Server 的工具，掛到支援 MCP 的代理客戶端上，README 的支援清單第一項就是 Claude Desktop。

設定檔方面，官方文件頁面（bai-lab.github.io/MemoryOS/docs）是參數的唯一來源，README 本身只點名 similarity_threshold 這一個鍵。LLM 端支援 OpenAI、Deepseek、Qwen 等，2025 年 7 月的更新加入了 Deepseek-r1 與 Qwen3 這類推理模型。部署上，2025 年 7 月 15 日的新聞條目寫到已把 Docker 納入部署流程，但 README 被截斷的部分正好落在支援清單的表格中段，Docker 的具體映像名稱與啟動指令無法從現有材料確認，需要直接查文件頁。

評估方面，README 提供了 LoCoMo 資料集的重現章節，並宣稱在該基準上 F1 平均提升 49.11%、BLEU-1 提升 46.18%。這些數字來自論文與官方評估腳本，不是第三方複現的結果。要採用之前，建議先跑一次官方提供的重現流程，確認在你自己的硬體與模型組合下能對上多少。

MCP 平行化與 ChromaDB 修正透露的工程狀態

從 release 節奏可以看出專案的成熟度輪廓。v1.0 在 2025 年 7 月 12 日首次上 GitHub，V1.1 隔天，V1.2 在 7 月 18 日。一週內三個版本，功能推進很快，但也意味著 API 與設定鍵在這段期間並不穩定。V1.2 的說明是「加入 ChromaDB 向量資料庫支援，並修復其中固定 LLM 呼叫的問題」，後半句值得注意：在加入向量資料庫的同時才發現 LLM 呼叫被寫死，這種問題通常代表早期版本在後端抽象上留了捷徑。

另一條線索是 7 月 7 日的「5 倍更快」公告，說法是透過平行化優化降低延遲。搭配 7 月 14 日的 MCP 平行化加速，可以看出檢索與更新路徑原本是序列執行的。序列化在記憶層這種要同時查多層儲存、又要呼叫 LLM 做摘要的架構裡，延遲會直接疊加到使用者感知的回應時間上，所以這類優化是必要的，不是錦上添花。

如果你的團隊對依賴穩定性要求高，這個時間軸本身就是判斷依據：專案在 2025 年下半年的變動幅度不小，鎖定特定版本並保留升級測試的時間，比跟著 main 分支走務實。

它不適合的場景與三個會咬人的地方

第一個限制是成本結構。MemoryOS 的更新與檢索流程會呼叫 LLM 做摘要與判斷，這表示每一輪對話除了主要推論之外，還有額外的模型呼叫。對於高頻互動的應用，這筆開銷會複合成主要成本，而不是零頭。README 沒有提供每個模組各自呼叫幾次 LLM 的說明，這需要在實測中量測。

第二個限制是評估基準的性質。LoCoMo 是長對話記憶的學術基準，F1 與 BLEU-1 的改善幅度反映的是「在該資料集上生成的答案更接近參考答案」。它不直接等於你的產品場景會變好，尤其當你的記憶需求偏向結構化欄位（例如訂單編號、行程時間）而非自然語言側寫時，這套以語意相似度為核心的檢索未必比直接寫進資料庫欄位更可靠。

第三個是記憶污染。多使用者共用同一套部署時，記憶隔離要靠使用者識別碼來切分，而 similarity_threshold 的合併邏輯是在單一使用者的記憶池內運作。如果識別碼傳錯或缺失，不同人的側寫會被合併進同一條長期記憶，而且這種錯誤不會拋例外，只會讓回應慢慢變得奇怪。這類失敗模式在文件裡沒有對應的警告，屬於使用時要自己加防護的地方。

和 Mem0 這類提取式記憶方案的路線差異

同類專案中最常被拿來對比的是 Mem0。兩者的分歧在於記憶的組織單位。Mem0 走的是提取式路線：從對話中抽出一條條獨立的事實或偏好，存成扁平的事實清單，檢索時用向量相似度挑出相關條目塞回上下文。MemoryOS 走的是分層路線：記憶有時間尺度，短期對話會被彙整成中期摘要，再沉澱為長期側寫，檢索時是跨層取用。

這個差異在長對話上會顯現。提取式方案的事實清單會隨時間膨脹，檢索要在一大堆碎片裡找相關項，而且碎片之間缺乏脈絡，模型拿到的是零散斷言。分層方案的中期與長期層本身就是壓縮過的內容，單次檢索帶回的資訊密度較高，代價是更新流程更複雜，因為它必須決定何時觸發彙整。

選擇上可以這樣判斷：如果你的記憶內容偏向可枚舉的偏好與事實，而且需要精確的增刪改查，提取式清單比較好除錯；如果你要的是「這個人講話的風格與關注的主題」這類模糊側寫，MemoryOS 的分層壓縮更貼近需求。兩者不是替代關係，README 也沒有聲稱要取代任何同類方案。

授權、維護成本與升級時要盯的檔案

授權是 Apache-2.0，允許商業使用、修改與再散布，需保留著作權聲明與授權副本，修改過的檔案要標註變更。這裡不構成法律意見，若你的產品涉及專利或需要客製授權條款，還是要走內部法務流程。

維護成本主要落在三處。一是 LLM 與 embedding 供應商的帳單，隨對話量成長；二是向量資料庫的維運，V1.2 之後 ChromaDB 是明確支援的選項，但其他後端的支援程度文件未載明；三是升級測試，從一週三個版本的節奏來看，設定鍵與 API 在早期版本間有變動，鎖版並在升級前跑一次 LoCoMo 重現流程，是成本最低的驗證方式。

社群管道方面，README 列出 Discord、微信與 YouTube 影片，論文掛在 arXiv 2506.06326，並註明已被 EMNLP 2025 主會場接收。學術背書對方法論的可信度有幫助，但它不保證工程面的穩定性，這兩件事要分開看。

編輯結論

如果你正在做需要跨越多輪對話記住使用者偏好、而且願意自己維運向量資料庫與 LLM 金鑰的 Python 專案，MemoryOS 值得裝起來跑一次官方提供的 LoCoMo 評估流程；若你只要單次問答的上下文、或不想承擔 embedding 與推論成本，它會是過重的依賴。動手前先確認三件事：你選的 LLM 與 embedding 組合是否在支援清單內、similarity_threshold 這個參數在你的語料上調到多少才不會誤刪記憶、以及 ChromaDB 之外的儲存後端是否已納入 V1.2 的實作。

官方來源

1. BAI-LAB/MemoryOS on GitHub
2. License: Apache-2.0
3. Project website
4. README
5. Releases