你可能已经跑通了普通 RAG，但遇到多跳问题、跨库检索、要跑好几个数据源才能答的场景就卡住：要么召回不全，要么模型自己乱编。这篇不聊原理，直接给一份场景清单——什么业务适合上 agentic RAG、什么情况下别上、上了之后超时并发降级日志评测该怎么做。
你可能已经把普通 RAG 跑通了：文档切片、向量检索、拼上下文、让模型答。可一遇到「要先查 A 再拿结果去查 B」「答案散在三个系统里」「模型不知道下一步该查哪」这类问题，就开始翻车——要么召回不全，要么模型自己编。agentic RAG 解决的就是这种「一次检索拿不全答案」的场景。
这篇不聊原理，直接给场景清单：什么业务值得上、什么情况别硬上、上了之后超时并发降级日志评测怎么做。判断的核心不是技术先不先进，而是你的问题里有没有「检索之外的动作」。全文提到的具体指标数字，都以站内相应页面的当时口径为准。
先判断：哪些问题非 agentic RAG 不可
最简单的一条判断标准：把问题拿给一个人看，他能不能只翻一份资料就答出来。能，就普通 RAG；不能，才考虑 agentic。上 agentic 一定更慢更贵，多一轮循环就多一次检索加一次模型调用，所以在决定之前先确认「多花这些成本能换来答对率提升」。
| 问题特征 | 建议方案 | 为什么 |
|---|---|---|
| 答案在一段文本里 | 普通 RAG | 多轮循环纯属浪费 |
| 固定文档 FAQ | 普通 RAG + 缓存 | 问法收敛，缓存命中率高 |
| 要跨两三份资料拼 | 可考虑 agentic | 单次检索覆盖不全 |
| 要先定位再查明细 | 可考虑 agentic | 需要一轮以上动作 |
| 要按条件换检索源 | 可考虑 agentic | 路由本身就是一步动作 |
| 首响延迟要求很紧 | 先用普通 RAG | 循环会把延迟拉高 |
- 动手做法：把最近答不好的二十来个问题抄出来，逐个标「缺的是哪一步」——缺检索词的补召回，缺外部动作的才考虑升级。
- 信号一：答案要跨两三份资料拼起来，单次检索怎么调参数都不全。
- 信号二：要先定位再查明细，比如先找到合同编号再翻具体条款。
- 信号三：要按条件换检索源，比如先查知识库，查不到再查工单库、订单库。
- 不适用的场景：答案就在一段文本里、在线客服首响卡得死、检索源只有一个且结构规整。
落地场景清单：按行业常见的六类任务
下面六类是目前见得比较多、也相对好落地的。每一类都要落到「谁用、一天多少次、答错代价多大」这三个数上，答错代价高的一律别做全自动，改成给人看草稿。
| 场景 | 典型任务 | 关键动作 | 落地要点 |
|---|---|---|---|
| 多跳问答与对比 | 法规条款比对、竞品参数对照 | 找到条款后再查适用范围 | 必须带原文出处 |
| 跨系统工单客服 | 先知识库再历史工单再订单 | 按命中结果决定下一站 | 降级时提示答案可能不全 |
| 代码与仓库问答 | 搜文件、读函数、追调用链 | 多轮定位到具体实现 | 权限要跟着代码库走 |
| 数据分析取数 | 查表结构、写 SQL、校验结果 | 失败自动重试改写 | 要有结果校验步骤 |
| 文档审阅与合规初筛 | 逐条比对规则清单 | 命中就翻原文确认 | 输出结论加引文 |
| 内部资料检索助手 | 跨多个文档库找线索 | 换库换关键词再找 | 告诉用户答案来自哪个库 |
挑场景的时候有个容易踩的坑：一上来就想做全自动。实际上答错代价高的场景，比如合同审查、财务取数、对外客服，更稳的做法是让 agentic RAG 出草稿加引文，人来做最后确认。这样既省了人工翻资料的时间，又不用背答错的责任。
工程落地：超时、并发、降级、日志四件事
agentic RAG 最容易出问题的地方不是效果，是跑飞。循环没上限、超时没分层、日志没记全，线上出了事故根本查不出来。下面四件事最好在接第一版的时候就定好，别等出问题再补。
- 超时分层单次检索、单轮循环、整体请求三个超时分开设，别用一个全局值。循环要有步数上限，比如最多几轮就强制收口，防跑飞。
- 并发与限流检索和模型调用分开算配额。批量场景用排队加退避，别一次性把配额打满，否则线上用户请求会被挤掉。
- 降级顺序先砍循环轮数，再砍检索条数，最后退回到单次检索加提示「答案可能不全」。不要直接把报错抛给用户。
- 日志必记会话 id、每轮检索词、命中的文档 id、每轮耗时与 token、最终是否降级，缺一项事后都没法复盘。
# 排查顺序：线上答不准时按这个链路走
# 1. 看日志里最后一轮的检索词还在不在原问题上
# 2. 看命中文档 id 有没有变化，是不是检索源挂了
# 3. 看轮数是不是被上限截断，没跑完就收口
# 4. 看是否触发了降级，降级后的答复有没有标提示
# 5. 以上都正常，再去调提示词或换模型怎么验收：别只看跑通，要看答对和便宜
验收最容易偷懒的地方是「我试了几个问题都答对了」就上线。agentic RAG 多了循环，变量也多了，必须有一批固定用例，每次改提示词或换模型都跑一遍，才能看出改动到底是变好还是变坏。
- 准备二十到三十条固定用例，覆盖「一轮能答」「必须多轮」「应该拒答」三类，缺哪类都说明覆盖不全。
- 看的指标：答对率、平均轮数、单次成本、p95 耗时。轮数涨了但答对率没涨，说明是检索有问题，不是循环不够。
- 对比口径：同一批用例下和普通 RAG 比一次，如果只快不准则果断回退，别为了「看起来高级」硬上。
- 数据源变了，比如文档更新、接口换版本，必须重跑一遍。具体基线数字到站内页面核对当时的数字。
agentic RAG 不是让模型更聪明，是让它多走几步路——但多走的每一步都要能超时、能降级、能复盘。下一步想掂量自己这套值不值得上、预算大概什么水位，去站内几个页面把当时的数字看一遍再决定，别凭感觉拍。→
常见问题
agentic RAG 和普通 RAG 到底差在哪，我该什么时候升级？
差别在于检索是自己发起并可能多轮：普通 RAG 固定查一次再拼进提示词，agentic 让模型判断要不要再查、查哪个源。升级信号是答案要跨多份资料或多步操作才拼得出来；如果一次检索就能答对，升级只会更慢更贵。
小团队只有一两个人维护，值得上吗？
看答错代价。用在高频、错了也没大损失的场景（内部问答、文档助手）可以试，先用两三个检索工具加步数上限跑通再说。要是用在对外承诺、金额、合规判断上，人工复核环节不能省，否则一次答错就够赔。
上了以后延迟很高、成本涨得快，先砍哪里？
先砍循环轮数和每轮检索条数，再看检索本身是不是召回太差导致反复重试。把每轮耗时和命中的文档 id 记全，通常能看出是卡在检索还是卡在模型，砍对地方比整篇回退有效。具体耗时基线可以用站内接口测速页先量一遍。
