你已经搭了个知识库问答，检索一次、拼进上下文、让模型回答，简单问题还行，一碰到「先查 A 再拿 A 的编号去查 B」就答不上来。这时候多半会听到别人建议你上 Agentic RAG。这篇不吹概念，把它和传统 RAG 的差别、真实的执行流程、什么时候不该用，按开发者视角捋一遍。
你已经搭了个知识库问答，检索一次、拼进上下文、让模型回答，简单问题还行，一碰到「先查 A 再拿 A 的编号去查 B」就答不上来。这时候多半会听到别人建议你上 Agentic RAG。这篇不吹概念，把它和传统 RAG 的差别、真实的执行流程、什么时候不该用，按开发者视角捋一遍。
一句话概括：Agentic RAG 是把「检索」从代码里写死的一步，变成模型手里可以自己决定调不调、调几次的工具。理解这一点，剩下的差别基本都是它的推论。至于各家模型和框架现在支持到什么程度，别听别人转述，到 /ai-dict/category/tech 核对当时的数字和说明。
传统 RAG 的固定流水线，卡在哪一步
传统 RAG 的骨架是写死的三步：把问题转成向量、召回一批片段、拼进上下文让模型答。整个过程中，检索这件事模型没参与决策——它只是被动接收别人塞给它的几段文字，既不知道这些片段从哪来，也无权要求再查一次。
- 只检索一次，而且用的是原始问题。问法含糊、需要拆成两个子问题、或者答案藏在一份要先被找到的文档里，第一跳就偏了
- 多跳和比较类问题最容易暴露：需要先拿到实体 A 的资料，再拿 A 里的字段去查 B，单轮检索拿不到这个链路
- 召回条数、相似度阈值、要不要重写查询，这些参数得靠人反复调，换一批文档就失效
- 召回了正确片段但模型没用上，这种失败和「压根没召回」看起来都是答错，病因却完全不同
| 问题形态 | 传统 RAG 表现 | 卡点在哪 |
|---|---|---|
| 单点事实查询 | 基本够用 | 无明显卡点 |
| 对照两份材料 | 容易只答一半 | 只能检索一次，拿不到第二份 |
| 按编号反查条款 | 经常查不到 | 需要先用别的内容定位到编号 |
| 问法含糊 | 召回偏题 | 没有机会先澄清或改写再查 |
| 需要跨文档串联 | 链路断裂 | 单轮拿不到中间结果 |
Agentic RAG 实际是怎么跑起来的
核心变化是模型手里多了「检索」这个工具。什么时候查、查几次、查完够不够，由模型自己判断，而不是代码里写死一个阈值。这一点决定了它的执行是循环结构，不是一条直线。
- 读题模型先判断现有上下文够不够回答。够就直接答，不够才进入检索。这一步能省掉大量无谓调用。
- 发出检索调用调用里带的查询可以是改写过的，不必等于用户原话。验证方法：把中间查询打日志，看它和原始问题差在哪。
- 读回结果模型拿到片段后判断是否还需要再查。这里的质量取决于片段有没有带来源标记，没标记它没法回溯。
- 收敛或兜底够了就组织答案并附引用；反复查不到就要有兜底话术，不能无限绕。
所以它天生是多轮的，和工具调用是同一套机制。常见增强件还包括查询改写、按文档结构切分而不是按字数硬切、给每个片段打来源标记、以及最终答案必须带引用。框架选型可以在 /stacks/frameworks 对照，别在第一步就锁死一家。
什么样的知识库值得上，什么情况别上
多轮检索意味着多次模型调用，延迟和单次成本都会上去。所以判断标准不是「这东西先不先进」，而是「你的问题有没有真的需要多跳」。下面这张表可以先自查一遍。
| 场景特征 | 建议 |
|---|---|
| 问题天然要多跳，比如对照两份制度 | 值得上 |
| 文档结构层次深：手册、法规、财报 | 值得上 |
| 对来源可追溯要求高 | 值得上 |
| 基本是单点事实查询 | 先别上 |
| 文档量小到能整篇进上下文 | 先别上 |
| 对延迟和单次成本极敏感 | 先别上 |
灰色地带要单独说：如果只是问法不规范导致召回差，先试查询改写和更好的切分，往往比整套 Agent 化便宜得多。判断顺序建议是——先量出当前方案在真实问题集上的失误类型，是「没召回」还是「召回了但没用上」，这两种病因对应的改法完全不同。不适用的情况也要讲清楚：如果你的用户能接受「答不上来」，那多轮检索带来的复杂度未必划算。
真要做，按这个顺序搭
- 准备问题集不是先接框架，而是攒 30 到 50 条真实问题，标上正确答案和它应该来自哪份文档。这是后面所有判断的依据。
- 检索做成独立函数把它接成一个工具，先在单轮里跑通，确认模型能正确发起调用并读懂返回结果。
- 再加多轮控制设检索次数上限、设无结果时的兜底话术、设超时，避免模型在一个查不到的问题上反复绕。
- 做评估回路每次改动都跑一遍问题集，看命中率和平均轮数分别怎么变。轮数涨了但命中率没涨，说明这轮检索是白花的。
这里有个容易被忽略的点：轮数本身不是指标，命中率才是。有人看到模型查了五次就以为效果好，其实后四次可能都在重复同一个方向。评估时最好把每次检索的查询词和命中情况都记下来，回看时一眼能看出是不是在原地打转。向量库的选型可以在 /stacks/vector-dbs 对照。
如果你还处在选型阶段，先别急着比模型价格。成本结构变了之后，单次调用便宜不一定整体便宜，因为一次问答可能触发多次调用。真要算账，到 /price-watch 核对当时的数字，把轮数乘进去再对比。
下一步把你现在这套知识库的失败案例翻出来，分成「没召回」和「召回了没用上」两类，各自数一下占比。这个比例会直接告诉你该不该上 Agentic RAG，比任何概念介绍都准。→常见问题
Agentic RAG 和普通 RAG 是不是替代关系？
不是。它是把检索从固定流水线变成模型可调用的动作，代价是调用次数和延迟上升。如果你的问题大多是单点事实查询，传统 RAG 更快更便宜，没必要换。判断标准是问题集里多跳类问题占比高不高，以及答错时是不是卡在「需要再查一次」上。
是不是必须用很贵的模型才能做？
不一定，但规划能力弱的模型会出现两种坏情况：明明该查却不查，或者反复查同一个查询。可以先在任务上试，同一份问题集跑下来，如果轮数明显偏高而命中率没提升，说明模型扛不住这个决策，再考虑换更强的。具体模型和当时的单价到 /models 与 /official-api 核对。
怎么判断我的 Agentic RAG 是不是白花钱？
看三个数：平均检索轮数、命中率、单次回答成本。理想情况是轮数增加换来了命中率明显提升。如果轮数涨了命中率不动，通常是检索本身质量差，加轮次只是在放大噪声，该回头去修切分和召回。延迟基线可以去 /tools/speed-test 先量一遍再对比。
