很多人第一次上 RAG，是照着教程把文档切块、灌进向量库、检索几条拼进提示词，跑起来觉得能用。可一旦用户问的是「跨三份文档做对比」「先查 A 再根据结果决定要不要查 B」，同一套代码就开始答非所问：要么召回不到，要么召回了但没被用上。这篇不重复讲检索原理，只解决一件事——你的场景到底该用一次性检索的普通 RAG，还是让模型自己决定查什么的 Agentic RAG，以及换过去要动哪些工程环节。
很多人第一次上 RAG，是照着教程把文档切块、灌进向量库、检索几条拼进提示词，跑起来觉得能用。可一旦用户问的是「跨三份文档做对比」「先查 A 再根据结果决定要不要查 B」，同一套代码就开始答非所问：要么召回不到，要么召回了但没被用上。
这篇不重复讲检索原理，只解决一件事——你的场景到底该用一次性检索的普通 RAG，还是让模型自己决定查什么的 Agentic RAG，以及换过去要动哪些工程环节。判断的起点不是「哪个更先进」，而是先把当前的失败模式说清楚。
一页纸说清两条链路的差别
普通 RAG 是一条固定流水线：切块、向量化、一次召回、重排、拼提示词、生成，中间没有分支，也没有回头路。请求进来走完全程就结束，路径长度是可预测的。
Agentic RAG 把检索包装成模型可调用的工具之一，模型可以决定查不查、查几次、换个关键词再查、查到一半去读原文。链路长度不固定，取决于模型判断。
| 对比项 | 普通 RAG | Agentic RAG |
|---|---|---|
| 下一步谁决定 | 流水线写死 | 模型按需决定 |
| 检索次数 | 一次为主 | 可能多次 |
| 失败表现 | 召回不准就答错 | 可能绕路、循环 |
| 延迟特征 | 稳定可预测 | 波动较大 |
| 调试重点 | 切块与重排 | 编排与日志 |
差别不在用了哪个向量库，而在「谁决定下一步」。这一点想通了，后面的选型和改造就有抓手：要动的是编排层，不是换一个更贵的检索组件。
先看问题形状，再谈架构选型
把线上问题按「需要几步才能拼出答案」分类，比讨论技术名词有用得多。分类清楚之后，选型基本就定了。
- 单跳事实型
- 某个参数是多少、某条规定怎么写，一次检索命中即可
- 多跳与对比型
- 需要跨几份文档交叉、先定位再展开
- 核验型
- 答案要有出处，要能指出资料之间的矛盾
- 单跳事实型问题普通 RAG 就够，加 Agent 只会变慢变贵
- 多跳与对比型问题 Agentic 的优势才显现出来
- 需要核验的问题建议走 Agentic，让模型显式地把原文取回来
- 语料规模小、问题集中、延迟敏感的场景，不要为了「先进」上 Agentic
反过来说，如果用户问的东西基本都能在固定几个片段里找到答案，那你的瓶颈是切块和重排，不是编排。这种情况下换成 Agentic，只是把同一件事做慢。
成本与延迟的账要提前算
普通 RAG 一次请求基本是一次模型调用加一次向量检索，延迟和花费可预测，适合按次数报价、按席位结算的业务。预算好做，SLA 也好承诺。
Agentic RAG 的调用次数由模型决定，最坏情况是循环查询。如果不设上限，一个复杂问题可能触发十几次调用，成本曲线会很难看。
- 先算基线按普通 RAG 的链路估一遍单次请求的 token 消耗与检索开销，作为对照数字
- 再算最坏情况给 Agent 设一个你认为能接受的最大步数，按这个步数乘系数，看总成本是否还在区间内
- 核对当前价格具体单价到 /price-watch 核对当时的数字，不要拿记忆里的价格做容量规划
- 定退出条件预算耗尽或步数用尽时走降级路径，而不是继续硬撑
延迟方面也一样：Agentic 的响应时间不是常数，前端如果有超时限制，要么把超时放宽，要么在等待期间给用户反馈。这一点在需求评审阶段就该提出来。
从普通 RAG 换成 Agentic，要补的四个工程件
从固定流水线换成模型驱动编排，代码改动其实不大，难的是把「模型可以自由决定」这件事约束在可控范围内。以下四件是必须补的。
- 工具层：把检索、读原文、按条件过滤各包成一个边界清晰的工具，参数用严格 schema 约束
- 编排层：设最大步数、超时、无进展就退出，并把每步的查询和命中写进日志
- 降级路径：Agent 循环失败或超预算时，退回一次性检索兜底，别让整个请求直接报错
- 评测集：准备一组必须多跳才能答对的问题，作为是否值得上 Agentic 的开关依据
这四件里，日志最容易被忽略。没有日志，你既说不清模型查了几次，也说不清哪一步开始跑偏，后面的调优全是猜。
工具边界怎么划
工具不是越多越好。一开始只放开「再次检索」这一个动作，观察收益，比一次性塞进去五六个工具更容易定位问题。
答不好时先分清是检索问题还是编排问题
上完 Agentic 发现效果没提升，很常见。这时候不要急着换模型或换库，先按现象归类。同样的现象，改的地方完全不同。
| 现象 | 大概率原因 | 先动哪里 |
|---|---|---|
| 命中正确片段但答案没用上 | 拼装与提示词问题 | 改拼装模板 |
| 一次召回总差一点 | 检索覆盖不够 | 放开再次检索 |
| 延迟飙高、调用失控 | 编排没约束住 | 加步数上限 |
| 日志里查询重复 | 模型陷入循环 | 加无进展退出 |
排查顺序建议：先看日志里每步的查询与命中，再决定是改切块、改重排，还是改编排。跳过日志直接改架构，大概率是白改。
命中不等于用上：检索命中了正确片段，不代表模型会在生成时用它。
什么情况下这套判断不适用
上面这套选型逻辑，前提是你的场景以问答和辅助决策为主，允许一定的路径差异。有几类场景不适用。
- 强合规或强确定性的问答场景，需要每次走同一条可审计路径，Agentic 的自由度反而是负担
- 离线批处理、对成本极度敏感的批量任务，优先把普通 RAG 调到更好，而不是换架构
- 团队没有日志和评测基建时，先补这两样，否则上了 Agentic 也说不清它到底有没有变好
还有一种情况：如果业务方根本给不出「什么叫答对」的标准，那无论用哪种架构都没法验收。这种时候先对齐验收标准，比讨论技术方案更优先。
切换前的落地清单
如果你判断下来该往 Agentic 走，别一次性把编排全放开。按下面的顺序小步走，每一步都有可观察的结果。
- 盘点失败问题列出当前线上最常失败的一批问题，人工标出哪些属于多跳，作为改造的目标集合
- 建评测用例为多跳问题建一小组评测用例，先跑通普通 RAG 的基线数字，后面所有对比都基于这组用例
- 检索改工具把检索改成模型可调用的工具，先只放开「再次检索」这一个动作，观察通过率变化
- 补齐约束确认超时、步数上限、预算和降级都已配置，再考虑放开更多工具或动作
- 按周对比上线后按周对比同一批用例的通过率与平均成本，任一项明显变差就回退到普通 RAG
回退不是失败，是这套流程本来的设计。先把评测集和日志建起来，无论最后用哪种架构，你都比之前更清楚系统在哪里出问题。
下一步想按当前各家 API 的实际价格和模型能力做容量规划，可以去站内的价格追踪与模型资料库对照当时的数字，再决定编排层放开几步。→常见问题
Agentic RAG 是不是一定比普通 RAG 效果好？
不一定。问题如果是单跳事实型，普通 RAG 通常又快又便宜，加 Agent 只是多花调用次数。只有当问题需要多步、跨文档或者要先查再决定下一步时，Agentic 的收益才明显。判断办法是拿一批真实失败问题看它们是不是多跳，如果大部分不是，先把切块和重排调好。
普通 RAG 换成 Agentic，主要改哪一层？
主要是把检索从固定流水线里的一个步骤，改成模型可调用的工具，并加一层编排来控制步数、超时和预算。向量库、切块、嵌入模型这些大多可以不动。所以改造量集中在工具定义、编排逻辑和日志，不在检索本身。
Agentic RAG 会不会把成本拖到不可控？
如果不管步数就会。务必设最大步数、单会话预算和超时，并在超预算时退回一次性检索兜底。同时把每步的查询和 token 消耗记进日志，这样你才能知道钱花在哪一步。实际单价按站内工具当时的数字换算，不要凭印象估。
怎么判断该不该继续往 Agentic 上加工具？
看新工具能不能让之前失败的那批用例变好。如果加了「按条件过滤」或「读原文」之后，评测用例通过率没动，而平均步数涨了，就说明这个工具在空转。一次只加一个工具，观察一轮再决定。
小团队没有评测基建，能不能先上 Agentic？
可以先做小范围验证，但至少准备十来条必须多跳才能答对的问题当开关依据，否则效果好坏全凭感觉。日志也必须有，否则循环卡住时你连哪一步出错都看不到。这两样投入不大，但决定了后面能不能持续优化。
