Agentic RAG：RAG为什么一步一步长出了Agent能力？

前面我们已经讲过为什么大模型需要 RAG，也拆过传统 RAG 的完整链路：用户提问，系统检索文档，拼进上下文，再让模型生成答案。

这套流程处理“退款政策是什么”没什么问题。

但问题一复杂，比如：

对比新旧两版退款政策，找出华东区的例外条款，再说明这些变化会影响哪些历史订单。

一次检索就开始吃力了。

它要查多个问题、多个版本、多个数据源，还要判断证据够不够。第一次没找到，不能硬着头皮往下答，得换个问法继续找。

传统 RAG 把检索写死在流程里，Agentic RAG 则把检索变成 Agent 可以按需使用、反复使用的工具。

先把定义说清楚：Agentic RAG 不是某一个固定算法，也不是某个框架的专属功能，而是一类架构模式。

在这类系统里，大模型不只负责最后写答案，还参与决定：要不要检索、问题怎么拆、查哪个数据源、检索结果是否可用、要不要换个 Query 再查，以及什么时候可以停止。

一、先别急着上 Agent，看看 RAG 是怎么走到这一步的

这段演进不是官方规定的版本号，而是一条很典型的工程演进逻辑。

每往前走一步，都是因为上一步解决不了新的问题。

第一阶段：传统 RAG，把外部知识拿给模型看

2020 年的 RAG 论文把模型参数里的“参数化知识”和外部索引里的“非参数化知识”结合起来。

到了工程里，大家通常把它实现成一条固定在线链路：

Query → 检索 Top-K → 拼接 Context → LLM 生成。

它解决了大模型不知道私有数据、知识更新慢、答案无法溯源的问题。

但这条链路有一个隐含假设：用户的一句话已经足够适合检索，而且第一次返回的 Top-K 就包含答案。

现实里，这个假设经常不成立。

第二阶段：Advanced RAG，把每一环做得更精细

于是系统开始增加 Query 改写、Multi-Query、混合检索、Rerank、父子块检索、Context 压缩。

这些方法在RAG 优化文章里已经详细讲过。它们非常有用：检索召回更高了，送给模型的上下文也更干净了。

但要看清它的边界：流水线变强了，流水线本身仍然是固定的。

开发者提前规定每个请求都改写三次、查两个索引、做一次 Rerank。即使一个简单问题根本不需要检索，它也照跑；即使复杂问题一次没查全，它通常也不会自己增加下一轮。

第三阶段：自适应与纠错，让系统开始“看结果再决定”

接下来出现了一批很关键的思路：

• Self-RAG：按需检索，并对检索内容和生成结果进行反思
• CRAG：先评估检索结果，结果不可靠时触发纠正动作
• Adaptive-RAG：根据问题复杂度，在不检索、单步检索和多步检索之间选择

它们的实现并不相同，也不能全部简单等同于 Agentic RAG。

但它们推动了同一个变化：检索不再是必走一次的固定步骤，而是一个可以判断、评估和纠错的过程。

第四阶段：Agentic RAG，把检索交给目标驱动的 Agent

有了 Function Calling、ReAct 和 Agent 运行时之后，检索可以被包装成工具。

Agent 接到的不再只是一个待搜索的 Query，而是一个需要完成的目标。它可以先规划，再调用向量库、关键词搜索、数据库、网页搜索等工具，根据中间结果继续调整。

这就是 RAG 从“固定流水线”走到“动态检索循环”的关键一步。

阶段	谁决定检索路径	检索次数	结果不好怎么办
传统 RAG	开发者写死	通常 1 次	带着错误结果继续生成
Advanced RAG	开发者写死更多优化	固定若干次	依赖预设的改写、重排策略
自适应/纠错 RAG	分类器或模型参与判断	0 到多次	评估、改写或补充检索
Agentic RAG	Agent 根据目标和状态决定	动态	换 Query、换工具、补证据或拒答

二、Agentic RAG 到底要解决什么问题？

很多人会说：“我已经加了混合检索和 Rerank，为什么还需要 Agentic RAG？”

因为它们解决的不是同一层问题。

混合检索和 Rerank 解决的是：这一次怎么查得更准。

