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 至少提供了一条往上走的路径。
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 至少提供了一条往上走的路径。