如果现在对于AI Agent 的知识引擎或者知识库的认知还停留在在「向量库 + embedding + topK 检索」的人，项目大概率正在踩坑。

传统 RAG 解决的是「能不能把资料塞给模型」的问题，而知识引擎要解决的是「模型能不能沿着知识结构走到正确答案」的问题。 这两个层级差得很远。前者偏检索，后者开始接近推理。Agent 一旦进入企业场景，尤其是要处理流程、制度、系统配置、投融资关系、风控链路、故障追因这类问题，知识如果还是碎片状态，后面的规划、调用、执行基本都会失真。因为对于模型来说重要的上下文已经是经是不完整的了，自然而然的就开始瞎猜了。

就 AI Agent 知识引擎来说，研发团队常遇到两个坑：

第一，很多团队高估了向量检索的上限。
第二，很多团队又低估了图结构落地的工程代价。

今天我们聊一下AI Agent 的知识引擎如何从碎片检索走到深度推理。

咱们今天主要聊四件事：

• 为什么传统 RAG 在复杂问题上会持续失手
• GraphRAG 到底重塑了什么
• 真正可落地的架构怎么搭
• 当前有哪些新一些的进展

传统短板

很多人第一次做 RAG，体验都挺好。

文档切块，做向量化，进库。用户一问，召回几段文本，拼 Prompt，模型生成答案。对于 FAQ、制度查询、产品说明、接口文档检索，这一套能迅速出结果，性价比很高。

问题在第二阶段才出现：用户不再问单点事实，而是开始问链式问题。

比如：

• 「2019 年收购 A 公司的企业，其母公司在 2021 年的主要投资对象是谁？」
• 「某服务在去年三季度的故障，和两个月前那次容量扩容有没有关联？」
• 「这份上百篇研报里，哪些公司通过共同供应商暴露了同类风险？」

这类问题有一个共同点：答案不在某一个 chunk 里，而是在多个实体、多个时间点、多个文档之间。

传统 RAG 在这里会出现几种典型失效。

关系丢失

向量检索擅长找「语义相近」。它不擅长找「关系成立」。

文档切块以后，文本里的结构被打散了。原文中可能存在很清楚的逻辑链：

• 公司 B 在 2019 年收购 A
• 公司 B 是集团 C 的子公司
• 集团 C 在 2021 年投资了 D

切完块之后，这三个事实可能散落在不同 chunk、不同文档、不同索引分区里。向量检索能不能一次把它们都召回？经常不能。即便召回了，顺序也未必对，相关性分也未必稳定。

这时候模型只能自己「脑补拼图」。一旦有一块没找到，推理链就断。而且，模型也不会老老实实说「证据不够」，它会倾向于补一个看起来像答案的东西出来。这就是很多人嘴里的幻觉。说白了，很多幻觉并不是生成模型凭空发疯，而是检索层先把它带沟里了。

上下文碎片化

RAG 的 chunk 机制本质上是一个工程妥协。

chunk 太小，语义不完整；chunk 太大，embedding 稀释，召回变钝，窗口成本暴涨。滑窗重叠能缓解一点，但解决不了跨章节、跨文档、跨时间的连续推理。

尤其是企业内部知识库，天然不是一本结构优雅的教材，而是一堆：

• PRD
• wiki
• 飞书文档
• 邮件摘要
• 会议纪要
• Jira 评论
• 数据库导出
• 运维记录
• 外部 PDF

这些东西之间本来就没有自然连续性。你再把它们切成块，信息完整性只会进一步恶化。

实体歧义

只靠向量，相同名字的实体很容易串。

一个公司简称可能对应母公司、子公司、事业部；一个人名可能在不同组织里都出现过；产品代号可能跨年份复用。向量模型对这种歧义问题并不稳定，尤其在中文企业数据里，简称、别名、历史命名混在一起，非常常见。

实际项目里，实体歧义一旦没有解决，后面所有链路都白搭。你在检索层把「A 公司」对齐错了，后面再高级的 Agent 规划、工具调用、答案归因，都是建立在错图上。

时间失真

这个问题很多团队前期根本没建模。

企业知识不是静态的。组织关系会变，制度会改版，接口会下线，股权会变更，设备状态有有效期，药品说明有版本，风控规则按月份生效。

传统 RAG 里，一个 chunk 通常只是一段文本。它不天然携带明确的「生效时间」「失效时间」「版本边界」。所以用户一旦问时间敏感问题，系统就容易把不同年份的事实混成一团。

