title: "MemOS: A Memory OS for AI System" source: "https://arxiv.org/abs/2505.22101" paper: "38-memos.pdf" publication: "2025" venue: "arXiv" status: deep-read-v2 tags: - memory-operating-system - memory-governance - llm-systems - memos - deep-read-v2

MemOS: A Memory OS for AI System

[!abstract] 一句话结论把记忆提升为 AI 系统的一等资源，用统一的 Memory Cube、调度器、生命周期与治理接口管理参数、激活和明文三类记忆。

TL;DR

维度	精读结论
发表	2025 · arXiv
核心命题	把记忆提升为 AI 系统的一等资源，用统一的 Memory Cube、调度器、生命周期与治理接口管理参数、激活和明文三类记忆。
证据边界	本笔记区分机制证据、短期任务收益、长期稳定性与生产治理，不把其中一项自动外推为另一项。
阅读定位	新一代模型的可塑状态、记忆组织或学习规则；需要放在统一长期自适应框架中比较。

原始页面：https://arxiv.org/abs/2505.22101
本地原文：[[38-memos.pdf]]
笔记版本：deep-read-v2，引用坐标来自本地 PDF 文本层，图示使用页内 rect。

1. 问题与背景

现有 LLM 系统的记忆分散在权重、KV cache、向量库、提示、日志和用户画像里。每种介质由不同组件管理，缺少统一来源、权限、生命周期和转换协议。结果是模型虽然“能记”，系统却难以回答：某条记忆来自哪里、谁可读取、何时过期、是否已被参数吸收、如何删除或回滚。

MemOS 不是提出一个更高准确率的记忆网络，而是提出操作系统式抽象：把记忆作为一等资源，通过标准对象和控制平面统一管理。论文区分 parametric memory、activation memory 与 plaintext memory，并允许在三者之间转换。核心对象 MemCube 同时携带内容载荷和元数据，调度层再决定存储、检索、迁移、合并、冻结和删除。

这解决的是长期自适应系统的工程缺口。仅有 TTT/Titans 的可塑状态还不足以部署，因为没有治理就无法隔离用户、追踪错误或满足删除要求。反过来，MemOS 本身也不证明新的学习算法；它是架构提案与原型愿景，实证强度需谨慎评价。

[!PDF|] 问题/定义原文锚点 1 · 38-memos.pdf, p.1

[!PDF|] 问题/定义原文锚点 2 · 38-memos.pdf, p.1

2. 相关工作

MemOS 连接操作系统资源管理、数据库、数据血缘、RAG、模型编辑、KV-cache 管理与多代理记忆。与向量数据库相比，它管理的不只是文本条目，还包括神经激活和参数记忆；与普通 memory agent 框架相比，它强调统一生命周期、调度和治理；与 MLOps 模型版本管理相比，它把更细粒度的记忆对象纳入版本与权限。

三类记忆各有边界：明文可解释、可检索、易删除但推理时需要显式读取；激活记忆速度快、贴近模型计算但脆弱且难跨模型；参数记忆推理便宜、容量高但写入昂贵、难追踪单条来源。MemOS 的价值在于把这些权衡显式化并提供转换接口。

与相邻概念的边界

Long context 让当前前向过程访问更多历史，但不必改变任何持久状态。
RAG / 外部记忆 把知识留在可检索介质，更新快、可追踪，却不自动形成内化技能。
Test-time adaptation 在推理流中改变状态，持续时间可能只有一个序列或会话。
Continual learning 要求在非平稳任务/数据流中获得新能力并控制旧能力退化。
Self-improvement 还多一层目标与验证闭环：系统不仅能更新，还能判断什么更新值得提交。

本文与这些概念有交集，但其证据只能覆盖实际实验过的范围。特别要避免把“状态能跨较长 token 序列存在”写成“知识能跨模型版本稳定保存”。

3. 方法

MemCube 可抽象为带治理元数据的记忆对象：

\[ \mathcal{M}= (\text{payload},\text{type},\text{provenance},\text{owner}, \text{lifetime},\text{priority},\text{version},\text{policy}). \]

