让 LLM 拥有“可治理的记忆”：MemOS：A Memory OS for AI System 论文解读

随着大语言模型（LLM）能力的持续扩展，研究者和开发者逐渐意识到，若要真正迈向通用人工智能（AGI），模型不仅需要强大的语言生成能力，更应具备长期一致性、知识演化能力与用户个性化适配能力。因此，越来越多的系统开始尝试将 LLM 作为智能体（Agent）进行封装，并探索其在多轮对话、长期任务、知识积累等真实场景中的表现。

然而，当前主流大语言模型在实践中仍面临几项核心瓶颈： 1. 上下文无限膨胀：为了控制窗口长度，我们必须丢弃历史信息；但一旦窗口装不下所有关键信息，模型就会“遗忘”重要的事实。 2. 知识个性化与时效性失效：主流 LLM 以参数形式封装知识，无法实时更新，也难以追踪用户偏好与行为风格。即使在某一轮对话中进行纠错或提示，后续生成中仍可能重复相同错误。这使得模型难以具备真正“可学习”的人格与行为连贯性

尽管 Retrieval-Augmented Generation（RAG）作为主流增强手段，在一定程度上缓解了知识时效性问题，它本质上仍是一种无状态、非统一的“按需检索”机制。论文明确指出，RAG 缺乏生命周期管理、版本控制、访问权限及演化机制，不能承担持久性认知系统的核心职责。

MemOS 正是在此背景下提出的系统级方案。论文将“记忆”首次明确视为一种可调度（Schedulable）、可控（Controllable）、可演化（Evolvable） 的系统资源，主张通过类似操作系统（OS）对计算资源统一管理的方式，构建一个面向记忆治理的抽象层。通过引入统一的 Memory API、结构化的 MemCube 记忆单元与三类记忆路径（Plaintext / Activation / Parameter），MemOS 使得 LLM 系统能够跨时间、跨任务、跨用户管理、迁移与融合异构知识资源，为构建具备持续学习与个性化能力的智能体系统提供了基础设施支持。

记忆系统的进化：从混沌到治理

在构建具备长期任务能力和个性化响应能力的语言智能体过程中，记忆系统已成为不可回避的核心组件。如何设计一个既支持灵活扩展，又具备演化与治理能力的记忆体系，已成为制约大模型持续应用能力的关键。

为此，论文《MemOS: A Memory OS for AI System》提出了一个系统性框架：将“记忆”作为模型内外部的基础资源进行治理与调度，并借鉴传统操作系统的结构进行建模。在介绍 MemOS 之前，论文对 LLM 记忆研究的演化路径进行了系统性划分，归纳为以下四个阶段：

1. 定义与探索阶段（Definition & Exploration）初期研究聚焦于对 LLM 记忆形式的观察与分类，例如参数型记忆（Parameter Memory）、非参数型上下文（Textual Memory）、短期状态缓存（KV-cache）等。该阶段的重点是理解模型内部是如何“记住”知识的。
2. 类脑记忆阶段（Human-like Memory）受人类认知结构启发，研究者尝试构建多层级、多通道的记忆组件。例如，模仿“海马体–新皮层”结构的 HippoRAG 模型，将记忆划分为长期知识与快速索引。同时，也探索记忆的生成、联想、再激活等动态行为。
3. 工具化阶段（Tool-based Management）工程上开始出现显式操作模型记忆内容的机制，如 EasyEdit 支持对参数层进行定向编辑，Mem0 引入了上下文内外显式记忆模块。但整体上各方案互不兼容，缺乏统一的生命周期控制与权限治理能力。
4. 系统治理阶段（Systematic Memory Governance）以 MemOS 为代表，首次将“记忆”视为一种可调度、可演化、可控制的系统资源（Schedulable, Evolvable, Controllable）。在此框架中，记忆拥有完整的生命周期、权限模型、结构抽象与行为指标，具备系统级的调度与治理能力，标志着从“功能工具”向“系统内核”的转变。

为什么说 MemOS 是“操作系统”？

MemOS 的设计核心，在于将传统操作系统中对计算资源的管理思想，映射到 LLM 的记忆管理中。如下表所示，论文明确构建了一组结构对应关系：

通过上述结构设计，MemOS 实现了当前记忆系统中最关键的三项能力：