你会看到模型回答得头头是道，但时间轴已经错了。

多跳能力弱

这个问题其实不是模型不会推理，而是检索不给路。

Agent 场景里，很多问题天然是多跳的。要找到答案，系统需要先定位实体，再沿某种关系扩展，再结合时间、置信度、来源做过滤，最后拿到一条可靠路径。传统向量召回没有这个导航能力，它只会不断找「像不像」。

这就是为什么很多团队把模型从一个升级到另一个，效果只提升一点点。瓶颈不在模型本身，而在知识引擎没有结构。

图谱价值

把知识图谱拉进来，改变了检索目标。

传统 RAG 检索的是文本片段。
GraphRAG 检索的是实体、关系、路径、子图，以及这些结构对应的证据。

这个差别很大。

显式关系

知识图谱最核心的价值，是把原来需要模型从文本里隐式猜出来的关系，变成显式结构。

比如：

• 公司 A — 收购 — 公司 B
• 公司 C — 母公司 — 公司 A
• 公司 C — 投资 — 项目 D

一旦这些关系被建出来，系统面对复杂问题时就不需要靠 Prompt 去碰运气，而是可以沿着边去找路径。路径找到后，再把路径上的证据喂给模型组织语言。

这一步非常关键。因为它把「推理」从纯生成问题，变成了「结构检索 + 受约束生成」。

多跳导航

图结构天然支持多跳。

从一个节点出发，系统可以做一跳邻域扩展、两跳路径发现、带类型约束的遍历、带时间过滤的路径搜索。很多复杂问题，其实本质上就是图上的 constrained traversal。

做过故障分析、供应链穿透、组织权限审计的人都知道，真实问题往往不是「找到相似文本」，而是「沿着几类特定关系往外走，直到找到证据链」。

GraphRAG 在这里的优势很直接：它给系统一张路网，而不是一堆散落纸片。

可解释性

只要答案建立在路径之上，归因就容易很多。

传统 RAG 的可解释通常是「我引用了这几段文本」。这不够，因为用户看不出这些片段之间为什么能导出结论。

GraphRAG 则可以给出：

• 命中的核心实体
• 扩展的关系类型
• 经过的中间节点
• 命中路径对应的来源文档
• 时间和版本约束

对于金融、医疗、法务、审计这类场景，是准入门槛。没有路径级证据，系统很难真正进入业务闭环。

异构融合

企业知识天生异构。数据库里有结构化字段，文档里有叙事描述，日志里有事件序列，报表里有指标快照，外部网页里有补充事实。

知识图谱很适合做这一层统一承载。节点和边上可以挂：

• 来源
• 时间戳
• 置信度
• 版本号
• 原文锚点
• 权限标签

这样，后面的 Agent 就不需要分别理解十几种数据形态，它只需要围绕图这个统一语义层工作。

幻觉压制

有人说 GraphRAG 「能消灭幻觉」。做工程的人都知道，不存在这种好事。

更准确地说，GraphRAG 能明显降低两类幻觉：

• 检索证据不足导致的瞎补全
• 实体关系错配导致的错误推断

图结构把推理空间收窄了。其本质上是一个针对知识的 harness 工程。模型不是面对无边界文本海洋自由发挥，而是在一个有限子图上做组织和归纳。再加上路径归因、时间约束、来源过滤，错误空间会被进一步压缩。

架构重构

GraphRAG 要真正落地，分为三段：建图、检索、生成。

建图阶段

图谱质量决定了 GraphRAG 的上限，建图成本决定了它的下限。

如果图是脏的、歧义的、缺时间边界的，后面做再多检索优化都只是补洞。

实体抽取

最基础的是从文本中抽实体、属性、关系。

早期很多方案喜欢直接让 LLM 通读文档抽三元组。这么做效果可以有，但成本极高，而且稳定性不够。文档一长、格式一乱、术语一偏，大模型就开始漂。

建议：实体抽取和关系抽取要拆开看，不要一把梭。

实体层往往更适合用稳定的 IE 管线或者轻量模型先打底，再让 LLM 做补充和歧义修正。原因：

• 实体是高频基础设施，规模大
• 实体错一个，影响整片图
• 实体任务相对更规则，适合工程化优化

尤其在垂直领域，术语标准化比抽取本身更难。医疗、金融、制造、运维，每个领域都有自己的缩写、版本命名、内部代号。这里如果没有术语表和字典体系，后面图融合基本没法看。

关系抽取

关系抽取是建图里最贵、最脆弱的一层。

