改进 MemOS 记忆操作系统：LLM 长程记忆工程实践

发表于 2025-12-20 更新于 2026-03-03 分类于 AI-Research ， Projects

原始代码:
https://github.com/MemTensor/MemOS
改进代码：
https://github.com/Kevin589981/MemOS/tree/main/code

LLM 的”遗忘”不只是上下文窗口的技术限制，更是系统设计层面的架构问题。MemOS（Memory OS）将记忆视为可管理的系统资源，提出了一套类比操作系统的记忆治理框架。本文结合在 LoCoMo 对话数据集上的工程实践，系统梳理 MemOS 的核心设计理念，以及如何通过数据增强、提示词工程和窗口策略将评测 F1 从 0.25 推进到 0.57 以上。

一、背景：为什么 LLM 需要”记忆操作系统”

当前主流 LLM 交互模式本质上是无状态的（Stateless）：每次对话独立发生，模型不保留历史。这在四个维度上造成了根本性局限：

长程依赖建模：超长上下文受限于窗口长度和计算开销，关键指令容易被遗忘；
知识无法演化：静态参数无法适应动态世界，RAG 缺乏版本意识，新旧知识可能冲突；
缺乏个性化：无跨会话的持久化”记忆痕迹”，模型无法记住用户长期偏好；
跨平台不可迁移：记忆缺乏可移植性和互操作性。

MemOS 的核心主张是：记忆不应是附属于推理的辅助缓存，而应是智能体的核心资产。推理是基于记忆的计算过程，记忆需要像操作系统管理 CPU/内存那样被系统性治理。

二、MemOS 框架设计

2.1 三种记忆类型

MemOS 将记忆统一为三种类型，覆盖从感知到巩固的全过程：

类型	类比	特点
纯文本记忆（Plaintext Memory）	外部存储（HDD）	显式可见、快速更新、适合事实密集型任务
激活记忆（Activation Memory）	缓存/RAM	核心是 KV-Cache，用于多轮对话连续性
参数记忆（Parameter Memory）	ROM/固件	编码在权重中，稳定但更新成本高

三种记忆并非孤立，而是可以相互转化：

Plaintext → Activation：高频访问的文本记忆预先转化为激活向量，降低解码延迟；
Plaintext/Activation → Parameter：长期稳定知识通过微调或蒸馏内化为参数（”本能”）；
Parameter → Plaintext：通过 Backpatching 导出过时知识以便显式修正。

2.2 MemCube：最小调度单元

每条记忆被封装为一个 MemCube，包含：

元数据头：时间戳、来源签名、语义类型（描述性）；访问权限、TTL、优先级（治理属性）；访问频率、上下文指纹（行为指标）；
记忆载荷：文本、张量（KV Cache）、LoRA Patch（模型权重增量）。

行为指标驱动冷热分层调度：高频文本自动升级为激活层；长期稳定高频记忆标记为适合内化为参数。这与操作系统的 LRU 页面替换是同构的。

2.3 三层架构

接口层（Interface Layer）
  ├── MemReader：语义解析器，将自然语言转化为结构化 MemoryCall
  ├── Memory API：Provenance/Update/LogQuery API
  └── Memory Pipeline：原子化工作流，支持事务回滚

操作层（Operation Layer）
  ├── MemOperator：多视角组织（标签/知识图谱/语义分层）+ 混合检索
  ├── MemScheduler：类型感知调度（KV-Cache/Parameter/Plaintext）
  └── MemLifecycle：五态模型（Generated/Activated/Merged/Archived/Expired）

基础设施层（Infrastructure Layer）
  ├── MemGovernance：三元权限模型 + 隐私保护 + 审计日志
  ├── MemVault：命名空间隔离存储，兼容多种数据库后端
  ├── MemLoader/Dumper：跨平台记忆迁移
  └── MemStore：开放记忆分发平台（发布/订阅机制）

MemScheduler 的核心是类型感知调度：对高频连贯性任务优先使用 KV-Cache，对程序化专家任务使用 Parameter，对临时事实查询使用 Plaintext。这比”一律 RAG”的方案在 Token 消耗和延迟上均有显著优势。

三、LoCoMo 数据集上的工程实践

3.1 任务定义

LoCoMo（Long-term Conversation Memory）是评测 LLM 处理长对话记忆能力的基准数据集，包含四类问题：

cat1：单跳事实问答；
cat2：时序推理（时间顺序、时间锚点）；
cat4：多跳聚合（需要跨句合并多条事实）；
开放域：无固定答案的推理类问题。

整体评测指标：BLEU、F1（token 级别）、LLM 打分（语义级别）。

3.2 接口对齐：add/search 双接口

评测框架以 add（写入记忆）和 search（检索记忆并生成答案）为核心接口。我们实现了 MemOS 版本的适配层：

add.py 的五大核心设计：

