Cognee：给 AI Agent 一块真正能用的「长期记忆」，开源知识图谱 + 向量检索双引擎

发表于 2026-06-28 分类于 AI Agent ，开源项目

一个 22.6k stars 的开源项目，用「向量 + 知识图谱 + 认知科学本体」三件套解决 Agent 跨会话失忆的痛点，remember/recall/forget/improve 四个 API 就能把文档、聊天、数据库、API 全变成 Agent 可调用的持久记忆，并自带 Claude Code / MCP / LangGraph 集成。

一个让人抓狂的对话现场

「我们昨天不是讨论过这个方案吗？你怎么又忘了？」

这是我上周在一个 Agent 项目的 Slack 群里看到的真实对话。做产品经理的同事连续三天让同一个 AI 助手帮他梳理一份产品需求：第一天讨论用户画像，第二天梳理功能优先级，第三天准备评审材料。结果到第三天，助手一脸无辜地问「请问您能再描述一下这个产品的目标用户吗？」

这不是孤例。今天几乎每一个用过 ChatGPT、Claude、文心一言开发 Agent 的人都会撞上同一面墙：大模型天然没有跨会话的长期记忆。你可以把上下文塞进 Prompt、用 RAG 检索临时文档、甚至把整段历史塞进 vector store—— 但这些方案要么撑不住会话长度，要么检索出的内容断章取义，要么干脆把成本烧到你怀疑人生。

更扎心的是，绝大多数 Agent 产品的演示视频都光鲜亮丽，一到「多轮对话、跨会话协作」环节就开始掉链子。背后的根因只有一个：它们都没有真正解决「持久、结构化、可演化的长期记忆」问题。

今天 GitHub Trending 上冒出来的一个项目，就是冲着这个根因去的 ——topoteretes/cognee，22.6k stars、7,800+ commits、114 个 Release，被官方定位为「the open-source AI memory platform for agents」。它把向量检索、知识图谱、认知科学本体生成三件套打包成四个极简 API：remember、recall、forget、improve。把文档、聊天记录、数据库、API 全变成 Agent 可以「记住、回忆、遗忘、自进化」的持久记忆。

下面我把它彻底拆开聊聊。

项目背景：Agent 的「失忆症」到底是怎么来的

要理解 Cognee 在解决什么，先得理解现代 LLM 应用的记忆结构。

一个典型的 AI Agent 至少有四层「记忆」：

上下文窗口（Context Window）：模型在一次推理里能看到的全部输入。GPT-4o 是 128k token，Claude Sonnet 4 是 200k，本质上是「金鱼记忆」—— 会话一关就没了。
会话内历史（Conversation History）：把多轮对话拼成上下文塞回去。聊到第 30 轮就开始爆 token。
短期 RAG（Retrieval-Augmented Generation）：用向量数据库（pgvector、Qdrant、Pinecone）按相似度检索历史片段。问题是它只看相似度、不看关系，检索出来的内容经常风马牛不相及。
长期记忆（Long-term Memory）：跨会话、跨用户、跨任务的持久化记忆。这一层是当前行业普遍缺失的。

Cognee 的切入点就是第 4 层。它的核心理念只有一句话：

把向量检索的「找相似」和知识图谱的「看关系」合并成一套 API，让 Agent 拥有既能按语义搜、又能按实体关系推理的持久记忆。

它甚至有一篇专门的学术论文背书：《Optimizing the Interface Between Knowledge Graphs and LLMs for Complex Reasoning》，Markovic 等 2025 年发表在 arXiv 上。在 2025 年这个「人人都在卷 RAG」的节点上，敢于把知识图谱重新搬回台面，并且让 KG 和 LLM 协同工作的项目并不多。

更值得一提的是商业信任背书 —— 它的用户列表里出现了 Apple、AWS、Cloudflare、Adobe、Samsung、GitHub、PayPal、Microsoft、Google、Shopify、IBM、Uber、Intel、Alibaba、ByteDance、Capgemini、KPMG、Alipay、Bayer、Baidu 这些名字的工程师，Bayer 还专门有一个案例：从 AI chatbot 升级到 agentic research memory。

合规层面也走得比较远：通过了 EU AI Act 和 GDPR 双认证（heyData 认证），并被 UC Berkeley Center for Responsible, Decentralized Intelligence 投资。

核心功能：四个 API + 三个引擎

Cognee 的设计哲学我特别喜欢 ——API 极简，内核极深。表面看只有四个方法，但底层跑的是「向量 + 图 + 本体」三件套。

1. `remember`：把任意数据塞进记忆

import cognee
import asyncio