关系比实体更依赖上下文。它牵涉事件角色、动作方向、时间条件、否定表达、范围限定。比如：

• 「计划收购」
• 「已完成收购」
• 「传闻收购」
• 「终止收购」

如果你都抽成同一种边，图就废了。

所以关系抽取不能只问「有没有关系」，还要问：

• 关系类型是什么
• 方向是什么
• 是否已生效
• 时间区间是什么
• 证据来源在哪里
• 置信度多少

不建议一上来就追求极全的关系本体。项目初期，关系类型设计得太花哨，抽取和维护成本会迅速失控。更稳一些的做法是围绕业务问题反推关系集合，先保核心链路通。

实体对齐

这是最容易被低估的坑。

同一个实体可能有：

• 全称
• 简称
• 英文名
• 别名
• 历史名称
• 内部代号
• 不同系统中的主键

如果没有实体对齐，图上会出现大量看似不同、实际相同的节点。结果是路径断裂、统计失真、召回稀释。

实体对齐需要多种信号联合：

• 名称相似度
• 类型一致性
• 属性重合度
• 上下游关系重合度
• 来源可信度
• 时间重叠情况

仅靠名称相似度会出很多事故。尤其在中文企业环境里，简称重复极多。我见过一个项目把两个不同区域的同名子公司合并成一个节点，导致后面整条供应链分析全错。

时间与版本

这部分如果不做，GraphRAG 只是比 RAG 多了一层图壳。

建议节点和边都尽量具备时间语义，至少要能表达：

• 创建时间
• 生效时间
• 失效时间
• 采集时间
• 数据版本

这样系统才能回答历史状态问题。比如：

• 「2021 年时它是否还是子公司」
• 「这个接口在 3 月版本里是否存在」
• 「某规则在事故发生当日是否已生效」

如果没有时间建模，系统只会返回一个「混合当前状态和历史状态」的伪答案。

质量控制

建图不是 ETL 一次跑完就结束。它需要持续质控。

至少要有几层控制：

• 抽取置信度阈值
• 本体约束校验
• 规则冲突检测
• 抽样人工复核
• 高风险实体白名单校正

比如，公司类型节点不该挂「毕业院校」属性；人员节点不该作为「机房设备」的父实体；时间区间不能出现失效时间早于生效时间。

这些校验就是 harness 工程。

检索阶段

GraphRAG 的检索不是去图库里「搜一下」这么简单。真正有效的检索，至少是一个分层过程。

第一步：实体定位

用户问题进来，先要知道问的是谁、什么对象、哪个版本、哪个时间点。

这一步常见做法是实体链接，必要时混合向量召回。目标是在图里找到核心节点。

这里有两个坑特别常见。

一个是用户表达不规范。简称、口语、错别字、历史名称都可能出现。
另一个是问题里实体不止一个，而且主次关系不清。

所以实体定位通常需要结合：

• NER
• 别名字典
• 向量相似召回
• 类型约束
• 上下文消歧

如果这一步错了，后面全错。

第二步：子图扩展

定位到核心节点后，要决定往外扩多少。

这一步不能粗暴按 N 跳展开。图一旦大起来，邻域爆炸是很快的。尤其企业图谱里很多「高连接度节点」会把子图迅速拉成垃圾堆。

建议的做法是带约束扩展：

• 限关系类型
• 限最大跳数
• 限时间区间
• 限置信度
• 限来源可信等级
• 限节点类型

比如查询收购链路，就优先沿「收购」「母公司」「投资」这类关系走，而不是把「合作」「提及」「共现」都混进来。

第三步：路径发现

复杂问题很多时候不只是看邻居，而是找满足条件的路径。

比如：

• 从 A 出发，找到其收购方，再找到收购方母公司，再找到该母公司在某年的主要投资对象
• 找到某故障对应组件，再向上找到依赖链，再找变更记录，再对齐时间窗口内的容量调整

这类问题，本质上就是受约束路径搜索。图数据库和图算法在这里比纯向量库更像工具。

但有个问题：路径一多，候选会急剧增加。这个时候不能一股脑全喂给模型。要做路径评分和裁剪。

常见评分信号包括：

• 路径长度
• 关系类型优先级
• 时间匹配度
• 节点权威性
• 来源可信度
• 历史问答反馈

第四步：证据序列化

图拿到了，不能直接丢给模型。大多数模型并不擅长原生理解复杂图结构。

要把子图变成模型好消化的证据形式。常见有两种：

• 路径序列化
• 子图摘要

