Cognee 智能体记忆平台
为智能体把数据沉淀为可跨会话检索的长期记忆。
按维度查看评分与理由
证据显示：依赖项有安全注释（如pydantic-settings的GHSA），但未发现权限最小化设计（如沙箱或最小权限原则）。用户确认机制缺失，数据流透明度有限（仅提及traceability和OTEL collector，但无具体实现）。敏感数据处理有加密（cryptography用于OAuth凭据），但未全面覆盖。外部影响有删除操作（forget），但无用户确认。回滚机制未明确。来源归属有提及traceability，但未详细说明。扣分原因：缺乏用户确认、权限最小化证据不足、数据流透明度不完整。
证据显示：README和pyproject.toml一致，依赖版本有明确范围，但失败消息未详细说明。扣分原因：失败消息处理不充分，依赖可用性未完全验证。
证据显示：面向开发者，有多个使用场景（客户支持、SQL Copilot），但能力边界未明确（如Postgres图存储标记为demo）。触发精度有参数验证（如validate_top_k），但整体不全面。环境适配良好（支持多种部署平台）。扣分原因：能力边界不清晰，触发精度部分不足。
证据显示：信息架构清晰（README、docs、examples），安装说明详细，命名稳定（cognee-cli），有示例和FAQ，已知限制有提及（Postgres demo），许可证明确（Apache-2.0），但版本变更日志未提供，维护责任未明确。扣分原因：缺少变更日志，维护责任不明确。
证据显示：输出可用性有格式化（如format_recall_results），边际价值高（提供持久记忆），但成本效益未量化。扣分原因：成本效益证据不足。
证据显示：有研究论文和基准测试，但未提供具体数据来源。扣分原因：声明可追溯性不足，交叉验证有限，事实与推断分离不明确。
- 用户确认机制缺失，删除操作可能无提示执行。
- Postgres图存储标记为demo，生产使用需谨慎。
- 依赖安全注释存在，但未全面覆盖所有依赖。
这个 Agent 能做什么，适合哪些场景？
Cognee 是一个面向 AI 智能体的开源记忆平台，提供 Python API、CLI、API 服务、MCP 服务以及本地 UI 的使用路径。它接收任意格式的数据，并将其组织为结合向量嵌入与关系结构的自托管知识图谱，用于后续检索。核心 API 为 remember、recall、forget 和 improve；其中会话记忆可先作为快速缓存使用，再在后台同步到图谱。默认本地开发可使用 SQLite、LanceDB 和 Kuzudb，也可选配 Postgres、Neo4j、Redis 等后端。它适合希望将记忆层嵌入 Python 智能体、Claude Code 工作流或自托管服务的团队，但需要配置 LLM 凭据并评估存储后端。
应用通过 await cognee.remember(...) 写入文本或带 session_id 的会话内容；永久写入会运行 add、cognify 和 improve 流程，会话内容先进入快速缓存并在后台同步。await cognee.recall(query) 会自动选择检索策略；指定 session_id 时先查会话记忆，未命中再查图谱。await cognee.forget(dataset="main_dataset") 可删除指定数据集，CLI 也提供 cognee-cli remember、cognee-cli recall 和 cognee-cli forget --all。服务可通过 Docker Compose 启动 API、UI、MCP、Postgres 和 Neo4j 配置；cognee-cli -ui 会启动容器中的 MCP 服务。Claude Code 插件会在生命周期钩子中注入相关上下文、记录提示词和工具轨迹，并在会话结束时同步永久图谱。
- 客服团队需要让支持智能体结合客户的历史工单、账单和产品记录处理未解决问题。
- 数据分析团队希望让初级分析师复用专家 SQL 查询、工作流模式和既有的成功方案。
- Python 智能体开发者需要用 session_id 保存当前对话偏好，并在跨会话时从长期图谱召回信息。
- 使用 Claude Code 的开发者希望在 SessionStart、PostToolUse 和 SessionEnd 等阶段持续采集并恢复项目上下文。
- 已有 Postgres 基础设施的团队希望在演示环境中将关系元数据、pgvector、会话缓存和图状态集中到一个实例。
这个 Agent 有哪些优点和局限？
- 将 remember、recall、forget、improve 统一为简洁的异步 API，并同时支持 Python、CLI、Docker 服务路径。
- 同时覆盖向量嵌入、知识图谱关系和会话缓存；recall 可自动路由检索策略，并可优先查询指定会话。
- 本地开发可使用 SQLite、LanceDB 和 Kuzudb，无需先部署外部服务；需要时可切换到 Postgres、Neo4j 或 Redis 等后端。
- 提供 Claude Code 专用记忆插件，明确覆盖上下文注入、工具轨迹采集、压缩前记忆保留和会话末同步。
- 开始使用需要 LLM_API_KEY；远程或 Cognee Cloud 模式还需要 COGNEE_BASE_URL 与 COGNEE_API_KEY。
- cognee-cli -ui 依赖 Docker 或兼容 OCI 运行时，部署 UI/MCP 增加了容器运行成本。
- Postgres 图存储被明确标为演示功能，尚不适合生产；生产图工作负载应使用 Kuzu 或 Neo4j 等图原生后端。
- README 所列 BEAM 成绩被定义为方向性信号，而非决定性的性能结论；实际效果仍需按数据和检索任务验证。
如何安装或部署这个 Agent？
运行环境为 Python 3.10 至 3.14。安装：uv pip install cognee。设置 LLM 凭据：export LLM_API_KEY="YOUR_OPENAI_API_KEY"，或依据 .env.template 创建 .env 并填入 LLM_API_KEY。容器部署时，克隆仓库后复制 .env.template 为 .env，设置 LLM_API_KEY，再运行 docker compose up；需要 UI、MCP、Postgres 或 Neo4j 时，分别增加对应的 --profile。使用 cognee-cli -ui 时，主机还需要 Docker Desktop、Colima 或其他可用 docker CLI 的 OCI 运行时。
如何使用这个 Agent？
最小调用为：import cognee；await cognee.remember("Cognee turns documents into AI memory.")；results = await cognee.recall("What does Cognee do?")。会话记忆使用 await cognee.remember("User prefers detailed explanations.", session_id="chat_1")，并用同一 session_id 调用 recall。命令行可执行 cognee-cli remember "Cognee turns documents into AI memory."，再执行 cognee-cli recall "What does Cognee do?"。连接托管或远程实例时先调用 await cognee.serve(url="https://your-instance.cognee.ai", api_key="ck_...")，完成后调用 await cognee.disconnect()。
这个 Agent 与同类方案有什么区别？
与分别部署图数据库、向量数据库、Redis 和关系数据库的传统记忆栈相比，Cognee 展示了以单个 Postgres 实例承载图状态、pgvector、会话缓存和元数据的演示方案。该方案降低服务数量，但其 Postgres 图后端目前不适合生产；生产关系检索仍应考虑 Kuzu 或 Neo4j 等图原生后端。