当 RAG 不再只是"查了再说"

过去两年，检索增强生成（RAG）几乎成了大模型落地的标配。企业知识库问答、智能客服、文档摘要——几乎所有需要"让模型知道一些它训练时没见过的新东西"的场景，都会先搭一个 RAG 管道。

但随着应用深入，一个尴尬的事实浮出水面：传统 RAG 太"直"了。

用户问一句，系统去向量库里捞几段文本，拼到 Prompt 里让模型生成回答。整个流程像一条流水线——检索一次，生成一次，没有回头路。遇到复杂问题，这种"一锤子买卖"往往答非所问。

有句话说，工具的价值不在于它有多复杂，而在于它能不能解决真正的问题。传统 RAG 解决的是"模型不知道"的问题，但它解决不了"模型想不清楚"的问题。

这就是 Agentic RAG 出现的背景。它不是对 RAG 的简单升级，而是一种范式转变：把 RAG 从一个固定的管道，变成一个能自主决策、动态规划的智能体系统。

本文将拆解这一演进路径，从架构对比到技术选型，再到一个可以真正跑起来的系统设计，带你走完从静态检索到动态推理的全过程。

传统 RAG：一条走不通的直线

基本流程回顾

传统 RAG 的架构非常清晰，三步走：

1. 索引阶段：将文档切片，通过 Embedding 模型转为向量，存入向量数据库。
2. 检索阶段：用户提问后，将问题也转为向量，在数据库中做相似度匹配，返回 Top-K 个文本片段。
3. 生成阶段：将检索到的片段拼入 Prompt，交给大语言模型生成最终回答。

1

用户提问 → 向量化 → 向量数据库检索 → Top-K 文本 → 拼接 Prompt → LLM 生成回答

这个流程简洁、可控、工程实现成本低，在简单问答场景下效果不错。

三个致命短板

但一旦问题变复杂，传统 RAG 就会暴露出结构性缺陷：

第一，检索是一次性的，没有纠错能力。

用户问"公司 A 和公司 B 在 2024 年的市场份额对比"，系统可能只检索到公司 A 的数据，公司 B 的信息被遗漏。因为没有"回头再查"的机制，模型只能基于不完整的信息硬编答案。

第二，没有推理规划能力。

面对一个需要多步分析的问题，比如"分析这份合同的违约风险并给出修改建议"，传统 RAG 无法判断需要先查合同条款、再查相关法律法规、最后交叉比对。它只能把所有检索到的内容一股脑丢给模型，期待模型自己理清逻辑。

第三，对工具的使用为零。

传统 RAG 只会"查向量库"这一件事。但真实场景中，很多问题需要查数据库、调 API、做计算、访问外部系统。纯靠文本检索远远不够。

Agentic RAG：让系统学会"想一想再动手"

核心理念

Agentic RAG 的本质，是给 RAG 系统装上一个"大脑"——一个具备规划、推理、反思和工具调用能力的智能体（Agent）。

这个智能体不再被动地执行固定流程，而是主动地：

• 分析用户意图：理解问题的真实需求，判断需要什么信息。
• 制定检索计划：决定从哪里查、查什么、查几次。
• 调用多种工具：向量检索只是工具之一，还可以调用搜索引擎、数据库、计算器、代码执行器等。
• 评估中间结果：检查已获取的信息是否足够、是否准确，不够就再查。
• 综合推理生成：基于多轮收集的信息，进行逻辑推理后生成最终回答。

如果传统 RAG 是一个"查字典的翻译"，那 Agentic RAG 就是一个"会上网、会打电话、会反复确认的研究员"。

架构分层

一个完整的 Agentic RAG 系统可以分为四层：

感知层：接收用户输入，进行意图识别和问题分析。

规划层：基于问题分析结果，制定执行计划。这一层通常由大模型充当"指挥官"，决定下一步该做什么。

执行层：实际调用各种工具完成信息获取和处理。每个工具是一个独立的模块，负责特定类型的操作。

反思层：对执行结果进行质量评估，判断是否需要补充检索或调整策略。

这四层不是线性执行的，而是一个可以循环迭代的闭环。规划层可以随时调整计划，反思层可以触发新一轮的执行。

传统 RAG vs Agentic RAG：全维度对比

为了更清晰地理解两者的差异，我们从多个维度做详细对比：

一个直观的类比

