14款Memory产品测评MemOS第一，我又把Hermes捞了回来

记忆是当前最被低估的Agent能力

现在大家谈Agent，最喜欢谈模型、工具调用、MCP、Skill、浏览器操作和代码能力。很少有人认真算另一笔账：你和Agent一起工作的那些时间，到底沉淀下来了多少？

Agent真正需要解决的，是那些只有做完一次任务才会产生的经验。上次修复Bug时，Agent先走了哪条错误路线，为什么失败；查资料时，哪些来源看似权威，实际已经过时；用户否定了一种表达，到底只是这次不适用，还是应该更新为长期偏好；某套工作流偶然成功了一次，究竟值不值得继续复用。

这些信息无法在任务开始前写进AGENTS.md，因为那时它们还不存在。模型在升级，工具在增加，Context Window也越来越长，但用户与Agent共同工作的历史，依然在一次次Session结束后被浪费掉。

真正有价值的Memory，应该至少解决三件事：第一，让Agent记得用户和项目当前是什么状态；第二，让它知道过去哪些方法成功、哪些方法失败；第三，让已经验证过的经验改变下一次行动。前两项是记忆，第三项才接近进化。

各家Memory定义差异巨大

不同Memory方案对比示意图

现在几乎所有主流AI产品都说自己有Memory，但它们对Memory的定义差异很大。

Codex式后台记忆的好处是，用户不需要天天维护，系统也可以尽量避免把大量脏数据暴露给用户。

Hermes式显式记忆的好处是，你能看见Agent如何理解自己和用户，记忆也更容易审计。

OpenClaw的文件化记忆强调可控和可迁移，但管理规模一大，也容易变成新的文件整理工作。

MemOS则试图在这些Agent之上再抽象一层，把记忆从某个产品的内部功能，变成相对独立的基础设施。一句话总结一下，它是在原始对话与Context Window之间，增加了一套完整的Memory Lifecycle。

一次任务产生的内容，可以被拆分为用户偏好、项目事实、工具轨迹、失败路径和可复用经验，并附带来源、时间、版本等元数据。MemOS再通过MemCube将这些异构记忆封装成可以管理的单元，让不同用户、项目和Agent的记忆既能隔离，也能按需组合、迁移和共享。

模型越来越容易换，Agent也可能不断换，但用户不应该每换一次工具，就把自己积累的上下文全部推倒重来。如果一套记忆只能跟着某个平台使用，那它不完全是用户资产，更像平台锁定用户的另一种手段。

OmniMemEval统一评测14款Memory产品

AI Memory最近越来越热闹，每一家都说自己召回更准、上下文更少、更懂用户。问题是，过去很多跑分根本不能直接比较。使用的数据集版本不同，回答模型不同，Prompt不同，Judge不同，检索参数不同，甚至连“得分”的定义都不完全一样。

MemOS最近开源的OmniMemEval，想解决的就是这个问题。它把14款主流Memory产品接入同一条评测流水线，尽量统一Benchmark、模型配置、Prompt、Judge和评分方式。

OmniMemEval评测框架示意图

OmniMemEval把评测分成两部分：

User Memory 测AI能不能长期理解用户，包括事实、偏好、时间关系、信息更新和遗忘要求；

Agent Memory 测过去积累的经验能不能真正提高Agent执行代码、搜索、数学推理和知识工作任务的成功率。

前者回答：“AI有没有越来越懂你”。后者回答：“AI有没有越做越好”。

MemOS在OpenClaw和Hermes中均显著提升任务完成率

先看最近大家最关心的Agent Memory。这次评测选择了OpenClaw和Hermes两种Agent环境，并覆盖五类任务。这些任务都不是问一句、答一句就能完成。Agent需要观察环境、调用工具、保存阶段性结果、排除错误路线，并在后续步骤中继续使用前面形成的判断。也就是说，它们不仅考模型聪不聪明，也考Agent走到一半以后，还记不记得自己正在干什么。

为了尽量减少模型能力差异的影响，OpenClaw和Hermes使用相同的回答模型和评测模型；同一任务连续独立运行三次，最终以平均一次通过率计算Accuracy。

OpenClaw环境下MemOS插件效果对比图

在OpenClaw环境中，未安装Memory插件时，五项任务的平均完成率为36.63%。接入MemOS Local Plugin 2.0后，平均完成率提升至50.07%。

在五项横向评测中，MemOS获得BrowseComp-Plus、OmniMath、GDPVal第一，SWE-Bench并列第一，LiveCodeBench第二。其中，GDPVal的提升最明显，从34.48%提升至62.07%。

这意味着，在需要持续搜集材料、保持任务状态并最终完成专业交付的场景中，Memory不只是帮Agent“想起一条信息”，而是在直接改变它把事情做完的概率。

Hermes环境下MemOS插件效果对比图

再看Hermes。Hermes本身已经具备较强的任务执行和记忆能力，但接入MemOS后，五项任务平均完成率依然从45.15%提升至53.05%。

其中，OmniMath达到72.67%，SWE-Bench达到52.56%，两项均位列横评第一；LiveCodeBench位列第二。尤其在SWE-Bench中，Hermes Baseline为37.18%，接入MemOS后提升至52.56%。

这说明MemOS的作用并不依赖某一种Agent架构。无论是OpenClaw，还是本身就强调自我进化的Hermes，接入同一套Memory系统后，都能在多个长程任务中获得可复现的提升。

把两类Agent、五类任务放在一起看，最终形成十组结果：

10组Agent Memory评测，MemOS取得6项第一、8项前二。

这组数据真正值得关注的地方，不只是“拿了几个第一”。而是：Memory开始从一个改善体验的功能，变成一个能够直接影响Agent任务完成率的工程变量。

