what is agentic rag

你已经用普通 RAG 把资料接进模型了，结果一问需要跨文档比对、多跳推理的问题就答偏，或者要跑三四个来回才有答案。这时候你会听到别人说「该上 agentic RAG」。这篇不堆概念，先把两者的差别讲成一句话，再给你判断标准、最小落地步骤和常见坑，让你知道自己该不该换、换了之后先做什么。

一句话说清 agentic RAG 是什么

普通 RAG 是一条固定流水线：用户问一句，系统拿这句话去向量库捞一次，把捞到的几段塞进提示词，模型生成答案，结束。整个流程是人提前写死的代码，检索只有一次机会，好不好全看这一次捞得准不准。问题在于，很多真实问题不是一次检索能解决的——要么第一次关键词就没抓对，要么答案需要拆成几步、来回翻几次才能拼出来。

agentic RAG 换了个思路：把「检索」做成一个模型能反复调用的工具，由模型自己在决策循环里决定什么时候查、查什么词、查几次、拿到结果后要不要再查一次、什么时候够了可以收尾。关键词是控制权转移——流程不再由人写死的代码串起来，而是交给模型的判断。它不是一个具体产品，而是一种把检索嵌进 Agent 工具调用循环的架构形态。

打个比方：普通 RAG 像你走到图书馆前台，把问题交给管理员，他进去翻一次，拿几本书出来给你，好不好就看这一趟。agentic RAG 是直接给你一张借书证，你自己进去翻，翻不到可以换书架、换关键词，觉得够了再出来。代价是你要会找书——模型如果判断力不行，就会在里面乱转，翻得越多未必越准。

• 先判断你的问题是不是「一次检索就能答」：FAQ、单点事实类，普通 RAG 往往够用，上 Agent 是过度设计
• 再看问题有没有「多跳」特征：需要先查 A、用 A 的结论再查 B、最后综合，这类才值得把控制权交给模型
• 检查你的检索工具是否已经封装成可调用接口，能接受模型生成的查询参数并返回结构化结果
• 想清楚循环上限和兜底：查几次算够、超时怎么办、模型判断失误时怎么退回普通流程，这些要提前定
• 如果连基础检索质量都不稳，先修检索再谈 agentic，否则只是把一个坏流程变得更复杂

和普通 RAG 的差别到底在哪几处

把普通 RAG 和 agentic RAG 摆在一起看，最直观的不是架构图，而是这四件事：一次问答里检索被调了几次、查询词是谁定的、查不到之后怎么办、账单和等待时间差多少。这四点基本能决定你该用哪种方案。

• 看你的问题是不是一次检索就能答：事实型、单跳问答，普通 RAG 够用
• 看查询词是否需要多轮试探：口语化、指代多、需要拆解的问题，才轮到 agentic RAG 上场
• 看你对延迟的容忍度：面向用户的实时对话，多轮检索很容易让人等得不耐烦
• 看你对答案落空的容忍度：宁可说「没查到」也不接受硬编，agentic RAG 的失败处理更靠谱
• 看预算是否按 token 结算：同一个问题，检索轮次一多，消耗会明显被放大

所以别把 agentic RAG 当普通 RAG 的升级版无脑替换。它的价值集中在「问题本身就模糊、需要边查边想」的那一小撮场景；如果你的流量大头是简单的单跳问答，多轮决策带来的开销会直接吃掉收益。想先摸清自己问题分布，可以到站内的评测与指南页面看当时的分场景数据，再决定要不要上。

什么情况下别急着上 agentic RAG

先说结论：agentic RAG 不是普通 RAG 的升级版，而是换了一种工作方式。它把「检索一次、生成一次」变成「自己判断要不要再查、查什么、够不够」。这个能力有代价，代价是多轮调用、更多 token、更长的链路和更难预测的行为。所以判断标准不是「它更先进所以该上」，而是「我的问题是不是真的需要反复找」。下面四种情况，通常说明还不需要。

