把蓝色外套记成牛仔裤，90%的系统都是花架子

---

今天搞了个得罪人的事——我在一个技术群里说，市面上90%的Agent“记忆”，本质就是个花里胡哨的数据库查询。

群里安静了大概三秒。

然后炸了。

讲真，我理解大家的反应。谁愿意承认自己花三个月搭的记忆系统，跟MySQL查表没啥本质区别？但你先别急着喷，听我讲个翻车现场。

去年帮一个电商客户搭客服Agent。他们技术团队贼自信，说“我们用了最先进的向量记忆方案”。结果上线第一周，用户问“我上次说的那个蓝色外套还有货吗”，Agent回了三个月前另一个用户问蓝色牛仔裤的对话。

翻车了。

这事儿让我琢磨了很久。咱们行业对“记忆”这个词用得忒随意。存个对话历史叫记忆，搞个RAG也叫记忆，往prompt里塞几段检索结果还叫记忆。概念膨胀得跟双十一的购物车似的——塞了一堆，有用的没几个。

记忆不是存得多，是忘得对

2024年12月，新加坡国立大学、人大、复旦、北大那帮人联合发了篇百页综述《Memory in the Age of AI Agents》（arxiv.org/abs/2412.13564）。我熬了两个通宵看完，说实话——好久没看到这么硬核的综述了。

他们提了个三角框架：Forms（形式）、Functions（功能）、Dynamics（动态）。

这框架挺野。它不问你“记了多久”，而是问三个更根本的问题：记忆存在哪儿？用来干嘛？怎么演化？

你细想。

传统的长短期记忆二分法，已经不够用了。一个Agent在代码仓库里记住的“这个函数调用链容易出bug”，跟它记住的“用户喜欢在周三下单”，能是一回事吗？前者是经验提炼，后者是偏好记录。但很多系统——包括我早期搭的那些——把它们都扔进同一个向量库，检索时靠相似度碰运气。

这不出问题才怪。

我在自己的项目里测过Mem0（2024年4月那版）。它用图结构做记忆表示，能从对话里动态提取实体关系。效果确实比纯向量检索强，至少不会把“蓝色外套”和“蓝色牛仔裤”搞混。

但它的图更新策略——不对，应该叫图演化策略——在长对话里还是会膨胀。

我跑了大概300轮对话后，图里塞了快2000个节点。检索延迟从80ms涨到了400ms。

400ms。

这就没法用了。用户等三秒就跑了，谁等你400ms查记忆？

那些论文到底在解决什么问题

我挑几个实际用过的说说。不是纸上谈兵，是真金白银花时间测过的。

MemOS（2024年3月）把记忆操作抽象成读/写/删/反思四个动作。思路挺野，我在一个研究型Agent上试过。它允许Agent自己决定“这段信息该不该存”。

结果你猜怎么着？

Agent变得特别抠门。重要推理步骤它觉得“显而易见”就不存了，下次遇到类似问题又得重推一遍。我当时看着日志，又好气又好笑——这Agent怎么跟我一样，该记的不记，不该记的瞎记。

这事儿教会我一个道理：记忆系统的写入策略，不能完全交给模型自己判断。得有个外部校验机制。或者说，至少得有个兜底的规则。不然它比我还懒。

PREMem（2024年9月）的思路就务实多了——把推理负担前置到写入阶段。存储时就提炼好，检索时直接用。

我在客服场景里测过，个性化回复质量确实提升了。但写入延迟增加了大概1.2秒。

1.2秒。

对于实时对话来说，这个代价有点肉疼。用户说“你好”，你花1.2秒存记忆，再花0.3秒生成回复——黄花菜都凉了。

Tencent MAICC（2024年11月）搞了个软遗忘机制。不硬删旧记忆，而是逐步衰减权重。

这个想法挺符合认知科学的。Active Forgetting那篇2021年的综述就论证过，前额叶皮层的主动遗忘不是bug，是feature。我在一个长期运行的Agent上试了软遗忘，确实比硬删除更稳定。至少不会出现“突然忘了某个重要用户偏好”的尴尬——那场面，想想都社死。

R³Mem（ACL 2024）那篇更激进，搞可逆上下文压缩，号称高压缩比下无损恢复。

说实话，我测试时没达到论文里那么漂亮的数据。压缩比到8倍时还行，到16倍就开始丢细节了。大概是任务场景不同吧——他们测的是标准benchmark，我测的是真实用户对话，噪音多得多。

