如果现在对于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 年的主要投资对象是谁？」
可以拆成：
-
谁在 2019 年收购了 A -
该收购方的母公司是谁 -
该母公司在 2021 年的主要投资对象有哪些 -
哪个对象符合「主要投资对象」定义
拆解后的每一步都更适合图查询和约束检索。
迭代探索
Agent 可以根据中间结果决定下一步动作：
-
命中实体不确定，先做消歧 -
路径证据不足，扩大时间窗口 -
图证据不全，补文本检索 -
文本冲突，回图里查来源优先级
这比一条固定链路强很多。因为真实问题不会永远按设计者预想的路径走。
风险
Agent 化一听就很高级，但工程上有几个明显的问题：
-
延迟增加 -
token 消耗增加 -
调试复杂度上升 -
失败路径变多
如果没有严密的步骤预算和停止条件，Agent 会在图里越走越远，最后拖垮时延和成本。
所以 Agent 化 GraphRAG 要有明确的控制策略：
-
最大迭代轮数 -
最大扩展跳数 -
最大证据数 -
最大 token 预算 -
终止阈值
没有这些约束，系统会变成一个会自主发散的检索器。
强化学习
2025 到 2026 年，另一个值得关注的方向是把强化学习或者类似 reward-guided 策略引进图检索过程。
这个方向的核心问题是：子图应该扩到哪里停？哪条边值得继续走？
以前这类问题多靠规则和启发式。比如限制两跳、限制 topN 邻居、按关系优先级排序。够用，但不够细。
强化学习的吸引力在于，它试图让检索器学会一件事：在有限上下文预算下，优先收集对答案最有价值的证据。
为什么有价值
GraphRAG 很容易出现一个悖论：
-
扩得太少，证据不够，答不出来 -
扩得太多，噪声暴涨，模型反而更容易错
最优点其实是一个动态平衡，而且和问题类型、图谱密度、时间约束都相关。静态规则很难适配所有情况。
落地现实
这个方向我认为在部分场景是一个比较不错的解。
原因很简单。强化学习提升的是「策略细节」，前提是你的图已经比较干净，检索反馈链路也能闭合。如果底层图谱质量一般，奖励模型再聪明也学不到稳定策略。
所以在工程优先级上，我会把它排在：
-
实体对齐 -
时间建模 -
混合召回 -
路径裁剪 -
再考虑 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 一旦开始承担任务，它需要的就不再是几个看起来相关的文本块，而是一条能走通、能解释、能复核的知识路径。
以上。