1. 统一抽象与封装（Abstraction）通过 MemCube，将多种类型的异构记忆（如 KV-cache、用户提示片段、LoRA patch 参数等）封装为结构一致的“可调度记忆单元”，支持跨模块、跨任务调用。
2. 动态调度与跨任务迁移（Scheduling & Transfer）依托 MemScheduler，系统能够根据当前任务上下文、记忆热度与任务语义结构，选择最适合的记忆类型，并支持在不同 Agent、会话或子任务间进行迁移与共享。
3. 版本管理与演化追踪（Versioning & Evolvability）每一个 MemCube 单元都具备版本链、上下文指纹与访问行为记录，支持记忆内容的版本控制、冲突回滚与历史恢复，使得记忆不再是静态缓存，而是具备演化能力的“智能资源单元”。

传统 RAG 或缓存机制，往往只能实现“在提示词中外挂一点知识”或“保留一点上下文状态”，缺乏治理能力和生命周期意识。而 MemOS 的提出，则代表着记忆系统不再是模型运行的附属工具，而是模型认知演化的基础设施核心。

这标志着我们正在从“让模型记住一些信息”，迈向“让模型管理自己的记忆”。

深入看看Memory Modeling：记忆如何成为可编排资源？

如果说 MemOS 的设计理念是“将记忆作为操作系统级别的资源”，那么它真正的系统亮点，在于如何将复杂、异构、多阶段的记忆，封装成可组合、可治理、可演化的最小资源单元，并在模型执行过程中动态调度与回收。

**1. 三种原生记忆：构建统一治理空间的原始素材

MemOS 首先明确划定了三类基础记忆类型，它们各自来源不同，但都被抽象进同一套记忆调度框架：

• Plaintext Memory：外部注入的结构化或非结构化信息，例如提示模板、图谱节点、用户笔记等，具备高度可编辑性，适合低成本快速更新。
• Activation Memory：推理过程中的中间状态（KV-cache、隐藏层激活），可实现上下文复用与长程依赖追踪，是高速工作记忆的主力形式。
• Parameter Memory：编码于模型权重或参数增量（如 LoRA、Adapter）的知识能力模块，推理效率高、冗余最少，适用于长期稳定能力表达。

这种划分，实质上覆盖了记忆的三个操作轴心：可编辑性（Editability）、可注入性（Injectability）、可压缩性（Compactness），为后续跨类型演化打下结构基础。

2. 动态演化：记忆类型的系统级转化路径

MemOS 并不将这三类记忆视为静态结构，而是建构了一个跨类型可演化的记忆闭环：

Plaintext ⇄ Activation ⇄ Parameter

系统根据调用频率、时间衰减、上下文耦合度等行为指标，对记忆进行热度建模，并据此自动触发跨类型迁移。论文称之为“跨模态演化机制（Cross-Modality Memory Transformation）”。

例如：

• 高频调用的 Plaintext 记忆片段可转化为 Activation Memory，直接以 KV-cache 形式注入模型，减少冗余前缀处理；
• 持续活跃的 Activation 可被系统后台调度转化为 Parameter Memory（如 distill 成 LoRA patch），从而释放上下文窗口；
• 冷却后的 Parameter 也可被解构回 Plaintext，重新回归易修改的表示形式。

这种闭环机制不仅提升了推理效率，更实现了知识的“热更新”与“冷淘汰”的统一治理。

3. MemCube：把一切记忆封装进“inode”

为实现跨类型统一调度，MemOS 提出了MemCube这一核心抽象。它类似于操作系统中文件的 inode，每个记忆单元不仅包含有效内容（Payload），还附带详细的结构化元数据（Metadata）：

• 内容部分可为文本片段、KV 张量或 LoRA patch；
• 元数据部分包括时间戳、调用计数、版本链、权限控制（ACL）、访问者、存储模式、敏感性标签、上下文指纹等。

这使得系统可以仅通过读取元数据，即可进行调度决策、版本回退、权限控制、冷存迁移等操作，形成“治理即调度”的资源框架。

📌 论文原文定义 MemCube 为：“a universal encapsulation unit for memory resources… with standardized interfaces, behavioral properties, and governance strategies.”

图片