第一种也是最常见的一种：问题的答案就在某一篇文档、某一个表格、某一段说明里。用户问的是「这个参数是多少」「这条规则怎么写的」，检索一次拿到那一段就够了，模型不需要再决定「要不要换个关键词再查一遍」。这种情况下 agentic RAG 的循环没有信息可挖，只是把同一条路多走几遍。判断方法很简单：把最近一批真实提问拉出来，看答案是否能在一篇文档内找到，如果大多数都能，就没必要上循环。

第二种是问法固定。客服 FAQ、产品参数查询、政策条款对照这类场景，用户的表达方式高度重复，检索层的关键词和向量策略调一次就能长期复用。固定流水线的好处是可复现：改了哪一步、效果怎么变，你能对上号。agentic RAG 每一步都可能换策略，同一句话问两次走的路径都可能不同，出了问题不好归因。什么情况下这条不适用？当用户问法开始发散、需要跨多份材料拼答案时，固定流水线的天花板才会显现，那才是考虑循环的时点。

• 首字延迟有硬指标、用户等超过几秒就流失的产品，别把多轮循环放在主链路上
• 语料规模小到整段塞进上下文就能覆盖的，先试直接喂，省掉检索这一层
• 团队里没人能持续盯日志、看检索命中、调策略的，优先选行为可预测的固定流水线
• 需求还在快速变化、连问题边界都没定清楚的，先别把架构做复杂
• 如果你的问题确实需要跨文档、多跳、边查边判断，那才轮到 agentic RAG 上场

最后一条最容易被忽略：维护成本。agentic RAG 的行为不是完全可预测的，它今天这么走、明天可能换一条路，没有持续观察和调优的人，问题会以「偶尔答错」「偶尔特别慢」的形式出现，很难复现也很难修。固定流水线虽然上限低，但坏起来是稳定的坏，你能定位。做决定之前先问一句：接下来三个月，谁负责看这个循环的日志和效果？答不上来，就先别上。

什么样的需求会长成 agentic RAG

不是所有问答都值得上 agentic RAG。判断标准很朴素：看你手上的问题，能不能一次召回就答完。能，就老老实实用普通检索增强；不能，才轮到多步检索、判断、再检索这一套。下面四类需求是最常见的「长成 agentic RAG」的信号，命中越多越值得投入。

• 跨文档比对：先抽关键字段，再按字段做对齐和冲突标注，最后才组织语言，重点在「比对」而不是「搜到」
• 多跳推理：把每一步的中间结论显式记下来，作为下一轮查询的输入，路径由模型现场决定而不是提前写死
• 数据源混杂：先做一层路由判断该问谁，再分别取证，最后合并，路由错了后面全错
• 需要自我校验：生成之后再跑一遍核对，引用锚点对不上的段落直接作废重来，宁可少答也别编

1. 先做一次「一次召回能否答完」的实测挑十几条真实问题，用现有单次检索跑一遍，逐条记录答不全的原因。占比高，才说明结构上不够用。
2. 按四类需求给问题打标把答不全的问题归到跨文档、多跳、多源、需校验四类里，看集中在哪一类，决定先补哪块能力。
3. 验证数据源是否真的可用确认 SQL 或接口侧的字段权限、更新频率、字段含义是否稳定，接口不稳的话，加多少推理步骤都是白搭。
4. 设一个可接受的放弃线明确什么情况下允许回答「查不到」，而不是让模型硬凑。这条线定不下来，自我校验环节就没法落地。

还有一个容易忽略的前提：得先有一批能拿来对照的坏例子。没有这些真实失败样本，你没法判断多步编排到底有没有变好。想省事的话，可以先到 站内评测与工具目录页面 看看别人是怎么组织这类测试集的，再结合自己的业务问题动手。阈值和通过线不用照搬，按你能接受的人工复核成本来定就行。

最小可用的循环长什么样

别一上来就想多复杂，最小可用循环其实就是四件事：一个检索工具、一条循环规则、两道闸、一份日志。缺任何一样，跑起来都不踏实。顺序别乱，先有工具再谈循环。

