本文深入浅出地介绍了Agentic RAG的概念和实践应用，通过对比普通RAG的局限性，阐述了Agentic RAG如何通过ReAct决策环让模型自主决定检索策略。文章详细讲解了如何将检索包装成工具，并提供了最小Agentic RAG的实战代码。此外，还探讨了Self-RAG的反思机制以及Agentic RAG的适用场景和工程挑战，帮助读者更好地理解和应用这一前沿技术。
前言：同一个问题，普通 RAG 答不上来
凌晨一点，你接到客服侧甩过来的工单——
用户问：“你们家 X3 和 X5 这两款扫地机，哪款更适合养猫的家庭？”
你心里咯噔一下，因为这个问题你公司的 RAG 系统答错过三次。
普通 RAG 把它当一个 query 走完整条流水线：embedding → Milvus 召回 top-3 → bge-reranker 精排 → 拼 prompt → DeepSeek 生成。出来的答案是——
“X3 续航 120 分钟，X5 续航 180 分钟，建议根据家庭面积选择。”
看起来像那么回事。
但答错了。
它根本没理解"养猫"这两个字背后藏着什么——防缠绕主刷能不能搞定猫毛、滤网清理频次、噪音会不会吓到猫、有没有避让宠物模式——这些信息散在 5 份不同的文档里，一次召回根本捞不全。
普通 RAG 是一锤子买卖——查一次、答一次、结束。但真实世界里的复杂问题，从来不是一次查询能搞定的。
过去两篇，我把 RAG 从头跑通了，又把召回准确率从 50% 拉到 90%。但有一个根本前提，我从来没动过——整条流水线是写死的，模型只是被动跑一遍。
今天，把这个前提拆掉。
Agentic RAG 不是新模型，是新模式。 把"检索"从代码里硬编码的步骤，变成模型可以自己调用的"工具"——区别不在于模型多强，在于谁来做决策。
PART 01：普通 RAG 的天花板——它只会"被动应答"
很多人召回准确率拉到 90%+，会觉得"我的 RAG 已经无敌了"。
未必。召回再准，也救不了三种问题。
硬伤 1：只会问一次
用户问"X3 适合养猫家庭吗？"——普通 RAG 把这当一个 query 走完一遍就结束。
但用户的真实需求是三步：先查 X3 规格参数 → 再查猫毛处理能力 → 再对比同价位其他型号值不值。普通 RAG 一步就交卷了，剩下两步被压缩进了 LLM 的"幻觉补全"里。
模型不敢说"我需要再查一次"——它的代码里没有这个出口。
硬伤 2：不知道自己不知道
召回的文档里如果根本没提"猫毛处理"，普通 RAG 还是会硬答——它会从一些边角信息里编出来一个看似合理的答案。
它没有"我不知道"这个出口。
GPT-4 也会犯这个错。Claude 也会。DeepSeek 也会。不是模型问题，是架构问题——普通 RAG 默认"必须给答案"，模型被逼着编。
硬伤 3：不会用工具
用户问"X3 现在多少钱？"——文档里只有 3 个月前的价格表。
普通 RAG 会拿旧价格答，而不是去调实时价格 API。它的代码里根本没有"调外部 API"这一环。
一个反直觉判断
这三大硬伤，靠前面讲的那些召回调优都救不回来。
召回再准，也救不了"该查两次的问题被压缩成一次"。也救不了"文档里压根没有这个信息"。也救不了"需要调外部工具"。
这就是 Agentic RAG 的入口——让模型从被动跑流水线，变成主动决定"我要不要查、查什么、查完够不够"。
PART 02：核心范式——ReAct 决策环
Agentic RAG 听起来很玄，剥开外壳就是 ReAct（Reasoning + Acting）—— 2022 年 Google 那篇论文提出来的范式。今天所有 Agent 框架，LangGraph、AutoGPT、CrewAI，底层全是它。
一个完整决策环，四步：
- Think（思考）
：模型先想"这个问题我需要查吗？查什么？"
- Act（行动）
：调用一个工具（检索、计算器、外部 API）
- Observe（观察）
：看工具返回了什么
- Loop（循环或结束）
：够答了就答，不够就再 Think 一次
用一个真实例子走一遍
还是那个"X3 适合养猫家庭吗"。Agent 的完整决策轨迹是这样的——
Think 1："需要查 X3 的规格和猫相关功能" Act 1：调用 rag_search(query="X3 规格 防缠绕 滤网") Observe 1：返回 3 个 chunk，提到防缠绕但没提滤网清理频次 Think 2："滤网清理频次没查到，再查一次" Act 2：调用 rag_search(query="X3 滤网清理 养宠物") Observe 2：返回 1 个 chunk，提到每周清理一次 Think 3："信息够了，可以答了" Answer："X3 配备防缠绕主刷，适合养猫家庭；滤网建议每周清理一次……"这就是 Agentic RAG 跟普通 RAG 最本质的区别——普通 RAG 把这段决策轨迹预先写死在代码里，Agentic RAG 让模型自己生成这段轨迹。
一个反直觉点
很多人以为 ReAct 是"循环直到完美"，所以会无限优化下去。
不是。
ReAct 是"循环直到模型自己判断够了"。所以——
模型推理能力才是 Agentic RAG 的真正瓶颈，不是召回。
这就是为什么 DeepSeek-V3、Claude 这种推理强的模型跑 Agentic RAG 效果更好。推理弱的模型可能查一次就草草收尾，或者陷入"查不够→再查→还是不够"的死循环。
PART 03：实战第一刀——把"检索"包装成 Tool
这一节是全文最重的代码段。用 DeepSeek 的 function calling（OpenAI 兼容格式），把前面搭好的检索函数包成一个 tool，让模型自己决定要不要调。
Step 1：把检索包成可调用函数
复用前面搭好的栈：bge-m3 embedding → Milvus 召回 → bge-reranker 重排。把它包成一个干净的函数：
# tools.py —— 把检索包成 Agent 可调用的工具 from FlagEmbedding import BGEM3FlagModel, FlagReranker embed_model = BGEM3FlagModel("BAAI/bge-m3", use_fp16=True) reranker = FlagReranker("BAAI/bge-reranker-v2-m3", use_fp16=True) def rag_search(query: str, top_k: int = 5) -> str: """在产品知识库里检索相关信息。 Args: query: 检索查询，建议具体而非笼统 top_k: 返回的文档数量，默认 5 Returns: 匹配到的文档片段，按相关性排序 """ # 标准配方：dense 召回 top-50 → 重排 → top-k vec = embed_model.encode([query])[0] candidates = vectorstore.similarity_search_by_vector(vec, k=50) pairs = [[query, d.page_content] for d in candidates] scores = reranker.compute_score(pairs, normalize=True) ranked = sorted(zip(candidates, scores), key=lambda x: -x[1])[:top_k] return "/n/n".join([d.page_content for d, _ in ranked])Step 2：给工具写 schema
DeepSeek 的 function calling 跟 OpenAI 一模一样。给工具写个 schema，告诉模型"这个工具叫什么、什么时候该用、参数长什么样"：
tools = [{ "type": "function", "function": { "name": "rag_search", "description": "在产品知识库里检索相关信息。当用户问及具体产品规格、政策、流程时调用。", "parameters": { "type": "object", "properties": { "query": {"type": "string", "description": "具体的检索查询"}, "top_k": {"type": "integer", "description": "返回文档数，默认 5"} }, "required": ["query"] } } }]一个关键工程坑
description 写得清楚不清楚，直接决定 Agent 会不会调用它。
模型决策完全靠 description 来判断"该不该用这个工具"——
- 写得太笼统（
"检索信息"），模型会乱调，啥问题都先去知识库翻一遍 - 写得太具体（
"只在用户提到 X3 时调用"），模型会漏调，X5 来了就忘了用
好的 description 应该回答三个问题：这个工具做什么、什么时候该用、什么时候不该用。
反直觉点
工具数量别贪多。
3 个写得清楚的工具 > 10 个写得模糊的工具。
模型在多工具场景下，选择准确率会断崖式下降——Anthropic 自己测过，工具数从 5 加到 20，调用准确率能掉 30 个百分点。
别一上来就给 Agent 配 10 个工具。先把 1 个调好。
PART 04：跑通一个最小 Agentic RAG
把 PART 03 的工具，接到 DeepSeek 的对话主循环里，跑通一个会自己决定查几次的 Agent。
完整可运行代码：
# agent.py —— 最小 Agentic RAG 主循环 from openai import OpenAI import json client = OpenAI( api_key="你的 DeepSeek API Key", base_url="https://api.deepseek.com/v1" ) def agentic_rag(user_query: str, max_turns: int = 5) -> str: messages = [ { "role": "system", "content": ( "你是一个会主动检索知识库的助手。" "遇到不确定的事实问题，先调用 rag_search 查资料，" "查到足够信息再回答。如果查不到，直接说不知道。" ) }, {"role": "user", "content": user_query} ] for turn in range(max_turns): response = client.chat.completions.create( model="deepseek-chat", messages=messages, tools=tools, tool_choice="auto" # 关键：让模型自己决定调不调 ) msg = response.choices[0].message messages.append(msg) # 模型决定不调工具 → 直接答，结束循环 if not msg.tool_calls: return msg.content # 模型决定调工具 → 执行 → 把结果塞回 messages for call in msg.tool_calls: args = json.loads(call.function.arguments) result = rag_search(args) messages.append({ "role": "tool", "tool_call_id": call.id, "content": result }) return "（超过最大轮次，强制结束）"同一个问题，两个版本对比
用户问：“我们 X3 扫地机适合养猫家庭吗？滤网多久清一次？”
普通 RAG——一次召回 → 答 → 大概率漏掉"滤网清理"那块，因为 query 偏向"适合养猫家庭"，滤网信息排到了 top-10 开外。
Agentic RAG（上面这个循环）——模型自己拆成 2 次检索：先查 X3 养猫相关，再单独查滤网清理 → 各自召回 → 综合答 → 完整。
三个工程坑
坑 1：延迟是普通 RAG 的 2-5 倍。 每次决策都要一次 LLM 调用 + 可能的检索。别把它当默认方案——按 PART 06 的决策表用。
坑 2：max_turns必须设上限。 不设的话，模型可能陷入"查不够→再查→还是不够→再查"的死循环，烧 token 烧到天荒地老。5 轮是经验值，绝大多数问题 3 轮内能搞定。
坑 3：流式输出必须开。 Agentic 一轮动辄几秒，用户等得没耐心。开 streaming，先吐"我先查一下 X3 的规格…"这种过渡话术，体验会好很多。
PART 05：让 Agent 会"反思"——Self-RAG
PART 04 那个循环能用，但有个问题：模型拿到检索结果后，直接信了。
它不会判断"这些结果是不是真的回答了问题"。如果召回跑偏了，模型也跟着跑偏。
Self-RAG（2023 年 ICLR 那篇）就是解这个的——核心思想是让模型输出"反思 token"：[Retrieve][Relevant][No Relevant][Generate]，每一步都先判断一下。
不用真去训练模型，靠 prompt 也能模拟个七八成。
反思 prompt（追加到 system message）
每次拿到检索结果后，先在内心判断三点： 1. **检索结果是否真的回答了用户问题？** （是 → 继续；否 → 改写 query 重查） 2. **是否有明显遗漏的关键信息？** （是 → 补查） 3. **信息之间是否冲突？** （是 → 再查一次确认） 不要直接告诉用户你在反思，直接决定要不要再调用 rag_search。三种"反思触发"场景
场景 1：召回结果跑题。 query 太宽，返回的 chunk 跟问题无关。反思后改写更具体——比如把"X3 适合养猫吗"改成"X3 防缠绕主刷 猫毛 测试"。
场景 2：召回结果不完整。 用户问 A 和 B，只查到 A。反思后补查 B。
场景 3：召回结果冲突。 两份文档说法不一致（旧版手册说续航 120 分钟，新版说 150 分钟）。反思后再查一次确认。
反直觉点
反思不是免费的。
每次反思 = 多一次 LLM 调用 + 可能的检索。复杂查询的延迟可能直接翻倍。
生产环境通常只开"召回结果跑题"这一种反思——其他场景靠 prompt 让模型自己判断要不要补查就行，不用显式反思。
不要为了显得"智能"就把三种反思全开，那是给自己挖坑。
PART 06：何时该上 Agentic RAG
这一节最重要。
Agentic RAG 不是普通 RAG 的升级版，是另一种东西。用错场景，反而更糟。
决策表
| 场景 | 该用哪个 | 理由 |
|---|---|---|
| 用户问"退货政策是什么" | 普通 RAG | 单跳问题，一次召回就够，Agentic 是浪费 |
| 用户问"X3 比 X5 适合养猫吗" | Agentic RAG | 多跳问题，需要拆解 + 多次检索 |
| 用户问"上周销量为啥跌了" | Agentic + 多工具 | 需要查销售库 + 查事件库 + 交叉分析 |
| 用户问"今天天气如何" | 直接调 API | 不需要知识库，外部 API 一次搞定 |
| 客服 FAQ（答案明确且单一） | 普通 RAG | Agentic 反而引入不确定性 |
| 复杂业务咨询（多约束条件） | Agentic RAG | 唯一能搞定的方案 |
三个上线坑
坑 1：延迟爆炸。 Agentic 一轮 = 1 次 LLM + 可能的检索，多轮就是数倍延迟。实时聊天场景必须给前端加"思考中…"动画 + 流式输出。
坑 2：token 成本翻 3-10 倍。 每次决策、每次反思都要 LLM 调用。生产环境必须监控 token 用量，否则账单会让你怀疑人生。一个朋友上了 Agentic RAG 之后，月度 API 账单从 800 涨到 6500——他没监控。
坑 3：可解释性下降。 Agentic 决策是黑盒，用户问"为啥你查了 3 次"——你必须保留决策日志，方便 debug 和审计。
一个收尾判断
Agentic RAG 的核心价值不在"答得准"，而在"能处理普通 RAG 处理不了的复杂问题"。
别为了时髦而升级。先问自己一句：我的场景真的需要多轮检索吗？
如果不需要，普通 RAG + 前面讲的那套调优已经够打了。
如何学习大模型 AI ？
由于新岗位的生产效率，要优于被取代岗位的生产效率，所以实际上整个社会的生产效率是提升的。
但是具体到个人，只能说是：
“最先掌握AI的人，将会比较晚掌握AI的人有竞争优势”。
这句话，放在计算机、互联网、移动互联网的开局时期，都是一样的道理。
我在一线科技企业深耕十二载，见证过太多因技术卡位而跃迁的案例。那些率先拥抱 AI 的同事，早已在效率与薪资上形成代际优势，我意识到有很多经验和知识值得分享给大家，也可以通过我们的能力和经验解答大家在大模型的学习中的很多困惑。我们整理出这套AI 大模型突围资料包：
- ✅ 从零到一的 AI 学习路径图
- ✅ 大模型调优实战手册（附医疗/金融等大厂真实案例）
- ✅ 百度/阿里专家闭门录播课
- ✅ 大模型当下最新行业报告
- ✅ 真实大厂面试真题
- ✅ 2026 最新岗位需求图谱
所有资料 ⚡️ ，朋友们如果有需要《AI大模型入门+进阶学习资源包》，下方扫码获取~
① 全套AI大模型应用开发视频教程
（包含提示工程、RAG、LangChain、Agent、模型微调与部署、DeepSeek等技术点）
② 大模型系统化学习路线
作为学习AI大模型技术的新手，方向至关重要。 正确的学习路线可以为你节省时间，少走弯路；方向不对，努力白费。这里我给大家准备了一份最科学最系统的学习成长路线图和学习规划，带你从零基础入门到精通！
③ 大模型学习书籍&文档
学习AI大模型离不开书籍文档，我精选了一系列大模型技术的书籍和学习文档（电子版），它们由领域内的顶尖专家撰写，内容全面、深入、详尽，为你学习大模型提供坚实的理论基础。
④ AI大模型最新行业报告
2025最新行业报告，针对不同行业的现状、趋势、问题、机会等进行系统地调研和评估，以了解哪些行业更适合引入大模型的技术和应用，以及在哪些方面可以发挥大模型的优势。
⑤ 大模型项目实战&配套源码
学以致用，在项目实战中检验和巩固你所学到的知识，同时为你找工作就业和职业发展打下坚实的基础。
⑥ 大模型大厂面试真题
面试不仅是技术的较量，更需要充分的准备。在你已经掌握了大模型技术之后，就需要开始准备面试，我精心整理了一份大模型面试题库，涵盖当前面试中可能遇到的各种技术问题，让你在面试中游刃有余。
以上资料如何领取？
为什么大家都在学大模型？
最近科技巨头英特尔宣布裁员2万人，传统岗位不断缩减，但AI相关技术岗疯狂扩招，有3-5年经验，大厂薪资就能给到50K*20薪！
不出1年，“有AI项目经验”将成为投递简历的门槛。
风口之下，与其像“温水煮青蛙”一样坐等被行业淘汰，不如先人一步，掌握AI大模型原理+应用技术+项目实操经验，“顺风”翻盘！
这些资料真的有用吗？
这份资料由我和鲁为民博士(北京清华大学学士和美国加州理工学院博士)共同整理，现任上海殷泊信息科技CEO，其创立的MoPaaS云平台获Forrester全球’强劲表现者’认证，服务航天科工、国家电网等1000+企业，以第一作者在IEEE Transactions发表论文50+篇，获NASA JPL火星探测系统强化学习专利等35项中美专利。本套AI大模型课程由清华大学-加州理工双料博士、吴文俊人工智能奖得主鲁为民教授领衔研发。
资料内容涵盖了从入门到进阶的各类视频教程和实战项目，无论你是小白还是有些技术基础的技术人员，这份资料都绝对能帮助你提升薪资待遇，转行大模型岗位。