4. MemScheduler：窗口内的记忆调度与替换策略

每次模型调用时，MemScheduler 会根据当前任务上下文、角色身份、token 限额，对候选 MemCube 进行优先级排序并选择注入路径。

排序逻辑主要由以下维度构成：

• 热度指标（调用频率 × 近期权重 × 上下文耦合）；
• 记忆类型偏好：Parameter > Activation > Plaintext（更压缩的优先）；
• 合规等级：例如敏感信息仅可注入到所属用户 session 中；
• Token 成本估计：避免窗口溢出，采取近似贪婪填充（论文未建模为严格 Bin-Packing，但行为等效）。

淘汰策略结合了 LRU（时间）与 LFU（频率）模型，不同类型可设定不同权重，例如 Activation 优先淘汰最近未用，而 Plaintext 更关注整体活跃度与内容时效性。

5. 治理逻辑：权限与合规不再靠业务实现

MemCube 的元数据中原生嵌入权限控制（ACL）、生命周期策略（TTL）、审计标记（Watermark）与版本链。这使得所有记忆资源都可在系统层面进行可控操作，而非依赖业务侧脚本。

举例而言：

• 系统可为敏感字段设定七天 TTL，到期后触发 soft-delete 标记，供审计系统备份；
• 所有操作将写入可查询的访问日志，支持审计追溯；
• 被标记为“deprecated”的知识块将在下次调用时自动降权或跳过调度。

6. 举个🌰

想象一下：法务同事刚刚整理完一份《数字人广告新规汇总》，通过 MemOS 提供的 Memory API 把它写进系统，设置 ACL 只允许“legal_team”读取，TTL 一年。三天后，市场部的智能体在撰写脚本时多次引用了这份新规，热度阈值被触发，它自动升格为 Activation，推理不再重新检索全文。再过一个月，这条法规依旧频繁出现，系统后台夜间作业把它蒸馏成 LoRA Δ——此后再也不占窗口 token，却始终在模型里“原生”生效。如果哪天法规废止，只要法务在后台把这一版 LoRA 标记为 deprecated，MemScheduler 会在下次装箱时自动回避；而旧版本的文本条目依旧可查，可审计，可回滚。

通过结构化建模三类记忆、封装成统一调度单元（MemCube），并基于使用行为驱动跨类型迁移，MemOS 实现了记忆系统从“外挂插件”向“操作系统资源”的根本跃迁。

这不仅是内存组织的技术进步，更是大模型迈向自我演化与系统治理的关键一步。

MemOS 三层架构剖析：将“记忆”纳入系统治理链条

论文《MemOS: A Memory OS for AI Systems》提出将“记忆”作为一级系统资源管理，类比于传统操作系统中的文件、进程与内存。这一理念的落地，依托于其清晰分层的架构设计。整个系统自上而下划分为三个功能层级：

Interface Layer（接口层） → Operation Layer（操作层） → Infrastructure Layer（基础设施层）

这一分层不仅提升了系统的可解释性和模块化，还使得记忆从输入解析到推理注入的全过程可被审计、可被回滚、可被调度。

图片

Interface Layer 接口层：自然语言如何变成系统指令

MemOS 中的接口层承接来自上层 Agent 或用户的自然语言请求。核心模块 MemReader 的职责，是将这些自然语言或半结构化输入解析为统一的内部指令格式 —— MemoryCall，该结构承担了类比系统调用 syscall 的角色，描述了本次请求的操作类型（读/写/更新/删除）、作用目标、调用方身份以及相关上下文信息。

📌 MemoryCall 是全系统调度的起点，其标准化封装为后续操作层与基础设施层的治理提供统一入口。

接口层同时还负责初步的合规验证，例如：

• 检查调用是否超出权限；
• 是否违反记忆 TTL 策略；
• 是否触发配额限制。

这一层的本质，是将模糊输入转换为系统可执行、可调度的 显式操作意图。

Operation Layer 操作层：记忆调度的大脑与神经**

该层负责所有关于“哪些记忆应被激活”“哪些应被淘汰”“哪些应迁移至冷存”的判断与执行逻辑，是 MemOS 的中枢控制单元。

MemOperator：构建记忆的多维索引图谱

