最近几个刷榜的模型，GLM-5.2、Kimi K3、Qwen-3.8-Max，看起来都挺能打。

这件事带来的一个直接变化是：我对 Agent 的选择，开始没那么依赖它默认绑定了哪一个模型。

模型可以换，API 可以接，今天用 GLM，明天换 Kimi，后天再试 Qwen。只要 Agent 本身足够开放，模型反而越来越像一颗可以随时替换的发动机。

如果你已经把它们当成日常工作的 AI 搭子，那我先说一个判断：

未来真正值钱的，可能不是模型，不是某个 Skill，甚至不只是 Agent，而是你和 AI 一起积累下来的上下文。

为什么？

/记忆可能是目前最被低估的 Agent 能力/

现在大家谈 Agent，最喜欢谈模型、工具调用、MCP、Skill、浏览器操作和代码能力。

很少有人认真算另一笔账：

你和 Agent 一起工作的那些时间，到底沉淀下来了多少？

Agent 真正需要解决的，是那些只有做完一次任务才会产生的经验。

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

这些信息无法在任务开始前写进AGENTS.md，因为那时它们还不存在。

模型在升级，工具在增加，Context Window 也越来越长，但用户与 Agent 共同工作的历史，依然在一次次 Session 结束后被浪费掉。

这是我认为 Memory 被低估的原因。

它并不只是让 AI 偶尔说一句“我还记得你喜欢什么”。

真正有价值的 Memory，应该至少解决三件事：

第一，让 Agent 记得用户和项目当前是什么状态；

第二，让它知道过去哪些方法成功、哪些方法失败；

第三，让已经验证过的经验改变下一次行动。

前两项是记忆，第三项才接近进化。

/各家都有记忆，但说的根本不是同一件事/

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

这些方案很难简单地说谁更先进。

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

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

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

MemOS 则试图在这些 Agent 之上再抽象一层，把记忆从某个产品的内部功能，变成相对独立的基础设施。

一句话总结一下，它是在原始对话与 Context Window 之间，增加了一套完整的 Memory Lifecycle。

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

这也是我真正感兴趣的地方。

模型越来越容易换，Agent 也可能不断换，但用户不应该每换一次工具，就把自己积累的上下文全部推倒重来。

如果一套记忆只能跟着某个平台使用，那它不完全是用户资产，更像平台锁定用户的另一种手段。

/Memory 产品都说自己强，到底信谁？/

AI Memory 最近越来越热闹，每一家都说自己召回更准、上下文更少、更懂用户。

问题是，过去很多跑分根本不能直接比较。

使用的数据集版本不同，回答模型不同，Prompt 不同，Judge 不同，检索参数不同，甚至连“得分”的定义都不完全一样。

这很像大模型早期各种排行榜乱飞的阶段。

每个人都参加了不同的考试，最后又把分数放到同一张海报上比较。

MemOS 最近开源的 OmniMemEval，想解决的就是这个问题。

它把 14 款主流 Memory 产品接入同一条评测流水线，尽量统一 Benchmark、模型配置、Prompt、Judge 和评分方式。

OmniMemEval 把评测分成两部分：

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

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

前者回答：

“AI 有没有越来越懂你”。

后者回答：

“AI 有没有越做越好”。

/把 OpenClaw 和 Hermes 放进同一场考试 /

先看最近大家最关心的 Agent Memory。

这次评测选择了 OpenClaw 和 Hermes 两种 Agent 环境，并覆盖五类任务：

OmniMemEval 的 Agent Memory 部分覆盖五类任务：

这些任务都不是问一句、答一句就能完成。

Agent 需要观察环境、调用工具、保存阶段性结果、排除错误路线，并在后续步骤中继续使用前面形成的判断。

也就是说，它们不仅考模型聪不聪明，也考 Agent 走到一半以后，还记不记得自己正在干什么。

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

结果很直接。

在 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。

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 任务完成率的工程变量。

/高分之外，我更关心它塞了多少上下文/

先看面向个人用户长期记忆的 User Memory。

根据 MemOS 公布的最新版本纵向测试结果，MemOS Cloud 在 LoCoMo 上达到 92.34，在 LongMemEval 上达到 93.40。

但比绝对分数更值得看的是 Context Tokens。

它代表 Memory 系统在回答问题时，最终向模型注入了多少上下文。

因为一个最偷懒的“长期记忆”方案，就是把所有聊天记录全部塞给模型。

模型看到的内容足够多，部分题目的命中率确实可能提高，但真实使用中会迅速出现几个问题：

Token 成本变高；

响应速度变慢；

无关信息开始污染上下文；

新旧信息互相冲突；

模型从一堆历史里捞错结论。

这不是记忆管理，只是信息囤积。

从 OmniMemEval 公布的结果看，MemOS 的优势并不是单纯依靠塞入更多历史，而是在相对有限的上下文里保持较高成绩。

这说明它至少在记忆抽取、检索路由、信息更新和上下文组织方面做了更深的处理。

当然，Context Tokens 少也不能直接等于系统总成本低。

真实成本还包括记忆生成、写入、更新、向量检索、模型调用和后台整理。只有把这些全部算进去，才能知道它在生产环境里到底省不省钱。

但方向是对的：

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

/一场由 MemOS 发起的评测，如何证明可信？/

当然，还有一个无法回避的问题：

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

我比较喜欢 Viewer 的一点是，它把原本藏在 Agent 内部的记忆摊开了。

Agent 记住了什么、怎样理解用户、形成了哪些任务经验，不再完全是一个黑箱。

这对长期记忆非常重要。

因为 Memory 越强，错误记忆的破坏力也越大。

如果 Agent 错误地记住了某个用户偏好，或者把一次偶然成功的操作当成长期策略，用户必须有机会发现并修正，而不是让错误在后台悄悄影响之后所有任务。

/它解决了我的问题，但我不会把它吹成万能大脑/

就目前的使用体验而言，MemOS 确实解决了我在 Hermes 最现实的问题：

Hermes 客户端和模型自由度我很喜欢，但原生记忆容量不够；MemOS 给它补上了一套更完整、可以查看、可以管理，也能够继续生长的长期记忆。

我感受最明显的，并不是 Agent 突然无所不能。

而是它少问了很多重复问题。

项目在哪里、常用什么格式、哪些表达我不喜欢、哪些方法已经试过，这些信息不需要每次开新会话都重新解释。

这看起来不如 Benchmark 第一刺激，却是日常工作中最实在的提升。

因为真正消耗人的，往往不是任务本身，而是不断替 Agent 重建上下文。

最后总结一下：

未来真正值钱的，不只是“一个很懂你的 AI”，而是一套真正属于你的记忆。

它应该可以查看、可以纠正、可以删除，也可以从一个模型迁移到另一个模型、从一个 Agent 带到另一个 Agent。

否则，Agent 越懂你，你被平台锁得越深。

模型当然还会继续变强。

GLM、Kimi、Qwen，今天谁刷榜，明天谁领先，都可能发生变化。

但对用户来说，真正不应该反复清零的，是那些在长期协作中一点点积累起来的上下文、经验和方法。

模型可以随便换。

记忆最好别每次重来。