Agent丨Agentic RAG 与传统 RAG 的核心区别是什么？

type

Post

status

Published

date

May 5, 2026

slug

agent30

summary

1. 传统 RAG 的典型架构

传统 RAG 一般是这样的：

对应到代码，大概是：

这种方式的优点是简单、稳定、成本可控、可观测性强。它适合 FAQ、企业知识库问答、客服标准问答、规章制度查询、文档摘要等场景。

但问题也很明显：

不管问题是否需要检索，都会检索。不管问题简单还是复杂，都只检索一次。检索错了，生成阶段通常也会被错误上下文带偏。多跳问题、模糊问题、跨数据源问题处理不好。缺少“我查到的信息不够，需要换策略”的能力。

Self-RAG 论文就指出，固定检索若不判断“是否需要检索”以及“检索内容是否相关”，会降低模型灵活性，并可能导致无用生成；CRAG 论文也专门针对“retriever 返回错误结果时模型如何纠正”提出了 retrieval evaluator 与 web search fallback。(arXiv)

2. Agentic RAG 的典型架构

Agentic RAG 不是简单地“RAG + Agent 名字包装”。它的关键是：让 LLM 或 Agent 控制检索流程中的决策点。

它更像这样：

核心变化是：RAG 从“检索组件”变成了 Agent 的一个工具能力。

3. 两者的核心区别

维度	传统 RAG	Agentic RAG
控制流	固定 pipeline	动态状态机 / Agent loop
是否检索	默认检索	由 Agent 判断是否检索
检索次数	通常一次	可多轮、多跳、递归检索
Query 处理	原始 query 或简单 rewrite	可拆解、改写、扩展、澄清
数据源	通常单一向量库	向量库、SQL、KG、Web、文件、API、代码库
错误处理	检索错了就容易生成错	可评估、重试、fallback、换工具
上下文管理	top-k 拼接	证据选择、压缩、记忆、状态追踪
成本	低且稳定	更高，波动更大
可控性	强，容易评估	复杂，需要轨迹评估和权限控制
适用问题	单跳事实问答	多跳、开放域、复杂任务、跨系统任务

4. 从成熟框架看 Agentic RAG 是怎么落地的

4.1 LangGraph：把 RAG 做成可循环的图状态机

LangGraph 官方 Agentic RAG 教程的关键设计是：

先构造一个 retriever tool；
再让 LLM 判断是否调用这个 tool；
检索后用 grader 判断文档是否相关；
如果不相关，就进入 rewrite_question 节点；
如果相关，才进入 generate_answer 节点。

官方示例中，generate_query_or_respond 节点通过 .bind_tools([retriever_tool]) 让模型决定是否发起工具调用；之后再用 grade_documents 决定进入生成还是重写问题。(LangChain 文档)

抽象成工程代码：

这个设计本质上已经不是传统 RAG，而是：

检索工具 + LLM 决策 + 状态图 + 条件边 + 自修复循环。

LangGraph 的定位也正好匹配这个方向：它是用于构建、管理和部署 long-running、stateful agents 的低层编排框架，支持持久执行、human-in-the-loop、记忆和调试观测。(GitHub)

4.2 Haystack：从固定 RAG pipeline 到带 fallback 的 Agentic Pipeline

Haystack 2.x 明确支持通过 pipeline 的 loops 和 branches 构建 agentic applications，例如条件分支、循环、自我修正等。官方文档提到，Haystack pipeline 不只是 query/indexing pipeline，也可以组合检索、API、预处理、条件路由等组件；loops 可用于 validator 不通过时回到 generator 自我修正。(docs.haystack.deepset.ai)

Haystack 的 Agentic RAG 示例非常典型：

先用知识库检索，如果文档无法回答，则返回 NO_ANSWER，然后通过 ConditionalRouter 进入 web search fallback 分支。(Haystack)

简化代码可以这样写：

注意：这看起来只是一个 fallback，但它已经具备 Agentic RAG 的关键特征：

系统不是盲目相信第一次检索，而是能判断“当前知识源不足”，然后主动切换策略。

4.3 LlamaIndex：把数据连接、索引、Query Engine 变成 Agent 可调用能力

LlamaIndex 的定位是 LLM 应用的数据框架：提供数据连接器、索引结构、查询接口、reranking 等模块，既有 5 行代码的高级 API，也有可以自定义 retriever、query engine、reranker 的低层 API。(GitHub)

