当Agent有了“长情”的大脑：深度拆解与对比Mem0/Graphiti/Cognee三大开源Memory方案

作者：秋山墨客

转载自AI大模型应用实践

我们在之前的一期中梳理过AI智能体长期记忆（Long-Term Memory）的常见实现策略（参考阅读：一文全解析：AI 智能体 8 种常见的记忆（Memory）策略与技术实现 ）。但大部分时候我们并不需要“手动搭积木”，本篇就将聚焦几款即插即用的开源Agent Memory项目，深入拆解它们的架构与特点，帮助我们从不同的维度来认识与对比它们，以在真实项目中作出选择。

今天的选手包括Mem0、Graphiti（Zep）、Cognee这三位。

这里只讨论“纯粹的Memory 框架”。像MemGPT（Letta）这种以 Memory 机制为核心、但本质上是完整Agent框架的项目，本篇暂不纳入讨论范围。

PART 01

Agent Memory再认识：与RAG/上下文工程的关系

我们知道，LLM天生是“健忘”（无状态）的。每次与它交互，模型不会记住之前的交互内容 - 它唯一关注的仅限于一个“上下文窗口”。但上下文窗口有限，超出窗口的内容怎么办？

这意味着：

即便用户在对话早期已经说明“我不吃辣”“我喜欢自然风光”“我希望邮件都用正式语气”等偏好，只要信息被挤出上下文，LLM 就会立刻“失忆”，需要用户再次重复。在持续对话时如此，在跨会话、多天乃至多周的使用中更是如此。

这种“短记性”严重影响AI Agent的体验：你不可能每次使用旅游规划助手，都强调你喜欢自然风光而不是人文景观：

所以，让Agent拥有更“长情”的大脑 — 长期记忆能力变得至关重要。

所谓长期记忆，在AI Agent的语境下就是：

为 Agent 引入一种可持续更新的记忆机制，使其能够在未来对话和任务中“回忆”过去的重要信息，从而变得更懂你、更个性化、更智能。

或者说，长期记忆像给LLM配备了随写随取的笔记本：重要的信息可以记录下来，需要时再取用，从而突破上下文窗口的限制。

AI 中的两类记忆：陈述性 vs 程序性

人类记忆可分为陈述性记忆（知道“是什么”）和程序性记忆（知道“怎么做”）。类似地，AI Agent的长期记忆也可大致分成这两类：

陈述性记忆（Declarative Memory）：关于事实和事件的知识 。它回答的是各种“是什么”的问题 — 无论是世界知识还是用户的具体信息。比如用户的姓名、喜欢的美食，曾遭遇过的事件等，都属于陈述性记忆 。

程序性记忆（Procedural Memory）：关于技能和流程的知识 。它指导Agent“如何”完成任务，就像行动指南。如果一个记忆能回答“怎么做”的问题（例如订票需按什么步骤调用哪些工具），就是程序性记忆 。

举个例子，假设有个AI客服，陈述性记忆可以是“这位用户上次投诉货物破损”，程序性记忆可以是“如何引导愤怒的用户冷静下来”的一套对话策略。

长期记忆与RAG：笔记本 VS 图书馆

长期记忆与我们所熟知的RAG（检索增强生成）是什么关系呢？毕竟RAG也同样是“在需要时再检索”。

但实际上，两者在系统设计中的定位完全不同：

Memory 更像一本随时可写、可删、可更新的“笔记本”或“硬盘”；而 RAG 更像一套结构稳定、更新不那么频繁的“参考书体系”。

用下面的表格总结Memory与RAG的差异：

总体上，RAG有助于Agent更准确的回答问题；而Memory则有助于Agent表现的更加智能。在更多时候，你需要同时使用它们：

如果缺少RAG：AI可能很了解用户，但可能回答“不够专业”。

如果缺少Memory：AI有很专业的知识，但却不够个性化。

长期记忆在上下文工程中的角色

记忆是上下文工程（Context Engineering）的重要支柱之一。

在编排上下文工程的过程中，长期记忆作为一种最重要的上下文来源之一，与其他的系统指令、工具定义、Few-shot示例、近期对话历史、RAG知识等，一起被拼装与输入。而作为上下文工程，你需要考虑：

哪些内容需要保存成长期记忆？

什么时候保存？由谁来判断？

未来如何召回？召回粒度是多少？

如何修剪、更新、合并？