命名空间隔离：每次实验通过 MEMOS_RUN_TAG 后缀区分 speaker 的 user_id 和 conversation_id，避免历史记忆污染新评测；
Day 边界标记：每条消息前缀化为 "[Day N] Speaker: text"，增强”同天事件聚合”的检索能力；
时间戳保存：写入 chat_time 字段（如 "8:56 pm on 20 July, 2023"），为时序问答提供可计算锚点；
滑动窗口批量写入：窗口大小 batch_size，步长 batch_size - overlap，让跨批次边界的事实在某个批次内共同出现；
并行双 speaker 写入：双线程上传，降低总体写入耗时。

search.py 的核心优化：

时序感知召回增强：对含 when/date/time/before/after 等关键词的问题，将 memory_limit_number 提升至 top_k × 1.3，降低时序记忆漏检概率；
时间戳规范化：将 MemOS 返回的数字时间戳格式化为可读 UTC 时间，防止模型复读纯数字时间戳作为答案；
非时序问题不注入时间信息：从输入侧降低模型被 timestamp 诱导输出时间的概率；
拒答归一化：将 “No memory mentions…” 等拒答句统一归一为 Unknown，避免大量零分。

3.3 数据预处理：locomo_enhanced

原始 LoCoMo 对话充满寒暄、省略和隐性事实，直接写入 MemOS 导致”关键句被淹没在噪声中，语义向量不够尖锐”。

核心思路：在写入前，用大模型抽取每段对话的显式事实，附加回原消息，形成”原文 + Facts 摘要”的增强版本：

[原消息]  Alice: I just got back from Paris last Tuesday.
[增强后]  Alice: I just got back from Paris last Tuesday.
          [Facts extracted: Alice visited Paris. Alice returned on Tuesday, the week before {Conversation Date}.]

时间表达的处理策略：

yesterday/today/tomorrow → 转为绝对日期；
last week/last <weekday> → The week/weekday before <Conversation Date>（相对但明确）；
two months ago 等复杂相对表达 → 保持原样（避免过度具体化导致与答案不一致）；
数字一律使用阿拉伯数字（4 years，10 years ago），减少格式差异导致的 F1 损失。

此步骤使分数从 ~0.487 提升至 ~0.53。

3.4 优化迭代记录

阶段	主要改动	F1 分数
基线（流程跑通）	零修改，验证端到端流程	0.25
Prompt 对齐 + Top-K 调整	短答案导向 Prompt，提升 top_k	0.499
滑动窗口写入	batch_size + overlap 策略	0.487
数据预处理（事实抽取）	locomo_enhanced 数据集	0.53+
抑制过度推理	微调预处理 Prompt，避免机械时间换算	0.54
窗口超参调优	batch=16, overlap=8	0.546
模型横向对比	`qwen-plus-latest` 推理能力更强	0.560

3.5 失败尝试与根因分析

Reranker 高召回重排序（top_k=50 + reranker）：分数反而降至 0.42。根因：reranker 只能重排序已召回的结果，无法弥补”多跳链路中关键节点未被召回”的根本缺陷；同时高召回+重排后拉长输入，生成长句，不利于短答案对齐。

图片信息提取：分数从 0.53 降至 ~0.40。根因：图片描述引入大量无关细节，增加噪声 token，削弱对关键信息的聚焦；多模态推理错误率传导至后续检索与生成阶段。

Agentic 多跳 RAG（混合 Dense + BM25 检索循环）：技术先进但边际收益有限，显著增加 Token 消耗和延迟，与短答案评测目标冲突。最终保留完整实现作为技术展示，主实验中关闭。

四、MemOS 评测结果：它真的”记得”更好吗？

MemOS 在官方评测中的表现印证了其设计优势：

LoCoMo：Overall 75.80 分（第二名 Memobase 72.01），在单跳、多跳、时序、开放域均取得最佳或次佳，且 Token 消耗（1589）远低于次优方案 Zep（2701）；
LongMemEval：综合准确率 77.8%，显著优于 Memobase (72.4%) 和 Mem0 (66.4%)；
并发压力测试：唯一在所有测试下保持 100% 成功率的系统；
KV-Based 记忆加速：在长上下文 + 短查询场景下，加速比最高达 94.2%（通过复用预计算的 KV 中间状态）。

五、工程洞见：什么真正有效

从这次从 F1=0.25 到 F1=0.56 的优化之旅中，最有价值的经验是：

显式化胜过检索技巧：将隐性事实预先抽取为结构化摘要，比各种检索优化（reranker、高召回）更有效。”让信息直接可检索”比”让检索器更聪明”ROI 更高。
时间信息是弱点：时序问题对格式极为敏感，需要从写入、检索、Prompt、评测四个层面同时处理。任一环节的时间格式失控都会造成大量零分。
短答案导向的 Prompt 约束是关键杠杆：F1 指标是 token 级别匹配，模型生成哪怕一个正确答案被埋在长句中也会被稀释。输出约束（”禁止解释””5-6词””禁止纯数字时间戳”）带来的收益超过了精细化的检索优化。
窗口参数不是越大越好：batch_size=16, overlap=8 是在”上下文完整性”与”向量噪声”之间的平衡点。过大的批次让语义向量趋于平均，导致检索钝化。