【Agent】MemOS 源碼筆記---(1)--基本概念
目錄
- 【Agent】MemOS 源碼筆記---(1)--基本概念
- 0x00 概要
- 0x01 背景
- 1.1 為什麼需要MemOS
- 1.2 MemOS 相關信息
- 1.3 MemOS能做些什麼
- 0x02 原理
- 2.1 記憶類型
- 2.1.1 GeneralTextMemory
- 記憶結構
- 元數據域 (TextualMemoryMetadata)
- 2.1.2 TreeTextMemory
- 記憶結構
- 元數據字段 (TreeNodeTextualMemoryMetadata)
- 特色
- 2.1.3 KVCacheMemory(激活記憶)
- 記憶結構
- API總結 (KVCacheMemory)
- 特色
- 2.1.4 參數記憶
- 設計目標
- 當前狀態
- 2.1.5 混合模式
- 何時使用:
- 工作原理:
- 0x03 MemCube
- 3.1 結構
- 3.2 初始化
- 3.3 核心方法
- 3.4 GeneralMemCube
- 3.4.1 核心特色
- 3.4.2 流程圖
- 初始化
- 加載流程
- 存儲流程
- 3.4.3 代碼
- 3.5 實例
- 🕰️ 創意1:智能世界時間線系統
- 🧠 創意2:動態Working Memory世界背景
- 0x04 記憶生產流程
- 0x05 常見問題
- Q:MemOS 和普通 RAG 框架有什麼區別?
- Q:MemOS 可以和已有 RAG 或知識圖譜結合嗎?
- 0xFF 參考
0x00 概要
隨着大型語言模型(LLMs)的不斷演進,其所承擔的任務日益複雜,包括多輪對話、規劃、決策制定以及個性化代理等。然而,主流 LLM 架構往往在記憶結構化、管理和集成方面存在不足,導致知識更新成本高、行為狀態不可持續以及難以積累用户偏好。因此,在此背景下,如何高效管理和利用記憶,成為實現長期智能與適應性能力的關鍵因素。
MemOS(Memory Operating System)的核心思想是把“記憶”從輔助功能提升為系統級資源:統一格式、統一生命週期、統一調度。它像操作系統管理磁盤一樣管理記憶——自動存取、版本控制、冷熱分層、併發安全,讓大模型應用無需重複編寫記憶邏輯,就能持續積累知識、按需調用上下文、並在多輪對話中保持連貫。
MemOS 的內容非常豐富,是個寶庫,但是因為內容太多,所以只能找自己最好奇的地方去閲讀。而且,因為本系列是使用MemOS的某個版本進行學習,而MemOS 本身在飛速發展,因此本系列的內容可能與最新進展有出入。
本文是基於MemOS的文檔內容進行梳理和重整,把散落在多個文檔中的內容,按照自己的理解聚合到一個文檔中。希望藉助本文,讀者可以瞭解到MemOS的意義、設計思路和基本概念。
注:MemOS文檔非常出色,本系列會大量直接引用其文檔。
0x01 背景
1.1 為什麼需要MemOS
大模型原生的記憶存在侷限:
- 上下文有限:一次對話的Token窗口再大,也無法承載長期知識。
- 遺忘嚴重:用户上週説過的偏好,下次對話就消失了。
- 難以管理:隨着交互增多,記憶混亂,開發者需要額外邏輯處理。
MemOS的價值在於,它抽象出記憶層,讓你只關注業務邏輯:
- 不再手寫繁瑣的“長文本拼接”或“額外數據庫調用”。
- 記憶可以像模塊一樣複用、擴展,甚至在不同Agent、不同系統之間共享。
- 通過主動調度和多層管理,記憶調用更快、更準,顯著降低幻覺。
簡單來説:MemOS讓AI不再是一次性的對話機器,而是能持續成長的夥伴。
下圖右側是傳統記憶系統,左側是MemOS。
1.2 MemOS 相關信息
論文名稱: MemOS: A Memory OS for AI System*
第一作者: MemTensor (Shanghai) Technology Co., Ltd.
論文鏈接: https://arxiv.org/pdf/2507.03724
GitHub:
- https://github.com/MemTensor/MemOS.git
- https://github.com/MemTensor/MemOS-Docs
1.3 MemOS能做些什麼
- 個性化對話:記住用户的姓名、習慣、興趣、指令偏好,下次自動補充。
- 團隊知識庫:把碎片對話轉化為結構化知識,供多個 Agent 協作使用。
- 任務連續性:跨會話、跨應用保持記憶,讓 AI 從容處理長流程任務。
- 多層記憶調度:針對不同需求調用最合適的記憶,提升性能與準確率。
- 開放擴展:支持單獨作為 API 使用,也能接入現有的框架(官方使用指導即將上線,着急的老師們也可以先自己動手哦~)
0x02 原理
參數化記憶將完成 MemOS 關於統一Memory³架構的設想:
- 參數化記憶: 嵌入知識
- 激活記憶: 短暫的運行狀態
- 明文記憶: 結構化的、可追溯的外部記憶
將這三者結合在一起,可以實現適應性強、可進化和可解釋的智能系統。
下圖就是MemOS的系統架構。
2.1 記憶類型
MemOS 把記憶分為以下三種。
- 結構化記憶(明文記憶):嘗試基於圖的分層知識 TreeTextMemory,是結構化、層次化和知識圖譜。圖與向量後端會連接 Neo4j 或 Qdrant 實現生產級向量/圖搜索。
- 激活記憶:使用 KVCacheMemory (最近或穩定的上下文)加速多輪對話,高效的運行時狀態緩存。
- 參數化記憶:用適配器/LoRA 實現動態技能注入。
2.1.1 GeneralTextMemory
title: "GeneralTextMemory: 通用文本的記憶"。
desc: "GeneralTextMemory 是MemOS中一個靈活的、基於向量的明文記憶模塊,用於存儲、搜索和管理非結構化知識。它適用於會話代理、個人助理和任何需要語義記憶檢索的系統。"
記憶結構
每條記憶都存儲為一個 TextualMemoryItem:
memory:主要文本內容(例如,“用户喜歡番茄。”)metadata:額外信息,使記憶可搜索且易於管理——類型、時間、來源、置信度、實體、標籤、可見性和更新時間。
這些字段使每條記憶都能被查詢、篩選和方便治理。
|
字段
|
類型
|
描述
|
|
|
|
UUID (如果省略則自動生成)
|
|
|
|
記憶內容主體 (必填)
|
|
|
|
元數據(用於搜索/過濾)
|
元數據域 (TextualMemoryMetadata)
|
字段
|
類型
|
描述
|
|
|
|
記憶類型,比如它是事實、事件還是觀點
|
|
|
|
記憶所指的日期/時間
|
|
|
|
記憶源
|
|
|
|
確定性/可信度評分(0–100)
|
|
|
|
主要實體/概念
|
|
|
|
主題標籤,即分組用的額外標籤
|
|
|
|
訪問範圍,即誰可以訪問
|
|
|
|
最近更新時間戳 (ISO 8601)
|
所有的值都經過驗證,無效的值將引發錯誤。
2.1.2 TreeTextMemory
TreeTextMemory 支持以結構化方式組織、關聯並檢索記憶,同時保留豐富的上下文信息與良好的可解釋性。即,TreeTextMemory是分層結構的、基於圖的、樹形明文記憶。當前使用Neo4j作為後端,未來計劃支持更多圖數據庫。
記憶結構
每個節點在TreeTextMemory 是一個 TextualMemoryItem:
id: 唯一記憶ID(如果省略則自動生成)memory: 主要文本metadata: 包括層次結構信息、嵌入、標籤、實體、源和狀態
元數據字段 (TreeNodeTextualMemoryMetadata)
|
字段
|
類型
|
描述
|
|
|
|
生命週期分類
|
|
|
|
節點狀態
|
|
|
|
訪問範圍
|
|
|
|
來源列表 (例如: 文件, URLs)
|
|
|
|
原始來源類型
|
|
|
|
確定性得分
|
|
|
|
提及的實體或概念
|
|
|
|
主題標籤
|
|
|
|
基於向量嵌入的相似性搜索
|
|
|
|
創建時間戳(ISO 8601)
|
|
|
|
最近更新時間戳(ISO 8601)
|
|
|
|
使用歷史
|
|
|
|
附加上下文
|
最佳實踐:使用有意義的標籤和背景——它們有助於組織你的圖進行多跳推理。
特色
TreeTextMemory的特點為:
- 結構層次: 像思維導圖一樣組織記憶——節點可以有父母、孩子和交叉鏈接。
- 圖風格的鏈接: 超越純粹的層次結構-建立多跳推理鏈。
- 語義搜索+圖擴展: 結合向量和圖形的優點。
- 可解釋性: 追蹤記憶是如何連接、合併或隨時間演變的.
2.1.3 KVCacheMemory(激活記憶)
KVCacheMemory 是MemOS中用於存儲和管理KV cache的專用記憶模塊,主要用於加速大語言模型(LLMs)推理並支持有效的上下文複用。它作為激活記憶有助於對於會話式和生成式人工智能系統。
在MemOS中,KV Cache最適合存儲語義穩定且經常複用的背景信息,例如:
- 常見問題(FAQs)或特定領域知識
- 先前的對話歷史
這些穩定的明文記憶項由MemScheduler模塊自動識別和管理。一旦被選中,它們就會被提前轉換成KV格式的表示(KVCacheItem)。這個預計算步驟以可複用的格式存儲記憶的激活狀態(鍵值對張量),允許它們在推理期間注入到模型的注意力緩存中
一旦進行轉換,這些KV記憶就可以跨查詢複用,而不需要對原始內容重新編碼。這減少了處理和存儲大量文本的計算開銷,使其成為需要快速響應時間和高吞吐量的應用程序的理想選擇。
記憶結構
通過KVCacheMemory實現基於KV的記憶複用,在保持相同輸出的同時,大大減少了模型大小和查詢類型之間的延遲。通過將可複用記憶從明文提示轉移到預先計算的KV Cache,MemOS消除了冗餘的上下文編碼,並實現了更快的響應時間,特別是在實時的、記憶增強的LLM應用程序中。
每個緩存被存儲為一個KVCacheItem:
|
字段
|
類型
|
描述
|
|
|
|
緩存中的唯一ID(UUID)
|
|
|
|
實際的KV Cache(transformers)
|
|
|
|
元數據 (源, 抽取時間等.)
|
API總結 (KVCacheMemory)
初始化
KVCacheMemory(config: KVCacheMemoryConfig)
核心方法如下:
|
方法
|
描述
|
|
|
使用LLM從輸入文本中提取KV Cache
|
|
|
添加一個或多個 |
|
|
根據ID獲取單個緩存
|
|
|
根據IDs獲取多個緩存
|
|
|
返回所有存儲的緩存
|
|
|
從多個IDs合併並返回組合緩存
|
|
|
通過IDs刪除緩存
|
|
|
刪除所有緩存
|
|
|
將所有緩存序列化到目錄中的pickle文件
|
|
|
從目錄中的pickle文件加載緩存
|
|
|
將 |
當調用dump(dir), 系統寫到:
<dir>/<config.memory_filename>
該文件包含所有KV Cache的pickle字典,可以使用load(dir)重新加載。
特色
將MemScheduler與KV Cache記憶集成可以實現顯著的性能優化,特別是在LLM推理的預填充階段。
當無KV Cache記憶時
- 每個新查詢都被添加到完整的提示模板中,包括背景知識。
- 模型必須在整個序列上重新計算token嵌入和注意力——即使是未更改的記憶。
當有KV Cache記憶時
- 背景知識以鍵值對張量的形式緩存一次。
- 對於每個查詢,只對新用户輸入(查詢token)進行編碼。
- 之前緩存的KV被直接注入到注意力機制中。
KV Cache這種分離減少了預填充階段的冗餘計算,從而導致:
- 跳過背景知識的重複編碼
- 更快的查詢token和緩存記憶之間的注意力計算
- 降低首次token時間(Time To First Token, TTFT) 生成過程中的延遲
這種優化在以下方面特別有價值:
- 多回合聊天機器人交互
- 檢索增強生成或上下文增強生成(RAG, CAG)
- 在固定文檔或FAQ風格記憶上操作的助理
2.1.4 參數記憶
參數化記憶(Parametric Memory) 是MemOS內部的核心長期的知識和能力儲存。與明文記憶或激活記憶不同,參數記憶,對語言結構、世界知識和一般推理能力的深度表示進行編碼,直接嵌入在模型的權重中。
在MemOS架構中,參數記憶不僅僅指靜態預訓練權重。它還包括模塊化權重組件,如LoRA適配器和插件專家模塊。這些允許您逐步擴展或專業化您的LLM的能力,而無需重新訓練整個模型。
例如,您可以將結構化或穩定的知識提取為參數形式,將其保存為能力塊,並在推理過程中動態加載或卸載它。這使得為法律推理、財務分析或特定領域的摘要等任務創建“專家子模型”變得容易——所有這些都由MemOS管理。
設計目標
- 可控制性 — 按需生成、加載、交換或組合參數模塊on demand.
- 可塑性 — 與明文和激活記憶一起演化;支持知識的提純與回滾
- 可追溯性 (開發中) — 參數塊的版本控制和管理
當前狀態
參數化記憶(Parametric Memory) 目前仍處於設計和原型階段。用於生成、壓縮以及熱插拔參數模塊的 API 將在未來版本中發佈,旨在支持多任務、多角色和多代理架構。
2.1.5 混合模式
何時使用:
- 你希望同時擁有長期可解釋記憶與短期快速上下文。
- 理想場景:用於具備計劃能力、能記住事實並保持上下文的複雜智能體。
- 展示多記憶調度能力。
工作原理:
- TreeTextMemory 將你的長時記憶存儲在圖數據庫(Neo4j)中。
- KVCacheMemory 將最近或穩定的上下文作為激活緩存保存。
- 二者在一個 MemCube 中協同工作,由你的
MOSPipeline 統一管理。
0x03 MemCube
MemCube是 MemOS 中的核心組織單元,專為封裝和管理用户或代理的所有類型記憶而設計。它為加載、保存和操作多個記憶模塊提供統一接口,使構建、共享和部署記憶增強應用程序變得容易。
MemCube 是一個容器,捆綁了三種主要類型的記憶:
- 明文記憶 (例如,
GeneralTextMemory、TreeTextMemory): 用於存儲和檢索非結構化或結構化文本知識。 - 激活記憶 (例如,
KVCacheMemory): 用於存儲鍵值緩存以加速 LLM 推理和上下文重用。 - 參數化記憶 (例如,
LoRAMemory): 用於存儲模型適應參數(如 LoRA 權重)。
每種記憶類型都是獨立可配置的,可以根據需要進行交換或擴展。
3.1 結構
MemCube 由配置定義(參見 GeneralMemCubeConfig),該配置為每種記憶類型指定後端和配置。典型結構是:
MemCube
├── text_mem: TextualMemory
├── act_mem: ActivationMemory
└── para_mem: ParametricMemory
所有記憶模塊都可通過 MemCube 接口訪問:
mem_cube.text_memmem_cube.act_memmem_cube.para_mem
基類代碼如下:
class BaseMemCube(ABC):
"""Base class for all MemCube implementations."""
@abstractmethod
def __init__(self, config: BaseMemCubeConfig):
"""Initialize the MemCube with the given configuration."""
self.text_mem: BaseTextMemory
self.act_mem: BaseActMemory
self.para_mem: BaseParaMemory
@abstractmethod
def load(self, dir: str) -> None:
"""Load memories from a directory."""
@abstractmethod
def dump(self, dir: str) -> None:
"""Dump memories to a directory."""
3.2 初始化
from memos.mem_cube.general import GeneralMemCube
mem_cube = GeneralMemCube(config)
3.3 核心方法
MemCube 的核心方法如下:
|
方法
|
描述
|
|
|
從目錄加載所有記憶
|
|
|
將所有記憶保存到目錄
|
|
|
訪問明文記憶模塊
|
|
|
訪問激活記憶模塊
|
|
|
訪問參數化記憶模塊
|
|
|
從目錄加載 MemCube
|
|
|
從遠程倉庫加載
|
3.4 GeneralMemCube
GeneralMemCube(通用記憶立方體)是一個記憶管理容器,核心職責是統一管理三種類型的 AI 記憶(文本記憶、激活記憶、參數化記憶),提供 “加載 - 存儲 - 實例化” 的全流程能力,適配本地和遠程兩種數據來源場景。
3.4.1 核心特色
- 多類型記憶統一管理:
- 整合文本記憶(text_mem)、激活記憶(act_mem)、參數化記憶(para_mem)三類記憶,通過統一接口(load/dump)實現批量加載 / 存儲,避免分散管理的繁瑣。
- 支持按需加載 / 存儲:可指定具體記憶類型,無需操作全部記憶,提升效率。
- 靈活的實例化方式:
- 本地初始化:從本地目錄加載配置和記憶數據(
init_from_dir),適配離線使用場景。 - 遠程初始化:從遠程倉庫(默認 Hugging Face)下載數據並初始化(
init_from_remote_repo),支持共享和複用公開記憶資源。
- 配置安全與兼容性:
- 配置校驗:加載時校驗配置文件的 schema 一致性,避免因配置格式不匹配導致的運行錯誤。
- 配置合併:支持將默認配置與用户配置合併,兼顧通用設置與個性化需求,提升配置靈活性。
- 類型安全與容錯:
- 記憶實例類型校驗:通過 setter 方法強制校驗記憶實例類型,確保僅支持對應基類的子類實例,避免類型錯誤。
- 未初始化提示:訪問未初始化的記憶時輸出警告日誌,而非直接拋出異常,提升系統容錯性。
- 數據安全保護:
- 存儲時校驗目標目錄是否為空,避免覆蓋已有數據,防止誤操作導致的數據丟失。
- 存儲時自動同步配置文件,確保記憶數據與配置一一對應,便於後續加載和遷移。
3.4.2 流程圖
初始化
加載流程
存儲流程
3.4.3 代碼
GeneralMemCube 的代碼如下
class GeneralMemCube(BaseMemCube):
"""記憶立方體(MemCube)是一個用於加載和存儲三種類型記憶的容器。
支持的記憶類型:文本記憶(text_mem)、激活記憶(act_mem)、參數化記憶(para_mem)
"""
def __init__(self, config: GeneralMemCubeConfig):
"""使用配置初始化記憶立方體。
參數:
config: 通用記憶立方體配置實例(GeneralMemCubeConfig),包含三種記憶的後端配置等信息
"""
self.config = config # 保存配置實例
time_start = time.time() # 記錄文本記憶初始化開始時間
# 初始化文本記憶:若配置中後端不是"未初始化"狀態,則通過工廠類創建實例
self._text_mem: BaseTextMemory | None = (
MemoryFactory.from_config(config.text_mem)
if config.text_mem.backend != "uninitialized"
else None
)
# 初始化激活記憶:邏輯同文本記憶
self._act_mem: BaseActMemory | None = (
MemoryFactory.from_config(config.act_mem)
if config.act_mem.backend != "uninitialized"
else None
)
# 初始化參數化記憶:邏輯同文本記憶
self._para_mem: BaseParaMemory | None = (
MemoryFactory.from_config(config.para_mem)
if config.para_mem.backend != "uninitialized"
else None
)
def load(
self, dir: str, memory_types: list[Literal["text_mem", "act_mem", "para_mem"]] | None = None
) -> None:
"""從指定目錄加載記憶數據。
參數:
dir: 存儲記憶文件的目錄路徑
memory_types: 要加載的記憶類型列表(可選)。若為None,加載所有可用的記憶類型。
可選值:["text_mem", "act_mem", "para_mem"]
"""
# 讀取目錄中的配置文件schema,用於校驗配置一致性
loaded_schema = get_json_file_model_schema(os.path.join(dir, self.config.config_filename))
# 校驗加載的配置schema是否與當前實例的配置schema一致,不一致則拋出配置錯誤
if loaded_schema != self.config.model_schema:
raise ConfigurationError(
f"Configuration schema mismatch. Expected {self.config.model_schema}, "
f"but found {loaded_schema}."
)
# 若未指定記憶類型,默認加載所有三種類型
if memory_types is None:
memory_types = ["text_mem", "act_mem", "para_mem"]
# 加載指定類型的記憶(僅加載已初始化的記憶實例)
if "text_mem" in memory_types and self.text_mem:
self.text_mem.load(dir) # 調用文本記憶的load方法加載數據
if "act_mem" in memory_types and self.act_mem:
self.act_mem.load(dir) # 調用激活記憶的load方法加載數據
if "para_mem" in memory_types and self.para_mem:
self.para_mem.load(dir) # 調用參數化記憶的load方法加載數據
def dump(
self, dir: str, memory_types: list[Literal["text_mem", "act_mem", "para_mem"]] | None = None
) -> None:
"""將記憶數據存儲到指定目錄。
參數:
dir: 保存記憶文件的目標目錄路徑
memory_types: 要存儲的記憶類型列表(可選)。若為None,存儲所有可用的記憶類型。
可選值:["text_mem", "act_mem", "para_mem"]
"""
# 校驗目標目錄是否存在且非空,非空目錄則拋出異常(避免覆蓋已有數據)
if os.path.exists(dir) and os.listdir(dir):
raise MemCubeError(
f"Directory {dir} is not empty. Please provide an empty directory for dumping."
)
# 始終先存儲配置文件(確保配置與記憶數據同步)
self.config.to_json_file(os.path.join(dir, self.config.config_filename))
# 若未指定記憶類型,默認存儲所有三種類型
if memory_types is None:
memory_types = ["text_mem", "act_mem", "para_mem"]
# 存儲指定類型的記憶(僅存儲已初始化的記憶實例)
if "text_mem" in memory_types and self.text_mem:
self.text_mem.dump(dir) # 調用文本記憶的dump方法存儲數據
if "act_mem" in memory_types and self.act_mem:
self.act_mem.dump(dir) # 調用激活記憶的dump方法存儲數據
if "para_mem" in memory_types and self.para_mem:
self.para_mem.dump(dir) # 調用參數化記憶的dump方法存儲數據
@staticmethod
def init_from_dir(
dir: str,
memory_types: list[Literal["text_mem", "act_mem", "para_mem"]] | None = None,
default_config: GeneralMemCubeConfig | None = None,
) -> "GeneralMemCube":
"""從本地目錄創建並初始化記憶立方體實例。
參數:
dir: 存儲記憶文件和配置文件的本地目錄路徑
memory_types: 要加載的記憶類型列表(可選)。若為None,加載所有可用類型。
default_config: 用於合併的默認配置(可選)。若提供,會合並通用設置,
同時保留用户特定的關鍵配置字段。
返回:
GeneralMemCube: 已加載指定目錄記憶數據的記憶立方體實例
"""
# 構建配置文件路徑(默認配置文件名為config.json)
config_path = os.path.join(dir, "config.json")
# 從JSON文件加載配置實例
config = GeneralMemCubeConfig.from_json_file(config_path)
# 若提供了默認配置,將其與加載的配置合併
if default_config is not None:
config = merge_config_with_default(config, default_config)
# 創建記憶立方體實例並加載指定目錄的記憶數據
mem_cube = GeneralMemCube(config)
mem_cube.load(dir, memory_types)
return mem_cube
@staticmethod
def init_from_remote_repo(
cube_id: str,
base_url: str = "https://huggingface.co/datasets",
memory_types: list[Literal["text_mem", "act_mem", "para_mem"]] | None = None,
default_config: GeneralMemCubeConfig | None = None,
) -> "GeneralMemCube":
"""從遠程倉庫創建並初始化記憶立方體實例。
參數:
cube_id: 遠程倉庫名稱(即記憶立方體ID)
base_url: 遠程倉庫的基礎URL(默認是Hugging Face數據集倉庫)
memory_types: 要加載的記憶類型列表(可選)。若為None,加載所有可用類型。
default_config: 用於合併的默認配置(可選)。
返回:
GeneralMemCube: 已加載遠程倉庫記憶數據的記憶立方體實例
"""
# 下載遠程倉庫到本地目錄
dir = download_repo(cube_id, base_url)
# 調用本地目錄初始化方法,創建並返回記憶立方體實例
return GeneralMemCube.init_from_dir(dir, memory_types, default_config)
@property
def text_mem(self) -> "BaseTextMemory | None":
"""獲取文本記憶實例(屬性訪問器)。"""
if self._text_mem is None:
logger.warning("Textual memory is not initialized. Returning None.")
return self._text_mem
@text_mem.setter
def text_mem(self, value: BaseTextMemory) -> None:
"""設置文本記憶實例(屬性修改器)。
參數:
value: 要設置的文本記憶實例,必須是BaseTextMemory的子類實例
"""
if not isinstance(value, BaseTextMemory):
raise TypeError(f"Expected BaseTextMemory, got {type(value).__name__}")
self._text_mem = value
@property
def act_mem(self) -> "BaseActMemory | None":
"""獲取激活記憶實例(屬性訪問器)。"""
if self._act_mem is None:
logger.warning("Activation memory is not initialized. Returning None.")
return self._act_mem
@act_mem.setter
def act_mem(self, value: BaseActMemory) -> None:
"""設置激活記憶實例(屬性修改器)。
參數:
value: 要設置的激活記憶實例,必須是BaseActMemory的子類實例
"""
if not isinstance(value, BaseActMemory):
raise TypeError(f"Expected BaseActMemory, got {type(value).__name__}")
self._act_mem = value
@property
def para_mem(self) -> "BaseParaMemory | None":
"""獲取參數化記憶實例(屬性訪問器)。"""
if self._para_mem is None:
logger.warning("Parametric memory is not initialized. Returning None.")
return self._para_mem
@para_mem.setter
def para_mem(self, value: BaseParaMemory) -> None:
"""設置參數化記憶實例(屬性修改器)。
參數:
value: 要設置的參數化記憶實例,必須是BaseParaMemory的子類實例
"""
if not isinstance(value, BaseParaMemory):
raise TypeError(f"Expected BaseParaMemory, got {type(value).__name__}")
self._para_mem = value
3.5 實例
官方代碼給出了使用實例如下:
🕰️ 創意1:智能世界時間線系統
基於MemOS構建動態的武俠世界時間軸,讓AI理解事件的因果關係:
# 示例:智能時間線管理
timeline_memory = {
"1094年": {
"events": ["蕭峯身世之謎揭開", "聚賢莊大戰"],
"consequences": ["江湖震動", "丐幫分裂"],
"affected_characters": ["蕭峯", "阿朱", "段正淳"]
},
"1095年": {
"events": ["雁門關事件真相", "阿朱之死"],
"consequences": ["蕭峯心境轉變", "宋遼關係緊張"]
}
}
# AI可以回答:如果蕭峯沒有去雁門關,後續會如何發展?
🧠 創意2:動態Working Memory世界背景
利用MemCube的working memory功能,讓世界背景隨着劇情發展實時更新:
# 示例:動態世界狀態管理
from memos.memories.textual.base import TextualMemoryItem
# 創建世界狀態記憶項
world_state_memories = [
TextualMemoryItem(
memory="宋遼政治緊張程度達到0.8級別,邊境衝突頻發",
metadata={"type": "world_state", "category": "politics"}
),
TextualMemoryItem(
memory="當前江湖流傳的絕世武功:九陽神功、易筋經",
metadata={"type": "world_state", "category": "martial_arts"}
),
TextualMemoryItem(
memory="少林與武當保持中立,丐幫內部出現分裂",
metadata={"type": "world_state", "category": "sect_relations"}
)
]
# 使用MemCube的文本記憶管理世界狀態
mem_cube.text_mem.replace_working_memory(world_state_memories)
# 當蕭峯做出重要決定時,自動更新工作記憶
current_working_memory = mem_cube.text_mem.get_working_memory()
0x04 記憶生產流程
當一條消息進入系統時,它是如何被加工成記憶,並在未來對話中被有效使用的?
MemOS 的記憶機制可以理解為一條完整的「工作流」:
你提交原始消息 → 對記憶進行加工生產 → 調度機制根據任務和上下文安排調用與存儲,並可動態調整記憶形態 → 在需要時被召回相關記憶注入為上下文或指令 → 同時由生命週期管理維持演化與更新。
即:記憶生產 → 記憶調度 → 記憶召回與指令補全 → 記憶生命週期管理
比如:構建一個基於《天龍八部》小説的智能記憶分析系統,實現從原始文本到結構化記憶的完整轉換流程。數據處理流水線如下:
- 文本預處理 → 章節切分 → 結構化輸入
- AI驅動抽取 → 人物建模 → MemCube生成
- 格式轉換 → 圖結構構建 → MemOS記憶庫
0x05 常見問題
Q:MemOS 和普通 RAG 框架有什麼區別?
|
對比維度 |
RAG |
MemOS |
MemOS 的優勢 |
|
精準度
|
語料越多,噪聲越大
|
通過生產階段的抽取、圖式化/關係建模,再配合調度與生命週期管理,形成結構化組織,記憶條理更清晰
能夠基於用户反饋驅動自我進化
|
更準:減少噪聲,降低幻覺 |
|
結果組織
|
直接拿原文段落,內容冗餘
|
將原始信息加工為記憶,提煉成事實/偏好等單元,內容更短、更純粹
|
更省:同等信息量下更少 token |
|
搜索範圍
|
每次都在全量語料裏搜,語料越大越慢
|
記憶動態更新,分層管理,逐層召回
|
更快:避免全局掃描,小範圍命中 |
|
理解力
|
不能從用户歷史對話中沉澱偏好(無個性化),僅依賴靜態知識庫的相似度匹配
|
會自動提取記憶做偏好建模,並在召回時轉化為可執行的指令,讓模型真正理解到位。
|
更懂:回答更貼近真實需求 |
Q:MemOS 可以和已有 RAG 或知識圖譜結合嗎?
可以結合。
- RAG 專注於 事實檢索與知識增強,讓模型“知道世界上有什麼”;
- MemOS 專注於 狀態管理與連續記憶,讓模型“知道你是誰、你想要什麼”。
兩者結合後能形成互補的智能結構:
🧠 RAG 提供外部知識,MemOS 提供內在記憶。
前者讓模型更聰明,後者讓模型更懂你。
在實踐中,MemOS 的記憶單元 可以與 RAG 的向量召回層 直接對接,也能調用外部知識圖譜。
區別在於——RAG 管理的是 靜態事實,而 MemOS 管理的是 隨時間演化的動態記憶。
換句話説:
- RAG 讓模型更像百科全書;
- MemOS 讓模型更像你長期相處的助手。
當兩者融合時,AI 就既能“知道世界”,也能“理解你”。
0xFF 參考
MemOS:一個為AI系統設計的記憶操作系統 唐國樑Tommy