RAG 与 AI Agent：智能体真的需要检索增强生成吗？

RAG 与 AI Agent：智能体真的需要检索增强生成吗？

很多企业做 AI 应用时，第一反应都是上 RAG：把内部文档切片、向量化、放进向量库，然后让大模型基于检索结果回答问题。

这个路径很常见，也确实能解决一批问题。但如果问题换成“AI Agent 真的需要 RAG 吗”，答案就没有那么简单。

先给结论：

智能体不一定需要 RAG，但一定需要外部接地。RAG 只是接地的一种方式，不应该被当成智能体架构的唯一核心。

这句话里有两个关键词：智能体、接地。

智能体的价值不是“会聊天”，而是能围绕目标持续完成任务。它需要感知环境、理解问题、做出计划、调用工具、检查结果，再继续下一步。这个循环要可靠，就不能只靠模型参数里存下来的旧知识。它必须知道“当前真实世界是什么样”，也必须知道“刚才那一步到底有没有成功”。

RAG 的作用，正是在某些场景下给模型补充外部事实。但它不是全部。

本文从第一性原理出发，重新拆开 RAG 和 Agent 的关系：RAG 到底解决了什么问题，为什么企业仍然重仓 RAG，什么时候应该继续用 RAG，什么时候应该转向工具调用、数据库查询、长上下文或记忆系统。

1. 先别急着谈 RAG，先看智能体缺什么

一个可工作的智能体，至少要跑通这条循环：

感知环境 -> 推理规划 -> 执行动作 -> 观察结果 -> 修正下一步

大模型本身主要提供的是推理能力。它可以读懂自然语言，抽象问题，生成计划，也可以写代码、写文档、做总结。但这些能力默认建立在模型已经学到的知识之上。

问题是，真实业务里最关键的信息往往不在模型参数里：

• 公司内部的制度、Wiki、接口文档、会议纪要；
• 刚刚更新的产品需求、价格、排班、库存；
• 当前机器上的代码、日志、测试结果；
• 需要权限控制的客户、订单、财务、工单数据；
• 任务执行后产生的新状态，比如命令是否成功、文件是否生成。

这些信息有三个共同点：私有、动态、可验证。

所以，智能体真正需要的不是“RAG”这个名词，而是“接地”能力，也就是让推理过程锚定在外部真实信息上。

接地可以有很多通道：

智能体的信息供给 = 参数知识 + 上下文注入 + 工具调用 + 持久记忆 训练时 RAG常在这里 API/DB/文件/搜索 跨会话状态

RAG 通常位于“上下文注入”这一层：先从外部知识库检索一批相关片段，再把片段塞进提示词，让模型基于这些片段生成回答。

但工具调用也是接地。读取文件是接地，查询数据库是接地，执行测试是接地，访问 API 是接地。对智能体来说，这些方式有时比 RAG 更直接。

比如代码智能体要理解一个函数怎么被调用，最可靠的方式往往不是从向量库里“相似搜索”几个片段，而是直接在仓库里搜索符号、打开文件、运行测试。因为它需要的是当前工作区的精确状态，而不是一段可能相似但不完整的文本。

2. RAG 的本质：把外部信息放进推理现场

RAG 是 Retrieval-Augmented Generation，通常翻译为“检索增强生成”。

从工程视角看，RAG 并不神秘。它做的事情可以压缩成一句话：

在模型回答之前，先从外部知识库找出相关信息，再把这些信息作为上下文交给模型。

一个经典 RAG 系统大致是这样的：

原始资料 -> 清洗 -> 切片 -> 向量化 -> 建索引 用户问题 -> 查询改写 -> 检索 -> 重排 -> 拼上下文 -> 生成回答 -> 引用来源

RAG 原论文把模型自身的参数知识看作 parametric memory，把外部可检索索引看作 non-parametric memory。这个划分很重要：模型参数里的知识更新成本高，也不容易追溯来源；外部索引里的知识可以增删改查，也更容易提供出处。

放到企业系统里，它解决的是一个很现实的问题：

模型本身不知道企业内部资料，但企业又希望它能基于这些资料回答问题。

于是 RAG 成了一个中间层。它不要求重新训练模型，也不要求把每个系统都改造成 API。只要把文档导进去，经过切片和索引，就能做出一个“能回答内部资料问题”的原型。

