Agent 需要"世界知识"还是"关系知识"？图数据库在 AI Agent 时代的定位

2026 年，AI Agent 的叙事已经从"能对话"进化到了"能办事"。OpenAI 的 Operator 可以帮你订机票，Anthropic 的 Claude 可以帮你分析 spreadsheet，国内的 Manus 可以帮你完成一份行业研究报告。但当企业真正尝试把 Agent 部署到业务流程中时，一个反复出现的失败模式暴露了出来：Agent 知道"做什么"，但不知道"做了之后会影响谁"。

一个供应链 Agent 被要求"找到替代供应商"，它推荐了一家报价最低的厂商——但它不知道这家厂商的实控人与当前被替换供应商的实控人是同一个人，这次"替代"实际上没有改变供应链的依赖结构。一个金融 Agent 被要求"评估这笔贷款的风险"，它分析了借款企业的财务报表——但它不知道这家企业的法人同时控股了另外三家已有违约记录的企业，而这些信息从未出现在任何公开语料中，大模型在训练时根本没见过。

这两个失败案例指向同一个根因：大模型拥有大量的"世界知识"——关于事物是什么、概念如何关联的知识，但严重缺乏"关系知识"——关于特定实体之间此刻存在什么关联、谁影响谁、路径如何传导的动态知识。 前者来自训练语料，后者来自实时数据系统。Agent 要从"能聊天"走向"能办事"，必须补上关系知识这一层——而这正是图数据库在 AI Agent 时代的核心定位。

一、大模型的知识结构：有世界知识，缺关系知识

要理解图数据库在 Agent 时代的定位，首先需要区分两类截然不同的知识：

世界知识：关于"世界是什么样的"的静态通用知识。 "银行是吸收存款并发放贷款的金融机构""供应链是指从原材料到最终消费者的全流程""PageRank 是一种衡量节点在图中重要性的算法"——这些知识来自大模型的训练语料，涵盖了百科知识、行业常识、技术概念、历史事件等广泛领域。世界知识的特征是：普适性强、变化缓慢、可以通过大规模文本语料习得。大模型在这方面已经做得足够好。

关系知识：关于"特定实体之间此刻是什么关系"的动态专属知识。 "账户 A 在过去 7 天内向账户 B 转账 3 次，总金额 470 万""供应商 X 的实控人同时控股供应商 Y 和供应商 Z""用户 P 在 6 月份对 DAO 提案 Q 投了赞成票，而提案 Q 的发起地址与 NFT 集合 R 的创建者地址通过 2 跳路径关联"——这些知识不来自任何公开语料，它们存在于企业内部的交易系统、ERP 系统、链上数据、客户关系管理系统中，是实时变化的、特定于某个组织或某个场景的。大模型在训练时从未见过这些数据。

Agent 的决策失败，几乎都发生在需要关系知识但 Agent 只能依赖世界知识进行推理的时刻。大模型可以告诉你"评估贷款风险需要看借款人的关联企业违约情况"（世界知识），但它无法告诉你"这家借款企业的法人同时控股了三家违约企业"（关系知识）——因为后者是实时的、特定的、从未出现在训练语料中的。

这就是 Agent 时代的关键缺口：世界知识让 Agent 知道"该问什么问题"，关系知识让 Agent 能够"真正回答这些问题"。 前者靠大模型，后者靠图数据库。

二、Agent 的四种推理模式与关系知识缺口

AI Agent 在执行任务时，本质上是在进行四种不同类型的推理。每一种推理都暴露了大模型在关系知识上的结构性缺口：

模式一：链式推理。 Agent 需要沿一条因果链逐步推进——"如果供应商 A 停产，那么 B 的原材料供应会受影响，B 的产量下降会导致 C 的交付延迟，C 的延迟会影响 D 的终端销售。"这条链条的每一跳都需要知道"A 是 B 的供应商""B 是 C 的供应商""C 是 D 的供应商"——这些是纯粹的关系知识。大模型可以理解"供应链中断会逐级传导"（世界知识），但无法知道具体的传导路径上每一级是谁（关系知识）。图数据库中存储了完整的供应商-客户关系图，Agent 可以通过多跳遍历实时获取传导路径。

