MemOS 记忆操作系统：把 LLM 记忆变成可调度、可解释的一级系统资源

• 人工智能
• 大模型
• Agent 记忆
• AI Agent
• RAG
• 知识图谱
• dsh-plugin

MemOS是本仓库中面向大语言模型（LLMs）与智能体（Agents）构建的记忆操作系统：它把记忆从"藏在模型权重里的不透明层"重新定义为"具有统一结构、生命周期管理与调度逻辑的核心模块化系统资源"，并提供基于 Python 的实现层，位于 LLM 与外部知识源之间，实现持久化、结构化、可解释的高效记忆操作。阅读本文你将掌握 MemOS 的核心设计（MemCube、记忆生命周期、三类记忆融合）、三大治理模块的职责划分、多视角记忆的演进机制，以及MOSCore在源码中的实际调度实现与配置方式，从而能够理解并评估它在对话代理、企业 Copilot 与多代理协作系统中的落地方案。

为什么需要 MemOS？

随着 LLMs 处理的任务日益复杂——多轮对话、长期规划、决策制定、个性化用户体验——仅靠模型自身的"先天记忆"已不足以支撑真正长期、自适应的智能。当前主流 LLM 严重依赖静态参数化记忆（模型权重），这带来一系列硬伤：

• 知识更新成本高：刷新知识需要重新训练或微调，代价高昂；
• 行为脆弱：上下文窗口之外的长期信息容易丢失，用户偏好难以积累；
• 个性化有限：无法针对单个用户沉淀可演进、可追溯的偏好与事实。

典型的向量检索（RAG）能够检索外部事实，却缺乏统一治理、生命周期控制和跨代理共享能力。MemOS 正是为弥合这一差距而设计：它的定位是"记忆的操作系统"——就像操作系统调度 CPU、RAM 和文件一样，MemOS调度、转换和治理多种记忆类型，从参数化权重到临时缓存，再到明文、可追溯的知识。从源码结构看，这一理念的核心载体是MOSCore（位于 src/memos/mem_os/core.py），它被定义为"管理多个 MemCube 对象及其操作"的操作系统层，负责创建、搜索、更新、删除 MemCube，并支持多用户场景。

核心构建模块：MemCube

MemCube是 MemOS 中最基础的概念——一个灵活的容器，可容纳一种或多种记忆类型。每个用户、会话或代理都可以拥有自己的 MemCube，且 MemCube 是可交换、可重用、可追溯的。

在源码中，GeneralMemCube 是这一容器的具体实现，它在初始化时按配置构建四类记忆子模块：

MemCube 提供两个关键能力（见 general.py 中load/dump实现）：

• dump(dir)：将配置（默认写为config.json）与指定类型的记忆持久化到目录；若目标目录非空会抛出MemCubeError以避免覆盖；
• load(dir)：从目录恢复记忆，加载前会校验配置 schema 与当前配置是否一致，不一致会抛出ConfigurationError；
• init_from_dir(dir)/init_from_remote_repo(cube_id)：分别支持从本地目录和远程仓库（默认从 HuggingFace datasets 下载）初始化 MemCube——这正是"可交换、可重用"的来源：一个 MemCube 可被导出、分享、再导入。

记忆生命周期：生成 → 激活 → 合并 → 归档 → 冻结

MemOS 为每个记忆单元定义了显式的状态机：生成 → 激活 → 合并 → 归档 → 冻结。

• 生成（Generation）：记忆被提取/创建，例如对话中被识别出的值得记住的事实；
• 激活（Activation）：记忆进入活跃使用状态，用于检索和推理复用；
• 合并（Merge）：相近或重复的记忆被合并，控制记忆规模；
• 归档（Archive）：低频记忆被降级归档，减少检索噪声；
• 冻结（Freeze）：过时或不再使用的记忆被冻结，不再参与常规检索。