1. 把检索包成工具入参至少给查询语句和条数上限两个字段，别只给一句 query 就完事，条数不让调用方控制，很容易一次拉回一堆噪声。返回里必须带文档标识和片段原文，标识用来去重和引用，原文用来喂给模型判断。写完自己拿两条极端查询试一下：一条命中很多、一条完全查不到，看返回结构是否稳定。
2. 写清循环规则用一段明确的话告诉模型：先看现有信息够不够，不够就调检索工具，结果回来后再重新判断。连续几次查不到，或者步数到顶，就停下来给结论。规则里最好写明停下来之后要输出什么，比如「说明目前掌握的信息和缺口」，否则模型容易硬编一个看似完整的答案。
3. 补上两道闸一道是最大循环步数上限，防模型反复检索停不下来；另一道是整条链路的总超时，防单轮慢、工具慢、串起来把请求挂死。两道闸都要有，只设步数不管时间，遇到慢接口照样拖垮；只设超时不管步数，额度还是可能被烧。具体数值不用照抄，按你的业务容忍度定，定完写进配置而不是散在代码里。
4. 把每轮都记进日志每一轮的查询语句、召回片段的标识和原文、当轮判断结果，都落一条日志。后面要调优，唯一靠得住的就是这些记录：是查询写歪了，还是召回质量差，还是判断逻辑太保守，看日志比猜快得多。日志里别只记最终答案，中间过程才是重点。

注意这套最小循环不是万能的。如果你的场景根本不需要外部资料，比如纯格式转换或固定规则判断，套上去只会变慢变贵；如果检索源本身质量很差，循环再多也救不回来，得先解决数据。判断标准很简单：任务是否依赖你库里没有的信息。不是，就别上这套。

上线前必须定的四个工程参数

Agentic RAG 上线翻车，十次有八次不是模型不行，是这四个参数没提前定。上线前把它们写进配置文件或者代码常量里，别等到半夜被告警叫醒才现场拍脑袋。下面四组参数，建议在第一次灰度之前就定稿。

单次检索超时

管住「一次工具调用卡住」，超了就当这次没调通，立刻走降级逻辑

链路总超时

管住「整条 agent 循环刹不住」，比如无限重试、来回互查，到点直接掐断并返回已有结果

会话轮次上限

单个用户会话最多跑几轮检索，超出就不再调工具，用现有信息收口

超时分两层定，别用一个数字糊弄。单次检索超时防的是某次接口抖动；链路总超时防的是逻辑死循环——比如模型反复觉得「还不够」继续查。具体分档和推荐取值别在这里猜，直接到 /guides/timeout超时专题的设置清单 对照，那里按工具类型给了档位。

1. 定单次超时给每个检索工具单独设一个上限，取值参考站内超时清单里对应工具类型的档位，宁可短一点，让失败快速暴露
2. 定链路总超时按用户能忍的等待时长来定链路总预算，单次超时乘以最大轮次必须小于它，否则总超时永远不触发
3. 上线前压测验证人为让某个检索工具变慢或返回空，确认两条超时都能按预期触发降级，而不是把请求挂在那里

• 并发与轮次上限：多个用户同时进来时，每个会话跑了多少轮检索必须限，这是成本失控最常见的入口。
• 按会话设轮次上限：单个会话最多调几次工具，超了就停止检索、用已有信息作答。
• 按用户或 IP 设并发：同一账号同时开几个会话也值得限，防止有人写脚本猛刷。
• 全局配额兜底：给整站或整个 API key 设每日调用总量，防止个别会话把预算吃光。
• 记录并监控触顶次数：哪个参数经常被打满，说明它定得太松或者流程本身有问题。

降级要提前定死，不能临时拍。检索工具挂了、或者连续几次空召回，无非两条路：退回普通 RAG 做单次检索，或者直接告诉用户「暂时查不到」。选哪条取决于你的场景——答案允许不完全时，退回单次检索体验更顺；答案必须准确、不能瞎编时，宁可明说查不到。别让模型自己临场决定，把规则写进流程判断里。