这也是为什么 RAG 很容易从 demo 走到 POC。它的技术门槛、交付周期、组织阻力都相对可控。

但 RAG 隐含了几个假设：

所以，RAG 不是“接上向量库就好了”。它是一条完整的信息供应链。任何一个环节失真，最后都会变成“检索到了看似相关但其实不对的内容，然后模型非常自信地回答错”。

3. RAG 真正擅长什么，又不擅长什么

RAG 最适合解决三类问题。

第一类是私有知识问答。

比如企业制度、产品手册、接口说明、历史事故复盘、客服话术库。这些资料大多是非结构化文本，本身就适合“切片、检索、引用”的流程。

第二类是知识时效性。

模型训练有截止时间。训练之后发生的事情，或者企业内部刚更新的流程，模型都不应该凭空猜。RAG 可以把新内容放进外部知识库，用索引更新替代模型再训练。

第三类是可追溯回答。

在金融、医疗、法律、企业合规等场景里，用户不只关心答案，还关心答案依据。RAG 可以把“引用了哪些文档、哪些片段”展示出来，让人能追溯和复核。

但 RAG 不擅长的地方也很明显。

第一，检索质量经常被低估。

很多人以为 RAG 的难点在大模型，其实更常见的问题在检索。用户的问题可能很口语化，文档里的术语却很正式；用户问的是一个组合问题，答案分散在多个文档；用户的问题带上下文，但检索系统只看到最后一句话。

第二，多跳推理不天然可靠。

如果答案需要跨多个材料综合，比如“结合今年政策、A 产品限制、B 客户合同条款，判断这个方案能不能做”，单次检索几个片段往往不够。你需要查询规划、多轮检索、结构化中间结果，甚至需要让智能体自己判断是否继续查。

第三，结构化数据不该硬塞进文档。

订单状态、库存、账单、权限、指标数据，本质上适合数据库查询或 API 调用。把它们导成文本再做向量检索，既损失结构，也容易产生权限和新鲜度问题。

第四，维护成本常常在 POC 之后暴露。

RAG 项目刚演示时只需要几十份文档，效果可能不错。真正上线后，文档会更新，权限会变化，旧版本要失效，用户问题会变复杂，答案要可审计，错误要能回放。这个时候，RAG 就不再是“向量库 + Prompt”，而是一个需要持续运营的知识系统。

可以把 RAG 的失败路径记成下面这条链：

资料质量差 -> 切片不合理 -> 检索召回差 -> 上下文拼接乱 -> 生成无约束 -> 没有评估 -> 线上不可控

如果一个 RAG 系统效果不好，先不要急着换大模型。很多时候，应该先查这条链上的前几个环节。

4. 智能体一定要 RAG 吗？

不一定。

更准确的说法是：智能体一定需要外部接地，但 RAG 只是接地方式之一。

对智能体来说，外部接地至少有四种典型方式。

如果任务是“根据公司知识库回答员工请假制度”，RAG 很合适。因为答案通常在文档里，用户需要自然语言解释，也需要引用来源。

如果任务是“帮我查这个客户今天的订单是否能退款”，RAG 就不应该是主路径。正确做法是调用订单系统、支付系统、售后规则引擎，再基于结构化结果生成解释。

如果任务是“修复这个代码仓库里的一个 bug”，RAG 也不是最佳核心。智能体更需要文件搜索、代码阅读、命令执行、测试反馈。这些工具返回的是当前环境里的 ground truth，而不是相似文本。

如果任务是“长期陪我管理一个项目”，则还会出现记忆系统。它需要记录用户偏好、历史决策、任务状态，但这些记忆不应该和企业事实混在一起。事实应该来自权威数据源，记忆只保存个性化和过程性信息。

所以，在 Agent 架构里，RAG 最好被看作一个“知识检索工具”，而不是整个智能体的代名词。

一个更合理的架构是：

用户目标 -> Planner 判断需要哪些信息 -> RAG 工具检索非结构化知识 -> API/DB 工具读取结构化与实时数据 -> 文件/命令工具获取运行环境反馈 -> Memory 保存长期偏好和任务状态 -> Evaluator 检查答案是否有依据、动作是否成功

这也是很多 Agent 工程实践的共同趋势：不要把所有知识都塞进一个向量库，而是让模型在任务过程中选择合适的信息通道。

5. 为什么企业仍然重仓 RAG

