重新理解 AI 的记忆,这个开源项目给了我不少启发

所以这段时间我看 AI Agent、看 RAG、看 memory system，关注点和以前有点不一样。以前我可能更在意一个项目能不能跑起来，现在我更在意，它对知识这件事到底是怎么理解的。因为只要你真的开始做知识工作者场景，就会很快发现，大家现在谈 Agent，谈工作流，谈工具调用，谈 planning，谈 autonomy，谈得都很热闹，但真正被低估的，可能还是记忆。

AI 最缺的是记忆

原因很简单。没有记忆，再聪明的 Agent 也很容易像个短期失忆的人。你这次跟它说过的话，它下次忘了；你前面已经处理过的知识，它后面又重复走一遍；你明明给了很多上下文，它还是只能在当下窗口里做一个局部最优的回答。

很多团队一开始解决这个问题，用的都是比较熟悉的办法，给它套一个 RAG。先把文档切 chunk，做 embedding，向量召回，再把结果塞回模型上下文里。这条路当然有用，我自己也不觉得 RAG 已经过时了。但你做得稍微深一点，就会发现它有一些很难回避的问题，检索命中了不等于真正理解了，语义相似不等于关系完整，文档之间的上下文经常还是断的，而且一旦涉及多跳推理、时间顺序、人物关系、跨源知识，传统 RAG 很容易开始露出底层的简化假设。

也就是在这个时候，我看到 Cognee 这个项目，第一反应是，这玩意和我现在在做的事情，理念上居然还挺接近。不是说它和 Clawme 一样，也不是说两边要解决的问题完全重合，而是它至少在认真回答一个更像下一阶段的问题，如果我们不把 Agent 的记忆只理解成“可检索文档”，而是理解成一个会持续学习、会形成关系、会演化的知识层，会怎样？

这就是 Cognee 最有意思的地方。它不是简单地把 RAG 再包装一下，然后换个名字。它更像是在试图搭一层真正的 memory engine，让数据不只是能被搜到，还能被关联、被更新、被延展，最后变成一个 Agent 真正可用、可持续生长的记忆系统。

Cognee它到底是什么

按官方的定义，Cognee 是一个开源的 knowledge engine。它的目标是把任意格式、任意结构的数据摄入进来，然后持续学习，给 AI agent 提供「正确的上下文」。

这里有几个关键词特别重要。

一个是 任意格式和结构。

另一个是 持续学习。

还有一个是 正确的上下文。

这三个词加在一起，其实已经说明它和很多传统 RAG 项目的差别了。它关心的不是把文本塞进向量库就算结束，而是摄入之后，怎么把这些数据真正变成一个可搜索、可连接、可演化的知识系统。

从架构上看，Cognee 不是只用向量库，也不是只做图数据库。官方文档写得很清楚，它现在本质上是一个三层存储架构。

• Relational store 负责追踪文档、chunk 和 provenance，也就是来源和处理链路
• Vector store 负责语义相似检索
• Graph store 负责实体与关系的知识图谱

你可以把它理解成，很多项目只解决了「怎么找到像的东西」，而 Cognee 想同时解决两件事，一是按意思找，二是按关系找。

这就是它最吸引 AI 开发者的地方。因为很多 Agent 的记忆问题，本来就不是简单的语义相似问题，而是关系问题。用户和用户之间的关系，任务和任务之间的关系，某个问题和之前解决方案之间的关系，某个时间点发生的事和另一个时间点之间的关系。你如果只靠 embedding 去近似，能覆盖一部分，但很难优雅地覆盖全部。

Cognee 至少在架构上承认了这一点。

为什么说它更像记忆层，不只是 RAG 补丁

我觉得这点要单独讲一下。

因为现在大家很容易把所有跟知识和检索相关的项目都扔进一个筐里，统称为 RAG。这样省事，但其实会掩盖很多差异。

传统 RAG 的出发点通常是这样的，把一堆文档切片、向量化，查询来了以后召回最相关的几个片段，再让大模型基于这些片段回答问题。这个路径对 FAQ、知识库问答、单轮检索增强很有效，也依然是很多团队最现实的方案。

但问题是，Agent 的记忆不只是问答。它要记住历史会话、记住执行结果、记住用户偏好、记住跨任务知识、记住失败模式、记住哪些关系已经在过去被证实过。这种时候，你需要的不只是 retrieval，你需要的是 memory。

