Agent 记忆系统学习笔记（五）：从 Cognee / LightRAG 看懂知识图谱型长期记忆

写在前面：为什么最后看 Cognee / LightRAG

前四篇看的是 Agent 与用户交互中的记忆问题：

Mem0：从对话中抽取可召回事实
Zep：把事实放进时间知识图谱
Letta：让 Agent 自主管理上下文层级
LangGraph：提供状态、checkpoint、store 等框架抽象

这一篇转向另一条路线：知识图谱型长期记忆。

代表项目是 Cognee 和 LightRAG。

这类系统的核心问题不是“用户喜欢什么”，而是：

如何把大量文档、代码、网页、数据库和业务记录
变成 Agent 可以长期查询、持续更新、保留来源、理解关系的知识记忆？

这和简单向量 RAG 不一样。向量 RAG 更擅长找“语义相似片段”，但它不天然知道：

哪些实体有关联
这个事实来自哪里
两个文档是否在讲同一个对象
关系是局部的还是全局的
一个回答需要跨多少跳关系

GraphRAG 型记忆试图补上这部分。

一、为什么 Agent 记忆不只是聊天记录

如果只做个人助理，一个 memory layer 可能主要存用户偏好：

用户喜欢中文
用户是前端工程师
用户正在研究 Agent memory
用户不喜欢太长的回答

但很多真实 Agent 面对的是另一类问题：

读一个公司代码库
理解一组产品文档
查询历史工单
分析客户会议记录
回答跨文档问题
在企业知识库中做多跳推理

这时，“记住用户说过什么”远远不够。系统需要记住的是一个外部世界：

产品、模块、接口、人员、项目、客户、事件、文件、版本、依赖关系

这些东西不适合只放成一堆孤立 memory，也不适合只靠 embedding 相似度。

比如用户问：

这个 API 改动会影响哪些下游模块？

这不是一个单纯语义相似问题，而是关系问题。

再比如用户问：

A 客户最近提到的性能问题，和之前哪个版本的改动有关？

这又是实体、时间、来源、事件之间的组合问题。

所以 Cognee / LightRAG 这类系统会把“记忆”建成图。

二、Cognee：把数据变成可持续改进的 AI memory

Cognee 的定位很直接：它是一个开源 AI memory 平台。

它的基本目标是把各种数据源转成长期可查询、可改善、可遗忘的记忆。相比传统 RAG，Cognee 更强调 memory 这个概念，因为它不只是存 chunks，而是维护实体、关系、向量和来源。

Cognee 的一个重要特点是三层存储：

Relational Store：管理来源和元数据

关系数据库负责管理数据对象本身：

documents
datasets
chunks
users
permissions
pipeline 状态
来源 metadata

这层很容易被忽略，但在真实应用里非常重要。因为记忆不是一堆无主文本。你需要知道：

这条记忆来自哪个文档
属于哪个用户或组织
是否可以被当前用户访问
什么时候写入
是否应该被删除

没有这层，长期记忆很快会变成无法治理的数据垃圾场。

Vector Store：负责语义相似

向量库存 embeddings。

它负责回答：

哪些文本片段和当前问题语义相近？
哪些 DataPoints 可能相关？

这是传统 RAG 的核心能力，Cognee 没有放弃它。区别是：向量检索只是 Cognee 记忆系统的一部分，不是全部。

Graph Store：表达实体和关系

图数据库存实体和关系。

它负责回答：

A 和 B 是什么关系？
某个实体连接到哪些事件？
这个模块依赖哪些服务？
某个客户的问题和哪些工单、版本、人员相关？

这层让记忆从“相似片段集合”变成“可导航的知识结构”。

三、Cognee 的 remember / recall：把底层 pipeline 包成记忆操作

Cognee v1.0 的抽象很有意思。它把用户面对的主要操作概括成四个：

remember：写入记忆

remember 可以写永久记忆，也可以写带 session_id 的会话记忆。

永久记忆通常会进入完整处理链路：

数据规范化
切块
提取实体和关系
生成 DataPoints
写入关系库、向量库、图数据库
建立可检索结构

这相当于把原始数据变成长期知识记忆。

会话记忆则更像短期或中期上下文。它适合保存一次会话中的内容，并在之后按 session-aware 的方式召回。

