从「固定单跳管道」到「Agent 自主决定检不检、检什么、要不要再检」· 面向要落地检索问答的工程师
面试里问「你做过 RAG 吗」，很多人张口就是「切块、向量化、检索 Top-K、塞进提示、让模型答」。这套流程没错，但只是最基础的一版。追问一句「用户问的是个需要跨三份文档、先算再查的复杂问题，你这套还灵吗？」，差距就出来了。Agentic RAG 正是冲着这类问题来的——它的核心区别只有一句话：把「检索」从一条写死的管道，变成 Agent 手里一个可以自己决定用不用、怎么用的工具。
传统 RAG：一条写死的单跳流水线
传统 RAG（也叫 naive RAG）的控制流是固定的、无分支的：不管用户问什么，都走同一条路。
检索一次
：拿用户原始问题去向量库做一次相似度检索，取回 Top-K 个片段；
塞进提示
：把这 K 个片段拼进 prompt 的上下文里；
生成一次
：LLM 基于这段上下文产出答案，结束。
关键词是**「一次」和「固定单跳」（single-hop）**：检索永远发生、永远只发生一次，用的永远是原始 query，检回来什么就用什么。它简单、快、便宜、可预测——对「答案就明明白白躺在某一段文档里」的简单事实问题，这套已经够用。
但它的短板也正来自这个「写死」：
- 问题本身就不该检索（比如「把上面那段话翻译成英文」），它照样白检一次；
- 原始 query 措辞不好、检不准，它没有第二次机会去改写重问；
- 答案要跨多份文档、需要「先查 A 得到线索、再据此查 B」的多跳推理，它只有一跳，直接够不着。
Agentic RAG：把检索交给 Agent 来「调度」
Agentic RAG 不再把检索当成流程里雷打不动的一步，而是把它包装成一个工具（tool / function），交到一个具备推理与决策能力的 Agent 手上。检索从「必经环节」降格成「一个可选动作」。于是 Agent 在每一轮都可以自主判断：
要不要检索
：能直接答的就不检，避免无谓开销；需要外部知识才去调检索工具；
检索什么
：可以先做query 改写 / 拆解——把一个笼统问题改写成更利于命中的表述，或拆成几个子问题分别检；
检得好不好
：拿回结果后先评估相关性，若发现片段跑题、信息不足，就换个查询再检一轮；
要不要继续
：支持多轮迭代检索——上一跳的结果成为下一跳查询的依据，直到攒够证据才收尾生成。
本质上它是一个带「检索工具」的 Agent 循环：推理下一步该做什么 → 决定调不调工具、调哪个、传什么参 → 观察结果 → 再推理，直到能给出可靠答案。工程上常见的落地形态包括ReAct 式的推理-行动循环、给检索加一层相关性打分与自我纠偏（如 self-reflection / corrective 思路），以及在多个数据源之间做路由（该查向量库、该查 SQL、还是该调 Web 搜索）。
# Agentic RAG 的控制流（伪代码，突出「决策 + 迭代」）context = [] while not agent.can_answer(question, context): action = agent.decide(question, context)# 自主决策下一步 if action.type == "ANSWER": break# 证据够了，直接收尾 q = agent.rewrite(question, context)# 按需改写 / 拆解查询 docs = retrieve(q)# 检索被当成一个工具调用 if agent.judge_relevance(docs) == "BAD":# 评估检索质量 continue# 不合格 → 换查询再检一轮 context += docs answer = agent.generate(question, context)一张表看清核心差异
| 维度 | 传统 RAG | Agentic RAG |
|---|---|---|
| 检索时机 | 固定必检，永远检一次 | Agent 自主决定检不检 |
| 控制流 | 固定单跳、无分支 | 可多轮迭代、带条件分支的循环 |
| 查询 | 直接用原始 query | 可改写、拆解、逐跳生成新 query |
| 质量把关 | 检回什么用什么 | 评估相关性，不合格就重检 |
| 多跳 / 复杂问题 | 够不着 | 逐跳积累证据，能处理 |
| 成本 / 延迟 | 低、快、可预测 | 更多次调用，更慢、更贵 |
| 可控性 | 高，行为确定 | 低，行为更难预测和调试 |
好处与代价：这是一笔明确的权衡
Agentic RAG 换来的能力很实在：对复杂、多跳、需要推理的问题明显更强——它能自己把大问题拆小、一步步查、把线索串起来；而且具备自我纠偏的能力，检偏了能察觉并重来，不会像传统 RAG 那样把一堆不相关片段硬塞给模型、诱发幻觉。
但代价同样明确，面试答题时一定要主动点出来，否则会显得只会吹优点：
更多调用、更慢
：多轮检索 + 多次 LLM 推理，延迟和 token 成本成倍上涨；
更难控、更难调试
：Agent 的决策路径是动态的，同一个问题两次跑法可能不同，出错时更难定位；
可能过度检索
：设计不好时，Agent 会为本不需要外部知识的问题反复空检，或陷入无谓的多轮循环，白白烧钱烧时间。
所以实践里通常要给 Agent 加护栏：限制最大检索轮数、设置成本 / 步数预算、对循环做超时与兜底，避免它「想太多」。
那到底该用哪种？
别默认「新的就是好的」。选型看问题形态和工程约束：
选传统 RAG：问答以简单事实型、单跳为主，答案基本能在单段文档里找到；对延迟和成本敏感、要高并发；追求行为可预测、易于评测和上线。这类场景上 Agentic 纯属杀鸡用牛刀。
选 Agentic RAG：问题复杂、需要跨多文档 / 多数据源、需要多跳推理或「边查边想」；对答案质量的要求高于对延迟和成本的要求；或者要在向量库、数据库、Web 搜索等多种工具间做路由。
一个务实的落地策略是分层：先用一个轻量判断把简单问题走传统 RAG 快速通道，只把识别出的复杂问题升级到 Agentic 路径，兼顾成本与能力。
一句话总结
传统 RAG 是「检一次 → 塞进提示 → 生成」的固定单跳管道；Agentic RAG 把检索包装成一个工具，让 Agent 自主决定检不检、检什么、检得好不好、要不要再检——用「更慢、更贵、更难控」的代价，换来对复杂多跳问题的处理力和自我纠偏能力。简单问题用前者，复杂问题用后者，能分层就分层。
学AI大模型的正确顺序，千万不要搞错了
🤔2026年AI风口已来！各行各业的AI渗透肉眼可见，超多公司要么转型做AI相关产品，要么高薪挖AI技术人才，机遇直接摆在眼前！
有往AI方向发展，或者本身有后端编程基础的朋友，直接冲AI大模型应用开发转岗超合适！
就算暂时不打算转岗，了解大模型、RAG、Prompt、Agent这些热门概念，能上手做简单项目，也绝对是求职加分王🔋
📝给大家整理了超全最新的AI大模型应用开发学习清单和资料，手把手帮你快速入门！👇👇
学习路线:
✅大模型基础认知—大模型核心原理、发展历程、主流模型（GPT、文心一言等）特点解析
✅核心技术模块—RAG检索增强生成、Prompt工程实战、Agent智能体开发逻辑
✅开发基础能力—Python进阶、API接口调用、大模型开发框架（LangChain等）实操
✅应用场景开发—智能问答系统、企业知识库、AIGC内容生成工具、行业定制化大模型应用
✅项目落地流程—需求拆解、技术选型、模型调优、测试上线、运维迭代
✅面试求职冲刺—岗位JD解析、简历AI项目包装、高频面试题汇总、模拟面经
以上6大模块，看似清晰好上手，实则每个部分都有扎实的核心内容需要吃透！
我把大模型的学习全流程已经整理📚好了！抓住AI时代风口，轻松解锁职业新可能，希望大家都能把握机遇，实现薪资/职业跃迁～