async def main():
    # 写入「永久知识图谱」
    await cognee.remember("Cognee turns documents into AI memory.")

    # 写入「会话级短期记忆」（后台异步合并到图里）
    await cognee.remember("User prefers detailed explanations.", session_id="chat_1")

asyncio.run(main())

remember 不只是存一段文本，它会自动跑一遍完整的 ETL 流水线：

解析：支持 PDF、Office、Markdown、图片、音频、视频，几乎覆盖所有常见数据格式。
Chunking：按语义切分而不是固定窗口，避免一句话被拦腰斩断。
Embedding：用配置的 LLM Provider 生成向量。
Cognify：这是 Cognee 独创的步骤 —— 用 LLM 抽取实体、关系、领域规则，存进图数据库（默认 Kuzu）。
Improve：基于反馈持续优化图的拓扑结构。

也就是说，你 remember 一段话，Cognee 在背后已经帮你做完了 NER、关系抽取、图谱构建、向量化 —— 这一整套手工在传统 RAG 方案里要写几百行代码。

2. `recall`：按语义 + 关系联合检索

# 自动路由：挑最合适的检索策略
results = await cognee.recall("What does Cognee do?")
for result in results:
    print(result)

# 会话级 recall：先看短期记忆，再穿透到长期图谱
results = await cognee.recall("What does the user prefer?", session_id="chat_1")

注意一个关键能力：Cognee 的 recall 不是单纯的「向量相似度 top-k」。它把检索分成了 Graph Completion、Vector Search、RAG Completion、Text Completion 多种策略，自动判断当前 query 适合用哪种。

举个例子：

问「Cognee 是干嘛的？」→ 走 RAG Completion，从文档里抠。
问「这个项目跟 LangChain 有什么关系？」→ 走 Graph Completion，沿图边遍历。
问「用户上次让我做什么来着？」→ 走 session memory fast path。

这个「auto-routing」的能力是大多数 RAG 框架没有的 ——LangChain、LlamaIndex 默认就是「向量化 → top-k → 拼 prompt」三板斧。

3. `forget`：可治理的遗忘

1	await cognee.forget(dataset="main_dataset")

GDPR 里有「被遗忘权（Right to be Forgotten）」，Cognee 把这个能力做成了一等公民。可以按 dataset、按 user、按 session 粒度删除记忆，并且会同步清理图谱里的孤儿节点。这对做 ToB 产品尤其是金融、医疗场景特别重要。

4. `improve`：让记忆自进化

这是 Cognee 最具差异化的能力之一 —— 记忆不是写进去就完事了，它会基于用户反馈持续调整。

1	await cognee.improve(user_feedback="This answer was unhelpful because it missed the pricing detail.")

improve 会基于反馈信号重新评估相关节点、边的权重，让后续 recall 的结果更精准。这相当于给 Agent 装了一个记忆层面的 fine-tuning 机制。

5. 部署选项

Cognee 给生产化做得很全：

场景	平台
不想管基础设施	Cognee Cloud（`await cognee.serve()`）
Serverless + GPU	Modal（`bash distributed/deploy/modal-deploy.sh`）
极简 PaaS	Railway（`railway init && railway up`）
边缘部署	Fly.io（`bash distributed/deploy/fly-deploy.sh`）
简单 PaaS	Render（Deploy to Render 按钮）
云端沙箱	Daytona（`distributed/deploy/daytona_sandbox.py`）

Docker 镜像也开箱即用：cognee/cognee（API 8000）、cognee/cognee-mcp（MCP 8001），两个镜像端口不冲突，可以同时跑。

实战示例：把 Cognee 接到 Claude Code

光说不练假把式。我来演示两个最常见的使用场景。

场景一：5 分钟给 Claude Code 装上「跨会话记忆」

Cognee 官方提供了一个 Claude Code 插件。安装完之后，Claude Code 的整个生命周期都被接管：

Hook	做什么
`SessionStart`	初始化记忆、加载相关上下文
`PostToolUse`	自动捕获工具调用行为
`UserPromptSubmit`	注入相关的历史上下文
`PreCompact`	上下文压缩前先把关键信息固化到图里
`SessionEnd`	把会话级数据桥接到永久图谱

效果：你今天跟 Claude Code 聊了一个复杂的多文件重构方案，明天重新打开 —— 它会主动告诉你「根据我们昨天的讨论，你当时决定把 X 模块拆出去……」。这种体验在传统方案里几乎不可能实现，因为光是把昨天的对话塞进今天的 prompt 就会把 token 撑爆，而 Cognee 是按「相关实体 + 关系」精准召回的。

场景二：构建一个「会学习的 SQL Copilot」

来自 Cognee 官方 Example 2（Expert Knowledge Distillation）：

import cognee

