淘天二面追问：Agentic RAG和普通RAG差在哪？不是加个智能体那么简单-优快云博客

前言

淘天二面这道题最近在 AI 求职圈反复出现。表面问"Agentic RAG 和普通 RAG 的区别"，但只要答出"加个智能体让它自己决定检索几次"，面试官就会端起水杯沉默——那种沉默比骂你一顿还难受。

Agentic RAG 不是在普通 RAG 上面"加一个 Agent 壳"，它和普通 RAG 的分野从文档进入系统那一刻就开始了——文档处理、检索、反思、规划四个层面全是闭环决策，不是检索完之后才补一层智能体。这道题考察的不是你会不会背定义，而是你有没有真的理解过一条 RAG 链路里哪些环节可以决策、哪些环节只能走流水线。

下面这段对话是复盘整理出来的原版追问节奏，尽量还原现场压力：

👔 面试官：你简历上写了做过 RAG 项目，那你说说看，Agentic RAG 和普通 RAG，在文档处理这块儿，到底有什么本质上的区别？

🙋‍♂️ 我：呃……Agentic RAG 就是在普通 RAG 的基础上加了一个智能体，让它自己去决定要不要检索、检索几次，大概就这样吧。

👔 面试官（笑而不语，端起水杯喝了一口）：那我问你，文档处理这一步，Agent 在哪里？

🙋‍♂️ 我：……（卡住）应该是在检索之后才介入的吧？

👔 面试官：你说的"加个智能体"，其实只描述了检索阶段的一个表象。Agentic RAG 真正的分水岭，在于它把文档处理和检索都变成了带反馈、可以迭代、可以规划的过程，而不是一条单向流水线。

🙋‍♂️ 我：所以从切文档那一刻起，两者就不一样了？

👔 面试官：对。如果连切块都是死的，后面的 Agent 再聪明也救不回来。

这一段对话基本能把 80% 候选人筛掉——大部分人把 Agentic RAG 理解成"RAG + Agent 的壳"，但分水岭其实从文档处理那一刻就开始了。

不管你是准备面大模型应用岗、RAG 工程岗，还是正在做企业知识库想升级到 Agent 化检索，读完这篇都能搞明白：普通 RAG 哪里是死的、Agentic RAG 哪里是活的、四个层面分别怎么从"流水线"升级成"闭环决策"，以及面试时怎么把这道题答到 90 分。

开拆。

一、普通 RAG 是怎么处理文档的：一条单向流水线

普通 RAG 也叫 Naive RAG，文档处理流程是一条流水线，从头到尾走一遍就结束：

索引段：原始文档 → 固定规则切块 → 向量化 → 存入向量库。

查询段：用户提问 → 向量化 → 相似度检索 Top-K → 拼接成 Context → 丢给 LLM 生成答案。

这套流程有几个明显特点，也正是它和 Agentic RAG 拉开差距的根因：

第一，切块方式是死的。 不管文档是合同、代码还是财报，都用固定长度（比如 512 token）加 overlap 来切，很少考虑语义边界。一份合同的"违约责任"条款被从中间切开，向量检索时两段语义都对不上。

第二，检索只做一次。 不管结果好不好用，都不会回头再查。LLM 只能基于捞回来的素材硬答。

第三，没有反思机制。 LLM 拿到什么 context 就用什么，不会判断够不够用。检索回来的三段话互相矛盾，LLM 也会硬编一个答案——这是幻觉的温床。

第四，文档结构信息基本丢失。 表格、标题层级、图表说明在切块那一刻就被拍扁成纯文本。一份财报的营收表格被拆成几行散落进不同 chunk，整体趋势完全还原不出来。

问题很直接：如果一个答案分布在文档的三个不同章节里，普通 RAG 大概率只能捞到其中一块，答案天然残缺。这也是很多人做完 RAG demo 上线后发现"检索效果不行"的原因——不是模型不行，是流水线本身的天花板就在这。

