Cognee 替代品对比：5款AI Agent记忆工具怎么选

🇺🇸
Read in English: Cognee Alternatives: 5 AI Agent Memory Tools Compared

你有没有遇到过这种情况：跟一个 AI 客服机器人聊了半小时,把问题背景交代得清清楚楚,结果第二天再打开对话,它把你当成第一次见面的陌生人,一切从头再问一遍。你说自己上周提交过退货申请,它一脸茫然让你重新描述订单号；你告诉它自己对某个功能过敏,下次它照样把这个功能推给你。

这不是模型笨,是它压根没有”记忆”这个概念。大语言模型本身是无状态的,每次对话结束,上下文就随着会话关闭而消失，模型能记住的只有当前这一次输入窗口里塞进去的内容,窗口一关，前面聊过什么、确认过什么、纠正过什么,全部清零。想让 agent 记住用户是谁、上次讨论到哪、哪些偏好已经确认过,靠的不是模型本身,而是外挂在模型旁边的一层记忆系统，这层系统要在对话结束后把关键信息提炼出来存起来,下次对话开始前再把相关的部分找回来塞回上下文。

这件事说起来简单，做起来处处是坑。存什么、存多久、怎么判断两条信息谁更新、检索的时候怎么知道该翻出哪一条,这些问题背后各有一套技术路线,而且路线之间的差异不是细枝末节，是决定了整套系统未来能不能扩展、要不要绑定某个框架的架构级选择。

这两年做 agent 开发的人,几乎都绕不开这个问题。市面上冒出了一批专门解决”AI 怎么记事”的工具,cognee 是其中比较受关注的一个。它把用户的对话历史、文档、结构化数据统一处理成知识图谱,存进图数据库,再配合向量检索做召回,GitHub 上已经攒了三万多星标。但它不是唯一的答案，围着”agent 长期记忆”这个赛道,还长出了 Mem0、Letta、Zep 这几个思路完全不同的项目，也有人干脆放弃现成方案，用向量数据库自己搭一套。

搞清楚这几个工具到底在解决什么问题、彼此差在哪,比记住哪个 star 数更高更有用。毕竟选错了记忆层,返工的成本比选错数据库还高，数据结构一旦定下来，agent 的行为逻辑也跟着长在上面了。

cognee 本身在做什么

先说清楚 cognee 的定位，不然后面的对比会失焦。它的核心思路是把”记忆”当成一条数据处理流水线：把非结构化的文本（聊天记录、文档、代码）丢进去，通过一系列可配置的处理步骤，抽取出实体和关系，构建成知识图谱,同时生成向量嵌入用于语义检索。存储层可以接 Neo4j 或者用内置的 NetworkX 做轻量方案,向量部分对接 Qdrant 或 Weaviate。

这套东西是开源的（GitHub: topoteretes/cognee），可以完全自托管。官方也提供托管云服务，Developer 档 35 美元一个月，Team 档 200 美元一个月。使用上有个绕不开的前提：无论自建还是走云端，生成嵌入向量都需要接 OpenAI 的 API key，也就是说即便你把整套系统部署在自己的服务器上，向量化这一步仍然依赖外部服务，这一点在做数据合规评估的时候容易被忽略。

搞清楚这个前提，再去看其他几个工具的思路差异，会更容易理解为什么它们不是简单的”平替”关系，而是解决同一个问题的不同路径。

cognee 的处理流程本身是可插拔的，官方文档里把这套流程称为 pipeline：数据先经过分块、抽取、打标签这些步骤，再送进图数据库和向量库两套存储。这种设计让它比较适合那种数据源本身就很杂的场景。你可能同时要处理客服聊天记录、产品文档、用户上传的 PDF，cognee 的流水线思路能把这些异构数据统一处理成同一种图结构，后续无论是做语义检索还是做关系查询，都在同一套存储里完成。这也是为什么不少做知识管理、企业内部知识库的团队会关注这个项目，而不只是做单纯的对话记忆。

Mem0：先把记忆做成一个通用 API

如果说 cognee 的思路是”先建图谱,再谈记忆”,Mem0 走的是完全相反的路子:先把记忆抽象成一个简单的接口，增、删、改、查,让开发者不用关心底层用的是向量库还是图数据库,调用几行代码就能给任何 agent 框架接上记忆能力。

