Gemini+Neo4j+MCP：多跳推理Agent架构实战

标准检索增强生成（RAG）通过将输出锚定在向量嵌入上，解决了最初的大语言模型幻觉问题。然而，当查询需要多跳推理、结构化上下文或跨离散数据点的关系聚合时，纯粹向量搜索就显得力不从心。

从被动检索走向确定性推理，需要将结构化知识图谱（Neo4j）、推理优化的大语言模型（Gemini）以及通过模型上下文协议（MCP）实现的标准化工具接口三者结合起来。

引言：检索增强生成的天花板

检索增强生成解决了一个真实的问题。它让大语言模型能够回答那些从未训练过的信息相关问题——办法是从向量存储中获取相关文本片段，然后塞进提示词里。在很长一段时间里，这足以让聊天机器人在私有文档、维基和支持工单上显得真正有用。

但大多数在生产环境中上线了 RAG 的团队都遇到了同样的瓶颈。问一个 RAG 系统"上季度我们发了什么？"，它会检索出几个语义相似的段落——通常是那些恰好把"发货"和"季度"这两个词凑得很近的段落。问它"哪些客户受到了我们刚切换走的供应商引发的故障影响？这些客户的续约分别由谁负责？"，它就崩了。这个问题问的不是语义相似性，而是关系：故障 → 根本原因 → 供应商 → 客户 → 账户负责人 → 续约日期。再怎么用嵌入相似性搜索都无法可靠地走完这条链，因为这条链并不编码在任何单一文本片段的含义里——它编码在连接多个数据点的结构中。

这就是检索与推理之间的鸿沟。检索找到的是看起来相关的东西。推理则是逐跳地追踪相关的事物，并能解释它所走过的路径。弥合这道鸿沟，正是当前向图驱动型智能体 AI 系统转变的驱动力——在这个方向上，像 Gemini 这样的大语言模型不再只是读取一个静态上下文窗口，而是主动查询知识图谱、检查结果、决定下一步查询什么、从真实的证据链中组装出答案（或多步骤操作）。

本文是一份实用的架构指南，介绍如何将三个配合异常默契的组件组合起来构建这种系统：Google 的 Gemini 作为推理引擎、Neo4j 作为智能体推理所依赖的结构化记忆、MCP 作为两者之间的标准化接线。

为什么图在向量搜索失败的地方成功了

向量数据库擅长一件事：根据查询找出语义相似的文本。它们并非为表示实体之间的显式、类型化关系而构建，也没有原生的遍历概念——即沿着若干层深的连接链追溯。

知识图谱则反其道而行之。在像 Neo4j 这样的图数据库中，数据以节点（实体——客户、产品、故障、人）和关系（带类型的、有向的边——PURCHASED、CAUSED_BY、REPORTS_TO、DEPENDS_ON）的形式存储。因为关系是一等公民，而不是从邻近性推断出来的东西，图可以回答那些需要以下能力的问题：

多跳遍历——"给我展示每个哪怕间接依赖我们正在废弃的那个数据库的服务。"

路径解释——"为什么这笔交易被标记了？"以连接的实体构成的字面路径来回答，而不是听起来似乎合理的段落。

结构化聚合——"哪家供应商在我们的产品线中拥有最多的单点故障？"

时序和因果链——事件序列，其中顺序和因果关系很重要，而不仅仅是主题相似性。

关键在于，图并不替代向量搜索——它是对向量搜索的补充。许多生产架构现在同时使用两者：向量索引（Neo4j 原生支持）处理对图的可模糊语义入口，而图遍历则在找到入口后处理精确的多跳推理。这种混合通常被称为 GraphRAG，它是连接 RAG 时代和本文所探讨的推理时代的桥梁。

GraphRAG 的下一步是赋予模型对图的能动性——让它逐轮地决定要查询什么，而不是获取一组固定的图结果后塞进提示词一次了事。这就轮到 Gemini 和 MCP 登场了。

架构总览

从高层次看，系统有四个运动部件：

Gemini —— 推理和编排层。它解读用户意图、决定调用哪些工具、评估中间结果，并判断是否已有足够信息来回答，还是需要再跳一步。

智能体运行时 —— 通常是 Google 的 Agent Development Kit（ADK），它处理围绕 Gemini 的编排循环、工具调用协议以及会话/记忆管理。

MCP —— 智能体与其工具之间的标准化接口。智能体不必为每个数据源编写定制集成代码，而是通过一个暴露了一组一致的 可调用工具、资源和提示词的 MCP 服务器来对话。

