Agent记忆方案“三国杀”！Mem0 vs Graphiti vs Cognee，一文读懂技术优劣与选型！

关注

原创最新推荐文章于 2026-11-10 16:06:23 发布 1.8k 阅读 AI 写同款· GEO 优化 ›

Agent 长期记忆三代演进：从 RAG 到 Memory Graph，mem0 / Zep / LangMem / Letta 深度横评文章摘要 2026年，Agent长期记忆技术迎来关键突破，OpenAI、Anthropic等厂商通过扩大上下文窗口和推出记忆工具，推动长期记忆从工程补丁发展为独立技术层。本文通过分析三代记忆架构演进（RAG→结构化Fact→MemoryGraph）和四大方案（mem0/Zep/LangMem/Letta）的8维度横评，揭示以下核心观点：长上下文≠长期记忆：128K上下文如同RAM，仍需硬盘式记忆层筛选和结构化存储，避免“Context Rot”导致的准确率下降。三代架构演进： Gen1（RAG）：向量检阅读详情

本篇就将聚焦几款即插即用的开源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存储用户的个性化记忆：

from mem0 import Memory# 初始化Mem0客户端（假设已设置API密钥）mem = Memory()# ...添加必要的记忆：存储用户的一条自述信息mem.add([{"role": "user", "content": "我更喜欢自然风光而不是人文景观"}], user_id="user_123")

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

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

...# 在记忆中根据输入来检索results = mem.search('请帮我设计旅游方案', user_id="user_123")print(results["results"][0]["memory"])# 将检索的记忆添加到上下文....

搜索结果中会返回先前存储的偏好信息。你只需要把它添加到 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添加不同类型事件，及其时间轴的构建：

......      episodes = [        {            'content': '卡玛拉·哈里斯是加利福尼亚州总检察长。她之前是旧金山的地方检察官。',            'type': EpisodeType.text,            'description': '播客文字稿',        },        {            'content': '作为总检察长，哈里斯的任期是从 2011 年 1 月 3 日到 2017 年 1 月 3 日',            'type': EpisodeType.text,            'description': '播客文字稿',        },        {            'content': {                'name': '加文·纽森',                'position': '州长',                'term_start': '2019年1月7日',                'term_end': '至今',            },            'type': EpisodeType.json,            'description': '播客元数据',        },    ]    for i, episode in enumerate(episodes):        await graphiti.add_episode(            name=f'Freakonomics Radio {i}',            episode_body=episode['content']            if isinstance(episode['content'], str)            else json.dumps(episode['content']),            source=episode['type'],            source_description=episode['description'],            reference_time=datetime.now(timezone.utc),        )    results = await graphiti.search('谁是加利福尼亚州总检察长？')

在这个例子中的事件具有很多时间特性，你将可以看到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 流程：

import cognee# 1. ADD：添加文本数据await cognee.add(    "我叫张伟，是公司的销售总监。",    dataset_name="user_profile")# 2. COGNIFY：构建知识图谱（触发 LLM 实体与关系抽取）await cognee.cognify(["user_profile"])# 3. SEARCH：混合检索（向量 + 图）results = await cognee.search("公司的销售总监是谁？")

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

核心特点

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

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

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

如何学习大模型 AI ？

由于新岗位的生产效率，要优于被取代岗位的生产效率，所以实际上整个社会的生产效率是提升的。

但是具体到个人，只能说是：

“最先掌握AI的人，将会比较晚掌握AI的人有竞争优势”。

这句话，放在计算机、互联网、移动互联网的开局时期，都是一样的道理。

我在一线互联网企业工作十余年里，指导过不少同行后辈。帮助很多人得到了学习和成长。

我意识到有很多经验和知识值得分享给大家，也可以通过我们的能力和经验解答大家在人工智能学习中的很多困惑，所以在工作繁忙的情况下还是坚持各种整理和分享。但苦于知识传播途径有限，很多互联网行业朋友无法获得正确的资料得到学习提升，故此将并将重要的AI大模型资料包括AI大模型入门学习思维导图、精品AI大模型学习书籍手册、视频教程、实战学习等录播视频免费分享出来。

在这里插入图片描述