二、Agentic RAG 的分水岭：不是"加个智能体"，而是闭环

面试官后来点破的那句话值得反复咀嚼：“你说的’加个智能体’，只描述了检索阶段的一个表象。Agentic RAG 真正的分水岭，在于它把文档处理和检索都变成了带反馈、可以迭代、可以规划的过程，而不是一条单向流水线。”

这句话拆开看有三层：

第一层，"加个智能体"只是表象。 很多人想象的 Agentic RAG 是"普通 RAG + Agent 调度器"，Agent 决定调几次检索、用哪个工具。但这只是检索阶段的优化，文档处理那条流水线还是死的——切块固定、结构信息丢失、没有反思。这种"加壳"式 Agentic RAG，能力上限被文档处理阶段就锁死了。

第二层，分水岭从文档处理就开始了。 Agentic RAG 在文档进入系统那一刻就走上了不同的路：语义分块替代固定切块、层级化索引替代扁平向量库、结构感知解析替代纯文本拍平。这些不是检索阶段能补救的，是文档处理阶段就决定了检索的天花板。

第三层，整条链路变成了闭环。 普通 RAG 是单向的：索引→检索→生成，走完就结束。Agentic RAG 的链路是带反馈的：检索完可以评估质量、质量不够可以重新检索、生成前可以自我质疑、生成后可以校验答案。规划能力还能把"回答问题"拆成多步任务，每步独立检索和反思。

后面四章（文档处理、检索、反思、规划）就是把这四层分水岭逐一拆开讲。

三、文档处理阶段：从"数 token 切块"到"语义感知 + 结构化索引"

普通 RAG 的切块逻辑基本就是在数字符数。Agentic RAG 倾向于用下面四种方式，每一种都针对普通 RAG 流水线的某个硬伤。

1. 语义分块（Semantic Chunking）

按语义相似度切而非固定长度。先按句子切，计算相邻句子的语义相似度，在相似度突然下降处动态决定切分点。好处是每个 chunk 内部语义连贯，不会出现"违约责任"被一刀切开。代价是要跑一遍 embedding 算相似度，但对合同、财报这种语义密度高的文档值得。

2. 层级化索引（Hierarchical Indexing）

普通 RAG 把所有 chunk 平铺进向量库。Agentic RAG 先生成摘要索引（每章一个摘要向量），再挂细粒度段落索引，检索时先定位章节再往下钻。这就是 RAPTOR 之类的树状索引思路，避免大海捞针。

3. 结构感知解析

普通 RAG 把表格、标题、图表说明拍平成纯文本。Agentic RAG 把表格转成结构化 JSON/Markdown 单独索引，图表 caption 单独处理，标题层级保留为元数据。对财报、技术文档、合同这类结构化重的文档特别关键。

4. 文档间关系建模

普通 RAG 让每个文档孤立存在。Agentic RAG 用知识图谱或引用关系，把"这份合同引用了另一份附件"这种跨文档关联也存下来，解决多跳问题——答案需要跨多份文档拼出来的场景，普通 RAG 基本无能为力。

总结：普通 RAG 是"拍平+切块+入库"，Agentic RAG 是"感知结构+建层级+建关联"。前者把文档当散乱文本片段，后者当带结构、带关联的知识网络。

四、检索阶段：从"一次到位"到"迭代式检索 + 策略切换"

普通 RAG 的检索是"一次到位"——用户问什么，就用原始问题去向量库捞 Top-K，捞完就结束。Agentic RAG 的检索是"迭代式"的，Agent 会根据问题类型和检索结果质量，动态决定怎么检索、检索几次、用什么策略。

1. 查询改写（Query Rewriting）

普通 RAG 直接拿用户原始问题去检索，但用户提问往往口语化、模糊——“那个项目的进展怎么样了”，向量检索根本捞不到有用的东西。Agent 会先判断问题是否清晰，生成更适合检索的查询语句。

2. 查询分解（Query Decomposition）

