RAG的工程选型正在从“要不要用”变成“用哪一种”。公开资料中已明确出现传统RAG、Graph RAG与Agentic RAG三种形态，但三者在检索、生成、推理与决策链条上的差异，直接决定了它们适合什么场景、不适合什么场景。本文不做泛概念综述，只围绕工程选型展开。

三种形态的链条差异

传统RAG的链条最短：索引、检索、生成三阶段。资料指出其核心问题是检索数据质量不足、模型选择不当，导致回答准确性和可追溯性受限。它的决策逻辑是“一次检索、一次生成”，没有中间推理环节，也没有对检索结果做二次判断的能力。

Graph RAG在检索阶段引入图结构。资料将其列为RAG未来方向之一，与多模态RAG、个性化RAG并列，并指出该方向面临挑战和待解决问题。从工程视角看，Graph RAG的差异在于：检索单元从文本块扩展到实体与关系，生成阶段需要把图路径转化为自然语言上下文。这增加了知识库构建成本，但为多跳推理和关系型问答提供了结构支撑。

Agentic RAG的链条最长。资料描述其关键创新是让RAG从静态流程变为具有理解、推理、决策能力的系统，引入AI Agent的四种核心模式，并涉及不同系统类型与工具生态。这意味着检索不再是单次动作，而是由Agent根据任务状态决定是否检索、检索什么、是否调用工具、是否重新规划。

选型判断表

工程选型应优先看三个维度：查询复杂度、知识结构、可接受的延迟与成本。

传统RAG适合：查询以事实型问答为主，知识以非结构化文本为主，对延迟敏感且预算有限。资料中提到的企业客服、工厂质检等场景，若问题边界清晰，传统RAG加检索优化即可覆盖。

Graph RAG适合：查询涉及实体关系、多跳推理或需要可追溯的推理路径。资料提到Graph RAG是未来方向之一，但同时也指出存在挑战和待解决问题。工程上应把它视为“知识结构升级”选项，而非默认替代方案。

Agentic RAG适合：任务需要多步决策、工具调用或动态规划。资料中Agentic RAG的系统类型和工具生态表明，它解决的是“静态RAG无法根据中间结果调整策略”的问题。代价是架构复杂度、延迟和调试难度显著上升。

演进路径与边界

从传统RAG向复杂形态演进，建议分三步走。第一步，先把传统RAG的检索质量和语料治理做扎实，资料明确指出检索数据质量不足是传统RAG的核心缺点之一。第二步，当查询开始涉及关系推理时，评估Graph RAG的图构建与维护成本。第三步，当任务需要多步决策和工具调用时，再引入Agentic RAG。

需要警惕的边界：Graph RAG的图构建和维护成本可能超过收益，尤其是知识更新频繁的场景；Agentic RAG的决策链条越长，失败模式越难定位，资料中提到的工具生态也意味着外部依赖风险。选型不是选“最先进”，而是选“链条长度与任务复杂度匹配”的方案。

资料中RAG五代演化历程和四大模式对比表明，形态演进是连续的，但工程落地可以跳跃。关键是先明确当前任务的检索、推理、决策需求，再决定用哪一段链条。