传统 RAG 中，LlamaIndex 常被用作：

Agentic RAG 中，query_engine 不再只是最后的问答接口，而会变成 Agent 的一个工具：

这里的区别是：

传统 RAG 是“一个 query engine 直接回答”。
Agentic RAG 是“Agent 在多个 query engine / tool 之间选择、组合、验证”。

4.4 Claude Code、OpenCode、OpenClaw 给 Agentic RAG 的工程启发

Claude Code 官方描述它是 agentic coding tool，可以读取代码库、编辑文件、运行命令，并与开发工具集成；Claude Agent SDK 则提供同样的工具、agent loop 和上下文管理能力，可用于构建能自主读文件、运行命令、搜索 Web、编辑代码的 Agent。(Claude API Docs)

这对 Agentic RAG 的启发是：

检索不一定只发生在向量库里。 对代码库问答来说，grep、AST、LSP、git diff、test runner、文件读取都可以是检索工具。

OpenCode 也体现了类似工程模式：它支持 primary agents 和 subagents，内置 Build、Plan、General、Explore、Scout 等不同角色，并允许通过权限控制不同 Agent 能调用哪些工具。(OpenCode)

OpenClaw 的 README 则强调 multi-agent routing、browser/canvas/nodes/cron/session/Slack/Discord 等一等工具，以及 sandbox 安全模型；这说明成熟 Agent 系统通常不会只关心“能不能检索”，还会关心“谁能调用什么工具、在哪个隔离环境里调用、如何管理会话与远程入口”。(GitHub)

这些思想迁移到 Agentic RAG，就是：

每个检索源都是 tool。每个 tool 都要有权限边界。每次检索都应该进入 trace。复杂问题可以交给 subagent。高风险数据源或外部动作需要审批、沙箱或只读模式。

OpenAI Agents SDK 对 Agent 的定义也很接近这个工程范式：Agent 是配置了 instructions、tools、handoffs、guardrails、structured outputs 等运行行为的 LLM；SDK 可以管理 turns、tools、guardrails、handoffs 和 sessions。(OpenAI)

5. Agentic RAG 的核心模块拆解

一个生产级 Agentic RAG 可以拆成下面几层：

5.1 Router：判断走哪条路径

Router 的职责不是生成答案，而是选择策略：

Prompt 可以这样设计：

5.2 Query Planner：把复杂问题拆成子问题

例如用户问：

“过去三个月我们客服退款投诉上升的原因是什么？和新版本发布有没有关系？”

传统 RAG 可能只做一次语义检索。Agentic RAG 应该拆成：

对应代码：

Adaptive-RAG 的研究方向也正是这个思路：根据问题复杂度动态选择 no-retrieval、single-step RAG 或 iterative RAG，而不是所有问题都用同一条链路。(arXiv)

5.3 Evidence Grader：判断检索结果是否足够

Agentic RAG 不能把 top-k 结果默认当真。需要一个证据评分器：

这和 LangGraph 示例中的 grade_documents → generate_answer / rewrite_question 条件边非常接近。(LangChain 文档)

5.4 Tool Policy：控制 Agent 能调用什么

Agentic RAG 最大的风险是：Agent 会“自己决定下一步”。因此工具权限一定要显式配置。

OpenCode 的权限设计可以作为参考：工具权限可以是 ask、allow、deny，并且可以按 Agent 覆盖；还可以对 bash 命令、外部目录、webfetch、websearch、LSP、skill 等能力做细粒度控制。(OpenCode)

6. 传统 RAG 到 Agentic RAG 的演进路径

不要一上来就做复杂多 Agent。比较稳妥的演进路线是：

阶段 1：Naive RAG

适合验证基本可行性。

阶段 2：加 Query Rewrite

解决用户问题太口语、太短、上下文依赖强的问题。

阶段 3：加 Retrieval Grader

解决“检索错了还强答”的问题。

阶段 4：加 Fallback

解决私有知识库没有答案的问题。

阶段 5：升级为 Agentic RAG

让 Agent 控制策略，而不是工程师写死策略。

7. Agentic RAG 适合哪些场景？

适合 Agentic RAG 的场景

1. 多跳问题
例如：“A 产品 3 月故障和 4 月退款增长有没有关系？”

2. 跨数据源问题
需要同时查文档、数据库、日志、网页、工单、代码库。

