Hotdry.

Article

6行代码构建AI代理知识图谱：Cognee从非结构化数据提取可查询知识引擎

深入解析开源项目Cognee如何用极简API实现知识图谱自动提取，结合向量搜索与图数据库为AI代理构建持久记忆系统。

2026-04-16ai-systems

在大语言模型应用开发中，如何让 AI 代理拥有持久记忆并支持复杂的关联查询，一直是工程化落地的重要挑战。传统方案需要分别搭建向量检索、图数据库存储、实体抽取管道，代码量动辄数百行。Cognee 项目的出现改变了这一局面 —— 它将知识图谱提取、向量嵌入、图数据库存储封装为四个简洁的 API，仅需六行代码即可完成从非结构化文本到可查询知识引擎的完整构建。

Cognee 的核心设计理念

Cognee 定位为 AI 代理的记忆引擎（Knowledge Engine），其核心理念是将任意格式的非结构化数据转化为可推理的知识图谱，同时保留向量语义检索能力。项目采用混合存储架构：图数据库（如 Neo4j）存储实体与关系，支持多跳推理；向量数据库（如 Qdrant、Pgvector）存储语义嵌入，支持相似度检索。这种双引擎设计使得系统在回答 “查找与某实体通过 N 层关系连接的节点” 这类复杂查询时，仍然保持高效。

从技术栈来看，Cognee 主体采用 Python 实现（占比 86.5%），通过 asyncio 实现异步管道；前端采用 TypeScript 构建可视化界面。项目原生支持 OpenAI、Anthropic Claude、Google Gemini 等多种大语言 provider，并提供 Claude Code 插件和 Hermes Agent 集成，方便开箱即用。

六行代码实现知识图谱提取

Cognee 对外暴露的核心 API 只有四个：remember（记忆）、recall（召回）、forget（遗忘）、improve（优化）。以下是基于这四个 API 的标准使用模式：

import cognee
import asyncio

async def main():
    # 永久存储到知识图谱（自动执行 add + cognify + improve）
    await cognee.remember("Cognee turns documents into AI memory.")
    
    # 会话级缓存存储，异步同步到图数据库
    await cognee.remember("User prefers detailed explanations.", session_id="chat_1")
    
    # 自动路由查询（系统自动选择最优检索策略）
    results = await cognee.recall("What does Cognee do?")
    for result in results:
        print(result)
    
    # 查询会话缓存，命中失败则回退到图数据库
    results = await cognee.recall("What does the user prefer?", session_id="chat_1")
    
    # 数据清理
    await cognee.forget(dataset="main_dataset")

asyncio.run(main())

这六行代码背后隐藏着完整的数据处理管道。当调用remember时，系统首先对输入文本进行分块处理，然后调用底层 LLM 进行实体抽取和关系识别，接着将提取的实体节点和关系边写入图数据库，同时生成向量嵌入存入向量存储。recall方法支持自动路由机制 —— 系统会根据查询意图判断是走向量检索、图数据库遍历还是混合策略。

关键配置参数与工程实践

在实际生产环境中使用 Cognee，需要关注以下几个关键配置点。

环境配置方面，项目要求 Python 3.10 至 3.13 版本。通过 pip 或 uv 安装后，需要在环境变量中配置 LLM API 密钥：设置LLM_API_KEY为对应的 OpenAI API Key，或者创建.env文件使用项目提供的模板。Cognee 还支持 Ollama 本地部署，适合对数据隐私有严格要求的场景。

数据源接入方面，Cognee 内置了多种数据格式的解析器，支持 PDF、Markdown、JSON、CSV 等常见格式。开发者可以通过cognee.add方法显式指定数据源和解析策略，也可以使用高级封装remember自动推断处理方式。对于大规模文档处理，建议先使用cognee.add进行批量 ingestion，再调用cognee.cognify执行知识图谱转换，最后通过cognee.improve优化图谱质量。

检索策略方面，Cognee 的recall方法支持三种模式：向量检索（semantic search）、图数据库遍历（graph traversal）、混合模式（hybrid）。默认的自动路由机制会根据查询复杂度自动选择，但对于高频生产场景，建议显式指定策略以获得更可预测的延迟和资源消耗。以下是显式指定检索模式的示例代码：

# 纯向量检索，适合语义相似度查询
results = await cognee.recall("find similar concepts", strategy="vector")

# 纯图遍历，适合关系推理查询  
results = await cognee.recall("what entities are connected to X", strategy="graph")

# 混合模式，兼顾语义与关系
results = await cognee.recall("complex reasoning query", strategy="hybrid")

部署选项方面，Cognee 提供多种部署路径：Cognee Cloud 提供全托管服务；自托管可选择 Modal（serverless GPU 负载）、Railway（简化 PaaS）、Fly.io（边缘部署）、Render（托管 Postgres）等平台。项目在 GitHub 上提供了完整的部署脚本，位于distributed/deploy/目录下。

知识图谱与向量检索的技术对比

理解 Cognee 的设计，需要回到知识图谱与向量检索的技术选型问题。根据 2025 年行业实践，两者在不同场景下各有优劣。

向量检索（RAG）适合单跳语义查找，优势在于快速搭建和广泛的文档搜索能力。其工作原理是将文本分块后生成向量嵌入，查询时计算向量距离返回最相似的结果。这种方式实现简单、延迟低，但对于需要理解实体间关系的复杂查询（如 “哪些客户受到供应商 A 的政策变化影响”）表现不佳。

知识图谱提取在多跳推理、显式关系建模、可解释性要求高的场景中优势明显。图结构可以精确表达 “公司 A 持有公司 B 的股份，公司 B 参股公司 C” 这类层级关系，并支持路径查询和推理验证。2025 年的研究表明，基于依赖解析器的知识图谱管道在成本显著低于 LLM 生成方式的同时，可达到约 94% 的性能表现。

Cognee 的混合架构正是对这一技术趋势的回应：通过统一 API 屏蔽底层差异，让开发者根据具体场景选择合适的检索策略，而非在系统设计阶段就做出非此即彼的抉择。

适用场景与选型建议

基于 Cognee 的技术特性，以下场景特别适合采用该方案。

AI 代理记忆系统是 Cognee 最直接的应用方向。项目原生支持与 Claude Code 和 Hermes Agent 集成，插件会在会话生命周期中自动管理记忆 ——SessionStart 初始化内存、PostToolUse 捕获工具调用、SessionEnd 将会话数据同步到永久图谱。这种设计解决了 AI 代理在长对话中上下文溢出导致记忆丢失的典型问题。

企业知识管理场景中，Cognee 可用于构建跨数据源的统一知识库。系统支持从多个异构数据渠道（客服记录、产品文档、财务数据）提取实体并建立关联，支持类似 “查找过去一个月内未解决的支持工单及其关联产品” 的复杂查询。

专家知识蒸馏是另一个高价值场景。通过将资深员工的 SQL 查询、工作流程、决策模式提取为知识图谱，新手员工可以使用自然语言查询获取类似问题的解决路径，实现组织知识的低成本传递。

需要注意的是，如果你的数据主要是独立文档且查询以简单关键词为主，传统 RAG 方案可能更具性价比。Cognee 的优势在于需要处理实体关系和复杂推理时才能充分体现。

资料来源

本文技术细节主要参考 Cognee 官方 GitHub 仓库（15.6k Stars，6,744 commits）及项目文档。

ai-systems