cat README.md | glow -p
Cognee
开源 AI Agent 记忆平台，为 AI Agent 提供跨会话的持久长期记忆，基于自托管知识图谱引擎。融合向量嵌入、知识图谱推理与认知科学本体论，让 AI 真正「记住」你做过的每一件事。
// 目录
// 我最近被一个问题困住了
做 AI 编程评测以来，我有一个体会越来越强烈：AI Agent 最大的瓶颈不是模型能力，是没有记忆。
Claude Code 写完代码，下次启动时完全不知道项目里有什么文件。Cursor Agent 做了一次重构，下周完全不记得改了哪些模块。我每次都要花 5-10 分钟重新喂上下文——「这是一个 Python 项目，目录结构是 xxx，你上次改了 yyy，现在需要 zzz」。
模型越来越强，但 Agent 越来越像金鱼。换个会话就清零，换个工具就失忆。这不是 Claude 的问题，不是 Cursor 的问题——是整个 AI Agent 生态缺了一个基础设施层：持久记忆。
直到我在 GitHub Trending 上看到 Cognee，读完它的论文和源码，我才发现这个问题已经有团队系统性地在解决了。
// 我的判断
// 概览
// Cognee 是什么
Cognee 是 Topoteretes 团队（总部柏林，$7.5M Seed 轮融资）开发的开源 AI Agent 记忆控制平面。核心定位一句话：用 6 行代码，把混乱的多模态数据变成 AI Agent 的长期记忆。
它不是 Mem0 那种「对话事实抽取」记忆层，也不是 Zep 那种「时序事实追踪」记忆层——Cognee 是把数据当知识图谱来经营的记忆层。搭配独家 ECL Pipeline（Extract → Cognify → Load）与 RDF/OWL 本体论验证，在 HotPotQA 多跳问答基准上拿到 0.93 的分数，接近人类标注者上限。
// 独家 ECL 管线
Cognee 最容易跟其他记忆层混淆的，就是它的 ECL（Extract → Cognify → Load）三段式 Pipeline。这套架构的设计哲学承袭传统数据仓库的 ETL，但把中间的「Transform」换成了「Cognify」（认知化），引入了本体论验证、跨文件指代消解、RDF/OWL URI 对齐等处理步骤。
PDF/Notion/Slack
Audio/Image/Code
跨文件指代消解
非固定字符切分
本体论 RDF/OWL
URI 实体去重
Neo4j/Qdrant
Postgres 单库模式
向量相似度
时序过滤混合
六个步骤里最被低估的是第 4 步 Cognify（认知化）。传统的 RAG 系统跳过了这一步——直接把文本切片塞进向量库就完事了。但 Cognee 在这一步用 LLM 提取实体三元组（subject-predicate-object），同时做本体论验证和 URI 标准化。
举个例子：你的文档里出现了「ChatGPT-4」「GPT-4 turbo」「OpenAI gpt-4」三种写法，Cognee 的 Cognify 步骤会把它们统一成 uri:openai:gpt-4。这个机制是 RAG 系统最常跳过的一步，但恰恰是多跳推理质量的决胜点。
// 真正打动我的几个能力
4 个 API 操作——业界最简洁的记忆接口
Cognee 把记忆层拆成 4 个直观动词：remember() 写入、recall() 读取、forget() 移除、improve() 强化。
这个设计学的是认知科学里的「主动记忆四阶段」——当 AI Agent 收到人类反馈后，improve() 会根据反馈重新加权图谱边，把「常用而正确」的关联往上提，把「过时而错误」的关联往下压。
全内存层跑在 Postgres 上
传统图谱记忆需要独立部署图数据库（关系）、向量数据库（嵌入）、Redis（会话）、关系型数据库（元数据）四套基础设施。Cognee 1.0 支持所有内存层运行在单个 Postgres 实例上——图谱、文本、元数据、嵌入都在同一个 Postgres 里，CI 基准测试中搜索速度比独立图+向量方案快约 10%。
Claude Code 插件——跨会话持久记忆
这是我最想试的功能。Cognee 为 Claude Code 提供了完整的记忆插件，自动捕获 Prompt、工具调用痕迹、助手响应到会话记忆，每次 Prompt 时注入相关上下文，会话结束时同步到永久知识图谱。相当于给 Claude Code 装了一个「永不遗忘的大脑」。
多平台一键部署
除了 Docker 自托管，Cognee 还支持 Modal（无服务器 GPU）、Railway、Fly.io、Render、Daytona 等平台的一键部署。还有全托管 Cognee Cloud 服务。
// 6 行代码上手
也可以用 CLI：
// 视频演示
// 基准测试——多跳推理 0.93 是什么概念
官方使用 BEAM（长上下文基准测试）测试 Cognee 默认配置：
在 HotPotQA 多跳问答基准上，Cognee 拿到 0.93 接近人类标注者上限，而纯向量 RAG 只能达到 0.5-0.6。在 Musique 基准上 Cognee 也领先纯向量 RAG +37%。
这个差距说明了一件事：纯向量检索在处理「需要跨多个文档才能答对」的问题时有天然天花板。向量只能告诉你「这段文字像不像」，但 Cognee 的知识图谱能告诉你「这个实体和那个实体是什么关系」——这是本质差异。
// AI 记忆层五大门派
AI Agent 记忆层目前形成了五个流派，各自解决不同的问题：
| 项目 | 定位 | 核心优势 | 短板 |
|---|---|---|---|
| Cognee | GraphRAG 图谱记忆 | HotPotQA 0.93 | 本体论 URI 去重 | ECL 管线 | Cloud Beta | 时序推理弱 | 学习曲线陡 |
| Mem0 | 通用 SDK 记忆层 | 41K Stars | 框架整合最广 | AWS Agent SDK | 多跳推理弱 | 知识图谱缺位 |
| Zep | 时序事实追踪 | Graphiti 双时间轴 | SOC2/HIPAA/GDPR | 图谱推理不如 Cognee | 定价较高 |
| Letta (MemGPT) | OS 风格自主代理 | Heartbeat 自治 | Core/Recall/Archival 三层 | 记忆层不是核心 | 生产化待验证 |
| Supermemory | 编码代理记忆 | LongMemEval 85.4% | Sub-300ms | MCP | 非通用记忆层 | 偏开发者场景 |
一句话选型：需要多跳推理+知识文档深度连接 → Cognee；需要通用 SDK+框架整合 → Mem0；需要时序事实追踪+企业合规 → Zep；需要 OS 风格代理自主 → Letta；需要编码代理+IDE 整合 → Supermemory。
// 博主评分
· HotPotQA 0.93 多跳推理人类等级——这是最硬的数字
· ECL Pipeline 六步模块化，每一步可单独替换测试
· 本体论 RDF/OWL URI 自动实体去重，知识图谱不被噪音稀释
· Knowledge Graph + Vector 双引擎，不是二选一
· 30+ 数据连接器，多模态摄入远超同类
· Apache 2.0 开源，80+ 贡献者，活跃社区
· 4 API 操作业界最简洁，学习曲线平缓
· $7.5M Seed + 学术论文背书，商业续航力够
· Cloud SaaS 仍 Beta，Dashboard 和文档在补齐中
· 1 GB 数据处理需约 40 分钟 + 100 容器，TB 级有压力
· TypeScript SDK 不完整，Python 是一等公民
· 无移动端 SDK，时序推理不如 Zep Graphiti 双时间轴
· 本体论需自备 RDF/OWL，小团队学习成本高
· 图谱 BFS 遍历延迟不适合 Sub-300ms 场景
// 跟我在做的事有什么关系
我做 GitHub AI 日报评测，评测本身就是一个需要记忆的场景——之前评测过的项目、踩过的坑、做出的判断，如果每篇都要重新查一遍，效率很低。
Cognee 给我三个启发：
评测自动化需要记忆层。我已经在维护自动化评测流程，但如果能用 Cognee 把每次评测的结论、竞品对比、评分都存入知识图谱，下次遇到类似项目时自动关联历史判断，评测的深度和一致性会提升一个量级。
ECL Pipeline 的「先认知化再存储」思路可以迁移。我现在的自动化流程是「采集→分析→生成文章」，中间缺了一步「结构化认知」。如果把分析结果先做实体抽取和关系建模（类似 Cognify），存入结构化知识库，文章的深度会比现在的「一次调研一次生成」强得多。
记忆是 AI Agent 成为「工具」而不是「玩具」的最后一块拼图。我评测过的项目越多，越觉得模型能力已经不是瓶颈了——真正的瓶颈是每次重新启动 Agent 就像面对一个失忆症患者。Cognee 解决的问题，是所有做 Agent 产品的人都绕不过去的。
// 适合谁，不适合谁
适合
· 做企业文档问答，需要多跳推理能力
· 构建知识图谱驱动的智能搜索，想替代纯向量 RAG
· 科研/医疗/法律/制药场景，有本体论需求且数据不出公司
· 已有 Neo4j 等图数据库资产，想接入 LLM
· 需要 PDF/影像/音频多模态整合的文档管理系统
不适合
· 只需要简单对话记忆 → Mem0 更轻量
· 时序事实追踪是核心需求 → Zep 的 Graphiti 更强
· 编码 Agent + IDE 整合 → Supermemory 更专注
· 移动 App 场景（缺 Mobile SDK）
· 需要 Sub-300ms 低延迟的实时系统