cognee

1. 项目概览

需要注意：本轮调研时 GitHub 匿名 API 已触发 rate limit，因此精确 stars/forks/issues 没有写入本笔记；正式对外引用前建议打开 GitHub 页面复核实时热度和 release 状态。但从 README、官方文档、Docker/CLI/Cloud/SDK 说明看，cognee 已经不是一个只有 demo 的小工具，而是在尝试做完整的 Agent memory infrastructure。

2. 项目自带示意图

2.1 Logo 和 Demo

2.2 Remember / Recall 工作示意

2.3 官方架构图

2.4 Demo 视频封面

3. 它主要能做什么

3.1 给 Agent 提供“长期记忆”

很多企业做 Agent 时会遇到一个典型问题：Agent 可以在一次会话里表现不错，但换一个会话、换一个任务、换一个用户后，之前的上下文、偏好、经验和业务知识就丢了。普通 RAG 可以检索文档，但不一定能表达“谁和谁有关”“某个事件导致了什么”“这个用户过去偏好什么”“哪些解决方案曾经成功”。

cognee 的核心价值就是把这些分散数据变成 Agent 可调用的长期记忆层：

• 文档知识可以进入永久图谱记忆。
• 会话偏好可以先进入 session memory。
• 后续可通过 improve 把会话经验桥接到永久图谱。
• 多个 Agent 可以在隔离权限下共享或调用特定数据集。

售前话术可以这样讲：

普通 RAG 解决“找得到文档片段”的问题，cognee 更关注“Agent 能否长期记住、理解关系、持续学习并在后续任务中复用经验”。

3.2 四个用户级操作：remember / recall / improve / forget

cognee v1.0 的用户工作流被抽象成四个操作：

这个抽象对售前非常好用，因为客户不需要一开始理解内部 graph/vector 细节，只要理解“记住、回忆、改进、遗忘”四步。

3.3 向量检索 + 知识图谱 + 关系推理

官方架构文档明确说明，cognee 组合三类存储：

普通向量 RAG 更擅长“找相似文本”。cognee 的卖点是同时保留“语义相似”和“结构关系”：比如客户支持场景中，不只是找到一段 FAQ，而是能把用户、工单、产品、历史解决方案、发票、失败动作串起来。

3.4 支持永久记忆和会话记忆

cognee README 的示例里展示了两类 remember：

await cognee.remember("Cognee turns documents into AI memory.")
await cognee.remember("User prefers detailed explanations.", session_id="chat_1")

第一种是永久知识图谱记忆，第二种是 session memory。对于售前，这是一个很重要的区分：

• 永久记忆：公司知识库、产品文档、历史案例、专家经验。
• 会话记忆：某个用户偏好、某次任务上下文、某个 Agent 当前会话状态。

客户如果关心隐私和权限，需要进一步设计 dataset、user、agent 的隔离方式。

3.5 支持多种检索模式

CLI 文档中提到 recall 支持多种 query type：

售前建议：给业务方演示 GRAPH_COMPLETION 和 RAG_COMPLETION 的差异；给技术方展示 CHUNKS、CYPHER 和 provenance。

3.6 可把整个记忆层跑在 Postgres 上

README 里有一个很重要的生产部署卖点：cognee 1.0 可以把整个 memory layer 放到一个 Postgres 实例中：

这对企业客户很有吸引力，因为很多客户并不想一开始就维护 Neo4j + 向量库 + Redis + 元数据 DB 多套基础设施。用 Postgres 起步，后续再按规模替换 Neo4j、Neptune、Redis、Qdrant、Weaviate 等组件，是一条更容易落地的路线。

3.7 有 CLI、本地 UI、MCP、Cloud 和多语言 SDK

cognee 不只是 Python 包：

• Python SDK：适合嵌入现有 Agent/RAG 应用。
• CLI：cognee-cli remember/recall/improve/forget，适合 PoC 和脚本化。
• 本地 UI：cognee-cli -ui，会启动 backend 和 React app。
• Docker API Server：适合服务化。
• MCP Server：适合 Claude Desktop、Codex、Cursor 等 Agent 工具调用。
• Cognee Cloud：托管体验。
• Rust client：cognee-rs。
• TypeScript client：@cognee/cognee-ts。
• Claude Code plugin / OpenClaw plugin：把 Agent 的使用痕迹和回答沉淀成记忆。

这个生态方向说明它想做“Agent memory infrastructure”，不是只做一个 Python notebook demo。

4. 适用场景

4.1 企业知识助手：从“文档问答”升级为“公司大脑”

适合客户：

• 企业知识管理团队
• 售前/咨询团队
• 研发支持团队
• 客服知识库团队

痛点：

