Agentic RAG vs 传统 RAG：什么时候值得上

传统 RAG 检索一次上下文，基于它生成答案。Agentic RAG 让模型自己驱动检索：规划找什么、检索、评估证据、必要时再检索、调用工具、然后回答。当问题复杂、有歧义或横跨多个系统时，agentic RAG 值得；否则它是一个昂贵的干扰。

市面上的对比大多写得像产品广告。这篇是一个决策框架：到底变了什么、代价是什么、你的负载落在分界线的哪一侧。

传统 RAG 一张图

问题
   ↓
检索          （一次，固定策略）
   ↓
上下文        （top-k 片段）
   ↓
大模型
   ↓
答案

管道是静态的：每个问题走同样的检索，中间没有决策。这不是弱点::这是承诺。行为可预测，延迟稳定，失败模式无聊且可调试。

Agentic RAG 变了什么

问题
   ↓
规划          （我需要知道什么？）
   ↓
检索          （选择来源和查询）
   ↓
评估          （证据足够吗？）
   ↓
再检索？      ── 是 ↺（循环）
   ↓ 否
推理 + 综合
   ↓
答案          （附所用来源）

微软研究院的 AgenticRAG 工作对企业知识库描述的正是这个转变：从固定的一次性检索，走向模型可以执行 search、open、summarize 等迭代动作的智能体化检索，直到证据足以支撑答案。模型不再是管道的最后一节，而成为管道的操作员。

Agentic RAG vs 传统 RAG

	传统 RAG	Agentic RAG
检索	一次固定	迭代、模型驱动
查询规划	有限或没有	显式规划步骤
工具调用	通常没有	有::计算器、API、数据库
延迟	更低、稳定	更高、波动
单题成本	更低	随步骤和重试成倍放大
调试	直接	困难::路径分叉还会循环
擅长	可预测的问题、单一语料	有歧义、多来源、需核验的答案

什么时候传统 RAG 就够

这一节值得比通常更多的篇幅，因为多数企业负载的默认答案仍然是传统：

• 单一知识库::一个受治理的语料：手册、政策、产品文档
• FAQ 形状的问题::“XR-200 的承载能力是多少？”
• 客服分流::意图可预测、答案集合已知
• 政策或规格查询::存在唯一权威来源且可被检索
• 对延迟敏感的界面::聊天窗口里，秒就是转化
• 要求低且平坦的单题成本::单题经济模型必须是平的

如果你的问题集合长这样，agentic RAG 是在为你没有的问题引入循环风险和 token 开销。一套治理良好、带引用的单遍 RAG::我们为客服和内部问答构建的那种::仍然是正确的工程答案。

什么时候 Agentic RAG 合理

• 多文档推理::答案必须组合单次检索捞不回来的证据
• 多个仓库::知识库 + CRM + ERP，系统必须决定去哪找
• 有歧义的查询::问题本身需要先解释，检索才有用
• 研究型工作流::竞品扫描、投标响应、尽调
• 多步核验::起草、对第二来源校验、调和、回答
• 依赖工具的回答::实时价格、库存水位、计算值与文档混合

共同特征：通往答案的路径事先未知。 路径已知时，把它一次性写进管道，然后停手。

根据数据来源和任务选路径

很多生产系统需要多条路径。更有用的问题是每一类问题应该走哪里，以及哪条路径能够以最低复杂度提供可靠答案。

数据来源与任务	合适的起点	原因
产品手册、制度和答案明确的文档问题	带引用的传统 RAG	来源稳定、答案路径已知、方便核验
表格或数据库中的汇总、趋势和当前数值	SQL 或边界明确的 API 工具	计算和实时状态应该留在结构化系统中
章节结构固定的周期性报告	确定性工作流加分段检索	固定计划成本更低，也更容易测试和复现
跨多个来源的开放式研究	有迭代上限的 Agentic RAG	下一步检索取决于上一步找到的证据
混合型企业负载	在 RAG、SQL、工具和 Agentic Retrieval 之间路由	每类问题都使用与来源和风险匹配的最小可靠路径

这个路由模型也回答了一个常见问题：生成报告本身并不意味着必须使用 Agent。如果报告章节已知，可以为每个章节检索证据，再通过固定工作流完成组合。只有系统需要在执行过程中自行发现路径时，Agentic 行为才开始产生价值。

Agentic RAG 的隐性成本

agentic 项目实际死在这里，所以值得直说：

