06. MemOS:把记忆当成系统资源来治理

论文:MemOS: A Memory OS for AI System
链接:https://arxiv.org/abs/2505.22101

本地原文:

![[papers/06-MemOS-2505.22101.pdf]]

论文定位与阅读路径

核心定位

MemOS 的核心是:记忆不是某个应用里的附属功能,而应该像 CPU、内存、文件、权限一样,被系统统一管理和调度。

原文结构导读

证据链阅读

研究背景与问题定义

为什么需要 Memory OS

当 Agent 从 demo 变成系统,会出现很多问题:

• 不同 Agent 都要用记忆,如何共享?
• 记忆有热/冷之分,如何调度?
• 记忆有隐私和权限,如何治理?
• 记忆可能是文本、KV cache、参数,如何统一抽象?
• 记忆需要演进,如何维护生命周期?

MemOS 就是在回答这些系统级问题。

方法框架与核心机制

三类记忆

这比只讨论“向量库记忆”更全面。

核心架构

关键概念

1. Memory as Resource

MemOS 把记忆当成一等系统资源。
这意味着它要有:

• 分配。
• 调度。
• 权限。
• 生命周期。
• 热度管理。
• 回收。

这和操作系统管理内存/文件很像。

2. MemCube

源文提到 MemCube:用统一对象封装不同记忆。

可以理解为:

MemCube = memory_content + metadata + access_stats + lifecycle_state

metadata 里可能包括:

• 类型。
• 来源。
• 重要性。
• 最近访问时间。
• 是否敏感。
• 是否过期。

3. Memory Governance

治理是 MemOS 的重点之一。
长期记忆会涉及隐私、安全、合规,不能只有“写入”和“检索”。

概念校准

如果 MemGPT 是“给一个 Agent 装记忆”,MemOS 就像“给整个学校建图书馆和档案系统”:谁能借、借多久、哪些资料保密、哪些资料归档、哪些资料淘汰,都要有规则。

工程映射与实践启发

工程落地方案

Java 后端可以先实现一个简化 Memory OS:

记忆状态可以设计成:

HOT -> WARM -> COLD -> ARCHIVED

相关工作与方法对比

和 MemGPT 的区别

局限、对比与阅读检查

局限与边界

• 系统视角很强,但实现复杂。
• Activation/Parameter Memory 对初学者门槛高。
• 工程落地需要大量基础设施。
• 评测不只是问答准确率,还要看治理、成本、可控性。

阅读重点

1. 它如何分类记忆。
2. MemCube 统一抽象是什么。
3. MemoryCall 如何表达一次记忆访问。
4. 它如何管理生命周期。
5. 它的治理思想怎么迁移到普通 Agent 后端。

实践启发

做个人项目时不必一上来实现完整 MemOS,但要提前留接口:

• 记忆类型。
• 权限字段。
• 热度字段。
• 访问统计。
• 删除/过期机制。

否则后期记忆库会变成无法治理的垃圾堆。

原文精读补充

1. MemOS 的问题层级比 Mem0 更高

Mem0 更像一个可用的长期记忆框架。MemOS 问的是系统级问题:

如果未来很多 Agent、很多模型、很多用户都要共享和调度记忆，
记忆应该如何像操作系统资源一样被管理？

所以 MemOS 不只讨论“怎么检索”,还讨论生命周期、治理、调度和跨形态转换。

2. 三类记忆为什么重要

MemOS 把记忆分成:

这提醒你:不要把 memory 狭隘理解成向量库。

3. MemCube 怎么理解

MemCube 可以看成一个统一的记忆对象壳:

MemCube = 内容 + 类型 + 元数据 + 权限 + 生命周期 + 使用统计

对于后端开发,它对应一个接口抽象:

interface MemoryUnit {
    MemoryType type();
    String scope();
    Metadata metadata();
    AccessPolicy policy();
}

真正的内容可以是文本、embedding、KV cache 描述、LoRA 引用等。

4. MemoryCall 是什么

MemoryCall 可以理解为一次结构化记忆请求:

我要在某个用户/项目范围内，找和当前任务相关的事实/事件/技能记忆。

这比直接 search(query) 更强,因为它能表达:

1. 任务意图。
2. 时间范围。
3. 实体约束。
4. 权限范围。
5. 需要的记忆类型。

5. 读原文时怎么抓重点

MemOS 原文会有很多系统概念。你先抓四问:

1. 记忆被抽象成什么资源?
2. 资源如何注册、调度、回收?
3. 不同记忆形态如何转换?
4. 治理和权限如何进入生命周期?

6. 工程落地提醒

你现在不用做完整 Memory OS,但可以提前把字段留好:

memory(
  id,               -- 记忆单元 ID。
  owner_id,         -- 所属用户/Agent/组织。
  scope_type,       -- 作用域类型，例如 user、project、workspace。
  scope_id,         -- 具体作用域 ID。
  memory_type,      -- plaintext / activation / parameter proxy 等类别。
  content,          -- 明文记忆或外部引用。
  source,           -- 来源：chat、note、tool、import。
  sensitivity,      -- 敏感级别，调度器据此决定能否注入上下文。
  access_count,     -- 使用次数，影响调度优先级。
  last_accessed_at, -- 最近访问时间。
  lifecycle_state,  -- active / archived / expired / deleted。
  created_at,       -- 创建时间。
  updated_at        -- 更新时间。
)