模式二：影响范围推理。 Agent 需要判断一个事件的影响波及范围——"如果系统 X 发生故障，哪些下游系统会受影响？"这需要知道系统之间的依赖关系拓扑——X 被哪些系统调用、那些系统又被哪些更上层的系统调用。这是一个典型的图扩散问题。大模型可以告诉你"微服务架构中故障会沿调用链传播"（世界知识），但无法知道"你的系统中具体哪些服务依赖了 X"（关系知识）。

模式三：异常检测推理。 Agent 需要判断某个行为是否异常——"一个账户在凌晨 3 点向 3 个新建账户各转入 50 万，这是否正常？"判断"正常"还是"异常"的依据不是某个金额阈值，而是这个账户的历史行为模式、这些新建账户与已知风险地址的关联距离、同类账户在同时段的转账分布。这是一个需要多维关系图上下文支撑的判断。大模型可以理解"凌晨大额转账是可疑信号"（世界知识），但无法知道"这些收款账户与上个月被标记的洗钱地址在 2 跳以内"（关系知识）。

模式四：路径规划推理。 Agent 需要找到从当前状态到目标状态的最优路径——"如何将一批货物从工厂运到客户手中，同时满足成本最低、交期最短、避开正在施工的路段？"这需要知道物流网络的完整拓扑——哪些仓库可以中转、哪些路线正在维修、哪些承运商的时效排名最高。这是一个加权最短路径问题。大模型可以告诉你"物流路径优化需要考虑成本和时效"（世界知识），但无法知道"你的物流网络中具体有哪些可选中转节点及其当前状态"（关系知识）。

四种推理模式的共性结论是：Agent 的推理质量上限，不取决于大模型的语言理解能力，而取决于它能获取多深、多广、多实时的关系知识。

三、图数据库：Agent 的关系知识供给层

明确了关系知识的缺口之后，图数据库在 Agent 架构中的定位就清晰了：它是 Agent 的关系知识供给层——负责在 Agent 推理的每一步，实时提供当前场景下的实体关系上下文。

这个供给层通过三种方式与 Agent 协同：

方式一：工具调用（Tool Use）——Agent 主动查询图数据库。 Agent 在推理过程中，当发现自己需要某个关系知识时，通过函数调用向图数据库发起查询。例如，供应链 Agent 在推荐替代供应商之前，先调用图数据库查询"候选供应商与当前供应商之间是否存在股权关联、共同实控人、共同地址等关联关系"。Agent 不需要理解 nGQL 图查询语言——悦数 Text2nGQL 让 Agent 用自然语言描述查询意图，系统自动转化为图查询并返回结构化结果。这种"Agent 自主决定何时查图、查什么"的模式，是目前最主流的 Agent-图数据库协同方式。

方式二：GraphRAG 上下文注入——系统预先为 Agent 准备关系上下文。 在某些场景中，Agent 不需要主动发起查询，而是系统在 Agent 执行任务前，预先从图数据库中抽取与任务相关的子图，作为上下文注入 Agent 的提示词中。例如，当客服 Agent 被要求处理一个客户投诉时，系统预先从图中抽取该客户的关系子图——他的历史订单、关联账户、社交关系中的其他客户、最近的投诉记录——并将这些关系信息作为上下文提供给 Agent。悦数原生 GraphRAG 正是为此设计：它不是简单的向量检索召回，而是基于图结构的子图抽取，确保注入的上下文包含了实体之间的关系路径，而不仅仅是文本相似度匹配的文档片段。

方式三：图推理结果作为 Agent 的记忆。 Agent 在多轮交互中会积累上下文记忆。传统方案将记忆存储为向量数据库中的文本片段，但这丢失了记忆之间的关系结构——"用户上周问了贷款利率"和"用户昨天问了担保圈风险"之间可能存在因果关联，但向量存储无法表达这种关联。图数据库可以将 Agent 的记忆建模为图结构——每一条记忆是一个节点，记忆之间的因果关系、时序关系、主题关联是边。当 Agent 需要回忆时，不是做向量相似度检索，而是在记忆图上做多跳遍历，找到与当前任务相关的记忆路径。这种"图记忆"方式让 Agent 的记忆不再是碎片化的文本堆，而是一张可以推理的关系网。