传统 RAG 像快餐店的标准化流程：你点单，厨房按配方出餐，端上来就完事。不管你要的是汉堡还是满汉全席，流程一样。

Agentic RAG 像一位经验丰富的主厨：先看你的需求，想想需要什么食材（检索计划），去不同的供应商那里采购（多工具调用），边做边尝（反思评估），最后端出一道完整的菜品。

显然，后者的成本高、速度慢，但能解决的问题范围大了不止一个量级。

动态规划：Agentic RAG 的"大脑"

任务分解

动态规划的第一步是任务分解。当用户提出一个复杂问题时，Agent 需要将其拆解为若干子任务。

例如用户问：“帮我分析一下我们 Q3 销售报告中增长最快的产品线，并和竞品做对比。”

Agent 的分析过程可能是：

1. 先检索 Q3 销售报告，定位增长最快的产品线
2. 获取该产品线的详细销售数据
3. 检索竞品相关信息
4. 整合数据，进行对比分析
5. 生成结论和建议

每一步的输出可能影响下一步的决策。如果第一步发现报告中有多个产品线增速接近，Agent 可能需要先确认用户关心的是哪个维度。

执行图构建

任务分解的结果不是简单的线性列表，而是一个有向无环图（DAG） 或更复杂的执行图。有些子任务可以并行执行，有些必须等待前置任务完成。

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15

         [分析用户意图]
              |
      ┌───────┴───────┐
      ▼               ▼
[检索内部报告]   [搜索竞品信息]
      │               │
      └───────┬───────┘
              ▼
        [数据整合]
              │
              ▼
        [对比分析]
              │
              ▼
        [生成报告]

动态调整

执行过程中，Agent 可以根据中间结果动态调整计划。这是与传统 RAG 最大的区别之一。

假设在检索竞品信息时，Agent 发现某个竞品的公开数据非常少。它可以：

• 扩大搜索范围，尝试更多数据源
• 降低该竞品在最终对比中的权重
• 明确告知用户该竞品数据不足，仅做部分对比

这种灵活性是固定管道无法实现的。

多步推理：从"拼答案"到"想答案"

思维链在 RAG 中的应用

多步推理的核心技术是思维链（Chain of Thought）。在 Agentic RAG 中，大模型不只是生成最终答案，而是先输出推理过程，再基于推理结果决定下一步行动。

典型的推理链可能长这样：

1
2
3
4
5
6
7
8

思考：用户想知道合同中的违约条款是否合理。
推理：我需要先找到合同中的违约条款，然后查找相关法律规定，最后进行比对。
行动：检索合同文档中的违约条款部分。
结果：找到第 12.3 条，规定违约金为合同金额的 30%。
思考：30% 的违约金是否合法？需要查阅《民法典》相关规定。
行动：检索法律法规数据库。
结果：根据相关司法解释，违约金一般不超过实际损失的 130%。
思考：需要确认是否有实际损失的数据...

推理深度控制

多步推理的一个关键挑战是深度控制。推理链条太长会导致延迟增加和成本上升，太短则可能分析不够充分。

实践中常见的策略包括：

• 预算机制：设定最大推理步数（如 5 步），超出后强制收敛。
• 信息饱和度判断：当 Agent 评估已获取信息足够回答时，提前终止推理。
• 超时降级：如果推理时间超过阈值，基于已有信息生成"最佳近似回答"并标注置信度。

工具调用：让 RAG 长出"手脚"

工具生态设计

在 Agentic RAG 中，向量检索只是众多工具之一。一个成熟的系统通常会接入以下工具：

信息检索类：

• 向量数据库检索（语义匹配）
• 关键词搜索引擎（精确匹配）
• 结构化数据库查询（SQL）
• 外部 API 调用（实时数据）

信息处理类：

• 代码执行器（数值计算、数据处理）
• 表格解析器（结构化数据提取）
• 图像理解器（图表解读）

信息生成类：

• 摘要生成器（长文本压缩）
• 对比分析器（多维度比对）
• 可视化生成器（图表输出）

工具选择机制

Agent 需要决定何时使用哪个工具。这通常通过工具描述 + 模型决策的方式实现。

每个工具都有结构化的描述信息，包括：名称、功能说明、输入参数、输出格式、适用场景。Agent 在规划阶段根据当前任务需求和各工具的描述，选择最合适的工具。