Agentic RAG 解决的是：这次该不该查、该查几次、查什么、结果不够时下一步怎么办。

1. 一个 Query 装不下复杂问题

“对比两个版本并找出地区例外”至少包含版本检索、差异比较和地区过滤三个子问题。

把整句话直接向量化，可能每个方向都沾一点，但哪个都查不准。Agent 可以先拆成子问题，分别找证据，再合并。

2. 第一次检索错了，固定流程不会自救

传统 RAG 一旦召回了不相关文档，后面的 Rerank、Prompt 和大模型都只能在错误候选集里挣扎。

Agentic RAG 会先评估证据。相关性低、来源冲突或关键字段缺失，就重写 Query、扩大范围、换数据源，或者明确告诉用户证据不足。

3. 不同问题需要不同数据源

政策解释适合查文档库，历史订单要查数据库，刚发生的变化可能要查网页或业务 API。

单一向量库不是企业全部知识。Agent 的价值之一，就是在多个受控工具之间做路由。

4. 不是所有问题都值得检索

用户说“把上一段改得更口语化”，根本不需要查知识库。

如果系统每次都跑 Query 改写、向量检索和 Rerank，只会增加延迟、Token 和费用。Agent 可以判断直接回答，或者走一条更轻的路径。

5. 多跳问题需要带着新线索继续查

第一轮找到“新政策从 7 月生效”，第二轮才知道应该查“7 月之后的订单”，第三轮再核对“华东区例外”。

后一次检索依赖前一次结果，这种多跳问题很难靠一条预先写死的 Query 完成。

三、Agentic RAG 的核心原理

它的底层并不神秘，就是把Agent 的规划、工具、执行和反馈放进 RAG 在线链路。

一个实用的 Agentic RAG，通常有五个角色：

1. 规划与路由：判断任务复杂度，决定直接回答、单次检索还是拆成多步。
2. 检索工具：向量检索、BM25、数据库、网页搜索和业务 API，各自暴露清晰能力。
3. 状态记录：保存子问题、已查来源、候选证据、冲突点、剩余预算。
4. 证据评估：检查相关性、完整性、来源可靠性和相互一致性。
5. 停止与生成：证据足够就组织带引用的回答；证据不足且预算耗尽就拒答或请用户补充信息。

它的运行过程，可以压缩成这个循环：

理解目标
  ↓
决定：直接回答，还是调用检索工具？
  ↓
拆分子问题 → 选择数据源 → 执行检索
  ↓
评估证据：相关吗？完整吗？互相冲突吗？
  ↓
不够：改写 Query / 换工具 / 继续检索
足够：整合证据 / 标注来源 / 生成答案

这就是 ReAct 在检索场景里的落地：模型基于当前状态决定行动，工具返回观察结果，模型再决定下一步。

注意，“反思”不能只靠模型拍脑袋说证据够了。

生产系统通常还要加确定性规则：至少需要几类证据、是否命中指定版本、引用能否回到原文、数值是否来自结构化数据、最大允许几轮、总耗时和费用上限是多少。

Agent 负责动态决策，规则负责兜底。两者缺一不可。

四、用一个例子走完完整过程

假设用户问：

对比 2025 和 2026 两版差旅报销政策，并说明上海分公司的特殊规定。

传统 RAG 往往把整句话检索一次，拿回几段最相似的内容就开始回答。如果召回的全是 2026 版，总结写得再流畅，也没有完成“对比”。

Agentic RAG 会这样处理：

1. 识别出三个证据槽位：2025 总部政策、2026 总部政策、上海分公司补充规定。
2. 为三个槽位分别生成 Query，可以并行检索，减少串行等待。
3. 检查版本号、生效日期、适用组织和来源权限，而不只看向量相似度。
4. 如果缺少 2025 版，就去历史归档库继续查；如果两个来源冲突，就优先核对正式发布记录。
5. 三类证据齐全后再做差异比较，并让每条结论带回原始来源。

你会发现，真正的变化不是“多查了几次”，而是系统知道自己为什么查、还缺什么、什么时候算查完。

五、Agentic RAG 不等于多 Agent

这是一个很容易被带偏的地方。

