Agentic RAG

Agentic RAG

flowchart LR
  A["Agentic RAG"]
  A --> B["分类：检索增强 (RAG)"]
  A --> C["关键词：RAG"]
  A --> D["关键词：Agentic RAG"]
  A --> E["关键词：LangGraph"]
  A --> F["关键词：LlamaIndex"]

前几篇写到这里，我们已经把 RAG 从“把相关文本塞给模型”这件事，逐步拆成了更完整的工程系统：如何切块、如何检索、如何重排、如何处理上下文窗口，如何让回答更可靠。

但传统 RAG 还有一个很明显的特征：流程通常是提前写死的。

用户提问之后，系统大多按固定顺序执行：

接收问题 → 检索一次或几次 → 拼接上下文 → 生成答案

这类流程并不差。事实上，大部分生产环境里的 RAG，真正稳定可控的，恰恰就是这种“固定管道式”的设计。 问题在于，当问题开始变复杂时，固定管道会暴露出局限：

• 有些问题根本不需要查库，模型直接回答更快
• 有些问题需要先拆解，再分别检索不同子问题
• 有些问题涉及多个来源，必须先判断“该去哪里查”
• 有些问题第一轮没查全，需要根据中间结果继续追查
• 有些问题表面像检索问题，本质却是“检索 + 推理 + 校验”的组合任务

于是，RAG 开始从“固定流程”走向“动态流程”。 这就是 Agentic RAG 想解决的问题。

它不是简单地把“检索”做得更强，而是把“如何检索”这件事，交给模型来决策：要不要查、先查什么、查几轮、查哪个源、什么时候停。

也因此，Agentic RAG 更像是：

让 LLM 不再只是答案生成器，而是检索流程的调度者。

RAG 的三阶段演进

可以把 RAG 的演化，粗略理解为三个阶段。

阶段	主要特征	典型流程
Naive RAG	单次检索，直接生成	Query → Embedding → Vector Search → LLM
Advanced RAG	在检索前后做优化	Query Rewriting / HyDE / Rerank / Compression → LLM
Agentic RAG	LLM 参与流程决策	LLM Planning → 多步检索 → 动态路由 → 合成

这三个阶段不是互相替代的关系，更像是逐层叠加：

• Naive RAG 解决“有没有外部知识”
• Advanced RAG 解决“检索质量够不够好”
• Agentic RAG 解决“固定检索流程是否足以应对复杂问题”

从工程上看，Agentic RAG 不是“更高级的检索器”，而是把检索流程本身变成一个可决策、可分支、可迭代的系统。

什么是 Agentic RAG

一个更准确的定义是：

Agentic RAG 是一种让 LLM 基于当前问题和中间状态，动态决定检索行为的 RAG 架构。

这里的关键不在“用了 Agent”，而在于检索不再是固定步骤，而是工具化能力。 LLM 可以在回答过程中：

1. 判断是否真的需要外部知识
2. 先规划问题，再决定检索顺序
3. 在多个数据源之间做路由
4. 根据第一轮结果决定是否继续检索
5. 在生成答案前做证据补充或结果校验

所以，Agentic RAG 的本质并不是“让模型更自由”，而是：

把原本由工程代码写死的检索策略，部分上移给模型决策。

这带来更强的适应性，但也同时引入更高的成本、延迟和不确定性。后面会反复看到，这种能力并不是免费的。

它和传统 RAG 的真正区别

很多介绍会把 Agentic RAG 概括成“多轮检索”。这不算错，但不够准确。 更本质的区别在于：谁在控制流程。

维度	传统 RAG	Agentic RAG
流程控制者	应用代码 / 固定链路	LLM + 状态机 / 策略层
是否检索	默认要检索	可动态决定
检索次数	通常固定	动态，1～N 次
查询方式	原始 query 或少量改写	可拆问题、重写、追问、迭代
数据源选择	通常预先指定	可路由到不同源
停止条件	固定流程结束	由状态、阈值、预算共同决定
适用问题	简单事实查询、单跳问答	多跳问题、跨源问题、需探索的问题
工程复杂度	低	高
成本与延迟	相对可控	更难控