一个工具描述的示例：

1
2
3
4
5
6
7

name: sql_query
description: 在结构化数据库中执行 SQL 查询，适用于需要精确数值、日期筛选、聚合计算的场景
parameters:
  query: 标准 SQL 语句
  database: 目标数据库名称
returns: 查询结果表格
limitations: 仅支持 SELECT 语句，不支持数据修改操作

工具编排模式

工具调用不是简单的串行执行，常见的编排模式有三种：

顺序编排：工具 A 的输出作为工具 B 的输入，形成处理链。

并行编排：多个工具同时调用，结果汇总后统一处理。适合相互独立的子任务。

条件编排：根据工具 A 的输出结果，动态决定调用工具 B 还是工具 C。这是最灵活也最复杂的模式。

向量数据库选型：Agentic RAG 的基石

虽然 Agentic RAG 的能力远超传统 RAG，但向量检索仍然是最核心的信息获取手段。向量数据库的选型直接影响系统的检索质量和响应速度。

主流向量数据库对比

选型决策树

在实际项目中，向量数据库的选型不应只看性能跑分，而要结合团队现状和业务需求：

• 团队小、想快速验证 → Chroma 或 Pinecone，零运维成本
• 已有 PostgreSQL 基础设施 → pgvector，减少引入新组件
• 数据量在千万级以上，需要高可用 → Milvus 或 Qdrant
• 需要多模态检索（图文混合） → Weaviate
• 不想管基础设施，预算充足 → Pinecone 或各云厂商托管服务

混合检索：Agentic RAG 的标配

纯向量检索在 Agentic RAG 中已经不够用了。混合检索（Hybrid Search） 结合了向量语义匹配和关键词精确匹配的优势，是当前最佳实践。

混合检索的典型策略：

1. 并行检索：同一查询同时走向量检索和 BM25 关键词检索
2. 结果融合：使用 RRF（Reciprocal Rank Fusion）等算法合并两路结果
3. 重排序：用 Cross-Encoder 对融合后的结果做精排

在实测中，混合检索相比纯向量检索，在复杂查询场景下的召回率通常能提升 15%-30%，这在 Agentic RAG 的多轮检索中会被进一步放大。

动态化 RAG 技术：让检索"活"起来

查询改写与扩展

用户输入的原始查询往往不是最优的检索语句。Agentic RAG 会在检索前对查询进行智能改写：

子查询分解：将一个复杂问题拆成多个简单子查询，分别检索后合并。

例如：“特斯拉和比亚迪 2025 年 Q1 销量对比"会被拆为：

• “特斯拉 2025 年第一季度销量数据”
• “比亚迪 2025 年第一季度销量数据”

查询扩展：基于原始查询生成语义相近但措辞不同的变体，扩大检索覆盖面。

假设文档嵌入（HyDE）：先让模型生成一个"假设性答案”，用这个答案去做向量检索，而不是用原始问题。因为答案和文档的语义空间更接近，检索效果往往更好。

自适应检索策略

传统 RAG 的 Top-K 是固定的，不管问题简单还是复杂，都返回同样数量的文档片段。Agentic RAG 采用自适应策略：

动态 K 值：根据问题复杂度自动调整返回数量。简单事实查询可能只需要 2-3 个片段，复杂分析可能需要 10-15 个。

迭代检索：第一轮检索后，Agent 评估结果质量。如果信息不足或存在矛盾，自动发起第二轮检索，可能调整检索策略（换关键词、扩大范围等）。

检索质量门控：设置相似度阈值，低于阈值的检索结果被丢弃，避免噪声信息干扰模型生成。

上下文窗口管理

大模型的上下文窗口是有限的。当 Agentic RAG 通过多轮检索积累了大量信息后，如何高效利用有限的窗口成为关键问题。

常见策略包括：

• 信息压缩：对检索到的长文本做摘要，保留关键信息
• 相关性排序：按与当前问题的相关度排序，优先保留高相关内容
• 分层存储：将信息分为"核心证据"和"补充材料"，核心证据全文保留，补充材料只保留摘要
• 滑动窗口：在多轮对话中，逐步淘汰与当前话题相关性最低的上下文

可落地的 Agentic RAG 系统架构

综合以上技术要素，下面给出一个面向生产环境的 Agentic RAG 系统架构设计。

整体架构图

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31