• 会话标识：把同一个用户的多轮请求串起来，否则日志是散的，事后没法还原一次完整对话。
• 轮次编号：第几轮检索、这一轮调了哪个工具，用来判断是单次失败还是整条链路有问题。
• 查询语句：模型最终拿去检索的原文，很多时候问题出在这里，不是检索工具本身。
• 召回条数：返回了几条、用了几条，空召回和超量召回要能一眼看出来。
• 耗时：单次工具耗时和整条链路耗时分开记，对不上超时配置就知道哪里漏了。
• token 消耗：每次调用花掉多少，缺这个后面无论按什么口径都算不清账。

怎么判断它到底比原来好

别靠感觉判断 Agentic RAG 有没有变好。先攒一份固定用例：几十条真实业务问题，每条写清楚「期望命中哪几篇文档」和「答案必须包含哪几个要点」。改之前跑一遍存结果，改之后再跑同一份，两次对着一行行比。用例不用多，但要稳定复用，否则每次换题就等于重新开盲盒。

1. 建用例集从客服记录、群聊提问、工单里挑几十条真实问题，覆盖不同难度和不同部门。每条标注期望文档 ID 和答案要点，写进表格或 JSON 存档。
2. 跑基线在当前版本上逐条跑，记录命中情况、轮数、token 消耗和最终答案。答案要点对着人工核一遍，别只看检索命中。
3. 跑改动版同一批问题、同一套判定标准再跑一遍。模型、温度、提示词尽量保持一致，否则变量太多说不清是谁的功劳。
4. 对照两类指标一类是准确性：答案要点覆盖率、文档命中率、答非所问比例。另一类是代价：平均检索轮数、平均 token、单条响应时间。两组数放一起看才成立。

用例里一定要塞几条故意查不到的题：问一个库里根本没有的东西，看它是老实说不知道，还是硬凑一段像模像样的答案。Agentic 流程多轮检索之后更容易「自己给自己找证据」，这类题恰恰是最能暴露问题的。哪几条属于这类，提前标好，评的时候单独拉出来看。

什么情况下上面这套判断不适用：如果你的场景容错极低、答错的代价远大于算力开销，那成本这一栏可以往后放，优先把准确率和拒答率拉满。反过来，如果只是内部辅助查询、用户自己会核实，那就没必要为了几个百分点把链路做重。

成本账怎么算，什么信号说明该收手

先把账算清楚，再谈收不收手。做法很简单：拿同一条有代表性的问题，分别走普通 RAG 和 agentic RAG，记录三个数——检索轮次、总 token、端到端延迟。单价不要凭印象，去站内的用量与价格页面查当时的数字自己折算，因为价格会变，写死在文里的数字第二天就可能过期。

• 平均轮次持续上涨：同样的流量结构，周均值一路往上，多半是模型学会了「多查一次更保险」，不是问题变难了。
• 空查询或重复查询占比变高：花了一轮 token 却没拿到新信息，等于纯开销。
• 长会话后半段几乎每句都在查：上下文越堆越长，模型越倾向再查一次确认，token 和延迟同步放大。
• 简单问题也被拖进多轮：本来一轮就能答的闲聊式问题，也开始走完整检索流程，说明分流没做。

1. 先动提示词，不要先动架构在系统提示里显式写清「什么时候不该查」：闲聊、追问上文已给出的信息、纯格式改写、寒暄，这些直接回答。多数失控是模型太爱查，不是查得不够，先把这条规则补上再观察轮次变化。
2. 设一条可量化的收手线给平均轮次和空查询占比各定一个阈值，超过就告警。阈值怎么定要看你自己的业务分布，不要抄别人的数字，用站内价格页面折算成单次会话成本，反推你能接受的轮次上限。
3. 还压不住就封顶再分流对单次会话做轮次封顶，超了就强制用已有信息作答；同时把需要多跳推理的复杂问题单独分流到另一条链路，普通问题走单轮。加检索工具只会让它查得更多，解决不了爱查的问题。

什么情况下不适用：如果你的业务本身就是低并发、对延迟不敏感的深度研究类场景，多查几轮换来的完整度可能是划算的，这时不必急着封顶；反过来，高并发、按次计费的问答场景，轮次波动会直接吃掉毛利，收手线要定得更紧。想核对自己场景下的单价和用量口径，到站内的用量与价格页面看当时的数字再换算。