1. 检索管道的天花板一次查询解决不了连锁问题做了一段时间 RAG 应用的人多半都会遇到同一个尴尬时刻知识库文档放得挺全向量检索的召回率调得也不算差但面对稍微复杂一点的问题系统就开始答非所问。比如用户问这家公司过去三年营收变化趋势如何主要受哪些因素影响传统 RAG 的做法是把它当成一个查询去库里捞几段最相似的文本拼在一起交给大模型。结果往往是营收数字捞到了但影响因素那部分上下文缺失模型只能靠自己的常识硬编或者干脆答偏。问题的根源在于传统 RAG 本质上是一条直线管道Embedding 召回 → Top-K 拼接 → LLM 生成。它默认一次检索就能拿到生成所需的全部信息但真实场景里用户的问题往往要拆成多个子问题、依赖多轮检索、需要对比多个文档、甚至要调用外部工具补充数据。直线管道没有规划这一步模型不知道先查什么、再查什么、查到的信息够不够、要不要换个角度再查一次。Agentic RAG 想解决的正是这个管道思维的瓶颈。它把检索生成从单次函数调用升级成多步决策闭环——系统不再被动等着用户给一个 query而是像一个有检索权限的智能体一样先拆解任务、制定检索计划、执行检索、评估结果是否足够回答问题不够就再检索、再分析直到信息充分才进入生成阶段。用大白话说传统 RAG 是你问一句我去库房搬一次货Agentic RAG 是我问清楚你要什么、分几趟搬、每次搬完检查一下货齐不齐实在缺货我还能去隔壁仓库调货。这篇文章不是概念科普是我把 Agentic RAG 从论文、开源项目一路拆到实际落地之后的经验整理。适合两类人看一是做 RAG 应用但总觉得效果天花板明显、想往上突破的开发者二是正在选技术路线想知道 Agentic RAG 到底比经典 RAG 强在哪、值不值得投入改造的架构决策者。我会把架构设计、核心能力拆解、代码实现路径、以及生产环境中那些文档里不会写的坑全部摊开讲。2. 从直线管道到决策环路架构到底变了什么2.1 经典 RAG 的路由过程先对齐一下基线。经典 RAG 的链路是固定的用户 query 进来经过 embedding 模型转成向量去向量库做相似度检索取回 Top-K 条文本块拼进 prompt交给 LLM 生成答案。整个过程没有任何分支判断也没有反馈机制。这套结构在问题简单、知识库垂直的场景下够用。比如XX 产品的退货政策是什么一个 query 就能命中不需要二次检索。但一旦问题涉及多跳推理——比如某型号设备在北方冬季的故障率为什么比南方高——模型需要先知道设备型号对应的技术参数再关联到环境温度对零部件的影响最后结合售后维修记录才能给出可信答案。这三个信息分布在知识库的不同区域靠一次相似度检索很难全部捞回来而直线管道没有发现缺哪块信息、再去补查的能力。2.2 Agentic RAG 的三个新增抽象Agentic RAG 没有推翻 RAG 的检索生成内核而是在外面加了一层代理决策机制。拆开看它引入了三个经典 RAG 没有的组件规划器Planner。负责把用户 query 拆解成可执行的检索子任务。拆解粒度根据任务复杂度动态调整简单问题一步完成复杂问题拆成多步子目标。这个组件通常由 LLM 充当核心是让模型以需要哪些信息才能回答这个问题的视角进行任务分解而不是直接把用户原话丢给检索器。执行器Executor。根据规划器的子任务确定调用哪个工具、传什么参数。工具可以是向量库检索、SQL 查询、HTTP API 调用甚至是另一个小模型的输出。这一步的关键是工具选择和参数构造都要由模型自主完成而不是代码里写死。评估器Evaluator。每执行完一步评估当前收集的信息是否足够支撑最终答案。不够就反馈给规划器补一步检索够了才进入生成阶段。这一环节是 Agentic RAG 与传统 RAG 最本质的区别——它把信息是否充分的判断从人转移到了系统本身。三个组件串起来就形成了一个 ReAct 模式的循环Reason思考缺什么信息→ Act执行检索→ Observe观察检索结果→ 再 Reason判断够不够不够继续。循环终止条件是评估器判定信息完备或者达到预设的最大步数。2.3 一个具体的控制流程示例拿前面那个某型号设备北方冬季故障率为什么偏高的问题举例Agentic RAG 的执行路径大概是规划器拆解出三个子任务检索设备型号的技术规格、检索北方环境条件下的零部件故障记录、检索该型号的售后维修统计报告。执行器先查技术规格拿到设备适用的温度范围。评估器发现温度范围和故障率之间还缺因果链——需要查环境温度对哪些零部件产生的应力超过设计余量。规划器补充第四个子任务检索低温环境 零部件应力相关的技术文档或测试报告。执行器补查评估器确认信息链完整。进入生成阶段模型综合所有轮次收集的信息组织答案。对比经典 RAG 的一次性检索这个过程的检索次数多了但每一步都有明确的信息目标最终答案的准确率和可解释性都显著高于碰运气式的一次召回。3. 多步推理不是炫技检索规划背后的信息论逻辑3.1 为什么多步检索能提升准确率而不是引入噪音有人会质疑多步检索每步都可能引入噪音步数越多错误累积的风险不也越大吗这个担心有道理但前提是——如果检索是盲目的多步确实会累积噪音。Agentic RAG 的多步检索之所以有效关键在于每步都有信息缺口分析作为前提检索是有方向的不是撒网。信息论里有个概念叫互信息增量新的检索结果应该为目标答案的确定提供新增的信息量而不是重复已有信息。规划器拆解子任务时本质是在做这个问题的答案空间里目前哪些维度还是不确定的。每一个子任务瞄准一个不确定维度检索回来的内容就是在消除这个维度上的不确定性。拿实际例子来说用户问A 方案和 B 方案的适用场景有什么区别。经典 RAG 可能直接把方案介绍文档整体丢给模型模型面对一堆描述性文字容易把两者适用边界混淆。Agentic RAG 会把任务拆成A 方案的适用约束条件和B 方案的适用约束条件两个子问题分别检索、分别整理最后在生成阶段做对比。每个子问题的检索都在消除一个维度A/B 各自的边界条件上的不确定性比一次性捞到混合信息再让模型自己去辨析准确率高得多。3.2 子查询拆分方式分解、对比、验证实际落地时子查询的拆分模式大致有三种可以根据问题类型预置也可以让模型动态决定分解型拆分。适用于整体问题可以拆成多个独立子问题的场景。比如XX 项目的风险评估报告主要结论是什么拆成财务风险评估、技术风险评估、市场风险评估三个子查询结果汇总。这种拆分最简单本质是 AND 逻辑。对比型拆分。适用于需要比较两个或多个实体的异同的场景。比如RAG 和 Agentic RAG 的架构差异拆成RAG 的架构特征和Agentic RAG 的架构特征两个子查询生成阶段再做差异对比。这种拆分的要点是让两个子查询的检索范围尽量正交避免重复文本进入上下文。验证型拆分。适用于一个问题需要从多个证据源交叉验证的场景。比如某产品是否满足某项安全认证标准先查产品参数再查标准要求再查检测报告让多轮检索结果相互印证。这是消除幻觉的关键手段——单一来源的信息可能是模型编的多个独立来源的一致信息则可信得多。三种拆分不是互斥的复杂问题往往是三种模式的组合。我在实际项目中见过一个比较复杂的例子用户问对比开源和商业 RAG 方案在合规场景下的优劣势系统先分解成开源方案合规模块和商业方案合规模块两个子问题每个子问题内部又做验证型拆分查文档介绍、查合规认证、查实际案例最后在生成阶段做对比。整个检索过程跑了 6 轮但每一轮返回的信息都在最终答案里派上了用场没有一轮是浪费的。3.3 动态规划还是固定模板一个需要想清楚的取舍做规划器的时候有个路线选择用固定模板强制拆分还是让 LLM 完全自由规划。这两种方案我都在生产环境试过。固定模板方案的优点是稳定——预先定义好不同类型问题的拆分规则系统只按规则执行不会出现模型脑洞大开拆出无关子问题的情况。缺点是死板真实用户的问题千奇百怪预置规则很难覆盖所有情况漏掉的场景就只能回退到单次检索。自由规划的优点是灵活模型可以根据问题内容动态决定拆分方式。缺点是不可控——模型可能拆出 8 个子问题其中 3 个是无效的或者绕来绕去始终停在同一个信息维度上打转。我的建议是先上固定模板保证稳定性再逐步放开自由度。给模型搭一个问题类型分类器 拆分策略库的框架先判断问题属于分解型 / 对比型 / 验证型 / 简单直答型中的哪一类再按照对应策略生成子查询。这样既保留了动态规划的空间又不会完全失控。4. 让手够得着更多信息Agentic RAG 的工具调用设计4.1 检索只是工具之一向量库、数据库、外部 API 的统一调度Agentic RAG 的Retrieval不再局限于语义向量库它把获取信息这个动作泛化成了工具调用。规划器拆解出子任务后执行器要决定该用哪个工具来满足当前的信息需求。常见的工具类型至少有这么几种向量语义检索适合答案藏在长文本里、不知道关键词的场景比如产品文档、研究报告、企业内部知识库。SQL/结构化查询适合答案精确、有明确字段约束的场景比如上季度各区域销售额排名前三的产品数据在库里但语义检索答不出来。关键词/倒排索引检索适合精确匹配、专有名词、编号类查询比如设备型号、SKU、法规条款编号。很多工程团队会忽略这类 工具但它在垂直领域的命中率往往比向量检索还高。外部 API/实时数据适合时效性要求高的信息比如天气、股票行情、物流状态。知识库里没有的东西就调接口拿最新数据。代码解释器适合需要计算、聚合、可视化的场景比如统计这批数据里连续下降超过三个月的产品数量不是问哪段文本说了答案而是让系统自己算出来。Agentic RAG 的核心价值不是把这些工具简单地并列摆放而是让模型按需组合。一次复杂的问答可能先调 SQL 拿到结构化数据再拿数据去知识库里查对应的业务背景最后调外部 API 补充最新状态三者的输出汇总成最终答案。4.2 工具描述的质量决定路由准确率工具调用最容易翻车的地方不在模型能力而在工具描述写得太烂。模型需要靠一段 tool description 来判断这个工具适不适合当前子任务。如果描述含糊模型就可能拿 SQL 工具去查语义问题或者拿向量检索去查精确数值——路由错了后面再怎么调优都白搭。几个实际的描述编写经验明确标注工具的适用范围和边界。比如向量检索工具描述写成适用于查询企业产品文档、技术支持手册中的语义相关内容不适用于精确数值、统计汇总查询模型就能更好地做路由判断。给出典型的调用示例。描述里加一两个 example说明什么类型的问题应该调用这个工具模型会更容易对齐。说明返回结果的格式。模型需要知道工具返回的是 JSON 还是纯文本、是单条记录还是列表才能正确处理后续步骤。4.3 Query 改写与上下文压缩减少噪音靠的不是模型是预处理多轮检索最怕的就是上下文爆炸——每步检索的结果都塞进对话没几轮就超过模型窗口。这里有两个绕不开的环节需要单独做Query 改写。用户原始问题通常不适合直接拿去检索。比如这个产品的价格最近为什么一直在降拿去向量检索可能捞到一堆广告文案但改成产品 A 近 30 天价格变动原因效果完全不同。规划器拆解子任务时要顺带做 query 改写剔除口语化表达、补全缺失实体、明确时间范围、转化成检索友好型语句。上下文压缩。每轮检索回来的文本块不是全都有用。常见做法是引入一个压缩器可以是小模型、规则过滤器、或 reranker对检索结果做两件事删除与当前信息目标不相关的冗余片段对相关性最高但过长的片段做摘要提取。压缩后只把精炼后的信息传回给规划器/生成器。压缩这一步很多团队会偷懒直接全文塞进上下文结果就是模型被一大堆无关文本干扰反而答得更差。压缩不是可选项是 Agentic RAG 的正常组成部分。5. 自我反思与验证让系统在答错之前踩一脚刹车5.1 从生成即终局到先审判再输出经典 RAG 的生成阶段是一锤定音上下文拼好、LLM 输出、返回给用户结束。中间没有任何人检查这份答案是不是基于真实检索到的信息有没有胡编的成分。Agentic RAG 在生成前后都加了验证环节。生成之前评估器要确认收集到的证据链是否完整生成之后还有一个输出验证器用独立的检查逻辑判断答案中的关键数值是否能在检索到的文本里找到出处答案是否完整覆盖了规划阶段拆解的所有子问题答案中是否存在模型自由发挥而检索证据中不支持的内容这一步的价值在合规类和医疗类场景尤其突出。用户问这种药和另一种药能不能同时服用如果答案引用的医学文档只提到其中一种药输出验证器就会标记证据不足触发一次补充检索而不是直接返回一个可能的错误答案。5.2 验证器的实现方式规则为主、模型为辅输出验证器不建议完全依赖一个大模型自我判断。模型自己生成内容再自己判断对错效果并不好就像让考生自己批改自己的答卷容易自我合理化。更稳妥的方案是分层验证硬规则层检查答案中出现的数字、日期、产品型号、货币金额等关键实体是否在检索到的文本片段中出现过。没出现就触发告警。用正则和精确匹配就能做成本低、可靠。溯源层答案的每个核心断言是否能在某个文档块中找到支持性引用。这需要把生成答案拆分成原子断言再和检索文本做相似度匹配。可以借助小型 NLI 模型自然语言推理模型判断证据是否支持结论。完整性层对照规划阶段拆解出的子问题列表逐一确认答案是否覆盖。漏了哪个子问题就补答或二次检索。5.3 验证失败后的兜底路径补检索、换工具、坦诚说不知道验证失败之后怎么办这里有个很多人容易犯的错误直接把验证不通过的答案改一版再输出看起来就像做了兜底其实只是换了一种方式继续错。正确的兜底路径是分级的第一级补充检索。如果缺的是局部信息规划器针对缺口拆一个新子问题再走一轮检索。第二级扩大召回或更换工具。如果补充检索还是找不到可能是检索入口不对换关键词检索、扩大时间范围、换个工具再试。第三级降低回答粒度。如果多轮尝试后证据仍然不足系统应该缩小问题范围——比如用户问完整评估报告系统只答复目前能确认的部分是 X其余部分资料库中没有足够证据明确标注信息边界。兜底底线明确说不知道。质感好的 Agentic RAG比强答更重要的能力是知道什么时候该承认不知道。给模型设一条硬规则如果检索了 N 轮我一般设 3 轮仍然凑不齐证据链必须输出类似当前知识库中找不到足够信息来回答此问题建议补充以下材料……的响应而不是硬编。6. LangGraph、LlamaIndex 还是自研落地框架选型与核心代码骨架6.1 三条路线的横向对比做 Agentic RAG 的工程落地目前基本是三条路方案核心机制适合场景上手成本可定制性LangGraph基于图状态机的 Agent 编排节点/边/状态显式定义需要精细控制执行流程、分支逻辑清晰的生产系统中高LlamaIndex 的 Agent 能力围绕索引与检索器构建 Agent 工作流内置 RAG 工具包知识库问答为核心、希望快速搭出原型低中自研编排自己写循环控制逻辑ReAct 模式 工具注册表需要深度定制、内部已有成熟检索组件高最高我的经验是如果你正在从零开始做一个新的 Agentic RAG 系统优先从 LangGraph 或自研循环开始而不是从 LlamaIndex 的 Agent 概念直接入手。原因是 LlamaIndex 的 Agent 模块帮你封装了大量操作细节出了问题排查链路会很深——你不知道是哪一步检索、哪一步决策出了问题。LangGraph 把每个节点暴露出来流程可视化、可单步调试生产排障的体验好一个量级。但如果你只是做个 Demo 验证 Agentic RAG 的效果LlamaIndex 确实快半天就能跑通。6.2 一个最小可运行的 ReAct 循环骨架这里给一个最朴素的 Agentic RAG 核心循环实现不依赖任何特定框架目的是让你看清楚整个机制的结构。我用 Python 伪代码风格写实际接哪个框架都可以替换class AgenticRAG: def __init__(self, llm, tools): self.llm llm # 大模型同时承担规划器/生成器 self.tools tools # 工具注册表{name: callable} self.max_steps 5 # 最大循环轮数 def formulate_plan(self, question): # 让模型输出拆解后的子任务列表JSON 格式 prompt f 请将以下问题拆解为最多 3 个独立的检索子任务 每个子任务包含query检索语句、purpose信息目的。 如果问题简单只需要一个子任务即可。 必须以 JSON 数组格式输出。 问题{question} resp self.llm.complete(prompt) return parse_json(resp) def evaluate_sufficiency(self, question, collected_evidence): # 评估当前证据是否支持回答问题 prompt f 根据已收集的证据是否可以完整回答用户问题 如果可以输出 SUFFICIENT 如果证据不足说明缺口是什么输出 INSUFFICIENT gap 描述。 问题{question} 证据{collected_evidence[-N:]} # 只传最近的N轮避免窗口爆炸 verdict self.llm.complete(prompt) return verdict def run(self, question): plan self.formulate_plan(question) collected_evidence [] for step in range(self.max_steps): # 执行阶段按计划逐个执行检索子任务 for task in plan if step 0 else [new_task]: # 确定用哪个工具这里简化默认向量检索可扩展为LLM路由 result self.tools[vector_search](task[query]) compressed self.compress_context(result) # 上下文压缩 collected_evidence.append({ query: task[query], purpose: task[purpose], result: compressed }) # 评估阶段证据是否充分 verdict self.evaluate_sufficiency(question, collected_evidence) if verdict.startswith(SUFFICIENT): # 生成最终答案 return self.generate_answer(question, collected_evidence) else: # 根据缺口描述生成新子任务 gap_desc verdict.split(:, 1)[1].strip() new_task self.llm.complete( f根据信息缺口描述生成一个新的检索任务{gap_desc} ) plan [parse_task(new_task)] # 达到最大步数仍未收集足够证据诚实承认信息不足 return 当前资料库中无法找到足够信息回答此问题建议补充……这个骨架的核心就是把 ReAct 的Reason → Act → Observe → 再 Reason用代码显式表达出来。实际工程里每个环节都要增强——LLM 路由工具而不是写死、压缩器做更精细的处理、评估器用独立验证器而不是让主 LLM 自评。6.3 跑通之后不可跳过的一步可控性治理Demo 跑通之后有几个坑几乎必踩提前打个预防针循环失控。Agent 可能在某两个状态之间反复横跳——评估器说证据不足规划器生成的新子任务和上一轮几乎一样检索结果也大同小异白白消耗 token。解决方案是给循环加去重机制子任务 query 和最近两轮的检索 query 相似度超过阈值就不执行直接触发兜底逻辑。窗口溢出。多轮检索的结果全堆在上下文里迟早把窗口塞满。除了压缩器之外还要设计证据修剪策略新证据进来走旧的相似证据出去——相关性最低、时间最久的那部分优先淘汰。工具误用。模型拿 SQL 工具去做语义检索、拿向量工具去查精确统计数字这类路由错误在小规模 Demo 里偶尔出错无所谓但在生产环境会系统性放大。治理方式是给工具路由加一层准入规则——每个子任务在调用工具之前做一次轻量分类判断数值型问题禁止走向量语义检索模型纠错成本远低于事后追责。7. 生产环境里那些文档不写但你必须知道的工程细节7.1 延迟预算与步数上限之间怎么平衡Agentic RAG 最直接的代价是延迟。一个 3 步循环的问答每步包括 LLM 推理 向量检索/API 调用总延迟可能是经典 RAG 的 3~5 倍。用户等 1 秒还觉得流畅等 8 秒就想关页面了。我实践下来的平衡策略是分层延迟预算第一步规划拆解和第一步检索必须在 1.5 秒内完成——如果这一步就发现资料充足就直接走普通 RAG 生成流程不进入循环。这实际上是规模自适应的路由简单问题走快通道复杂问题才走慢通道。每多一轮循环给一个明确的时间预算上限比如 3 秒。总预算设 8 秒超过直接跳过评估环节、用现有证据生成答案同时在答案里标注部分信息未经过充分验证。把多轮检索改成可并行的就并行。规划器拆解出来的多个子任务如果相互独立就并发执行时间成本从串行之和变成串行最大之一延迟立刻降下来。7.2 评估指标与传统 RAG 完全不同别只盯着 recall 和 precision做 Agentic RAG 的评测传统 RAG 的召回率、精确率、命中率这些指标只是基础真正要盯的是决策质量指标规划正确率规划器拆解出的子任务里有多少真正对回答用户问题有贡献。无效子任务比例高说明规划器在空转。工具路由准确率每个子任务选择的工具是否恰当。路由错了检索结果再准也是无用功。证据利用率最终答案里有多少比例的断言能映射到检索证据上。这个指标直接反映答案的可溯源程度也是幻觉率的反向代理。提前终止准确率评估器判定证据充分而提前进入生成阶段的比例以及这个判定的正确度。判定太激进会牺牲质量太保守会牺牲延迟。这些指标需要在系统上线前就定义好、量化好否则 Agentic RAG 就是一个黑盒——你知道它可能更聪明但说不清聪明在哪。7.3 推荐一个评估工具RAGAS 的 Agent 模式评估不要自己从零搭直接用 RAGAS 这类开源框架。它针对 Agentic RAG 场景专门设计了评估维度和配套算子能够量化规划质量、工具选择准确度、多步检索的信息整合程度还会模拟用户对最终答案做整体评判。我实际使用的体验是它对规划是否正确拆解了问题这个维度的评估很有价值——可以输出一份报告标注出哪些步骤的检索是多余的哪些应该拆开的子问题没有被拆开。这类反馈对迭代优化规划器帮助很大比自己凭感觉改 prompt 高效得多。8. 一个踩了三轮坑才跑通的实战复盘从看似智能到真正可用最后分享一个实际项目的复盘。我之前搭建了一套面向某企业内部知识库的 Agentic RAG 系统目的是让员工可以用自然语言查询制度文档、项目资料和结构化业务数据。第一版跑通之后效果不理想调了两轮质变。过程比预期曲折值得把坑摊开说。第一轮多步检索上线后准确率反而下降了。排查发现问题出在规划器拆解出的子任务过于细碎——一个问题拆出 5 个子任务其中两个检索的内容严重重叠重复文本大量进入上下文模型被冗余信息干扰最终答案的清晰度反而差了。修复方式是给规划器加了一个约束子任务之间必须有明确的信息互补性相似度太高的子任务会被合并。同时把默认最大子任务数从 5 压到 3。第二轮验证器形同虚设。第一版验证器只是让主 LLM自我检查答案是否正确结果模型在验证阶段只会顺着自己刚才的答案说对——这符合我前面说的问题自我验证基本无效。后来单独引入了一个轻量 NLI 模型做证据支持判断把答案里的核心断言逐个拉出来和检索文本比对效果立刻不一样原来模型生成的很多自信但没根据的句子全被拦下来了。第三轮工具路由在真实用户问题前失灵。内部员工的问题往往是口语化的比如帮我查下最近哪个项目的预算超支最多规划器把它拆成了语义检索类子任务结果向量库捞回来的都是些不痛不痒的项目描述文本。修复方案是在路由前加了一个数值意图识别层问题里出现最多/最少/同比/超支这类需要聚合计算的信号直接把路由导向 SQL 工具不走向量检索。三轮改完之后系统的最终效果才基本符合预期复杂问题的答案可溯源率明显提升简单问题延迟没有明显劣化。回头看第一版的问题不是Agentic 不够多而是没有把不必要的能力堆上去之前先确保每一个环节的功能都有明确的评测反馈。9. 我对 Agentic RAG 现状与边界的判断做了大量实际测试之后我给 Agentic RAG 的定位是它没有改变大模型的知识边界但它让模型更高效地使用外部信息工具来补足自己的边界。它解决的问题是模型不知道答案、但也不告诉你它不知道这个经典困境——通过多轮规划与验证把不知道的情况显式暴露出来并触发补充检索或诚实承认。它也不是万能的。以下几点是我在实践中反复踩到的边界不适合超低延迟场景。步数越高延迟线性增长做不到秒回。不适合信息源本身很单薄的场景。如果知识库总共就几十篇文档简单问题搞一次检索就够了多步规划纯粹是资金浪费。不适合需要强事实一致性的合规场景。虽然验证器能降低幻觉率但做不到百分之百医疗、金融等场景还是需要人工复核环节。成本比经典 RAG 高一个数量级。每多一轮循环就是多次 LLM 调用和多次检索token 消耗随步数线性上涨。我在项目里统计过3 步循环的单次请求成本基本是经典 RAG 的 5 到 7 倍。但如果你面对的是一批用户会问出真实复杂问题的知识库场景经典 RAG 的天花板就在那里——一次查询解决不了连锁问题而 Agentic RAG 至少提供了一条往上走的路径。 
长河君 · 2026/10/20 8:54:28 · 阅读 1.2k Agentic RAG 实战指南：从直线管道到多步决策闭环
1. 检索管道的天花板一次查询解决不了连锁问题做了一段时间 RAG 应用的人多半都会遇到同一个尴尬时刻知识库文档放得挺全向量检索的召回率调得也不算差但面对稍微复杂一点的问题系统就开始答非所问。比如用户问这家公司过去三年营收变化趋势如何主要受哪些因素影响传统 RAG 的做法是把它当成一个查询去库里捞几段最相似的文本拼在一起交给大模型。结果往往是营收数字捞到了但影响因素那部分上下文缺失模型只能靠自己的常识硬编或者干脆答偏。问题的根源在于传统 RAG 本质上是一条直线管道Embedding 召回 → Top-K 拼接 → LLM 生成。它默认一次检索就能拿到生成所需的全部信息但真实场景里用户的问题往往要拆成多个子问题、依赖多轮检索、需要对比多个文档、甚至要调用外部工具补充数据。直线管道没有规划这一步模型不知道先查什么、再查什么、查到的信息够不够、要不要换个角度再查一次。Agentic RAG 想解决的正是这个管道思维的瓶颈。它把检索生成从单次函数调用升级成多步决策闭环——系统不再被动等着用户给一个 query而是像一个有检索权限的智能体一样先拆解任务、制定检索计划、执行检索、评估结果是否足够回答问题不够就再检索、再分析直到信息充分才进入生成阶段。用大白话说传统 RAG 是你问一句我去库房搬一次货Agentic RAG 是我问清楚你要什么、分几趟搬、每次搬完检查一下货齐不齐实在缺货我还能去隔壁仓库调货。这篇文章不是概念科普是我把 Agentic RAG 从论文、开源项目一路拆到实际落地之后的经验整理。适合两类人看一是做 RAG 应用但总觉得效果天花板明显、想往上突破的开发者二是正在选技术路线想知道 Agentic RAG 到底比经典 RAG 强在哪、值不值得投入改造的架构决策者。我会把架构设计、核心能力拆解、代码实现路径、以及生产环境中那些文档里不会写的坑全部摊开讲。2. 从直线管道到决策环路架构到底变了什么2.1 经典 RAG 的路由过程先对齐一下基线。经典 RAG 的链路是固定的用户 query 进来经过 embedding 模型转成向量去向量库做相似度检索取回 Top-K 条文本块拼进 prompt交给 LLM 生成答案。整个过程没有任何分支判断也没有反馈机制。这套结构在问题简单、知识库垂直的场景下够用。比如XX 产品的退货政策是什么一个 query 就能命中不需要二次检索。但一旦问题涉及多跳推理——比如某型号设备在北方冬季的故障率为什么比南方高——模型需要先知道设备型号对应的技术参数再关联到环境温度对零部件的影响最后结合售后维修记录才能给出可信答案。这三个信息分布在知识库的不同区域靠一次相似度检索很难全部捞回来而直线管道没有发现缺哪块信息、再去补查的能力。2.2 Agentic RAG 的三个新增抽象Agentic RAG 没有推翻 RAG 的检索生成内核而是在外面加了一层代理决策机制。拆开看它引入了三个经典 RAG 没有的组件规划器Planner。负责把用户 query 拆解成可执行的检索子任务。拆解粒度根据任务复杂度动态调整简单问题一步完成复杂问题拆成多步子目标。这个组件通常由 LLM 充当核心是让模型以需要哪些信息才能回答这个问题的视角进行任务分解而不是直接把用户原话丢给检索器。执行器Executor。根据规划器的子任务确定调用哪个工具、传什么参数。工具可以是向量库检索、SQL 查询、HTTP API 调用甚至是另一个小模型的输出。这一步的关键是工具选择和参数构造都要由模型自主完成而不是代码里写死。评估器Evaluator。每执行完一步评估当前收集的信息是否足够支撑最终答案。不够就反馈给规划器补一步检索够了才进入生成阶段。这一环节是 Agentic RAG 与传统 RAG 最本质的区别——它把信息是否充分的判断从人转移到了系统本身。三个组件串起来就形成了一个 ReAct 模式的循环Reason思考缺什么信息→ Act执行检索→ Observe观察检索结果→ 再 Reason判断够不够不够继续。循环终止条件是评估器判定信息完备或者达到预设的最大步数。2.3 一个具体的控制流程示例拿前面那个某型号设备北方冬季故障率为什么偏高的问题举例Agentic RAG 的执行路径大概是规划器拆解出三个子任务检索设备型号的技术规格、检索北方环境条件下的零部件故障记录、检索该型号的售后维修统计报告。执行器先查技术规格拿到设备适用的温度范围。评估器发现温度范围和故障率之间还缺因果链——需要查环境温度对哪些零部件产生的应力超过设计余量。规划器补充第四个子任务检索低温环境 零部件应力相关的技术文档或测试报告。执行器补查评估器确认信息链完整。进入生成阶段模型综合所有轮次收集的信息组织答案。对比经典 RAG 的一次性检索这个过程的检索次数多了但每一步都有明确的信息目标最终答案的准确率和可解释性都显著高于碰运气式的一次召回。3. 多步推理不是炫技检索规划背后的信息论逻辑3.1 为什么多步检索能提升准确率而不是引入噪音有人会质疑多步检索每步都可能引入噪音步数越多错误累积的风险不也越大吗这个担心有道理但前提是——如果检索是盲目的多步确实会累积噪音。Agentic RAG 的多步检索之所以有效关键在于每步都有信息缺口分析作为前提检索是有方向的不是撒网。信息论里有个概念叫互信息增量新的检索结果应该为目标答案的确定提供新增的信息量而不是重复已有信息。规划器拆解子任务时本质是在做这个问题的答案空间里目前哪些维度还是不确定的。每一个子任务瞄准一个不确定维度检索回来的内容就是在消除这个维度上的不确定性。拿实际例子来说用户问A 方案和 B 方案的适用场景有什么区别。经典 RAG 可能直接把方案介绍文档整体丢给模型模型面对一堆描述性文字容易把两者适用边界混淆。Agentic RAG 会把任务拆成A 方案的适用约束条件和B 方案的适用约束条件两个子问题分别检索、分别整理最后在生成阶段做对比。每个子问题的检索都在消除一个维度A/B 各自的边界条件上的不确定性比一次性捞到混合信息再让模型自己去辨析准确率高得多。3.2 子查询拆分方式分解、对比、验证实际落地时子查询的拆分模式大致有三种可以根据问题类型预置也可以让模型动态决定分解型拆分。适用于整体问题可以拆成多个独立子问题的场景。比如XX 项目的风险评估报告主要结论是什么拆成财务风险评估、技术风险评估、市场风险评估三个子查询结果汇总。这种拆分最简单本质是 AND 逻辑。对比型拆分。适用于需要比较两个或多个实体的异同的场景。比如RAG 和 Agentic RAG 的架构差异拆成RAG 的架构特征和Agentic RAG 的架构特征两个子查询生成阶段再做差异对比。这种拆分的要点是让两个子查询的检索范围尽量正交避免重复文本进入上下文。验证型拆分。适用于一个问题需要从多个证据源交叉验证的场景。比如某产品是否满足某项安全认证标准先查产品参数再查标准要求再查检测报告让多轮检索结果相互印证。这是消除幻觉的关键手段——单一来源的信息可能是模型编的多个独立来源的一致信息则可信得多。三种拆分不是互斥的复杂问题往往是三种模式的组合。我在实际项目中见过一个比较复杂的例子用户问对比开源和商业 RAG 方案在合规场景下的优劣势系统先分解成开源方案合规模块和商业方案合规模块两个子问题每个子问题内部又做验证型拆分查文档介绍、查合规认证、查实际案例最后在生成阶段做对比。整个检索过程跑了 6 轮但每一轮返回的信息都在最终答案里派上了用场没有一轮是浪费的。3.3 动态规划还是固定模板一个需要想清楚的取舍做规划器的时候有个路线选择用固定模板强制拆分还是让 LLM 完全自由规划。这两种方案我都在生产环境试过。固定模板方案的优点是稳定——预先定义好不同类型问题的拆分规则系统只按规则执行不会出现模型脑洞大开拆出无关子问题的情况。缺点是死板真实用户的问题千奇百怪预置规则很难覆盖所有情况漏掉的场景就只能回退到单次检索。自由规划的优点是灵活模型可以根据问题内容动态决定拆分方式。缺点是不可控——模型可能拆出 8 个子问题其中 3 个是无效的或者绕来绕去始终停在同一个信息维度上打转。我的建议是先上固定模板保证稳定性再逐步放开自由度。给模型搭一个问题类型分类器 拆分策略库的框架先判断问题属于分解型 / 对比型 / 验证型 / 简单直答型中的哪一类再按照对应策略生成子查询。这样既保留了动态规划的空间又不会完全失控。4. 让手够得着更多信息Agentic RAG 的工具调用设计4.1 检索只是工具之一向量库、数据库、外部 API 的统一调度Agentic RAG 的Retrieval不再局限于语义向量库它把获取信息这个动作泛化成了工具调用。规划器拆解出子任务后执行器要决定该用哪个工具来满足当前的信息需求。常见的工具类型至少有这么几种向量语义检索适合答案藏在长文本里、不知道关键词的场景比如产品文档、研究报告、企业内部知识库。SQL/结构化查询适合答案精确、有明确字段约束的场景比如上季度各区域销售额排名前三的产品数据在库里但语义检索答不出来。关键词/倒排索引检索适合精确匹配、专有名词、编号类查询比如设备型号、SKU、法规条款编号。很多工程团队会忽略这类 工具但它在垂直领域的命中率往往比向量检索还高。外部 API/实时数据适合时效性要求高的信息比如天气、股票行情、物流状态。知识库里没有的东西就调接口拿最新数据。代码解释器适合需要计算、聚合、可视化的场景比如统计这批数据里连续下降超过三个月的产品数量不是问哪段文本说了答案而是让系统自己算出来。Agentic RAG 的核心价值不是把这些工具简单地并列摆放而是让模型按需组合。一次复杂的问答可能先调 SQL 拿到结构化数据再拿数据去知识库里查对应的业务背景最后调外部 API 补充最新状态三者的输出汇总成最终答案。4.2 工具描述的质量决定路由准确率工具调用最容易翻车的地方不在模型能力而在工具描述写得太烂。模型需要靠一段 tool description 来判断这个工具适不适合当前子任务。如果描述含糊模型就可能拿 SQL 工具去查语义问题或者拿向量检索去查精确数值——路由错了后面再怎么调优都白搭。几个实际的描述编写经验明确标注工具的适用范围和边界。比如向量检索工具描述写成适用于查询企业产品文档、技术支持手册中的语义相关内容不适用于精确数值、统计汇总查询模型就能更好地做路由判断。给出典型的调用示例。描述里加一两个 example说明什么类型的问题应该调用这个工具模型会更容易对齐。说明返回结果的格式。模型需要知道工具返回的是 JSON 还是纯文本、是单条记录还是列表才能正确处理后续步骤。4.3 Query 改写与上下文压缩减少噪音靠的不是模型是预处理多轮检索最怕的就是上下文爆炸——每步检索的结果都塞进对话没几轮就超过模型窗口。这里有两个绕不开的环节需要单独做Query 改写。用户原始问题通常不适合直接拿去检索。比如这个产品的价格最近为什么一直在降拿去向量检索可能捞到一堆广告文案但改成产品 A 近 30 天价格变动原因效果完全不同。规划器拆解子任务时要顺带做 query 改写剔除口语化表达、补全缺失实体、明确时间范围、转化成检索友好型语句。上下文压缩。每轮检索回来的文本块不是全都有用。常见做法是引入一个压缩器可以是小模型、规则过滤器、或 reranker对检索结果做两件事删除与当前信息目标不相关的冗余片段对相关性最高但过长的片段做摘要提取。压缩后只把精炼后的信息传回给规划器/生成器。压缩这一步很多团队会偷懒直接全文塞进上下文结果就是模型被一大堆无关文本干扰反而答得更差。压缩不是可选项是 Agentic RAG 的正常组成部分。5. 自我反思与验证让系统在答错之前踩一脚刹车5.1 从生成即终局到先审判再输出经典 RAG 的生成阶段是一锤定音上下文拼好、LLM 输出、返回给用户结束。中间没有任何人检查这份答案是不是基于真实检索到的信息有没有胡编的成分。Agentic RAG 在生成前后都加了验证环节。生成之前评估器要确认收集到的证据链是否完整生成之后还有一个输出验证器用独立的检查逻辑判断答案中的关键数值是否能在检索到的文本里找到出处答案是否完整覆盖了规划阶段拆解的所有子问题答案中是否存在模型自由发挥而检索证据中不支持的内容这一步的价值在合规类和医疗类场景尤其突出。用户问这种药和另一种药能不能同时服用如果答案引用的医学文档只提到其中一种药输出验证器就会标记证据不足触发一次补充检索而不是直接返回一个可能的错误答案。5.2 验证器的实现方式规则为主、模型为辅输出验证器不建议完全依赖一个大模型自我判断。模型自己生成内容再自己判断对错效果并不好就像让考生自己批改自己的答卷容易自我合理化。更稳妥的方案是分层验证硬规则层检查答案中出现的数字、日期、产品型号、货币金额等关键实体是否在检索到的文本片段中出现过。没出现就触发告警。用正则和精确匹配就能做成本低、可靠。溯源层答案的每个核心断言是否能在某个文档块中找到支持性引用。这需要把生成答案拆分成原子断言再和检索文本做相似度匹配。可以借助小型 NLI 模型自然语言推理模型判断证据是否支持结论。完整性层对照规划阶段拆解出的子问题列表逐一确认答案是否覆盖。漏了哪个子问题就补答或二次检索。5.3 验证失败后的兜底路径补检索、换工具、坦诚说不知道验证失败之后怎么办这里有个很多人容易犯的错误直接把验证不通过的答案改一版再输出看起来就像做了兜底其实只是换了一种方式继续错。正确的兜底路径是分级的第一级补充检索。如果缺的是局部信息规划器针对缺口拆一个新子问题再走一轮检索。第二级扩大召回或更换工具。如果补充检索还是找不到可能是检索入口不对换关键词检索、扩大时间范围、换个工具再试。第三级降低回答粒度。如果多轮尝试后证据仍然不足系统应该缩小问题范围——比如用户问完整评估报告系统只答复目前能确认的部分是 X其余部分资料库中没有足够证据明确标注信息边界。兜底底线明确说不知道。质感好的 Agentic RAG比强答更重要的能力是知道什么时候该承认不知道。给模型设一条硬规则如果检索了 N 轮我一般设 3 轮仍然凑不齐证据链必须输出类似当前知识库中找不到足够信息来回答此问题建议补充以下材料……的响应而不是硬编。6. LangGraph、LlamaIndex 还是自研落地框架选型与核心代码骨架6.1 三条路线的横向对比做 Agentic RAG 的工程落地目前基本是三条路方案核心机制适合场景上手成本可定制性LangGraph基于图状态机的 Agent 编排节点/边/状态显式定义需要精细控制执行流程、分支逻辑清晰的生产系统中高LlamaIndex 的 Agent 能力围绕索引与检索器构建 Agent 工作流内置 RAG 工具包知识库问答为核心、希望快速搭出原型低中自研编排自己写循环控制逻辑ReAct 模式 工具注册表需要深度定制、内部已有成熟检索组件高最高我的经验是如果你正在从零开始做一个新的 Agentic RAG 系统优先从 LangGraph 或自研循环开始而不是从 LlamaIndex 的 Agent 概念直接入手。原因是 LlamaIndex 的 Agent 模块帮你封装了大量操作细节出了问题排查链路会很深——你不知道是哪一步检索、哪一步决策出了问题。LangGraph 把每个节点暴露出来流程可视化、可单步调试生产排障的体验好一个量级。但如果你只是做个 Demo 验证 Agentic RAG 的效果LlamaIndex 确实快半天就能跑通。6.2 一个最小可运行的 ReAct 循环骨架这里给一个最朴素的 Agentic RAG 核心循环实现不依赖任何特定框架目的是让你看清楚整个机制的结构。我用 Python 伪代码风格写实际接哪个框架都可以替换class AgenticRAG: def __init__(self, llm, tools): self.llm llm # 大模型同时承担规划器/生成器 self.tools tools # 工具注册表{name: callable} self.max_steps 5 # 最大循环轮数 def formulate_plan(self, question): # 让模型输出拆解后的子任务列表JSON 格式 prompt f 请将以下问题拆解为最多 3 个独立的检索子任务 每个子任务包含query检索语句、purpose信息目的。 如果问题简单只需要一个子任务即可。 必须以 JSON 数组格式输出。 问题{question} resp self.llm.complete(prompt) return parse_json(resp) def evaluate_sufficiency(self, question, collected_evidence): # 评估当前证据是否支持回答问题 prompt f 根据已收集的证据是否可以完整回答用户问题 如果可以输出 SUFFICIENT 如果证据不足说明缺口是什么输出 INSUFFICIENT gap 描述。 问题{question} 证据{collected_evidence[-N:]} # 只传最近的N轮避免窗口爆炸 verdict self.llm.complete(prompt) return verdict def run(self, question): plan self.formulate_plan(question) collected_evidence [] for step in range(self.max_steps): # 执行阶段按计划逐个执行检索子任务 for task in plan if step 0 else [new_task]: # 确定用哪个工具这里简化默认向量检索可扩展为LLM路由 result self.tools[vector_search](task[query]) compressed self.compress_context(result) # 上下文压缩 collected_evidence.append({ query: task[query], purpose: task[purpose], result: compressed }) # 评估阶段证据是否充分 verdict self.evaluate_sufficiency(question, collected_evidence) if verdict.startswith(SUFFICIENT): # 生成最终答案 return self.generate_answer(question, collected_evidence) else: # 根据缺口描述生成新子任务 gap_desc verdict.split(:, 1)[1].strip() new_task self.llm.complete( f根据信息缺口描述生成一个新的检索任务{gap_desc} ) plan [parse_task(new_task)] # 达到最大步数仍未收集足够证据诚实承认信息不足 return 当前资料库中无法找到足够信息回答此问题建议补充……这个骨架的核心就是把 ReAct 的Reason → Act → Observe → 再 Reason用代码显式表达出来。实际工程里每个环节都要增强——LLM 路由工具而不是写死、压缩器做更精细的处理、评估器用独立验证器而不是让主 LLM 自评。6.3 跑通之后不可跳过的一步可控性治理Demo 跑通之后有几个坑几乎必踩提前打个预防针循环失控。Agent 可能在某两个状态之间反复横跳——评估器说证据不足规划器生成的新子任务和上一轮几乎一样检索结果也大同小异白白消耗 token。解决方案是给循环加去重机制子任务 query 和最近两轮的检索 query 相似度超过阈值就不执行直接触发兜底逻辑。窗口溢出。多轮检索的结果全堆在上下文里迟早把窗口塞满。除了压缩器之外还要设计证据修剪策略新证据进来走旧的相似证据出去——相关性最低、时间最久的那部分优先淘汰。工具误用。模型拿 SQL 工具去做语义检索、拿向量工具去查精确统计数字这类路由错误在小规模 Demo 里偶尔出错无所谓但在生产环境会系统性放大。治理方式是给工具路由加一层准入规则——每个子任务在调用工具之前做一次轻量分类判断数值型问题禁止走向量语义检索模型纠错成本远低于事后追责。7. 生产环境里那些文档不写但你必须知道的工程细节7.1 延迟预算与步数上限之间怎么平衡Agentic RAG 最直接的代价是延迟。一个 3 步循环的问答每步包括 LLM 推理 向量检索/API 调用总延迟可能是经典 RAG 的 3~5 倍。用户等 1 秒还觉得流畅等 8 秒就想关页面了。我实践下来的平衡策略是分层延迟预算第一步规划拆解和第一步检索必须在 1.5 秒内完成——如果这一步就发现资料充足就直接走普通 RAG 生成流程不进入循环。这实际上是规模自适应的路由简单问题走快通道复杂问题才走慢通道。每多一轮循环给一个明确的时间预算上限比如 3 秒。总预算设 8 秒超过直接跳过评估环节、用现有证据生成答案同时在答案里标注部分信息未经过充分验证。把多轮检索改成可并行的就并行。规划器拆解出来的多个子任务如果相互独立就并发执行时间成本从串行之和变成串行最大之一延迟立刻降下来。7.2 评估指标与传统 RAG 完全不同别只盯着 recall 和 precision做 Agentic RAG 的评测传统 RAG 的召回率、精确率、命中率这些指标只是基础真正要盯的是决策质量指标规划正确率规划器拆解出的子任务里有多少真正对回答用户问题有贡献。无效子任务比例高说明规划器在空转。工具路由准确率每个子任务选择的工具是否恰当。路由错了检索结果再准也是无用功。证据利用率最终答案里有多少比例的断言能映射到检索证据上。这个指标直接反映答案的可溯源程度也是幻觉率的反向代理。提前终止准确率评估器判定证据充分而提前进入生成阶段的比例以及这个判定的正确度。判定太激进会牺牲质量太保守会牺牲延迟。这些指标需要在系统上线前就定义好、量化好否则 Agentic RAG 就是一个黑盒——你知道它可能更聪明但说不清聪明在哪。7.3 推荐一个评估工具RAGAS 的 Agent 模式评估不要自己从零搭直接用 RAGAS 这类开源框架。它针对 Agentic RAG 场景专门设计了评估维度和配套算子能够量化规划质量、工具选择准确度、多步检索的信息整合程度还会模拟用户对最终答案做整体评判。我实际使用的体验是它对规划是否正确拆解了问题这个维度的评估很有价值——可以输出一份报告标注出哪些步骤的检索是多余的哪些应该拆开的子问题没有被拆开。这类反馈对迭代优化规划器帮助很大比自己凭感觉改 prompt 高效得多。8. 一个踩了三轮坑才跑通的实战复盘从看似智能到真正可用最后分享一个实际项目的复盘。我之前搭建了一套面向某企业内部知识库的 Agentic RAG 系统目的是让员工可以用自然语言查询制度文档、项目资料和结构化业务数据。第一版跑通之后效果不理想调了两轮质变。过程比预期曲折值得把坑摊开说。第一轮多步检索上线后准确率反而下降了。排查发现问题出在规划器拆解出的子任务过于细碎——一个问题拆出 5 个子任务其中两个检索的内容严重重叠重复文本大量进入上下文模型被冗余信息干扰最终答案的清晰度反而差了。修复方式是给规划器加了一个约束子任务之间必须有明确的信息互补性相似度太高的子任务会被合并。同时把默认最大子任务数从 5 压到 3。第二轮验证器形同虚设。第一版验证器只是让主 LLM自我检查答案是否正确结果模型在验证阶段只会顺着自己刚才的答案说对——这符合我前面说的问题自我验证基本无效。后来单独引入了一个轻量 NLI 模型做证据支持判断把答案里的核心断言逐个拉出来和检索文本比对效果立刻不一样原来模型生成的很多自信但没根据的句子全被拦下来了。第三轮工具路由在真实用户问题前失灵。内部员工的问题往往是口语化的比如帮我查下最近哪个项目的预算超支最多规划器把它拆成了语义检索类子任务结果向量库捞回来的都是些不痛不痒的项目描述文本。修复方案是在路由前加了一个数值意图识别层问题里出现最多/最少/同比/超支这类需要聚合计算的信号直接把路由导向 SQL 工具不走向量检索。三轮改完之后系统的最终效果才基本符合预期复杂问题的答案可溯源率明显提升简单问题延迟没有明显劣化。回头看第一版的问题不是Agentic 不够多而是没有把不必要的能力堆上去之前先确保每一个环节的功能都有明确的评测反馈。9. 我对 Agentic RAG 现状与边界的判断做了大量实际测试之后我给 Agentic RAG 的定位是它没有改变大模型的知识边界但它让模型更高效地使用外部信息工具来补足自己的边界。它解决的问题是模型不知道答案、但也不告诉你它不知道这个经典困境——通过多轮规划与验证把不知道的情况显式暴露出来并触发补充检索或诚实承认。它也不是万能的。以下几点是我在实践中反复踩到的边界不适合超低延迟场景。步数越高延迟线性增长做不到秒回。不适合信息源本身很单薄的场景。如果知识库总共就几十篇文档简单问题搞一次检索就够了多步规划纯粹是资金浪费。不适合需要强事实一致性的合规场景。虽然验证器能降低幻觉率但做不到百分之百医疗、金融等场景还是需要人工复核环节。成本比经典 RAG 高一个数量级。每多一轮循环就是多次 LLM 调用和多次检索token 消耗随步数线性上涨。我在项目里统计过3 步循环的单次请求成本基本是经典 RAG 的 5 到 7 倍。但如果你面对的是一批用户会问出真实复杂问题的知识库场景经典 RAG 的天花板就在那里——一次查询解决不了连锁问题而 Agentic RAG 至少提供了一条往上走的路径。