• Token 成本。 每轮循环都是一次完整模型调用。生产规模下，单题成本可能数倍于单遍 RAG。
• 延迟。 规划-检索-评估-再来的意思是秒级，不是毫秒级。在面向客户的界面上，这是转化问题。
• 循环。 没有硬迭代上限的”再检索一次”，意味着偶发的永不优雅终止的问题。
• 工具失败。 每次工具调用都是一个会超时、会返回垃圾、会与语料矛盾的依赖::而 agent 会自信地把它揉进答案。
• 权限复杂度。 检索器碰一个索引；一个能浏览来源的 agent 把权限模型必须覆盖的面翻了几倍::见《AI Agent 治理》。
• 评估难度。 一条管道是一条待测路径；一个 agent 是一棵路径树。评估集必须跟着长大，否则质量全凭感觉。

这些都不是不建 agentic 系统的理由，而是诚实做预算、并把 agentic 行为留给养得起它的负载的理由。

企业级 Agentic RAG 参考架构

当下面的决策框架说”agentic”时，我们部署的是这个形状::护栏就是架构本身，不是事后补的：

问题
   ↓
规划器               分解；选择来源和工具
   ↓
循环（最多 N 步）     检索 → 评估 → 也许再检索
   │                 工具：ERP 查询、计算器（白名单）
   ↓
综合器               只基于收集到的证据作答
   ↓
引用层               每个论断 → 带日期的来源
   ↓
审计日志             步骤、工具调用、成本、延迟

三个细节把它和周末原型区分开：迭代上限（一个硬性的 N，循环必须终止）、只基于证据的综合器（最终答案只能用循环收集到的东西，不能用想象）、审计日志（没有它，每次回归都无解，每次成本尖峰都不可见）。

怎么评估一个 Agentic RAG 系统

检索指标衡量不了 agentic 行为。改测这些：

• 任务准确率::最终答案是否真正解决了问题，对照 ground truth 判，不是看”流不流畅”
• 回答率 vs 拒答率::一个能正确说”来源不覆盖这个”的系统，好过一个硬填空白的系统
• 引用率::带可核验来源的回答占比
• p95 延迟与单题解决成本::循环会放大两者；测尾部，别测均值
• 循环行为::平均迭代数，以及预算被耗尽的比例
• 工具失败处理::ERP 在循环中途超时，系统会怎样：降级、重试，还是幻觉

把度量做进第一个版本。没有评估就上线的 agentic 系统，活不到”足够好”的那天。

Agentic RAG 与企业知识

这个决策的企业版还有第二条轴，多数对比跳过了它：谁拥有真相。 在未治理的混乱上迭代的 agent 不会收敛到真相，它收敛到”最容易被检索到的那一版”::这就是 2019 年的 PDF 为什么赢过 2024 年的勘误。

在两种 RAG 之前，语料本身需要治理：去重、版本化、权属、权限。这就是知识治理，它在所有检索架构决策的上游。检索器::无论是否 agentic::只和它脚下的层一样可信：上下文工程决定系统可以知道、检索、引用和执行什么。

把比较转化为架构评估

可靠的选择来自真实问题，而不是一张通用架构图。一次有效的 RAG 架构评估需要：

1. 20 到 50 个真实问题，来自未来真正使用系统的人
2. 有代表性的信息源样本，包括文档、表格、数据库和业务应用
3. 权限规则，明确每类用户可以访问哪些来源
4. 可评分的评估集，覆盖答案质量、引用、延迟和成本
5. 问题路由图，把每类问题分配给 RAG、SQL、工具、固定工作流或有边界的 Agentic Retrieval

最终得到的是一项来自真实业务负载的生产决策，同时也建立了评估基线，用来判断未来升级 Agentic RAG 是否真的改善了系统。

一个决策框架

问题可预测，且来自同一个
受治理语料？
  ↓ 是 → 传统 RAG（+ 引用）

答案需要实时系统或计算
（价格、库存、计算器）？
  ↓ 是 → RAG + 工具调用（仍然不是 agentic）

通往答案的路径事先未知
::多来源、有歧义、需核验？
  ↓ 是 → Agentic RAG，带迭代上限、
          工具白名单和评估覆盖

注意中间那步，它是实践中被过度建造最多的地方：需要一次实时价格查询不会让一个系统 agentic。RAG 加受治理的工具调用是一条带插槽的管道::往往就是正确的建造，而且简单一个数量级。

按约束的真实形状来建架构。

如果上面的框架说明传统 RAG 已经足够，就先把检索、引用和评估做好。如果流程确实需要跨业务系统的多步检索，我们的企业上下文工程服务会先梳理真实问题、信息源、权限和路由，再进入实施。