这张表背后其实对应一个重要判断：

当问题结构本身不确定时，固定管道往往不够用。

例如“去年收入最高的产品线负责人现在归哪个部门”这种问题，显然不是一次向量检索就能稳妥解决的。它需要沿着一条有依赖关系的链条往前查：先找产品线，再找负责人，再找当前部门。这种问题天然更适合 Agentic RAG。

Agentic RAG 的核心能力

Agentic RAG 常被拆成几个能力模块，但更重要的是理解这些能力各自解决什么问题。

1. Query Planning：先理解问题结构，再决定怎么查

用户问题并不总是“一个问题”。很多时候它只是表面上看起来像一句话，实际上内部包含多个子任务。

例如：

苹果公司 2024 年的营收是多少？和微软相比如何？

如果把整句直接送去检索，系统可能会召回：

• 苹果营收相关内容
• 微软财报相关内容
• 一些“苹果 vs 微软”的评论文章
• 混杂年份不一致的内容

从“召回到一点相关文本”的角度看，这不算失败；但从“可靠回答问题”的角度看，它仍然不够。

更稳妥的方式，是先把问题结构化：

• 子问题 1：苹果公司 2024 年营收是多少
• 子问题 2：微软 2024 年营收是多少
• 子问题 3：基于一致口径做对比

这里的重点不是“拆题”本身，而是显式暴露问题中的依赖关系和比较维度。 一个成熟的 Agentic RAG 通常不会把 planning 当成装饰步骤，而会把它视为后续检索策略的入口：拆完之后，每个子问题该去哪里查、是否需要不同工具、结果如何合并，都会受这一步影响。

但要注意，Query Planning 也不是越复杂越好。规划过度会带来两个问题：

• 计划成本高于问题价值：简单问题却先跑一轮 plan，反而拖慢整体速度
• 规划漂移：模型把问题改写成另一个“更好回答但不等价”的问题

所以，planning 的关键不是“是否拆得足够细”，而是“是否把原问题保真地转成可执行的检索任务”。

2. Multi-step Retrieval：第一轮结果不够，就继续查

传统 RAG 常默认“一次检索应该拿回足够多的信息”。 这在单跳事实问答里通常成立，但在复杂任务里并不成立。

例如：

我们公司去年销售额最高的产品线，其负责人现在在哪个部门？

这个问题至少包含三段依赖关系：

1. 去年销售额最高的产品线是谁
2. 这条产品线的负责人是谁
3. 这个人当前归属哪个部门

第一轮检索很可能只能命中销售报表； 第二轮才有机会查到组织关系； 第三轮可能还要补一条最新的人事变更记录。

这就是多步检索的价值：每一轮检索都以前一轮结果为条件。 它不是“多查几次”这么简单，而是“沿着中间证据逐步推进”。

这类模式通常会遇到两个工程现实：

第一，模型很容易把“不完整”误判为“足够”

如果停得太早，就会出现一种很危险的假稳定： 系统回答看起来很完整，但实际只拿到了部分链路。

第二，模型也很容易把“已经足够”误判为“还不够”

这会导致无休止继续查，直到达到轮次上限。 因此，多步检索必须依赖显式停止条件，而不是完全相信模型的主观判断。

常见停止条件包括：

• 已满足某些字段完整性要求
• 证据数量达到阈值
• 新一轮检索没有带来新增信息
• 超过最大轮次 / 时间预算 / Token 预算
• 命中高可信来源后不再继续扩展

真正可用的 Agentic RAG，往往不是“模型自由决定一切”，而是：

模型负责提出下一步，系统负责设置边界。

3. Source Selection：先判断去哪查，而不是默认查同一个库

一旦系统里的知识源变多，问题就不再只是“怎么查”，还包括“去哪查”。

比如你可能同时有：

