上一篇文章里我们讨论了 GraphRAG。GraphRAG 解决的是普通 RAG 在实体关系、跨文档关联和全局结构问题上的边界。它让系统不只是从 Chunk 里找相似片段也能利用实体、关系和图结构来回答问题。但 RAG 继续往真实应用里走还会遇到另一类问题不是知识结构复杂而是任务过程本身不固定。比如帮我判断这个客户问题应该查哪些资料。 先看一下这个报错可能和哪些配置有关再给我排查步骤。 如果资料不够你再继续查相关制度。 帮我比较这几个方案并说明每个结论依据来自哪里。这些问题不是一次检索就能稳定解决。系统需要先理解任务再决定是否检索、检索什么、是否继续检索以及什么时候停止。这就是 Agentic RAG 被讨论的原因。这篇文章就围绕一个问题展开Agentic RAG 是什么为什么要让 Agent 决定什么时候检索。传统 RAG 的流程是固定的传统 RAG 通常有一条比较固定的链路。用户问题 ↓ 检索资料 ↓ Rerank ↓ 拼接 Prompt ↓ 大模型生成答案这个流程非常清晰。它适合很多知识库问答场景。比如试用期员工能不能休年假 ERR_1024 表示什么 POST /orders 的 quantity 参数是否必填 报销申请需要提前几天提交这些问题目标明确。系统知道要做什么先检索再回答。但是在真实 AI 应用里很多用户问题并不是这么标准。用户可能不是直接问一个事实而是提出一个任务。比如帮我分析这次接口报错可能是什么原因。这个任务可能需要查接口文档。查错误码说明。查权限配置说明。查历史故障案例。判断资料是否足够。必要时继续检索。如果仍然套用固定流程用户问题 - 检索一次 - 回答系统很容易只查到一部分资料然后给出不完整答案。这就是传统 RAG 的局限。它把检索看成固定步骤。但真实任务里检索可能是一个需要动态决策的过程。Agentic RAG 到底是什么Agentic RAG 可以理解为让 Agent 根据任务状态动态决定如何使用检索能力。在传统 RAG 里Retriever 是流程中的一个固定节点。在 Agentic RAG 里Retriever 更像是 Agent 可以调用的工具。Agent 会根据当前任务决定是否需要检索。检索哪个知识源。用什么查询去检索。检索结果是否足够。是否需要再次检索。是否需要换一种检索策略。什么时候可以停止检索并生成答案。一个简化流程是用户任务 ↓ Agent 理解任务 ↓ 判断是否需要检索 ↓ 调用 Retriever ↓ 阅读检索结果 ↓ 判断资料是否足够 ↓ 必要时继续检索 ↓ 生成最终答案这和传统 RAG 的区别在于传统 RAG 是固定链路。Agentic RAG 是动态决策。它不是简单把 Agent 和 RAG 两个词拼在一起。它的核心是把检索从固定步骤变成可被 Agent 调度的能力。为什么需要 Agent 决定是否检索并不是所有问题都需要检索。有些问题模型可以直接回答。比如Python 里的 list 和 tuple 有什么区别如果这是通用编程问答可能不需要查企业知识库。但有些问题必须检索。比如我们公司试用期员工能不能休年假这必须查内部制度。还有一些问题一开始不确定是否需要检索。比如这个报错是不是权限问题Agent 可能需要先判断用户说的“这个报错”有没有错误码是否提供了接口名是否有上下文记录需要查错误码还是权限文档如果问题缺信息Agent 可能不应该直接检索而应该追问。比如请补充具体错误码或接口名称这样才能判断是否和权限配置有关。所以是否检索本身就是一个决策。传统 RAG 默认每次都检索。Agentic RAG 则更灵活该检索时检索不该检索时追问或直接回答。Agent 如何决定检索什么Agentic RAG 的关键不只是决定“要不要检索”还包括决定“检索什么”。比如用户问订单创建接口返回 403应该怎么排查这句话里包含几个潜在检索方向订单创建接口文档 403 错误码说明 接口鉴权规则 token 过期处理 权限配置说明 历史故障案例传统 RAG 可能只用原始问题检索一次。Agentic RAG 可以先规划第一步查询订单创建接口的鉴权要求。 第二步查询 403 错误码含义。 第三步查询权限配置和 token 相关说明。 第四步如果资料足够再生成排查步骤。这个过程更像任务执行。Agent 需要把用户问题拆成检索计划。再比如用户问帮我比较新旧报销制度的差异。Agent 不能只检索“报销制度差异”。它可能需要查新版本报销制度 查旧版本报销制度 提取申请条件 提取审批流程 提取额度规则 比较差异 引用来源这里的检索是为任务服务的。Agent 先理解任务再生成检索动作。这就是 Agentic RAG 和普通检索增强问答的差别。检索结果不够时Agent 应该继续查传统 RAG 通常只检索一次。如果召回内容不完整模型可能会硬答。Agentic RAG 更强调反馈循环。比如第一次检索后Agent 可以判断当前资料只说明了错误码含义没有说明排查步骤。于是继续检索查询403 错误 排查步骤 权限配置再比如第一次检索只找到了新制度没有找到旧制度。Agent 可以继续查查询报销制度 历史版本 2025这个过程可以表示为检索 ↓ 阅读结果 ↓ 判断是否足够 ↓ 不足则继续检索 ↓ 足够则回答这就是 Agentic RAG 的重要能力。它不把检索看成一次性动作而是看成可迭代过程。但这里也要注意继续检索不是无限检索。Agent 必须有停止条件。比如已经找到足够证据。检索次数达到上限。连续两次没有新增有效信息。资料冲突无法消解。需要用户补充信息。没有停止条件Agentic RAG 很容易进入检索循环。Agentic RAG 和 Multi-hop Retrieval 有什么区别第 9 篇文章里我们讨论过 Multi-hop Retrieval。它也是多步检索。那它和 Agentic RAG 有什么区别可以这样理解Multi-hop Retrieval 更像一种预设策略。比如第一步查实体 第二步查实体相关属性 第三步合成答案它通常适合结构比较明确的问题。比如负责 Alpha 系统的部门有哪些审批权限可以先查 Alpha 系统归属部门再查该部门审批权限。Agentic RAG 更强调动态决策。它不一定提前知道要查几步。Agent 会根据每一步结果决定下一步。比如第一次检索发现资料不足 - 再查 第二次检索发现有冲突 - 查版本信息 第三次检索仍无法判断 - 说明资料冲突并停止所以两者不是对立关系。Multi-hop Retrieval 可以是 Agentic RAG 里的一个检索策略。Agentic RAG 的范围更大。它包括任务理解、工具选择、检索计划、结果反思、继续检索和停止判断。Agentic RAG 适合什么场景Agentic RAG 不一定适合所有知识库问答。它更适合任务过程不固定的场景。第一类是复杂排障。比如这个接口报错可能是什么原因应该怎么查它可能需要查错误码、接口文档、权限规则、配置项和历史案例。第二类是多轮对话。比如用户先问制度再追问那如果是上海员工呢 旧版本是不是不一样 这个流程谁审批Agent 需要结合上下文决定检索方向。第三类是资料不足时需要继续探索。比如第一次检索没有找到明确依据Agent 可以换查询或查其他知识源。第四类是需要选择不同工具。比如有多个知识源制度库 接口文档库 故障案例库 代码仓库说明 数据库字段字典Agent 可以根据问题选择工具。第五类是需要生成分析型结果。比如帮我比较三个方案的风险和依据。这不是简单问答而是需要查资料、整理证据、比较和输出结构化结论。第六类是工作流型任务。比如帮我根据知识库生成一份排查清单。Agent 需要分步骤完成任务。这些场景里固定 RAG 链路会显得太死。Agentic RAG 能给系统更多主动性。Agentic RAG 不适合什么场景Agentic RAG 有价值但也不应该滥用。第一简单事实问答不需要。比如ERR_1024 表示什么直接关键词检索可能更快、更稳。第二强实时低延迟场景要谨慎。Agentic RAG 可能多次调用模型和检索工具。延迟和成本都会上升。第三高风险确定性场景要谨慎。如果系统必须严格按固定流程执行Agent 的动态决策可能带来不可控行为。第四缺少日志和可观测性时不要急着上。Agentic RAG 链路更复杂。如果没有记录中间决策很难排查为什么它查了这个、不查那个。第五权限边界不清楚时不要上。Agent 会动态选择工具和知识源。如果权限过滤不严格可能造成越权检索。第六基础 RAG 还没做好时不要上。如果文档切分、检索、Rerank、Prompt 都不稳定Agentic RAG 只会把不稳定放大。所以 Agentic RAG 不是高级版万能药。它是在基础 RAG 能力稳定之后为复杂任务引入动态决策。Agentic RAG 的风险Agentic RAG 最大的问题是复杂性上升。风险主要有几个。第一检索循环。Agent 一直觉得资料不够一直继续检索。这会导致延迟和成本失控。第二错误反思。Agent 可能误判检索结果不够或者误判已经足够。第三错误工具选择。比如本来应该查接口文档它却查了制度库。第四查询漂移。多轮检索中查询逐渐偏离用户原始问题。第五权限风险。Agent 动态选择知识源时必须严格执行用户权限。第六可观测性变差。传统 RAG 只要看一次检索结果。Agentic RAG 要看每一步计划、工具调用、检索结果和停止理由。第七答案责任边界模糊。如果 Agent 进行了多次检索和推理最终答案必须仍然能追溯到证据。这些风险决定了Agentic RAG 必须有边界和日志。不能只让 Agent 自由行动。一个可落地的 Agentic RAG 流程一个更可控的 Agentic RAG 流程可以这样设计用户任务 ↓ 任务分类 ↓ 判断是否需要检索 ↓ 生成检索计划 ↓ 选择知识源或工具 ↓ 执行检索 ↓ 评估结果是否足够 ↓ 必要时继续检索 ↓ 整理证据 ↓ 生成答案其中几个环节特别重要。第一任务分类。先判断这是简单问答、排障、对比、总结、追问还是资料不足。第二检索计划。不要让 Agent 直接乱查。可以要求它输出需要查什么 为什么查 使用哪个知识源 预期找到什么第三工具选择。不同知识源要有明确用途。比如制度库查制度和流程 接口文档库查接口参数和错误码 故障案例库查历史排障经验 图谱工具查实体关系和影响路径第四结果评估。Agent 要判断资料是否足够支撑答案。第五停止条件。必须限制最大检索轮数。第六证据整理。最终答案不能只给结论还要说明依据。日志和可观测性必须做好Agentic RAG 的调试难度比普通 RAG 高很多。所以日志非常关键。至少应该记录用户原始任务 任务分类结果 Agent 的检索计划 每次检索的查询 使用的知识源 每次检索返回的资料 Agent 对结果的判断 是否继续检索 停止原因 最终上下文 Prompt 版本 最终答案 引用来源如果答案错了需要知道错在哪里。可能是任务分类错了。可能是工具选错了。可能是查询写偏了。可能是检索结果没召回。可能是 Agent 误判资料足够。也可能是 Prompt 没约束住模型。没有日志Agentic RAG 很难上线。因为它的行为不是固定链路而是动态决策。动态决策必须可追踪。如何控制 Agentic RAG 不失控落地 Agentic RAG 时要给 Agent 设置边界。第一限制检索轮数。比如最多检索 3 轮。第二限制每轮候选数量。避免一次拿太多资料。第三限制可用工具。不同用户、不同任务只能访问允许的工具。第四要求每次检索说明理由。如果 Agent 不知道为什么查就不应该查。第五要求基于证据回答。即使是 Agentic RAG最终也不能脱离资料自由发挥。第六资料不足时允许停止。不要为了给答案而无限检索。第七对高风险任务设置人工确认。比如涉及权限、删除、发布、审批等操作时不能让 Agent 自动执行。这些边界会让 Agentic RAG 更像工程系统而不是一个不受控的自动循环。Agentic RAG 和 GraphRAG 可以结合吗可以。GraphRAG 提供的是图谱检索能力。Agentic RAG 提供的是动态决策能力。两者可以组合。比如用户问如果支付系统异常会影响哪些业务流程应该先通知哪些团队Agent 可以这样规划第一步使用 GraphRAG 查询支付系统的依赖关系。 第二步查询支付系统影响的业务流程。 第三步查询相关系统负责人或维护团队。 第四步整理影响范围和通知清单。这里 GraphRAG 是工具。Agentic RAG 决定什么时候调用这个工具以及是否继续查其他资料。一个组合链路可以是用户任务 ↓ Agent 规划 ↓ 普通 RAG / GraphRAG / 关键词检索 ↓ Agent 判断资料是否足够 ↓ 必要时继续检索 ↓ 基于证据生成答案所以 GraphRAG 和 Agentic RAG 不是替代关系。GraphRAG 解决知识结构问题。Agentic RAG 解决任务流程动态决策问题。怎么评估 Agentic RAGAgentic RAG 不能只看回答是否流畅。要评估整个过程。第一是否正确判断需要检索。有些问题不需要检索有些问题必须检索。第二是否选择了正确知识源。接口问题应该查接口文档制度问题应该查制度库。第三检索计划是否合理。计划要覆盖任务关键点不能偏离用户问题。第四是否能在资料不足时继续检索。第五是否能在资料仍不足时停止并说明原因。第六最终答案是否基于证据。第七延迟和成本是否可接受。可以准备一组测试任务简单事实问题 复杂排障问题 多轮上下文问题 对比分析问题 资料不足问题 跨知识源问题 权限边界问题分别观察 Agent 的行为。评估重点不是它“看起来聪不聪明”。而是它是否稳定、可控、可解释。落地建议如果你准备做 Agentic RAG可以按下面顺序推进。第一先把基础 RAG 做稳。文档解析、切分、检索、Rerank、Prompt 和引用来源要先可用。第二先限定场景。不要一开始做万能 Agent。可以先从排障问答、制度对比或多轮知识库助手开始。第三定义工具边界。每个工具能做什么不能做什么要清楚。第四限制检索轮数。先从 2 到 3 轮开始。第五要求 Agent 输出检索理由。便于审计和排查。第六记录完整链路日志。没有日志就不要上线复杂 Agentic RAG。第七建立测试集。用真实任务评估 Agent 的决策质量。第八资料不足时允许追问或停止。不要强行给答案。总结传统 RAG 是固定流程适合目标明确的知识库问答。Agentic RAG 则让 Agent 根据任务状态动态决定是否检索、检索什么、是否继续检索以及什么时候停止。它的核心不是把 Agent 和 RAG 两个概念简单拼接而是把 Retriever 变成 Agent 可以调度的工具。Agentic RAG 适合复杂排障、多轮对话、跨知识源检索、分析型任务和工作流型任务。但它也带来更高的复杂度、成本和风险。检索循环、工具选择错误、查询漂移、权限问题和可观测性不足都会影响系统稳定性。所以 Agentic RAG 必须有边界。它需要明确的工具定义、检索轮数限制、停止条件、权限控制和完整日志。从工程角度看Agentic RAG 不是让模型自由行动而是让模型在受控边界内做动态检索决策。下一篇文章可以继续讨论 RAG 系统怎么评测。因为无论是普通 RAG、GraphRAG 还是 Agentic RAG最终都不能只靠“看起来还不错”来判断质量。Agentic RAG 是什么让 Agent 决定什么时候检索上一篇文章里我们讨论了 GraphRAG。GraphRAG 解决的是普通 RAG 在实体关系、跨文档关联和全局结构问题上的边界。它让系统不只是从 Chunk 里找相似片段也能利用实体、关系和图结构来回答问题。但 RAG 继续往真实应用里走还会遇到另一类问题不是知识结构复杂而是任务过程本身不固定。比如帮我判断这个客户问题应该查哪些资料。 先看一下这个报错可能和哪些配置有关再给我排查步骤。 如果资料不够你再继续查相关制度。 帮我比较这几个方案并说明每个结论依据来自哪里。这些问题不是一次检索就能稳定解决。系统需要先理解任务再决定是否检索、检索什么、是否继续检索以及什么时候停止。这就是 Agentic RAG 被讨论的原因。这篇文章就围绕一个问题展开Agentic RAG 是什么为什么要让 Agent 决定什么时候检索。传统 RAG 的流程是固定的传统 RAG 通常有一条比较固定的链路。用户问题 ↓ 检索资料 ↓ Rerank ↓ 拼接 Prompt ↓ 大模型生成答案这个流程非常清晰。它适合很多知识库问答场景。比如试用期员工能不能休年假 ERR_1024 表示什么 POST /orders 的 quantity 参数是否必填 报销申请需要提前几天提交这些问题目标明确。系统知道要做什么先检索再回答。但是在真实 AI 应用里很多用户问题并不是这么标准。用户可能不是直接问一个事实而是提出一个任务。比如帮我分析这次接口报错可能是什么原因。这个任务可能需要查接口文档。查错误码说明。查权限配置说明。查历史故障案例。判断资料是否足够。必要时继续检索。如果仍然套用固定流程用户问题 - 检索一次 - 回答系统很容易只查到一部分资料然后给出不完整答案。这就是传统 RAG 的局限。它把检索看成固定步骤。但真实任务里检索可能是一个需要动态决策的过程。Agentic RAG 到底是什么Agentic RAG 可以理解为让 Agent 根据任务状态动态决定如何使用检索能力。在传统 RAG 里Retriever 是流程中的一个固定节点。在 Agentic RAG 里Retriever 更像是 Agent 可以调用的工具。Agent 会根据当前任务决定是否需要检索。检索哪个知识源。用什么查询去检索。检索结果是否足够。是否需要再次检索。是否需要换一种检索策略。什么时候可以停止检索并生成答案。一个简化流程是用户任务 ↓ Agent 理解任务 ↓ 判断是否需要检索 ↓ 调用 Retriever ↓ 阅读检索结果 ↓ 判断资料是否足够 ↓ 必要时继续检索 ↓ 生成最终答案这和传统 RAG 的区别在于传统 RAG 是固定链路。Agentic RAG 是动态决策。它不是简单把 Agent 和 RAG 两个词拼在一起。它的核心是把检索从固定步骤变成可被 Agent 调度的能力。为什么需要 Agent 决定是否检索并不是所有问题都需要检索。有些问题模型可以直接回答。比如Python 里的 list 和 tuple 有什么区别如果这是通用编程问答可能不需要查企业知识库。但有些问题必须检索。比如我们公司试用期员工能不能休年假这必须查内部制度。还有一些问题一开始不确定是否需要检索。比如这个报错是不是权限问题Agent 可能需要先判断用户说的“这个报错”有没有错误码是否提供了接口名是否有上下文记录需要查错误码还是权限文档如果问题缺信息Agent 可能不应该直接检索而应该追问。比如请补充具体错误码或接口名称这样才能判断是否和权限配置有关。所以是否检索本身就是一个决策。传统 RAG 默认每次都检索。Agentic RAG 则更灵活该检索时检索不该检索时追问或直接回答。Agent 如何决定检索什么Agentic RAG 的关键不只是决定“要不要检索”还包括决定“检索什么”。比如用户问订单创建接口返回 403应该怎么排查这句话里包含几个潜在检索方向订单创建接口文档 403 错误码说明 接口鉴权规则 token 过期处理 权限配置说明 历史故障案例传统 RAG 可能只用原始问题检索一次。Agentic RAG 可以先规划第一步查询订单创建接口的鉴权要求。 第二步查询 403 错误码含义。 第三步查询权限配置和 token 相关说明。 第四步如果资料足够再生成排查步骤。这个过程更像任务执行。Agent 需要把用户问题拆成检索计划。再比如用户问帮我比较新旧报销制度的差异。Agent 不能只检索“报销制度差异”。它可能需要查新版本报销制度 查旧版本报销制度 提取申请条件 提取审批流程 提取额度规则 比较差异 引用来源这里的检索是为任务服务的。Agent 先理解任务再生成检索动作。这就是 Agentic RAG 和普通检索增强问答的差别。检索结果不够时Agent 应该继续查传统 RAG 通常只检索一次。如果召回内容不完整模型可能会硬答。Agentic RAG 更强调反馈循环。比如第一次检索后Agent 可以判断当前资料只说明了错误码含义没有说明排查步骤。于是继续检索查询403 错误 排查步骤 权限配置再比如第一次检索只找到了新制度没有找到旧制度。Agent 可以继续查查询报销制度 历史版本 2025这个过程可以表示为检索 ↓ 阅读结果 ↓ 判断是否足够 ↓ 不足则继续检索 ↓ 足够则回答这就是 Agentic RAG 的重要能力。它不把检索看成一次性动作而是看成可迭代过程。但这里也要注意继续检索不是无限检索。Agent 必须有停止条件。比如已经找到足够证据。检索次数达到上限。连续两次没有新增有效信息。资料冲突无法消解。需要用户补充信息。没有停止条件Agentic RAG 很容易进入检索循环。Agentic RAG 和 Multi-hop Retrieval 有什么区别第 9 篇文章里我们讨论过 Multi-hop Retrieval。它也是多步检索。那它和 Agentic RAG 有什么区别可以这样理解Multi-hop Retrieval 更像一种预设策略。比如第一步查实体 第二步查实体相关属性 第三步合成答案它通常适合结构比较明确的问题。比如负责 Alpha 系统的部门有哪些审批权限可以先查 Alpha 系统归属部门再查该部门审批权限。Agentic RAG 更强调动态决策。它不一定提前知道要查几步。Agent 会根据每一步结果决定下一步。比如第一次检索发现资料不足 - 再查 第二次检索发现有冲突 - 查版本信息 第三次检索仍无法判断 - 说明资料冲突并停止所以两者不是对立关系。Multi-hop Retrieval 可以是 Agentic RAG 里的一个检索策略。Agentic RAG 的范围更大。它包括任务理解、工具选择、检索计划、结果反思、继续检索和停止判断。Agentic RAG 适合什么场景Agentic RAG 不一定适合所有知识库问答。它更适合任务过程不固定的场景。第一类是复杂排障。比如这个接口报错可能是什么原因应该怎么查它可能需要查错误码、接口文档、权限规则、配置项和历史案例。第二类是多轮对话。比如用户先问制度再追问那如果是上海员工呢 旧版本是不是不一样 这个流程谁审批Agent 需要结合上下文决定检索方向。第三类是资料不足时需要继续探索。比如第一次检索没有找到明确依据Agent 可以换查询或查其他知识源。第四类是需要选择不同工具。比如有多个知识源制度库 接口文档库 故障案例库 代码仓库说明 数据库字段字典Agent 可以根据问题选择工具。第五类是需要生成分析型结果。比如帮我比较三个方案的风险和依据。这不是简单问答而是需要查资料、整理证据、比较和输出结构化结论。第六类是工作流型任务。比如帮我根据知识库生成一份排查清单。Agent 需要分步骤完成任务。这些场景里固定 RAG 链路会显得太死。Agentic RAG 能给系统更多主动性。Agentic RAG 不适合什么场景Agentic RAG 有价值但也不应该滥用。第一简单事实问答不需要。比如ERR_1024 表示什么直接关键词检索可能更快、更稳。第二强实时低延迟场景要谨慎。Agentic RAG 可能多次调用模型和检索工具。延迟和成本都会上升。第三高风险确定性场景要谨慎。如果系统必须严格按固定流程执行Agent 的动态决策可能带来不可控行为。第四缺少日志和可观测性时不要急着上。Agentic RAG 链路更复杂。如果没有记录中间决策很难排查为什么它查了这个、不查那个。第五权限边界不清楚时不要上。Agent 会动态选择工具和知识源。如果权限过滤不严格可能造成越权检索。第六基础 RAG 还没做好时不要上。如果文档切分、检索、Rerank、Prompt 都不稳定Agentic RAG 只会把不稳定放大。所以 Agentic RAG 不是高级版万能药。它是在基础 RAG 能力稳定之后为复杂任务引入动态决策。Agentic RAG 的风险Agentic RAG 最大的问题是复杂性上升。风险主要有几个。第一检索循环。Agent 一直觉得资料不够一直继续检索。这会导致延迟和成本失控。第二错误反思。Agent 可能误判检索结果不够或者误判已经足够。第三错误工具选择。比如本来应该查接口文档它却查了制度库。第四查询漂移。多轮检索中查询逐渐偏离用户原始问题。第五权限风险。Agent 动态选择知识源时必须严格执行用户权限。第六可观测性变差。传统 RAG 只要看一次检索结果。Agentic RAG 要看每一步计划、工具调用、检索结果和停止理由。第七答案责任边界模糊。如果 Agent 进行了多次检索和推理最终答案必须仍然能追溯到证据。这些风险决定了Agentic RAG 必须有边界和日志。不能只让 Agent 自由行动。一个可落地的 Agentic RAG 流程一个更可控的 Agentic RAG 流程可以这样设计用户任务 ↓ 任务分类 ↓ 判断是否需要检索 ↓ 生成检索计划 ↓ 选择知识源或工具 ↓ 执行检索 ↓ 评估结果是否足够 ↓ 必要时继续检索 ↓ 整理证据 ↓ 生成答案其中几个环节特别重要。第一任务分类。先判断这是简单问答、排障、对比、总结、追问还是资料不足。第二检索计划。不要让 Agent 直接乱查。可以要求它输出需要查什么 为什么查 使用哪个知识源 预期找到什么第三工具选择。不同知识源要有明确用途。比如制度库查制度和流程 接口文档库查接口参数和错误码 故障案例库查历史排障经验 图谱工具查实体关系和影响路径第四结果评估。Agent 要判断资料是否足够支撑答案。第五停止条件。必须限制最大检索轮数。第六证据整理。最终答案不能只给结论还要说明依据。日志和可观测性必须做好Agentic RAG 的调试难度比普通 RAG 高很多。所以日志非常关键。至少应该记录用户原始任务 任务分类结果 Agent 的检索计划 每次检索的查询 使用的知识源 每次检索返回的资料 Agent 对结果的判断 是否继续检索 停止原因 最终上下文 Prompt 版本 最终答案 引用来源如果答案错了需要知道错在哪里。可能是任务分类错了。可能是工具选错了。可能是查询写偏了。可能是检索结果没召回。可能是 Agent 误判资料足够。也可能是 Prompt 没约束住模型。没有日志Agentic RAG 很难上线。因为它的行为不是固定链路而是动态决策。动态决策必须可追踪。如何控制 Agentic RAG 不失控落地 Agentic RAG 时要给 Agent 设置边界。第一限制检索轮数。比如最多检索 3 轮。第二限制每轮候选数量。避免一次拿太多资料。第三限制可用工具。不同用户、不同任务只能访问允许的工具。第四要求每次检索说明理由。如果 Agent 不知道为什么查就不应该查。第五要求基于证据回答。即使是 Agentic RAG最终也不能脱离资料自由发挥。第六资料不足时允许停止。不要为了给答案而无限检索。第七对高风险任务设置人工确认。比如涉及权限、删除、发布、审批等操作时不能让 Agent 自动执行。这些边界会让 Agentic RAG 更像工程系统而不是一个不受控的自动循环。Agentic RAG 和 GraphRAG 可以结合吗可以。GraphRAG 提供的是图谱检索能力。Agentic RAG 提供的是动态决策能力。两者可以组合。比如用户问如果支付系统异常会影响哪些业务流程应该先通知哪些团队Agent 可以这样规划第一步使用 GraphRAG 查询支付系统的依赖关系。 第二步查询支付系统影响的业务流程。 第三步查询相关系统负责人或维护团队。 第四步整理影响范围和通知清单。这里 GraphRAG 是工具。Agentic RAG 决定什么时候调用这个工具以及是否继续查其他资料。一个组合链路可以是用户任务 ↓ Agent 规划 ↓ 普通 RAG / GraphRAG / 关键词检索 ↓ Agent 判断资料是否足够 ↓ 必要时继续检索 ↓ 基于证据生成答案所以 GraphRAG 和 Agentic RAG 不是替代关系。GraphRAG 解决知识结构问题。Agentic RAG 解决任务流程动态决策问题。怎么评估 Agentic RAGAgentic RAG 不能只看回答是否流畅。要评估整个过程。第一是否正确判断需要检索。有些问题不需要检索有些问题必须检索。第二是否选择了正确知识源。接口问题应该查接口文档制度问题应该查制度库。第三检索计划是否合理。计划要覆盖任务关键点不能偏离用户问题。第四是否能在资料不足时继续检索。第五是否能在资料仍不足时停止并说明原因。第六最终答案是否基于证据。第七延迟和成本是否可接受。可以准备一组测试任务简单事实问题 复杂排障问题 多轮上下文问题 对比分析问题 资料不足问题 跨知识源问题 权限边界问题分别观察 Agent 的行为。评估重点不是它“看起来聪不聪明”。而是它是否稳定、可控、可解释。落地建议如果你准备做 Agentic RAG可以按下面顺序推进。第一先把基础 RAG 做稳。文档解析、切分、检索、Rerank、Prompt 和引用来源要先可用。第二先限定场景。不要一开始做万能 Agent。可以先从排障问答、制度对比或多轮知识库助手开始。第三定义工具边界。每个工具能做什么不能做什么要清楚。第四限制检索轮数。先从 2 到 3 轮开始。第五要求 Agent 输出检索理由。便于审计和排查。第六记录完整链路日志。没有日志就不要上线复杂 Agentic RAG。第七建立测试集。用真实任务评估 Agent 的决策质量。第八资料不足时允许追问或停止。不要强行给答案。总结传统 RAG 是固定流程适合目标明确的知识库问答。Agentic RAG 则让 Agent 根据任务状态动态决定是否检索、检索什么、是否继续检索以及什么时候停止。它的核心不是把 Agent 和 RAG 两个概念简单拼接而是把 Retriever 变成 Agent 可以调度的工具。Agentic RAG 适合复杂排障、多轮对话、跨知识源检索、分析型任务和工作流型任务。但它也带来更高的复杂度、成本和风险。检索循环、工具选择错误、查询漂移、权限问题和可观测性不足都会影响系统稳定性。所以 Agentic RAG 必须有边界。它需要明确的工具定义、检索轮数限制、停止条件、权限控制和完整日志。从工程角度看Agentic RAG 不是让模型自由行动而是让模型在受控边界内做动态检索决策。下一篇文章可以继续讨论 RAG 系统怎么评测。因为无论是普通 RAG、GraphRAG 还是 Agentic RAG最终都不能只靠“看起来还不错”来判断质量。
Agentic RAG 是什么？让 Agent 决定什么时候检索
上一篇文章里我们讨论了 GraphRAG。GraphRAG 解决的是普通 RAG 在实体关系、跨文档关联和全局结构问题上的边界。它让系统不只是从 Chunk 里找相似片段也能利用实体、关系和图结构来回答问题。但 RAG 继续往真实应用里走还会遇到另一类问题不是知识结构复杂而是任务过程本身不固定。比如帮我判断这个客户问题应该查哪些资料。 先看一下这个报错可能和哪些配置有关再给我排查步骤。 如果资料不够你再继续查相关制度。 帮我比较这几个方案并说明每个结论依据来自哪里。这些问题不是一次检索就能稳定解决。系统需要先理解任务再决定是否检索、检索什么、是否继续检索以及什么时候停止。这就是 Agentic RAG 被讨论的原因。这篇文章就围绕一个问题展开Agentic RAG 是什么为什么要让 Agent 决定什么时候检索。传统 RAG 的流程是固定的传统 RAG 通常有一条比较固定的链路。用户问题 ↓ 检索资料 ↓ Rerank ↓ 拼接 Prompt ↓ 大模型生成答案这个流程非常清晰。它适合很多知识库问答场景。比如试用期员工能不能休年假 ERR_1024 表示什么 POST /orders 的 quantity 参数是否必填 报销申请需要提前几天提交这些问题目标明确。系统知道要做什么先检索再回答。但是在真实 AI 应用里很多用户问题并不是这么标准。用户可能不是直接问一个事实而是提出一个任务。比如帮我分析这次接口报错可能是什么原因。这个任务可能需要查接口文档。查错误码说明。查权限配置说明。查历史故障案例。判断资料是否足够。必要时继续检索。如果仍然套用固定流程用户问题 - 检索一次 - 回答系统很容易只查到一部分资料然后给出不完整答案。这就是传统 RAG 的局限。它把检索看成固定步骤。但真实任务里检索可能是一个需要动态决策的过程。Agentic RAG 到底是什么Agentic RAG 可以理解为让 Agent 根据任务状态动态决定如何使用检索能力。在传统 RAG 里Retriever 是流程中的一个固定节点。在 Agentic RAG 里Retriever 更像是 Agent 可以调用的工具。Agent 会根据当前任务决定是否需要检索。检索哪个知识源。用什么查询去检索。检索结果是否足够。是否需要再次检索。是否需要换一种检索策略。什么时候可以停止检索并生成答案。一个简化流程是用户任务 ↓ Agent 理解任务 ↓ 判断是否需要检索 ↓ 调用 Retriever ↓ 阅读检索结果 ↓ 判断资料是否足够 ↓ 必要时继续检索 ↓ 生成最终答案这和传统 RAG 的区别在于传统 RAG 是固定链路。Agentic RAG 是动态决策。它不是简单把 Agent 和 RAG 两个词拼在一起。它的核心是把检索从固定步骤变成可被 Agent 调度的能力。为什么需要 Agent 决定是否检索并不是所有问题都需要检索。有些问题模型可以直接回答。比如Python 里的 list 和 tuple 有什么区别如果这是通用编程问答可能不需要查企业知识库。但有些问题必须检索。比如我们公司试用期员工能不能休年假这必须查内部制度。还有一些问题一开始不确定是否需要检索。比如这个报错是不是权限问题Agent 可能需要先判断用户说的“这个报错”有没有错误码是否提供了接口名是否有上下文记录需要查错误码还是权限文档如果问题缺信息Agent 可能不应该直接检索而应该追问。比如请补充具体错误码或接口名称这样才能判断是否和权限配置有关。所以是否检索本身就是一个决策。传统 RAG 默认每次都检索。Agentic RAG 则更灵活该检索时检索不该检索时追问或直接回答。Agent 如何决定检索什么Agentic RAG 的关键不只是决定“要不要检索”还包括决定“检索什么”。比如用户问订单创建接口返回 403应该怎么排查这句话里包含几个潜在检索方向订单创建接口文档 403 错误码说明 接口鉴权规则 token 过期处理 权限配置说明 历史故障案例传统 RAG 可能只用原始问题检索一次。Agentic RAG 可以先规划第一步查询订单创建接口的鉴权要求。 第二步查询 403 错误码含义。 第三步查询权限配置和 token 相关说明。 第四步如果资料足够再生成排查步骤。这个过程更像任务执行。Agent 需要把用户问题拆成检索计划。再比如用户问帮我比较新旧报销制度的差异。Agent 不能只检索“报销制度差异”。它可能需要查新版本报销制度 查旧版本报销制度 提取申请条件 提取审批流程 提取额度规则 比较差异 引用来源这里的检索是为任务服务的。Agent 先理解任务再生成检索动作。这就是 Agentic RAG 和普通检索增强问答的差别。检索结果不够时Agent 应该继续查传统 RAG 通常只检索一次。如果召回内容不完整模型可能会硬答。Agentic RAG 更强调反馈循环。比如第一次检索后Agent 可以判断当前资料只说明了错误码含义没有说明排查步骤。于是继续检索查询403 错误 排查步骤 权限配置再比如第一次检索只找到了新制度没有找到旧制度。Agent 可以继续查查询报销制度 历史版本 2025这个过程可以表示为检索 ↓ 阅读结果 ↓ 判断是否足够 ↓ 不足则继续检索 ↓ 足够则回答这就是 Agentic RAG 的重要能力。它不把检索看成一次性动作而是看成可迭代过程。但这里也要注意继续检索不是无限检索。Agent 必须有停止条件。比如已经找到足够证据。检索次数达到上限。连续两次没有新增有效信息。资料冲突无法消解。需要用户补充信息。没有停止条件Agentic RAG 很容易进入检索循环。Agentic RAG 和 Multi-hop Retrieval 有什么区别第 9 篇文章里我们讨论过 Multi-hop Retrieval。它也是多步检索。那它和 Agentic RAG 有什么区别可以这样理解Multi-hop Retrieval 更像一种预设策略。比如第一步查实体 第二步查实体相关属性 第三步合成答案它通常适合结构比较明确的问题。比如负责 Alpha 系统的部门有哪些审批权限可以先查 Alpha 系统归属部门再查该部门审批权限。Agentic RAG 更强调动态决策。它不一定提前知道要查几步。Agent 会根据每一步结果决定下一步。比如第一次检索发现资料不足 - 再查 第二次检索发现有冲突 - 查版本信息 第三次检索仍无法判断 - 说明资料冲突并停止所以两者不是对立关系。Multi-hop Retrieval 可以是 Agentic RAG 里的一个检索策略。Agentic RAG 的范围更大。它包括任务理解、工具选择、检索计划、结果反思、继续检索和停止判断。Agentic RAG 适合什么场景Agentic RAG 不一定适合所有知识库问答。它更适合任务过程不固定的场景。第一类是复杂排障。比如这个接口报错可能是什么原因应该怎么查它可能需要查错误码、接口文档、权限规则、配置项和历史案例。第二类是多轮对话。比如用户先问制度再追问那如果是上海员工呢 旧版本是不是不一样 这个流程谁审批Agent 需要结合上下文决定检索方向。第三类是资料不足时需要继续探索。比如第一次检索没有找到明确依据Agent 可以换查询或查其他知识源。第四类是需要选择不同工具。比如有多个知识源制度库 接口文档库 故障案例库 代码仓库说明 数据库字段字典Agent 可以根据问题选择工具。第五类是需要生成分析型结果。比如帮我比较三个方案的风险和依据。这不是简单问答而是需要查资料、整理证据、比较和输出结构化结论。第六类是工作流型任务。比如帮我根据知识库生成一份排查清单。Agent 需要分步骤完成任务。这些场景里固定 RAG 链路会显得太死。Agentic RAG 能给系统更多主动性。Agentic RAG 不适合什么场景Agentic RAG 有价值但也不应该滥用。第一简单事实问答不需要。比如ERR_1024 表示什么直接关键词检索可能更快、更稳。第二强实时低延迟场景要谨慎。Agentic RAG 可能多次调用模型和检索工具。延迟和成本都会上升。第三高风险确定性场景要谨慎。如果系统必须严格按固定流程执行Agent 的动态决策可能带来不可控行为。第四缺少日志和可观测性时不要急着上。Agentic RAG 链路更复杂。如果没有记录中间决策很难排查为什么它查了这个、不查那个。第五权限边界不清楚时不要上。Agent 会动态选择工具和知识源。如果权限过滤不严格可能造成越权检索。第六基础 RAG 还没做好时不要上。如果文档切分、检索、Rerank、Prompt 都不稳定Agentic RAG 只会把不稳定放大。所以 Agentic RAG 不是高级版万能药。它是在基础 RAG 能力稳定之后为复杂任务引入动态决策。Agentic RAG 的风险Agentic RAG 最大的问题是复杂性上升。风险主要有几个。第一检索循环。Agent 一直觉得资料不够一直继续检索。这会导致延迟和成本失控。第二错误反思。Agent 可能误判检索结果不够或者误判已经足够。第三错误工具选择。比如本来应该查接口文档它却查了制度库。第四查询漂移。多轮检索中查询逐渐偏离用户原始问题。第五权限风险。Agent 动态选择知识源时必须严格执行用户权限。第六可观测性变差。传统 RAG 只要看一次检索结果。Agentic RAG 要看每一步计划、工具调用、检索结果和停止理由。第七答案责任边界模糊。如果 Agent 进行了多次检索和推理最终答案必须仍然能追溯到证据。这些风险决定了Agentic RAG 必须有边界和日志。不能只让 Agent 自由行动。一个可落地的 Agentic RAG 流程一个更可控的 Agentic RAG 流程可以这样设计用户任务 ↓ 任务分类 ↓ 判断是否需要检索 ↓ 生成检索计划 ↓ 选择知识源或工具 ↓ 执行检索 ↓ 评估结果是否足够 ↓ 必要时继续检索 ↓ 整理证据 ↓ 生成答案其中几个环节特别重要。第一任务分类。先判断这是简单问答、排障、对比、总结、追问还是资料不足。第二检索计划。不要让 Agent 直接乱查。可以要求它输出需要查什么 为什么查 使用哪个知识源 预期找到什么第三工具选择。不同知识源要有明确用途。比如制度库查制度和流程 接口文档库查接口参数和错误码 故障案例库查历史排障经验 图谱工具查实体关系和影响路径第四结果评估。Agent 要判断资料是否足够支撑答案。第五停止条件。必须限制最大检索轮数。第六证据整理。最终答案不能只给结论还要说明依据。日志和可观测性必须做好Agentic RAG 的调试难度比普通 RAG 高很多。所以日志非常关键。至少应该记录用户原始任务 任务分类结果 Agent 的检索计划 每次检索的查询 使用的知识源 每次检索返回的资料 Agent 对结果的判断 是否继续检索 停止原因 最终上下文 Prompt 版本 最终答案 引用来源如果答案错了需要知道错在哪里。可能是任务分类错了。可能是工具选错了。可能是查询写偏了。可能是检索结果没召回。可能是 Agent 误判资料足够。也可能是 Prompt 没约束住模型。没有日志Agentic RAG 很难上线。因为它的行为不是固定链路而是动态决策。动态决策必须可追踪。如何控制 Agentic RAG 不失控落地 Agentic RAG 时要给 Agent 设置边界。第一限制检索轮数。比如最多检索 3 轮。第二限制每轮候选数量。避免一次拿太多资料。第三限制可用工具。不同用户、不同任务只能访问允许的工具。第四要求每次检索说明理由。如果 Agent 不知道为什么查就不应该查。第五要求基于证据回答。即使是 Agentic RAG最终也不能脱离资料自由发挥。第六资料不足时允许停止。不要为了给答案而无限检索。第七对高风险任务设置人工确认。比如涉及权限、删除、发布、审批等操作时不能让 Agent 自动执行。这些边界会让 Agentic RAG 更像工程系统而不是一个不受控的自动循环。Agentic RAG 和 GraphRAG 可以结合吗可以。GraphRAG 提供的是图谱检索能力。Agentic RAG 提供的是动态决策能力。两者可以组合。比如用户问如果支付系统异常会影响哪些业务流程应该先通知哪些团队Agent 可以这样规划第一步使用 GraphRAG 查询支付系统的依赖关系。 第二步查询支付系统影响的业务流程。 第三步查询相关系统负责人或维护团队。 第四步整理影响范围和通知清单。这里 GraphRAG 是工具。Agentic RAG 决定什么时候调用这个工具以及是否继续查其他资料。一个组合链路可以是用户任务 ↓ Agent 规划 ↓ 普通 RAG / GraphRAG / 关键词检索 ↓ Agent 判断资料是否足够 ↓ 必要时继续检索 ↓ 基于证据生成答案所以 GraphRAG 和 Agentic RAG 不是替代关系。GraphRAG 解决知识结构问题。Agentic RAG 解决任务流程动态决策问题。怎么评估 Agentic RAGAgentic RAG 不能只看回答是否流畅。要评估整个过程。第一是否正确判断需要检索。有些问题不需要检索有些问题必须检索。第二是否选择了正确知识源。接口问题应该查接口文档制度问题应该查制度库。第三检索计划是否合理。计划要覆盖任务关键点不能偏离用户问题。第四是否能在资料不足时继续检索。第五是否能在资料仍不足时停止并说明原因。第六最终答案是否基于证据。第七延迟和成本是否可接受。可以准备一组测试任务简单事实问题 复杂排障问题 多轮上下文问题 对比分析问题 资料不足问题 跨知识源问题 权限边界问题分别观察 Agent 的行为。评估重点不是它“看起来聪不聪明”。而是它是否稳定、可控、可解释。落地建议如果你准备做 Agentic RAG可以按下面顺序推进。第一先把基础 RAG 做稳。文档解析、切分、检索、Rerank、Prompt 和引用来源要先可用。第二先限定场景。不要一开始做万能 Agent。可以先从排障问答、制度对比或多轮知识库助手开始。第三定义工具边界。每个工具能做什么不能做什么要清楚。第四限制检索轮数。先从 2 到 3 轮开始。第五要求 Agent 输出检索理由。便于审计和排查。第六记录完整链路日志。没有日志就不要上线复杂 Agentic RAG。第七建立测试集。用真实任务评估 Agent 的决策质量。第八资料不足时允许追问或停止。不要强行给答案。总结传统 RAG 是固定流程适合目标明确的知识库问答。Agentic RAG 则让 Agent 根据任务状态动态决定是否检索、检索什么、是否继续检索以及什么时候停止。它的核心不是把 Agent 和 RAG 两个概念简单拼接而是把 Retriever 变成 Agent 可以调度的工具。Agentic RAG 适合复杂排障、多轮对话、跨知识源检索、分析型任务和工作流型任务。但它也带来更高的复杂度、成本和风险。检索循环、工具选择错误、查询漂移、权限问题和可观测性不足都会影响系统稳定性。所以 Agentic RAG 必须有边界。它需要明确的工具定义、检索轮数限制、停止条件、权限控制和完整日志。从工程角度看Agentic RAG 不是让模型自由行动而是让模型在受控边界内做动态检索决策。下一篇文章可以继续讨论 RAG 系统怎么评测。因为无论是普通 RAG、GraphRAG 还是 Agentic RAG最终都不能只靠“看起来还不错”来判断质量。Agentic RAG 是什么让 Agent 决定什么时候检索上一篇文章里我们讨论了 GraphRAG。GraphRAG 解决的是普通 RAG 在实体关系、跨文档关联和全局结构问题上的边界。它让系统不只是从 Chunk 里找相似片段也能利用实体、关系和图结构来回答问题。但 RAG 继续往真实应用里走还会遇到另一类问题不是知识结构复杂而是任务过程本身不固定。比如帮我判断这个客户问题应该查哪些资料。 先看一下这个报错可能和哪些配置有关再给我排查步骤。 如果资料不够你再继续查相关制度。 帮我比较这几个方案并说明每个结论依据来自哪里。这些问题不是一次检索就能稳定解决。系统需要先理解任务再决定是否检索、检索什么、是否继续检索以及什么时候停止。这就是 Agentic RAG 被讨论的原因。这篇文章就围绕一个问题展开Agentic RAG 是什么为什么要让 Agent 决定什么时候检索。传统 RAG 的流程是固定的传统 RAG 通常有一条比较固定的链路。用户问题 ↓ 检索资料 ↓ Rerank ↓ 拼接 Prompt ↓ 大模型生成答案这个流程非常清晰。它适合很多知识库问答场景。比如试用期员工能不能休年假 ERR_1024 表示什么 POST /orders 的 quantity 参数是否必填 报销申请需要提前几天提交这些问题目标明确。系统知道要做什么先检索再回答。但是在真实 AI 应用里很多用户问题并不是这么标准。用户可能不是直接问一个事实而是提出一个任务。比如帮我分析这次接口报错可能是什么原因。这个任务可能需要查接口文档。查错误码说明。查权限配置说明。查历史故障案例。判断资料是否足够。必要时继续检索。如果仍然套用固定流程用户问题 - 检索一次 - 回答系统很容易只查到一部分资料然后给出不完整答案。这就是传统 RAG 的局限。它把检索看成固定步骤。但真实任务里检索可能是一个需要动态决策的过程。Agentic RAG 到底是什么Agentic RAG 可以理解为让 Agent 根据任务状态动态决定如何使用检索能力。在传统 RAG 里Retriever 是流程中的一个固定节点。在 Agentic RAG 里Retriever 更像是 Agent 可以调用的工具。Agent 会根据当前任务决定是否需要检索。检索哪个知识源。用什么查询去检索。检索结果是否足够。是否需要再次检索。是否需要换一种检索策略。什么时候可以停止检索并生成答案。一个简化流程是用户任务 ↓ Agent 理解任务 ↓ 判断是否需要检索 ↓ 调用 Retriever ↓ 阅读检索结果 ↓ 判断资料是否足够 ↓ 必要时继续检索 ↓ 生成最终答案这和传统 RAG 的区别在于传统 RAG 是固定链路。Agentic RAG 是动态决策。它不是简单把 Agent 和 RAG 两个词拼在一起。它的核心是把检索从固定步骤变成可被 Agent 调度的能力。为什么需要 Agent 决定是否检索并不是所有问题都需要检索。有些问题模型可以直接回答。比如Python 里的 list 和 tuple 有什么区别如果这是通用编程问答可能不需要查企业知识库。但有些问题必须检索。比如我们公司试用期员工能不能休年假这必须查内部制度。还有一些问题一开始不确定是否需要检索。比如这个报错是不是权限问题Agent 可能需要先判断用户说的“这个报错”有没有错误码是否提供了接口名是否有上下文记录需要查错误码还是权限文档如果问题缺信息Agent 可能不应该直接检索而应该追问。比如请补充具体错误码或接口名称这样才能判断是否和权限配置有关。所以是否检索本身就是一个决策。传统 RAG 默认每次都检索。Agentic RAG 则更灵活该检索时检索不该检索时追问或直接回答。Agent 如何决定检索什么Agentic RAG 的关键不只是决定“要不要检索”还包括决定“检索什么”。比如用户问订单创建接口返回 403应该怎么排查这句话里包含几个潜在检索方向订单创建接口文档 403 错误码说明 接口鉴权规则 token 过期处理 权限配置说明 历史故障案例传统 RAG 可能只用原始问题检索一次。Agentic RAG 可以先规划第一步查询订单创建接口的鉴权要求。 第二步查询 403 错误码含义。 第三步查询权限配置和 token 相关说明。 第四步如果资料足够再生成排查步骤。这个过程更像任务执行。Agent 需要把用户问题拆成检索计划。再比如用户问帮我比较新旧报销制度的差异。Agent 不能只检索“报销制度差异”。它可能需要查新版本报销制度 查旧版本报销制度 提取申请条件 提取审批流程 提取额度规则 比较差异 引用来源这里的检索是为任务服务的。Agent 先理解任务再生成检索动作。这就是 Agentic RAG 和普通检索增强问答的差别。检索结果不够时Agent 应该继续查传统 RAG 通常只检索一次。如果召回内容不完整模型可能会硬答。Agentic RAG 更强调反馈循环。比如第一次检索后Agent 可以判断当前资料只说明了错误码含义没有说明排查步骤。于是继续检索查询403 错误 排查步骤 权限配置再比如第一次检索只找到了新制度没有找到旧制度。Agent 可以继续查查询报销制度 历史版本 2025这个过程可以表示为检索 ↓ 阅读结果 ↓ 判断是否足够 ↓ 不足则继续检索 ↓ 足够则回答这就是 Agentic RAG 的重要能力。它不把检索看成一次性动作而是看成可迭代过程。但这里也要注意继续检索不是无限检索。Agent 必须有停止条件。比如已经找到足够证据。检索次数达到上限。连续两次没有新增有效信息。资料冲突无法消解。需要用户补充信息。没有停止条件Agentic RAG 很容易进入检索循环。Agentic RAG 和 Multi-hop Retrieval 有什么区别第 9 篇文章里我们讨论过 Multi-hop Retrieval。它也是多步检索。那它和 Agentic RAG 有什么区别可以这样理解Multi-hop Retrieval 更像一种预设策略。比如第一步查实体 第二步查实体相关属性 第三步合成答案它通常适合结构比较明确的问题。比如负责 Alpha 系统的部门有哪些审批权限可以先查 Alpha 系统归属部门再查该部门审批权限。Agentic RAG 更强调动态决策。它不一定提前知道要查几步。Agent 会根据每一步结果决定下一步。比如第一次检索发现资料不足 - 再查 第二次检索发现有冲突 - 查版本信息 第三次检索仍无法判断 - 说明资料冲突并停止所以两者不是对立关系。Multi-hop Retrieval 可以是 Agentic RAG 里的一个检索策略。Agentic RAG 的范围更大。它包括任务理解、工具选择、检索计划、结果反思、继续检索和停止判断。Agentic RAG 适合什么场景Agentic RAG 不一定适合所有知识库问答。它更适合任务过程不固定的场景。第一类是复杂排障。比如这个接口报错可能是什么原因应该怎么查它可能需要查错误码、接口文档、权限规则、配置项和历史案例。第二类是多轮对话。比如用户先问制度再追问那如果是上海员工呢 旧版本是不是不一样 这个流程谁审批Agent 需要结合上下文决定检索方向。第三类是资料不足时需要继续探索。比如第一次检索没有找到明确依据Agent 可以换查询或查其他知识源。第四类是需要选择不同工具。比如有多个知识源制度库 接口文档库 故障案例库 代码仓库说明 数据库字段字典Agent 可以根据问题选择工具。第五类是需要生成分析型结果。比如帮我比较三个方案的风险和依据。这不是简单问答而是需要查资料、整理证据、比较和输出结构化结论。第六类是工作流型任务。比如帮我根据知识库生成一份排查清单。Agent 需要分步骤完成任务。这些场景里固定 RAG 链路会显得太死。Agentic RAG 能给系统更多主动性。Agentic RAG 不适合什么场景Agentic RAG 有价值但也不应该滥用。第一简单事实问答不需要。比如ERR_1024 表示什么直接关键词检索可能更快、更稳。第二强实时低延迟场景要谨慎。Agentic RAG 可能多次调用模型和检索工具。延迟和成本都会上升。第三高风险确定性场景要谨慎。如果系统必须严格按固定流程执行Agent 的动态决策可能带来不可控行为。第四缺少日志和可观测性时不要急着上。Agentic RAG 链路更复杂。如果没有记录中间决策很难排查为什么它查了这个、不查那个。第五权限边界不清楚时不要上。Agent 会动态选择工具和知识源。如果权限过滤不严格可能造成越权检索。第六基础 RAG 还没做好时不要上。如果文档切分、检索、Rerank、Prompt 都不稳定Agentic RAG 只会把不稳定放大。所以 Agentic RAG 不是高级版万能药。它是在基础 RAG 能力稳定之后为复杂任务引入动态决策。Agentic RAG 的风险Agentic RAG 最大的问题是复杂性上升。风险主要有几个。第一检索循环。Agent 一直觉得资料不够一直继续检索。这会导致延迟和成本失控。第二错误反思。Agent 可能误判检索结果不够或者误判已经足够。第三错误工具选择。比如本来应该查接口文档它却查了制度库。第四查询漂移。多轮检索中查询逐渐偏离用户原始问题。第五权限风险。Agent 动态选择知识源时必须严格执行用户权限。第六可观测性变差。传统 RAG 只要看一次检索结果。Agentic RAG 要看每一步计划、工具调用、检索结果和停止理由。第七答案责任边界模糊。如果 Agent 进行了多次检索和推理最终答案必须仍然能追溯到证据。这些风险决定了Agentic RAG 必须有边界和日志。不能只让 Agent 自由行动。一个可落地的 Agentic RAG 流程一个更可控的 Agentic RAG 流程可以这样设计用户任务 ↓ 任务分类 ↓ 判断是否需要检索 ↓ 生成检索计划 ↓ 选择知识源或工具 ↓ 执行检索 ↓ 评估结果是否足够 ↓ 必要时继续检索 ↓ 整理证据 ↓ 生成答案其中几个环节特别重要。第一任务分类。先判断这是简单问答、排障、对比、总结、追问还是资料不足。第二检索计划。不要让 Agent 直接乱查。可以要求它输出需要查什么 为什么查 使用哪个知识源 预期找到什么第三工具选择。不同知识源要有明确用途。比如制度库查制度和流程 接口文档库查接口参数和错误码 故障案例库查历史排障经验 图谱工具查实体关系和影响路径第四结果评估。Agent 要判断资料是否足够支撑答案。第五停止条件。必须限制最大检索轮数。第六证据整理。最终答案不能只给结论还要说明依据。日志和可观测性必须做好Agentic RAG 的调试难度比普通 RAG 高很多。所以日志非常关键。至少应该记录用户原始任务 任务分类结果 Agent 的检索计划 每次检索的查询 使用的知识源 每次检索返回的资料 Agent 对结果的判断 是否继续检索 停止原因 最终上下文 Prompt 版本 最终答案 引用来源如果答案错了需要知道错在哪里。可能是任务分类错了。可能是工具选错了。可能是查询写偏了。可能是检索结果没召回。可能是 Agent 误判资料足够。也可能是 Prompt 没约束住模型。没有日志Agentic RAG 很难上线。因为它的行为不是固定链路而是动态决策。动态决策必须可追踪。如何控制 Agentic RAG 不失控落地 Agentic RAG 时要给 Agent 设置边界。第一限制检索轮数。比如最多检索 3 轮。第二限制每轮候选数量。避免一次拿太多资料。第三限制可用工具。不同用户、不同任务只能访问允许的工具。第四要求每次检索说明理由。如果 Agent 不知道为什么查就不应该查。第五要求基于证据回答。即使是 Agentic RAG最终也不能脱离资料自由发挥。第六资料不足时允许停止。不要为了给答案而无限检索。第七对高风险任务设置人工确认。比如涉及权限、删除、发布、审批等操作时不能让 Agent 自动执行。这些边界会让 Agentic RAG 更像工程系统而不是一个不受控的自动循环。Agentic RAG 和 GraphRAG 可以结合吗可以。GraphRAG 提供的是图谱检索能力。Agentic RAG 提供的是动态决策能力。两者可以组合。比如用户问如果支付系统异常会影响哪些业务流程应该先通知哪些团队Agent 可以这样规划第一步使用 GraphRAG 查询支付系统的依赖关系。 第二步查询支付系统影响的业务流程。 第三步查询相关系统负责人或维护团队。 第四步整理影响范围和通知清单。这里 GraphRAG 是工具。Agentic RAG 决定什么时候调用这个工具以及是否继续查其他资料。一个组合链路可以是用户任务 ↓ Agent 规划 ↓ 普通 RAG / GraphRAG / 关键词检索 ↓ Agent 判断资料是否足够 ↓ 必要时继续检索 ↓ 基于证据生成答案所以 GraphRAG 和 Agentic RAG 不是替代关系。GraphRAG 解决知识结构问题。Agentic RAG 解决任务流程动态决策问题。怎么评估 Agentic RAGAgentic RAG 不能只看回答是否流畅。要评估整个过程。第一是否正确判断需要检索。有些问题不需要检索有些问题必须检索。第二是否选择了正确知识源。接口问题应该查接口文档制度问题应该查制度库。第三检索计划是否合理。计划要覆盖任务关键点不能偏离用户问题。第四是否能在资料不足时继续检索。第五是否能在资料仍不足时停止并说明原因。第六最终答案是否基于证据。第七延迟和成本是否可接受。可以准备一组测试任务简单事实问题 复杂排障问题 多轮上下文问题 对比分析问题 资料不足问题 跨知识源问题 权限边界问题分别观察 Agent 的行为。评估重点不是它“看起来聪不聪明”。而是它是否稳定、可控、可解释。落地建议如果你准备做 Agentic RAG可以按下面顺序推进。第一先把基础 RAG 做稳。文档解析、切分、检索、Rerank、Prompt 和引用来源要先可用。第二先限定场景。不要一开始做万能 Agent。可以先从排障问答、制度对比或多轮知识库助手开始。第三定义工具边界。每个工具能做什么不能做什么要清楚。第四限制检索轮数。先从 2 到 3 轮开始。第五要求 Agent 输出检索理由。便于审计和排查。第六记录完整链路日志。没有日志就不要上线复杂 Agentic RAG。第七建立测试集。用真实任务评估 Agent 的决策质量。第八资料不足时允许追问或停止。不要强行给答案。总结传统 RAG 是固定流程适合目标明确的知识库问答。Agentic RAG 则让 Agent 根据任务状态动态决定是否检索、检索什么、是否继续检索以及什么时候停止。它的核心不是把 Agent 和 RAG 两个概念简单拼接而是把 Retriever 变成 Agent 可以调度的工具。Agentic RAG 适合复杂排障、多轮对话、跨知识源检索、分析型任务和工作流型任务。但它也带来更高的复杂度、成本和风险。检索循环、工具选择错误、查询漂移、权限问题和可观测性不足都会影响系统稳定性。所以 Agentic RAG 必须有边界。它需要明确的工具定义、检索轮数限制、停止条件、权限控制和完整日志。从工程角度看Agentic RAG 不是让模型自由行动而是让模型在受控边界内做动态检索决策。下一篇文章可以继续讨论 RAG 系统怎么评测。因为无论是普通 RAG、GraphRAG 还是 Agentic RAG最终都不能只靠“看起来还不错”来判断质量。
