本文深入探讨了Agentic RAG一种让Agent自主决策检索策略的先进技术。文章指出传统RAG的局限性如单次检索无回头、单一数据源孤岛等并提出了四种Agentic RAG模式路由型、多步型、纠错型和自适应型。通过CRAG实战案例展示了如何为检索结果添加评分机制实现自我纠错。文章还强调了工具描述对路由准确率的重要性并警示了常见的工程陷阱如重试次数设置和评分Prompt设计。对于想要提升大模型回答质量、减少检索错误的程序员和小白来说本文提供了宝贵的实践指导。上一篇讲完了 Multi-Agent 测试这篇切回 RAG——但不是普通的 RAG而是让 Agent 自己掌控检索节奏的 Agentic RAG。你有没有遇到过这种情况搭了一套标准 RAG上线后发现检索结果驴唇不对马嘴——用户问「2024 和 2025 的年度报告对比一下」系统只检索到了 2024 的内容然后大模型用这半桶水给了你一个「信心满满但完全错误」的答案。你反复调 top-K、调 chunk size就是不稳。根本原因不是参数没调对而是传统 RAG 的架构本身就没有自我纠错的能力——它就是个固定管道检一次生成完事。Agentic RAG 的核心思路是把检索这件事交给 Agent 来决策。要不要检索检哪个数据源检完发现不够怎么办这些都由 Agent 在运行时自主判断而不是你在代码里硬编码。这篇从原理到实战把四种 Agentic RAG 模式拆透。01 为什么说传统 RAG 是「一次性赌注」传统 RAG 的执行路径是固定的用户提问 → Embedding → 向量检索(top-K) → 塞进 Prompt → 生成答案。这个流程在生产环境中有三个死穴死穴一单次检索没有回头路。 第一次检索结果质量差没有任何机制能发现这一点并重试。系统会继续往下走用一堆不相关的 chunk 生成一个「看起来很正经」的错误答案。死穴二单一数据源知识孤岛。 用户的问题往往跨越多个数据域——文档库、数据库、实时 API。传统 RAG 只能连一个向量库碰到跨域问题直接哑火。死穴三无法分解复杂问题。 「对比 Q3 和 Q4 的用户留存率结合客服反馈分析原因」——这个问题需要至少三次独立检索再汇总。传统管道里你只能硬塞进一个 query然后祈祷。根据多个生产系统的统计15%-30% 的 RAG 失败都源于检索质量问题——而这些失败在传统架构里根本无从发现更无法修复。Agentic RAG 的解法很直接在检索和生成之间加一层「会思考的 Agent」。能力维度传统 RAGAgentic RAG检索策略固定单次向量搜索动态Agent 选数据源、改查询检索轮次永远是 1 次按需决定1 到 N 次质量评估无Agent 给检索结果打分错误恢复无检测到失败后换策略重试工具调用无可调用 API、SQL、网页搜索查询分解无把复杂问题拆成子问题02 四种模式Agentic RAG 的设计图谱Agentic RAG 不是一种固定架构而是四种可组合的模式。理解这四种模式是选型的基础。模式一路由型 RAGRouting RAG适用场景知识分散在多个后端——向量库、SQL 数据库、知识图谱、实时 API。核心逻辑是 Agent 先理解问题意图再决定去哪里取数据。用户问「Q3 营收」走 SQL问「产品规格」走向量库问「最新股价」走实时 API。模式二多步型 RAGMulti-step RAG适用场景单个 Query 需要多轮独立检索才能回答。Agent 把复杂问题拆解成子问题依次检索最后汇总。「新定价方案上线后流失率怎么变化客服反馈如何」拆成三个独立子查询分别检索最后合并推理。模式三纠错型 RAGCorrective RAG / CRAG适用场景需要对检索结果进行可信度评估。检索 → 评分相关吗→ 相关就生成不相关就改写 Query 重试完全没有就降级到网页搜索。这是实际项目里最实用的模式。模式四自适应型 RAGAdaptive RAG适用场景需要在「要不要检索」这一步就做判断。Agent 先判断这个问题是常识、上下文已覆盖还是真的需要检索不需要就直接生成避免无意义的检索开销。03 CRAG 实战给检索加一个「评分官」CRAGCorrective RAG是工程价值最高的模式用 LangGraph TypeScript 完整实现它。先定义 State 和图结构import { Annotation, StateGraph, END } from langchain/langgraph; import { ChatOpenAI } from langchain/openai; import { z } from zod; // 定义 Graph 状态 const AgenticRAGState Annotation.Root({ question: Annotationstring(), documents: Annotationstring[]({ reducer: (prev, next) [...prev, ...next], default: () [], }), generation: Annotationstring(), retrieval_grade: Annotationrelevant | irrelevant | none(), retry_count: Annotationnumber({ reducer: (prev, next) next, default: () 0, }), }); type RAGState typeof AgenticRAGState.State; const llm new ChatOpenAI({ model: gpt-4o-mini, temperature: 0 });检索节点 评分节点——从向量库取文档再让 LLM 判断相关性// 检索节点 async function retrieveNode(state: RAGState) { const results await vectorStore.similaritySearch(state.question, 5); return { documents: results.map((d) d.pageContent) }; } // 评分节点 const GradeSchema z.object({ score: z.enum([relevant, irrelevant, none]), reason: z.string(), }); async function gradeDocumentsNode(state: RAGState) { const structuredLLM llm.withStructuredOutput(GradeSchema); const prompt 你是一个检索结果评分器。 用户问题${state.question} 检索到的文档 ${state.documents.join(/n/n---/n/n)} 评估这些文档是否能回答用户问题 - relevant高度相关可以据此生成可靠答案 - irrelevant关联性很弱但还有一些信息 - none完全无关或为空 给出评分和原因。; const result await structuredLLM.invoke(prompt); return { retrieval_grade: result.score }; }Query 改写节点 生成节点// Query 改写节点——检索质量差时优化问题表述 async function rewriteQueryNode(state: RAGState) { const prompt 原始问题${state.question} 向量检索结果质量不佳。请重写问题包含更多关键词、拆解更具体、去除歧义。 只输出改写后的问题不要任何解释。; const response await llm.invoke(prompt); return { question: response.content as string, documents: [], // 清空旧结果准备重新检索 retry_count: state.retry_count 1, }; } // 生成节点 async function generateNode(state: RAGState) { const context state.documents.join(/n/n); const prompt 基于以下文档回答问题。 文档${context} 问题${state.question} 给出准确、有据可查的回答。如果文档不足以完整回答请明确说明。; const response await llm.invoke(prompt); return { generation: response.content as string }; }条件路由 组装 Graph// 条件路由——核心决策逻辑 const MAX_RETRY 2; function routeAfterGrading(state: RAGState): string { if (state.retrieval_grade relevant) return generate; if (state.retry_count MAX_RETRY) { console.log(⚠️ 超过重试上限降级生成); return generate; } if (state.retrieval_grade none) return rewrite_query; return generate; // irrelevant 但有一些信息接受并生成 } // 组装 Graph const workflow new StateGraph(AgenticRAGState) .addNode(retrieve, retrieveNode) .addNode(grade_documents, gradeDocumentsNode) .addNode(rewrite_query, rewriteQueryNode) .addNode(generate, generateNode) .addEdge(__start__, retrieve) .addEdge(retrieve, grade_documents) .addConditionalEdges(grade_documents, routeAfterGrading, { generate: generate, rewrite_query: rewrite_query, }) .addEdge(rewrite_query, retrieve) // 改写后重新检索 .addEdge(generate, END); const app workflow.compile(); // 运行 const result await app.invoke({ question: LangGraph 的 Checkpoint 是什么 }); console.log(最终答案, result.generation);04 路由型 RAG让 Agent 决定去哪个「图书馆」找书路由型 RAG 的关键在于把每个数据源封装成 Tool让 LLM 自主选择。import { tool } from langchain/core/tools; import { z } from zod; // 工具1向量库搜索文档、FAQ const searchDocsTool tool( async ({ query }: { query: string }) { const results await vectorStore.similaritySearch(query, 5); return results.map((d) d.pageContent).join(/n/n); }, { name: search_docs, description: 搜索产品文档、技术规格、使用指南。适用于功能介绍、操作步骤类问题。, schema: z.object({ query: z.string() }), } ); // 工具2SQL 数据库结构化数据 const queryDatabaseTool tool( async ({ sql }: { sql: string }) { const result await db.query(sql); return JSON.stringify(result.rows); }, { name: query_database, description: 查询业务数据库。适用于营收、用户量、留存率等量化指标问题。只支持 SELECT 语句。, schema: z.object({ sql: z.string().describe(只读 SQL 查询语句) }), } ); // 工具3网页搜索实时信息 const webSearchTool tool( async ({ query }: { query: string }) { const results await tavilySearch(query); return results.map((r: any) r.content).join(/n/n); }, { name: web_search, description: 搜索互联网获取最新信息。适用于当前事件、最新版本、外部市场数据。, schema: z.object({ query: z.string() }), } ); // 绑定工具让 Agent 自主路由 const agentWithTools llm.bindTools([ searchDocsTool, queryDatabaseTool, webSearchTool, ]);工具描述是路由准确性的关键——越清晰LLM 选错的概率越低。每个工具描述都要写清楚适用于什么问题而不只是「功能是什么」。反例就在上面如果你把三个工具描述都写成「搜索相关信息」LLM 会倾向于总选第一个路由完全失效。05 自适应 RAG连「要不要检索」都让 Agent 决定自适应 RAG 在所有模式里成本最优因为它在最上游就做了一次过滤这个问题需要检索吗const RouteSchema z.object({ datasource: z.enum([vectorstore, web_search, direct_answer]), reason: z.string(), }); async function routeQuestion(state: RAGState) { const structuredLLM llm.withStructuredOutput(RouteSchema); const prompt 你是一个问题路由器决定如何最高效地回答用户问题。 问题${state.question} 选择路由策略 - direct_answer通用知识或对话上下文已覆盖不需要检索 - vectorstore关于特定文档、产品内部知识 - web_search需要实时信息或外部知识 选择最合适的一个给出原因。; return await structuredLLM.invoke(prompt); } // Graph 中根据路由结果分叉 function routeNode(state: RAGState { routing_decision?: string }): string { const decision state.routing_decision; if (decision direct_answer) return generate; if (decision web_search) return web_search; return retrieve; }这个模式特别适合通用助手场景——用户既会问「你好帮我写段代码」不需要检索也会问「我们的 API 文档里 rate limit 是多少」需要检索内部文档。统一入口自适应路由。06 常见坑Agentic RAG 踩过才知道坑1忘记设置最大重试次数Graph 无限循环纠错型 RAG 最容易踩这个坑。如果向量库里压根没有这个知识CRAG 会一直循环到 token 耗尽。// 正确做法硬性保护State 里记录重试计数 if (state.retry_count MAX_RETRY) { return fallback_generate; // 降级绝不继续循环 }坑2评分 Prompt 太模糊LLM 永远返回 “relevant”如果评分 Prompt 只说「判断文档是否相关」LLM 倾向于给「相关」——它在训练时被优化为「有帮助」的助手不喜欢说「这个我不知道」。解法在 Prompt 里给出具体的 “irrelevant” 判断条件比如「如果文档只是包含相同关键词但讨论完全不同话题算 irrelevant」。坑3多步 RAG 子问题有依赖却并行执行把复杂问题拆成子问题后如果直接并行检索但子问题 B 的答案依赖子问题 A 的结果最终合并时会出现逻辑断层。解法在分解步骤里判断依赖关系有依赖的串行独立的才并行。坑4工具描述写得太像LLM 每次都选同一个路由型 RAG 里如果三个工具描述都是「搜索相关信息」LLM 会分布极不均匀。解法每个工具描述要突出差异化适用场景用反例说明「什么情况下不要用这个工具」。坑5评分节点用大模型贵还不稳定用 LLM 评估 LLM 检索结果本身有幻觉风险。评分用小模型gpt-4o-mini配 Zod schema 强制结构化输出不要用大模型做简单分类任务——成本高且评分反而更不稳定。总结这篇我们把 Agentic RAG 从头到尾拆完了传统 RAG 的三个死穴单次检索无回头、单一数据源孤岛、无法分解复杂问题——不是调参能解决的是架构层的缺陷。四种模式各有适场路由型解决多数据源、多步型解决复杂分解、CRAG 解决检索质量、自适应型解决无意义检索开销——实际项目经常组合使用。CRAG 是工程价值最高的起点加一个评分节点 Query 改写节点 重试上限三步改造让 RAG 具备自我纠错能力。最大重试次数是生命线任何带循环的 Agentic RAG都要在 State 里记录重试计数超限强制降级永远不要让 Graph 无限重试。工具描述决定路由准确率路由型 RAG 里工具的 description 比代码逻辑更关键——写清楚适用场景和反例。最后2026 年一晃已经过半AI 大模型的热潮不仅没有降温反而持续升温金融行业用大模型做风控、医疗依靠 AI 解析影像电商、制造、教育各行各业都在把 AI 融入日常业务。曾经热闹的 “百模大战”早就告别单纯比拼模型参数正式进入落地应用时代。现在企业疯狂紧缺一类人才懂业务、懂 AI、能做出可上线项目的大模型开发工程师岗位缺口大薪资待遇十分可观。风口再好不如手握高薪 offer 实在。行情火热普通人、程序员该怎样从零入门大模型抓住这波机会今天整理好【2026 最新版】AI 大模型全套免费学习资源覆盖零基础入门、项目实战、理论知识、大厂面试从基础一路进阶。所有资料分类归档没有多余杂料无套路免费分享给想要入局 AI 赛道的程序员与零基础小白扫码免费领取全部内容1、大模型系统化完整学习路线2、大模型经典书籍文档3、AI 大模型最新行业研究报告4、企业级实战项目 完整配套源码5、大厂大模型面试真题汇总6、这些资料真的有用吗这份资料由我和鲁为民博士(北京清华大学学士和美国加州理工学院博士)共同整理现任上海殷泊信息科技CEO其创立的MoPaaS云平台获Forrester全球’强劲表现者’认证服务航天科工、国家电网等1000企业以第一作者在IEEE Transactions发表论文50篇获NASA JPL火星探测系统强化学习专利等35项中美专利。本套AI大模型课程由清华大学-加州理工双料博士、吴文俊人工智能奖得主鲁为民教授领衔研发。资料内容涵盖了从入门到进阶的各类视频教程和实战项目无论你是小白还是有些技术基础的技术人员这份资料都绝对能帮助你提升薪资待遇转行大模型岗位。这份完整版的大模型 AI 学习资料已经上传CSDN朋友们如果需要可以微信扫描下方CSDN官方认证二维码免费领取【保证100%免费】