这种”轻集成”的设计,让它在需要快速验证想法的团队里很受欢迎。项目在 GitHub 上（mem0ai/mem0）已经积累了接近六万星标,协议是 Apache-2.0，自托管完全免费，功能上不设阉割。官方托管平台分了四档:免费的 Hobby 档每月一万次记忆写入、一千次检索;往上是 Starter，19 美元一个月;Growth 档 79 美元;顶配 Pro 档 249 美元一个月，这一档才解锁图记忆能力、更高级的检索方式，以及 SOC 2、HIPAA 一类的合规认证。

值得留意的一点是，Mem0 的锁定程度很低。它就是一个记忆服务,和你的 agent 框架、编排逻辑之间是干净的接口边界。真到某天想换掉它,把记忆调用换成别的实现就行,agent 的其他部分几乎不用动。这跟接下来要说的 Letta 是完全不同的哲学。

有个容易被高估的地方是基准测试成绩。第三方对比文章里流传的 LoCoMo 分数版本不一，有的表格写 Mem0 得分 68.5，Mem0 官方研究页给出的数字是 92.5，两边差距不小。这类第三方复现的基准数字,建议当参考而不是定论,真要评估还是拿自己的场景跑一遍最靠谱。

Letta：让 agent 自己管理记忆

Letta 之前的名字是 MemGPT，这个改名背后其实是产品定位的收窄和聚焦。它的思路来自一篇论文（Packer 等人,arXiv:2310.08560），核心比喻是操作系统管理内存的方式：核心记忆常驻在上下文窗口里，相当于 CPU 寄存器；归档记忆按需检索，相当于磁盘存储。关键差异在于，agent 本身可以主动编辑自己的核心记忆块，决定什么信息该留在”寄存器”里、什么该换出到”磁盘”。

这不是一个你调用的记忆 API，而是一整套agent运行环境。用 Letta，相当于把整个 agent 的运行逻辑托管在它的框架里，好处是记忆管理这件事变得很”聪明”，agent 能自主判断信息的取舍；代价是你不再只是接入一个记忆库，而是在采用一整个agent操作系统，框架绑定的程度明显更深。

Letta 同样是 Apache-2.0 协议开源（GitHub 星标两万三千左右），自托管免费，且不做功能阉割，桌面端 ADE（Agent Development Environment）界面也从早期的强制云端使用改成了本地就能跑,门槛降了不少。托管云服务 Pro 档 20 美元一个月起,再往上根据活跃 agent 数量和工具调用量计费，适合需要跑一批长期在线 agent 的团队。

对比 Mem0，Letta 更适合那种”我要构建的本身就是一个复杂的自主 agent，记忆只是其中一个环节”的场景；如果你只是想给现有系统外挂一层记忆，Mem0 的轻量接入方式会更省心。

有个细节值得展开说说：Letta 的核心记忆块是可以被 agent 自己改写的，这意味着记忆的准确性某种程度上取决于 agent 自身的判断力。如果底层模型在总结、取舍信息上表现不稳定，记忆内容也会跟着漂移，这跟 Mem0、Zep 那种由外部规则或算法统一管理记忆写入的方式,风险分布是不一样的。选 Letta 相当于把一部分记忆治理的责任也交给了模型本身，这对模型能力和 prompt 设计的要求会更高一些。

Zep：用时间维度的知识图谱记事

Zep 解决的是另一类问题：不只记住”发生了什么”，还记住”这件事是什么时候成立的、后来有没有被推翻”。它底层用的是 Graphiti 这个时序知识图谱引擎，存的不是静态事实，而是带时间戳、带有效期的关系。举个例子，用户上个月说自己在北京工作，这个月说搬到了上海，Zep 能区分这两条信息哪个是”当前有效”，哪个是”历史事实”，而不是简单覆盖或者两条信息打架。

这种时间敏感的记忆模型，在需要长期跟踪用户状态变化的场景（比如客服系统、私人助理）里价值明显，官方给出的 LoCoMo 基准分数是 94.7%，LongMemEval 是 90.2%，响应延迟控制在一百多毫秒。

