Agent 老是失忆？这四个记忆项目能治，附选型清单

先说说你大概也遇到过的那个问题

你用 Agent 帮你干活的时候，有没有过这种挠头时刻？

前一天配合得好好的，活儿干得漂亮，收工的时候心满意足。第二天再打开，问它「昨天那个事怎么样了」——它一顿读文件，读完整理，整理完还是没记全。你只好重新交代背景、重新说清上次的结论，一趟下来，光「复习」就花掉十几分钟。

这不是模型不够聪明，是它没有记住你的地方。

Agent 越普及，这事就越扎眼。一个人一天可能同时用三四个 Agent——写代码的、查资料的、写文案的——每个都记不住，每个都要重讲一遍。于是「给 Agent 加记忆」成了一条热闹的赛道，GitHub 上叫得出名字的项目就有十几个。

今天我们挑了四个近期关注度高、涨得快的：

四个都自称解决"Agent 记不住事"。但把它们放在一起，"Agent 记忆"这个词其实装不下四种不同的东西。

专业分析

一、分歧的第一层：到底"记住什么"

这是四家分道扬镳的地方，而且选择各不相同：

• ai-memory 记的是观察：Agent 在工作时通过生命周期钩子静默发出"已脱敏的观察"，会话结束时这些观察被整理成项目 wiki 里的 markdown 页面
• cognee 记的是数据：任何格式摄取进来，建成自托管知识图谱，重点是"连起来"
• Memori 记的是动作：它的口号很明确——Memory from what agents do, not just what they say（记忆来自 Agent 做了什么，不只是说了什么）
• hindsight 记的是观察 + 心智模型：从观察提炼出"mental models & knowledge pages"

注意这个差异的分量：记"对话"的系统，最后会变成聊天记录检索器；记"动作"的系统，才有可能回答"上次这个任务是怎么做完的"。这一层选错，后面所有优化都白费。

二、分歧的第二层：怎么把它取回来

• ai-memory：下一个会话（任意 Agent、任意机器）拿到一份有边界的简报（bounded brief），同时可以搜索全文、实体、链接、可选向量，融合成单一排序
• cognee：先查会话记忆，不够再落到图谱上
• Memori：结构化存储 + 按需检索——它的公开数据是 87% 准确率、平均 721 token/查询，只占全上下文 2.8%，比 Zep 省约 67% 的 prompt，比"全塞上下文"省 36 倍成本
• hindsight：三个动作分得很清——retain（存）、recall（取）、reflect（提炼）

这里最值得单独说的是 Memori 那组数字。它证明了一件违反直觉的事：记忆的瓶颈不是"能不能记住"，而是"取回来的时候占多少上下文"。721 token 意味着记忆系统本身几乎不消耗预算——对每天跑几百次调用的生产环境，这是决定性的差别。

而对"多 Agent 协作"最直接的是 ai-memory 的 handoff：跨 Agent 交接时显式传递接力棒。读过它架构文档的话会发现，它专门写了一节"保持多用户、多会话安全的不变式"——说明它踩过这方面的坑。

三、分歧的第三层：给谁用

这一层决定产品形态，也最容易被忽略：

hindsight 的"记忆银行"值得单独提：它用 banks 做隔离，配上 per-user 元数据——这是多租户场景的正确答案。相比之下，把所有人的记忆堆在一个池子里、靠检索去区分，迟早会串味。

关联信息与影响

第一个影响：给选型的人省了时间。 这四个项目经常被放在同一篇文章里"推荐"，但它们其实不可互换。问自己三个问题就知道该选谁：你要记住的是动作还是对话？取回来时能不能承受大上下文？是单人多机还是多人多租户？

第二个影响：它暴露了这块赛道真正没解决的事。 四个项目里，没有一个把"多人协作同一个项目时的记忆共享"当成核心问题——banks 解决的是隔离，handoff 解决的是单人接力。当两个不同的人、用两个不同的 Agent 在同一个项目上干活时，记忆该怎么合并、冲突该怎么裁决？ 这个问题目前是空着的。

第三个影响：评测标准还不统一。 hindsight 拿 LongMemEval 的 SOTA 说事，Memori 拿 token 成本和准确率说事，cognee 谈的是平台能力。没有公认的评测口径，就意味着"哪个最好"这个问题现在没有答案——而这恰恰是早期赛道的特征。

未来展望

短期，记忆系统会先出现功能收敛：结构化存储 + 检索预算控制（Memori 那套思路）+ 多租户隔离（banks 那套思路）会成为标配，而不是差异点。

中期，真正的分水岭在跨 Agent / 跨人类协作。单机记忆已经很卷了，但当多个 Agent 分属不同的人，记忆的"合并、授权、冲突裁决"才是新的深水区。谁先解决这个，谁就从"记忆库"升格成"协作基础设施"。

长期看，记忆系统可能会像数据库一样分层：底下的存储引擎、中间的检索与压缩策略、上面的领域模型（编程 / 研究 / 客服各有各的记忆结构）。到那时，"这个 Agent 记得住吗"会变成"它的记忆架构对不对"。

需要泼的冷水：这些项目的公开数据几乎都是自测口径。Memori 的 721 token 是它自己的 benchmark，hindsight 的 SOTA 也是它自己引用的评测。在没有第三方横向复现之前，任何"某某最强"的说法都只是营销。 更现实的判断方式是：拿你自己的数据跑一遍。

信号强度

• 正在选型的开发者：先回答"记动作还是记对话""单用户还是多租户"这两个问题，再看 Star。选错了，Star 再高也白搭。
• 做多 Agent 产品的团队：重点看 ai-memory 的 handoff 设计和 hindsight 的 banks——前者是接力，后者是隔离，这两件事你迟早都要做。
• 维护内部 Agent 平台的团队：Memori 那组"721 token / 2.8% 上下文"的数字值得当成预算红线，记忆系统的成本要单独计量，不能混在总账里。
• 普通用户：暂时不用管。但可以留意一个信号——什么时候你的 AI 助手能主动说出"上次那件事后来怎么样了"，说明这套东西真正落地了。

SIGNAL FILE · 情报档案

对比四家会发现，分歧根本不在技术选型，而在"回答哪个问题"：ai-memory 解决"换个 CLI 就丢上下文"（capture→consolidate→recall→handoff），cognee 解决"把任意格式数据变成可查图谱"，Memori 解决"别把上下文塞爆"（721 token/查询、2.8% 占用），hindsight 解决"记忆要有多准"（LongMemEval SOTA + 银行隔离）。选型的第一问不是"哪个 Star 多"，而是"你要解决的是哪一个"。

本文基于 AI 情报库收录的条目展开深析；事实性信息以原始报道为准，分析与展望为编辑观点。

原始报道：https://github.com/topoteretes/cognee（GitHub）

查看原始报道 ↗返回首页