Memory的生命周期本质上都属于上下文工程的一部分，从生成、存储、检索、到修剪。所以，Memory并不是一个简单的外挂模块，而是上下文工程中重要的组成部分，用来管理 “跨会话、个性化、需要长期保留的信息”。

PART 02

Mem0：开箱即用的智能记忆管理引擎

Github Star: 43.6K

Mem0 可能是目前最广为人知的独立 Agent Memory 产品，由初创团队 Mem0.ai 开源推出。它的目标是为 LLM 提供可持续更新的个性化长期记忆，既可自托管也可使用云服务，是最易落地的 Memory 引擎之一。

核心架构

Mem0 的核心是记忆存储与管理，当前支持向量存储与图存储两种模式：

向量存储：这是默认的模式。用于存储语义向量，可进行语义相似检索，适合用户偏好、事件摘要等内容。

图存储：用于存储实体及关系，用知识图谱表示更复杂的结构，如企业内部门关系、供应链结构等。

两者可组合使用，形成混合记忆系统。其管理流程用下图表示：

当添加记忆时，LLM提取关键事实（知识、决策等），并做向量存储

如果启用Graph，LLM会同时提取实体与关系，并存储到图数据库

写入记忆时Mem0会自动进行冲突检测，避免重复记忆或矛盾记忆

根据检测结果，Mem0决定是添加新记忆，还是更新或者删除旧记忆

需要注意：

冲突检测要求必须使用LLM来提取事实，而不能直接存储原始文本

默认不会进行的图知识提取，必须提供图数据库的存储配置

混合检索：如果启用Graph模式，那么在检索时会同时进行向量搜索与图搜索，且向量搜索的结果会被用来缩小图搜索的范围：

快速上手

以下是一个简化示例，演示如何利用Mem0存储用户的个性化记忆：

调用add接口添加一条用户信息，Mem0会将“user_123更喜欢自然风光"这个事实存入记忆库（通常由LLM来提取，也支持直接存储原始文本）。

当下次需要时（如下一次Agent任务），可以按需检索：

搜索结果中会返回先前存储的偏好信息。你只需要把它添加到 LLM 的上下文中，LLM 就会表现得像“记住了”你的喜好，更好地完成后续的任务。

在真实的对话Agent中，这些调用也可能由LLM框架自动触发：任务结束后存储记忆，新任务开始时自动检索并注入上下文。

能力特点

这里总结Mem0的核心能力与特点：

组合存储架构

默认的向量库用于语义检索；图数据库用于实体与关系的知识图谱表达。两者结合可同时捕捉“相似语义”与“结构关系”。

多级记忆体系

同时维护用户级、会话级和代理级的记忆。用户级记忆用来存储用户长期偏好，会话级记录当前上下文，代理级记忆则可跨用户地共享知识 。

记忆分类与检索

Mem0 支持自定义目录（category），并通过 LLM 自动分类。配合元数据过滤，可实现更精细的记忆搜索。

多模态记忆

Mem0 能从图像 + 文本的多模态输入中提取可记忆信息，例如从发票、屏幕截图、产品照片中抽取关键事实。

记忆质量管理

支持记忆时间戳、冲突检测、智能过滤（识别“哪些需要记忆”）等机制，保持记忆时间线清晰、内容一致、冗余可控。

简洁易用，低侵入性

Mem0 易于集成到现有 LLM 应用中，几行代码即可为系统加入记忆能力。并兼容 LangGraph 等主流智能体框架，适合快速构建“可进化”的 Agent。

PART 03

Graphiti：时序知识图谱与结构化记忆