也可能是我没调好参数。嗯，大概率是。

但反正我跑出来的结果就这样。16倍压缩，细节丢得跟筛子似的。

记忆共享是个大坑

多Agent协作场景里，Memory Sharing（2024年5月那篇）提出了记忆同步协议和冲突消解策略。

我在一个三Agent协作系统里试过。两个Agent对同一个用户的偏好得出了不同结论，冲突消解模块选了“投票机制”。

结果呢？

两个Agent都觉得自己对，第三个Agent弃权。系统僵在那儿了。我盯着日志看了十分钟，突然觉得这场景莫名熟悉——像极了我们组会讨论技术方案时的样子。

后来我改成了基于置信度的加权融合，效果好一些。但引入了新问题：高置信度的错误记忆会污染整个共享池。

这事儿目前没有完美解法。

我试过加人工审核节点，但那就违背了自动化的初衷。两难。真的两难。

别把RAG和Memory混为一谈

这是我最想吐槽的。真的，听多了头疼。

RAG是检索，Memory是记忆。检索是你去图书馆查资料，记忆是你脑子里存的东西。两者可以配合，但不是一回事。

很多团队把对话历史切片扔进向量库，然后说“我们实现了Agent记忆”。这就像你把所有聊天记录截图存硬盘里，然后说“我有记忆了”。

存储不等于记忆。

记忆需要组织、提炼、遗忘、演化。这四个动作，少一个都不叫记忆。

那篇综述里把Agent Memory和RAG、Context Engineering的边界厘清了。建议所有做Agent的人都看看。至少别再跟我说“我们用Pinecone实现了记忆功能”这种话了。

讲真，每次听到这种话，我都想反问：那你用MySQL算不算记忆？

我的实操建议

基于这两年踩的坑——真的是踩了无数坑——我总结几条野路子经验：

先定义记忆的功能，再选存储形式。是记事实？记经验？记偏好？还是记当前任务状态？不同功能对应不同技术栈。事实用知识图谱，经验用参数微调，偏好用结构化存储，任务状态用上下文窗口。别搞混。搞混了就是灾难。

遗忘机制比记忆机制更重要。一个不会忘的Agent会越来越慢、越来越蠢。我在Mem-α（2024年9月，基于RL的记忆构建）上看到过类似结论——最优策略往往包含主动遗忘。不是存得越多越好。这个洞察，值回我读那篇论文的时间。

还有，写入成本别忽略。PREMem那种前置推理的方案效果好，但延迟高。MemTool（2024年7月）提供了三种可配置的短期记忆架构，在效率和性能之间做权衡。思路值得参考。你得根据场景选，没有银弹。别听那些卖产品的忽悠。

另外，别迷信端到端。MemoryLLM（2024年2月）试图用隐空间记忆池自动管理一切。我测过，在小规模任务上还行，任务一复杂就崩。显式记忆加隐式记忆的混合方案（比如MMAG，2024年12月）更实用。至少出问题了你能debug。能debug的东西，才是能用的东西。

这个领域还在野蛮生长

说实话，2024年Memory相关的论文井喷，但很多都是换个名字重新发明轮子。A-MEM借鉴Zettelkasten笔记法，Nemori模拟人类记忆的自动聚类，ChemAgent搞混合更新——想法都挺好。

但工程落地时你会发现，真正好用的还是那些朴素的方案。

我现在的做法是：短期用MemTool管理上下文，长期用Zep（基于时序知识图谱，支持软更新）存结构化事实，经验类知识直接微调模型参数（AlphaEdit那套局部编辑思路）。

三个系统各司其职。

比一个“大一统记忆方案”稳定得多。当然，这套组合拳也有问题。维护成本高，三个系统的同步偶尔会出岔子。但至少比把一切都交给一个黑盒记忆模块强——出问题了我知道该查哪个系统，而不是对着一个巨大的向量库发呆。

这就够了。

记忆这事儿，说到底不是技术问题，是认知问题。你得先想清楚“这个Agent需要记住什么、为什么需要记住、记多久、怎么忘”，然后才谈得上技术选型。

别一上来就选向量数据库。

那是偷懒。

---

下一篇我打算写写Memory的评估协议。现在这个领域最大的问题不是没方案，是没法横向对比。各家论文用的指标都不一样，跟菜市场似的——你说你的白菜好，我说我的萝卜甜，谁也说服不了谁。

你们觉得呢？有没有遇到类似的问题？或者有没有什么好用的评估框架推荐？留言聊聊。