我的AI代理在会话之间总是忘记'Karpathy'是谁。以下是解决这个问题的架构

我在 Obsidian、Readwise、NotebookLM 和 Claude Code 上运行第二大脑。针对每个主题，我建立一个范围化的维基，结构为 Andrej Karpathy 提出的 LLM 知识库。随着知识库的增长，它无法提取和维护共享实体和事实。如果"Claude Code"出现在10个文档中，一旦超过50个文档，我就无法统一它、按频率排序，或将其链接到 Anthropic、Codex 和 Gemini CLI。问题在于文件系统是仅追加的日志，会碎片化上下文，而向量索引提供模糊回忆但没有身份感，因此无法知道这是否与你昨天遇到的同一个"Karpathy"实体。知识图谱记忆是从 RAG 到智能体 RAG，再到通过 GraphRAG 实现的智能体记忆弧线上的下一步，我花了2天时间阅读的一个 Neo4j 仓库完美体现了这一模式。持久的智能体记忆需要一个跟踪身份的结构化图谱，而不仅仅是回忆。以下是架构： 1. 该仓库有一个 SDK，在写入侧输入自然语言，在读取侧输出融合的记忆上下文，全部锚定到一个 Neo4j 图上。 2. 该架构在一个图中使用3层记忆：短期记忆是线性的`:Message`序列，长期记忆是去重的类型化`:Entity`图。推理记忆以每轮智能体运行的树结构存储，保存过去成功或失败的思维模式，使智能体能够一次性处理未来的请求，这类似于强化学习，但在数据库层面实现。 3. 系统遵循 POLE+O 本体论，这是一个包含人、物、地点、事件和组织5种类型的封闭词汇。每个实体恰好是一种类型，具体化为多层 Neo4j 标签，还有用于通用声明的`:Fact`节点和使用`SUPERSEDED_BY`关系的`:Preference`节点。 4. 提取工作是一个速度与精度的阶梯：spaCy 处理快速命名实体识别，GLiNER/GLiREL 进行零样本提取。LLM 阶段仅在实际语义和关系时触发，因此廉价模型处理高置信度案例，无需为每个提及支付 LLM 成本。 5. 解析和去重是两个不同的问题。解析通过模糊匹配规范化名称，而去重使用向量分数决定是否创建新节点。误合并是静默且不可恢复的。误拆分有噪声但可恢复。 6. 单个 Cypher 查询通过融合向量相似性、多跳遍历和对话步行处理整个检索。这消除了跨存储连接或外部协调器的需求，但上下文压缩仍然是你的责任。 这个仓库是一个蓝图，不是一个定论。你可以借用这些模式，在 Postgres 或 MongoDB 上实现，以避免在生产中运行图数据库。我仍然使用 Neo4j 进行数据挖掘，但在代码库中花费2天后，逻辑更重要。你目前如何处理智能体记忆？平面文件、向量索引、知识图谱，还是更奇特的东西？**TL;DR：** 文件和向量存储可以回忆文本，但无法跨会话跟踪身份。带有类型化实体和正式去重步骤的知识图谱，才能将回忆转化为持久记忆。