async def setup_sql_copilot():
    # 1. 把团队的 SQL 规范文档塞进记忆
    await cognee.remember("""
    - 财务相关的查询必须使用 partition_date 过滤
    - 用户表大表 JOIN 必须带 LIMIT 10000
    - 所有时间字段统一使用 ISO 8601
    """, dataset_name="sql_guidelines")

    # 2. 把历史「好 SQL」案例存进去
    await cognee.remember(open("historical_good_queries.sql").read(),
                          dataset_name="sql_examples")

    # 3. 用户提问时直接 recall
    results = await cognee.recall(
        "查询最近 30 天 DAU 按渠道拆分的 SQL 怎么写？",
        dataset_name=["sql_guidelines", "sql_examples"]
    )
    return results

这套方案相当于把团队多年沉淀的「SQL 编码规范 + 历史最佳实践」做成了一个可被 Agent 持续调用的知识库，新员工入职第一天就能拥有老员工的经验值。

跟同类项目比，Cognee 强在哪

维度	Cognee	LangChain Memory	LlamaIndex	mem0
长期持久化	✅ 自带图谱	⚠️ 需自己接 DB	⚠️ 需自己接 DB	✅ 向量为主
知识图谱	✅ 一等公民	❌ 无	⚠️ 第三方插件	❌ 无
关系推理	✅ Graph Completion	❌	❌	❌
跨框架集成	✅ Claude Code/MCP/LangGraph/CrewAI	✅ LangChain 系	✅ LlamaIndex 系	⚠️ 有限
自进化	✅ `improve` API	❌	❌	⚠️ 简单反馈
可遗忘	✅ GDPR 一等公民	⚠️ 需手动	⚠️ 需手动	✅
学术背书	✅ arXiv 论文	❌	⚠️ 有论文	⚠️ 有论文
部署成熟度	✅ 6+ 平台	⚠️ 自己拼	⚠️ 自己拼	✅ 较简单

Cognee 的护城河在于「知识图谱是一等公民」。大多数 RAG 框架把 KG 当成外挂的 fancy 插件，Cognee 直接把它焊死在 API 表面，并且通过 cognify 步骤让 LLM 主动参与图谱构建 —— 这是它跟 LangChain/LlamaIndex/mem0 最大的差异。

适用场景和限制

✅ 适合用 Cognee 的场景

企业知识库问答：跨部门、跨系统的文档统一 recall，需要关系推理。
客户支持 Agent：要把用户历史工单、产品手册、内部 SOP 全串起来。
研究类助手：论文、项目文档、会议纪要需要长期沉淀。
Claude Code / Cursor 类编码 Agent：跨会话的「项目记忆」。
多 Agent 协作：Cognee 提供 shared memory API，多个 Agent 可以读同一张图。

❌ 目前不太适合的场景

超大规模（>1 亿文档）：默认 Kuzu 适合中等规模，需要换 Neo4j 或自研 worker（仓库里有 cognee_db_workers 模板）。
纯流式聊天机器人：如果没有跨会话需求，传统方案更轻量。
对延迟极敏感（< 100ms）：cognify 步骤需要 LLM 介入，首次写入会有秒级延迟。
完全不想碰 Python：Cognee 的核心 SDK 是 Python，其他语言目前要靠 MCP / REST 间接调用。

⚠️ 几个工程化提醒

LLM Provider 需要自己配 ——Cognee 默认 OpenAI，但支持 Anthropic、Ollama、Bedrock 等 20+ 家，记得看 LLM Provider 文档。
MCP server 默认跑在 Docker 里 —— 需要 Docker Desktop / Colima / OCI 兼容 runtime。
首次跑 remember 会比较慢 —— 因为要建图，建议先在小批量数据上试。

总结

Cognee 给我的最大启发是：Agent 真正的护城河不是模型能力，而是记忆质量。

当所有人都在卷 context window 大小、卷 fine-tuning 技巧、卷 reasoning 能力的时候，Cognee 反其道而行 —— 把记忆层做厚、做结构化、做可治理。它用四个极简的 API（remember / recall / forget / improve）封装了向量检索、知识图谱、认知科学本体这三件大事，让开发者 5 行代码就能给 Agent 装上真正的「长期记忆」。

如果你的 Agent 项目正在被「跨会话失忆」「检索结果风马牛不相及」「用户反馈没沉淀」这三件事折磨，强烈建议花一个下午把 Cognee 跑起来。GitHub 地址：https://github.com/topoteretes/cognee，文档：https://docs.cognee.ai/。

下期我打算聊聊怎么把 Cognee 和 Hermes Agent 接起来，做一个「有持久记忆的日常助手」。如果你也在玩 Agent 记忆层，欢迎在评论区交流。