文档强调：每一步都通过来源跟踪（provenance tracking）和审计日志进行版本控制。旧记忆可以像"时间机器"一样回退到之前的版本，用于恢复或反事实模拟。这也是"每个记忆单元都携带完整来源元数据，因此可以审计谁创建、修改或查询了它"的合规性设计基础。

从仓库结构看，生命周期与调度相关的实现集中在 src/memos/mem_scheduler/ 与 src/memos/mem_feedback/：前者包含memory_manage_modules（激活记忆管理、后处理、检索器等）、monitors（调度监控）、task_schedule_modules（任务调度/编排）；后者提供基于 LLM 分类器的记忆反馈闭环，用于驱动记忆的合并、演化与降级。

操作与治理：三大模块

MemOS 将记忆操作与治理拆分为三个并列模块：

• MemScheduler— 动态转换记忆类型以实现最优复用。源码中对应 GeneralScheduler 与 BaseScheduler：它维护调度任务队列（可选 Redis 队列）、Dispatcher 并行分发、Monitor 监控与 Retriever 检索，并提供enable_activation_memory、top_k、context_window_size、consume_interval_seconds等调度超参数；
• MemLifecycle— 管理状态转换、合并和归档。对应memory_manage_modules中的ActivationMemoryManager（周期性地把稳定上下文提升为激活记忆）、MemoryPostProcessor（记忆增强与过滤）等；
• MemGovernance— 处理访问控制、编辑、合规性和审计跟踪。对应 UserManager 与 MOSCore 中的访问控制逻辑：create_user、validate_user_cube_access、create_cube_for_user、share_cube_with_user等接口共同实现"谁可以访问哪个 MemCube"的权限模型，而记忆单元携带的来源元数据则支撑审计。

在 MOSCore 中，调度器的启停是显式可控的：mem_scheduler_on()/mem_scheduler_off()用于动态开关调度服务；配置项enable_mem_scheduler决定初始化时是否构建调度器，构建后SchedulerFactory.from_config(scheduler_config)会以聊天 LLM、处理 LLM 与用户数据库引擎初始化各子模块并启动。

多视角记忆：三类记忆的融合与演进

MemOS 在生命周期中融合三种记忆形式，这是它区别于纯 RAG 或纯微调方案的核心设计：

仓库中三类记忆分别有独立实现目录：src/memos/memories/parametric/（lora.py）、src/memos/memories/activation/（kv.py、vllmkv.py）与 src/memos/memories/textual/（naive.py、general.py、tree.py、preference.py等）。其中明文记忆的tree_textbackend 进一步引入图数据库（Neo4j 等）、reranker、互联网检索器与memory_size桶容量配置（如{"WorkingMemory": 20, "LongTermMemory": 10000, "UserMemory": 10000}），用于构建结构化、可解释的树状记忆。

三类记忆之间是动态演进的，而非静态并存：

• 频繁使用的明文记忆可以提炼为参数化权重（写入 LoRA adapter）；
• 稳定的上下文被提升为 KV cache 以快速注入（见ActivationMemoryManager.update_activation_memory_periodically）；
• 使用频率低或过时的知识可以被降级（归档/冻结）。

这一演进机制意味着：MemOS 中的记忆不是"存了就完"，而是随着使用模式持续流动与再组织。

MOSCore：源码中的记忆操作系统层

src/memos/mem_os/core.py 中的MOSCore是"记忆操作系统"理念在代码层的直接体现。它管理多个 MemCube 实例，向应用层暴露统一操作入口：

