AgentRAG vs 传统RAG：当AI学会"三思而后答"

做过RAG项目的人大概都有过这样的体验：用户问了一个比较复杂的问题，AI的回答要么答非所问，要么只回答了一半。你去看检索日志，发现第一次检索确实没找到太相关的内容，但如果你手动换一个关键词再搜一次，其实能找到很好的资料。

问题出在哪？出在传统RAG是"一锤子买卖"——用户问什么，就搜什么，搜到什么，就答什么。它不会反思自己搜得好不好，也不会主动换个角度再搜一次。

这就是传统RAG和AgentRAG最核心的区别。后者让AI具备了"思考-行动-观察-再思考"的循环能力，更像一个真正会查资料的人。

这篇文章，我们就把这两种RAG方式掰开揉碎了看看到底有什么不同。

一、传统RAG的工作方式

传统RAG的流程可以用一条直线来描述：

用户提问 → 查询改写 → 向量检索 → 拼装Prompt → LLM生成回答

就这么简单。整个流程走一遍，回答就出来了。从工程实现来看，通常是这样的：

第一步：查询改写（可选）

直接拿用户的问题去搜，有时候效果不好。比如用户问"它怎么用？"，这里的"它"指代不明。所以有些系统会做一步查询改写，把"它怎么用？"结合上下文改成"产品X的使用方法"。但这一步通常只是简单的文本处理，不会深度理解用户意图。

第二步：向量检索

拿着改写后的查询，通过Embedding模型转成向量，去向量数据库里搜。搜出来的结果按相似度排序，取Top K条。

第三步：生成回答

把检索到的文档片段和用户问题拼在一起，交给LLM生成回答。

这个流程的优点是快——只检索一次，延迟低，实现简单。缺点也很明显：如果第一次检索没搜到好内容，结果就基本定了。系统没有纠错和补充的机会。

二、AgentRAG的工作方式

AgentRAG引入了ReAct（Reasoning + Acting）推理框架。ReAct的核心思想来自人类解决问题的思维方式：先想清楚要做什么，然后去做，观察结果，根据结果再决定下一步做什么。

用一个生活中的例子来类比：

你要帮朋友找一家适合过生日的餐厅。 传统RAG的做法：直接搜"适合过生日的餐厅"，拿到结果就推荐。 AgentRAG的做法：

1. 先分析朋友的需求——预算多少？多少人？什么口味偏好？
2. 第一次搜索"适合过生日的餐厅"
3. 看看搜索结果——找到了5家，但好像没有特别便宜的
4. 换个角度搜索"经济实惠的生日餐厅"
5. 看看新结果——找到了3家便宜的
6. 综合两次搜索的结果，给出推荐

你看，AgentRAG多了一个"评估-反思-再检索"的环节。

以 JBoltAI 平台的 ReActRagChain 实现为例，AgentRAG 的流程更像一个循环：

用户提问 → 查询分析 → 生成执行计划 → 进入推理循环：
 ├─ 思考：当前信息够不够回答？
 ├─ 选择工具：调用知识库检索 / 数据库查询 / 外部工具
 ├─ 观察结果：评估检索质量
 ├─ 判断：信息充足则结束循环，否则继续下一轮
 └─ 退出循环 → 生成最终回答

三、关键差异逐项对比

3.1 查询分析：简单改写 vs 深度理解

传统RAG的查询分析通常比较简单，可能只是去除一些无意义的语气词，或者结合上下文做一些代词替换。

AgentRAG则做了更深层的分析。在实际工程中，查询分析包含两层：

第一层是规则匹配，零成本，不需要调用LLM。系统内置了一套意图关键词库，能快速识别出十几种意图类型：

• 闲聊（"你好"、"谢谢"）
• 流程查询（"怎么操作"、"如何设置"）
• 对比查询（"A和B有什么区别"）
• 故障排查（"报错了"、"无法连接"）
• 概念定义（"什么是X"）
• 追问（"还有呢"、"具体说说"）
• 等等