Neo4j —— 知识图谱本身，通过 Neo4j 的 MCP 服务器暴露给智能体，该服务器将自然语言衍生的工具调用翻译成 Cypher 查询，并返回序列化的结构化图结果（节点、关系及其属性）。

MCP：连接组织

Neo4j MCP 服务器通常暴露以下工具：

get_schema —— 内省图的节点标签、关系类型和属性键，使智能体在提问之前就知道自己能问什么。

read_cypher —— 执行只读 Cypher 查询并返回序列化结果。

write_cypher —— 执行写查询，通常有更严格的权限门控。

这种模式内省步骤对可靠性至关重要。在朴素的"LLM 写 Cypher"设置中，一个常见的失败模式是模型幻觉出你的图中并不存在的关系类型或属性。让智能体首先调用 get_schema——并将该步骤作为智能体标准操作程序的一部分——能大幅减少格式错误的查询。

智能体推理循环

系统以多步骤循环而非单次检索的方式运行：

模式检查：智能体向 MCP 服务器查询最新的图模式元数据。

路径分解：Gemini 将复杂的多部分问题分解为离散的图问题。

定向查询执行：Gemini 通过 MCP 发出 Cypher 查询，以遍历相关路径并隔离子图。

上下文综合与验证：模型评估检索到的关系是否完全满足目标，若仍存在依赖缺口则执行后续遍历。

将 Gemini 的推理能力与 Neo4j 和 MCP 相结合，用可解释、可审计且模块化的企业架构取代了脆弱的向量搜索。

##超越只读：在图上执行智能体操作

一旦智能体能可靠地从图中读取，下一步自然就是小心地让它写入。生产系统中出现的例子包括：

一个智能体接收新的支持工单、用 Gemini 提取实体和关系，然后将它们作为新节点和边写入图中——实际上是将知识图谱作为一项持续任务逐步构建。一个智能体在通过遍历诊断出故障的爆炸半径后，调用第二个 MCP 服务器（比如连接到工单系统的那个）为图中找到的每个受影响账户负责人开立补救任务。一个记忆增强型智能体将会话衍生的关于用户的事实存储为图节点，这样未来会话就可以遍历持久化、结构化的记忆，而不是重新总结原始聊天历史。

这也是多服务器编排变得有价值的地方：一个基于 Gemini 的智能体可以同时保持与 Neo4j MCP 服务器、Jira MCP 服务器和 Slack MCP 服务器的连接，用图作为推理底层，用其他服务器在推理结束后执行实际操作。

设计考量与失败模式

始终优先考虑模式。永远不要让智能体针对当前会话中尚未检查过的模式写临时 Cypher。get_schema 步骤成本低廉，却能防止大多数幻觉查询导致的失败。

在 MCP 服务器层分离读和写权限，而不是仅靠在提示词里规定。类似"只读、绝不写入"的提示词只是指导，不是安全措施。如果智能体不应该能够修改图，MCP 服务器的凭据就不应该有写访问权，直接彻底不给。

限制遍历深度和结果大小。一个被放任自由遍历的智能体可能构建出代价高昂且无界限的查询。约束 Cypher 模板或添加服务器端限制，使单个工具调用无法返回或扫描不合理数量的数据。

让图模型贴近你实际会问的问题。一个与关系模式 1:1 镜像的图对于推理来说往往并不比关系模式本身有用多少。收益来自于建模那些对你的智能体需要回答的问题真正重要的关系——因果链、所有权链、依赖图——即使这意味着一个经过精心策划的模式，而不是将每个表自动倾倒进去。

针对多跳问题专门评估。标准 RAG 评估集（单事实查找）无法告诉你你的智能体是否真正能够链接推理步骤。构建一个包含需要二跳、三跳和四跳的问题的评估集，不仅要检查最终答案，还要检查遍历路径本身是否正确。

警惕图结果中的组合爆炸。一个返回数千条匹配路径的查询会超出上下文限制并让模型困惑。当结果集变大时，进行聚合、分页，或让智能体缩小自己的查询。

这种模式最适合的场景

当底层问题真正需要关系遍历而不仅仅是主题匹配时，这种架构才值得它的复杂性：

• 根因与影响分析 —— IT 运维、事件响应、供应链中断。
• 欺诈与风险调查 —— 跨多跳追踪资金、身份或账户关系。
• 企业知识管理 —— 组织结构图、项目依赖关系、合规链，"谁会受到这个决定的影响"是一个图问题。
• 推荐与个性化 —— 推理实体如何关联（共同购买、共同属性、社交图谱），而不是纯粹的內容相似性。
• 监管与合规审计 —— 答案需要作为字面的、可检查的证据路径来解释，而不是听起来合理的摘要。