• chat(query, user_id, base_prompt)：检索可访问 MemCube 中的明文记忆（支持top_k与对话历史注入），构建带记忆上下文的 system prompt（可用{memories}占位符定制），生成回答；若启用激活记忆且聊天后端为 HuggingFace 系，会将 KV cache 作为past_key_values注入生成；
• search(query, user_id, install_cube_ids, top_k, mode, internet_search, moscube, session_id)：跨用户可访问的所有 MemCube 并行检索明文记忆与偏好记忆，返回包含text_mem、act_mem、para_mem、pref_mem四类结果的MOSSearchResult；支持session_id过滤与fast/fine两种检索模式；
• add(messages, memory_content, doc_path, mem_cube_id, ...)：支持从对话消息、单条记忆文本、本地文档目录（自动递归收集.txt/.pdf/.json/.md/.ppt/.pptx）三种来源写入明文与偏好记忆；text_mem.mode为async时依赖 MemScheduler 异步落库；
• get/update/delete/delete_all：按memory_id对记忆做查询、修改与删除，均先校验用户对 MemCube 的访问权；
• dump/load：将整个 MemCube 持久化或恢复，支持按memory_types选择性导出；
• 用户与共享管理：create_user、register_mem_cube、unregister_mem_cube、share_cube_with_user等接口支撑多用户与跨代理记忆共享。

这些方法共同回答了文档提出的核心主张：像操作系统调度 CPU 和内存一样，MemOS 通过统一的MOSCore层调度、转换和治理不同记忆类型。

配置一览：MOSConfig 与 MemCube 配置

MOSCore的行为由 src/memos/configs/mem_os.py 中的MOSConfig定义，关键参数如下：

MemCube 级配置在 src/memos/configs/mem_cube.py 中定义（cube_id、text_mem/act_mem/para_mem/pref_mem四组 backend），并在MemoryConfigFactory（src/memos/configs/memory.py）处完成 backend 合法性校验与具体配置类的构造。对tree_text明文记忆，还可配置图数据库（graph_db）、reranker、互联网检索器（internet_retriever）、重组开关（reorganize）、各记忆桶容量（memory_size）与检索策略（search_strategy，如{"bm25": true, "cot": false}）。

MemOS 有什么不同？

综合文档定位与仓库实现，MemOS 的差异化能力可归纳为五点：

1. 混合检索— 符号与语义混合、向量与图混合检索（tree_textbackend 同时接入向量库与图数据库，并提供bm25、Chain-of-Thought 等检索策略选项）；
2. 多代理与多用户图— 私有与共享记忆图，通过UserManager的 MemCube 访问控制实现；
3. 来源与审计跟踪— 每个记忆单元都被治理和可解释，可追溯创建/修改/查询者；
4. 自动 KV cache 提升— 稳定上下文被周期性提升为激活记忆以复用（ActivationMemoryManager）；
5. 记忆生命周期调度— 通过 MemScheduler 主动调度记忆转换，减少陈旧事实或臃肿权重带来的调用负担。

适合谁？

MemOS 面向四类典型使用者：

• 需要多轮、演进记忆的对话代理——跨会话保留用户上下文与偏好；
• 处理合规性、领域更新和个性化的企业级 Copilot——来源元数据与审计日志支撑合规要求；
• 在共享知识图上协作的多代理系统——MemCube 的创建、注册与共享机制天然适配多代理场景；
• 想要模块化、可查记忆而不是黑盒提示的 AI 构建者——三类记忆 + MemCube 的统一容器让记忆可加载、可保存、可通过 API 访问。

关键要点

MemOS 将 LLM 从"只是预测 tokens"升级为可以记忆、推理和适应的智能演进系统。它的核心主张可以概括为：把记忆当作操作系统的一级资源来管理——用 MemCube 作为统一容器，用生命周期状态机（生成→激活→合并→归档→冻结）管理记忆流动，用 MemScheduler / MemLifecycle / MemGovernance 三个模块完成调度、转换与治理，最终让 AI 系统不仅存储事实，而且随使用持续演进。对于希望在对话代理、企业 Copilot 与多代理系统中构建可解释、可审计、可演进记忆能力的开发者，docs/cn/open_source/home/memos_intro.md 是理解整体设计的最佳起点，而 src/memos/mem_os/core.py、src/memos/mem_cube/general.py 与 src/memos/mem_scheduler/ 则是深入其实现细节的推荐阅读路径。

• 人工智能
• 大模型
• Agent 记忆
• AI Agent
• RAG
• 知识图谱
• dsh-plugin