MemOS 2.0 评测：给 LLM Agent 装上可检查、可纠错的长时记忆层

它解决什么问题：Agent 的短期对话记忆与长期事实记忆之间的缺口

LLM Agent 在单次对话中表现良好，但一旦会话结束，所有上下文就消失了。客户支持机器人无法记住用户上一周提过的工单，个人助手记不住用户偏好，多 Agent 协作时彼此不知道对方做过什么。MemOS 2.0 试图填补这个缺口：它把记忆从对话上下文中抽离出来，成为一个独立的存储与检索层。README 明确说它的目标不是做一个黑盒 embedding 存储，而是把记忆组织成图结构，让开发者可以检查、编辑和删除具体条目。这个定位很关键，因为很多同类方案只提供向量数据库的封装，开发者无法理解模型为什么召回某条记忆。MemOS 面向的是需要长期运行的 Agent 系统，比如客服机器人、个性化助手和多 Agent 协作框架。它的设计假设是：记忆必须可管理、可追溯，而不是一个只进不出的池子。

核心机制：图结构记忆、混合检索与三层技能演化

MemOS 的架构核心是统一记忆 API，它将记忆组织为图，而非简单的键值对或向量列表。图结构允许记忆之间建立关联，比如用户偏好、历史交互和工具调用记录可以互相引用。检索层面，MemOS 采用混合检索，结合了 SQLite 的 FTS5 全文搜索与向量检索。这个组合很实际：全文搜索擅长精确匹配，向量检索擅长语义相似，两者互补。在技能复用方面，README 提到 L1 traces、L2 policies、L3 world models 和 crystallized Skills 的分层结构。这听起来像是把原始交互记录（traces）逐步提炼为策略（policies），再升级为世界模型（world models），最终固化为可复用的技能（Skills）。这个演化过程是 MemOS 所谓的"self-evolving"的关键，但 README 没有给出具体的提炼算法或触发条件，只描述了结果。另外，MemOS 支持多模态记忆，包括文本、图像、工具痕迹和人格设定，这些不同类型的内容在同一个检索系统中被统一处理。

异步写入与反馈纠错：生产环境下的两个关键设计

MemOS 引入了 MemScheduler 来处理异步写入。README 声称这能在高并发下保持毫秒级延迟。异步写入的意义在于，Agent 的主流程不需要等待记忆持久化完成，可以继续处理下一个请求。这对于生产环境的稳定性很重要，因为同步写入在高负载下会成为瓶颈。另一个值得注意的设计是"memory feedback & correction"，即用户或系统可以用自然语言反馈来修正已有记忆。例如，用户可以说"我不喜欢草莓，改为喜欢巧克力"，MemOS 会更新对应的记忆节点。这个功能把记忆从静态存储变成了可演化的实体，但 README 没有说明反馈是如何被解析和应用的，是调用 LLM 还是规则匹配？这一点需要查看文档或源码才能确认。

四种接入方式：从零运维的云 API 到全本地的 SQLite 插件

MemOS 提供了四种部署形态，每种面向不同场景。最轻量的是 Cloud API，只需注册获取以 mpg- 开头的密钥，然后通过 HTTP 调用 add/message 和 search/memory 接口。README 给出了完整的 Python 示例，代码不到十行，适合快速集成到现有应用中。第二种是自托管，需要 Neo4j 和 Qdrant 两个基础设施，通过 docker compose up 启动。这适合对数据主权有要求的企业。第三种是 MemOS Cloud Plugin，专门为 OpenClaw 设计，零运维但数据存储在云端。第四种是 Local Plugin，支持 DeepSeek Harness、Hermes 和 OpenClaw，使用本地 SQLite 和 FTS5，无需额外基础设施。Local Plugin 的版本号已经迭代到 v2.0.17，说明它比 Cloud API 更活跃。选择哪种方式取决于你对数据位置的容忍度：如果数据不能出域，Local Plugin 是唯一选择，但它的功能可能比云端版本少，比如多 Agent 记忆共享可能受限。