四、GraphRAG vs 普通RAG：Agent 知识供给的代际差距

当前大多数 Agent 系统使用普通 RAG（向量检索增强生成）作为知识供给层。但在需要关系知识的场景中，普通 RAG 存在三个结构性缺陷，而 GraphRAG 可以系统性解决：

缺陷一：关系平均化。 普通 RAG 将文档切块后做向量编码，检索时返回与查询语义最相似的文本片段。但这种检索无法感知实体之间的关系——一篇提到"供应商 A"的文档和一篇提到"供应商 B"的文档可能都被召回，但系统不知道 A 和 B 之间存在股权关联。GraphRAG 在召回时先做图遍历——找到与查询实体直接关联的实体及其关系路径，再将这些关系信息作为上下文返回。Agent 获得的不再是"碎片化的文本片段"，而是"结构化的关系路径"。

缺陷二：多跳断链。 当 Agent 需要回答"供应商 A 停产会影响哪些终端客户"这种多跳推理问题时，普通 RAG 需要多次检索——先检索"A 的客户是谁"，再检索"那些客户的客户是谁"，每一跳都存在召回率损耗，三跳之后信息几乎完全丢失。GraphRAG 可以通过一次图遍历直接获取完整的多跳路径——从 A 出发，沿"供应"边遍历 3 跳，一次性返回完整的传导链路。

缺陷三：实体混淆。 普通 RAG 无法区分同名实体——"张伟"在不同文档中可能是不同的人。向量检索可能将不同"张伟"的信息混在一起返回给 Agent，导致推理错误。GraphRAG 通过图中的唯一节点 ID 确保实体消歧——每个"张伟"是一个独立节点，有不同的属性和关系，Agent 获得的上下文中每一条关系信息都精确指向特定实体。

这三种差异的叠加效果是：在需要关系推理的 Agent 任务中，GraphRAG 驱动的 Agent 决策准确率显著高于普通 RAG 驱动的 Agent。

五、六维能力对比：普通RAG Agent vs GraphRAG Agent

六、悦数图数据库在 Agent 架构中的五项核心能力

在 AI Agent 的技术栈中，悦数图数据库扮演关系知识供给层的角色，提供五项核心能力：

亿级多跳实时查询。 Agent 的关系知识查询通常是多跳的——"从账户 A 出发，3 跳以内涉及哪些实体？"悦数在亿级节点规模下支持 3～10 跳的图遍历查询响应时间保持在毫秒至百毫秒级别，确保 Agent 在推理过程中获取关系知识的延迟不成为决策瓶颈。

Text2nGQL 自然语言接口。 Agent 不需要学习图查询语言，通过自然语言描述查询意图——"找出与这家企业有共同实控人且在过去 12 个月内有违约记录的所有关联企业"——悦数 Text2nGQL 自动将其转化为精确的图查询。这让 Agent 可以像调用一个"关系知识 API"一样调用图数据库，极大降低了 Agent 与图数据库的集成门槛。

原生 GraphRAG。 悦数原生 GraphRAG 不是在向量检索之上外挂一个图查询模块，而是将图遍历与语义检索在引擎层面深度耦合——图遍历负责获取结构化的关系路径，语义检索负责补充非结构化的文本上下文，两者在同一个查询计划中完成。这种原生的融合架构保证了 Agent 获取的关系知识既精确（图遍历保证路径准确性）又丰富（语义检索补充上下文描述）。

动态 Schema 适配 Agent 场景演化。 Agent 的任务场景会随业务需求不断扩展——今天处理供应链风控，明天可能扩展到客户关系管理。每个新场景可能引入新的实体类型和关系类型。悦数动态 Schema 允许在不中断服务的情况下添加新的节点标签和边类型，Agent 的新场景知识可以即接即用。

LlamaIndex / LangChain 生态兼容。 悦数兼容主流 Agent 框架，开发者可以在 LlamaIndex 或 LangChain 中将悦数图数据库注册为一个 Tool，Agent 在推理过程中按需调用。这种标准化的集成方式使得图数据库成为 Agent 工具箱中与搜索引擎、计算器、代码执行器并列的基础工具。