MemOperator 为活跃的 MemCube 构建多模态索引： • 向量索引：用于模糊语义召回； • 关键词倒排索引：支持精确定位； • 图谱结构索引：维护实体之间的引用、依赖与上下游调用关系。

它像是系统的“知识图谱生成器”，让每一条记忆都能被快速访问、联动和理解。

MemScheduler：在有限窗口中做最优注入决策

推理窗口的 token 空间始终有限——不论是 8K、32K，还是未来的 128K，都只能容纳有限数量的记忆注入。

MemScheduler 会根据多维权重对每一个 MemCube 打分，包括： • 热度（访问频率、上下文相关性）； • 形态优先级（参数 > 激活 > 明文）； • 权限隔离策略（如用户私有数据优先注入到专属上下文）； • 存储滞留时间（防止“冷知识”长期霸占位置）；

该机制类比于 OS 中的分页调度或 cache eviction，论文未使用 bin-packing 的术语，但其 token-aware injection 策略本质类似于容量受限的资源调度问题。

MemLifecycle：为记忆定义清晰的生命周期

记忆并非一次性资源，而是一个“状态流转体”。

MemLifecycle 记录每个 MemCube 的完整生命周期：

ounter(line
Generated → Activated → Merged / Replaced → Archived → Purged

• Generated：被写入系统；
• Activated：被频繁使用；
• Merged：整合进长期结构化知识；
• Archived：冷藏等待再利用；
• Purged：软删除或物理销毁。

这保证了记忆调度的 可审计性与可回滚性，也支持数据治理场景如 TTL 到期自动清理、敏感数据销毁、历史版本追踪等。

Infrastructure Layer：冷热分层、权限审计，一座“记忆数据中心”

底层设施为整个 MemOS 提供资源支持与治理能力，主要由以下组件构成：

1. MemVault：支持冷热分层存储

根据热度和访问策略，MemVault 管理不同等级的存储后端：

• Hot KV Store：部署于 GPU HBM，供 KV 缓存类记忆低延迟访问；
• Warm Vector DB：NVMe 级别，用于高效检索型记忆；
• Cold Blob Store：S3、HDFS 等，用于归档长期低频知识。

所有 MemCube 的迁移只需“整体搬运”，索引与元数据不变，极大降低了迁移开销。

2. MemGovernance：系统级权限与合规控制

治理模块负责：

• TTL 到期后的自动软删 / 硬删；
• 敏感内容水印植入、泄露追溯；
• 权限控制与调用记录留痕。

无论是监管合规还是企业安全，都有了“系统级防线”。

3. MemLoader / Dumper & MemStore：记忆迁移与跨节点共享

这组组件负责记忆的跨设备、跨智能体同步与卸载。支持：

• 用户本地记忆向云端迁移；
• Agent 记忆打包迁移至其他模型；
• 不同角色/租户之间进行受控记忆共享。

虽论文未明示“记忆商品化”能力，但此类通用搬运机制为未来构建记忆即服务（Memory-as-a-Service）平台奠定了基础。

看个🌰

我们来看论文中的这张图，简单看下这三层架构是如何运作的。

图片

1. 用户输入自然语言 My dog needs help → 经 MemReader 封装为 MemoryCall，包含操作类型、意图关键词、调用者身份。
2. 操作层检索多个候选记忆（Plaintext + LoRA patch），并由 MemScheduler 评估其热度与适配性，最终确定注入对象。
3. 选定的记忆单元（如狗狗护理指南文本 + 宠物专家 LoRA patch）被注入模型完成响应生成。
4. 响应过程中的调用轨迹被写入记录，以供回溯与治理。

MemOS 三层结构清晰、模块分工明确。其最大创新，不在于新模型结构，而在于：将记忆视作可调度、可治理的“系统一级资源”，并在架构设计中贯彻执行路径、权限控制与数据生命周期管理。

它将以往散落在各工具和模型中的技巧（如 RAG、KV cache、LoRA patch）统一抽象为 MemCube，并纳入系统内核，实现真正意义上的“记忆操作系统”。

效果评估

MemOS 的系统设计理念虽新颖，但最终仍需落脚于实证效果。论文通过多个角度对其三大核心能力（长程推理能力、记忆调度智能性、系统响应效率）进行了详尽实验评估，主要分为四大部分：

一、在 LOCOMO 基准上的端到端推理测试

MemOS 在 LOCOMO 推理评估基准中接受端到端测试，任务覆盖：

• Single-hop 问答
• Multi-hop 复杂推理
• Open-domain 问答
• Temporal Reasoning 时间推理

评估指标使用 LLM-Judge（基于 GPT-4 的人工一致性打分），并辅以 BLEU、ROUGE-L、F1 分数与嵌入相似度衡量输出的语义保真度与风格一致性。

📈 结果分析：

• MemOS 在 Multi-hop 与 Temporal Reasoning 任务中显著超越 mem0、zep、langmem 等系统；
• 在 Single-hop 和 Open-domain 任务上则与最强对手差距较小，整体保持领先或并列第一；
• 嵌入余弦相似度在所有子任务中始终维持较高值（>0.95），显示出强一致性。

✅ 说明：MemOS 的长时记忆调度机制，能有效支持语境整合、事件链追踪与事实稳定性。

二、消融实验：记忆量对性能影响的定量分析

论文设计了两个关键变量消融实验：

• Memory Chunk Size：从小记忆块（128 tokens）增长至大块（1024 tokens）；
• Memory Top-K：从激活 10 条记忆增长至最多 80 条。

📊 观察结论：

• BLEU 与 ROUGE-L 随 memory 量稳步提升，且无明显过拟合或退化；
• 嵌入相似度曲线几乎保持水平，说明大量记忆注入未造成语义漂移；
• 显示 MemOS 的分层调度机制具备较强“记忆稳定性”。

三、系统响应效率：高负载下的稳定性对比

为了进一步验证 MemOS 的系统稳定性和扩展能力，作者将其与多种系统在相同条件下进行了横向对比：

系统对比 MemOS-0630 / mem0 / langmem / OpenAI Memory / 纯 RAG（不同配置） 评估指标 LLM-Judge 得分、检索延迟（P50 / P95）、总时延

结论一目了然： • MemOS 在 LLMJudge 得分上与“全上下文推理”持平甚至超出； • 同时，在延迟指标上（尤其是 P95），比其它方案低一个量级； • 即使同时管理超过 1500 个记忆单元，MemOS 的响应速度依然接近 mem0 这类轻量方案。

✅ 这说明：MemOS 的“按需激活 + 混合语义结构”策略，实现了精准召回与系统响应之间的平衡，无需一股脑加载上下文，也不牺牲推理质量。

四、KV 加速实验：让记忆进入“快速通道”

为了量化 KV 注入机制带来的性能提升，作者又构建了一个对照实验，评估 KV 激活机制对 TTFT（Time to First Token） 的加速能力。

测试模型涵盖： • Qwen3-8B • Qwen3-32B • Qwen2.5-72B

🚀 开启 KV 加速后，TTFT 大幅下降，且模型输出内容与关闭 KV 时保持完全一致，说明语义行为无偏差。

特别是在大模型 + 长上下文的场景下，性能提升尤为明显，对于 Qwen2.5-72B，在长上下文 + 短查询任务中，TTFT 降幅高达 91.4%！

结论明确：KV 激活机制是高性能、低延迟智能体运行的关键支点。

总的来说，MemOS 并非仅在模型外部“外挂记忆模块”，而是以操作系统式架构将记忆纳入 LLM 的核心调度路径，兼顾：

• 推理准确性（LLM-Judge + BLEU）；
• 响应实时性（TTFT + P95）；
• 行为一致性（CosSim + 语义稳定性）；

它展示了一个系统如何在不扩大 token 长度的前提下，实现真实智能体所需的“长期记忆 + 个性化响应”能力。

MemOS 如何落地？

在论文的最后一节，作者提出了两个关键性的系统设计理念，分别从“知识商品化”与“自动治理能力”两个维度，拓展了记忆管理的边界。这不仅是对“记忆即系统资源”理念的工程化落地，也为构建长期智能体生态提供了可执行的路线。

🧩 1. Paid Memory as Modular Installables

知识，也能像插件一样分发和变现。

在 MemOS 中，每一个具备结构化元信息的 MemCube 都可以被打包成可复用的知识模块，具备如下特征：

• 封装形式：包含明文内容、激活缓存或参数权重（如 LoRA Δ），并带有版本号、访问控制、标签体系；
• 加载机制：下游智能体无需了解内容细节，仅通过 MemoryCall(op="LOAD", source="pkg://legal.lo.ra") 形式调入；
• 托管能力：MemStore 与 MemGovernance 模块可对模块实现权限隔离、调用计费、更新广播与版本冻结等功能。

这一设计使得记忆的使用方式类比软件插件（Plug-in）：

• 企业可以打包合规知识、客户标签图谱为 LoRA 记忆模块，对内复用或对外发布；
• 模型开发者可共享微调结果作为“记忆资产”出售或组合；
• 最终构建出一个“记忆应用市场”。

📌 核心转变： LLM 生态中首次将“知识本身”模块化，具备调用接口、托管策略与经济模型。

🧠 2. Painless Memory Management

记忆全生命周期自治：从开发者负担转向系统责任

传统 LLM 应用中，知识注入与缓存管理常依赖外部脚本控制或手动清洗操作，难以标准化。MemOS 提供了完整的生命周期治理体系，使得记忆管理流程完全系统内生：

ounter(line
MemoryCall(op="WRITE", payload="2025年广告法规更新", tags=["legal"])

以上调用自动触发如下子流程：

系统将所有记忆视为资源图谱中的节点，自动进行调度、压缩、淘汰与快照记录，无需开发者介入。

📌 治理视角提升： 记忆的“创建—激活—持久化—清除”不再依赖业务逻辑，而成为操作系统级协议的一部分。

💡 MemOS 可落地的四大典型应用场景

作者还提出了四种现实可用的落地场景，进一步验证了其可操作性与通用性：

1. 多轮对话任务：记住“你五轮前说的预算”
   • MemOS 会将每一轮对话中的关键信息（如预算、地点、偏好）结构化编码为对话记忆单元；
   • 即使对话进行到第 50 轮，也能回溯第 5 轮的预算条件，实现上下文连续性和响应一致性。
2. 知识更新与版本控制
   • 法规、商品描述、公司政策等随时在变；
   • 通过 MemCube 的版本链机制，可以无缝进行知识更新、对比和回滚。
3. 个性化体验：从一次记住，到长期理解
   • 用户的风格偏好、提问习惯、常用术语可通过 MemCube 持久存储并在多任务间复用；
   • 从而实现真正意义上的 长期用户建模与行为一致性。
4. 跨平台迁移：打破“记忆孤岛”
   • 你的旅行偏好不再只存在某个 App 中；
   • 通过 Loader / Dumper，你的 AI 记忆可以从手机迁移到 Web，再同步到公司系统；
   • 一份记忆，多端生效

总结： 从记忆系统，到记忆生态：AI 进入“知识的工业时代“

大语言模型（LLM）正在成为新一代智能系统的“通用引擎”，而构建真正可持续、可演化的智能体，必然依赖一个系统级的记忆机制。MemOS 的提出，正是迈向这一目标的关键一步。

论文首次将“记忆”作为一种可编排、可调度、可治理的系统资源进行设计，抽象出统一的 MemoryCall API、封装形式统一的 MemCube 记忆单元，并通过三层架构体系（接口层 / 操作层 / 基础设施层）支撑记忆的全生命周期管理。

这一设计不仅赋予了 LLM 系统长期一致性、知识演化与个性化适配能力，还提供了结构完备、可工程化落地的治理机制，使得记忆不再依赖外部脚本或规则控制，而成为系统内生能力。

MemOS 展示了一种范式转变的可能性：未来的 AI 系统将不再仅依赖一次性推理，而是围绕长期记忆进行**持续演化（evolution）、主动调度（scheduling）、合规审计（governance）**的完整闭环。

如果说推理能力让 LLM 能“看清当下”，那么记忆治理则让它们“理解过去、适应未来”。

你好，我是叶子，9年Java开发老司机，待过小的创业公司也待过上市厂子。擅长各种姿势的CRUD，但现在工作重心逐渐往中间件开发转移。喜欢折腾技术，AI是个人爱好驱动去学习的。但不管是Java还是AI还是其他非技术行业的知识，我都希望能和大家共同学习进步，如果文章有用，还请大家点击关注，希望我们能一起在技术的道路上走的更远！