调度器在候选介质 \(j\) 之间优化综合成本：

\[ j^\*=\arg\min_j\; \alpha C_{\mathrm{latency}}^j+\beta C_{\mathrm{storage}}^j+ \gamma C_{\mathrm{risk}}^j-\delta U_{\mathrm{task}}^j, \]

并通过转换算子执行 plaintext→activation、activation/plaintext→parametric 或 parametric→plaintext。第二个式子是用于理解系统权衡的抽象，不是论文报告的已训练最优调度器。

MemCube 的 payload 保存具体记忆，metadata 记录来源、有效期、访问控制、优先级、版本和使用统计。接口层通过 MemReader/API 向模型与应用提供读写入口；操作层包含 MemScheduler、Lifecycle Manager 和 Memory Operator；基础设施层包括 Vault、Governance、Store、Loader/Dumper。

Scheduler 根据任务、成本与策略选择何种记忆、何时加载、向哪种介质迁移。Lifecycle 把记忆视为状态机，支持创建、激活、更新、合并、冻结、归档和删除，并强调 rollback。Operator 承担抽取、压缩、检索、融合与转换。这个分层把“模型怎样学”与“系统怎样管理学习结果”解耦。

论文还设想跨模型/跨代理的记忆共享乃至市场。这里必须保持批判：格式可互操作不代表语义可互操作；一个模型的激活或参数片段通常不能安全迁到另一个模型；共享记忆也会带来隐私、授权和投毒风险。可行的近期形态更可能是标准化明文/结构化事件与可验证摘要。

[!PDF|] 方法原文锚点 1 · 38-memos.pdf, p.1

[!PDF|] 方法原文锚点 2 · 38-memos.pdf, p.4

[!PDF|] 方法原文锚点 3 · 38-memos.pdf, p.5

关键图示

图 1：精读裁剪 · 38-memos.pdf, p.4

这张裁剪用于定位论文的整体机制/架构。阅读时应沿着输入、写入信号、被更新状态和输出四条线检查：若只知道“有记忆模块”而不知道其写入目标与重置边界，就无法判断它属于缓存、在线学习还是持久知识。

图 2：精读裁剪 · 38-memos.pdf, p.6

第二张裁剪用于定位结果或关键消融。图表分数必须与预算一起读：额外状态、额外参数、额外生成 token、离线更新次数和墙钟成本都可能是收益来源。

4. 实验与证据

这是一篇概念与系统架构论文，主要证据来自分类框架、组件设计、原型场景和未来路线，而不是严谨的公开 benchmark。图示展示三类记忆、MemCube、调度与生命周期如何衔接；文本讨论版本回滚、冻结、来源记录和不同介质转换。它能证明设计具有一定完整性，不能证明自动调度提升多少准确率、吞吐或长期保持。

因此阅读时不应把 MemOS 与 TTT/Titans 的实验表格同级比较。它回答“一个可持续学习系统需要哪些控制面”，而非“哪种记忆更新规则最好”。评价标准应是接口是否足以表达治理需求、故障是否可隔离、转换是否可验证、元数据开销是否可接受。

最强的可用洞见是：长期记忆必须同时是模型问题和系统问题。最弱的部分是未来愿景，例如去中心化共享与记忆经济，当前缺少安全模型、性能数据和跨架构可迁移证明。

[!PDF|] 实验/结果原文锚点 1 · 38-memos.pdf, p.6

我对证据强度的判断

直接支持：论文实际实现的状态更新机制，在其报告任务和预算下具有可测收益。
部分支持：多时间尺度/自适应设计可能比单一静态状态更有效，但具体因果项仍需等预算消融。
尚未支持：多年开放世界运行、跨用户安全持久化、自动选择长期目标、无需外部评估的自主迭代。

判断实验是否接近持续学习，至少要同时看到学习新分布的速度和旧分布的完整轨迹。只报告最后一步平均分会隐藏“先学会、后忘掉”与任务顺序敏感性；只报告长上下文检索又会把存储/定位能力误当成参数知识与技能形成。