以后从单人 Agent 进化到多项目、多工具、多 Agent 时,不会重构崩。

深度精读:MemOS 讲的是“记忆基础设施”,不是一个记忆算法

1. 为什么需要 OS 级抽象

如果只有一个聊天机器人,记忆可以写在一个表里。但当系统变成:

1. 多个用户。
2. 多个 Agent。
3. 多种模型。
4. 多种记忆形态。
5. 多种权限和隐私级别。

单个 memory_text 表就不够了。MemOS 的问题意识是:

AI 系统里的记忆会变成一种公共资源；
公共资源需要注册、调度、权限、生命周期和审计；
所以要像操作系统管理资源一样管理记忆。

这比 MemGPT 更宏观。MemGPT 像一个进程的虚拟内存,MemOS 像整个系统的内存/文件/权限管理层。

2. Plaintext、Activation、Parameter 三类记忆的本质差异

这三类不是谁替代谁,而是适合不同场景:

用户偏好 -> plaintext
高频上下文缓存 -> activation
稳定领域能力 -> parameter

你的个人 Agent 早期只做 plaintext 就够,但接口设计要知道未来可能接 activation/cache。

3. MemCube 为什么有工程价值

MemCube 的意义是把不同记忆包装成统一对象。你可以把它想成 Docker 镜像/文件描述符这类抽象:

不管底层是文本、向量、KV cache、LoRA；
上层都通过统一 metadata、policy、lifecycle 管它。

一个 MemCube 至少要描述:

这会直接影响后期系统能不能治理。

4. Memory Scheduler 要解决什么

当一次任务来了,系统可能有很多记忆:

用户偏好、项目规则、历史对话、工具执行日志、论文笔记、代码片段、缓存状态

Memory Scheduler 要决定:

1. 哪些记忆候选参与。
2. 哪些记忆进 prompt。
3. 哪些只作为工具结果保留。
4. 哪些需要预热成 cache。
5. 哪些因为权限不能用。

这就是上下文预算管理的系统版。

5. Memory lifecycle 不是可选项

长期记忆一定会膨胀。MemOS 强调生命周期,你可以按下面理解:

HOT: 高频使用，可能常驻或优先检索
WARM: 偶尔使用，正常检索
COLD: 很少使用，降低优先级
ARCHIVED: 保留但默认不进检索
DELETED: 用户要求删除或合规删除

这比简单 deleted boolean 强很多。

6. 用 Java 后端实现一个小 MemOS

interface MemoryStore {
    MemoryUnit get(String id);                         // 按 ID 精确读取一个记忆单元。
    List<MemoryUnit> search(MemoryQuery query);        // 按文本、类型、时间和预算检索候选记忆。
    void put(MemoryUnit unit);                         // 写入新记忆，入口处必须做权限和敏感级别判断。
    void updateLifecycle(String id, LifecycleState state); // 修改生命周期，例如归档、过期、删除。
}

record MemoryQuery(
    String ownerId,          // 查询哪个用户/Agent 的记忆。
    String scopeId,          // 限定项目或工作区，避免跨域召回。
    List<MemoryType> types,  // 只召回指定类型，减少噪声。
    String queryText,        // 当前任务或问题文本。
    TimeRange timeRange,     // 时间过滤条件。
    int budgetTokens         // 最多允许注入多少 token。
) {}

重点是把 query 做成结构化对象,而不是一个字符串。这样后续权限、时间、类型、预算都能进入调度。

7. MemOS 对你当前学习的提醒

你现在在做笔记,不是做大系统。但如果你以后真的做 Personal Knowledge Agent,要从第一天就避免:

所有记忆都一个字段 content；
所有记忆都一个 embedding；
所有记忆都永久有效；
所有工具都能读所有记忆；
没有任何访问日志。

这些短期省事,长期会把系统拖死。

8. 读论文时不要被“大词”带跑

MemOS 会出现很多系统愿景词。你读时只抓五个实际问题:

1. 记忆如何统一表示?
2. 记忆如何调度?
3. 记忆如何跨形态转换?
4. 记忆如何权限治理?
5. 记忆如何生命周期管理?

如果这五问答清楚,你就读懂了。

论文精读主线:问题-方法-验证-局限-启发

1. 核心结论

MemOS 把 AI 系统里的明文记忆、激活记忆和参数记忆统一抽象为可管理资源,强调记忆生命周期、调度、权限、迁移和治理。

本篇的阅读重心是:把记忆提升为系统资源:有类型、生命周期、权限、调度和迁移。读完后要能说清它改变的是 runtime、存储、检索、更新还是评测层;否则只是记住了论文名。

2. 问题背景

复杂 Agent 的记忆会散落在 prompt、向量库、数据库、KV cache、模型参数、工具日志和文件系统里。没有统一抽象,每个模块都直接读写自己的记忆,系统会失去权限边界和生命周期控制。

