给 AI 装上"长期记忆"：cognee 深度拆解，为什么它是 Agent 记忆层的最佳选择？

你有没有遇到过这种情况：跟 AI 助手聊了半小时，关掉窗口再打开，它把你当陌生人？或者让 Agent 帮你跟踪一个项目，第二天它连项目名都忘了？

这不是模型不够聪明，是架构本身没给"长期记忆"留位置。传统的 RAG 只能解决"静态知识库"问题，它无法处理跨会话的用户偏好、动态更新的业务状态，更别提多智能体之间的记忆共享了。

今天来拆解一个在 AI 记忆领域杀出重围的开源项目——cognee，GitHub 28.8K Stars，由微软 AutoGen 团队成员创办，BEAM 基准测试双杀 SOTA。看完这篇，你就知道为什么越来越多的 Agent 开发者选择它作为记忆层。

---

一、cognee 是什么？一句话讲透

cognee 是一个为 AI Agent 构建持久化长期记忆的开源平台。

它的核心思路是：把非结构化数据（对话、文档、日志）通过 LLM 自动提取实体和关系，构建知识图谱，再结合向量检索，让 Agent 拥有"理解+记忆"的能力。

用一句话概括：RAG 让 AI 能"查到"，cognee 让 AI 能"记住并理解"。

与传统 RAG 的区别在于：

维度	传统 RAG	cognee
存储方式	向量切片	知识图谱 + 向量 + 关系
检索方式	语义相似度	语义 + 图推理 + 关键词 BM25
关系理解	无	实体间关系自动推理
跨会话记忆	不支持	原生支持
数据更新	重新索引	增量更新

---

二、核心原理：ECL Pipeline 到底做了什么？

cognee 的技术核心是一条叫 ECL（Extract → Cognify → Load） 的端到端认知化流水线。别被名字唬住，我给你拆开讲。

2.1 Extract：从非结构化数据中提取知识

这一步用 LLM 从文本中抽取实体（Entity）和关系（Relation）。比如你告诉 Agent"张三在字节跳动做算法工程师"，Extract 阶段会抽出来：

• 实体：张三（人）、字节跳动（公司）、算法工程师（职位）
• 关系：张三-[就职于]->字节跳动，张三-[职位]->算法工程师

2.2 Cognify：认知化——生成认知本体

这是 cognee 最有技术含量的一步。它不是简单地把三元组塞进图数据库，而是基于认知科学自动生成认知本体（Cognitive Ontology）。

什么意思？就是说它会把提取出来的实体和关系，按照认知层次重新组织——哪些是核心概念，哪些是附属属性，哪些是因果链——形成一个有结构的、可推理的知识网络，而不是一堆松散的三元组。

2.3 Load：多后端存储

cognee 支持三类存储后端，你可以按需组合：

• 图数据库：Kuzu、Neo4j、Neptune —— 存实体关系和图结构
• 向量数据库：LanceDB、ChromaDB、PGVector、Qdrant、Weaviate、Milvus —— 存语义嵌入
• 关系数据库：SQLite、PostgreSQL —— 存结构化元数据

重点来了：cognee 1.0 版本推出了 Postgres 统一方案——整个记忆层可以跑在一个 Postgres 实例上（pgvector + Postgres graph backend + SQL session-cache），对中小团队来说部署成本直接降了一个数量级。

---

三、四大 API：记住、回忆、遗忘、进化

cognee 的 API 设计非常直觉，就四个动词：

3.1 remember() —— 知识存储

import cognee

# 添加文本到记忆
await cognee.add("document_name", "张三在字节跳动做算法工程师，他喜欢用 PyTorch")

# 触发 ECL Pipeline
await cognee.cognify()

调用 add() 后再调用 cognify()，ECL Pipeline 就会自动跑一遍 Extract → Cognify → Load，把知识存进图谱和向量库。

3.2 recall() —— 智能查询

# 自然语言查询，自动路由到最合适的检索方式
results = await cognee.search("张三用什么框架", query_type=QueryType.GRAPH_COMPLETION)

recall() 的厉害之处在于自动路由：它会根据查询类型，自动选择向量语义搜索、图结构推理还是关键词 BM25，或者三者混合。你不需要关心底层实现，问就完了。

3.3 forget() —— 精确删除

# 精确删除某个知识点
await cognee.delete("document_name")

知识图谱不是只进不出，forget() 可以精确删除过期或错误的知识，保持图谱的准确性。

3.4 improve() —— 反馈优化

基于用户反馈持续优化记忆质量，这是 cognee 区别于其他记忆框架的一个亮点——记忆不是一锤子买卖，它可以进化。

---

四、混合检索：为什么三种方式要一起用？

这是 cognee 在 BEAM 基准测试上碾压 SOTA 的关键。

• 向量语义搜索：擅长"语义相似"的查询，比如"深度学习框架"能匹配到"PyTorch"
• 图结构推理：擅长"关系推理"，比如"张三的同事用什么框架"需要先找到张三→同事→工具的路径
• 关键词 BM25：擅长精确匹配，比如搜"BERT"就是要找 BERT，不要给我整语义相似的

三种方式混合，cognee 在 BEAM 基准测试上交出了亮眼成绩：

• 100K tokens 规模：得分 0.79，超过 SOTA 的 0.735
• 10M tokens 规模：得分 0.67，超过 SOTA 的 0.641

大规模数据下优势更明显，因为图结构推理在数据量越大时，越能发挥关系网络的优势。

---

五、Session Memory：快慢结合的记忆架构

cognee 还有一个很实用的设计——Session Memory（会话级快速缓存）。

