从Mem0/MemOS/Graphiti 聊大模型记忆

上一篇我们聊 token 消耗，表面上是额度不够用，本质上是 agent 在一次任务里读了太多没必要读的信息。它不知道去哪找，就反复搜索、读文件、跑命令；工具返回什么，它就接受什么。CodeGraph 和 Headroom 这类工具，解决的是一次任务里的信息浪费。

但这个问题还有下一层。

如果一个 agent 今天已经查过项目结构，排除过错误方向，知道某个方案为什么不能用，明天它还要重新查一遍，那浪费就不只是发生在一次任务里，而是跨 session 重复发生。

为了解决这个问题，Agent Memory进入了大家的视野，它解决的是：每开一个新对话，别从头再读一遍。

过去我们用 AI，多数是一问一答：写文案、解释代码、生成方案。任务短，忘了影响不大。现在 agent 开始改代码、查日志、跟项目、维护文档，进入了连续工作，问题就变了。昨天留下的判断、约定和排查结果，会直接影响今天能不能少走弯路。

这就是 Agent Memory 最近变热的原因。不是“记忆”这个词新，而是 agent 的使用场景变了，我们不能总是从零开始。

一个 coding agent 如果每次新开 session 都要重新理解项目结构、技术栈、踩坑记录和用户偏好，它看起来是在工作，实际是在反复建立现场。

一、问题不是忘记，而是没有工作状态

聊天记录只是材料，真正有用的是状态。

一次事故排查可能有一万行日志和几十轮对话，但下次真正需要的，也许只有三条：问题发生在哪个模块，哪些方向已经排除，最后修复点在哪里。

技术选型讨论也是这样。完整对话可以存档，但下次真正有价值的是：为什么当时放弃 A，为什么选择 B，什么条件变化后需要重新做判断。

上下文窗口解决不了这个问题。窗口变大，只是桌面变大，可以摊开的材料更多；但它不会自动判断哪些材料有效，哪些已经过期，哪些只是噪声。

长期工作需要的不是更多历史，而是整理过的状态。

二、哪些历史应该留下来

agent 要有状态，第一步是从历史里提取以后还会用的信息。

难点不在存储，而在选择。用户说过的话，agent 做的动作，工具返回的结果。哪些只是临时信息，哪些会影响后面的任务？这一步判断错了，要么该记的没记住，要么不该记的留下来。

Mem0 主要处理这一层。它不是把完整对话塞回模型，而是从对话中提取事实、偏好和背景，整理成可检索的记忆，需要时再取回来。比如用户长期偏好某种回答风格，某个项目有固定技术约定，某个任务已经形成明确事实，这些都不应该每次重新解释。

agentmemory（github项目） 也在处理这一层，只是场景更具体。coding agent 需要留下来的，不只是用户偏好，还有工作过程：查过哪些文件，排除过哪些方案，踩过哪些坑，形成过哪些项目判断。它通过 hooks、MCP、REST API 把这些 session 过程记录，再在下次任务里注入相关记忆。

这两个工具不是在解决两个问题，而是在同一个问题上有不同侧重：Mem0 更通用，agentmemory 更贴近 coding agent。

这一层做不好，agent 每次都要重新认识现场。

三、留下来的信息什么时候还有效

历史留下来以后，马上会遇到第二个问题：状态变更。

项目以前用 pnpm，现在换成 bun。接口以前走老鉴权，现在迁到新中间件。用户以前偏好某种方案，现在因为团队变化改了标准。旧事实不是不存在，只是不能再当成当前事实使用。

很多记忆系统容易卡在这里。它们能把旧信息找回来，但不一定知道旧信息现在还算不算数。普通向量检索尤其容易遇到这个麻烦：只要语义相似，旧记录也可能被找出来。

Graphiti / Zep 的价值主要在这一层。它们不只是保存文本，而是把事实、实体、关系、来源和时间放进同一个结构里。某条事实什么时候成立，什么时候被替代，来源是什么，都要被记录下来。

长期记忆里最危险的东西，往往不是空白，而是过期信息。空白会让 agent 去查，过期信息会让 agent 自信地错。

所以，记忆不能只问“有没有”，还要问“现在还算不算数”。

四、能不能从经历里提炼经验

保存历史和更新事实，还只是基础。更难的是：agent 能不能从重复经历里提炼经验。

一个项目多次出问题都和权限层有关，这是一种项目风险。一个用户多次否掉复杂方案，偏向可调试、可维护的做法，这是决策风格。

这些东西不能靠单条记忆直接得到，需要从多次任务中归纳出来。

但这也是最容易出错的一层。用户只是某次赶时间选择了轻量方案，agent 却总结成“这个用户永远不喜欢重型架构”，以后就会稳定误判。

MemOS、Letta 这类方向有潜力，是因为它们不满足于 add 和 search。它们开始把记忆看成一种系统资源，考虑不同层级的记忆怎么组织、更新、版本化和使用。

这里关心的已经不是“能不能搜到一条历史”，而是大量记忆如何形成可管理、可修正、可复用的状态体系。

五、记忆多了以后谁来管

没有记忆，agent 每次从零开始；记忆太多、太乱，agent 又会被过去拖住。

临时决定、过期结论、错误判断、敏感信息，如果都长期留在系统里，记忆就会从帮助变成负担。

所以 memory 最后一定会碰到治理问题：什么可以长期记，什么只能短期保留，什么需要用户确认，什么应该被删除，哪些记忆可以跨项目共享，哪些必须隔离。

这也是 MemOS 这类项目把 memory 当成系统资源的原因。只要 agent 长期运行，记忆就不再只是外挂功能，而会变成系统的一部分。

记忆越有用，越不能乱记。

六、怎么看 Agent Memory 这个热点

看 Agent Memory，哪个库最火没有意义，把这些工具简单分成几个赛道也有点太片面。但是这些工具都在解决同一个大问题：agent 如何从无状态工作，走向有状态工作。

只是这个问题本身有几层：哪些历史应该留下来；留下来的信息什么时候还有效；能不能从重复经历里提炼经验；记忆多了以后怎么管理。

Mem0、agentmemory、Graphiti / Zep、MemOS 这些工具，分别在这些层面上有不同侧重。它们不是互相割裂的答案，而是同一个状态问题在不同位置上的解法。

模型能力解决的是这一次能不能做对，记忆系统解决的是下一次能不能少从头来。

Agent 真开始干活以后，这两个问题都重要。没有记忆，它可以一次次表现得聪明，但不能一天一天地积累，这就是 Agent Memory 今天变成真问题的原因。

参考：

Mem0： https://github.com/mem0ai/mem0

agentmemory： https://github.com/rohitg00/agentmemory

Graphiti： https://github.com/getzep/graphiti

MemOS： https://github.com/MemTensor/MemOS