构建 Agentic GraphRAG 系统：从知识图谱和本体论到作为 AI 智能体 MCP 服务器的统一记忆

我在一个月内两次进行了这场演讲：一次是在 O’Reilly 的上下文工程大会（Context Engineering Event）上，另一次是在 Abi Aryan 关于大规模 LLM 推理的 Maven 课程上。在被各种问题轰炸后，我意识到一件事：GraphRAG 不是检索算法，而是一个数据建模问题。利用知识图谱（KGs）和本体论来赋能智能体仍然是一个未解之谜。与我交谈的所有工程师都希望实现 GraphRAG，但不知道如何实施。但核心而言，我们应该问一个不同的问题。我们为什么首先需要 GraphRAG？为什么要把解决方案变得比简单的 RAG 系统更复杂？有三个核心原因：1. 上下文腐烂 2. 数据碎片化 3. 智能体的统一记忆自然地映射为知识图谱（KG）。在深入 GraphRAG 的兔子洞几个月后，我将其简化为以下 5 个组件： 1. 数据管道在构建任何图形结构之前收集和规范化信息。从 URI、笔记、电子邮件和 Google Drive 中提取内容，将所有内容规范化为单个文档集合。 2. 记忆管道将文档转换为带类型的三元组，而非自由格式的数据块。每个文档变为（实体，关系，实体）三元组，写入作为知识图谱建模的统一记忆中。本体论通过限制 LLM 仅使用六种实体类型和八种带类型的边（如 `PERSON`、`TASK`、`RELATED_TO` 或 `HAS`）来保持系统的合理性。 3. 知识图谱是可查询的工件。这是智能体与之交互的物化视图，其中属性以 JSON 形式挂在节点和边上。你使用混合索引，通过倒数秩融合（Reciprocal Rank Fusion）合并文本和语义搜索以作为入口点，然后在带类型的边上执行 2-3 跳遍历。 4. MCP 服务器暴露两个工具族，而非 40 个端点。`search_memory` 工具仅将智能体需要的图片段带入上下文。`write_memory` 工具按需针对对话或 URI 运行数据和记忆管道。 5. 智能体框架通过承载业务逻辑的技能（如 `assistant-memory` 和 `assistant-learn`）连接 MCP 服务器工具。这些技能决定何时读取、何时写入，以及什么值得记忆。 如我在开头所说，GraphRAG 是一个数据建模问题。因此，永远不要跳过本体论，也不要让 LLM 自由发明标签。例如，当我运行 LangChain 的 `MongoDBGraphStore` 时，我让 LLM 在没有本体论限制的情况下自由提取实体和关系类型。五份文档产生了 17 种节点类型和 34 种关系类型，且 `part_of`、`Part Of` 和 `part of` 同时存在于同一个图中。 在基础设施方面，对于 2-3 跳的遍历，Postgres 或 MongoDB 可以在单一系统中处理文档、向量和图查找。MongoDB 使用 `$graphLookup` 递归遍历节点。只有当深度遍历或专用图算法是你产品的核心时，你才真正需要 Neo4j。或者，你可以轻松地将 Neo4j 保留为第二个数据库，作为内部工具用于可视化和探索图结构，而无需承担生产环境的开销。 当处理数千份文档时，不要为 Google 级别的规模进行设计。你为你的智能体记忆选择了什么样的本体论形状？你在标准数据库和专用图数据库之间划清了怎样的界限？ **TL;DR：** GraphRAG 是一个数据建模问题，而非检索算法。定义本体论，运行数据和记忆管道进入知识图谱，通过 MCP 暴露 `search_memory` 和 `write_memory`，并让智能体框架通过技能将其集成进来。