路径序列化适合事实问答。
子图摘要适合全局分析和开放问题。

实际工程里，更推荐结构化证据和原文片段联合输入。因为图给的是骨架，文本给的是细节。只有骨架，没有细节，答案会很硬；只有文本，没有骨架，答案会发散。

生成阶段

GraphRAG 不是检索完就结束。很多项目到这一步依然翻车，因为 Prompt 设计和输出约束没做好。

证据优先

Prompt 里必须明确要求模型优先依据图证据回答，不足时才引用文本补充，证据冲突时按来源等级和时间规则处理。

如果不写这些约束，模型还是会习惯性按语言流畅性组织答案，最后把未经验证的补全混进去。

路径归因

对于高事实性场景，建议回答里至少保留轻量级路径说明。未必要全部展示给用户，但系统内部必须保留。

比如答案背后至少知道：

• 起点实体
• 中间关系
• 终点实体
• 每一步证据来源
• 时间过滤条件

有了这层，后面才能做审计、回放、纠错、反馈学习。

模板化输出

在财务、医疗、法务、运维这些高风险领域，自由生成要尽量少。

更稳的方式是字段化输出，例如：

• 结论
• 证据路径
• 证据来源
• 时间范围
• 置信度
• 不确定点

这样做的缺点是可读性略硬，优点是稳定。企业系统最终是要接流程、接审批、接工单、接风控策略的，格式稳定比文采重要得多。

三类路线

GraphRAG 现在大体有三条实现路线。可以工程投入和适用边界来看：

知识驱动

这一类把图谱作为主检索引擎。问题进来后，系统尽量转成图查询、路径搜索或者约束遍历，文本只做辅助。

这条路线适合：

• 实体和关系相对清晰
• 业务规则稳定
• 可解释性要求高
• 多跳推理占比高

典型场景像金融股权穿透、资产关系分析、故障因果链、药物禁忌关系、组织权限依赖。

优点：精度高、证据链清晰、推理路径稳定。

缺点：图谱不全时脆弱，对建图质量依赖极大。

如果你手里只有一堆杂乱文档，图谱覆盖率还没起来，就直接 all in 知识驱动，项目容易陷进「图不够用，文本又没保留好」的尴尬局面。

索引驱动

这一类不强调图上直接推理，而是把图结构转成索引增强信号。

比如：

• 给 chunk 挂上关联实体、关系标签
• 把子图摘要拼进 chunk 再做向量化
• 用邻居关系信息做 rerank 特征

这条路线改造成本低，适合已有 RAG 系统做增强。很多团队第一阶段其实更适合走这条，而不是直接重做知识底座。

缺点也很实在：图只是辅助特征，没有成为真正的推理空间。所以多跳能力提升有限，可解释性也一般。

混合路线

现在真正跑得稳的，大多是混合型。

简单讲就是双路甚至多路召回：

• 一路走图
• 一路走向量
• 必要时再接关键词或结构化库查询
• 最后统一重排、裁剪、融合

这条路线最像真实世界。因为企业问题本来就不是纯图问题，也不是纯文本问题。很多时候用户一半在问事实链路，一半在问叙事背景。只用一种召回方式，效果往往不稳。

混合路线的问题在于系统复杂度高。链路变长之后，监控、调参、缓存、权限控制、延迟预算都更难。可它依然是现在最主流、也最靠谱的方案。

轻量建图

微软把 GraphRAG 带火，但慢慢大家发现了一个问题：原版重度 GraphRAG 太贵。

用 LLM 通读全量文档，逐段抽实体、关系、摘要，这种方案到真实数据规模经常直接失控。于是轻量化建图开始流行。

实体图思路

轻量路线的核心变化是：不再执着于完整关系抽取，而是先把实体和文档块稳定连起来。

也就是说，先建一个实体图，或者说 relation-light graph：

• 节点是实体、文档、chunk
• 边主要表达提及、共现、引用、归属、锚定等轻关系
• 更复杂的关系留给后续局部推理或按需补抽

高质量关系抽取太贵、太慢、太脆。那就先把高确定性的部分做出来，把知识骨架做起来。

很多场景下，这么做反而更稳。因为实体图能显著改善召回导航，成本又远低于全量三元组图谱。

成本变化

轻量建图通常能把两个指标打下来：

• Token 消耗
• 图谱更新时间

这对中小项目非常关键。一个知识引擎如果更新周期是按天甚至按周算，它对 Agent 的支撑就已经很有限了。现实里的知识是流动的，尤其在运维、客服、风控、投研这些场景，更新速度直接决定答案可信度。