复杂问题没法一次检索到位。比如"对比这三份财报的营收增长趋势并给出结论"，Agent 会拆成多个子问题：分别检索三份财报营收数据、检索行业平均增速、最后汇总对比。普通 RAG 拿到这种问题只会一把检索，对比根本做不起来。

3. 多跳检索（Multi-hop Retrieval）

第一轮检索结果不够用时，Agent 会根据已有信息生成新的检索请求，直到信息够用为止。比如用户问"收购方 A 的母公司去年营收多少"，第一轮检索"收购方 A"拿到母公司是 B，第二轮再检索"B 公司去年营收"。这种多跳场景只有 Agentic RAG 能处理。

4. 检索策略动态切换

普通 RAG 只会向量检索。Agent 会根据问题类型动态选择：

向量检索：语义相似度匹配，适合模糊语义问题
关键词检索（BM25）：精确匹配专有名词、产品型号、报错码
SQL 查询：结构化数据，直接查数据库比向量检索准
API 调用：实时数据（股价、天气、库存），直接调外部 API

这四个能力叠加，Agentic RAG 的检索就从"一次性捞 Top-K"升级成了"带规划、带迭代、带策略切换的检索过程"。

五、反思与自我评估：Agentic RAG 会"自己质疑自己"

普通 RAG 检索完就直接生成答案，从来不检查检索质量。Agentic RAG 会在生成答案之前插入一个自我评估环节——这是普通 RAG 完全没有的能力。这套机制在学术界有专门的名字，工程界也已有开源实现。

Self-RAG：让模型自己判断要不要检索、检索得够不够

Self-RAG 训练模型学会"反思 token"——生成过程中自己输出 [Retrieve]、[Relevant] 等标记，自主判断这一步要不要检索、检索回来的内容相不相关。落到工程上，Agent 先判断"这个问题能不能直接答"，能答就不检索，不能答才触发；检索回来还会判断"够不够用"，不够就再检索一轮。这种"按需检索 + 质量自评"的闭环，普通 RAG 完全不具备。

CRAG（Corrective RAG）：对检索结果做质量打分，差的就修正

CRAG 对检索回来的每条结果做质量打分，分三档：

正确（Correct）

：高度相关，直接用
错误（Incorrect）

：完全不对路，丢弃，触发网络搜索兜底
模糊（Ambiguous）

：部分相关，保留相关部分，补充网络搜索

这解决的是普通 RAG 的致命问题：检索回来一堆不相关内容，LLM 照样硬答导致幻觉。CRAG 在生成前就把不相关的过滤掉，质量差的还触发兜底检索。

反思这一层的本质

普通 RAG 链路是"检索→生成"，单向不回头。Agentic RAG 链路是"检索→评估→（不够）重新检索→生成→校验"，多了评估和重试两个环节。这意味着 RAG 系统从"盲目执行"变成了"带自我意识的执行"——系统会自己质疑自己，这种自我质疑能力是 Agent 区别于流水线工具的根本标志。

六、规划能力：把"回答问题"变成"完成一个任务"

普通 RAG 目标单一：检索 + 生成，一问一答。Agentic RAG 的 Agent 会先做任务规划，把"回答问题"拆解成一系列步骤。这是最本质的区别——普通 RAG 只能回答问题，Agentic RAG 能完成任务。

从"回答问题"到"完成任务"

举个例子。用户问：“帮我分析一下这家公司的财务状况，给出投资建议。”

普通 RAG：一把检索"公司财务状况"，捞回几段财报片段，LLM 硬编投资建议，结果大概率片面。

Agentic RAG 的 Agent 会拆成多步：

检索公司基本资料（主营业务、行业地位）
检索近三年财务报表（营收、利润、现金流、负债）
检索行业对标数据（同行业平均增速、市场份额）
检索最新新闻动态（重大诉讼、政策风险）
综合以上信息生成投资建议

只有第一步和第二步勉强算普通 RAG 的检索范围，第三步到第五步都是普通 RAG 不具备的——需要规划（拆解任务）、多步执行（每步独立检索）、汇总推理（整合成结论）。