• 文档很多，普通 RAG 只能召回片段。
• 客户案例、产品能力、交付经验、FAQ、工单之间存在关系，但没有被结构化。
• 员工离职或项目结束后，经验很难沉淀。

cognee 的切入：

• 用 remember 接入文档、FAQ、案例和会议纪要。
• 用图谱表达客户、产品、问题、解决方案之间的关系。
• 用 recall 支持业务问答。
• 用 improve 把新会话经验和反馈沉淀进去。

售前价值：

把企业知识库从“文件夹 + 搜索框”升级为“可持续学习的 Agent 记忆层”。

4.2 客服/售后 Agent：避免重复犯错

README 给了一个 Customer Support Agent 示例：用户问发票异常和问题未解决，cognee 可以跟踪历史交互、失败动作、已解决案例、产品历史，并检索类似已解决案例。

客户价值：

• 新客服能复用历史解决方案。
• Agent 能看到该客户过去发生过什么。
• 对重复问题，系统能推荐更有把握的处理路径。
• 处理结果可继续回写为记忆。

PoC 可以这样设计：

• 输入 50 条历史工单 + 10 条 FAQ + 5 个产品变更说明。
• 选 10 个真实客服问题。
• 对比普通 RAG 和 cognee 的回答是否更能关联历史案例。

4.3 SQL Copilot / 专家经验复用

README 的第二个例子是 Expert Knowledge Distillation：把专家 SQL、工作流模式、schema 结构、成功实现沉淀下来，帮助 junior analyst 复用专家经验。

这类场景非常适合售前：

• 客户有资深分析师，但新人上手慢。
• SQL/BI/数据口径经常重复出错。
• 知识不只在文档里，也在历史查询和专家操作中。

cognee 可以作为“专家经验记忆层”，让 Agent 根据当前 schema 找到过去相似任务和成功 query，再适配到当前问题。

4.4 开发者 Agent / Claude Code 记忆

cognee 有 Claude Code plugin。插件会在 Claude Code 生命周期中捕获：

• session start
• user prompt
• tool traces
• assistant response
• context compact 前的记忆保护
• session end 时同步到永久图谱

适合客户：

• 内部 AI Coding 平台
• 研发知识库
• 代码助手记忆增强
• 多项目开发经验沉淀

售前表达：

很多 AI Coding 工具每次都要重新解释项目背景。cognee 可以把项目约束、历史决策、工具使用痕迹和回答沉淀成可回忆的长期记忆。

4.5 多 Agent 协作平台

CLI 文档有 agents create/list/register/connections 等命令，每个 agent 可有自己的 agent user 和 API key，并按 dataset 授权。

这适合做：

• 多 Agent 平台的数据隔离。
• 不同 Agent 共享公司知识但保留各自会话记忆。
• Agent 连接状态和 memory sources 管理。
• 多租户知识助手。

5. 不太适合的场景

6. 核心能力清单

7. 架构/部署/集成方式

7.1 高层架构

7.2 本地 PoC 部署

最小安装：

uv pip install cognee

配置 LLM：

export LLM_API_KEY="YOUR_OPENAI_API_KEY"

Python 示例：

import cognee
import asyncio

async def main():
    await cognee.remember("Cognee turns documents into AI memory.")
    results = await cognee.recall("What does Cognee do?")
    for result in results:
        print(result)

asyncio.run(main())

CLI 示例：

cognee-cli remember docs/company-handbook.pdf --dataset-name handbook
cognee-cli recall "Who owns the rollout plan?" --datasets handbook
cognee-cli improve --dataset-name handbook
cognee-cli forget --dataset handbook

7.3 Docker / API / UI

Docker Compose：

cp .env.template .env
docker compose up
docker compose --profile ui up
docker compose --profile mcp up
docker compose --profile postgres up
docker compose --profile neo4j up

预构建镜像：

echo 'LLM_API_KEY="YOUR_OPENAI_API_KEY"' > .env
docker run --env-file ./.env -p 8000:8000 --rm -it cognee/cognee:main
docker run -e TRANSPORT_MODE=http --env-file ./.env -p 8000:8000 --rm -it cognee/cognee-mcp:main

本地 UI：

cognee-cli -ui

UI 会启动 backend http://localhost:8000 和 React app http://localhost:3000，并尝试启动 MCP server。

7.4 Postgres 生产化路线

安装：

pip install "cognee[postgres]"

环境变量：

DB_PROVIDER=postgres
VECTOR_DB_PROVIDER=pgvector
GRAPH_DATABASE_PROVIDER=postgres
CACHE_BACKEND=postgres

DB_HOST=localhost
DB_PORT=5432
DB_USERNAME=cognee
DB_PASSWORD=cognee
DB_NAME=cognee_db

售前建议：对大多数企业客户，Postgres 路线比一开始引入 Neo4j + Redis + 向量库更容易接受；等业务规模、图查询复杂度、向量规模上来后，再考虑替换专用组件。