Cognee 的设计明显在往这个方向靠。

官方现在给出的主操作不只是 add 和 search，而是更像一组长期运行的记忆动作，remember、recall、forget、improve。你一看就知道，这套命名的心智模型已经不是传统检索系统，而是更接近一个能记、能取、能删、还能从反馈里继续学的系统。

这也是为什么我会觉得它更像记忆层。因为它在抽象上已经把「知识是可以被持续更新和组织的」这件事，提到了第一位。

它的核心工作流，为什么值得开发者留意

Cognee 的官方文档现在更常用的是 add -> cognify -> search / memify 这套说法。你可以把它理解成一条比传统 RAG 更完整的 ECL 管道。

第一步是 add，先把原始数据放进来。

这里做的是 ingestion。官方文档写得很细，它支持原始文本、本地文件、目录、S3 URI，甚至 Office 文档、PDF、图片、音频这类都能吃。数据先进 dataset，做标准化、去重、记录来源。

第二步是 cognify。

这一步是它最关键的地方。文档里写得很明确，cognify 会把数据变成 chunks、embeddings、summaries、nodes 和 edges。也就是说，它不是只切片和向量化，还会做实体和关系抽取，把东西送进图数据库，再把摘要和节点嵌入送进向量库。

官方甚至把 cognify 拆成了六个步骤，文档分类、权限检查、chunk 抽取、graph 抽取、summary 生成、data points 写入。这里我觉得很值得开发者注意的一点是，它把结构化知识抽取和语义索引放在同一条标准流水线上了，而不是让你自己额外再拼一套 graph-RAG。

第三步是 search。

这个地方也很有意思。官方文档现在强调的不是单一检索模式，而是 vector similarity + graph structure + LLM reasoning 的组合。你去看他们的 search 文档，能看到它把模式、dataset scope、权限、会话记忆、observability 都当成正式能力来讲，而不只是一个 top_k recall。

第四步是 memify。

这个词一开始看着有点怪，但我觉得它挺贴切。它做的事情不是重新 ingest 原始数据，而是基于现有知识图谱再做 enrichment。官方定义也很清楚，memify 负责在已有 graph 上继续提取、推导、补充新的知识。对于开发者来说，这意味着 Cognee 不只是一次性处理层，它还有继续长的能力。

这几步连起来，你会发现它的目标已经不是「把文档喂给模型」，而是「把文档变成一个会生长的知识层」。

为什么它会让 AI 开发者眼前一亮

从 AI 开发者的角度，我觉得 Cognee 有几件事情是很加分的。

第一，抽象做得比较顺手。

你不需要一上来就理解全部底层细节，官方 quickstart 现在就是很直接的几步，uv pip install cognee，配置 LLM_API_KEY，然后开始 remember、recall、forget。README 里那段经典示例确实很有传播力，因为它把一个复杂问题压缩成了一个很容易试的起点。

第二，概念上是统一的。

很多开发者自己做 Agent 记忆层，痛苦的地方往往不是不会做，而是东西散。向量库是一套心智模型，图数据库是一套心智模型，会话缓存又是一套心智模型，用户反馈学习又是另一套。Cognee 至少是在试图给你一个统一接口，把这些事放进一条 coherent 的 pipeline 里。

第三，跟现在主流 Agent 生态贴得很近。

GitHub README 里已经直接写了，它有 Claude Code 插件，也能接 Hermes Agent，还可以把任何 Python agent 指到 Cognee Cloud。这就非常实际。很多开源项目看着很美，但离真实工作流很远。Cognee 现在给人的感觉是，它不仅想做一个研究味很浓的记忆系统，也想成为你真的能接进开发栈里的组件。

第四，数据和权限边界考虑得比很多 demo 项目认真。

文档里一直在讲 dataset、permissions、ownership、access control。这说明它不是只想着「能跑起来」，而是开始在往真实团队环境和多用户环境走。对开发者来说，这比单纯多几个 benchmark 更重要，因为你总不能真的把生产数据全扔给一个没边界的 memory layer。

这个项目现在能用到什么程度

如果只看 GitHub 面，它现在已经不算小项目了。2026 年 4 月 18 日 我看到的 star 是 16.2k，fork 1.7k，最新 release 是 v1.0.1.dev1，发布时间是 2026 年 4 月 15 日。仓库本身也很活跃，6,700 多次提交，不是那种突然火一把的样子货。

