Agentic RAG 架构设计：从静态检索到动态推理的演进路径

Fri, 26 Jun 2026 14:00:00 +0800

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

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

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

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

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

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

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

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

基本流程回顾

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

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

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

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

三个致命短板

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

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

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

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

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

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

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

维度	传统 RAG	理想状态
检索次数	一次	按需多次
检索策略	固定 Top-K	动态调整
推理能力	无	多步推理
工具使用	仅向量检索	多种工具
错误修正	无	自我反思+重试
上下文管理	简单拼接	智能筛选

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

核心理念

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

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

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

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

架构分层

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

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

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

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

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

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

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

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

对比维度	传统 RAG	Agentic RAG
架构模式	线性管道	有向图 + 循环
决策方式	预设规则	模型自主决策
检索策略	单一向量相似度	混合检索 + 动态路由
查询改写	无或简单改写	多策略查询扩展
多步推理	不支持	支持链式推理
工具生态	仅向量库	多工具编排
上下文窗口管理	被动填充	主动筛选压缩
错误处理	忽略	自动重试 + 降级
响应延迟	低（单次调用）	较高（多轮迭代）
工程复杂度	低	高
适用场景	简单问答	复杂分析

一个直观的类比

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

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

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

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

任务分解

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

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

Agent 的分析过程可能是：

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

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

执行图构建

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

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

动态调整

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

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

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

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

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

思维链在 RAG 中的应用

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

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

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

推理深度控制

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

实践中常见的策略包括：

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

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

工具生态设计

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

信息检索类：

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

信息处理类：

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

信息生成类：

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

工具选择机制

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

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

一个工具描述的示例：

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

工具编排模式

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

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

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

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

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

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

主流向量数据库对比

数据库	部署方式	索引算法	最大数据量	混合检索	适用场景
Milvus	分布式/单机	HNSW/IVF/DiskANN	十亿级	支持	大规模生产环境
Pinecone	全托管云服务	自研	十亿级	支持	快速上线/免运维
Weaviate	单机/集群	HNSW	亿级	原生支持	多模态检索
Qdrant	单机/分布式	HNSW	亿级	支持	Rust 高性能场景
Chroma	嵌入式/单机	HNSW	百万级	基础支持	原型验证/小规模
pgvector	PostgreSQL 扩展	IVFFlat/HNSW	千万级	SQL 联合	已有 PG 的团队

选型决策树

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

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

混合检索：Agentic RAG 的标配

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

混合检索的典型策略：

并行检索：同一查询同时走向量检索和 BM25 关键词检索
结果融合：使用 RRF（Reciprocal Rank Fusion）等算法合并两路结果
重排序：用 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 系统架构设计。

整体架构图

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

核心模块详解

意图分析模块

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

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

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

计划生成模块

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

{
  "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
}

执行引擎

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

反思评估模块

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

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

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

数据流走查

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

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

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，但需要较大的工程投入。

技术选型速查表

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

组件	推荐方案	备选方案	选型理由
Agent 框架	LangGraph	AutoGen / CrewAI	图结构编排灵活，社区活跃
向量数据库	Milvus	Qdrant / pgvector	生产级稳定性，支持大规模
Embedding 模型	BGE-M3	text-embedding-3	中文效果优秀，多语言支持
重排序模型	BGE-Reranker	Cohere Rerank	开源可自部署，延迟可控
关键词检索	Elasticsearch	Meilisearch	生态成熟，混合检索能力强
缓存层	Redis	本地缓存	支持语义缓存，TTL 管理
可观测性	LangSmith	Phoenix / 自研	全链路追踪，可视化分析
大模型	GPT-4o / Claude 3.5	Qwen-2.5 / DeepSeek	推理能力强，工具调用成熟

面向未来的架构思考

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

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

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

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

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

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

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

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

AI架构 on 文艺技术笔记