一个 Agent 配几个检索工具，加上明确的状态机和证据检查，已经是 Agentic RAG。

只有当任务确实存在稳定的职责边界，比如法规检索、财务数据查询和证据审计需要不同权限或不同模型时，才值得拆成多个 Agent。

否则，多 Agent 会带来更多通信、上下文复制、错误传播和调试成本。

先把单 Agent 的检索循环跑稳，再考虑多 Agent。

六、它比传统 RAG 强，但也更难上线

Agentic RAG 不是免费午餐。

维度	传统 RAG	Agentic RAG
路径	固定，容易预测	动态，每次可能不同
延迟	低且稳定	多轮工具调用，波动更大
成本	容易估算	与规划轮数、检索次数相关
调试	看固定链路	要看完整决策轨迹和工具结果
权限	一个检索入口较简单	多数据源需要逐工具鉴权
上限	适合简单、单跳问答	适合复杂、多跳、多源任务

落地时至少要守住六条：

• 限制循环：设置最大步骤、超时、Token 和工具调用预算，防止越查越远。
• 工具要窄：每个工具用途清晰，参数 Schema 和返回值稳定，别做一个“万能搜索”。
• 权限前置：检索必须继承用户权限，不能让 Agent 绕过原系统访问敏感数据。
• 证据可回放：记录每次 Query、命中文档、评分、选择理由和最终引用。
• 失败能降级：Agent 超时或判断不稳时，可以退回固定 RAG、澄清问题或拒答。
• 分层评估：既评估检索是否找全，也评估答案是否忠于证据；还要统计平均步骤、P95 延迟和单次费用。

工具怎么设计，可以继续看Agent 工具设计；指标怎么拆，可以参考RAG 评估和Agent 评估。

七、什么场景值得用 Agentic RAG？

适合它的场景通常有这些特征：

• 问题需要多跳推理，后一步依赖前一步找到的新线索
• 一个请求包含多个子问题，需要拆解后分别检索
• 知识分散在文档库、数据库、网页和业务 API 中
• 对证据完整性、来源引用和冲突处理要求高
• 用户问题模糊，需要先澄清意图或动态调整检索方向

下面这些场景，固定 RAG 往往更划算：

• FAQ、产品手册等简单单跳问答
• 数据源单一，Query 模式稳定，检索命中率已经很高
• 对首字延迟要求严格，无法承受多轮模型和工具调用
• 流程有明确规则，用 Workflow 就能可靠完成

合理的升级顺序应该是：先把传统 RAG 的文档、切片、检索和评估做好，再增加路由与纠错，最后才开放更动态的 Agent 循环。

如果基础召回都做不好，套一层 Agent 只会让系统用更贵、更慢的方式找不到答案。

八、面试里怎么解释 Agentic RAG？

面试官如果问“Agentic RAG 和传统 RAG 有什么区别”，可以这样回答：

传统 RAG 的检索路径通常由开发者预先写死，用户问题经过一次或固定次数检索后直接生成。Agentic RAG 把检索封装成 Agent 工具，由模型根据任务状态决定是否检索、如何拆分 Query、选择哪个数据源，并对中间证据做评估；证据不足时可以改写或继续检索，足够时才停止并生成带引用的答案。它更适合复杂、多跳和多数据源问题，但会增加延迟、成本、可观测性和权限治理难度。

这段回答里，定义、原理、场景和代价都有了，比只说“Agentic RAG 更智能”有用得多。

Agentic RAG 真正增加的不是一层 Agent 外壳，而是检索过程中的决策权、反馈和停止条件。

参考资料

• Retrieval-Augmented Generation for Knowledge-Intensive NLP Tasks (opens new window)
• ReAct: Synergizing Reasoning and Acting in Language Models (opens new window)
• Self-RAG: Learning to Retrieve, Generate, and Critique through Self-Reflection (opens new window)
• Corrective Retrieval Augmented Generation (opens new window)
• Adaptive-RAG: Learning to Adapt Retrieval-Augmented Large Language Models through Question Complexity (opens new window)
• AgenticRAG: Agentic Retrieval for Enterprise Knowledge Bases (opens new window)