把问题具体化为失败样例:多个 Agent 共用同一记忆池,隐私、过期、权限和成本没有边界,越用越难治理。用这个样例反推论文动机,比泛泛说“上下文不够”或“记忆不准”更有判断力。

3. 核心方法

论文把记忆资源封装成类似 MemCube 的对象,并通过 MemoryCall 进行访问。Memory OS 负责注册资源、选择后端、调度读写、控制权限和审计生命周期。

flowchart TD
    A["AI 应用"] --> O["Memory OS"]
    O --> S["Scheduler"]
    S --> P["Plaintext Memory"]
    S --> V["Activation Memory"]
    S --> W["Parameter Memory"]
    O --> G["Governance"]
    S --> R["记忆调用结果"]

方法部分按数据流读:记忆先被分型和分级,再进入调度层;访问时按身份、任务、权限、生命周期和成本决定是否可用。每一步都要能标出输入、输出、控制点和失败后该记录的日志。

4. 技术细节

三类记忆的工程性质不同:明文记忆可读可审计,激活记忆高效但短暂,参数记忆影响深但难回滚。统一管理不等于统一存储,而是统一 metadata、policy、lifecycle 和调用入口。

final class MemoryOS {
    private final MemoryRegistry registry; // 登记所有 MemCube 的类型、位置、所有者和状态
    private final MemoryScheduler scheduler; // 根据任务意图、预算和权限选择要读写的记忆资源
    private final GovernanceService governance; // 处理访问控制、审计、生命周期和隔离
    private final BackendDispatcher dispatcher; // 把统一 MemoryCall 分发到向量库、图谱、缓存或文件系统

    MemoryResult handle(MemoryInput input) {
        // 1. 登记所有 MemCube 的类型、位置、所有者和状态
        // 2. 根据任务意图、预算和权限选择要读写的记忆资源
        // 3. 处理访问控制、审计、生命周期和隔离
        // 4. 把统一 MemoryCall 分发到向量库、图谱、缓存或文件系统
        // 返回结果时必须带 evidence、confidence、traceId，方便以后追查记忆为什么生效。
        return MemoryResult.withTrace(input.traceId());
    }
}

字段检查重点是 namespace、owner、memoryType、ttl、permission、quota、migrationState 是治理字段。这些字段不是装饰,它们决定后续能否检索、审计、回滚、限权和做离线评测。

5. 实验验证

这类框架论文不能只按准确率读。要看统一管理是否降低 token 成本、提高复用率、改善多 Agent 隔离、减少记忆冲突。工程评测应包括读写延迟、命中率、权限正确率、生命周期操作正确率。

实验阅读重点:综述类工作要转成治理 checklist:隔离是否有效、迁移是否可追踪、删除是否真的生效、成本是否受控。如果论文没有直接给出这层证据,复现时就要自己补机制级指标。

6. 局限与启发

概念大,直接照抄容易过度设计。启发是先做 plaintext memory OS:把 Obsidian 块、用户偏好、任务记录、检索缓存统一成受管资源;暂时不要急着管理参数记忆。

迁移到你的项目时,结论是:现在不用做完整 Memory OS,但表结构和 API 要预留 namespace、权限、生命周期,否则以后重构很痛。先把边界做对,再追求更复杂的模型或更大的记忆规模。

7. 关键术语表

8. 复现难点

范围控制最难。一上来管理所有记忆类型会失焦。统一接口也不能抹平后端差异,否则会变成低能力抽象。只要涉及多用户和同步到博客,权限与本地/公开边界就是治理的一部分。

复现入口应从失败集开始:构造跨用户、跨项目、跨 Agent 的访问场景,验证不该看到的记忆不会被检索或注入上下文。只有先证明旧方案会坏,才知道新机制是否真的解决了问题。

9. 代码框架建议

先定义 MemoryBackend.read/write/supports,再实现 ObsidianBlockBackend、VectorMemoryBackend、UserProfileBackend、TaskTraceBackend。所有后端统一经过 MemoryOS.call() 做权限和审计。

代码验收门槛:所有 memory read/write 都必须经过统一 gateway;业务代码不能绕过权限直接查库。这条门槛应写进测试或 trace 字段里,避免实现只停留在 demo。

10. 相关论文对比

MemOS 抽象层最高。MemGPT 解决单 Agent 上下文调度,Mem0 解决写入维护,Zep 解决事实图谱,MemoryBank 解决陪伴画像,MemOS 试图把它们纳入统一资源治理。

横向比较时抓这个角度:MemOS 是治理层;Mem0 是写入决策;MIRIX 是多模块分工;三者可以叠在同一系统里。比较对象不是谁“更先进”,而是谁负责哪一层失败。

11. 批判性思考

MemOS 的术语很完整,但概念不等于实现。真正价值取决于接口是否清晰、生命周期是否可执行、治理是否落地、评测是否证明收益。当前阶段应把它当长期蓝图。

批判边界:OS 级抽象容易过度设计;只有当多 Agent、多用户、多类型记忆同时出现时才值得完整实现。这不是否定论文,而是把论文结论放回真实系统的成本、权限和恢复约束里。