从使用层面，至少有几件事是已经很明确的。

• 它支持本地安装，Python 3.10 到 3.13
• 支持 uv、pip、poetry
• 有 CLI，cognee-cli remember/recall/forget
• 有本地 UI，直接 cognee-cli -ui
• 有 Claude Code 插件
• 有 Hermes Agent 集成
• 也有托管版 Cognee Cloud

官方文档还写得很清楚，它支持 session_id 做会话记忆，也支持 dataset 级别的组织和权限控制，支持时间感知查询，支持图和向量混合检索，支持在现有图谱上做 enrichment。这些东西加在一起，对一个想做 Agent memory 的团队来说，吸引力是很实在的。

快速上手到底有多快

如果只是想先感受一下，它确实很快。

官方 quickstart 现在最小可行的起手式就是：

import osimport cogneeimport asyncioos.environ["LLM_API_KEY"] = "YOUR_OPENAI_API_KEY"async def main():    await cognee.remember("Cognee turns documents into AI memory.")    results = await cognee.recall("What does Cognee do?")    print(results)asyncio.run(main())

安装也就是：

uv pip install cognee

或者：

pip install cognee

或者：

poetry add cognee

CLI 也很直观：

cognee-cli remember "Cognee turns documents into AI memory."cognee-cli recall "What does Cognee do?"cognee-cli forget --all

要开本地 UI，就：

cognee-cli -ui

这种上手路径对开发者很友好，因为它把试错成本压得很低。你不需要先部署一整套复杂系统，就可以先摸到 API 的手感。

对 AI 开发者最有启发的，不只是功能，而是思路

如果我是纯从开发者视角来给 Cognee 做一句评价，我会说，它最有价值的地方，不只是把向量检索和图数据库拼在一起，而是它把「Agent 的记忆应该是什么」这件事，往前推了一步。

它在提醒大家，记忆层不是模型旁边一个可有可无的小外挂，也不是简单的 context stuffing。真正好用的 Agent memory，应该至少同时满足几件事。

• 能 ingest 各种真实世界数据
• 能保留来源和演化路径
• 能做语义相似搜索
• 能表示实体与关系
• 能按会话和长期记忆分层
• 能在反馈之后继续更新
• 最好还能接进你已经在用的 agent 框架

Cognee 现在当然还不是完美答案，但它至少是在用一个比较统一的系统设计，认真回应这些问题。

对普通人有什么启发

如果你不是开发者，看到这里可能会觉得，这不还是程序员的事情吗。

某种程度上是。

但我觉得它给普通人的启发也挺直接的，AI 真正缺的，从来不只是更聪明的大脑，而是更可靠的记忆。

你今天和一个 AI 聊得很顺，明天它就忘了；你教会它一件事，换个会话它又重新变回陌生人；你把很多资料喂进去，结果它每次都只能临时现查。很多普通用户对 AI 的失望，其实不来自「它不够聪明」，而来自「它不够记得」。

从这个角度看，Cognee 这种项目有一个很重要的提醒，未来更好用的 AI，不一定只是答案更漂亮，而是它开始真正记住你、记住上下文、记住关系、记住历史，并且在这些记忆之间建立连接。

这才是 AI 从工具走向助手，再从助手走向系统的一条关键路径。

最后

我不想把 Cognee 写成一个包治百病的神项目。开源项目看到这个阶段，真正值得关注的不是赞美词，而是它有没有抓住一个真实问题，能不能提供一套自洽的解法。

Cognee 在我看来，至少做到了第一点，而且第二点也已经有了一个挺清楚的轮廓。它把向量搜索、图数据库、数据摄入、知识演化、会话记忆、Agent 集成这些东西，往一条统一记忆层的方向拉拢。这个方向本身，就已经足够值得 AI 开发者认真看一眼。

如果你正在做 AI Agent，或者你已经被传统 RAG 的效果折腾得有点烦，我觉得它值得你花一点时间上手试试。不是因为它会立刻替代所有现有方案，而是因为它很可能会帮你重新想一遍，Agent 的记忆到底应该怎么设计。

而如果你不是开发者，这个项目也至少在提醒你一件事，未来 AI 真正拉开差距的，不只是会不会说话，而是会不会记得，会不会连接，会不会在记忆里继续生长。

这件事，比很多人想象中重要。

来吧，加入 AI 社群