7.5 安全配置要点

官方安全文档中值得售前重点提醒：

这部分可以作为和客户安全团队沟通的抓手：cognee 有安全开关，但不能默认裸奔上线。

8. 售前可以怎么讲

面向业务方

现在很多 AI 助手最大的问题不是不会回答，而是不会长期记住。今天问过、解决过、反馈过的东西，下一次又要重新解释。cognee 可以把企业文档、历史工单、专家经验和会话偏好沉淀成 Agent 的长期记忆，让 AI 助手不只是“查资料”，而是逐步形成“公司大脑”。

业务价值：

• 减少重复解释背景。
• 让新人复用专家经验。
• 让客服/售后 Agent 参考历史成功案例。
• 让企业知识库从文档检索升级到关系记忆。
• 支持知识遗忘、数据隔离和后续治理。

面向技术方

cognee 是一个把 relational、vector、graph 三种存储组合起来的 Agent memory layer。它既保留 chunk 和来源，又生成 embeddings 做语义检索，还抽取实体关系进入图谱。上层用 remember/recall/improve/forget 简化调用，下层可以从 SQLite/LanceDB/Kuzu 的本地栈切换到 Postgres/PGVector/Neo4j 等生产栈。

技术价值：

• 比单向量库更有结构关系。
• 比传统知识图谱更容易接入 LLM/Agent。
• 比自研 memory layer 更快 PoC。
• CLI、SDK、MCP、Docker 都有，集成路径多。
• Apache-2.0 对商业集成相对友好。

面向管理层

cognee 适合先做企业 AI 助手长期记忆 PoC，不需要一开始建设庞大知识图谱平台。我们可以选一个有明确价值的场景，比如客服历史案例、售前资料库、研发知识库，用 1-2 周验证它是否能提升回答质量和减少重复劳动。

9. 常见客户问题

10. PoC 建议

PoC 1：售前资料长期记忆助手

输入材料：

• 20 份产品方案
• 20 个客户案例
• 10 份竞品资料
• 10 条历史售前问答

验证问题：

• 某行业客户常见痛点是什么？
• 某产品能力在哪些案例中用过？
• 某竞品和我方方案差异是什么？
• 某客户历史沟通里提过哪些关注点？

成功指标：

• 回答能引用到正确资料。
• 能串联案例、产品能力和客户问题。
• 相比普通 RAG，关系型问题回答更完整。
• 支持按 dataset 隔离不同客户资料。

PoC 2：客服历史案例记忆

输入材料：

• 100 条历史工单
• FAQ 文档
• 产品变更记录
• 处理结果和客户反馈

验证问题：

• 当前问题是否有相似历史案例？
• 哪些处理方式失败过？
• 哪个版本变更可能导致这个问题？
• 新工单应该推荐什么处理路径？

成功指标：

• 相似案例召回准确率。
• 回答中能解释关联原因。
• 能减少客服重复排查时间。

PoC 3：AI Coding 项目记忆

输入材料：

• 项目 README
• 架构说明
• 代码规范
• 历史 PR/issue 摘要
• Claude Code/Codex 会话记录

验证问题：

• 项目有哪些架构约束？
• 某模块之前为什么这么设计？
• 新功能应该遵循哪些代码风格？
• 过去类似 bug 是怎么修的？

成功指标：

• 新会话中能主动召回项目上下文。
• 减少重复解释项目背景。
• 能定位相关历史决策。

11. 风险和注意事项

12. 我的售前判断

cognee 是这批项目里非常值得重点看的一个，因为它踩中了 Agent 产业里一个很真实的痛点：Agent 不能只会调用工具，还要能长期记住、持续学习、按关系理解企业知识。

它适合的售前定位不是“又一个 RAG 框架”，而是：

Agent 长期记忆层 + 企业知识图谱化记忆 + 向量/图混合检索基础设施。

最适合讲给三类客户：

1. 已经做过 RAG，但发现回答缺少上下文和关系推理的客户。
2. 正在做企业 Agent 平台，需要 memory layer 的客户。
3. 有客服、售前、研发、数据分析等“经验沉淀”需求的客户。

不建议一上来承诺生产替换客户现有知识平台。更稳的打法是：用 1-2 个高价值场景做 PoC，尤其是“历史案例 + 当前问题 + 关系推理”类问题。如果 cognee 在这些问题上明显优于普通向量 RAG，就很容易把客户带到“长期记忆/公司大脑”的方案叙事里。

13. 参考资料

• GitHub - topoteretes/cognee
• Cognee Documentation
• Installation
• Core Concepts Overview
• Architecture
• Cognee CLI
• Security & Privacy
• Cognee Cloud
• Research Paper