5. 局限与开放问题

论文缺少端到端定量实验、公开故障注入、调度算法消融和大规模成本测量；三类记忆转换有些在技术上非常困难，尤其 parametric→plaintext 的可逆抽取与 activation 跨模型迁移；MemCube 元数据是否能细粒度绑定分布式参数尚不清楚；统一控制面也可能成为单点故障和高价值攻击面；“删除”明文条目不等于参数层真正遗忘。

反例是错误事实已通过多轮训练扩散到大量参数，系统即使保留 provenance 也不能精确撤回。另一个反例是调度器为降低时延把敏感记忆缓存进共享激活状态，造成跨租户泄漏。架构必须给出不可跨越的权限边界，而非只依赖策略标签。

[!PDF|] 局限/结论原文锚点 1 · 38-memos.pdf, p.7

[!PDF|] 局限/结论原文锚点 2 · 38-memos.pdf, p.8

尚待回答的开放问题

容量：数据流无限而状态有限时，淘汰规则是否可解释、可调、可恢复？
冲突：新事实与旧事实冲突时，是覆盖、并存版本、按上下文路由，还是拒绝更新？
信用：一次长期收益应归因于哪条经验、哪个记忆层或哪次参数更新？
治理：如何做到用户隔离、来源追踪、敏感信息删除、异常检测和事务式回滚？
目标稳定：模型可以改变学习状态后，谁保证其优化目标、安全边界和评估器没有共同漂移？

6. 与长期自适应智能的关系

MemOS 处在长期自适应智能的“记忆控制平面”。Fast Weights、TTT、Titans 提供可塑数据面，SEAL 提供更新数据生成，MemOS 则负责对象化、路由、版本、权限与生命周期。没有控制平面，自适应越强，污染、隐私和不可逆错误的风险越大。

它还帮助区分 memory 与 learning：保存一条文本不是模型能力提升，改参数也不保证记得正确。完整系统需要将事件、状态、技能和参数更新都注册为可追踪资产，再用验证结果决定是否升级到更慢、更难撤销的介质。MemOS 的研究价值正在于推动这种系统化语言。

在完整闭环中的位置

一个更完整的系统需要按顺序完成：观察经验 → 判断新颖性/可信度 → 写入快记忆 → 检索并解决冲突 → 离线巩固 → 多维验证 → 提交或回滚 → 监控长期漂移。本文主要强化其中一个或数个环节，而不是覆盖整条链。

因此，“下一代模型”不应被理解为单一更大的参数函数，而应是多个可塑介质和学习回路组成的系统：即时激活负责当前计算，快状态负责临时适应，外部记忆负责可追踪事实，慢参数负责稳定技能，元规则负责决定如何更新。持续学习是这些层之间受约束的信息流。

审稿式证据分级

阅读这类论文时，建议把证据分成四级，而不要把“模型能更新”直接等同于“模型会长期学习”：

机制存在：某种状态确实会被输入改变，且消融能定位到该机制。
短期有效：在同一上下文、单任务或少量任务切换中，新增能力优于基线。
长期稳定：在足够长的数据流中，新能力保持、旧能力不发生不可接受退化。
可治理部署：更新有来源、权限、版本、隔离、审计和回滚，能抵抗噪声与恶意输入。

本文的实验主要覆盖前两级，并在部分设置触及第三级；若没有跨会话状态、长周期回归和故障注入，就不能宣称达到第四级。这个分级用于防止把 long context、test-time state、参数编辑和持续学习混成一个概念。

统一比较坐标

维度	精读时要问的问题
写入介质	token/KV、外部条目、神经状态、adapter，还是基础参数？
写入信号	监督标签、自监督损失、惊奇度、奖励、重放，还是人工规则？
保留周期	单步、单会话、跨会话、跨模型版本，还是永久？
容量与遗忘	固定容量如何淘汰？容量增长是否计入比较？
选择与路由	谁决定写什么、读什么、何时巩固？是否需要 task ID？
证据公平性	参数量、状态字节、训练 token、生成 token、FLOPs 与墙钟是否等价？
可逆性	能否定位一次更新、撤销单条知识、恢复旧 checkpoint？
安全与隐私	恶意经验、跨用户污染、敏感数据删除如何处理？

