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

人工智能大模型Agent 记忆AI AgentRAG知识图谱dsh-plugin【免费下载链接】MemOSSelf-evolving memory OS for LLM AI Agents: ultra-persistent memory, hybrid-retrieval, and cross-task skill reuse, with 35.24% token savings and DeepSeek Harness support.项目地址https://gitcode.com/gh_mirrors/memos/MemOS点击查看免费下载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并支持多用户场景。核心构建模块MemCubeMemCube是 MemOS 中最基础的概念——一个灵活的容器可容纳一种或多种记忆类型。每个用户、会话或代理都可以拥有自己的 MemCube且 MemCube 是可交换、可重用、可追溯的。在源码中GeneralMemCube 是这一容器的具体实现它在初始化时按配置构建四类记忆子模块子模块属性名承载的记忆类型允许的 backend由 src/memos/configs/mem_cube.py 校验明文记忆text_mem文本、文档、向量块naive_text、general_text、tree_text、uninitialized偏好记忆pref_mem用户显式偏好pref_text、uninitialized激活记忆act_memKV cache 等推理态kv_cache、vllm_kv_cache、uninitialized参数记忆para_memLoRA 适配器lora、uninitializedMemCube 提供两个关键能力见 general.py 中load/dump实现dump(dir)将配置默认写为config.json与指定类型的记忆持久化到目录若目标目录非空会抛出MemCubeError以避免覆盖load(dir)从目录恢复记忆加载前会校验配置 schema 与当前配置是否一致不一致会抛出ConfigurationErrorinit_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 或纯微调方案的核心设计类型描述用例参数记忆Parametric Memory知识提炼到模型权重中如 LoRA 适配器常青技能、稳定领域事实激活记忆Activation Memory用于推理复用的 KV caches 和隐藏状态快速多轮聊天、低延迟生成明文记忆Textual Memory文本、文档、图、向量块、用户可见事实语义搜索、演进、可解释记忆仓库中三类记忆分别有独立实现目录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定义关键参数如下配置项默认值说明user_idroot区分不同用户记忆的用户 IDsession_id随机 UUID区分不同对话会话chat_model—聊天 LLM 配置mem_reader—记忆读取/抽取器配置mem_schedulerNone记忆调度器配置可选user_managersqlite 后端用户与 MemCube 权限数据库max_turns_window15对话历史保留的最大轮数top_k5每次查询检索的最大记忆条数enable_textual_memoryTrue启用明文记忆enable_activation_memoryFalse启用激活记忆KV cacheenable_parametric_memoryFalse启用参数记忆LoRAenable_preference_memoryFalse启用偏好记忆enable_mem_schedulerFalse启用记忆调度器PRO_MODEFalse复杂查询分解的 PRO 模式MemCube 级配置在 src/memos/configs/mem_cube.py 中定义cube_id、text_mem/act_mem/para_mem/pref_mem四组 backend并在MemoryConfigFactorysrc/memos/configs/memory.py处完成 backend 合法性校验与具体配置类的构造。对tree_text明文记忆还可配置图数据库graph_db、reranker、互联网检索器internet_retriever、重组开关reorganize、各记忆桶容量memory_size与检索策略search_strategy如{bm25: true, cot: false}。MemOS 有什么不同综合文档定位与仓库实现MemOS 的差异化能力可归纳为五点混合检索— 符号与语义混合、向量与图混合检索tree_textbackend 同时接入向量库与图数据库并提供bm25、Chain-of-Thought 等检索策略选项多代理与多用户图— 私有与共享记忆图通过UserManager的 MemCube 访问控制实现来源与审计跟踪— 每个记忆单元都被治理和可解释可追溯创建/修改/查询者自动 KV cache 提升— 稳定上下文被周期性提升为激活记忆以复用ActivationMemoryManager记忆生命周期调度— 通过 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 AgentRAG知识图谱dsh-plugin【免费下载链接】MemOSSelf-evolving memory OS for LLM AI Agents: ultra-persistent memory, hybrid-retrieval, and cross-task skill reuse, with 35.24% token savings and DeepSeek Harness support.项目地址https://gitcode.com/gh_mirrors/memos/MemOS点击查看免费下载相关推荐自动化构建docker-alpine-java镜像generate_dockerfiles.sh脚本完全指南自动化构建docker alpine java镜像generate_dockerfiles.sh脚本完全指南 在容器化部署的时代高效构建轻量级Java环境至MemOS 2.0 记忆操作系统实战指南统一记忆 API、Docker 自托管与 OpenClaw/Hermes/DeepSeek Harness 插件生态MemOS 2.0 记忆操作系统实战指南统一记忆 API、Docker 自托管与 OpenClaw/Hermes/DeepSeek Harness 插件生态人工智能大模型Agent 记忆AI AgentRAG知识图谱dsh-pluginMemOS 贡献指南实战从零开始参与 LLM 记忆操作系统开发MemOS 贡献指南实战从零开始参与 LLM 记忆操作系统开发 导读 本文基于 MemOS 仓库根目录的 CONTRIBUTING.md https://li人工智能大模型Agent 记忆AI AgentRAG知识图谱dsh-plugin创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考