cognee
为 AI Agent 提供持久化记忆,支持知识图谱与向量双轨检索,让 Agent 从「能记住」进化到「会推理」
加载项目详情…
本应用为开源项目,仅供学习研究,请遵守其开源协议。
为 AI Agent 提供持久化记忆,支持知识图谱与向量双轨检索,让 Agent 从「能记住」进化到「会推理」
加载项目详情…
本应用为开源项目,仅供学习研究,请遵守其开源协议。
想象一个客服机器人,它能在每一次对话中记住你上次投诉的问题是什么、什么时候投诉的、和之前哪个问题相关——这不是科幻,而是 Cognee 正在实现的事情。
在 AI Agent 飞速普及的今天,一个致命短板始终没有被好好解决:大模型的「记忆」是短暂的。每次新的对话开始,模型就像失忆了一样,一切从头来过。Cognee 正是为解决这一痛点而生——它是一个开源的 AI Agent 记忆控制平面,让 Agent 能够跨会话持久化记忆,并从中不断学习和推理。

Cognee 是什么?一句话定位:Cognee 是一个开源的 Agent 记忆控制平面(Memory Control Plane),用 6 行代码就能为 AI Agent 赋予持久化记忆能力。它将数据摄取(Ingestion)、语义搜索(Vector Search)和知识图谱(Knowledge Graph)三种技术融为一体,让 Agent 的记忆不仅「能被找到」,还能「被理解关系」。
让我们从一个真实场景说起:你在一家大型企业的客服系统中部署了一个 AI 助手。第一天,客户王女士咨询了物流延迟问题并得到解决。第五天,她再次联系,但换了一个问题——产品使用方法。第二天,一个新客户问的问题恰好和王女士第一天的经历有关。
在传统的 RAG(检索增强生成)方案中,Agent 每次都是「大海捞针式搜索」——根据当前问题找到最相似的文本片段。但它无法理解:王女士两次问题之间的关联、新客户问题和历史案例的关系、哪些信息需要被主动「记住」而不是临时检索。
Cognee 的解决思路完全不同:在查询之前,先构建知识图谱。它先把企业数据(文档、邮件、工单、数据库记录等)转化为结构化的知识图谱,让数据之间的关系被显式表达。当 Agent 需要记忆时,它调用的不再是模糊的向量相似度,而是有结构、有关系、可推理的知识网络。

图1:Cognee 的记忆层架构,结合向量嵌入与知识图谱双重检索
Cognee 的架构设计非常精妙,核心分为三层:
第一层:数据摄取层(Ingestion Pipeline)
Cognee 支持任意格式的数据摄取——PDF、网页、Notion 文档、数据库记录,甚至是网页爬取的内容。它内置了超过 10 种数据解析器,通过 Pydantic 进行结构化数据建模,确保每一条数据都有清晰的 schema 定义。这层还支持多模态数据的语义压缩(Semantic Compression),把长文档提炼为关键信息点,大幅降低上下文窗口的消耗。
第二层:双轨检索层(Dual-track Retrieval)
这是 Cognee 最核心的创新点。它同时维护两个检索通道:
两个通道的检索结果会通过重排序(Reranking)机制合并,确保返回的是既语义相关又关系紧密的记忆片段。这比单纯依赖向量相似度要可靠得多。
第三层:认知调度层(Cognitive Scheduler)
这是最体现 Cognee「认知科学」野心的部分。它引入了反馈驱动的学习机制(Feedback-driven Learning)——Agent 可以对记忆的使用效果打分,系统据此调整记忆的权重和优先级。也就是说,Cognee 不仅被动存储记忆,还能主动学习哪些记忆更有价值。
从代码结构来看,Cognee 是一个纯 Python 项目,采用 Poetry 进行依赖管理,核心依赖包括:
litellm 和 openai SDK 对接主流 LLM(OpenAI、Anthropic、Ollama、Mistral、Groq 等),实现模型的统一抽象代码采用模块化架构,核心模块包括:
memory/ —— 记忆核心抽象,包含向量存储和图谱存储的实现pipelines/ —— 数据处理流水线,支持链式处理和并行摄取modules/ —— 可插拔的认知模块(重排序、反馈学习等)api/ —— FastAPI Web 服务,含完整的 REST 端点cli/ —— 命令行工具,方便脚本化和集成cognee-frontend/ —— Web UI(React 技术栈)代码质量方面,项目有完整的类型注解(typing_extensions)、structured logging(structlog)、速率限制(limits + aiolimiter)、重试机制(tenacity)等企业级工程实践。文档质量极高,支持 8 种语言的 README 翻译。
Cognee 的设计哲学是「简单但不失深度」,官方甚至在 README 直接展示了 6 行代码的核心用法:
import cognee
# 1. 添加数据
await cognee.add("path/to/your/data")
# 2. 构建记忆
await cognee.cognify()
# 3. 查询记忆
results = await cognee.search("What do you remember about our past conversations?")
就这么简单三步,Agent 就能拥有持久化记忆。当然,生产环境需要配置 API Key、选择向量数据库后端、设置数据源等,但基础体验确实做到了极简。
2025 年 Cognee 推出了 MCP(Model Context Protocol)服务器集成,这意味着开发者可以在 Claude Code 等 IDE 中直接调用 Cognee 的记忆层。对于经常和 AI 编程工具打交道的开发者来说,这意味着:你在一个项目中积累的技术上下文,可以无缝带到下一个项目中。
当前 Agent 记忆领域的主要竞品包括 Mem0、Zep、Hindsight 等。相比之下,Cognee 的核心差异在于:
| 维度 | Cognee | Mem0 | Zep |
|---|---|---|---|
| 知识图谱 | 原生支持 | 纯向量 | 纯向量 |
| 多后端支持 | 灵活切换 | 受限 | 受限 |
| MCP 集成 | 支持 | 无 | 无 |
| Web UI | 有 | 有 | 有 |
| 开源程度 | 完全开源 | 部分开源 | 部分开源 |
Cognee 的知识图谱原生支持是最大差异化亮点——它不是事后补救加的图谱功能,而是从架构设计层面就将图谱作为一等公民。这让它在需要关系推理的场景(比如客服、工单分析、医疗记录等)中有明显优势。
Cognee 提供了完整的容器化部署方案:
docker-compose.yml 包含主服务和 MCP 服务,配置了 healthcheck 和资源限制(4核8GB)硬件需求方面,日常使用无需 GPU,主要消耗是 RAM(建议 8GB+)和磁盘空间(10GB+)。如需加速 embedding 计算,可选配 FastEmbed 本地模型。
Cognee 也面临一些现实挑战:
Cognee 的出现代表了 AI Agent 记忆层发展的一个重要方向——从「能记住」到「会推理」的跃迁。传统 RAG 解决的是「检索」问题,而 Cognee 解决的是「理解关系」的问题。在企业级 AI 应用场景中,数据的关联性往往比数据的量更重要。
目前 Cognee 已有 Bayer(拜耳)等企业级客户案例,GitHub Stars 超过 1.7 万,增长势头强劲。它的 MCP 集成路线也显示出团队对 AI 工具链生态的深刻理解——不是做一个孤立的记忆库,而是成为 AI 工具之间的「记忆协议层」。
如果你正在开发需要持久化记忆的 AI 应用,或者希望让现有 Agent 具备跨会话上下文能力,Cognee 绝对值得一试。