1. 从"检索增强"到"智能体驱动检索"的认知转变
很多人第一次接触 RAG，脑子里浮现的画面是这样的：用户问一个问题，系统把问题转成向量，去向量库里捞几段最相似的文本，拼进提示词，丢给大模型生成答案。这套流程在 2023 年几乎成了标配，也确实解决了一部分"模型不知道私有知识"的问题。但真正把它放到生产环境里跑上几周，你就会发现一个尴尬的事实：固定流水线的 RAG，本质上是一次性的、盲目的检索。
为什么说它盲目？因为传统 RAG 的检索动作是"一次性"的——它不会判断这个问题到底需不需要检索，不会评估检索回来的内容质量够不够，更不会在发现检索结果跑偏时换个关键词重新查一遍。它就像一个只会执行一次动作的机械臂，你让它抓东西，它就抓一次，抓没抓到、抓得对不对，它不管。
Agentic RAG 要解决的正是这个问题。它的核心思路是：把"检索"这个动作从固定流水线里拆出来，交给一个具备决策能力的智能体去调度。这个智能体可以决定要不要检索、检索几次、用什么查询词、检索到的内容是否足够、不够的话下一步该干什么。换句话说，检索不再是流程中的一个固定环节，而是智能体工具箱里的一个可调用工具。
这个转变听起来只是"加了个判断"，但实际影响是结构性的。传统 RAG 的失败模式往往是"检索没命中，然后模型硬编"，而 Agentic RAG 的失败模式变成了"智能体判断失误，多绕了几圈"。前者是静默失败，后者至少是可观测、可干预的。对于做企业级应用的人来说，可观测性往往比一次性成功率更重要。
这篇文章我会从零讲清楚 Agentic RAG 到底是什么、和普通 RAG 的本质区别在哪、一个最小可用的智能体检索系统该怎么搭、里面有哪些坑是我自己踩过的。适合已经了解基础 RAG、想往智能体方向进阶的开发者，也适合正在评估"要不要上 Agentic RAG"的技术负责人。
2. Agentic RAG 到底"智能"在哪里：四个决策点拆解
要理解 Agentic RAG，不能停留在"它更聪明"这种模糊描述上。我们得把"智能"拆成具体的决策点，看看智能体在哪些环节做了传统 RAG 做不了的事。
2.1 决策点一：要不要检索
传统 RAG 是无条件检索的。用户问"你好"，它也去向量库捞一遍，然后拼一堆无关内容给模型。这不仅浪费算力，还会污染上下文，让模型被无关信息干扰。
Agentic RAG 的第一个决策就是路由判断：这个问题需要查知识库吗？还是模型自己就能回答？还是需要调用别的工具（比如计算器、数据库查询）？这个判断通常由一个轻量级的分类器或者大模型自己完成。我实测下来，用大模型做路由判断的准确率明显高于小模型分类器，但延迟会高一些，需要根据场景权衡。
2.2 决策点二：用什么查询词检索
这是最容易被低估的一环。用户的原话往往不适合直接拿去检索。比如用户问"你们那个退货政策是几天来着"，直接拿这句话去向量检索，命中率可能很低，因为知识库里写的是"自签收之日起 7 个自然日内可申请无理由退货"。查询词和文档之间存在表述鸿沟。
Agentic RAG 会让智能体先对用户问题做查询改写，生成一个或多个更适合检索的查询。常见做法包括：把口语化问题改写成书面表述、把一个问题拆成多个子问题分别检索、生成同义词扩展查询。我一般会让智能体生成 2 到 3 个不同角度的查询词，然后并行检索后合并结果，召回率提升非常明显。
2.3 决策点三：检索结果够不够
传统 RAG 拿到 top-k 结果就直接用了，不管这些结果相关不相关。Agentic RAG 会加一个相关性评估环节：让模型判断检索回来的内容是否真的能回答问题。如果评估结果是"不够"，就触发下一步动作——可能是换个查询词重试，可能是扩大检索范围，也可能是直接告诉用户"知识库里没有相关信息"。
这个环节的价值在于避免模型硬编。我见过太多案例，检索回来的是一堆不相关内容，模型为了"完成任务"，硬生生编出一个看似合理的答案。加了相关性评估之后，这种情况能减少一大半。
2.4 决策点四：什么时候停止
这是智能体系统里最微妙的问题。检索可以一直重试，但你不能让它无限循环下去。Agentic RAG 需要设定停止条件：达到最大检索轮次、相关性评分超过阈值、或者连续两轮检索结果没有改善，都应该触发停止。
我自己的经验是，最大轮次设 3 轮比较合适。超过 3 轮还没找到相关内容，大概率是知识库里真的没有，继续重试只是浪费 token。这个数字不是拍脑袋定的，是我在几个不同知识库上跑下来，观察"第几轮开始收益递减"得出的经验值。
把这四个决策点串起来，一个完整的 Agentic RAG 流程大致是这样的：接收问题 → 判断是否需要检索 → 改写查询词 → 执行检索 → 评估相关性 → 不够则调整重试 → 够了则生成答案。这个流程不是线性的，而是一个带循环的图结构，这也是为什么很多实现会用状态机或者图编排框架来做。
3. 搭建最小可用 Agentic RAG 的完整路径
理论讲完了，接下来是实操。我会用一个"企业知识库问答"的场景，从零搭一个最小可用的 Agentic RAG。技术栈选择上，我倾向于用现成的编排框架而不是纯手写，因为状态管理和循环控制手写起来很容易出 bug。
3.1 技术选型：为什么我最终选了图编排而不是链式编排
早期我用链式编排（Chain）做过一版，很快就遇到瓶颈。链式结构是单向的，一旦走到下一步就没法回头，而 Agentic RAG 的核心恰恰是"回头重试"。你当然可以用各种 hack 在链里塞循环，但代码会变得非常难维护。
图编排（Graph）天然支持循环和条件分支，节点之间可以任意跳转，状态在节点间传递。这跟 Agentic RAG 的"检索-评估-重试"循环结构是天然契合的。我现在的项目基本都用图编排来做智能体流程，链式编排只用在那些确实没有分支的简单场景。
具体到框架，LangGraph 是目前比较成熟的选择，它的状态管理和检查点机制对调试非常友好。如果你用 Java 技术栈，Spring AI 也在往这个方向走，虽然生态还不如 Python 那边丰富，但企业级项目里用起来更顺手。
3.2 状态设计：整个系统的"记忆"该怎么组织
图编排的核心是状态（State）。所有节点读写同一个状态对象，状态设计得好不好，直接决定了系统能不能跑通。
我的状态对象一般包含这几个字段：
class RAGState(TypedDict): question: str # 原始问题 rewritten_queries: list # 改写后的查询词列表 retrieved_docs: list # 检索到的文档 relevance_score: float # 相关性评分 retry_count: int # 已重试次数 final_answer: str # 最终答案 need_retrieval: bool # 是否需要检索这里有个细节值得说：retry_count 必须放在状态里，不能放在节点内部。因为节点每次执行都是独立的，如果计数器放在节点里，每次重试都会重置，循环就永远停不下来。我第一次写的时候就犯了这个错，跑起来直接死循环，排查了半天才发现是计数器位置放错了。
3.3 节点实现：路由、改写、检索、评估、生成
整个图由五个核心节点组成，我逐个说实现要点。
路由节点负责判断是否需要检索。实现上就是给大模型一个提示词，让它输出"需要检索"或"不需要检索"。提示词里要明确列出哪些类型的问题需要检索（涉及具体事实、数据、政策的问题），哪些不需要（闲聊、通用常识、纯计算）。这个节点的输出直接决定流程走向。
改写节点把用户问题转成检索友好的查询词。我一般让它输出 JSON 格式的查询列表，方便后续解析。提示词里会强调"生成 2 到 3 个不同角度的查询，覆盖问题的不同侧面"。实测下来，多查询并行检索的召回率比单查询高 30% 以上。
检索节点执行实际的向量检索。这里有个工程细节：多个查询词要并行检索，然后做结果去重和合并。去重不能简单按文档 ID，因为同一文档的不同片段可能都相关，我一般按"文档 ID + 片段内容哈希"去重，保留相关性最高的那个。
评估节点判断检索结果是否足够。让模型对每个检索结果打相关性分数（0 到 1），然后取最高分作为整体评分。如果最高分低于阈值（我一般设 0.7），就判定为"不够"，触发重试。这里要注意，评估的提示词要给出明确的评分标准，否则模型打分很随意。
生成节点基于检索结果生成最终答案。提示词里要强调"只基于提供的资料回答，资料里没有的信息不要编造"。如果评估节点判定资料不足，生成节点应该输出"根据现有资料无法回答该问题"，而不是硬编。
3.4 条件边：控制循环的关键
节点之间的跳转由条件边控制。路由节点之后，根据 need_retrieval 决定走检索分支还是直接生成。评估节点之后，根据 relevance_score 和 retry_count 决定是重试还是生成。
重试的逻辑是这样的：如果评分不够且 retry_count 小于 3，就回到改写节点重新生成查询词；如果评分够了或者已经重试 3 次，就进入生成节点。这里有个优化点：重试时可以让改写节点参考上一轮的失败原因，生成不同的查询词，避免重复检索同样的内容。
def should_retry(state): if state["relevance_score"] >= 0.7: return "generate" if state["retry_count"] >= 3: return "generate" return "rewrite"这段逻辑看起来简单，但阈值和轮次这两个参数需要根据你的知识库特点调。知识库内容密集、表述规范的，阈值可以设高一点；知识库内容零散、口语化的，阈值要设低一点，否则会一直重试。
4. 实测中暴露的五个典型问题与应对
上面讲的是"理想流程"，但实际跑起来，问题一个接一个。我把自己踩过的坑整理出来，这些是文档里不会写、只有真正跑过才知道的东西。
4.1 查询改写反而降低了召回率
这是最反直觉的一个坑。我一开始以为改写一定比不改写好，结果在某些场景下，改写后的查询词反而偏离了原意，召回率不升反降。
原因出在改写提示词上。如果提示词让模型"自由发挥"，它可能会加入很多原问题没有的假设，导致查询词跑偏。比如用户问"退款要多久"，模型改写成"退款处理时效和到账时间说明"，看起来更专业，但如果知识库里写的是"退款周期"，反而匹配不上。
我的应对方法是：改写提示词里明确要求"保持原问题的核心意图，只做表述规范化，不要添加原问题没有的信息"。同时保留原始查询词一起检索，把改写查询和原始查询的结果合并，这样即使改写跑偏，原始查询还能兜底。
4.2 相关性评估的"假高分"问题
评估节点用大模型打分，会遇到一个经典问题：模型倾向于给高分。你让它对检索结果打 0 到 1 的分，它经常给 0.8、0.9，哪怕内容其实不太相关。
这个问题的根源是提示词设计。如果提示词只是笼统地说"评估相关性"，模型没有明确的判断标准，就会凭感觉打分。我的做法是给出具体的评分锚点：0.9 到 1.0 表示"直接回答了问题"，0.7 到 0.9 表示"包含相关信息但需要推理"，0.5 到 0.7 表示"部分相关"，0.5 以下表示"不相关"。有了具体锚点，模型打分明显更靠谱。
另一个技巧是让模型先给出判断理由，再给分数。强制它先分析"这段内容和问题的关系是什么"，再打分，能有效抑制乱打分。这个技巧在多个评估任务上都验证过，效果稳定。
4.3 多轮重试的 token 成本失控
Agentic RAG 比传统 RAG 贵，这是必然的。每多一轮检索和评估，就多几次大模型调用。我实测下来，一个平均 2 轮检索的 Agentic RAG，token 消耗大约是传统 RAG 的 3 到 4 倍。
控制成本有几个手段。第一，路由和评估用便宜的小模型，只有最终的答案生成用大模型。这两个环节的判断任务相对简单，小模型完全够用。第二，设置合理的最大轮次，我前面说的 3 轮是经验值，你可以根据成本预算调整。第三，缓存检索结果，相同或相似的查询词直接命中缓存，避免重复检索。
还有一个容易被忽略的点：评估节点不需要对每个检索结果都打分。如果检索回来 10 个片段，你只需要评估相关性最高的前 3 个，后面的本来就不太可能被用到。这样能省下不少 token。
4.4 检索结果去重后反而丢了关键信息
前面提到多查询并行检索后要去重。我一开始按文档 ID 去重，结果发现有些关键信息丢了。原因是同一文档的不同片段可能都相关，按文档 ID 去重会把它们合并成一个，丢失了片段级别的信息。
后来改成按"文档 ID + 片段内容哈希"去重，保留每个独立片段。但这样又带来新问题：同一文档的多个片段可能内容高度重叠，都塞进上下文会浪费 token。最终的方案是先按片段去重，再按相关性排序，只保留 top-k 个片段，k 根据上下文窗口大小动态调整。
4.5 智能体"过度思考"导致延迟过高
Agentic RAG 的另一个代价是延迟。传统 RAG 一次检索一次生成，可能 2 秒出结果；Agentic RAG 走完路由、改写、检索、评估、重试、生成，可能要 8 到 10 秒。
对于交互式场景，这个延迟是致命的。我的优化思路是分级响应：先用传统 RAG 快速给一个初步答案，同时后台跑 Agentic RAG 的完整流程，等完整结果出来后再更新。这样用户感知到的首屏延迟还是 2 秒左右，体验好很多。
另一个手段是并行化。路由判断和查询改写其实可以并行做，不用等路由结果出来再改写。检索多个查询词也是并行的。把这些能并行的环节并行起来，整体延迟能压下来不少。
5. 从能跑到好用：几个值得投入的优化方向
系统能跑通只是第一步，真正拉开差距的是那些"让它更好用"的优化。这部分我分享几个投入产出比比较高的方向。
5.1 给检索加上元数据过滤
纯向量检索有个天然缺陷：它只看语义相似度，不看其他维度的约束。用户问"2024 年的销售政策"，向量检索可能把 2023 年的政策也捞回来，因为语义上太像了。
解决办法是在检索时加上元数据过滤。给每个文档片段打上时间、部门、文档类型等元数据标签，检索时先按元数据过滤，再做向量相似度排序。这个改动不大，但对准确率的提升非常明显，尤其是在文档有时间维度或分类维度的场景下。
元数据的提取可以在文档入库时用大模型自动完成，也可以人工标注。我一般用大模型自动提取，准确率能到 90% 以上，剩下的人工抽检修正。
5.2 混合检索：向量加关键词
向量检索擅长语义匹配，但对精确的关键词匹配反而不如传统的关键词检索。比如用户问一个具体的产品型号"X200-Pro"，向量检索可能匹配到一堆相似型号，而关键词检索能精确命中。
混合检索就是把向量检索和关键词检索（比如 BM25）的结果合并，各取所长。实现上，两路检索并行执行，然后用倒数排名融合（RRF）算法合并结果。RRF 的好处是不需要调权重，直接按排名融合，工程上很省心。
我实测下来，混合检索在专业术语密集的场景下，召回率比纯向量检索高 20% 到 30%。这个提升在技术文档、法律条文、医疗记录这类场景里尤其明显。
5.3 把评估结果反馈给检索
这是一个进阶优化。评估节点判断"检索结果不够"时，不只是触发重试，还可以把"为什么不够"的信息反馈给改写节点。比如评估发现"检索结果缺少关于退款时效的具体天数"，改写节点就可以针对性地生成"退款到账天数"这样的查询词。
这个反馈机制让重试变得"有的放矢"，而不是盲目换词。实现上，评估节点的输出除了分数，还要包含一段"缺失信息描述"，改写节点读取这段描述来调整查询方向。这个改动让我的系统在重试场景下的命中率提升了不少。
5.4 可观测性：把每一步都记下来
Agentic RAG 的流程比传统 RAG 复杂得多，出问题时如果不知道是哪一步出了问题，排查会非常痛苦。所以可观测性必须从一开始就做，不能等出了问题再补。
我的做法是记录每一步的输入输出：路由判断的结果和理由、改写生成的查询词、检索返回的文档 ID 和分数、评估的评分和理由、最终生成的答案。这些日志存下来，出问题时可以完整回放整个流程。
更进一步，可以做一个简单的可视化界面，把整个流程的每一步展示出来。调试的时候一眼就能看出是哪一步跑偏了。这个投入在项目初期看起来有点重，但后期排查问题的效率提升是巨大的。
6. 关于 Agentic RAG 的几个常见误解
在跟同行交流的过程中，我发现大家对 Agentic RAG 有一些普遍的误解，这里澄清几个。
误解一：Agentic RAG 一定比传统 RAG 好。不一定。如果你的场景是简单的 FAQ 问答，知识库内容规范、问题类型单一，传统 RAG 完全够用，上 Agentic RAG 只是徒增复杂度和成本。Agentic RAG 的价值在复杂场景——问题类型多样、需要多跳推理、知识库内容零散。选型要看场景，不要为了"先进"而先进。
误解二：智能体越多越好。有人一听"多智能体"就觉得高级，恨不得每个环节都搞一个独立智能体。实际上，智能体之间的通信成本很高，协调逻辑也很复杂。我建议从单智能体起步，把检索、评估、生成都作为这个智能体的工具或节点，等确实遇到瓶颈了再考虑拆分。多智能体不是目标，解决问题才是。
误解三：上了 Agentic RAG 就不需要调提示词了。恰恰相反，Agentic RAG 对提示词的要求更高。因为每个节点都依赖提示词来引导模型行为，提示词写得好不好，直接决定整个系统的表现。我在提示词上花的时间，比写代码的时间还多。
误解四：评估节点可以省掉。有人觉得评估节点只是"锦上添花"，为了省成本就砍掉。但评估节点是 Agentic RAG 区别于传统 RAG 的关键——没有它，系统就失去了"判断检索质量"的能力，退化成"多轮盲目检索"。省这个节点的成本，换来的是准确率的大幅下降，不划算。
7. 我个人的一些实操体会
最后分享几点纯个人经验，不一定对所有人适用，但都是我实际跑项目攒下来的。
第一，先用传统 RAG 跑通，再逐步加智能体能力。不要一上来就搭完整的 Agentic RAG，那样出问题时你根本不知道是哪一环的问题。我的做法是先搭一个最简的传统 RAG，跑通之后，逐个加上路由、改写、评估、重试，每加一个就测一轮，确认没问题再加下一个。这样每一步的收益和问题都清清楚楚。
第二，评估阈值和重试轮次一定要用真实数据调。我见过有人直接抄别人的配置，结果在自己的知识库上表现很差。这两个参数跟知识库的特点强相关，必须拿真实问题集跑一遍，看准确率和成本的曲线，找到平衡点。我一般会准备 50 到 100 个真实问题做测试集，跑几轮不同配置，对比效果。
第三，不要迷信"全自动"。Agentic RAG 再智能，也会有判断失误的时候。对于关键场景，我会加一个人工兜底机制：当系统连续重试都找不到答案时，转人工处理，而不是硬编一个答案。这个机制看起来"不够智能"，但在实际业务里，它避免了很多因为错误答案导致的麻烦。
第四，关注 token 成本，但不要因噎废食。Agentic RAG 确实贵，但如果它能把准确率从 60% 提到 85%，这个成本是值得的。关键是要算清楚账：错误答案带来的损失，和额外 token 的成本，哪个更大。在大多数企业场景里，前者远大于后者。
第五，保持对新技术的好奇，但别急着上生产。Agentic RAG 这个方向还在快速演进，新的框架、新的模式层出不穷。我的态度是积极尝试、谨慎上线。新东西先在测试环境跑，验证有效果、稳定了，再考虑上生产。追新不是目的，解决问题才是。