3. 检索结果不稳定的问题
需要判断文档是否相关，不相关就改写 query 或换数据源。

4. 需要任务执行的问题
不只是回答，还要生成报告、创建 ticket、跑 SQL、读代码、运行测试。

5. 需要长期上下文的问题
例如研究助手、代码助手、运维排障助手、企业数据分析助手。

不适合 Agentic RAG 的场景

1. 高频、简单、标准答案问答
用传统 RAG 更便宜、更稳定。

2. 强实时低延迟场景
Agent loop 可能多次调用 LLM 和工具，延迟不可控。

3. 强合规但缺少权限系统的场景
Agentic RAG 没有权限、审计、沙箱时风险较高。

4. 数据源质量很差的场景
Agent 再聪明也无法弥补脏数据、过期数据、权限混乱。

8. Agentic RAG 的常见架构模式

模式一：Router RAG

由 Router 决定走哪个数据源。

适合企业内部多个知识库。

模式二：Corrective RAG

检索后进行评估，不合格则纠正。

CRAG 论文提出的思想就是在检索失败时引入 retrieval evaluator，并触发不同知识检索动作，例如 web search。(arXiv)

模式三：Self-RAG

模型在生成过程中判断是否需要检索、是否支持当前生成内容。

Self-RAG 的重点是让模型学习“retrieve、generate、critique”，并能按需检索，而不是固定塞入若干文档。(arXiv)

模式四：Multi-Agent RAG

多个 Agent 分工检索、验证、生成。

OpenAI Agents SDK 的 handoffs 机制就是类似思想：一个 Agent 可以把任务委派给另一个专门 Agent，handoff 在模型侧表现为工具调用。(OpenAI)

9. 生产级 Agentic RAG 的关键设计

9.1 状态必须显式建模

Agentic RAG 不是简单 while loop，必须维护状态：

没有状态，就无法评估：

它为什么检索？
为什么改写？
为什么换数据源？
哪一步导致幻觉？
哪个工具调用浪费 token？

9.2 必须设置停止条件

Agentic RAG 最怕“越查越乱”或“无限循环”。

OpenCode 这类 Agent 工具也支持 max steps、权限、subagent 控制等配置思想，说明成熟 Agent 系统会把“模型能做什么、最多做多久、什么时候需要审批”作为一等配置，而不是完全交给模型自由发挥。(OpenCode)

9.3 检索工具要分层

不要只有一个 search()。

不同工具应有明确描述：

工具描述越清楚，Agent 选错工具的概率越低。

9.4 引用和证据链必须结构化

Agentic RAG 的答案应返回：

否则 Agentic RAG 的复杂性会变成黑盒，出了问题很难定位。

10. 如何评估 Agentic RAG？

传统 RAG 通常评估：

检索召回率、MRR、nDCG、答案正确率、faithfulness、citation accuracy、延迟、成本。

Agentic RAG 还要额外评估“轨迹质量”：

评估对象	指标
路由	route accuracy、错误路由率
工具调用	tool precision、tool recall、无效调用率
多轮检索	平均步数、重试成功率、循环失败率
证据判断	evidence grading accuracy
fallback	fallback 触发率、fallback 后正确率
成本	tokens per answer、tool calls per answer
安全	越权调用率、敏感工具审批命中率
可解释性	trace completeness、citation coverage

一个简单的评估样例：

11. 面试或技术文章中可以这样总结

传统 RAG 解决的是“如何把外部知识塞给 LLM”。
它的核心是检索质量、分块策略、embedding、rerank、prompt grounding。

Agentic RAG 解决的是“LLM 如何主动决定使用哪些知识和工具完成任务”。
它的核心是决策、规划、工具调用、状态管理、检索自评、fallback、循环控制和权限治理。

更工程化地说：

12. 最后给一个完整参考实现骨架

结论

Agentic RAG 与传统 RAG 的核心区别，不是“有没有向量数据库”，也不是“用了几个 Agent”，而是：

传统 RAG 把检索当成固定前置步骤。
Agentic RAG 把检索、改写、验证、fallback、工具调用都变成 Agent 可决策的动作。

所以它的工程重点也从：

升级为：

实际落地时，建议不要直接追求复杂多 Agent，而是先从传统 RAG 做起，逐步加入 query rewrite、retrieval grader、fallback、多数据源路由，最后再升级为完整 Agentic RAG。这样可控性、成本和效果都会更稳。