• 产品手册
• FAQ / 客服知识库
• 内部 SOP
• CRM / 工单系统
• 实时 API
• 结构化数据库
• 向量库
• 知识图谱

这时候，统一塞进一个向量库未必是最佳选择。 原因很直接：不同知识源的语义结构、更新时间、可信度、可解释性都不同。

例如：

问题类型	更合适的数据源
产品参数	产品手册 / 官方规格数据
售后政策	客服知识库 / 最新政策文档
内部流程	内部 SOP / Wiki
库存、价格、订单状态	实时 API / 数据库
实体关系、多跳依赖	知识图谱或结构化表

这类按问题路由到不同来源的模式，常被称为 Router RAG。 但它的难点不是“分类”，而是错误路由的代价：

• 路由错了，后续检索质量再高也没意义
• 多源并查虽然更稳，但成本和噪声会上升
• 某些问题需要的不只是“选一个源”，而是“按顺序组合多个源”

所以，源选择不是简单的 if/else，也不只是一个 LLM router prompt。成熟系统通常会把它设计成多层决策：

1. 规则优先拦截确定性场景
2. 再由模型处理模糊路由
3. 对高风险问题做并行检索或回退策略
4. 对关键源设置可信度优先级

这意味着，Router 的目标不是“让模型自由选”，而是“在多源环境里，把正确源命中的概率做高”。

4. Answer Synthesis：不是把片段拼起来，而是把证据组织成答案

Agentic RAG 的最后一步当然仍然是回答，但这个“回答”跟传统 RAG 里“基于上下文生成”不是一回事。

因为前面拿回来的已经不再是单次检索得到的一组块，而可能是：

• 多轮检索的证据链
• 不同来源的异构数据
• 彼此时间不一致的片段
• 部分相互印证、部分相互冲突的信息

所以 synthesis 的真正任务是：

• 组织证据顺序
• 统一口径
• 处理冲突
• 表达不确定性
• 给出引用或依据说明

一个成熟的 Agentic RAG，在这一阶段通常至少会显式处理三个问题：

证据是否一致

比如不同来源给出不同版本的人事归属、不同日期的产品参数、不同口径的财务数字。 系统不能只是“挑一个最像答案的片段”，而要知道：

• 哪个来源更新
• 哪个来源更权威
• 是否需要向用户暴露冲突

证据是否覆盖了问题的所有部分

很多回答看起来流畅，但只是覆盖了问题前半句。 例如用户问“营收是多少，和微软相比如何”，系统可能只答出苹果营收，完全没有比较部分。

答案是否应该保守

如果证据链有断点，理想行为不是“把空白补成自然语言”，而是明确说明：

• 哪一步已确认
• 哪一步缺证据
• 哪一部分是推断而不是文档事实

因此，Answer Synthesis 在 Agentic RAG 中的角色，更接近“基于证据链组织最终输出”，而不只是“语言润色”。

Agentic RAG 的三种典型模式

很多系统会混合使用几种模式，但从理解上，可以先把它拆成三类。

1. Router RAG：解决“查哪”

当你面对的是多源知识环境，核心问题往往不是“怎么重排”，而是“先去哪个源查”。

典型场景：

• 一个企业里同时有产品文档、售后文档、内部流程文档
• 一个 Copilot 同时接了向量库、数据库和 API
• 一个问答系统需要区分“私有知识问题”和“通用知识问题”

这类问题中，Router RAG 的价值很大，因为错误路由会从入口就拉低质量。 但它适合的前提是：不同源之间职责边界相对清晰。如果所有知识本质上都高度重叠，路由本身反而可能变成额外噪声。

2. Iterative RAG：解决“查几次”

当问题有明显的多跳依赖时，Iterative RAG 往往比单次检索更稳。

典型特征包括：

• 当前问题依赖上一步结果
• 第一轮无法确定最终 query
• 需要边查边缩小搜索空间
• 需要围绕中间实体继续追查

这类模式常见于：

• 组织关系查询
• 合同条款追溯
• 事件链调查
• 多实体比较
• 复杂工单分析

