★ FEATURED ARTICLE 1. 从传统RAG到Agentic RAG一次架构思路的彻底转变做过RAG应用的人大概都有过这种体验搭一个“文档入库—向量检索—拼上下文—丢给模型”的流水线demo阶段效果惊艳一旦上线面对真实用户的刁钻提问立刻原形毕露。用户问“对比一下A文档第三章和B文档附录里关于成本测算的口径差异”传统RAG要么召回一堆不相关的片段要么把两个文档的内容混在一起给出一个似是而非的答案。问题不在于向量库不够强也不在于模型不够聪明而在于整个流程是“一次性”的——检索一次生成一次中间没有任何反思、纠错、补充的机会。Agentic RAG要解决的就是这个结构性缺陷。它的核心思路是把“检索”从一个固定步骤升级为Agent可以自主决策、多轮调用、动态调整的工具。换句话说传统RAG是“检索增强生成”Agentic RAG是“Agent编排检索与生成”。这个区别听起来只是措辞变化但落到工程实现上是两套完全不同的架构。我最初接触这个概念时也犯过嘀咕不就是加个循环让模型多查几次吗后来在实际项目里踩了坑才明白难点根本不在“循环”本身而在于什么时候该循环、循环时查什么、查到什么程度算够、多个来源冲突时怎么裁决。这些问题没有标准答案必须靠Agent的推理能力在运行时动态判断。这也是为什么它叫“Agentic”——决策权交给了Agent而不是写死在代码里的if-else。这篇文章我会围绕Agentic RAG的架构设计、核心组件、实操落地和排查经验展开重点讲清楚它和传统RAG的本质差异、多轮检索的调度逻辑、工具选型的取舍以及我在实际搭建中遇到的那些“文档里不会写”的坑。适合已经了解基础RAG、想进一步做复杂问答系统的开发者参考也适合正在评估是否要引入Agent架构的技术负责人做决策参考。2. 核心架构拆解Agentic RAG到底由哪些部件组成2.1 为什么传统RAG的“单次检索”必然失效先把传统RAG的流程摊开看。典型实现是这样的用户提问 → 问题向量化 → 向量库相似度检索Top-K → 拼接Prompt → LLM生成答案。这条链路里有一个隐含假设用户的问题和文档中的答案之间存在直接的语义对应关系。只要向量模型够好Top-K召回就能覆盖答案所需的信息。这个假设在简单事实型问答上成立比如“某产品的保修期是多久”。但真实场景里大量问题不满足这个假设。我归纳了三类典型失效场景第一类是多跳推理问题。用户问“去年营收增长最快的部门它的负责人今年提出了什么战略”这需要先查营收数据找到部门再查该负责人的战略文档两次检索之间有依赖关系单次检索无法同时命中。第二类是对比与聚合问题。用户要对比多个文档的观点或者统计某类信息的总和。单次检索返回的是零散片段模型拿到手也拼不出完整对比。第三类是模糊与追问问题。用户自己都没想清楚要问什么第一轮提问很宽泛需要Agent先检索一轮根据结果判断“信息不够需要缩小范围再查”然后发起第二轮更精准的检索。传统RAG面对这三类问题要么答非所问要么强行编造。而Agentic RAG的价值恰恰在于它能识别“当前信息不足”并主动发起补充检索。2.2 Agentic RAG的四层核心结构我把Agentic RAG拆成四个层次来理解这样在实现时能清楚知道每一层该做什么、不该做什么。决策层是整个系统的大脑通常由一个具备工具调用能力的LLM担任。它负责理解用户意图、判断是否需要检索、决定检索什么、评估检索结果是否充分、决定是否继续检索或直接生成。这一层的核心是推理循环观察当前状态 → 思考下一步动作 → 执行动作 → 观察结果 → 再思考直到满足终止条件。工具层是Agent可以调用的能力集合。最基础的是向量检索工具但实际项目里往往还需要关键词检索、结构化查询、文档元数据过滤、甚至外部API调用。工具层的设计原则是每个工具职责单一、输入输出明确这样Agent才能准确判断该用哪个工具。记忆层负责维护对话历史和中间状态。Agentic RAG的多轮检索会产生大量中间结果哪些保留、哪些丢弃、如何压缩直接影响后续决策的质量。我见过不少实现把每一轮检索的原始片段全部塞回上下文结果Token爆炸模型反而抓不住重点。生成层是最终输出环节。它和传统RAG的生成层看起来一样但输入不同——Agentic RAG传给生成层的是经过筛选、整合、可能还经过冲突裁决的上下文而不是原始检索片段。这四层之间的关系不是线性的而是决策层在中间反复调度工具层和记忆层直到它认为信息足够才交给生成层输出。理解这一点是理解整个架构的关键。2.3 一个容易混淆的点Agentic RAG和Workflow RAG的区别市面上还有一种叫“Workflow RAG”的方案它把检索流程编排成固定的工作流比如“先查A库再查B库然后合并结果”。这种方案看起来也能实现多轮检索但它和Agentic RAG有本质区别。Workflow RAG的流程是预先定义好的开发者写死了“第一步做什么、第二步做什么”。Agentic RAG的流程是运行时决定的Agent根据当前情况自主选择下一步。前者适合流程稳定、可预测的场景后者适合问题类型多样、需要灵活应对的场景。我个人的经验是如果业务问题类型收敛、可以枚举Workflow RAG更可控、更省钱如果问题开放、类型多变Agentic RAG的灵活性才值得那份额外的复杂度和成本。不要为了“Agentic”这个标签而强行上Agent这是我在项目里交过学费的教训。3. 多轮检索的调度逻辑Agent什么时候该再查一次3.1 检索充分性的判断标准Agentic RAG最核心的决策是当前检索到的信息够不够回答用户问题这个判断做不好要么检索不足导致答案残缺要么过度检索浪费成本。我在实践中总结了一套判断维度供Agent在推理时参考覆盖度用户问题涉及的每个子问题是否都有对应信息支撑。比如问“对比A和B”如果只检索到A的信息覆盖度就不够。一致性多个来源的信息是否互相印证。如果两个文档对同一事实的描述矛盾说明需要进一步查证。具体度检索到的信息是泛泛而谈还是具体到细节。用户问具体数字检索到的却是概述性描述具体度就不够。时效性如果问题涉及时间敏感信息检索到的内容是否足够新。这四个维度不需要全部满足但Agent需要在推理时明确当前缺哪个维度才能有针对性地发起下一轮检索。我见过一些实现只是简单判断“检索结果数量是否大于N”这种粗糙的判断在复杂问题上基本无效。3.2 查询改写与分解的实操方法当Agent决定需要补充检索时它面临的下一个问题是用什么查询词去查直接用用户原问题再查一遍通常没用因为同样的查询会召回同样的结果。这时候需要查询改写或查询分解。查询改写是把原始问题转换成更适合检索的形式。比如用户问“那个新功能怎么用”Agent需要先结合对话历史判断“那个新功能”指什么改写成“XX功能的使用方法”再去检索。这一步依赖对话记忆没有记忆层支撑的Agent做不好改写。查询分解是把复杂问题拆成多个子查询。比如“对比A和B的成本差异”可以拆成“A的成本构成”和“B的成本构成”两个查询分别检索后再合并。分解的粒度很关键拆得太粗检索结果还是混杂拆得太细检索次数爆炸。我的经验是按语义单元拆分每个子查询对应一个独立的、可回答的信息需求。这里有个实操技巧让Agent在分解查询时同时输出每个子查询的预期答案类型。比如“A的成本构成”预期返回一个列表“B的成本构成”预期返回一个列表。这样在后续整合时Agent能更快判断检索结果是否符合预期。3.3 终止条件的设定避免无限循环Agentic RAG最怕的就是Agent陷入“再查一次”的循环查了十轮还在查。必须设定明确的终止条件。我通常设三层终止条件。第一层是最大轮次限制比如最多检索5轮超过就强制进入生成阶段。第二层是边际收益判断如果新一轮检索的结果和已有信息高度重复说明再查也没用终止。第三层是置信度阈值Agent对当前信息的置信度超过某个阈值就认为够了。这三层条件里边际收益判断最难实现但最重要。我的做法是让Agent在每轮检索后对比新结果和已有信息的语义相似度如果相似度超过0.9就判定为重复不再继续。这个阈值需要根据实际数据调0.9是我在几个项目里试出来的经验值太高会漏掉补充信息太低会重复检索。注意终止条件不要只依赖轮次限制。我见过一个实现设了最大3轮结果Agent在第2轮就检索到了关键信息但因为没到3轮又强行查了一轮反而引入了噪声。轮次限制应该是兜底不是主要判断依据。4. 工具选型与检索策略向量、关键词还是混合4.1 向量检索的适用边界向量检索是RAG的默认选择但它不是万能的。向量检索擅长语义相似的匹配用户问“如何提升客户满意度”它能召回“改善用户体验的方法”这类语义相近但用词不同的内容。这是它的优势。但向量检索有两个明显短板。一是精确匹配能力弱用户问某个具体编号、具体名称向量检索可能召回一堆语义相近但编号不对的内容。二是对长文档的细粒度定位差一篇长文档整体向量化后检索时只能定位到文档级别无法精确定位到段落。在Agentic RAG里向量检索通常作为第一轮粗筛工具快速召回一批相关文档然后由Agent判断是否需要更精确的检索。4.2 关键词检索的补位价值关键词检索比如BM25在Agentic RAG里经常被低估。它擅长精确匹配用户问具体术语、编号、名称时关键词检索能精准命中。而且关键词检索对低频词更敏感向量检索容易把低频词的信息淹没在语义空间里。我的做法是把向量检索和关键词检索都封装成工具让Agent根据问题类型选择。如果问题里包含明显的专有名词、编号、代码优先用关键词检索如果是开放式的语义问题优先用向量检索。这个判断逻辑可以写在Agent的系统提示里也可以做成一个轻量的分类器。4.3 混合检索的融合策略更常见的做法是混合检索同时跑向量和关键词然后融合结果。融合策略有两种主流方式。一种是加权融合给向量得分和关键词得分各分配权重加权求和后排序。权重的设定依赖数据特点我通常从0.5:0.5开始调如果数据里专有名词多就提高关键词权重。另一种是RRFReciprocal Rank Fusion不依赖具体得分只看排名。每个结果在各自检索列表里的排名取倒数后相加得到融合得分。RRF的好处是不用调权重对得分尺度不敏感我在多个项目里用下来觉得更省心。融合之后Agent拿到的是一个统一排序的结果列表。但要注意融合结果里可能仍然包含不相关的片段Agent需要进一步筛选。这时候可以让Agent对每个片段做相关性打分只保留高分片段进入下一轮。4.4 工具描述的写法直接影响Agent选择这是一个容易被忽视但极其重要的细节Agent选择哪个工具很大程度上取决于工具的描述怎么写。如果向量检索工具的描述是“检索相关文档”关键词检索工具的描述也是“检索相关文档”Agent根本分不清该用哪个。我的写法是让每个工具的描述都包含适用场景、输入格式、输出格式、典型示例。比如向量检索工具描述成“适用于语义相似查询输入自然语言问题返回语义相关的文档片段适合开放式问题”关键词检索工具描述成“适用于精确匹配查询输入包含专有名词或编号的问题返回包含这些关键词的文档片段”。这样Agent在推理时能根据问题特征明确选择工具。我实测下来优化工具描述后Agent选错工具的概率下降了一半以上。5. 实操落地从零搭建一个Agentic RAG原型5.1 环境准备与依赖选型搭建原型不需要太重的技术栈。我的最小可行配置是一个支持工具调用的LLM接口、一个向量库、一个关键词检索库、一个编排框架。向量库我常用本地轻量方案比如基于FAISS或Chroma够用且部署简单。关键词检索用BM25实现Python生态里有现成库。编排框架可以用LangGraph或类似的Agent编排工具它能把“决策—工具调用—观察—再决策”的循环用图结构表达出来比手写while循环清晰得多。依赖装好后先跑通一个最小闭环用户提问 → Agent判断需要检索 → 调用向量检索 → 拿到结果 → Agent判断信息够不够 → 生成答案。这个闭环跑通了再逐步加工具、加记忆、加终止条件。5.2 检索工具的具体实现向量检索工具的核心是文档切分策略。切分粒度直接影响检索质量。切太粗一个片段里混杂多个主题检索时定位不准切太细片段缺乏上下文模型拿到也理解不了。我的经验是按语义段落切分每段300到500字相邻段落保留50到100字重叠。重叠是为了避免关键信息刚好被切在边界上。切分后每个片段单独向量化存入向量库同时保留来源文档、段落位置等元数据方便后续追溯。关键词检索工具的实现相对简单把文档片段分词后建倒排索引即可。但要注意中文分词的处理通用分词器对专业术语的切分可能不准需要根据领域词典做定制。两个工具的输出格式要统一都返回“片段内容 来源 得分”的结构这样Agent处理起来不用区分工具来源。5.3 Agent决策循环的代码骨架决策循环是整个系统的核心。用伪代码表达大致是这样的def agentic_rag_loop(user_query, max_rounds5): memory init_memory(user_query) for round in range(max_rounds): decision agent_decide(memory) if decision.action generate: return generate_answer(memory) elif decision.action retrieve: query decision.query tool decision.tool results call_tool(tool, query) if is_redundant(results, memory): return generate_answer(memory) memory.add(results) return generate_answer(memory)这段骨架里agent_decide是最关键的函数它接收当前记忆输出下一步动作。动作空间包括“生成答案”“调用某工具检索”“改写查询后再检索”等。is_redundant负责判断新结果是否重复避免无效循环。实际实现时agent_decide通常是一次LLM调用把当前记忆和可用工具列表塞进Prompt让模型输出结构化的决策结果。这里要特别注意输出格式的约束用JSON Schema或类似机制强制模型输出可解析的结构否则解析失败会导致整个循环崩溃。5.4 记忆压缩的实操技巧多轮检索后记忆里会堆积大量片段。全部保留会撑爆上下文全部丢弃又丢失信息。我的做法是分层记忆原始片段保留在外部存储记忆里只保留每个片段的摘要和来源索引。摘要的生成可以在检索后立即做让模型对每个片段生成一句话概括。这样记忆里存的是“片段摘要 来源ID”需要详细内容时再根据ID回查原始片段。这样既控制了上下文长度又不丢失信息。另一个技巧是按相关性动态调整记忆。每轮检索后重新评估已有片段的相关性把低相关片段移出活跃记忆只保留高相关的。这样记忆始终聚焦在当前问题上不会被早期无关检索干扰。6. 常见问题与排查技巧实录6.1 Agent不检索直接回答怎么办这是最常见的初期问题。Agent拿到问题后直接用自己的知识回答根本不调用检索工具。原因通常是系统提示里没有强调“必须基于检索结果回答”或者工具描述不够吸引Agent使用。解决办法是在系统提示里明确写“对于任何涉及具体事实、数据、文档内容的问题必须先调用检索工具获取信息不得直接回答。”同时可以在Few-shot示例里放几个“先检索再回答”的样例让Agent模仿。如果还是不行可以在决策层加一个前置判断先用一个轻量分类器判断问题是否需要检索需要则强制进入检索流程。这个分类器可以很简单基于关键词规则都行。6.2 检索结果不相关怎么调整检索结果不相关排查顺序是先看查询词再看切分粒度最后看向量模型。查询词的问题最常见。用户原问题往往不适合直接检索需要改写。检查Agent是否做了查询改写改写后的查询是否准确表达了信息需求。切分粒度的问题也常见。如果片段太长里面混杂多个主题检索时向量被平均化定位不准。试着把切分粒度调细看效果是否改善。向量模型的问题相对少见但如果前面都排查了还是不行可以考虑换一个更适合领域的向量模型。不同模型在不同领域的表现差异很大通用模型在专业领域可能不如领域微调过的模型。6.3 多轮检索后答案反而变差这个问题很隐蔽。原因是多轮检索引入了噪声或者不同来源的信息冲突模型整合时反而混乱。排查方法是逐轮检查检索结果看哪一轮引入了不相关或矛盾的信息。如果某轮结果质量差检查该轮的查询词和工具选择是否合理。另一个原因是记忆里新旧信息冲突。比如第一轮检索到“成本是100”第二轮检索到“成本是120”两个信息都在记忆里模型不知道该信哪个。解决办法是在记忆层加冲突检测发现矛盾时让Agent专门做一次裁决检索或者标记冲突让生成层明确说明存在不同说法。6.4 常见问题速查表问题现象可能原因排查方向解决思路Agent不检索直接答提示未强调检索必要性检查系统提示明确要求先检索加Few-shot示例检索结果不相关查询词未改写检查查询改写逻辑结合对话历史改写查询检索结果不相关切分粒度过粗检查片段长度调细切分增加重叠多轮后答案变差引入噪声信息逐轮检查结果加相关性过滤剔除低分片段多轮后答案变差信息冲突检查记忆内容加冲突检测与裁决机制循环不终止终止条件缺失检查循环逻辑加轮次限制和边际收益判断上下文超长记忆未压缩检查记忆管理分层记忆只存摘要6.5 几个踩过坑才明白的经验第一个经验不要追求一次到位。我最初想设计一个能处理所有情况的Agent结果提示词越写越长Agent反而更迷茫。后来改成先支持两三种核心问题类型跑通后再逐步扩展效果好得多。第二个经验日志要记全。Agentic RAG的决策过程是黑盒出问题时如果没记日志根本不知道Agent为什么做了某个决策。我现在的做法是每一轮决策都记录当前记忆摘要、Agent的推理过程、选择的动作、工具返回结果摘要。这些日志在排查时是救命稻草。第三个经验成本要提前算。多轮检索意味着多次LLM调用和多次检索调用成本比传统RAG高不少。上线前一定要估算平均轮次和单次成本设定预算上限。我见过一个项目没做成本控制上线后账单超预期好几倍。第四个经验评估要分环节。不能只看最终答案对不对要分环节评估检索环节的召回率、决策环节的准确率、生成环节的忠实度。分环节评估才能定位问题出在哪。我通常会用一批标注好的测试问题分别跑各个环节看哪个环节拖后腿。7. 效果评估与迭代方向7.1 分环节评估指标的设计Agentic RAG的评估比传统RAG复杂因为多了决策环节。我通常设三组指标。检索环节看召回率和精确率召回率衡量该查到的信息有没有查到精确率衡量查到的信息有多少是相关的。这两个指标要分开看召回率低说明查询改写或工具选择有问题精确率低说明切分或过滤有问题。决策环节看轮次合理性和工具选择准确率轮次合理性衡量Agent是否在合适的时机停止检索工具选择准确率衡量Agent是否选对了工具。这两个指标反映Agent的推理质量。生成环节看忠实度和完整性忠实度衡量答案是否基于检索结果没有编造完整性衡量答案是否覆盖了用户问题的所有方面。这两个指标反映最终输出质量。7.2 迭代优化的优先级拿到评估结果后优化要有优先级。我的经验是先修检索再修决策最后修生成。因为检索是源头检索不准后面再怎么优化都是白搭。检索修好后决策环节的问题才会暴露出来这时候再调决策逻辑。生成环节的问题通常最少因为模型本身能力够强只要前面喂给它的信息对生成质量一般不会差。每次迭代只改一个环节改完重新评估确认该环节指标提升且其他环节没有退化。这样能清楚知道每个改动的影响避免多个改动混在一起说不清效果。7.3 后续可以扩展的方向跑通基础版后有几个方向可以继续深挖。一是引入更多工具比如结构化数据库查询、外部API调用让Agent能处理需要实时数据的问题。二是加入自我反思机制让Agent在生成答案后自己检查一遍发现遗漏再补检索。三是做领域适配针对特定领域优化查询改写模板和工具描述提升领域问题的处理效果。不过我的建议是不要贪多先把核心场景做扎实。Agentic RAG的复杂度已经够高了每加一个功能都会带来新的调试成本。我个人的节奏是一个功能稳定运行两周、评估指标达标后再考虑加下一个。最后分享一个我在实际项目里体会最深的心得Agentic RAG的效果七分靠检索质量三分靠Agent调度。很多人把精力花在优化Agent的推理提示上却忽视了检索本身的质量。实际上如果检索能稳定返回高质量片段即使Agent调度逻辑简单一点整体效果也不会差。反过来检索质量差Agent再聪明也巧妇难为无米之炊。所以如果你刚开始做先把检索环节打磨好这是投入产出比最高的地方。
阅读完成 · 觉得有帮助？
