过去两年RAG 几乎已经成为企业大模型应用的标准组件。只要涉及企业知识库、私有数据问答、制度查询、项目资料检索大家首先想到的通常都是 RAG。最早我们讨论的问题很简单Embedding 模型选哪个向量数据库选 Milvus、pgvector 还是 ElasticsearchChunk 切多大Top-K 取多少后来问题逐渐变复杂。大家开始讨论Hybrid Search 怎么做BM25 和向量检索怎么融合Reranker 有没有必要Parent-Child Chunk 能不能提高召回率GraphRAG 到底什么时候值得使用而到了现在RAG 面临的问题又发生了一次变化。真正困难的问题开始变成这个问题到底需不需要检索应该先查哪个知识库第一次没查到要不要换一个 Query一个问题需要组合多个知识源怎么办什么时候应该查询数据库而不是向量库搜索出来的信息够不够支撑最终结论如果多个资料之间互相矛盾要不要继续寻找新的证据这些已经不再只是 Retrieval 的问题。它开始变成一个 Agent 问题。因此现在越来越多系统开始从传统 RAG 向Agentic RAG演进。如果从技术演进角度来概括这个阶段也可以称作RAG 3.0。需要说明的是RAG 3.0 并不是一个由某个标准组织正式定义的版本号而是一种更容易理解技术演进的说法。但背后的变化是真实存在的。RAG 正从一个固定的“检索增强生成流水线”逐渐演变成一个由 Agent 主导的自主知识获取系统。一、从 RAG 1.0 到 RAG 2.0我们一直在解决“怎么把知识找回来”RAG 最初解决的问题其实非常直接。大模型虽然知道很多公开知识但它不知道企业自己的知识。比如公司的差旅制度是什么某个项目去年做了什么客户技术方案有哪些约束内部模型部署参数是多少这些内容既不在模型训练数据里也不适合为了几个文档重新训练一个模型。于是最早的 RAG 出现了。典型架构非常简单用户问题 ↓Embedding ↓Vector Search ↓Top-K Chunk ↓Prompt ↓ LLM ↓Answer核心逻辑就是Retrieve → Generate先检索再生成。这解决了一个非常重要的问题企业私有知识如何进入大模型的上下文。但 RAG 1.0 很快暴露出一个根本缺陷。模型回答质量高度依赖第一次搜索。如果第一次召回错了后面的模型即使再聪明也只能基于错误材料生成答案。比如用户问“去年哪个 AI 项目的成本最高主要原因是什么”传统 RAG 很可能直接拿整句话去做向量搜索。但真正需要的信息可能分散在项目清单预算表GPU 采购记录云模型调用账单项目周报会议纪要。一次 Top-K 很难把这些资料同时找到。于是 RAG 进入第二阶段。RAG 2.0 的核心目标变成不是只要搜到而是要尽可能搜准。这一阶段出现了大量 Retrieval Engineering 技术。Query Rewrite用户输入的问题通常不一定是最适合搜索的问题。例如“这个项目为什么这么贵”如果直接做 Embedding语义非常模糊。系统需要结合对话上下文把它改写成AI 网关 2026 年成本构成或者AI 网关 GPU 资源、模型调用及研发成本这就是 Query Rewrite。Multi Query进一步系统不再只生成一个 Query而是拆成多个搜索方向项目总预算GPU 采购成本模型 API 调用费用软件研发投入运维费用然后分别检索再融合结果。这样可以显著提高复杂问题的召回率。Hybrid Search单独使用向量检索也并不总是可靠。向量搜索擅长语义相似但对型号、编号、专有名词、数字等精确信息不一定敏感。例如H20GLM-5.2项目编号 XJ2026-018这种场景 BM25 往往比 Dense Retrieval 更可靠。于是典型检索链路开始变成Query │ ┌──────┴──────┐ ↓ ↓ Dense Search BM25 Search ↓ ↓ └──────┬──────┘ ↓ Fusion ↓ RerankerDense Retrieval 负责语义。BM25 负责关键词。Fusion 可以使用 RRF也可以根据业务场景进行加权。Reranker第一阶段 Retriever 的目标通常是尽量不要漏。例如先找 50 个候选 Chunk。Reranker 再解决哪些是真的相关。于是Retriever Top 50 ↓Cross Encoder / Reranker ↓ Top 5 ↓ LLM这已经成为今天很多企业 RAG 系统的标准结构。与此同时还有Parent-Child ChunkSemantic ChunkingTable-aware ChunkingHeader-aware ChunkingGraphRAGMetadata Filter。本质上全部是在解决同一个问题如何让真正需要的信息进入模型 Context。但到了这里RAG 仍然存在一个没有解决的问题整个 Retrieval Pipeline 是开发人员提前设计好的。无论用户问什么基本都按照同一套流程运行。而真实世界的问题本身并不是固定流程。二、RAG 3.0真正的变化不是检索算法而是检索控制权假设用户问去年几个 AI 项目中哪个投入最高为什么投入这么高如果让一个人去解决他通常不会直接把整句话丢进搜索框。一个正常的分析过程更像先找去年有哪些 AI 项目 ↓分别查询每个项目的投入 ↓ 比较成本 ↓ 找到最高项目 ↓ 分析成本构成 ↓继续查项目总结和会议纪要 ↓ 确认高成本原因 ↓ 形成结论这里面包含的已经不是一次 Retrieval。而是一系列连续决策任务拆解知识需求判断搜索规划数据源选择结果分析再次搜索证据验证。因此架构必须发生变化。传统 RAG 是Query ↓Retriever ↓LLMAgentic RAG 更像Query ↓Planner ↓Sub Tasks ↓Tool Router ↓Retrieve ↓Evaluate ↓Need More Evidence? ↙ ↘Yes No ↓ ↓Rewrite Synthesize ↓ ↓Retrieve Answer最大的变化并不是多了一个 Reranker也不是换了一个更好的 Vector DB。而是谁来决定下一次检索什么。过去Developer ↓设计固定 Pipeline现在Agent ↓根据任务动态决定这就是 Agentic RAG 的核心。换句话说传统 RAG 的中心是 Retriever。Agentic RAG 的中心变成了 Agent。RAG 只是 Agent 可以调用的一种 Tool。这也是为什么现在很多 Agent 框架里知识库开始和 SQL、Web Search、Browser、MCP 并列。例如Agent │ ┌───────────┼───────────┐ ↓ ↓ ↓ RAG Search SQL MCP ↓ ↓ ↓ Vector DB Database Enterprise API │ │ │ └────── Evidence ───────┘用户只问一个问题。Agent 可能实际执行十几个内部 Query。因此到了这个阶段用户问题已经不再等于检索 Query。用户问题只是一个 Task。真正的 Retrieval Query是 Agent 执行过程中不断生成的中间产物。比如太空算力现在有哪些真正落地的项目国内外有什么区别Agent 可能生成国内已发射太空计算卫星项目国内在轨 AI 推理卫星项目国外 orbital computing projectsStarcloud orbital compute deployment已发射项目和规划项目区别太空数据中心典型应用最后把多个结果组合起来。因此 RAG 3.0 新增加了一个非常重要的能力Query Planning。未来评估一个 RAG 系统可能不能只看 RecallK。还需要看Agent 有没有问对问题。三、Agentic RAG 的核心不是“多搜几次”而是一个完整的 Retrieval Loop如果只是让模型连续调用三次知识库其实并不能算真正成熟的 Agentic RAG。真正关键的是形成闭环。典型架构应该包含至少五个组件。Planner先判断怎么解决问题用户问题进来以后不一定立即调用 Retriever。首先应该进行任务分析。例如{ task_type: multi_hop_research, steps: [ 查询2026年AI项目列表, 查询各项目成本, 计算并比较项目投入, 查询最高成本项目的成本构成, 查询相关项目总结并分析原因 ]}Planner 不一定要单独使用一个大模型。很多场景可以直接利用主模型通过 Structured Output 生成计划。复杂系统则可能专门使用一个较小模型负责规划降低成本。Tool Router决定去哪查企业知识并不会全部存在向量库里。真正的系统里通常至少有文档知识库数据库CMDBOACRMWiki代码仓库互联网企业 API所以 Agent 需要判断“项目方案是什么”→ RAG“预算多少”→ SQL“负责人是谁”→ CMDB“审批状态”→ OA“竞争对手最近发生什么”→ Web Search这就是 Tool Router。这一步也是 Agentic RAG 和传统知识库最明显的区别之一。未来企业内部的数据架构不一定是所有数据 ↓Embedding ↓一个巨大 Vector DB更合理的方式可能是Agent │ Knowledge Router │ ┌─────────────┼─────────────┐ ↓ ↓ ↓ Documents SQL API ↓ ↓ ↓ Vector DB Database Business System数据仍然保留在最适合自己的系统中。Agent 通过统一 Knowledge Access Layer 使用它们。Retriever负责真正找资料Retriever 本身仍然非常重要。Agentic RAG 并没有取代传统 Retrieval Engineering。反而要求 Retrieval 更可靠。通常仍然会包含Query Rewrite ↓Dense Sparse ↓Metadata Filter ↓Fusion ↓Rerank ↓Parent Chunk Expansion也就是说RAG 1.0 和 RAG 2.0 的技术并没有消失。而是成为 RAG 3.0 的基础能力。Evaluator判断证据够不够这是很多 Demo 最容易忽略的一层。第一次搜索之后不能直接回答。系统应该判断当前 Evidence 能回答用户问题吗例如{ sufficient: false, missing: [ 缺少2026年项目实际支出数据, 缺少GPU采购费用 ], next_query: [ 2026 AI项目实际支出, AI项目GPU采购成本 ]}如果不够就继续搜索。于是整个系统形成Retrieve ↓Evaluate ↓Enough? ↙ ↘No Yes↓ ↓Rewrite Generate↓Retrieve这才是真正的 Retrieval Loop。Evidence / Verification答案必须有证据企业 RAG 最终不能只输出一句“根据资料”。应该建立 Evidence Layer。比如结论 A├── 项目预算表 2026.xlsx├── AI网关项目周报第18期└── 9月项目评审会议纪要结论 B├── GPU采购记录└── 财务系统查询结果如果两个来源冲突文档 A预算 1200 万数据库 B实际支出 1380 万系统应该知道这是不同口径。而不是随机选一个数字回答。因此成熟 Agentic RAG 最终会逐渐加入Source ReliabilityFreshnessConflict DetectionCitationVerification。这也是为什么 RAG 3.0 本质上正在从Retrieval System演变成Evidence System。四、进入企业生产环境后真正难的是权限、成本和可观测性Agentic RAG Demo 很容易做。给 Agent 几个 Tool让它自己搜索很快就能跑起来。但一进入企业生产环境复杂度会迅速上升。首先是权限。传统知识库的权限模型通常很简单User ↓Knowledge Base用户有知识库权限就能搜索。但 Agentic RAG 里User ↓Agent ↓RAGSQLMCPAPIBrowserAgent 是代表用户执行任务。因此真正的权限模型应该是用户身份 ↓Agent Runtime ↓Authorization ↓Tool Permission ↓Resource Permission ↓Data Filter例如一个研发人员问“帮我分析所有部门今年的 GPU 采购情况。”即使 Agent 能调用财务数据库也不能因此绕过原有权限体系。所以权限必须发生在Retrieval Before Generation。而不是先把全量数据拿给 LLM再让模型自己判断哪些不能说。这是完全不同的安全模型。第二个问题是成本。传统 RAG 一次请求可能是Embedding × 1Retrieval × 1LLM × 1Agentic RAG 可能变成Planner × 1Query Rewrite × 3Retriever × 6Evaluator × 3Tool Call × 4Synthesis × 1Verification × 1一个问题可能触发十几次甚至几十次调用。因此 Agentic RAG 必须设计预算机制。例如max_iterations 5max_tool_calls 10max_retrieval_rounds 4max_input_tokens 100kmax_execution_time 30s而且最好能够动态判断。简单问题直接 Standard RAG。复杂问题进入 Agentic RAG。比较合理的架构是Query ↓ Complexity Router ↙ ↘ Simple Query Complex Query ↓ ↓ Standard RAG Agentic RAG ↓ ↓ Answer Answer例如“差旅补贴标准是多少”没有必要运行 Agent。一次检索即可。而“过去三个项目成本分别是多少哪部分增长最快导致增长的主要原因是什么”才适合进入 Agentic 流程。因此未来成熟的系统不是所有问题都 Agent 化。而是只在必要的时候 Agentic。第三个问题是可观测性。传统 RAG 调试主要看QueryTop-KScoreAnswerAgentic RAG 需要记录整个 TrajectoryUser Query ↓Plan ↓Tool Selection ↓Generated Query ↓Retrieved Evidence ↓Evaluation ↓Next Action ↓Tool Call ↓Final Evidence ↓Answer否则当用户说“为什么这个答案错了”你根本无法判断是Planner 错了Query Rewrite 错了Retriever 漏召回Reranker 排错了Tool Router 调错工具数据库返回旧数据还是 LLM 最后总结错了。因此 Agent Trace 会逐渐成为 Agentic RAG 的基础设施。五、为什么 WeKnora 这一类产品开始越来越不像“知识库”这也是最近 WeKnora 这类开源项目值得关注的原因。如果按照传统 RAG 的产品形态一个知识库系统通常只需要上传文档 ↓解析 ↓Chunk ↓Embedding ↓Retrieval ↓问答但现在 WeKnora 已经明显超出了这个范围。它一方面仍然保留典型 RAG 能力Hybrid SearchRerankParent-Child ChunkCitationGraphRAG另一方面开始加入ReAct AgentMCPSkillBrowserSandbox于是知识库从Retriever逐渐变成Knowledge Platform例如一个 Agent 可以先搜索企业知识库再调用 MCP 查询业务系统然后进入 Sandbox 处理文件最后综合结果生成报告。这说明 RAG 产品的边界正在发生变化。过去Knowledge Base ↓ LLM未来可能是Agent │ Knowledge Runtime │ ┌─────────────┼─────────────┐ ↓ ↓ ↓ RAG MCP SQL ↓ ↓ ↓ Document Business API Database这里真正重要的已经不是“有没有一个知识库”。而是有没有一套统一的Knowledge Runtime。它负责知识在哪里谁可以访问应该用什么方式查询需要查几次什么时候停止证据是否足够最终答案来自哪里。从这个角度看RAG 未来可能逐渐从一个显性的产品能力下沉成 Agent 基础设施中的一层。就像今天很多业务系统都依赖数据库但普通用户并不会感知“我现在正在使用数据库。”未来用户也可能不会感知“我正在使用 RAG。”他们只会对 Agent 说帮我分析一下这个项目为什么延期。而后台自动完成查项目文档 ↓查 Jira ↓查会议纪要 ↓查代码提交 ↓查负责人反馈 ↓交叉验证 ↓形成分析RAG 仍然存在。只是它变得越来越隐形。六、RAG 3.0 真正意味着什么从 Retrieval 到 Autonomous Knowledge Acquisition如果把过去几年的演进重新看一遍其实逻辑非常清楚。RAG 1.0 解决的是有没有知识。所以核心技术是EmbeddingVector DBTop-K。RAG 2.0 解决的是能不能把正确知识找回来。所以出现Query RewriteHybrid SearchRerankerSemantic ChunkingParent-Child ChunkGraphRAG。而到了 RAG 3.0真正的问题开始变成为了完成当前任务我下一步应该获取什么知识因此系统开始需要PlannerTool RouterMulti-step RetrievalEvaluatorReflectionVerificationMemoryMCPAgent Trace。所以如果一定要用三句话概括这三代技术我更愿意这样理解RAG 1.0让模型拥有企业知识。RAG 2.0让模型找到更准确的企业知识。RAG 3.0让 Agent 自己知道应该寻找什么知识。这三者并不是互相替代。而是逐层叠加。最终一个成熟的 Agentic RAG 系统可能长这样User Task │ ↓ Agent Runtime │ ↓ Task Planner │ ↓ Knowledge Router ┌─────────────┼─────────────┐ ↓ ↓ ↓ RAG SQL MCP │ │ │ Hybrid Search Database Enterprise API │ │ │ └──────── Evidence ─────────┘ │ ↓ Evaluator │ ┌───────┴───────┐ ↓ ↓ Continue Sufficient ↓ ↓ Re-plan Verify ↓ Answer到了这里RAG 已经不再只是Retrieval-Augmented Generation。它正在走向Agentic Retrieval。再进一步就是Autonomous Knowledge Acquisition。Agent 不再被动等待知识送进 Context。而是根据任务主动判断什么时候应该查应该查什么去哪里查应该查多少哪些证据可信什么时候可以停止。这可能才是所谓“RAG 3.0”真正值得关注的地方。下一阶段企业 AI 的竞争可能也不再只是谁的向量检索快几个毫秒谁的 Recall10 高几个点谁支持更多 Vector DB。而是谁能让 Agent 更稳定、更低成本、更安全地获取完成任务所需的知识。当这件事情真正成熟以后企业知识库也不会再只是一个“上传文件然后问问题”的系统。它会逐渐成为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时代风口轻松解锁职业新可能希望大家都能把握机遇实现薪资/职业跃迁这份完整版的大模型 AI 学习资料已经上传CSDN朋友们如果需要可以微信扫描下方CSDN官方认证二维码免费领取【保证100%免费】