很多团队做知识库问答时，第一个能跑通的版本都是「用户提问→向量检索一次→拼进上下文→出答案」。上线后遇到多跳问题、需要比较多个来源、或者第一轮没召回就得放弃。这篇不重复讲 RAG 原理，而是把两种链路在「谁决定检索什么、检索几次、什么时候停」上的差异摊开，给你一份按场景选的判断清单和上线前的评测动作。
很多团队做知识库问答，第一个能跑通的版本几乎都是同一条路：用户提问，向量检索跑一次，把命中的片段塞进上下文，模型出答案。这套东西上线快、链路短，问题也来得快——遇到要多跳才能拼出答案的问题、需要横向比较几个来源的问题，或者第一轮没召回就彻底没辙。这时候团队就会开始琢磨：是不是该换成 Agentic RAG。
这篇不重讲 RAG 原理，只把两种链路在「谁决定检索什么、检索几次、什么时候停」这三个问题上的差异摊开，再给一份按场景选的判断清单和上线前的排查顺序。选型阶段最怕的不是选错，而是没搞清楚自己在选什么。
链路差异：谁在决定「检索什么」
传统 RAG 的检索动作是应用代码写死的：一次查询、一个索引、固定 top-k，模型拿到结果只负责读和生成，它没有「要不要再查一次」的发言权。Agentic RAG 把检索封装成模型可调用的工具，由模型根据当前缺口决定查什么、要不要改写 Query、要不要再来一轮。差别不在用不用向量库，而在决策权在代码手里还是模型手里。
判断自己的系统属于哪一侧，不用看架构图，看两个点就够：检索次数是不是代码固定的，查询串是不是模型改写的。只要有一项由模型动态决定，就落在 Agentic 这一侧。反过来，如果查询串永远是用户原话、检索永远一次，那不管中间套了多少层封装，本质还是传统 RAG。
工程上的四个控制点：步数、预算、超时、退出条件
Agentic 一侧最常翻车的方式不是模型不够聪明，而是循环没有上限。所以第一件事就是显式设死线：最大检索轮数、单次请求允许的总工具调用次数、整体超时时间。这三项要写进配置里，能被运维改，而不是藏在代码常量里靠人记得。
| 控制点 | 传统 RAG 的做法 | Agentic 的做法 |
|---|---|---|
| 检索次数 | 代码固定，通常一次 | 模型决定，必须设上限 |
| 查询串 | 用户原话或简单改写 | 模型按缺口改写，需要日志留痕 |
| 停止条件 | 检索完即停 | 低分退出、连续重复退出、预算耗尽退出 |
| 调优重心 | 召回质量与上下文拼装 | 循环控制与退出时机 |
| 成本估算 | 一次检索加一次生成 | 按最坏轮数估算，随轮数浮动 |
每一轮检索都要能被打断，这是硬要求：命中分数低于阈值直接退出，连续两轮召回内容高度重复就停，预算耗尽时返回当前最好的答案，而不是硬凑出一轮。另外，两种链路的监控指标不能混着看——传统 RAG 盯召回率和答案质量，Agentic 还要盯平均轮数、轮数分布、超限比例，指标口径混在一起就分不清是检索变差还是循环失控。
- 设死线：最大轮数、总工具调用次数、整体超时三项都要能配置
- 设退出：低分退出、重复召回退出、预算耗尽退出，三选一必配
- 估成本：按最坏轮数算，别按平均轮数算
- 分指标：召回质量归召回质量，循环健康度归循环健康度
日志与评测：怎么验证换方案后到底有没有变好
换链路之前先把日志补齐，否则改完根本说不清是变好还是变贵。每一轮至少记这五项：这一轮的查询串、召回条数与最高分、模型决定继续还是停下的理由、当前累计轮数、当前累计耗时。缺了轮次信息，一次很贵的请求你只能看到总账，看不到贵在哪一轮。
评测集要分两类来建：一类是单跳事实题，一类是需要多步才能拼出答案的题。只看单跳题，传统 RAG 会拿到虚高的分；只看多跳题，又会低估简单场景下多花的那部分延迟和成本。两类题的比例最好贴近真实提问分布，抽样方式可以到站内的评测方法相关页面看当时的做法说明。
- 先攒真实提问抽样近两周的真实提问，按单跳、多跳、比较型三类标注占比，别用自己编的题
- 单跳题先跑对照同一批单跳题分别跑两种链路，重点看答案质量有没有差异，如果没差异就不用往下比
- 多跳题看增量多跳题上对比两种链路的答案完整度，同时记录平均轮数和总耗时
- 按最坏轮数核成本拿日志里的轮数分布，到站内价格页面按当时的单价核对一轮大概花多少，再乘最坏轮数
有一个阶段不适用这套评测：语料每天大幅变动、问题分布完全未知的早期探索期。这时候先攒真实提问，等提问分布稳定下来再谈评测集，否则评测集建完就过期。
上线前排查顺序：按这个顺序逐项确认
这一节给的是顺序，不是清单——顺序错了会白干。很多团队一上来就调循环控制，结果底下的召回本身就不准，加多少轮都是放大错误。正确的做法是从问题分布往下排查，每一步确认了再走下一步。
| 顺序 | 确认什么 | 不通过怎么办 |
|---|---|---|
| 第一步 | 抽查真实提问，看单跳占比 | 单跳占比高就先别上 Agentic |
| 第二步 | 单独测召回质量，不看生成 | 召回不准先修检索，别加循环 |
| 第三步 | 把轮数上限调低跑一遍 | 超限时要返回可用答案而不是报错 |
| 第四步 | 接日志和告警，再谈灰度 | 轮数异常、耗时异常看不见就别放量 |
第三步值得单独说一句：人为把轮数上限调到很低跑一遍，看系统是返回当前最好答案，还是直接抛异常或者给出半截话。这一步能提前暴露退出条件写没写对，比上线后靠用户反馈发现要便宜得多。第四步接完日志再考虑灰度，灰度期间重点看轮数分布有没有长尾，长尾往往就是那几个会烧预算的问题类型。
下一步如果你正在两种链路之间犹豫，建议先去站内的中转站目录看一圈实际在跑的服务，再到价格追踪页按当时的单价核对一下多轮请求的成本量级，最后回到评测方法页面把对照用例的写法定下来——顺序别反。→常见问题
是不是所有知识库问答都该升级成 Agentic RAG？
不是。单跳事实型问题、语料集中、答案段落明确的场景，传统 RAG 更快更便宜也更可控。Agentic 的价值出现在需要多跳、需要比较多个来源、或者第一轮检索经常漏掉的场景。判断方式很土但有效：翻一批真实提问，数数有多少是「一次检索答不上来」的，占比低就先维持现状。
Agentic RAG 会不会一直循环停不下来？
会，所以上限必须写在代码里而不是提示词里。至少设三层：单请求最大检索轮数、总工具调用次数、整体超时。再配合退出条件，比如连续两轮召回内容高度重复、或最高分低于阈值就直接返回当前最好结果。上线前把上限调到最低跑一遍，看超限时的兜底答案能不能用。
换过去以后成本涨多少算正常？
没法给统一数字，取决于平均轮数和每轮带回来的文本量。做法是先按最坏轮数估算上限，再拿日志里的实际轮数分布看平均值。注意别只看 token 单价，要按「一次问答的总消耗」对比，Agentic 的输入侧上下文会随轮数累积。当前各家单价到 /official-api 与 /tools/model-cost-calculator 核对后再算。