局限

轻量图省成本，但也有边界。

它更适合做「导航增强」和「局部上下文组织」，不适合承担强逻辑推理的全部职责。因为如果关系层太弱，系统最终还是要回文本里做大量补推断。

所以我们一般把轻量图看成一个很好的过渡层，或者作为混合架构中的图底座。

Agent 化检索

GraphRAG 这两年另一个明显趋势，是从固定流水线走向 Agent 化。

传统流程大多是：

用户提问 → 定位实体 → 扩子图 → 生成答案

问题是，复杂问题往往一轮检索拿不全证据。系统需要边查边判断：现在的证据够不够？应该沿哪类边继续走？有没有必要换一个切入实体？要不要回文档补背景？

这时候，GraphRAG 和 Agent 很自然就结合起来了。

查询拆解

复杂问题先拆成子问题，是 Agent 化 GraphRAG 的第一步。

比如：

「2019 年收购 A 公司的企业，其母公司在 2021 年的主要投资对象是谁？」

可以拆成：

1. 谁在 2019 年收购了 A
2. 该收购方的母公司是谁
3. 该母公司在 2021 年的主要投资对象有哪些
4. 哪个对象符合「主要投资对象」定义

拆解后的每一步都更适合图查询和约束检索。

迭代探索

Agent 可以根据中间结果决定下一步动作：

• 命中实体不确定，先做消歧
• 路径证据不足，扩大时间窗口
• 图证据不全，补文本检索
• 文本冲突，回图里查来源优先级

这比一条固定链路强很多。因为真实问题不会永远按设计者预想的路径走。

风险

Agent 化一听就很高级，但工程上有几个明显的问题：

• 延迟增加
• token 消耗增加
• 调试复杂度上升
• 失败路径变多

如果没有严密的步骤预算和停止条件，Agent 会在图里越走越远，最后拖垮时延和成本。

所以 Agent 化 GraphRAG 要有明确的控制策略：

• 最大迭代轮数
• 最大扩展跳数
• 最大证据数
• 最大 token 预算
• 终止阈值

没有这些约束，系统会变成一个会自主发散的检索器。

强化学习

2025 到 2026 年，另一个值得关注的方向是把强化学习或者类似 reward-guided 策略引进图检索过程。

这个方向的核心问题是：子图应该扩到哪里停？哪条边值得继续走？

以前这类问题多靠规则和启发式。比如限制两跳、限制 topN 邻居、按关系优先级排序。够用，但不够细。

强化学习的吸引力在于，它试图让检索器学会一件事：在有限上下文预算下，优先收集对答案最有价值的证据。

为什么有价值

GraphRAG 很容易出现一个悖论：

• 扩得太少，证据不够，答不出来
• 扩得太多，噪声暴涨，模型反而更容易错

最优点其实是一个动态平衡，而且和问题类型、图谱密度、时间约束都相关。静态规则很难适配所有情况。

落地现实

这个方向我认为在部分场景是一个比较不错的解。

原因很简单。强化学习提升的是「策略细节」，前提是你的图已经比较干净，检索反馈链路也能闭合。如果底层图谱质量一般，奖励模型再聪明也学不到稳定策略。

所以在工程优先级上，我会把它排在：

1. 实体对齐
2. 时间建模
3. 混合召回
4. 路径裁剪
5. 再考虑 RL 优化

很多团队喜欢直接追最新论文方向，结果底座没打稳，投入产出很差。

动态建图

静态全量图谱还有一个问题：更新慢。

数据一旦高频变化，整库重建非常重，增量融合也复杂。于是最近很实用的一条路是查询驱动的动态局部建图。

思路

先用向量检索或关键词检索，快速圈出和问题强相关的一小批文档或 chunk。然后只针对这部分数据，在内存里临时构建一个局部图，用来做当前问题的推理。

这样做的好处很明显：

• 不需要维护一个永远完整的全局大图
• 对高频更新数据更友好
• 构建成本和时延更可控
• 对冷门知识不用提前付建图成本

适用场景

这条路线特别适合：

• 数据更新快
• 查询分布长尾
• 很多知识只会被偶尔问到
• 无法接受全量图谱重构成本

比如运维告警分析、实时舆情、工单流、交易异常调查。

局限

动态建图的问题也很明显：它的全局视角弱。

如果问题本身需要跨全库的大结构理解，比如全局主题分布、长期模式汇总、跨社区关联，局部动态图就不够用了。所以它更像实时推理层，不是全局知识层的完全替代品。