它的核心不是“多轮”，而是“每轮都由前一轮证据驱动”。

3. Adaptive RAG：解决“要不要查”

并不是所有问题都值得进入检索流程。 有些问题是纯通用知识，有些问题是寒暄，有些问题其实只是简单改写或总结请求。如果每个请求都强制走检索，不仅贵，而且慢。

Adaptive RAG 的目标是：

• 对能直接回答的问题，尽量直接回答
• 对必须依赖私有知识或时效信息的问题，再进入检索链路
• 对边界模糊的问题，可以先轻量探测，再决定是否深入检索

这类模式在面向真实用户的产品里非常实用，因为它能显著改善平均延迟和平均成本。 但它也有一个风险：误判为“无需检索”时，系统会显得过度自信。 所以，Adaptive RAG 通常不应该只靠模型主观判断，而应结合：

• 问题分类
• 领域识别
• 时间敏感词
• 是否涉及企业内部实体
• 高风险任务白名单 / 黑名单

可以把三种模式记成先看定义：

Router 解决“查哪”，Iterative 解决“查几次”，Adaptive 解决“要不要查”。

Agentic RAG 适合什么问题

不是所有 RAG 都值得做成 agent。 如果一篇文章读完只记住一个结论，我更希望是这一句：

Agentic RAG 适合“问题结构不确定”的场景，而不是“单次召回已经够用”的场景。

更具体地说，它更适合以下几类问题。

1. 多跳问题

需要先拿到 A，才能继续查 B，再根据 B 去确认 C。 这类问题最典型，也最容易从 Agentic RAG 获益。

2. 跨源问题

一个问题的答案天然分散在不同系统里。 例如产品文档给参数，CRM 给客户状态，工单系统给故障历史。

3. 信息不完整的问题

第一轮检索大概率拿不到完整信息，需要增量补全。

4. 需要动态策略的问题

例如一些问题先做结构化查询更优，一些问题更适合语义检索，一些问题根本不需要检索。

相反，下面这些场景通常不值得上 Agentic RAG：

• 单文档问答
• FAQ 类简单事实问答
• 高 QPS、极度延迟敏感的接口
• 数据源单一且结构稳定的问题
• 用户问题非常短且意图明确的场景

一句话概括：

复杂问题用复杂架构；简单问题不要为了“智能”而牺牲确定性。

一个更接近真实工程的例子

假设用户问：

我们公司去年销售额最高的产品线，其负责人现在在哪个部门？

这是一个很适合说明 Agentic RAG 的例子，因为它看似一句话，实际包含一个三段式依赖链。

如果用传统 RAG，会发生什么

最常见的做法是，把整句作为 query 检索企业知识库。 你可能会召回到：

• 年度销售总结中的产品线排名
• 某产品线介绍页
• 人员通讯录
• 一条旧组织架构文档

问题在于，这些片段都相关，但并不能自动组成答案。 模型可能会试图“凭感觉”把这些零散片段串起来，这时就很容易出现：

• 用了旧负责人信息
• 用了旧部门归属
• 销售额最高的口径不一致
• 缺失中间证据但仍然生成结论

如果用 Agentic RAG，更合理的流程是什么

一个更稳健的流程大概会是：

1. 识别问题结构：

   • 求“去年销售额最高的产品线”
   • 求“该产品线负责人”
   • 求“该负责人当前部门”

2. 第一轮检索： 查销售数据或年度报告，锁定产品线 A

3. 第二轮检索： 以“产品线 A”为实体，查负责人信息，得到张三

4. 第三轮检索： 以“张三”为实体，查最新组织架构或人事系统，得到当前部门

5. 结果合成： 输出答案，并按步骤引用证据来源

这个例子的关键不在于“多查了三次”，而在于：

每一步检索都在缩小问题空间，并且下一步 query 依赖上一步结果。

这正是 Agentic RAG 和普通多路召回之间的差异。

Agentic RAG 与 ReAct、Tool Use 的关系

