cognee 深度解读

“不只是记住，而是理解——用 Ontology 把信息织成可推理的知识网络”

一句话定位

把非结构化数据转化为可推理知识网络的 ECL 管线引擎，强调”认知”（Cognify）而非简单”记忆”——Extract-Cognify-Load 三步曲，是 7 个项目中最接近”知识工程框架”的方案。

设计哲学上最精彩的地方

cognee 的名字来自 cognition（认知），它的目标不仅是”记住”信息，而是“理解”信息之间的关系。它用 Ontology（本体论）来组织知识——先定义领域中的概念和关系类型，再把非结构化文本映射到这个结构上。

日常类比：mem0 是往笔记本上一条一条记事实，cognee 是画一张概念地图——不仅记录”A 是什么”，还记录”A 和 B 是什么关系”、”A 属于哪个类别”。笔记本查东西靠翻找，概念地图查东西靠沿线走。这个区别在简单场景感受不到，在多跳推理（”小明同事的公司在哪个城市”）时差异巨大。

ECL 三步管线——最工程化的检索架构

cognee 的检索是一个三步管线：Retrieve（从向量/图数据库获取候选）→ Rerank（cross-encoder 或 LLM 重排）→ Filter（根据置信度阈值过滤）。每一步都是可插拔的——换图数据库、换排序模型、调过滤阈值，互不影响。这种管线式设计在 7 个项目中是最工程化的，和 Graphiti 的两阶段检索相比多了显式的过滤层。

同时 cognee 的 add()（对应 ECL 的 Extract）也是管线化的：文档分块 → 实体识别 → 关系提取 → Ontology 映射 → 存入图/向量双库。写入和检索都是可插拔管线，这让 cognee 的定制化能力在 7 个项目中最强。

多图后端的工程挑战

cognee 同时支持 Kuzu（嵌入式图数据库）、Neo4j（企业级）和 FalkorDB（Redis 兼容）作为图存储后端。但三个图数据库的查询语言、数据模型、事务语义完全不同。最典型的问题是 Kuzu 的 RelatesToNode_ 前缀约定——Kuzu 是强类型的，每种关系需要固定的源/目标节点类型，新增关系就得建表；Neo4j 不需要。这导致了大量后端特化代码，是”同时支持多后端”的隐性成本。

场景边界——太重

cognee 的代码量最大（~2290 文件），复杂度最高。Ontology-based 知识组织比 mem0 的”自由提取事实”更结构化，但也更脆弱——本体定义不完整会漏信息，定义过宽会降质量。它更像一个”知识工程框架”而非”记忆系统”，适合需要深度知识组织的企业场景，对个人 Agent 或轻量记忆来说太重了。

本地代码结构

cognee/
  cognee/
    api/                       # 顶层 API（add / cognify / search）
    tasks/
      ingestion/               # 数据摄入（文档分块、格式解析）
      graph/                   # 图构建（实体提取、关系映射）
      summarization/           # 摘要生成
    modules/
      retrieval/
        base_retriever.py      # 三步管线基类
        graph_retriever.py     # 图检索
        vector_retriever.py    # 向量检索
      graph/
        neo4j_driver.py        # Neo4j 后端
        kuzu_driver.py         # Kuzu 后端
        falkordb_driver.py     # FalkorDB 后端
      ontology/                # 本体定义与映射
      storage/                 # 向量/关系/Blob 存储抽象
    infrastructure/            # 底层基础设施
  tests/
  docs/

本地关键文件