基准数据：分数亮眼，但评估方法需要独立验证

README 列出了一组基准分数，包括 LoCoMo 88.83、LongMemEval 89.20、PersonaMem v2 40.58、SWE-Bench 38.46 等。这些分数来自 OmniMemEval，一个声称统一评估了 14 个商业记忆产品的框架。值得注意的是，这些分数并非全部处于顶尖水平，比如 SWE-Bench 38.46 并不算高，而 BrowseComp-Plus 只有 23.85。这提醒我们，MemOS 在长对话记忆和用户画像方面表现强，但在代码生成和复杂浏览任务上并不突出。README 还提到，使用 MemOS 后 OpenClaw 的平均任务完成率从 36.63% 提升到 50.87%，这是相对提升，但绝对数字仍然偏低。这些数据是项目方自己发布的，没有第三方独立复现。在决定采用前，你应该在自有数据集上跑一遍 OmniMemEval，而不是直接信任 README 的数字。

维护与升级成本：依赖 Neo4j 和 Qdrant，插件版本迭代频繁

自托管模式需要维护 Neo4j 和 Qdrant 两个数据库，这意味着额外的运维负担。Neo4j 是图数据库，Qdrant 是向量数据库，两者都有各自的学习曲线和版本升级风险。MemOS 的发布节奏很快，v2.0.32 是 2026 年 8 月 28 日发布的，而 Local Plugin 在四天内从 v2.0.17 更新到 v2.0.18-beta.1。频繁的版本迭代意味着你需要持续关注更新日志，否则可能错过 bug 修复或破坏性变更。许可证是 Apache-2.0，允许商用和修改，但如果你修改了代码并分发，需要保留版权声明。如果你打算把 MemOS 作为云服务提供给第三方，需要注意 Apache-2.0 的专利条款，但这不是法律建议，具体要咨询律师。

替代方案对比：LangChain 记忆模块与自建向量库

MemOS 的直接替代品是 LangChain 的记忆模块，后者提供了 ConversationBufferMemory 和 VectorStoreRetrieverMemory 等组件。两者的核心区别在于，LangChain 的记忆是围绕对话历史设计的，而 MemOS 是围绕图结构和技能演化设计的。LangChain 的向量记忆只做相似度检索，没有记忆编辑或反馈纠错功能。另一个替代方案是自建向量数据库，比如用 Chroma 或 Pinecone 加一个 embedding 模型，然后自己写检索逻辑。这种方式的优点是灵活，你可以完全控制数据流，但缺点是你需要自己实现记忆去重、更新和关联，这些正是 MemOS 内置的功能。MemOS 的图结构记忆是一个明显的差异点：它允许记忆之间有边，比如"用户喜欢草莓"和"用户住在上海"可以关联到同一个用户节点，这在纯向量库中很难做到。如果你的需求只是简单的语义搜索，自建向量库可能更简单；如果你需要记忆的关联和演化，MemOS 的图模型值得考虑。

编辑结论

MemOS 2.0 适合两类人：一是希望给 OpenClaw、Hermes 或 DeepSeek Harness 这类 Agent 框架快速加上持久记忆的开发者，二是需要多知识库隔离与共享的企业团队，且愿意自行维护 Neo4j 与 Qdrant。不适合的是：对延迟极度敏感、要求全本地运行且不想引入额外依赖的简单应用，这类场景直接用 SQLite 加向量索引可能更轻。采用前应先验证三件事：其一，你的 Agent 框架是否有官方插件，若没有，你需要评估 MemOS 的统一 API 能否覆盖你的调用模式；其二，确认你的数据量级是否值得引入图数据库与向量库，小规模场景可能过度设计；其三，仔细阅读 Apache-2.0 许可证在商业闭源产品中的使用限制，尤其是云服务场景。MemOS 的基准分数（LoCoMo 88.83、LongMemEval 89.20）来自其自述的 OmniMemEval 评估，独立复现前不宜当作绝对结论。

官方来源

1. Official documentation
2. Official README
3. Project repository
4. Release notes