Github Star: 20.5K(Graphiti）

Graphiti 是由 Zep 团队开源的一套知识图谱型记忆引擎。它的路线非常鲜明：用动态演化的“时间知识图谱”来承载 AI 的长期记忆。它可以将 AI 的交互内容与业务知识不断融合进一个统一的知识图谱中，并借助图数据库实现结构化、可解释、可推理的记忆管理。

Graphiti 的商业版是 Zep，它在 Graphiti 之上加入了大量工程化能力。Graphiti 则是其开源核心引擎，但部分周边能力需要自行搭建。

核心架构

Graphiti引入时间知识图谱的概念，专门为AI Agent设计：它能够将对话内容（非结构化）和业务数据（结构化）纳入同一图谱，不断增量更新，并保留历史演化关系。其工作流程描述为：

事件记录（Episode）：每当有新信息到来时，Graphiti将其视为一个“事件”（episode）。事件可以是聊天消息、文档文本，或者JSON数据流 。开发者通过调用add_episode接口把事件添加到知识图谱。

增量解析：Graphiti对文本进行处理清洗，借助LLM提取出其中提到的实体（nodes）及它们之间的关系（edges），并识别文本中的时间信息（如日期、时间点），将其用于实时更新知识图谱。

图谱更新：将解析出的实体和关系并入知识图谱中。当新信息与旧事实冲突时，Graphiti不会简单覆盖旧事实，而是根据时间戳将旧关系标记为“已失效”，再创建新的事实关系，保证可追溯性 。这种时间轴模型让AI可以回答诸如“去年xxx的职位是什么？”这样的问题。

混合索引检索：Graphiti内置多类型索引与排序机制。对于复杂问题，Graphiti可以综合语义搜索、关键词匹配和图谱关系推理，实现混合检索。

快速上手

以下展示如何在Graphiti添加不同类型事件，及其时间轴的构建：

在这个例子中的事件具有很多时间特性，你将可以看到Graphiti如何构建时序的知识图谱，进而保持历史的可追溯。

能力特点

Graphiti的能力特点总结如下：

基于知识图谱的可解释性

记忆以图谱呈现，结构清晰、关系直观，非常适合需要可溯源的企业级场景。

支持自定义实体与关系类型

支持通过 Pydantic 模型自定义实体与关系，能够更精准地抽取特定领域知识，减少不必要的“噪声记忆”

“双时间轴”的表达与动态更新

同时记录时间发生时间和记入图谱时间。可以进行时间推理和因果分析，适用于复杂的企业场景。

强大的混合搜索能力与策略

支持广泛混合搜索、或者指定节点的距离重排序搜索。甚至可通过底层配置定制更复杂的搜索策略。

卓越的性能、Token成本低

Graphiti 减少了大量的LLM总结等调用，使得性能得到大幅提升 — 延迟低、所需token更少，非常适合实时性的应用（如语音助理、在线客服等）。

Graphiti相对其他记忆引擎的不足主要在于：

必须依赖图存储，因此在“纯自由对话”类场景中，实体抽取容易产生噪声，不如向量记忆自然。

图数据库本身需要额外的部署成本和资源，整体工程复杂度更高。

对开发者要求较高，需要理解知识图谱建模，学习成本更高一些。

PART 04

Cognee：向量+图谱+本体的知识记忆平台

Github Star: 9.4K

Cognee 是Memory开源框架的后期之秀，专为 AI 代理构建持久化记忆。它能够将原始数据转化为可搜索的“智能记忆层”，并通过 向量检索 + 图数据库 + 本体结构 的组合，使数据既能进行语义相似检索，又能进行结构化推理。同大部分开源的Memory方案一样，Cognee 也提供托管云服务。

Cognee 的底层采用多重存储架构：

关系存储：跟踪文档、数据块以及它们的来源与关联

向量存储：保存文本嵌入，用于语义相似度检索

图谱存储：记录实体与实体之间的关系

这使得 Cognee 在检索时能够同时使用向量搜索与知识图谱推理，形成更强的混合查询能力。

核心架构

用下图来表示Cognee的核心架构：

Cognee 的底层由以下核心组件组成：

Tasks：最小的数据处理单元，例如文本到实体/关系的解析

Pipelines：多个 Task 组成的工作流，比如一次完整的从输入到图谱完成

DataPoints：图谱中的一个信息实体（Pydantic 模型），如“员工”等

但实际使用中，开发者会通过更“上层”的接口完成主要流程：

数据添加（Add）： 使用 cognee.add 接口将文本、对话、文件等多种数据源导入系统 ，系统会自动切分文档并为后续处理做准备。

构建知识图谱（Cognify）： 调用 cognee.cognify 后，Cognee 利用内置的抽取任务，从已添加的数据中识别实体/关系，生成知识图谱 。

语义增强（Memify）： （可选）在已构建的图谱上运行 cognee.memify，可进一步利用语义算法对图谱进行丰富和优化。

混合检索（Search）： 使用 cognee.search 可对构建好的知识图谱发起向量相似度与图遍历等的混合查询，返回检索结果 。

快速上手

以下示例展示一个最小可用的 Cognee 流程：

这里的流程非常直观：添加 → 构建图谱 → 查询。

核心特点

Cognee的能力特点总结如下：

端到端记忆架构

Cognee 将向量存储、图数据库和推理管道整合为统一的记忆引擎，使 AI 代理能从图谱中连贯地检索知识 。

高可定制本体体系

支持基于 RDF / OWL 本体 的知识结构定义，你可以通过自定义任务与管道来表示特定行业的实体、属性与关系。

RDF 和 OWL是语义网领域的标准化本体语言，以特定序列化格式（如 XML）描述领域的知识结构、语义关系与约束。

多源数据互联

能够处理对话记录、文档、图片、音频等 30 多种数据类型，实现多模态信息的记忆构建 。

混合检索能力

提供语义相似性查询和知识图遍历查询的混合策略，可在查询时同时利用向量匹配和图结构关系 。

良好的生态集成能力

Cognee支持与广泛的LLM、嵌入模型、结构化输出框架、关系数据库、图数据库、向量数据库的集成。

Cognee 具有新颖的设计与强大的功能。其目前不足主要体现在：

对开发者要求相对较高，需要同时维护向量库、图数据库甚至本体体系。

项目相对较新，文档、生态、工具链仍在快速成长中。

架构复杂度高于一般 Memory 方案，更适合复杂业务场景。

PART 05

对比与选择建议

介绍完以上三种主流长期记忆方案，我们从多个角度对它们做一个整体汇总，便于在真实项目中选择最适合的方案。

【产品策略】

三者都采用“开源核心 + 商业托管平台”的双轨模式：开源负责吸引开发者、降低集成门槛；商业平台提供更完善的工程能力、监控、托管与企业级功能。

Mem0：记忆逻辑、向量存储、检索全部开源，社区迭代活跃。

Graphiti：是 Zep 的开源核心引擎，但完整体验需要配合商业版 zep（监控、UI、长文档存储等）。

Cognee：知识抽取、管道、存储层等全部开源，支持本地完全自托管。

【记忆架构】

Mem0：最初是轻量向量记忆，现在也支持动态图式记忆（混合存储）。

Graphiti：以时间知识图谱为中心，强调事件、关系与时序演化。

Cognee：向量 + 知识图谱 + RDF/OWL 本体，多种结构结合的完整知识记忆引擎。

【功能侧重】

Mem0：对话型记忆的提取、冲突检测、自动更新与高效检索。简单易集成，是给对话 Agent 加“长期记忆”的最快方式。

Graphiti：强项是结构化知识图谱、双时间轴模型和混合搜索推理，在事件流、CRM、人事、客服等场景更适合。

Cognee：最全面的知识记忆平台，能处理向量、图谱、本体等多层次知识结构，适合构建大型企业知识库或“企业知识大脑”甚至替代RAG。

【性能】

三者都通过不同方式提升性能与降低 Token 成本，例如减少 LLM 调用、提升记忆质量、异步处理等。其中Graphiti在更复杂的企业场景测试中将准确率进一步提高，并让响应速度快了一个量级。

【灵活性与定制】

Mem0：轻量、开箱即用，配置项少、上手成本低，但可定制能力相对弱。

Graphiti：可自定义实体、关系等图谱结构，但强依赖图模型，对“松散型记忆”不太友好。

Cognee：三者中灵活性最高，自定义本体、任务管道、实体/关系等都非常自由，支持多类型存储。

【兼容性与集成开发】

三者都兼容主流LLM、向量数据库、图数据库、MCP 协议、LangGraph 等。但集成体验有区别：

Mem0：最省力。几乎能直接“插入”现有应用，几行代码即可获得长期记忆。

Cognee：次之。功能强大但架构更复杂，需要少量学习。

Graphiti：最复杂。限定在知识图谱模型，需要理解且API使用更复杂些。

用这张图进行汇总：

最后，用一句话总结三者的典型使用场景：

你的目标是快速给对话式Agent添加记忆？ 建议选 Mem0

最简单、最省心、几乎零学习成本。

你的数据涉及事件、人物、流程，需要时序推理？ 选 Graphiti

CRM、人事系统、客服场景的好选择。

你需要构建“企业级知识大脑”或“带本体的多模态知识库”？ 选 Cognee

最强的表达能力、最高的灵活性。

当然，真正的选型仍需根据你的数据类型、业务复杂度、团队能力、可维护成本综合权衡。

END