MemoryOS：把操作系统那套分层内存管理搬给 AI Agent 的尝试
[EMNLP 2025 Oral] MemoryOS is designed to provide a memory operating system for personalized AI agents.
秒懂
- 它是什么？
- MemoryOS 是 BAI-LAB 在 EMNLP 2025 主会发表并开源的 Agent 长期记忆框架，用 Storage、Updating、Retrieval、Generation 四个模块管理短期、中期、长期记忆。本文只依据仓库与 README 可见的信息，说明它的机制、接入方式与适用边界。
- 适合谁用？
- 如果你的 Agent 需要跨会话记住用户偏好，并且愿意自己维护 LLM 调用与向量库配置，MemoryOS 值得先跑一遍官方 Playground 或 MCP Server 再决定是否嵌入生产链路；如果只是单轮问答或短对话，引入这套分层存储只会增加延迟和运维面。上手前先确认三件事：ChromaDB 之外你还需要哪些存储后端、similarity_threshold 在你的语料上取值多少、以及 MCP 并行化在你的调用配额下是否真的更快。
- 能商用吗？
- 可以。Apache-2.0 是宽松许可证：你可以使用、修改并销售基于它的软件，只需保留版权和许可证声明。
- 还在维护吗？
- 在维护。仓库最近一次提交在 70 天前。
- 用什么语言写的？
- 主要是 Python（依据 GitHub 的语言统计）。
以上回答依据项目的 GitHub 数据（最近同步于 2026年9月15日）和我们的分析，不构成法律意见。
开源项目深度解析
它要解决的是长对话里人设漂移，而不是单轮问答
普通 RAG 把历史消息一股脑塞进向量库，检索出来的片段彼此孤立，Agent 记不住用户上周说过讨厌什么、这周又改了口。MemoryOS 的目标读者是这类需要跨会话保持人格一致性的应用开发者：陪伴型助手、长期项目助理、需要记住用户偏好的客服机器人。README 把定位写成「为个性化 AI Agent 提供记忆操作系统」，论文标题是 Memory OS of AI Agent，核心主张是把短期、中期、长期记忆分开存放，而不是混在一个检索池里。它不处理工具调用、不处理规划，只管记忆这一层，所以可以塞进已有 Agent 框架，也可以单独作为 MCP Server 挂在 Claude Desktop 这类客户端后面。
四个模块的分工：Storage、Updating、Retrieval、Generation
README 明确列出四个核心模块：Storage 负责分层存储，Updating 负责根据新对话动态写入和修正，Retrieval 负责按需取回，Generation 负责把取回的记忆组织成可用的上下文。分层对应短期、中期、长期三档 persona memory，这一点在论文摘要里有对应描述。设计思路借自操作系统的内存管理，也就是把热数据放在快而小的层、冷数据下沉到慢而大的层。需要说明的是，仓库 README 没有给出每一层的具体容量阈值、淘汰策略或晋升条件，这些细节要去 arXiv 论文 2506.06326 或文档站 bai-lab.github.io/MemoryOS/docs 里找。就仓库可见的部分而言，Updating 模块是最值得关注的一环，因为它决定了错误记忆会不会被反复写入并污染后续检索。
LoCoMo 上的 49.11% 与 46.18% 该怎么读
README 写明在 LoCoMo 基准上 F1 平均提升 49.11%、BLEU-1 提升 46.18%。这两个数字是相对基线而言的，README 没有在同一处列出基线是谁、评测配置如何，因此不宜直接当作绝对能力指标。仓库提供了 Reproduce 章节，说明评测流程是公开可复现的，这一点比数字本身更有价值：你可以用同一套脚本在自己的数据分布上验证。需要注意 LoCoMo 是长对话记忆基准，它的对话长度和话题切换频率与真实产品日志未必一致，提升幅度能否迁移到你的场景，只能自己跑。任何声称在这类基准上取得大幅提升的项目，都应该先看复现脚本是否完整，MemoryOS 在这点上给了入口。
接入路径有两条：PyPI 包与 MemoryOS-MCP
第一条路是直接装 PyPI 包，把 MemoryOS 当作库嵌进自己的 Agent 代码，配置项包括 LLM 提供方、embedding 模型和向量库。README 的更新记录显示支持 OpenAI、Deepseek、Qwen 等模型，也支持 BGE-M3 与 Qwen3 的 embedding，V1.2 起加入 ChromaDB 支持并修复了其中固定 LLM 调用的问题。第二条路是 MemoryOS-MCP，通过 MCP Server 暴露模块化工具，让 Claude Desktop 这类客户端直接调用长期记忆能力，README 提到 2025-07-14 做过 MCP 并行化加速。配置层面，2025-07-08 新增了 similarity_threshold 参数，具体写法和取值范围在文档站而不是 README 正文里。部署方面，2025-07-15 起支持 Docker。这里要提醒一句：README 没有给出完整的 config 示例文件，实际接入时你需要以文档站为准，不要凭新闻条目猜键名。
它的边界：记忆层不能替代检索质量，也不是免费的
MemoryOS 管的是记忆的组织方式，不管 embedding 模型本身好不好。如果你的语料是结构化文档而非对话，或者用户根本不会回头，分层存储带来的写入和晋升开销就是纯负担。另一个现实约束是成本：Updating 和 Generation 两个模块都要调 LLM，每次对话结束都可能触发一轮写入，这意味着 token 消耗随会话数线性增长，而不是随查询数增长。README 提到的 5 倍加速来自并行化优化，属于工程层面的改进，没有改变调用次数本身。还有一个未在仓库中说明的点：多层记忆之间的一致性如何保证，比如长期记忆与中期记忆冲突时以谁为准，README 没有给出规则。选型时这是必须向作者确认或自己读论文确认的问题。
和 Mem0、Zep 这类方案比，差别在分层还是扁平
同类项目里，Mem0 走的是从对话中抽取事实条目再存向量库的路线，Zep 走的是时序知识图谱路线，两者都把记忆当成一个扁平或图状的池子，检索时按相关性取回。MemoryOS 的不同在于显式引入短期、中期、长期三档，并借用操作系统的分层思想决定数据放在哪一层。这个差别带来两种后果：分层让冷热数据分离，理论上能降低检索噪声；代价是层与层之间的晋升和淘汰逻辑需要额外调参，配置面比扁平方案大。如果你要的是最小改动就能记住用户名字，Mem0 那类抽取式方案接入更快；如果你要的是长周期人设维护并且愿意调参，MemoryOS 的分层结构才有意义。README 的 Support List 里也列出了 Agent Client 的适配情况，选型时值得对照。
维护成本与 Apache-2.0 的实际含义
项目从 2025 年 7 月的 v1.0 到 V1.2，三周内发了三个版本，2026 年 7 月仍有提交，节奏不算慢。Apache-2.0 允许商用、修改和再分发，附带专利授权条款，对商业集成相对友好。但要注意两点：一是论文与代码是两套东西，论文里的方法不保证与仓库当前实现完全一致，升级版本时行为可能变化；二是项目同时维护 PyPI 包、MCP Server、Playground 平台和文档站四条线，README 的更新记录里既有代码变更也有平台发布，实际维护重心不一定在库本身。如果你的团队要长期跟进，建议锁定具体版本号而不是跟踪 main 分支，并在升级前跑一遍仓库提供的 Reproduce 流程，确认指标没有回退。
编辑结论
如果你的 Agent 需要跨会话记住用户偏好，并且愿意自己维护 LLM 调用与向量库配置，MemoryOS 值得先跑一遍官方 Playground 或 MCP Server 再决定是否嵌入生产链路；如果只是单轮问答或短对话，引入这套分层存储只会增加延迟和运维面。上手前先确认三件事：ChromaDB 之外你还需要哪些存储后端、similarity_threshold 在你的语料上取值多少、以及 MCP 并行化在你的调用配额下是否真的更快。这三项都能在本地复现，不必依赖论文数字。
社区笔记