如果规则能直接命中，系统连LLM都不用调，直接进入后续流程，省时省钱。

第二层是LLM兜底，当规则无法识别时，调用一次LLM来完成意图识别、查询改写和子查询拆分。注意这里的关键词——一次调用。很多系统会把意图识别和查询改写分成两次LLM调用，但在实际工程中，完全可以在一次调用中同时完成，省一半的开销。

此外，AgentRAG还能识别复合查询。比如用户问"Spring Boot和Spring Cloud有什么区别，分别怎么安装？"这是一个对比查询+两个流程查询的组合。系统会自动把它拆分成多个子查询，在后续的推理循环中分别处理。

3.2 执行计划：无计划 vs 有规划

传统RAG没有"计划"这个概念。用户问什么就搜什么，搜到就回答，搜不到也回答（只不过可能答得不好）。

AgentRAG会根据查询分析的结果，生成一个执行计划。不同类型的查询有不同的计划模板：

• 事实查询：语义检索一次 → 生成回答（预计1轮）
• 对比查询：分别检索各实体 → 对比分析（预计N+1轮，N为实体数量）
• 故障排查：先用关键词定位问题 → 再用语义检索找解决方案 → 验证方案可行性（预计2轮）
• 分析查询：从多个角度检索 → 综合分析（预计4轮）

这个计划不是僵化的，而是作为"建议"指导后续的推理循环。如果第一轮检索结果就很好，LLM可以直接判断信息充足并结束循环；如果结果不理想，循环会继续，直到收集到足够的信息或者达到最大迭代次数。

3.3 检索策略：单次检索 vs 多轮自适应

传统RAG只检索一次。检索策略通常在系统配置时确定（语义检索 or 混合检索），运行时不会改变。

AgentRAG在推理循环中可以多次检索，而且每次检索都可以选择不同的策略和关键词：

• 第一轮用语义检索，发现结果不够精确
• 第二轮切换到关键词检索，找到了包含错误码的FAQ文档
• 第三轮用改写后的查询再搜一次，补充了缺失的信息

在工程实现中，这通过一个"工具注册"机制来实现。系统会把可用的工具（知识库检索、数据库查询、Excel查询、用户自定义函数等）注册到一个工具中心，然后由LLM自主选择在每一轮调用哪个工具。

更重要的是，系统还内置了相似度守卫（Similarity Guard）——如果LLM选的查询关键词和之前已经搜过的太相似，系统会直接拦截并提示"请换用不同的关键词"，避免无效的重复检索。

3.4 结果评估：不评估 vs 多维度评估

传统RAG不做结果评估。检索到什么就用什么。

AgentRAG在每次检索后会进行多维度的质量评估：

• 相关性：检索结果的平均相似度分数
• 覆盖度：检索到的文档数量是否足够
• 多样性：结果是否来自不同的文档（避免所有结果都来自同一篇文档）

评估结果会反馈给LLM，帮助它决定是继续检索还是可以开始回答。比如评估反馈"相关性不足，建议调整查询词义或使用不同的检索策略"，LLM看到这个提示，就会换一个角度重新检索。

3.5 工具扩展：固定流程 vs 动态挂载

传统RAG的处理链路通常是固定的：检索 → 生成回答。如果你想加入数据库查询、API调用等能力，需要修改代码重新部署。

AgentRAG通过"工具挂载"机制实现了灵活的能力扩展。用户可以在应用配置中挂载多种数据源：

• 知识库（向量检索）
• 外部数据库（Text2SQL查询）
• Excel表格（自然语言查询）
• 自定义函数（FunctionCall）
• MCP服务（Model Context Protocol）

系统在推理循环开始前，会根据用户的问题自动判断需要激活哪些工具。比如用户问"上个月的销售数据是多少？"，系统会识别到这是一个数据统计类问题，自动激活数据库查询工具。如果用户问"退款流程是什么？"，则只需要知识库检索工具。

这种动态路由的机制，让同一个Agent应用能够处理各种不同类型的问题，而不需要为每种问题类型单独配置一个应用。

