MemOS 核心概念详解:MOS 编排层、MemCube 容器与三类记忆的协同进化机制

发布时间:2026/9/24 0:31:49
MemOS 核心概念详解:MOS 编排层、MemCube 容器与三类记忆的协同进化机制 人工智能大模型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 将记忆视为与计算、存储同等地位的一等资源围绕组织、存储、检索与治理四个维度为 LLM 与 AI Agent 构建结构化、可解释、可演进的记忆系统。本文以官方核心概念文档 docs/cn/open_source/home/core_concepts.md 为主体骨架结合仓库源码src/memos/mem_cube、src/memos/memories、src/memos/mem_os与示例代码逐层拆解 MOS 编排层、MemCube 记忆容器、参数记忆/激活记忆/明文记忆三类记忆类型以及混合检索、治理与生命周期等横切概念帮助你从概念到实现完整掌握 MemOS 的记忆架构与落地用法。概述MemOS 的四个核心构件官方核心概念文档将 MemOS 的知识体系归纳为四条主线后续所有模块与配置都围绕它们展开MOS记忆操作系统负责编排调度的核心层MemCube可插拔、可扩展的记忆容器记忆类型参数记忆、激活记忆、明文记忆横切概念混合检索、治理与生命周期等跨层机制。整体设计理念是记忆不是静态的数据堆积而是动态演化的知识系统——它可以被提炼、被缓存、被降级、被审计最终支撑智能体进行长远规划、复杂推理与持续自适应。MOS记忆操作系统定义MOS 是 MemOS 的编排调度层负责协调多个 MemCube 与各类记忆操作。它作为中间件将 LLM 与结构化、可解释的记忆系统连接起来以支持复杂的推理与规划任务。使用场景当您需要在用户、会话或智能体之间建立一致、可审计且可追溯的记忆工作流时应使用 MOS 进行统一调度。在源码层面MOS 对应 src/memos/mem_os/core.py 中的MOSCore类其类注释直接点明了职责定位The MOSCore (Memory Operating System Core) class manages multiple MemCube objects and their operations. It provides methods for creating, searching, updating, and deleting MemCubes, supporting multi-user scenarios.从实现细节看MOSCore具备以下几个与文档概念一一对应的能力多 MemCube 管理内部持有mem_cubes: OptimizedThreadSafeDict[str, GeneralMemCube]在多用户生产场景下使用线程安全字典为每个用户/会话分配并隔离独立的 MemCubesrc/memos/mem_os/core.py用户治理通过UserManager校验用户是否合法validate_user不存在的用户会直接抛出ValueError保证记忆工作流可审计、可追溯LLM 接入通过LLMFactory.from_config(config.chat_model)初始化聊天模型使 MOS 成为连接 LLM 与记忆系统的中间件记忆读取与调度挂载MemReaderFactory构建的记忆读取器并可通过enable_mem_scheduler配置项启用 MemScheduler由调度器在后台统一执行记忆的添加、检索、偏好抽取等任务任务标签定义于 src/memos/mem_scheduler/schemas/task_schemas.py。MemCube可插拔的记忆容器定义MemCube 是 MemOS 中的可插拔、可扩展记忆容器。每个用户、会话或任务均可分配独立的 MemCube其中可承载一种或多种类型的记忆。使用场景随着系统规模增长可通过配置不同的 MemCube 实现记忆的隔离、复用与水平扩展。从抽象基类到通用实现仓库中定义了抽象基类 src/memos/mem_cube/base.py它规定了每个 MemCube 必须包含四种记忆槽位属性类型对应记忆text_memBaseTextMemory明文记忆含普通文本与偏好记忆act_memBaseActMemory激活记忆KV Cache / 隐藏状态para_memBaseParaMemory参数记忆模型权重 / LoRApref_memBaseTextMemory偏好记忆一种特殊明文记忆同时基类声明了load(dir)与dump(dir)两个抽象方法使记忆容器具备持久化能力。具体实现位于 src/memos/mem_cube/general.py 的GeneralMemCube它通过MemoryFactory.from_config(...)按配置实例化四类记忆并实现了完整的生命周期操作load(dir, memory_types)从目录加载记忆。加载前会校验目录内config.json的model_schema与当前配置是否一致不一致则抛出ConfigurationError防止加载错误版本的记忆src/memos/mem_cube/general.pydump(dir, memory_types)将记忆导出到目录。注意 dump 目标目录必须为空否则抛出MemCubeError避免覆盖已有数据导出时会先写入config.json再写入各记忆文件init_from_dir(dir)从本地目录创建 MemCube支持传入default_config与已有配置合并merge_config_with_defaultinit_from_remote_repo(cube_id, base_url)从远程仓库默认 Hugging Face Datasets下载记忆并初始化实现记忆的跨环境复用。四个记忆槽位的类型校验同样严格例如text_mem的 setter 会校验传入值必须是BaseTextMemory实例否则抛出TypeError。示例代码速览仓库在 examples/mem_cube 提供了两个可直接运行的示例dump_cube.py构造一个GeneralMemCube并导出到目录生成config.json与各记忆文件load_cube.py从已导出的目录中恢复 MemCube 并执行检索查询。与之配套的样例数据位于 examples/data/mem_cube_2其中包含activation_memory.pickle激活记忆文件文件名与BaseActMemoryConfig.memory_filename默认值一致与parametric_memory.adapter参数记忆文件直观展示了 MemCube 目录结构的真实形态。三类记忆类型MemOS 将记忆分为三类每一类对应不同的知识载体与生命周期策略记忆类型描述何时使用参数记忆内化至模型权重的知识常青技能、稳定领域专业知识激活记忆可复用的 KV 缓存与隐藏状态对话中的快速重用、多轮会话明文记忆文本、文档、图节点、工具或偏好等可搜索、可检查、演进知识参数记忆定义参数记忆指固化在模型权重中的知识可视为模型的长期记忆。它始终在线为推理任务提供零延迟的知识支持。使用场景适用于稳定的领域知识、经过提炼的通用问题解法以及不易变化的操作技能。在源码中参数记忆对应 src/memos/memories/parametric 目录其配置类定义于 src/memos/configs/memory.pyBaseParaMemoryConfig默认将记忆文件命名为parametric_memory.adapterLoRAMemoryConfigLoRA 参数记忆实现要求extractor_llm.backend必须为huggingface或huggingface_singleton否则抛出ConfigurationError——因为参数记忆的提炼本质上是把高频知识微调进模型权重。需要说明的是从源码结构看BaseParaMemorysrc/memos/memories/parametric/base.py当前仍是占位实现文件头部明确标注 This file currently serves as a placeholder因此在当前版本中参数记忆以架构设计与配置通道为主尚未提供完整可运行的后端实现。激活记忆定义激活记忆是模型可复用的工作记忆包括预先计算的键值缓存KV Cache与隐藏状态可直接注入注意力机制中避免对重复内容的重复编码。为什么重要将稳定的上下文信息如产品说明、操作指南以 KV Cache 形式存储可大幅降低首词元延迟TTFT并提升多轮对话与检索增强生成RAG的吞吐效率。何时使用在连续查询中复用背景知识加速基于固定上下文的对话系统配合 MemScheduler 将高频明文记忆自动转换为 KV 缓存。源码中激活记忆位于 src/memos/memories/activation其配置类KVCacheMemoryConfig将记忆文件命名为activation_memory.pickle并要求extractor_llm.backend必须是huggingface、huggingface_singleton或vllm之一src/memos/configs/memory.py——这正对应 KV Cache 的生成需要本地模型推理引擎这一前提。BaseActMemorysrc/memos/memories/activation/base.py定义了extract、add、get、get_by_ids、get_all、delete、delete_all等完整接口。仓库提供了两种后端示例kv_cache_memory.py基于 Hugging Face 模型生成并复用 KV Cachevllm_kv_cache_memory.py基于 vLLM 推理引擎实现面向高吞吐生产场景。明文记忆定义结构化或非结构化的知识单元具有用户可见性和可解释性。除了传统的文档、聊天日志、图节点和向量嵌入外MemOS 还将以下内容视为明文记忆工具记忆Tool Memory包括工具的定义Schema和使用轨迹Trajectory用于增强智能体Agent的工具调用能力偏好记忆Preference Memory显式或隐式的用户偏好用于个性化推荐和响应。使用场景适用于语义搜索、个性化体验构建、复杂任务的工具增强以及随时间演进的可追溯事实。支持标签、来源追踪和完整的生命周期管理。明文记忆在源码中对应 src/memos/memories/textual抽象基类 src/memos/memories/textual/base.py 定义了极为完整的接口extract从对话中抽取记忆、add、update、search、get、get_by_ids、get_all、delete、delete_all、drop。明文记忆的多种后端根据 src/memos/configs/memory.py 中的配置定义明文记忆提供多种实现后端配置类特征对应实现NaiveTextMemoryConfig仅需抽取 LLM简单存储naive_textual_memory.pyGeneralTextMemoryConfig需要vector_db与embedder向量化存储general_textual_memory.pyTreeTextMemoryConfig基于图数据库Neo4j的树状记忆tree_textual_memory.py其中TreeTextMemorysrc/memos/memories/textual/tree.py是最具 MemOS 特色的实现它同时挂载extractor_llm与dispatcher_llm双 LLM、EmbedderFactory生成的嵌入器、GraphStoreFactory创建的 Neo4j 图存储并通过MemoryManager维护三层记忆容量memory_size默认值WorkingMemory: 20、LongTermMemory: 1500、UserMemory: 480支持reorganize记忆重组开关与可选联网检索器internet_retriever。偏好记忆Preference Memory偏好记忆作为明文记忆的特殊形态在仓库中有独立实现目录 src/memos/memories/textual/prefer_text_memory内部按职责拆分为extractor.py从对话中抽取显式/隐式偏好adder.py与retrievers.py偏好的写入与检索spliter.py与utils.py偏好文本切分与工具函数。示例 pref_textual_memory.py 演示了偏好记忆的抽取、存储与个性化检索的完整链路。偏好记忆的配置由 src/memos/mem_reader/read_pref_memory 与 MemReader 协同支持显式偏好用户明说与隐式偏好从行为中推断两类来源。它们如何协同工作记忆的生命周期循环MemOS 的核心价值在于让三种记忆类型在生命周期循环中流动起来提炼过程高频使用的明文记忆可被蒸馏为参数记忆提升推理效率。这对应 MemScheduler 中的记忆管理模块——从源码结构看src/memos/mem_scheduler/memory_manage_modules 内置了 10 个记忆管理子模块负责高频记忆的识别与提炼调度缓存优化常见推理路径可固化为可复用的 KV 模板减少重复计算。即通过激活记忆将稳定的上下文预编码为 KV Cache配合 MemScheduler 将高频明文记忆自动转换为 KV 缓存降级归档使用频率降低的参数或激活记忆可降级为明文存储便于审计与再训练形成可审计、可再训练的知识闭环。借助 MemOS您的 AI 系统不仅能存储信息更能实现持续记忆、深度理解和自主进化。系统洞察随着时间的推移频繁使用的明文记忆可以提炼为参数记忆低频参数或缓存则可归档为明文形成闭环。横切概念混合检索结合向量相似性检索和图遍历算法实现稳健且具有上下文感知能力的混合搜索。在实现层面TreeTextMemory默认采用cosine_local后端重排序器RerankerConfigFactory默认level_weights为{topic: 1.0, concept: 1.0, fact: 1.0}并可选启用 BM25 稀疏检索EnhancedBM25通过search_strategy[bm25]开关控制——从源码结构看src/memos/memories/textual/tree_text_memory/retrieve 目录汇集了searcher.py、advanced_searcher.py、bochasearch.py、bm25_util.py、reranker.py等多种检索与重排实现并可挂载联网检索器internet_retriever_factory.py支持 Tavily、XinYu 等后端正是向量 图遍历 稀疏检索混合策略的落地载体。同时 MemOS 支持 MMR最大边际相关性候选剪枝相关测试见 tests/api/test_mmr_candidate_pruning.py。治理与生命周期每个记忆单元都具备完整的生命周期状态激活、合并、归档并支持来源跟踪和细粒度访问控制这对满足审计和数据合规性要求至关重要。从源码看明文记忆的元数据结构TextualMemoryMetadata、TreeNodeTextualMemoryMetadata定义于 src/memos/memories/textual/item.py为记忆单元携带来源与层级信息MemCube 的load过程中的 schema 一致性校验config.model_schema比对则从容器层面保证了记忆版本的可追溯性MOSCore的UserManager.validate_user提供了用户级的访问控制前置校验。合规提示请确保对每个记忆单元的来源与状态变更进行完整记录以符合数据治理与审计规范。关键要点MemOS 为您的 LLM 应用提供结构化、可演进、可治理的记忆系统分层清晰MOS 编排层统一调度、MemCube 容器承载隔离、三类记忆各司其职动态演化记忆在明文 → 参数/KV 缓存之间双向流动提炼、缓存、降级形成闭环可治理来源追踪、状态机生命周期、schema 校验与用户鉴权共同支撑审计与合规混合检索向量相似性 图遍历 稀疏检索BM25的组合保障检索的稳健性与上下文感知能力。这些机制使智能体能够进行长远规划、复杂推理与持续自适应为下一代 AI 应用释放真正的潜力。继续深入源码可以从 src/memos/mem_cube/general.py 的 MemCube 生命周期、src/memos/mem_os/core.py 的 MOS 编排逻辑以及 examples/mem_cube 的可运行示例开始动手验证。赞分享人工智能大模型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 核心概念完全解读MOS、MemCube 与三类记忆的协作机制MemOS 核心概念完全解读MOS、MemCube 与三类记忆的协作机制 MemOS 是一个将记忆作为一等公民first class citizen设人工智能大模型Agent 记忆AI AgentRAG知识图谱dsh-pluginKubernetes核心概念Pod与容器编排机制详解Kubernetes核心概念Pod与容器编排机制详解 本文深入解析Kubernetes最核心的调度单元Pod的设计理念与架构详细剖析容器运行时接口 CRI教程云原生容器编排MemOS MemCube 记忆容器全解析三种记忆的统一管理、View 架构与持久化实战MemOS MemCube 记忆容器全解析三种记忆的统一管理、View 架构与持久化实战 MemCube记忆收纳箱是 MemOS 中负责统一管理明文记忆、人工智能大模型Agent 记忆AI AgentRAG知识图谱dsh-plugin创作声明:本文部分内容由AI辅助生成(AIGC),仅供参考