最小复现协议

建议先建立四条等预算基线：冻结模型 + 长上下文/RAG、naive sequential fine-tuning、等容量 replay、一个参数隔离/PEFT 方法。对目标方法固定总训练 token、可训练参数、推理上下文、状态字节和总 FLOPs；如果方法额外生成数据或搜索候选，也必须计入预算。

数据流至少包含：稳定新知识、随时间变更的事实、互相冲突的任务、一次性噪声、重复噪声、稀有高价值事件和对抗写入。每个阶段保存 checkpoint，画完整学习轨迹，不只报最终平均分。最低指标集包括新任务学习面积（forward transfer）、旧任务保持/BWT、通用能力、校准、安全回归、状态/参数增长、时延、吞吐、能耗与原始数据保留量。

最重要的测试是 恢复性：分布 A→B→A 后，系统能否快速回到 A；删除一条经验后，所有介质是否都不再泄露；一次错误更新能否自动检测并回滚。持续学习不是只看平均准确率，而是看一个长期运行系统是否仍可控。

部署成熟度检查

在研究原型之外，还应记录更新是否发生在共享基础模型、用户专属适配器、会话状态或外部存储中。四者的故障半径完全不同：共享参数的一次错误可能影响所有用户，会话状态的错误通常可随重置消失，外部条目则较容易审计与撤销。默认策略应当是先写可逆介质、后做慢层提交，并把每次提交视为一次需要回归测试的模型发布。若论文没有说明状态边界、重置条件和跨用户隔离，就只能评价算法可塑性，不能据此判断生产可用性。

还要区分 记忆正确、行为正确 与 目标正确：系统可能准确记住错误信息，也可能拥有正确事实却在错误目标驱动下使用它。长期评估因此不能只查事实命中率，还要审查策略遵从、因果一致性、拒答与不确定性。自适应系统的失败往往不是完全忘记，而是把局部经验错误地泛化到不该适用的上下文。

[!tip] 阅读建议先判断论文改变了哪个状态、该状态能保留多久，再看分数。若论文只证明更长上下文上的困惑度或检索准确率，把它标为“在线/上下文适应证据”；只有跨任务、跨会话、带旧能力回归的实验，才升级为“持续学习证据”。最后单独审查治理条件，不让算法指标替代部署安全。

个人思考

我认为 MemOS 的方向比“又一个 memory benchmark”更接近实际缺口，但现阶段应称研究议程而非已验证操作系统。最可取的是一等记忆对象和生命周期；最需谨慎的是把 parametric memory 说得像数据库页一样可迁移、可删除。

最小可验证原型应选择三种具体介质：PostgreSQL/向量库明文、会话 KV/TTT 状态、LoRA 参数。实现统一 provenance、TTL、权限、快照和回滚，再做故障注入：错误写入、用户删除、模型升级、跨用户访问、巩固失败。只有报告恢复时间、残留率、性能与存储成本，MemOS 才从架构图走向工程科学。

可证伪预测

若本文机制真正捕捉到通用长期适应规律，那么在固定总 FLOPs、状态字节和参数量后，它仍应在长任务流上同时改善新任务学习曲线与旧任务保持曲线；收益不应只来自更长提示、更多生成样本或更大隐状态。若加入噪声、冲突、任务顺序反转和 A→B→A 恢复后优势消失，就应把结论降级为特定 benchmark 的序列建模技巧。

最终判断

这篇论文值得精读，因为它为“模型如何在运行中改变”提供了一个具体机制或系统抽象。我的判断不是简单的推荐/否定，而是：先把它放到正确时间尺度和状态介质上，再用等预算、长周期、可恢复的实验检验。只有同时通过能力、稳定性和治理三道门，它才从“可塑模型组件”成长为“长期自适应智能组件”。