最近面试AI开发岗位，被问到一个很熟悉又陌生的问题: 简单说一下传统RAG和Agent中RAG的差异。
被问到时我头脑一片空白，感觉有很多想说，但是却好像又都不够具体，我当时就回答: 传统RAG的链路是死的，用户提问向量化，然后去向量数据库检索后一并交由大模型思考得出结果；而Agent RAG是LLM知道自己有检索的能力，自主选择是否需要检索，然后再给出最后的结果。
这个回答我自己也是不满意的，说到底是我在接触RAG时，本身就是在Agent条件下，本质没有接触过传统的RAG，所以这个问题给我问懵住了。于是花了一些时间去了解了一下其中的逻辑。记录一下。
写在前面
RAG的出现是为了解决大模型的一个老毛病——幻觉。你问它一个它训练语料里没有、或者记不清的事实，它不会说”我不知道”，而是一本正经地编一个看起来很合理的答案。再加上模型的知识有截止日期，对特定场景的内部的私有文档更是一无所知。所以就需要一个外挂的知识库来补充大模型的知识。
传统 RAG
传统 RAG（也常被叫做 Naive RAG）的流程非常固定，本质就是一条单向流水线：
拆开来看就是这几步：
- 把用户问题通过
Embedding模型转成向量； - 拿这个向量去向量数据库里做相似度检索，捞出
Top-K个最相关的文本片段； - 把这些片段和原始问题拼成一个
Prompt； - 丢给 LLM 生成最终答案。
代码层面，它甚至可以简单到几行：
# [伪代码] 传统 RAG 的核心逻辑：检索一次，生成一次
def naive_rag(question: str) -> str:
query_vec = embed(question) # 1. 向量化
chunks = vector_db.search(query_vec, k=5) # 2. 检索 Top-K
context = "\n".join(chunks) # 3. 拼接上下文
prompt = f"根据以下资料回答问题：\n{context}\n\n问题：{question}"
return llm.invoke(prompt) # 4. 一次性生成
传统RAG的关键特征：整个过程只检索一次、生成一次，流程写死，不会回头。检索器在这里扮演的角色，更像是 LLM 前面的一个自动查字典动作，查到什么就用什么，查得对不对、够不够，它自己是不知道的。
正是这种一条龙的设计，决定了它的局限。基本都能归到这几类：
- 检索质量直接决定上限。如果用户的提问措辞和文档里的表达对不上（比如用户问”年假怎么休”，文档里写的是”带薪休假申请流程”），向量召回就可能偏，而传统 RAG 没有任何机制去”换个说法再查一次”。
- 应付不了多跳问题。像”对比一下 A 产品和 B 产品在 2025 年的销量增长”这种问题，需要分别检索 A、B 两份资料再做计算，单次检索根本搞不定。
- 不会自我怀疑。检索到的内容哪怕是噪声、是无关片段，它也会硬着头皮拿去生成，最后输出一个似是而非的答案。
- 数据源单一。它通常只连一个向量库，没法根据问题灵活地去查数据库、调 API 或者搜实时网页。
Agentic RAG
Agentic RAG 的核心改变，就是把那条死板的流水线，换成了一个**会思考的智能体（Agent）**来当总指挥。
检索不再是写死的第一步，而是 Agent 手里众多TOOLS中的一个。要不要检索、检索什么、用哪个数据源、检索回来的东西够不够、要不要再来一轮，这些全部交给 LLM 自己推理决策。
整个过程变成了一个带反馈的循环：
- 理解 & 规划：问题的拆解。先想清楚这个问题要拆成几步，需要哪些信息；
- 选工具 / 改写查询：决定调用哪个工具，必要时把用户的口语化提问改写成更适合检索的查询（
Query Rewrite）； - 多源检索：可能查向量库，也可能搜网页、查数据库、调 API，而且可以多轮；
- 评估 & 反思：拿到结果后自己掂量一下——信息够不够？答案靠不靠谱？如果不够，回到第 2 步改写查询再来一遍；
- 生成答案：确认信息充分后，再给出带引用的最终回答。
这里最本质的两个新增能力是 反思（Reflection） 和 迭代（Iteration）。传统 RAG 是”查完即用”，而 Agentic RAG 是”查完先验货，不合格就退回重查”。
实际场景中使用的Agentic RAG通常有下面几种:
- 1. 路由式（Router）：最轻量。前面加一个”路由器”，根据问题类型决定去查哪个知识源——技术问题查技术库，财务问题查财务库，时效性问题走网页搜索。它本身还是单次检索，只是多了”选对地方”这一步。
- 2. 单智能体（Single-Agent）：一个 Agent 大脑 + 一套工具（向量检索、Web、SQL、计算器……），由它自主决定调用顺序和次数，支持多轮迭代。这是目前性价比最高、用得最多的形态。
- 3. 多智能体（Multi-Agent）：一个主控（
Orchestrator）把任务拆给多个各有专长的子 Agent——检索 Agent 负责找资料、分析 Agent 负责处理、写作 Agent 负责成文。能力最强，但工程复杂度和成本也最高，适合真正复杂的工作流。
不过Agentic RAG也不是完美的，依旧会有一些缺点:
第一，Agentic RAG 不是传统 RAG 的”升级替代”，而是”复杂度换能力”的取舍。 它多调几次 LLM，意味着延迟可能从几百毫秒飙到几秒甚至几十秒，token 成本翻几倍，而且因为路径是动态的，一旦出错你很难复现和定位——同一个问题两次跑出来的中间步骤都可能不一样。对一个”查个公司请假规定”的简单问答上 Agent，纯属杀鸡用牛刀。
第二，Agentic 的上限，仍然压在底座模型的推理能力上。 反思、规划、路由这些动作全靠 LLM 自己判断。如果模型本身推理不行，所谓的”自我纠错”很可能变成”自我欺骗”——它反思完反而更自信地给你一个错的答案。所以 Agentic RAG 对模型能力的要求，其实比传统 RAG 高得多。
第三，检索质量这个地基，两者都逃不掉。 Agentic RAG 能多查几轮、能改写查询，但如果你的文档切分得稀烂、Embedding 模型选得不对、向量库里全是脏数据，那 Agent 查一百轮也是垃圾进垃圾出。
两者的本质区别
如果让我用一句话概括，那就是：
传统 RAG是执行一条写好的流水线；Agentic RAG是自己做决策的员工分析解决问题。
- 传统 RAG = 检索 + 生成的固定流水线，简单、快、便宜，但不会变通；
- Agentic RAG = 用一个会决策的 Agent 来指挥检索，能改写、能多轮、能多源、能自我纠错，更强但更慢更贵；
- 两者是自动化程度的两端，不是谁取代谁；
- 选型的关键不在于”哪个更先进”，而在于你的任务复杂度是否真的值得这份额外的成本。