规划能力的工程意义

真实业务问题很少是"一问一答"能解决的。客服问题需要查订单、查物流、查退换货政策；合规咨询需要查规则、查案例、查条款。这些都需要拆解成多个子任务，每个独立检索，最后汇总。普通 RAG 只能硬检索一把，Agentic RAG 能像分析师一样先规划思路、再分步执行、最后综合判断。

为什么 Agentic RAG 不是"RAG + Agent"的简单叠加

Agent 不是在 RAG 外面套壳，而是在内部重新定义了信息获取和处理的过程。规划能力决定检索深度和广度，反思能力决定检索质量，工具调用能力决定能触达的数据源。三个能力叠加，Agentic RAG 才从"问答系统"升级成"任务执行系统"。

一句话概括：普通 RAG 是"检索 + 生成"，Agentic RAG 是"规划 + 检索 + 反思 + 生成 + 校验"。多出来的不是一层壳，而是四个能力维度。

七、一张表看懂八维度差异

前面四层拆完，下面用一张表把八个维度的差异收拢一下。这张表建议存下来，面试前过一遍，基本能覆盖 80% 的追问点。

对比维度	普通 RAG（Naive RAG）	Agentic RAG
文档切块	固定长度 + overlap，按 token 数硬切	语义感知切块，按语义相似度动态决定切分点
结构化信息	表格/标题/图表全部拍平成纯文本，基本丢失	表格转 JSON/Markdown 单独索引，标题层级保留为元数据，图表 caption 单独处理
检索次数	通常只检索一次，捞完就生成	支持多轮迭代检索，信息不够就再查
查询处理	直接拿用户原始问题去检索	先改写查询，再按需分解成子问题分别检索
检索策略	单一向量检索	动态选择向量检索 / BM25 关键词 / SQL / API 调用
结果校验	无校验，检索什么就用什么，直接拼接生成	自我评估检索质量（Self-RAG / CRAG），不够则重新检索或换策略
任务能力	只能一问一答，复杂问题答不全	能做任务规划、多步推理，把"回答问题"拆成"完成任务"
工具使用	无外部工具调用能力	可调用搜索引擎、代码执行器、数据库、外部 API 等工具

这张表里有几个维度是面试官最爱追问的：

检索次数。 普通 RAG 只检索一次是天花板——不管结果好坏都没回头路。Agentic RAG 的多轮迭代不是 for 循环，背后是 Agent 在评估每轮结果质量、决定要不要继续查。

检索策略。 真实业务里向量检索只解决一部分问题。精确匹配 BM25 更准，结构化数据 SQL 更准，实时数据必须走 API。动态切换是刚需不是花架子。

结果校验。 普通 RAG 检索完就生成，中间没质量把关；Agentic RAG 在生成前插入自我评估，决定了系统会不会"基于错误证据硬答"。

任务能力。 普通 RAG 只能回答问题，Agentic RAG 能完成任务——前者是工具，后者是助手。这个认知差异决定了你设计系统的天花板。

八、从架构师视角看 Agentic RAG 的六个工程取舍

讲完原理和对比，下面从架构师视角聊聊 Agentic RAG 落地时的几个工程取舍。这些点原文没展开，但真正做选型时全是绕不开的决策。

1. 语义分块不是万能药，要按文档类型选切块策略

语义分块对合同、财报效果好，但对代码、日志、聊天记录反而可能更差——代码语义边界是函数/类，日志是事件，聊天是消息轮次，硬套"句子相似度"切分反而切断逻辑单元。工程做法是按文档类型路由：结构化文档走语义分块，代码走 AST 级切块，日志按时间窗口切，聊天按轮次切。

2. 层级化索引的 ROI 要算清楚