3.6 闲聊处理：一视同仁 vs 快速通道

传统RAG通常不区分闲聊和业务问题。用户说"你好"，系统也会老老实实地去知识库搜一遍，浪费资源不说，搜出来的结果可能还很尴尬。

AgentRAG在查询分析阶段就会识别出闲聊意图，然后走一个快速通道——跳过所有的检索和工具调用，直接让LLM友好地回复。这样既省了资源，响应也更快。

3.7 退出机制：搜完就答 vs 自主判断

传统RAG的退出条件很简单——检索完成就生成回答，不管检索质量如何。

AgentRAG有更完善的退出机制：

• LLM主动退出：当LLM判断信息已经充分时，调用finish工具主动结束循环
• 评估通过退出：当累计检索结果达到一定数量且质量达标时
• 最大迭代次数兜底：防止无限循环（默认可配置，比如5轮）
• 总超时兜底：防止某次推理耗时过长（默认5分钟）

值得注意的是，只有LLM主动调用finish才是"正常退出"。评估通过只是意味着"通常情况下信息已经够了"，但LLM仍然可以选择继续检索。这种设计给了LLM更大的自主权，避免了过早退出导致回答质量不佳。

四、两种RAG的适用场景

说了这么多差异，那到底该选哪种？

传统RAG适合的场景：

• 问题类型比较单一、明确（比如FAQ问答）
• 对响应速度要求极高
• 知识库内容质量高、覆盖全面，一次检索就能命中
• 用户群体主要是内部员工，提问方式比较规范

AgentRAG适合的场景：

• 问题类型复杂多样（既有事实查询，又有流程指导，还有故障排查）
• 对回答质量要求高于对响应速度的要求
• 知识库内容庞大但分散，需要多次检索才能找到完整答案
• 用户群体不固定，提问方式千奇百怪
• 需要同时查询知识库和外部数据源

在实际落地中，两者的选择并不是非此即彼。JBoltAI 平台就同时提供了两种应用类型——"智能问答"走传统RAG快速通道，"AgentRAG智能问答"走多轮推理深度链路，用户创建应用时根据场景选择即可。这种分级处理的思路，在保证响应速度的同时，也不会牺牲复杂问题的回答质量。

五、工程实现中的一些取舍

从开发者的角度来看，AgentRAG的复杂度明显高于传统RAG：

1. LLM调用次数更多：查询分析可能调一次，每轮推理都要调一次，最后生成答案还要调一次。成本和延迟都会增加。
2. 状态管理更复杂：传统RAG是无状态的，每次请求独立处理。AgentRAG需要维护推理循环的状态——当前是第几轮、已经搜了什么、收集了哪些结果、上一轮的结论是什么。
3. 3. 并发安全：多个用户同时使用AgentRAG时，工具注册和注销需要引用计数机制，防止一个用户的操作影响到另一个用户。
4. 4. 可观测性：传统RAG的链路简单，排查问题容易。AgentRAG的多轮循环中，任何一步都可能出现异常，需要完善的日志和进度追踪机制。

但这些复杂度的增加是值得的。从效果上看，AgentRAG在复杂问题上的表现明显优于传统RAG——它能找到更全面的信息，给出更准确的回答，还能处理传统RAG根本无法处理的跨数据源问题。

写在最后

传统RAG和AgentRAG并不是替代关系，而是互补关系。传统RAG解决了"从0到1"的问题——让AI能够基于知识库回答问题；AgentRAG解决了"从1到10"的问题——让AI能够像人一样思考和分析，给出更高质量的回答。

随着LLM能力的不断提升和推理成本的持续下降，AgentRAG的应用门槛会越来越低，适用场景也会越来越广。但对于大多数刚刚开始建设知识库的企业来说，从传统RAG起步，逐步积累经验和数据，再根据需要升级到AgentRAG，可能是更务实的选择。毕竟，最好的架构不是最先进的架构，而是最适合当前阶段的架构。