┌─────────────────────────────────────────────────────────┐
│                      用户接口层                          │
│              (API Gateway / WebSocket)                   │
└───────────────────────┬─────────────────────────────────┘
                        │
┌───────────────────────▼─────────────────────────────────┐
│                     Agent 编排层                         │
│  ┌──────────┐  ┌──────────┐  ┌──────────┐  ┌────────┐ │
│  │ 意图分析  │→│ 计划生成  │→│ 执行引擎  │→│ 反思评估│ │
│  └──────────┘  └──────────┘  └──────────┘  └────────┘ │
│       ↑                                      │         │
│       └──────────── 反馈循环 ────────────────┘         │
└───────────────────────┬─────────────────────────────────┘
                        │
┌───────────────────────▼─────────────────────────────────┐
│                      工具层                              │
│  ┌────────┐ ┌────────┐ ┌────────┐ ┌────────┐          │
│  │向量检索 │ │关键词搜索│ │SQL查询 │ │外部API │          │
│  └────────┘ └────────┘ └────────┘ └────────┘          │
│  ┌────────┐ ┌────────┐ ┌────────┐                      │
│  │代码执行 │ │文档解析 │ │缓存管理 │                      │
│  └────────┘ └────────┘ └────────┘                      │
└───────────────────────┬─────────────────────────────────┘
                        │
┌───────────────────────▼─────────────────────────────────┐
│                     数据层                               │
│  ┌──────────┐  ┌──────────┐  ┌──────────┐  ┌────────┐ │
│  │向量数据库 │  │关系数据库 │  │文档存储   │  │对象存储│ │
│  │(Milvus)  │  │(PostgreSQL)│ │(ES/S3)   │  │(S3)   │ │
│  └──────────┘  └──────────┘  └──────────┘  └────────┘ │
└─────────────────────────────────────────────────────────┘

核心模块详解

意图分析模块

接收用户输入后，首先进行意图分类和问题复杂度评估。判断标准包括：

• 问题类型：事实查询 / 对比分析 / 多步推理 / 开放式讨论
• 信息需求：单一来源 / 多来源交叉
• 所需工具：纯检索 / 需要计算 / 需要外部数据

分析结果会传递给计划生成模块，作为制定执行计划的依据。

计划生成模块

基于意图分析结果，生成结构化的执行计划。计划格式如下：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24

{
  "task": "分析 Q3 销售增长最快的产品线并对比竞品",
  "steps": [
    {
      "id": 1,
      "action": "vector_search",
      "params": {"query": "Q3 销售报告 产品线增长", "top_k": 5},
      "depends_on": []
    },
    {
      "id": 2,
      "action": "web_search",
      "params": {"query": "竞品 Q3 市场表现"},
      "depends_on": []
    },
    {
      "id": 3,
      "action": "synthesize",
      "params": {"inputs": [1, 2], "task": "对比分析"},
      "depends_on": [1, 2]
    }
  ],
  "max_iterations": 3
}

执行引擎

按计划调度各工具的调用。支持并行执行无依赖关系的步骤，串行执行有依赖关系的步骤。每一步的执行结果都会被记录，供反思模块评估。

反思评估模块

每一步执行完成后，反思模块会检查：

1. 结果是否完整回答了当前子任务
2. 信息质量是否达标（相关性、准确性、时效性）
3. 是否存在矛盾信息需要进一步验证
4. 是否需要调整后续计划

如果评估不通过，反思模块会触发计划修正，可能添加新的检索步骤或调整策略。

数据流走查

以一个实际场景走查完整数据流：

用户提问：“我们公司去年的客户流失主要集中在哪些行业？原因是什么？”

Step 1 - 意图分析：判定为多步分析问题，需要内部数据检索 + 归因分析。

Step 2 - 计划生成：

• 子任务 A：检索客户流失数据
• 子任务 B：检索流失原因分析
• 子任务 C：综合归因

Step 3 - 执行子任务 A：调用向量检索，查询"客户流失 行业分布"。返回 5 个相关片段。

Step 4 - 反思评估：片段中包含行业分布数据，但有一个行业的名称被截断。决定追加一次 SQL 查询获取完整数据。

Step 5 - 执行补充查询：调用 SQL 工具查询客户流失统计表。获取完整数据。

Step 6 - 执行子任务 B：并行调用向量检索和关键词搜索，分别查询"客户流失原因"和"客户满意度调查结果"。