多模态图

GraphRAG 继续演进，节点已经不再局限于文本实体。

很多真实场景里，关键证据来自图像、图表、表格、时序信号。把这些都挂进图里，才可能支撑更完整的 Agent 推理。

例如医疗场景里：

• 症状描述是文本节点
• 检查指标是结构化节点
• 影像特征是图像节点
• 治疗方案是流程节点

如果这些数据还分散在不同系统里，Agent 再强也只能在局部瞎猜。多模态图的价值，在于把这些证据接成可遍历的语义网络。

不过这块别急着神化。多模态 GraphRAG 落地难度明显高于文本图谱，主要难点有三类：

• 跨模态对齐难
• 证据置信度难统一
• 存储与检索链路更复杂

所以大多数团队短期内更现实的做法，是先把表格和结构化字段接进来，再逐步引入图像等模态。

超图方向

传统的知识图谱仅支持二元关系（即一条边连接两个节点，如 实体A → 关系 → 实体B）。然而在真实复杂场景中，事实往往是多维度的。

比如：

• 三家公司共同参与某项目
• 一笔交易涉及买方、卖方、标的、通道、时间、地区
• 一个法律案件涉及原告、被告、法条、法院、时间节点

• 超图与超边（Hypergraph & Hyperedges）：超图允许单条“超边”连接任意数量的实体/节点。例如在医学场景中，描述“某症状”的发生可能涉及“患者、医生、检查手段、特定药物和治疗结果”。
• 低阶与高阶关联：通过超图，系统能同时无损存储成对的“低阶关联”与包含多个实体的“高阶关联”，从根本上减少信息压缩带来的损失。

这个方向在金融穿透、案件分析、复杂项目协作里很有吸引力。因为它能更自然地表达群体事件和多方关系。

但说实话，超图现在离大规模工程标配还有距离。核心原因不是理念不对，而是生态、工具链、调试经验都还不够成熟。一般团队现在没必要急着上，除非业务场景确实被二元关系表达卡住了。

落地取舍

那么 团队到底该怎么选？

只做传统 RAG 就够的情况

如果你的问题大多是：

• 单文档问答
• FAQ 查询
• 产品知识助手
• 代码片段召回
• 对多跳推理要求不高

那就别急着上图。把 chunk、embedding、rerank、query rewrite、metadata filter、citation 做好，收益通常更高。

应该上轻量 GraphRAG 的情况

如果已经出现这些信号：

• 同一个问题答案分散在多个文档
• 实体名称混乱、简称多
• 用户经常追问上下游关系
• 向量召回结果看起来相关，答案却老是不对
• 需要更稳定的引用与归因

那我建议先上轻量图。先做实体层和文档锚定层，不要一口气建满关系宇宙。

应该上重度 GraphRAG 的情况

如果业务本身就是关系驱动的：

• 金融穿透
• 医疗知识网络
• 风控依赖链
• 故障根因传播
• 供应链关联追踪
• 组织权限审计

那重度图谱是值得的。因为这里的问题本质上就是图问题，用纯文本方案长期只能堆补丁。

Agent 化和 RL 什么时候考虑

当且仅当你已经满足这些条件时再往上走：

• 图谱基础质量稳定
• 问题复杂度确实需要多轮探索
• 现有检索链路可观测、可回放
• 成本和延迟预算允许

否则，先把基础检索做好，比上复杂策略更值。

小结

图结构是检索的 harness 工程。

向量检索还是底座，图结构正在变成高阶能力的分水岭。

没有向量，系统对模糊语义和开放文本会很迟钝。
没有图，系统对关系、路径、时间、一致性会很脆弱。

未来成熟的 Agent 知识引擎，大概率都不是单一路线，而是分层组合：

• 向量层负责广覆盖召回
• 图层负责关系组织与多跳导航
• 结构化查询层负责精确过滤
• Agent 层负责查询拆解与迭代探索
• 生成层负责受约束表达与归因输出

说到底，知识引擎这件事，已经从「找资料」变成「构造可推理的证据空间」。

GraphRAG 不是给 RAG 多加一个数据库，也不是给模型多喂一点上下文。它把原来松散、偶然、靠模型自行拼接的知识，重组成了一张可以遍历、可以约束、可以回放的网络。

对 AI Agent 来说，对于 AI Agent 的上下文构建来说，这是关键的一步。

因为 Agent 一旦开始承担任务，它需要的就不再是几个看起来相关的文本块，而是一条能走通、能解释、能复核的知识路径。

以上。