需要说明的是 Zep 的开源边界。Graphiti 图引擎本身是开源的，Apache-2.0 协议，可以自己接 Neo4j、FalkorDB 或者 Kuzu 这类图数据库自托管。但完整的 Zep 平台功能，尤其是企业级的治理能力（数据访问控制、留存策略、审计日志、SOC 2 Type II、HIPAA BAA），只在 Zep Cloud 里提供，走的是按信用点计费的模式，Flex 档每月 25 美元包含两万点，往上 Flex Plus 每月 475 美元对应三十万点。早期那个可以整体自托管的 Community Edition 版本已经停止维护，现在开源路线只剩 Graphiti 加一个外部图数据库，跟 Mem0 那种”SDK 一装就能跑”的自托管体验不是一回事。

自己搭一套向量方案，值不值得

前面三个都是现成产品，但不少团队的第一反应是：干嘛不直接拿 Chroma 或者 Postgres 加 pgvector 自己搭一套记忆层？把对话内容切片、生成 embedding、存进向量库，检索的时候按语义相似度取回最相关的几条，逻辑不复杂，市面上教程一大把。

这条路的好处是控制权完全在自己手里，不依赖任何第三方服务的可用性和定价策略，数据全程留在自己的基础设施里。代价也很直接：知识图谱那类需要理解实体关系、时间演变的记忆场景，纯向量检索天然处理不好，因为它只按语义相似度召回，缺乏结构化的关系推理能力。记忆的写入策略（什么该存、什么该丢弃、怎么去重）、检索的排序逻辑,这些原本是现成工具帮你趟过的坑，自建方案要自己一点点补齐,前期省下的接入成本,很可能在后期维护上还回去。

还有个容易被忽视的成本是团队规模。现成工具背后有社区和文档在支撑排错，自建方案出了问题只能自己啃源码。如果团队里没有人专门负责维护这套记忆层，随着业务逐渐依赖它，技术债会越滚越大，等到真出问题的时候，往往已经积累了不少历史包袱。所以自建这条路更适合团队本身就有向量检索经验、且明确知道自己不需要复杂关系推理的场景，纯粹图个省钱、图个数据不出自己家门。

摆在一起看会更清楚

把上面这几款放进同一张表,对比维度选了开源协议、部署方式、定价起点这几个能直接查证的硬指标,而不是主观的”好不好用”：

工具	开源协议	自托管	云服务起价	核心存储
cognee	开源	支持	Developer $35/月	Neo4j/NetworkX + Qdrant/Weaviate
Mem0	Apache-2.0	支持,无功能阉割	Starter $19/月	自建向量库+图（Pro档）
Letta	Apache-2.0	支持,无功能阉割	Pro $20/月起	PostgreSQL/SQLite
Zep (Graphiti)	Apache-2.0（引擎）	仅图引擎部分	Flex $25/月	Neo4j/FalkorDB/Kuzu
自建向量方案	N/A	完全自主	N/A（基础设施成本自负）	Chroma/pgvector 等

表格能看出的是硬指标，看不出的是适用场景。这几个工具与其说是互相替代，不如说是分别在回答不同的问题：你要的是一个能随手接入任何 agent 的记忆接口，还是一整套让 agent 自己管理状态的运行环境，又或者是需要精确追踪信息随时间变化的关系图谱。

回到最开始那个场景，如果只是想让客服机器人记住用户上次说过什么，Mem0 这种轻量接入的方式大概是投入产出比最高的选择；如果你正在从零搭建一个长期在线、需要自主决策的复杂 agent，记忆管理只是整套系统里的一环，Letta 提供的操作系统式思路会更贴合；要是业务里存在大量随时间变化的事实（合同状态、用户身份信息、订单流转），并且需要能解释”这个结论是什么时候成立的”，Zep 的时序图谱是目前唯一专门为这个问题设计的方案。至于 cognee，它的知识图谱构建流水线适合那种数据源本身就杂、需要从文档和对话里提炼实体关系的场景，如果团队已经接受了引入 OpenAI 依赖这个前提，它的自托管灵活度是几个选项里比较高的。

没有哪一个是绝对正确的答案，取决于你要解决的是接入问题、状态管理问题，还是时间维度的事实追踪问题。想清楚这一点，再去看 GitHub 星标数或者定价页面，才不会被表面数字牵着走。