RAPTOR 这类树状索引在文档量大、查询需要跨章节定位时收益明显。但知识库只有几百篇文档、查询大多是单点事实查询时，建树的开销（摘要向量的 LLM 调用 + 维护成本）可能收不回来。判断标准：文档量 > 1 万篇、查询有"先定位再细化"模式时才上层级索引，小库直接扁平索引 + rerank。

3. 多跳检索要设上限，否则会陷入死循环

多跳检索必须设跳数上限（通常 3-5 跳）。原因：每多一跳就多一轮 LLM 调用 + 检索调用，成本和延迟线性增长；Agent 可能在某一跳走偏，后续每跳都在错误方向越走越远。上限不是限制能力，是防止系统失控的兜底。

4. CRAG 的"网络搜索兜底"在企业场景要慎用

CRAG 论文里检索质量差就触发网络搜索，在开放场景合理。但企业场景下网络搜索的可信度、合规性、时效性都没法保证——金融、医疗、法务领域直接用网络搜索兜底，可能引入更严重的错误。企业兜底策略更应该是触发人工审核队列，或降级到"建议联系人工客服"。

5. 反思机制要分级，不是每次检索都跑 Self-RAG

Self-RAG 的反思 token 机制会拖慢生成速度——每步都要判断要不要检索、检索得够不够，这些判断本身都是 LLM 调用。工程做法是分级反思：简单事实查询跳过反思，复杂推理查询才开启。判断依据可以是问题分类器，把反思开销花在真正需要的查询上。

6. 规划能力要约束，Agent 自由拆任务容易跑偏

完全放任 Agent 自己拆任务，容易出现"拆出 10 个子任务，每个都检索一轮，最后 LLM 上下文塞不下"。工程约束包括：子任务数量上限（通常 5-7 个）、每步检索结果 token 上限、总执行时间上限、子任务间依赖关系要显式。

一句话总结：Agentic RAG 每一个"活"的能力都需要对应的工程约束兜底——灵活性不是免费的，每多一层决策就多一层失控风险。

九、面试话术：考官想听的是什么

这道题面试官想听的绝对不是"Agentic RAG 就是加了 Agent 的 RAG"。下面拆两个典型错误回答，再给一个高分答题模板。

错误回答一：“Agentic RAG 就是普通 RAG 加一层 Agent 调度，让 Agent 决定检索几次。”

问题在于把 Agent 局限在检索阶段，忽略了文档处理阶段的分野。面试官追问"那文档处理这一步 Agent 在哪里"，立刻答不上来。本质是把 Agentic RAG 理解成"RAG + Agent 壳"，没触到分水岭。

错误回答二：“Agentic RAG 比普通 RAG 多了反思和规划能力，能自我纠错。”

比第一个好一点，但停留在"多了一些能力"的层面，没讲清楚这些能力怎么从根本上改变链路结构。面试官继续追问"那这些能力是怎么和检索、生成串起来的"，答起来就散了。

高分答题模板：三层结构 + 一句升华

第一层（基本原理）：分野从文档进入系统那一刻就开始了，不是检索完之后才加智能体。 普通 RAG 是单向流水线，Agentic RAG 把文档处理、检索、反思、规划四个环节都变成了带反馈的闭环。

第二层（细节为什么）：四个层面分别升级。 文档处理从固定切块升级到语义分块+层级索引+结构感知；检索从一次到位升级到查询改写+分解+多跳+策略切换；反思新增 Self-RAG/CRAG 自我评估；规划把"回答问题"拆成多步任务。

第三层（设计哲学）：普通 RAG 是工具，Agentic RAG 是助手。 Agent 不是在 RAG 外面套壳，而是在内部重新定义了信息获取和处理的过程，把"一次性检索+生成"升级成"可自主决策、可自主纠错的任务执行过程"。

升华一句：Agentic RAG 不是"RAG 加 Agent 的壳"，而是用 Agent 的规划、反思和工具调用能力，重新定义了整个 RAG 链路。

60 分 vs 90 分对比表