Step 7 - 执行子任务 C：将所有收集到的信息送入合成模块，进行归因分析。

Step 8 - 最终生成：基于完整的分析结果，生成结构化的回答。

工程落地中的关键挑战

延迟与成本的平衡

Agentic RAG 的多轮交互天然带来更高的延迟和 API 调用成本。在实际部署中需要做好平衡：

分级响应策略：简单问题走快速通道（传统 RAG 流程），复杂问题才启用完整的 Agent 流程。判断依据是意图分析模块的复杂度评分。

缓存机制：对高频查询的中间结果和最终结果做缓存。相似问题命中缓存后直接返回，跳过完整推理流程。

异步执行：对于需要多步推理的复杂问题，可以采用异步模式——先返回一个"正在分析"的状态，后台完成推理后推送结果。

可观测性建设

Agentic RAG 的执行过程比传统 RAG 复杂得多，完善的可观测性至关重要：

全链路追踪：记录每一步的输入输出、耗时、工具调用详情。方便定位问题环节。

决策日志：记录 Agent 的每次决策及理由，便于复盘和优化。

质量监控：对用户反馈（点赞/点踩）与 Agent 执行路径做关联分析，发现低质量回答的模式。

安全与权限控制

当 Agent 可以调用多种工具时，安全边界变得更加重要：

• 工具权限分级：只读工具（检索）和写入工具（数据库操作）设置不同的权限等级
• 查询审计：所有 SQL 查询和 API 调用都需记录，支持事后审计
• 输出过滤：对 Agent 生成的最终回答做敏感信息过滤
• 沙箱执行：代码执行器必须在隔离环境中运行，限制资源使用

实践建议：从传统 RAG 到 Agentic RAG 的渐进升级

对于已经有传统 RAG 系统的团队，不需要一步到位推翻重建。以下是推荐的渐进升级路径：

第一阶段：增强检索质量

在不改变整体架构的前提下，优化检索环节：

• 引入混合检索（向量 + BM25）
• 添加查询改写模块
• 实现检索结果重排序
• 优化文档切片策略

这一阶段投入小、见效快，通常能带来明显的质量提升。

第二阶段：引入简单路由

在传统 RAG 的基础上加一层意图分类，实现查询路由：

• 简单问题 → 传统 RAG 快速通道
• 需要多源信息的问题 → 多次检索 + 结果合并
• 需要计算的问题 → 检索 + 代码执行

这一阶段开始引入"智能决策"的概念，但决策逻辑还比较简单。

第三阶段：全面 Agent 化

引入完整的规划-执行-反思循环：

• 部署 Agent 编排引擎
• 接入完整的工具生态
• 实现动态规划和多步推理
• 建设可观测性体系

这一阶段是真正的 Agentic RAG，但需要较大的工程投入。

技术选型速查表

在实际落地过程中，以下技术选型清单可以作为参考：

面向未来的架构思考

Agentic RAG 仍在快速演进中。几个值得关注的方向：

自进化能力：Agent 能否从历史执行记录中学习，自动优化自己的规划和决策策略？这需要引入强化学习或经验记忆机制。

多 Agent 协作：对于极其复杂的任务，单一 Agent 可能力不从心。多个专业化的 Agent 协作完成任务（如一个负责检索、一个负责分析、一个负责写作）将成为趋势。

端侧推理：随着端侧模型能力增强，部分 Agentic RAG 的推理能力可能下沉到终端设备，降低对云端的依赖。

多模态融合：当前 Agentic RAG 主要处理文本。未来需要支持图像、视频、音频等多模态信息的检索和推理，这将在数据层和工具层带来全新的挑战。

技术的演进从来不是跳跃式的。从静态 RAG 到 Agentic RAG，看似是一大步，实际上是无数个工程细节的积累。每一个查询改写的优化、每一次检索策略的调整、每一层反思机制的加入，都在推动系统向更智能的方向迈进。

构建一个好的 Agentic RAG 系统，不是堆砌最先进的组件，而是在理解业务需求的基础上，找到复杂度与效果的平衡点。有时候，一个简单的查询路由就能解决 80% 的问题；而真正的复杂场景，才需要动用完整的 Agent 能力。

务实、渐进、可度量——这或许是当下构建 Agentic RAG 系统最需要的三个关键词。