如果把视野再放大一点，Agentic RAG 其实可以看成 Tool Use 在检索场景里的一个特化版本。

三者关系可以这样理解：

概念	作用范围	关系
Tool Use	最宽泛。模型调用各种工具	检索只是其中一种工具
ReAct	推理 + 行动循环	“行动”可以是调用检索
Agentic RAG	聚焦检索决策	是 Tool Use / ReAct 在 RAG 场景中的具体落地

这意味着，Agentic RAG 不一定非要长成“一个自由行动的 Agent”。 很多工程里，它更适合被实现成：

• 一个有状态的图
• 一个带预算的决策流
• 一个有限动作集合的 planner-executor 架构

从工程上看，“Agentic”不等于“完全开放式智能体”。 在生产环境里，真正可靠的 Agentic RAG 往往是受约束的 agent：

• 允许调用哪些工具是预定义的
• 能走哪些路径是受限的
• 每一步状态都可观测
• 停止条件和降级路径都写清楚

这比“放一个大模型自由思考”要靠谱得多。

一个更实用的系统视角：把它看成状态机，而不是魔法

从工程角度看，Agentic RAG 最容易被误解的一点是： 大家容易把它想成“LLM 自己会规划和行动”，于是系统设计也变得过度抽象。

更有帮助的理解方式是：

Agentic RAG 本质上是一个由模型参与决策的状态机。

系统中通常会有这些状态：

• 初始问题分析
• 是否需要检索
• 路由到哪个源
• 当前证据是否足够
• 是否继续检索
• 是否发生冲突
• 进入回答或降级分支

这样看之后，很多设计问题就会变清楚：

• 你需要保存哪些中间状态？
• 哪些状态由模型决定，哪些由规则决定？
• 哪些决策必须可审计？
• 什么时候应该回退到保守回答？
• 如何避免一轮又一轮重复查同样的东西？

因此，Agentic RAG 真正的工程价值，不只是“更聪明”，而是：

把复杂检索过程显式结构化，从而让复杂问题可被系统性处理。

实现方式：LangGraph 与 LlamaIndex

在具体实现上，常见框架里，LangGraph 和 LlamaIndex 都能做 Agentic RAG，但它们适合的团队画像并不一样。

LangGraph：适合把流程当系统来建模

LangGraph 的优势不是“能做 Agent”，而是它很适合把带状态、带分支、可回退的流程画清楚。 如果你的重点是这些问题：

• 需要显式状态管理
• 需要可视化或可追踪的节点流转
• 需要精细控制循环、重试、停止条件
• 需要把工具调用、检索、校验拆成独立节点

那么 LangGraph 往往更合适。

它比较像在搭一个受控执行图。 模型可以决定走哪条边，但边本身是你定义的。

# 伪代码：用状态驱动检索决策
def decide_next_step(state):
    # state 中可能包含：
    # - original_question
    # - retrieved_evidence
    # - missing_slots
    # - iteration_count
    # - budget_remaining

    decision = llm.invoke(
        "根据当前证据，判断下一步是继续检索、切换数据源，还是生成答案",
        state
    )

    if state["iteration_count"] >= 3:
        return "generate_or_fail_safe"

    if decision == "retrieve_more":
        return "retrieve"

    if decision == "switch_source":
        return "route"

    return "generate"

这类方式的优点是控制力强，缺点是：

• 需要你自己想清楚状态设计
• 需要处理更多边界条件
• 初期搭建成本更高

所以它更适合对系统行为有明确要求的团队，而不只是想快速搭个 demo。

LlamaIndex：适合快速原型和高层抽象

LlamaIndex 的思路更偏“把检索相关能力封装成较高层的组件”。 如果你的目标是快速验证这些问题：

• agent 方式检索是否有收益
• 多源检索是否比单源更好
• 某种 query planning 是否有效
• 某类文档是否值得做 agent 化检索

那么 LlamaIndex 往往更容易起步。

它的优势是：

• 检索相关抽象比较丰富
• 更容易快速拼出原型
• 对“把 RAG 做深一点”的场景很友好