它的工作方式是：对话中的短期记忆先存在 Session Cache 里（快），后台异步同步到永久知识图谱（慢但持久）。这样既保证了对话中的响应速度，又不丢失长期记忆。

这就像人的大脑：海马体负责短期记忆的快速存取，大脑皮层负责长期记忆的持久存储，睡眠时把短期记忆"整理"到长期记忆中。cognee 的 Session Memory 就是这个思路的工程实现。

---

六、快速上手：5 分钟跑起来

6.1 安装

pip install cognee

6.2 最简配置（Postgres 统一方案）

import cognee
from cognee.infrastructure.databases.vector import PGVectorAdapter

# 配置 Postgres 作为统一后端
cognee.config.set_vector_db(PGVectorAdapter)
cognee.config.set_graph_db("postgres")  # Postgres graph backend

6.3 记住和查询

import asyncio
from cognee.api.v1.search import SearchType

async def main():
    # 添加知识
    await cognee.add("project_notes", """
    项目A使用 React + TypeScript 前端技术栈，
    后端是 Go 微服务架构，数据库用 PostgreSQL。
    负责人是李四，团队有8人。
    """)
    
    # 触发认知化
    await cognee.cognify()
    
    # 查询
    results = await cognee.search(
        "项目A的技术栈是什么", 
        SearchType.GRAPH_COMPLETION
    )
    print(results)

asyncio.run(main())

6.4 Agent 集成

cognee 提供了多种 Agent 集成方式：

• Claude Code 插件：直接在 Claude Code 中使用 cognee 记忆
• MCP Server：任何支持 MCP 的 Agent 框架都能接入
• Rust/TypeScript 客户端：跨语言支持

---

七、竞品对比：cognee vs Mem0 vs Graphiti vs Letta

这是大家最关心的部分。我选了四个最有代表性的竞品来对比。

7.1 Mem0：关系型记忆的"瑞士军刀"

• 定位：通用型个人记忆层，图+向量双栈
• 优势：生态最成熟（4.1万+ Stars），支持 LangChain、CrewAI 等主流框架，AWS Agent SDK 独家记忆提供商
• 劣势：基准测试争议（Letta 团队公开指控其造假），conflict detector 不够稳定，图谱增强版 Mem0g 延迟从 1.44s 涨到 2.59s
• 适合场景：需要快速集成、对精度要求不是极致的项目

7.2 Graphiti（Zep）：时序知识图谱专家

• 定位：时序感知的动态知识图谱
• 优势：双时态数据模型（记录事件发生时间和数据摄入时间），增量更新无需重算，查询延迟亚秒级
• 劣势：强依赖 Neo4j，部署成本高；时序能力虽强但通用性不如 cognee
• 适合场景：需要精确时间回溯查询的场景（医疗、金融、法律）

7.3 Letta（MemGPT）：上下文管理元老

• 定位：有状态 Agent 框架，上下文管理为核心
• 优势：UC Berkeley 孵化，白盒设计，模型无关，可视化调试
• 劣势：更偏 Agent 框架而非纯记忆层，记忆能力不如专门的记忆框架深入
• 适合场景：需要完整 Agent 开发框架，记忆只是其中一环

7.4 Microsoft GraphRAG：静态文档摘要专家

• 定位：微软开源的 GraphRAG 方案
• 优势：对静态文档的全局摘要能力很强
• 劣势：批处理模式，无时序能力，延迟高（数秒到数十秒），不支持增量更新
• 适合场景：静态文档的全局理解和摘要

7.5 一图胜千言

维度	cognee	Mem0	Graphiti	Letta	GraphRAG
核心技术	知识图谱+向量+BM25	图+向量双栈	时序知识图谱	上下文管理	图+全局摘要
记忆类型	语义+结构+关键词	语义+关系	时序+关系	上下文窗口	静态摘要
增量更新	✅	✅	✅	❌	❌
时序感知	❌	❌	✅✅	❌	❌
部署复杂度	低（Postgres统一）	中	高（需Neo4j）	中	高
BEAM得分	0.79/0.67	争议数据	—	—	—
GitHub Stars	28.8K	41K+	5K+	19K	20K+
研究论文	✅ arxiv 2505.24478	✅ 争议	✅	✅	✅

我的建议：

• 如果你要最均衡的记忆方案，选 cognee——混合检索+Postgres统一部署+学术背书
• 如果你追求生态和快速集成，选 Mem0——但要注意基准测试争议
• 如果你需要精确时序回溯，选 Graphiti——但准备好 Neo4j 的运维成本
• 如果你要完整的 Agent 框架，选 Letta——记忆只是它的子功能
• 如果你只做静态文档理解，选 GraphRAG——但别指望它处理动态数据

---

八、写在最后

AI Agent 的下一个突破点不在模型参数量，而在记忆。一个没有长期记忆的 Agent，就像一个每天失忆的助手——能力再强，也无法持续为你服务。

cognee 的设计哲学很清晰：用认知科学的方式组织知识，用混合检索的方式利用知识，用简洁的 API 暴露能力。28.8K Stars 不是白来的，BEAM 基准测试的双杀 SOTA 也不是吹的。

如果你在做 Agent 开发，强烈建议花一个下午把 cognee 跑起来，感受一下"有记忆的 Agent"和"没记忆的 Agent"之间的差距。

GitHub 地址：https://github.com/topoteretes/cognee

研究论文：arxiv 2505.24478《Optimizing the Interface Between Knowledge Graphs and LLMs for Complex Reasoning》

---

觉得有用？转发给你身边做 Agent 开发的朋友，让他们也少走弯路。有问题欢迎留言讨论。