recall：召回记忆

recall 不只是做一次 embedding search。Cognee 会根据查询和参数自动路由到不同检索方式，例如：

session memory
graph completion
temporal search
summary search
chunk search

这里的关键变化是：召回不再等于“top-k chunk”。

召回变成一个路由问题：

当前问题需要最近会话？
需要某个实体的图邻居？
需要时间范围？
需要摘要？
还是只需要语义片段？

improve：持续改进记忆

improve 的意义是：长期记忆不是一次性索引，而是可以持续改进。

一个系统可能先把会话写成 session memory，之后再把其中稳定、有价值的内容提炼到永久图记忆里。

这和人类记忆很像：不是每一句话都立刻进入长期记忆，而是经过整理、抽象、合并后才稳定下来。

forget：可治理的遗忘

长期记忆一定需要遗忘。

原因很简单：

数据可能过期
用户可能撤回授权
事实可能被更新
低质量记忆会污染召回
法规要求可删除

所以 GraphRAG 型记忆不能只考虑“怎么存更多”，还要考虑“怎么删除、怎么隔离、怎么审计”。

四、LightRAG：轻量图增强 RAG 引擎

LightRAG 的目标和 Cognee 接近，但气质不同。

Cognee 更像一个 AI memory platform，强调 remember / recall / improve / forget 这样的记忆操作。

LightRAG 更像一个轻量 GraphRAG 引擎，强调高效索引、实体关系抽取、增量更新，以及多种查询模式。

LightRAG 的典型流程是：

1. 文档切分成 chunks
2. LLM 从 chunks 中抽取 entities 和 relations
3. 生成实体、关系、文本片段的 embedding
4. 写入图存储、向量存储、KV / 文档状态存储
5. 查询时根据模式组合局部图、全局图和向量片段

它的查询模式很有代表性：

local：围绕具体实体做局部检索
global：查全局主题、社区和宏观关系
hybrid：合并 local 和 global
naive：传统向量 chunk 检索
mix：综合 local / global / naive

这说明一个问题：GraphRAG 并不是要替代向量检索，而是把向量检索放进更大的检索框架。

当问题是“某个实体附近发生了什么”，local graph 很有用。

当问题是“这个知识库整体上有哪些主题”，global graph 更有用。

当问题只是找一段相似文字，naive vector search 反而足够。

好的记忆系统应该能在这些模式之间切换。

五、图检索和向量检索到底差在哪

这一点非常关键。

向量检索回答的是：

哪些文本和 query 在语义空间里接近？

图检索回答的是：

哪些实体通过关系连接？
这条关系是什么类型？
可以沿关系走到哪里？

两者解决的问题不同。

向量检索的优势

向量检索适合：

模糊语义匹配
找相似段落
召回没有明确实体的问题
处理自然语言表达差异
快速搭建 baseline RAG

它的弱点是：

关系结构弱
多跳推理弱
来源和实体合并困难
容易召回语义相近但关系不对的片段

图检索的优势

图检索适合：

实体关系查询
依赖分析
多跳推理
时间线和事件链
跨文档归并

它的弱点是：

建图成本高
实体抽取和关系抽取会出错
schema 设计复杂
图过大后检索和排序也不简单

所以 Cognee / LightRAG 这类系统通常不会二选一，而是同时保留图和向量。

真正的问题不是“图好还是向量好”，而是：

当前问题应该先走语义相似，还是先走实体关系？
召回结果如何合并、去重、排序、压缩？

六、GraphRAG 型记忆和前几篇方案的关系

现在可以把整个系列串起来。

Mem0、Zep、Letta、LangGraph 关注的主要是 Agent 与用户交互时的记忆。Cognee / LightRAG 则更偏 Agent 面对外部知识世界时的记忆。

和 Mem0 的区别

Mem0 更像“用户级长期偏好记忆”。

它适合记录：

用户喜欢什么
用户是谁
用户过去说过哪些稳定事实
当前回答前应该召回哪些个人记忆

Cognee / LightRAG 更适合记录：

一个组织的知识库
一个代码库的实体关系
产品文档里的概念依赖
跨文档、跨实体、跨事件的知识网络