但抽象层高也意味着一个典型代价： 系统行为有时不像你自己写状态机那样透明。 当效果不稳定时，你仍然要下钻去看每一步到底发生了什么。

怎么选

可以用一句比较实用的话来概括：

• 想精细控制流程、状态、回退与观测，就更偏 LangGraph
• 想更快验证思路、利用现成检索抽象，就更偏 LlamaIndex

真正的关键不在框架名，而在于你对系统的要求：

• 你更在意速度，还是更在意控制？
• 你做的是 demo，还是未来要上线的长期系统？
• 你的问题是“验证思路”，还是“稳定交付”？

框架只能放大你的设计，不会替你完成设计。

成本、延迟与稳定性：为什么很多 Agentic RAG 停在 demo

Agentic RAG 常见于演示，因为演示里的问题通常复杂、精彩，也更能体现“智能决策”的魅力。 但一进生产环境，团队很快就会面对三个非常现实的问题：

1. 延迟会快速上升

每多一次 planning、routing、judge、retrieve、reflect，本质上都是额外的一次模型调用或一次工具调用。

原来 1 次检索 + 1 次生成的链路，可能会变成：

• 1 次问题分析
• 1 次路由决策
• 2～3 次检索
• 1 次是否继续检索判断
• 1 次最终生成

即使每一步都不慢，总延迟也会明显拉长。 对用户来说，这种差异往往不是“从 200ms 变 400ms”，而是“从可接受的等待，变成明显卡顿”。

2. 成本不是线性问题，而是分布问题

平均看，多一步就是多一次调用； 但更麻烦的是长尾问题。

Agentic RAG 的成本问题往往来自少数复杂请求：

• 反复规划
• 多轮检索
• 调多个源
• 大量上下文拼接
• 最终还要再合成一次

所以你不能只看平均 Token 成本，更要看：

• P95 / P99 请求的成本
• 哪类问题最容易触发多轮
• 哪些 source 最容易引发无效循环
• 哪些 prompt 会导致过度保守或过度探索

3. 不稳定会显著放大

传统 RAG 的不稳定，多数集中在“检索得不好”或“生成引用不稳”。 而 Agentic RAG 会多出一层不稳定：决策本身不稳定。

同一个问题，模型可能这次决定直接回答，下次决定先查； 这次先查产品库，下次先查知识库； 这次两轮停，下次三轮还不停。

这类不稳定会让线上表现变得难以复现，也难以调试。

因此，Agentic RAG 上线前，必须回答这些问题：

• 允许最大检索轮次是多少？
• 单请求最大 Token 预算是多少？
• 单请求允许访问多少个源？
• 哪些问题必须走检索，哪些问题禁止自由探索？
• 何时强制降级到传统 RAG 或保守答复？

很多团队最后会发现，真正能落地的不是“完全开放式 Agentic RAG”，而是：

一个有预算、有边界、有回退的半自动 Agentic RAG。

设计时最值得提前想清楚的权衡

如果你真的要做 Agentic RAG，下面这些权衡通常比“选哪个模型”更先决定成败。

最大检索轮次

轮次太少，复杂问题查不全； 轮次太多，成本和延迟失控。

工程上常见的选择是 2～5 轮，但更重要的是： 轮次上限必须与业务价值匹配。 不是所有请求都值得 5 轮追查。

规划是否缓存

对于高频、结构相似的问题，规划结果可能具备复用价值。 比如很多查询其实只是实体变了，问题结构没变。

缓存的好处是减少重复 planning； 但难点在于：

• cache key 很难设计
• 问题表述相似，不代表执行路径完全一致
• 数据时效性变化会让旧规划失效

所以，缓存通常更适合缓存“问题模式”，而不是缓存完整执行轨迹。

决策由模型做多少，规则做多少

这是 Agentic RAG 的核心设计题。 如果什么都交给模型，系统会很灵活，但很难控。 如果什么都写死，又失去了 agent 的意义。

