从"检索员"到"问题解决者"：AgentRAG正在重新定义企

一、企业RAG的真实困境：检索到了，但没用

过去一年，RAG（检索增强生成）几乎成了企业AI落地的标配。任何一家做AI转型的公司，第一件事就是搭知识库——把文档灌进去，让大模型能检索企业自己的数据。

这个思路本身没问题。但走到落地阶段，问题来了。

检索到的内容，经常不是用户真正需要的。

举个典型场景：某制造企业搭建了RAG知识库，技术员问"产线A的SOP变更流程是什么"。传统RAG的做法是：在向量库中检索与"SOP""变更流程"相关的文档片段，拼接到prompt中，让大模型生成回答。

结果呢？系统返回了一段SOP文档原文的改写。技术员真正想知道的是"我这台设备需要走哪几个审批节点、找谁签字、周期多长"，但RAG给的是一整页通用流程描述。

这不是RAG检索错了——它确实找到了最相关的文档片段。问题是，单次检索无法覆盖多步骤、跨文档的复杂问题。传统RAG本质上是"检索员"，你问一个问题，它帮你找一段资料。但如果你的问题需要推理、需要组合多个信息源、需要经过几步判断才能得出答案，传统RAG就力不从心了。

这正是AgentRAG要解决的问题。

二、AgentRAG的核心逻辑：给RAG装上推理引擎

如果说传统RAG是一个"只管找资料"的检索员，那AgentRAG就是一个"先想清楚要找什么、再动手去找、找到还不对就换方向继续找"的问题解决者。

这两者的区别不在模型能力上，而在执行逻辑上。

AgentRAG的核心框架是ReAct推理链（Reasoning + Acting），它让AI的每一次检索不再是孤立的"一问一答"，而是一个有目标的、可迭代的推理过程。

具体来说，一条完整的AgentRAG推理链包含五个步骤：

1. 第一步：查询分析——理解用户真正在问什么 当用户问"产线A的SOP变更流程"时，AgentRAG不会立刻去检索。它先分析这个查询的意图：这是一个流程类问题，涉及审批节点、责任人、时间周期三个维度。因此需要的信息不是一段文档，而是一个结构化的流程链路。
2. 第二步：执行规划——制定检索策略 基于查询分析的结果，AgentRAG会规划检索路径：先查SOP管理制度文档，确定变更的基本流程框架；再查产线A的设备档案，确定设备类型对应的特殊审批要求；最后查最近的变更记录，确认实际执行中的常见处理方式。
3. 第三步：工具调度——按需调用检索工具 传统RAG一次检索就完事，AgentRAG会按规划依次检索，并根据每一步的结果决定下一步行动。如果第一步检索发现产线A属于特种设备类别，它会动态调整后续检索方向，加入特种设备审批的相关文档。
4. 第四步：迭代推理——根据中间结果修正方向 这是AgentRAG和传统RAG最大的区别。如果某一步检索结果不足以支撑回答，AgentRAG不会硬拼一段文本交差，而是回到规划阶段重新分析——"我需要的信息还缺什么？应该从哪里补？"。这个循环会持续直到它有足够的证据生成一个可靠回答。
5. 第五步：最终生成——基于完整推理链路输出答案 最终生成的不是一段文档摘要，而是一个经过推理验证的结构化回答："产线A的SOP变更需要经过3个审批节点（班组长→车间主任→品质部），整体周期3-5个工作日。因该产线涉及特种设备，需额外经过安全部会签。最近一次变更（2026年3月）实际耗时4天。" 这个回答的每一步都有检索依据，用户可以看到AI是怎么一步步得出结论的。

三、步骤可视化：让推理过程不再"黑盒"

AgentRAG的推理能力很强，但如果用户看到的只是"思考中…"然后蹦出一个答案，体验其实不如传统RAG——至少传统RAG还能显示引用了哪段文档。

所以执行步骤的可视化是AgentRAG落地的关键一环。

目前我们在JBoltAI V4.3中实现了一个叫chat-step-progress的组件。它的作用很简单：把AgentRAG的ReAct推理链路，实时展示在对话界面上。

用户看到的效果是这样的：

• 正在分析您的问题...
• 已识别为流程类查询，需要检索3类信息源
• 正在检索：SOP管理制度文档（1/3）
• 正在检索：产线A设备档案（2/3）
• 正在检索：近期变更记录（3/3）
• 发现产线A属于特种设备类别，补充检索安全审批要求
• 正在整合4个检索结果...
• 回答生成完成

每一步都是透明的。用户不仅能看到最终答案，还能看到AI是怎么思考的、检索了哪些信息、为什么要补充检索。对于企业场景来说，这种可追溯性不是体验问题，是信任问题——企业用户需要知道AI的结论是怎么来的，才敢用它辅助决策。

四、从"被动检索"到"主动推理"：为什么这是分水岭

站在企业AI应用的角度，AgentRAG代表的其实是一个根本性的范式转变：

传统RAG是"被动"的——它等着用户提问，然后尽力去找最相关的资料。用户问得好，它答得好；用户问得模糊，它也只能模糊地答。

AgentRAG是"主动"的——它会对用户的问题进行二次加工，理解背后真正的需求，然后主动规划检索路径。用户不需要知道该问什么、不需要一次把所有条件说清楚，AgentRAG会通过推理帮你补全信息需求。

这个区别在简单的问答场景里不太明显，但在企业级应用中差距巨大。企业的知识库不是百科全书——信息分散在不同系统、不同部门、不同格式的文档里，很多问题的答案需要跨文档、跨系统推理才能拼出来。

从"被动检索"到"主动推理"，RAG从工具变成了能力。它不再是"帮你找资料"的系统，而是"帮你解决问题"的系统。

五、落地建议：企业如何判断自己需不需要AgentRAG

不是所有企业都需要AgentRAG。如果你的知识库主要用来回答FAQ类的简单问题——比如"年假有几天""报销流程是什么"——传统RAG完全够用，AgentRAG反而增加了不必要的复杂度。

但如果你的场景符合以下任何一个特征，建议认真考虑AgentRAG：

1. 答案需要跨多个信息源组合：比如"这个订单延迟交付，涉及的物料缺了哪些、供应商最近一次报价是多少、有没有替代料"——这种问题需要同时检索ERP、采购系统、物料数据库，传统RAG做不到。
2. 问答涉及推理和判断：比如"这台设备最近频繁报警，可能的原因是什么"——需要检索设备历史数据、维修记录、同类设备的故障模式，然后做因果推理。
3. 用户的问题经常是模糊的：一线操作人员很难用精确的检索词描述问题，AgentRAG的查询分析和意图理解能力可以弥补这个gap。
4. 回答需要可追溯：在制造、金融、政务等行业，AI的每个结论都需要有依据。AgentRAG的步骤可视化天然支持这一点。

从我们的实践来看，AgentRAG真正发挥价值的场景，恰恰是传统RAG落地后用户抱怨"答案不太对"的那些场景。它不是传统RAG的替代，而是升级——当你发现检索增强"增强"得还不够的时候，AgentRAG就是下一步。