既然 RAG 不是终点，为什么企业还在大量投入？

原因不是企业都被概念绑架了，而是 RAG 在当前阶段确实是一个很现实的局部最优解。

5.1 企业知识形态天然适配 RAG

企业里的知识大量存在于 Word、PDF、PPT、Wiki、邮件、会议纪要、产品手册、客服文档中。这些内容不是干净的数据库表，也不是统一 API，而是非结构化文本。

对这种资料，RAG 是阻力最小的桥梁。

你不需要重构所有业务系统，也不需要等数据中台完全治理好。先把关键文档接进来，做清洗、切片、索引，就能让 AI 用上其中一部分知识。

这对于企业落地很关键。很多时候，能上线的方案比理论上最优的方案更有价值。

5.2 相比微调，RAG 更适合知识更新

微调适合改变模型行为风格、输出格式、特定任务能力，但不适合把大量经常变化的事实塞进模型参数。

比如公司报销制度每个月都可能更新。如果用微调解决，每次更新都要重新准备数据、训练、评估、发布。用 RAG 则只需要更新知识库索引。

RAG 的核心优势不是“让模型变聪明”，而是“让模型在回答时看到新资料”。

5.3 相比长上下文，RAG 更经济

长上下文能力越来越强，但这不代表应该每次都把全部资料塞进提示词。

如果你有 10,000 页文档，用户只问一个很窄的问题，全量输入既浪费 token，也可能引入噪音。RAG 的价值在于先过滤，再把少量高相关内容交给模型。

也就是说，长上下文不是 RAG 的反面。它们可以配合：检索先缩小范围，长上下文再容纳更完整的相关材料。

5.4 相比 Agent 工具链，RAG 更容易交付

一个真正可靠的工具型 Agent，需要准备清晰的工具接口、权限控制、错误处理、审计日志、回滚机制和人工确认点。这些东西比“搭一个文档问答系统”复杂得多。

RAG 的落地门槛相对低：数据源可以先从文档开始，权限可以先按知识库或目录控制，回答也可以先限制在“只读问答”范围内。

这就是为什么很多企业会先做 RAG，再逐步引入 Agent 能力。它不是最终形态，但常常是第一站。

5.5 云厂商和生态已经把 RAG 产品化

AWS Bedrock Knowledge Bases、Azure AI Search、Google Vertex AI Search 等平台都已经把知识库、检索、引用、重排、权限、数据同步等能力包装成企业可购买的产品。

这进一步降低了企业采用 RAG 的成本。

从组织角度看，RAG 项目也更容易定义边界：接哪些文档、服务哪些问题、如何引用来源、如何统计命中率。相比一个开放式 Agent 项目，它更容易写进项目计划，也更容易验收。

所以，企业重仓 RAG 的根本原因是：

企业真正买的不是 RAG，而是“让 AI 用上企业知识”的能力。RAG 恰好是当前最容易采购、交付和治理的实现路径之一。

6. 让 RAG 少踩坑：不要只建向量库，要建知识供应链

如果你已经决定做 RAG，重点不是“选哪个向量库”，而是把整条知识供应链做好。

6.1 先治理资料，不要把垃圾喂给检索系统

RAG 对资料质量很敏感。源文档混乱，后面再强的模型也只能在混乱中找答案。

需要先回答几个问题：

• 哪些资料是权威来源？
• 是否存在多个版本互相冲突？
• 文档是否有更新时间、所属业务线、适用范围？
• 是否有权限边界，哪些人能看哪些内容？
• 废弃文档如何下线？

很多 RAG 系统回答错，不是模型幻觉，而是知识库里本来就有过期或冲突的信息。

6.2 切片不是越细越好

切片太细，检索命中容易丢掉上下文；切片太粗，又容易把无关内容塞进提示词。

更稳妥的做法是按语义结构切片，而不是按固定字数机械切。比如按标题层级、段落、表格、代码块、FAQ 条目来切，再加上文档标题、章节路径、版本、时间等元数据。

Anthropic 提出的 Contextual Retrieval 思路也值得参考：在每个 chunk 前补一段短上下文，让这个片段在脱离原文时仍然知道自己属于哪份文档、哪个章节、哪个实体。这样可以缓解“切片后失去上下文”的问题。

6.3 检索不要只靠向量相似度