一个比较健康的分层通常是：

• 规则负责硬边界：预算、权限、敏感源、超时、最大轮次
• 模型负责软决策：query 改写、子问题拆解、下一步优先级
• 评估器负责质量门槛：证据是否足够、冲突是否解决、是否应保守作答

失败后如何降级

降级策略必须事先设计，而不是线上临时补。

常见降级方式包括：

• 超轮次后强制总结现有证据
• 只返回已确认部分，不补猜测
• 回退到单轮传统 RAG
• 明确告知“未找到足够证据”
• 将结构化信息和未确认项拆开展示

这里没有统一标准，但有一个通用原则：

降级时优先保住可信度，而不是保住“像是答出来了”的表面效果。

常见失败模式，比“无限循环”更值得警惕

很多文章提 Agentic RAG 的风险时，只会说无限循环。确实，这是一个问题，但并不是最危险的那个。真正麻烦的失败模式通常更隐蔽。

1. 规划漂移

模型在拆问题时，悄悄把用户原问题改写成了另一个更容易回答的问题。

例如用户问“现在在哪个部门”，模型却只查到“曾经在哪个团队”，最后拿旧信息当当前信息。 这类问题特别危险，因为流程看起来很完整，实际上目标早就变了。

2. 错误路由后的高置信输出

一旦第一步源选错，后续检索可能会在错误语境里越查越“完整”。 最终答案会显得很流畅，但证据链从一开始就走歪了。

3. 证据链断裂但语言把空白补满

这是 LLM 最典型的问题之一。 系统只拿到了 A 和 C，没有拿到 B，但模型会自然地把 B 补出来，让答案读起来像完整事实。

Agentic RAG 并不会天然消除这个问题，反而因为步骤更多，更容易产生“局部证据 + 全局叙述”的幻觉。

4. 重复检索同一信息

模型判断“信息还不够”，但其实只是换了几个词又查了一遍相同内容。 这会带来成本浪费，而且让系统误以为做了更多探索。

5. 过拟合单一来源

某个源特别容易命中，模型就不断依赖它，忽略了更权威但不那么“语义相近”的来源。 例如内部讨论文档可能比正式制度文档更好召回，但不代表它更可信。

6. 把 agent 当作检索质量问题的替代品

如果基础索引很差、切块有问题、元数据缺失、重排没做好，那么上 Agentic RAG 往往只是在更复杂的流程里重复放大这些问题。

这一点很重要：

Agentic RAG 不是基础检索质量差时的补救药。

如果底层 RAG 做得不稳，agent 往往只会让问题更难排查。

怎么避坑：几个比“加一个 prompt”更有效的做法

给模型有限动作空间

不要让模型“自由发挥所有可能行为”，而是只允许它在有限动作里选：

• 直接回答
• 改写 query
• 继续检索
• 切换数据源
• 请求澄清（如果产品允许）
• 返回证据不足

动作空间越清晰，系统越可控。

维护显式工作记忆

把已经查到的实体、缺失字段、访问过的数据源、已验证结论写进状态，而不是每一轮全靠模型在上下文里“记住”。

否则，随着轮次增加，模型很容易忘记：

• 自己已经查过什么
• 哪些信息已确认
• 哪些地方还缺证据
• 哪些 query 只是重复劳动

给“继续检索”设置硬门槛

不要只问模型“还要不要继续查”。 更好的问题是：

• 当前答案缺的是哪一项字段？
• 新一轮最可能补到什么？
• 如果再查不到，是否应停止？
• 继续检索的收益是否超过预算？

这样可以把“继续查”从一种主观感觉，变成一种有条件的决策。

对来源设置优先级和可信度

在 synthesis 阶段，应让系统明确知道：

• 哪些源是权威源
• 哪些源只适合补充背景
• 哪些源时效性强但可能不完整
• 哪些源只能作线索、不能作最终依据

否则，多源系统很容易出现“最容易命中的片段压过最可信的片段”。

做好可观测性

Agentic RAG 最怕黑盒。 上线前至少要能看到这些信息：