追问点	60 分回答	90 分回答
文档处理差在哪？	“用语义分块。”	“语义分块只是其一，还有层级化索引、结构感知、文档间关系建模，四个维度一起升级。”
检索阶段差在哪？	“能多检索几次。”	“查询改写、分解、多跳、策略动态切换四个能力叠加，是带判断的迭代不是 for 循环。”
反思机制是什么？	“Self-RAG 和 CRAG。”	“Self-RAG 判断要不要检索、够不够；CRAG 对结果质量打分，差的触发兜底，解决硬答幻觉问题。”
规划能力为什么重要？	“能拆成子问题。”	“普通 RAG 只能回答问题，Agentic RAG 能完成任务，从’问答系统’到’任务执行系统’的本质跃迁。”

加分项：主动提一句工程取舍——“语义分块要按文档类型路由、多跳检索要设跳数上限、反思机制要分级”。这一句能把回答从"会背原理"拉到"做过落地"。

总结

1. 分水岭从文档处理就开始了。 从文档进入系统那一刻起，语义分块、层级索引、结构感知、关系建模就和普通 RAG 分道扬镳。

2. 四个层面全是闭环决策。 文档处理、检索、反思、规划——普通 RAG 这四层都是单向流水线，Agentic RAG 都变成了带反馈、可迭代、可规划的闭环。

3. 检索从"一次到位"升级成"迭代式 + 策略切换"。 查询改写、分解、多跳、动态策略切换四个能力叠加，让 Agentic RAG 能处理复杂业务问题。

4. 反思机制和规划能力是分水岭。 Self-RAG/CRAG 让系统会自我质疑；规划能力让系统从"回答问题"升级成"完成任务"。普通 RAG 是工具，Agentic RAG 是助手。

5. 工程落地每个"活"的能力都要配约束。 语义分块按文档类型路由、多跳设上限、CRAG 兜底分场景、反思分级、规划约束子任务数。灵活性不是免费的，每多一层决策就多一层失控风险。

6. 面试答题讲三层。 基本原理（分水岭从文档处理开始）→ 细节为什么（四层闭环升级）→ 设计哲学（从工具到助手），再加一句工程取舍做加分项。

一句话留给读者：Agentic RAG 不是"RAG 加 Agent 的壳"，而是用 Agent 的规划、反思和工具调用能力，把"一次性检索 + 生成"升级成了"可自主决策、可自主纠错的任务执行过程"。欢迎评论区聊聊你做 RAG 项目时踩过的坑。

学AI大模型的正确顺序，千万不要搞错了

🤔2026年AI风口已来！各行各业的AI渗透肉眼可见，超多公司要么转型做AI相关产品，要么高薪挖AI技术人才，机遇直接摆在眼前！

有往AI方向发展，或者本身有后端编程基础的朋友，直接冲AI大模型应用开发转岗超合适！

就算暂时不打算转岗，了解大模型、RAG、Prompt、Agent这些热门概念，能上手做简单项目，也绝对是求职加分王🔋

在这里插入图片描述

📝给大家整理了超全最新的AI大模型应用开发学习清单和资料，手把手帮你快速入门！👇👇

学习路线:

✅大模型基础认知—大模型核心原理、发展历程、主流模型（GPT、文心一言等）特点解析
✅核心技术模块—RAG检索增强生成、Prompt工程实战、Agent智能体开发逻辑
✅开发基础能力—Python进阶、API接口调用、大模型开发框架（LangChain等）实操
✅应用场景开发—智能问答系统、企业知识库、AIGC内容生成工具、行业定制化大模型应用
✅项目落地流程—需求拆解、技术选型、模型调优、测试上线、运维迭代
✅面试求职冲刺—岗位JD解析、简历AI项目包装、高频面试题汇总、模拟面经

以上6大模块，看似清晰好上手，实则每个部分都有扎实的核心内容需要吃透！

我把大模型的学习全流程已经整理📚好了！抓住AI时代风口，轻松解锁职业新可能，希望大家都能把握机遇，实现薪资/职业跃迁～