向量检索擅长语义相似，但不一定擅长精确术语、编号、产品型号、错误码、函数名。

生产系统里常见的更稳组合是：

关键词检索 + 向量检索 + 元数据过滤 + 重排模型 + 阈值控制

关键词检索负责精确匹配，向量检索负责语义召回，元数据负责范围控制，重排模型负责把最可能有用的片段排到前面。

如果用户问题复杂，还可以加查询改写或查询拆解：

原始问题 -> 补全上下文 -> 拆成多个子问题 -> 并行检索 -> 合并重排 -> 生成

这也是“agentic retrieval”类方案想解决的问题：从单次查询，演进到带规划的多查询检索。

6.4 生成阶段要有约束

RAG 的答案应该尽量满足三点：

• 能指出依据来自哪些资料；
• 没有检索到足够依据时，敢说“不确定”；
• 不把检索结果之外的信息包装成事实。

一个简单但有效的提示词约束是：

请只基于给定资料回答。 如果资料不足以支持结论，请明确说明缺少什么信息。 回答中标注依据片段编号。 不要补充资料中没有出现的具体数字、日期、政策或承诺。

这不能彻底消灭幻觉，但可以把错误从“自信瞎编”拉回到“依据不足”。

6.5 一定要做评估，不要靠感觉

RAG 上线前至少要有一组黄金问题集。每个问题应该标注：

• 期望答案；
• 应该命中的文档或片段；
• 是否允许模型回答“不知道”；
• 权限边界；
• 过期答案示例。

评估指标可以分几层：

没有评估的 RAG，很容易停留在“演示时看起来不错”。真正上线后，用户问法一变，文档一更新，效果就开始漂。

7. 怎么选：RAG、工具调用、长上下文、微调、记忆

下面这张表可以作为架构选型的第一步。

这里最容易犯的错，是把所有问题都往 RAG 里塞。

RAG 适合“从一堆文本里找依据并生成解释”。如果问题本质是“查实时数据”，就应该用工具；如果问题本质是“执行任务”，就应该让 Agent 调用工具并观察结果；如果问题本质是“跨会话偏好”，就应该设计记忆。

一个更务实的路线是：

第一阶段：用 RAG 覆盖企业知识问答 第二阶段：把结构化系统接成工具 第三阶段：让 Agent 学会在 RAG、工具、记忆之间做选择 第四阶段：用评估和审计控制质量、成本和权限

这样做不会把系统锁死在 RAG 上，也不会一开始就跳到难以治理的开放式 Agent。

8. 总结：RAG 不是智能体的终点，但仍是重要工具

回到开头的问题：智能体真的需要 RAG 吗？

答案是：

智能体需要接地，不一定需要 RAG。RAG 是接地层里的一个重要工具，尤其适合企业非结构化知识问答，但它不能替代工具调用、数据库查询、长上下文和记忆系统。

理解这一点，就不会陷入两个极端。

一个极端是把 RAG 神化，好像所有企业 AI 问题都能靠“向量库 + Prompt”解决。这个想法忽略了检索质量、权限、新鲜度、评估和结构化数据的复杂性。

另一个极端是因为 Agent、长上下文、MCP、Memory 越来越火，就觉得 RAG 已经过时。这个判断也太早。企业的大量知识仍然是文档，仍然需要检索、引用、审计和治理。RAG 依然是最现实的入口。

更好的心智模型是：

RAG 不是 AI Agent 的大脑。 RAG 是智能体接触企业知识的一条通道。

当任务是文档知识问答时，让 RAG 站在前台；当任务需要实时事实和动作时，让工具调用站在前台；当任务需要长期个性化时，让记忆系统站在前台；当任务需要复杂规划时，再让 Agent 把这些能力组合起来。

最终要追求的不是“有没有 RAG”，而是系统能否在正确的时候拿到正确的信息，并且把答案、动作和依据都交代清楚。

参考资料

• Patrick Lewis et al.：Retrieval-Augmented Generation for Knowledge-Intensive NLP Tasks
• Anthropic：Contextual Retrieval
• Anthropic：Building Effective Agents
• Model Context Protocol：What is the Model Context Protocol?
• AWS：Retrieve data and generate AI responses with Amazon Bedrock Knowledge Bases
• Microsoft Learn：Retrieval-augmented generation in Azure AI Search
• Google Cloud：Grounding with Vertex AI Search