• 每轮 query 是什么
• 命中了哪个源
• 为什么继续或停止
• 哪些证据被采纳，哪些被丢弃
• 最终答案引用了哪些片段

没有这些观测能力，后续优化几乎只能靠猜。

一个很重要的判断：先把传统 RAG 做稳，再谈 Agentic

实践里经常出现一种顺序错误： 团队在基础检索还没做稳时，就急着上 agent，希望用更复杂的决策逻辑弥补召回质量不足。

这通常不会成功。

更现实的顺序应该是：

1. 先把基础 RAG 跑通 包括切块、索引、召回、重排、引用、评估

2. 再确定瓶颈是不是“流程固定” 而不是基础质量问题、知识覆盖问题或数据时效问题

3. 只有当问题确实需要动态决策时，再引入 agent 化能力

因为很多看起来像“需要 Agentic RAG”的问题，最后真正的根因可能只是：

• 元数据没打好
• chunk 太碎或太粗
• query 改写缺失
• rerank 没做
• 结构化数据没有单独接入
• 时效数据本就不该走向量检索

所以，Agentic RAG 更像是 RAG 系统的“第二阶段优化”，而不是起步配置。

何时该用，何时不该用

可以把判断压缩成一组更实用的建议。

场景	更推荐的方案
单文档问答、FAQ、简单事实查询	传统 RAG
多跳推理，需要沿证据链逐步查询	Agentic RAG
多数据源融合，需要先判断查哪里	Router / Agentic RAG
信息经常不完整，需要边查边补	Iterative RAG
通用知识与私有知识混合	Adaptive RAG
极度延迟敏感、高并发接口	优先传统 RAG 或混合方案
基础检索质量尚不稳定	先补底层，不急着 agent 化

真正的工程建议不是“复杂问题用 Agentic”，而是：

只有当固定流程已经成为瓶颈，Agentic RAG 才值得引入。

小结

Agentic RAG 代表的，不只是 RAG 多了一层“智能”，而是 RAG 的架构思路发生了变化：

• 从“预先写死的检索流水线”
• 走向“带状态、带决策、带回退的动态检索系统”

它最有价值的地方，不在于听起来更像 Agent，而在于它确实能处理那些传统 RAG 很难优雅覆盖的问题：多跳、跨源、不完整、需要动态选择策略的问题。

但它也绝不是默认升级项。

它的代价同样明确：

• 更高的成本
• 更长的延迟
• 更复杂的调试
• 更强的可观测性要求
• 更严格的边界与降级设计

所以，更克制的结论应该是：

Agentic RAG 不是“更先进的 RAG 形态”，而是“当问题复杂到固定管道不再够用时，一种更合适的系统设计”。

如果前几篇是在讨论“怎样把检索做准”，那么这一篇真正讨论的是：

当检索不再是一步，而是一连串需要决策的动作时，RAG 应该如何被设计。

这也是它和后续话题之间的自然连接点： 当问题越来越依赖关系结构和显式连接，下一步就不再只是“多轮检索”，而会进一步走向 Graph RAG。

核心概念速查

概念	一句话说明
Agentic RAG	让 LLM 参与决定是否检索、检索什么、检索几次、去哪里检索的 RAG 架构
Query Planning	先把问题转成可执行的检索任务，而不是直接拿原句去查
Router RAG	根据问题类型或证据需求，决定把请求送到哪个知识源
Iterative RAG	基于中间证据逐步推进检索，而不是默认一次查全
Adaptive RAG	先判断问题是否值得检索，再决定是否进入 RAG 链路
Source Selection	在向量库、数据库、API、知识图谱等来源之间做动态路由
Answer Synthesis	对多轮、多源证据做统一、冲突处理与最终组织，而不只是拼文本
最大风险	成本、延迟、决策不稳定，以及证据链断裂后仍生成“完整答案”
实践原则	先把传统 RAG 做稳，再在“固定流程已成为瓶颈”时引入 Agentic 能力

---