和 Zep 的区别

Zep 也是图，但它的图更偏“对话中出现的事实、实体、关系、时间”。

Cognee / LightRAG 的图更偏“外部知识库里的实体、关系、文档、主题”。

粗略说：

Zep：conversation graph memory
Cognee / LightRAG：knowledge graph memory

当然二者边界不是绝对的。Cognee 也支持 session memory，Zep 也能处理知识关系。但它们默认关注点不同。

和 Letta 的区别

Letta 关心 Agent 如何管理自己的上下文窗口：

核心记忆放什么
外部记忆何时查
上下文满了如何换页
Agent 如何主动编辑 memory

Cognee / LightRAG 关心知识库本身如何组织：

文档怎么切
实体怎么抽
关系怎么建
图和向量怎么共同召回

一个是 Agent 内部上下文管理，一个是外部知识记忆基础设施。

和 LangGraph 的区别

LangGraph 是编排框架。

你完全可以在 LangGraph 的某个 node 里调用 Cognee 或 LightRAG：

用户问题进入 graph
node 先读 thread state
再调用 Cognee / LightRAG 检索知识记忆
把检索结果和短期 state 一起喂给 LLM
必要时把新信息写回 store 或外部 memory platform

也就是说，LangGraph 和 Cognee / LightRAG 不是替代关系，而是上下游关系。

七、什么时候该用 GraphRAG 型记忆

不是所有 Agent 都需要 GraphRAG。

如果你的应用只是：

个人聊天机器人
简单客服 FAQ
少量文档问答
用户偏好记忆

那纯向量 RAG 或 Mem0 这类 memory layer 可能已经够了。

但如果你面对的是：

大型文档库
代码库理解
企业知识库
跨文档事实合并
多实体关系推理
需要来源追踪和权限治理
知识持续更新

那 GraphRAG 型记忆就值得考虑。

它真正适合的问题有几个特征：

实体很多
关系重要
上下文跨文档
问题经常需要多跳
来源和权限不可忽略
知识会持续增长和被修正

反过来，如果只是把十几篇文章做问答，强行上知识图谱可能是过度工程。

八、我的判断：GraphRAG 是长期知识记忆，不是万能记忆

看完 Cognee / LightRAG，我的判断是：GraphRAG 型系统解决的是“长期知识记忆”，不是所有 Agent 记忆问题。

它非常适合把外部数据世界变成可查询结构。

但它不直接解决这些问题：

当前任务执行到哪一步
用户刚刚在这个 thread 里说了什么
Agent 应该如何修改自己的行为规则
哪些用户偏好应该立刻生效
会话上下文满了怎么办

这些仍然需要 LangGraph、Letta、Mem0、Zep 或你自己的状态系统来处理。

所以我更愿意把 Agent memory 分成两大类：

交互记忆：围绕用户、对话、任务、偏好、行为改进
知识记忆：围绕文档、实体、关系、来源、跨文档推理

Cognee / LightRAG 是第二类的代表。

它们提醒我们：长期记忆不仅是“用户说过什么”，也可能是“世界是什么样的”。

九、整个系列的收束

写到这里，这个系列可以形成一个比较完整的地图：

Mem0：事实抽取与多信号召回
Zep：带时间维度的对话知识图谱
Letta：Agent 自主管理上下文层级
LangGraph / LangMem：框架级状态、store 和记忆类型抽象
Cognee / LightRAG：知识图谱增强的长期知识记忆

如果把它们按问题来分：

这也说明，Agent 记忆不是单点能力，而是一组系统能力的组合。

一个成熟 Agent 可能同时需要：

checkpointer 保存当前 thread state
store 保存用户长期偏好
memory extractor 抽取稳定事实
graph memory 管理实体关系和时间
knowledge memory 检索外部知识库
prompt optimizer 改进行为规则
forget / permission / provenance 做治理

这就是为什么“给 Agent 加记忆”听起来简单，真正做起来却非常复杂。

因为你不是在加一个数据库，而是在设计 Agent 与时间、用户、知识和自身行为之间的关系。

参考资料

• Cognee Documentation
• Cognee GitHub
• Cognee Core Concepts
• Cognee Architecture
• LightRAG GitHub
• LightRAG Paper EOF