MemOS在有限上下文中保持高分

先看面向个人用户长期记忆的User Memory。根据MemOS公布的最新版本纵向测试结果，MemOS Cloud在LoCoMo上达到92.34，在LongMemEval上达到93.40。

但比绝对分数更值得看的是Context Tokens。它代表Memory系统在回答问题时，最终向模型注入了多少上下文。因为一个最偷懒的“长期记忆”方案，就是把所有聊天记录全部塞给模型。

模型看到的内容足够多，部分题目的命中率确实可能提高，但真实使用中会迅速出现几个问题：Token成本变高；响应速度变慢；无关信息开始污染上下文；新旧信息互相冲突；模型从一堆历史里捞错结论。这不是记忆管理，只是信息囤积。

MemOS与其他产品Context Token对比图（左）MemOS与其他产品Context Token对比图（右）

从OmniMemEval公布的结果看，MemOS的优势并不是单纯依靠塞入更多历史，而是在相对有限的上下文里保持较高成绩。这说明它至少在记忆抽取、检索路由、信息更新和上下文组织方面做了更深的处理。

当然，Context Tokens少也不能直接等于系统总成本低。真实成本还包括记忆生成、写入、更新、向量检索、模型调用和后台整理。只有把这些全部算进去，才能知道它在生产环境里到底省不省钱。

Memory不是越多越好，而是当前任务需要什么，就准确地给什么。

OmniMemEval作为公共基础设施的价值

当然，还有一个无法回避的问题：OmniMemEval由MemOS团队发起，而MemOS又在多项评测中领先，怎么保证这不是一场为自己设计的考试？

答案不应该是反复强调“我们绝对公平”。更有价值的方式，是把考试过程公开。目前，OmniMemEval已经开放了评测代码、数据准备流程、适配器、运行配置和结果目录。

报告也明确说明，各产品配置依据其公开文档、API和已有Benchmark指南准备，但不声称每一个适配器都已经达到该产品的全局最优配置；如果其他团队认为某项参数或接入方式可以改进，也可以提交贡献和复现结果。

因为一个真正有行业价值的Benchmark，不应该是一张发布后不再变化的排行榜。它更应该是一套公共基础设施：允许不同团队进入；允许结果被挑战；允许配置被修正；也允许新的Memory架构不断刷新现有成绩。

只有这样，AI Memory才能从“各自展示自己的高分”，走向可以比较、解释和复盘的工程阶段。

实测：为Hermes安装MemOS Local Plugin 2.0

MemOS有不同产品形态，我这次使用的是MemOS Local Plugin 2.0。它可以安装到OpenClaw或Hermes上，让Agent获得一套独立于原生小文件之外的长期记忆。

官方提供了一键安装脚本：

curl -fsSL https://raw.githubusercontent.com/MemTensor/MemOS/main/apps/memos-local-plugin/install.sh | bash

脚本会检测本机已经安装的OpenClaw和Hermes，把插件部署到对应目录，为Hermes生成相关配置，并启动本地Viewer。

安装完成后，Hermes对应的Viewer默认运行在http://127.0.0.1:18800

MemOS Viewer界面截图

我比较喜欢Viewer的一点是，它把原本藏在Agent内部的记忆摊开了。Agent记住了什么、怎样理解用户、形成了哪些任务经验，不再完全是一个黑箱。

这对长期记忆非常重要。因为Memory越强，错误记忆的破坏力也越大。如果Agent错误地记住了某个用户偏好，或者把一次偶然成功的操作当成长期策略，用户必须有机会发现并修正，而不是让错误在后台悄悄影响之后所有任务。

MemOS解决了现实问题，但不是万能大脑

就目前的使用体验而言，MemOS确实解决了我在Hermes最现实的问题：Hermes客户端和模型自由度我很喜欢，但原生记忆容量不够；MemOS给它补上了一套更完整、可以查看、可以管理，也能够继续生长的长期记忆。

我感受最明显的，并不是Agent突然无所不能。而是它少问了很多重复问题。项目在哪里、常用什么格式、哪些表达我不喜欢、哪些方法已经试过，这些信息不需要每次开新会话都重新解释。

这看起来不如Benchmark第一刺激，却是日常工作中最实在的提升。因为真正消耗人的，往往不是任务本身，而是不断替Agent重建上下文。

未来真正值钱的，不只是“一个很懂你的AI”，而是一套真正属于你的记忆。它应该可以查看、可以纠正、可以删除，也可以从一个模型迁移到另一个模型、从一个Agent带到另一个Agent。否则，Agent越懂你，你被平台锁得越深。

模型当然还会继续变强。GLM、Kimi、Qwen，今天谁刷榜，明天谁领先，都可能发生变化。但对用户来说，真正不应该反复清零的，是那些在长期协作中一点点积累起来的上下文、经验和方法。

模型可以随便换。

记忆最好别每次重来。

JOTO 企业落地观察

• 企业部署AI智能体时，若缺乏跨平台记忆迁移能力，将导致每次更换Agent框架或模型供应商时，历史上下文全部丢失，形成隐性知识沉没成本。
• 这类系统的取舍在于：是否接受将记忆系统作为独立基础设施部署，而非绑定于某款Agent SDK——前者带来架构灵活性与长期资产沉淀，后者换取短期集成效率。
• RAG知识工程正从静态文档索引，转向动态记忆生命周期管理；企业需评估现有RAG pipeline能否兼容MemCube类结构化记忆单元的写入、版本控制与跨会话检索。
• AI安全治理需新增记忆审计维度：显式记忆（如Hermes式）便于人工核查与干预，但对大规模企业级部署而言，后台记忆（如Codex式）的自动化合规校验机制更为关键。