Agentic RAG完整指南：原理解析与代码实现

为什么传统RAG已经不够用了？

如果你搭建过RAG系统，一定遇到过这些痛点：模型回答答非所问、检索到一堆看似相关却毫无用处的内容、问知识库有哪些文档时系统直接"当机"、检索不到答案时就"摆烂"而不是换一种方式重试。

RAG（Retrieval-Augmented Generation，检索增强生成）最早由Meta AI在2020年的论文中正式提出，其核心思想是将外部知识库与大语言模型结合，解决模型知识截止日期和幻觉（Hallucination）问题。传统RAG在企业知识问答、智能客服、文档助手等场景中被广泛应用，但其"一次检索、一次生成"的刚性流程在面对复杂查询、多跳推理（Multi-hop Reasoning）和模糊表述时表现出明显的脆弱性。

这些问题的根源在于：传统RAG是一条固定的流水线，检索一次、生成一次、结束。它缺乏灵活性，无法应对检索失败或信息不完整的情况。而Agentic RAG的出现，正是对这一范式的根本性升级。

传统RAG的实现原理

传统RAG可以分为两个核心流程：离线流程和在线流程。

离线流程：文档切片→向量化→存储

离线流程与用户无关，是数据准备阶段：

1. 文档加载：将PDF、Word、TXT等文档加载到内存中
2. 文本切片：由于文档可能有上万字，无法一次性全部给到大模型（受限于上下文窗口长度），需要按固定长度（如256个字符）进行切分，段落之间保留一定重叠（overlap）。文本切片（Chunking）是RAG系统中影响检索质量的关键环节，常见策略包括固定长度切分、按语义段落切分、递归字符切分等。chunk_overlap的设置是为了避免关键信息被截断在两个片段的边界处，通常设置为chunk_size的10%-20%。
3. 向量化：使用Embedding模型将每个段落转换为固定维度的向量。Embedding模型（如OpenAI的text-embedding-ada-002、智源的BGE系列、M3E等）将文本映射到高维向量空间（通常为768或1536维），使得语义相近的文本在向量空间中的余弦距离更近，从而支持基于语义相似度的检索，而非简单的关键词匹配。
4. 存储：将向量存入向量数据库（如ChromaDB、Milvus、Pinecone、Weaviate等），这些数据库针对高维向量的近似最近邻（ANN）搜索进行了专门优化

在线流程：检索→拼接→生成

当用户提出问题后，系统执行以下步骤：

1. Query改写：用户的原始问题可能不适合直接检索（如口语化表述、代词指代不明等），需要进行改写优化，使其更适合向量检索
2. 双路检索：分别使用BM25关键词检索和向量相似度检索，获取两批候选片段。BM25是一种经典的基于词频统计（TF-IDF改进版）的信息检索算法，属于稀疏检索方法，擅长精确匹配关键词和专有名词。向量检索则属于稠密检索，擅长捕捉语义相似性和同义词改写。两者形成互补：BM25解决"精确匹配"问题，向量检索解决"语义理解"问题。
3. 合并与重排序：将两路结果合并后，通过Reranker模型（如Cohere Rerank、BGE-Reranker、bce-reranker等）进行精排，选出最相关的Top-K片段。Reranker与初始检索不同，它会同时考虑Query和Document的交互信息，排序精度更高但计算成本也更大。
4. Prompt拼接：将检索到的片段作为Context注入到提示词模板中
5. 大模型生成：模型根据Context和用户问题生成最终答案

整个过程是单向、固定、一次性的。如果第一轮检索没有找到有用信息，系统无法自动重试或换一种方式检索。

什么是Agentic RAG？

Agentic RAG是对传统RAG的根本性升级。它的核心思想是：把RAG中的各个环节（Query改写、向量检索、关键词搜索、文件读取等）全部封装成可调用的工具（Tool），并赋予大模型自主决策的能力。

这里的"Agentic"一词来源于AI Agent（智能体）的概念——即具备自主感知环境、做出决策并采取行动能力的AI系统。将Agent的自主决策能力引入RAG，就形成了Agentic RAG：模型不再是被动地接收检索结果，而是主动地规划检索策略、评估结果质量、决定是否需要进一步检索。

Agentic RAG与传统RAG的核心区别

维度	传统RAG	Agentic RAG
流程	固定单向	循环迭代
检索次数	一次	多次，动态调整
决策主体	预设规则	大模型自主判断
失败处理	直接返回"不知道"	改写Query重试
复杂问题	难以处理多跳推理	可分解为多步子任务
工具使用	固定流水线	按需动态选择

Agentic RAG的三大核心能力

Agentic RAG依赖模型具备以下能力：

1. 规划能力（Planning）：通过Chain-of-Thought（CoT，思维链）推理，规划解决问题的步骤。CoT是由Google Brain团队在2022年提出的提示技术，通过引导模型逐步推理而非直接给出答案，显著提升了模型在复杂推理任务上的表现。在Agentic RAG中，CoT使模型能够分析用户问题的复杂度、判断当前信息是否充分、规划下一步应该调用哪个工具，这种规划能力是Agent从"被动执行"走向"主动决策"的关键。

2. 工具调用能力（Tool Use）：能够识别并调用合适的工具获取信息。现代大模型（如GPT-4、Claude、Qwen等）通过Function Calling机制，可以在生成过程中输出结构化的工具调用请求（包含工具名称和参数），由外部系统执行后将结果返回给模型继续推理。

3. 多步迭代能力（ReAct Loop）：在最终回答前，可以进行多轮工具调用，从思考→行动→观察→再思考，形成闭环。ReAct（Reasoning + Acting）是由Yao等人在2022年提出的Agent推理框架，其核心是让模型交替进行推理（Thought）和行动（Action），并根据环境反馈（Observation）调整下一步策略。这种循环使得Agent能够处理需要多步推理的复杂任务，而不是一步到位地给出可能错误的答案。

ChatPDF/ChatBoss的Agentic RAG实现逻辑拆解

以开源产品ChatBoss为例，它的Agentic RAG实现逻辑非常值得借鉴。

决策分流机制

当用户问题进入系统后，首先判断模型是否支持工具调用（Function Calling）：

• 不支持工具调用：通过Prompt判断问题是否需要检索。不需要则直接回复；需要则进行语义搜索后生成答案。这种方式适用于较老的模型或不支持Function Calling的开源模型。
• 支持工具调用：将所有工具注册到模型中，由模型自主决策调用哪些工具

这种方式比在Prompt中让模型忽略无关Context更优，因为它用两个模型做决策（一个判断是否需要检索，一个生成答案），理论上效果更好。这也体现了"路由"（Router）的设计思想——在系统入口处进行意图分类，将不同类型的请求导向不同的处理流程。

四大核心工具详解

1. Search Query：基础的语义检索工具，执行向量相似度匹配。模型可以自主决定搜索词，而不是简单地使用用户原始问题，这本身就实现了隐式的Query改写。
2. List Files：列出知识库中的文件清单，解决"你有哪些文档"这类传统RAG无法回答的问题。传统RAG只能检索文档内容，对于知识库本身的元信息（有哪些文件、文件结构等）完全无能为力。
3. Read File：根据文档ID精确读取特定片段，当信息不完整时可主动读取前后片段补充上下文。这解决了切片导致的信息碎片化问题——当一个答案跨越多个chunk时，模型可以主动获取更多上下文。
4. Gather File Meta：获取文件的元数据信息（如文件名、创建时间、页数、作者等），帮助模型在多文档场景中做出更精准的检索决策。

实际案例对比：传统RAG vs Agentic RAG

传统RAG：用户查询 → 向量检索 → 检索结果 → 生成答案（一步到位）

Agentic RAG：

• 第一轮搜索：使用原始Query检索，发现命中率很低（相似度分数低于阈值）
• 观察与改写：模型判断检索结果质量不佳，分析原因可能是Query表述不当，决定改写查询词
• 第二轮搜索：用改写后的Query重新检索，命中相关片段
• 第三轮补充：发现检索到的片段信息不完整，调用Read File获取相关文档的更多上下文
• 最终生成：基于整合好的信息生成完整答案

这个过程可能涉及3-5次工具调用，虽然延迟增加，但答案质量显著提升。这就是"用时间换智能"的核心理念。

Agentic RAG代码实现详解

传统RAG实现（基于LangChain）

离线部分的核心步骤：

# 1. 加载文档
loader = TextLoader(\"your_file.txt\")
# 2. 文本切分
splitter = RecursiveCharacterTextSplitter(chunk_size=256, chunk_overlap=50)
# 3. 向量化 + 存储到ChromaDB
Chroma.from_documents(documents=splits, embedding=embedding_model, persist_directory=\"./db\")

其中RecursiveCharacterTextSplitter是LangChain提供的递归字符切分器，它会优先按段落、句子等自然边界切分，只有在无法满足chunk_size限制时才按字符强制切断，这比简单的固定长度切分能更好地保持语义完整性。

在线部分：加载向量数据库 → 相似度检索（Top-K） → 拼接Prompt → 大模型生成。

实测中，当检索到的片段不包含答案信息时，模型只能回答"不知道"——这正是传统RAG的局限。

Agentic RAG实现（基于LangGraph）

LangGraph是LangChain团队推出的用于构建有状态、多步骤AI Agent的框架。与LangChain的线性Chain不同，LangGraph基于有向图（DAG）的概念，允许定义节点（处理逻辑）和边（流转条件），支持循环、条件分支和状态持久化。这使得它天然适合实现ReAct这种需要循环迭代的Agent模式。

核心使用LangGraph的create_react_agent：

# 定义工具集
tools = [search_query, list_files, read_file, reason_file]

# 创建React Agent
agent = create_react_agent(
    llm=model,           # 大模型
    tools=tools,         # 工具列表
    system_prompt=prompt  # 系统提示词
)

# 运行
result = agent.invoke({\"input\": user_query})

create_react_agent内部实现了完整的ReAct循环：模型生成工具调用请求→LangGraph执行对应工具→将工具返回结果追加到对话历史→模型根据新信息决定是否继续调用工具或生成最终答案。这个循环会持续进行，直到模型认为信息充分并输出最终回答，或达到预设的最大迭代次数。

代码看上去简洁，但它赋予了模型自主决策、动态调整的能力。模型会在ReAct循环中不断思考→调用工具→观察结果，直到获得足够信息后才生成最终答案。

总结与思考

传统RAG是"检索即回答"的线性流程，简单直接但缺乏应变能力。Agentic RAG则将检索能力工具化，让大模型成为决策中枢，能够规划、调用、反思和迭代。

关键启示：

• 工具赋予能力，智能在于选择——真正的Agentic RAG始于检索，成于决策。工具本身是静态的，模型的决策能力才是系统智能的来源。
• 核心逻辑并不复杂，国内很多"套壳"应用本质上就是这套实现。理解了ReAct + Tool Use的范式，就掌握了当前大部分AI应用的技术内核。
• 重点工作仍在离线流程：如何切分文档、选择Embedding模型、设计检索策略，这些决定了Context的质量。即使有了Agentic能力，如果底层检索质量差，模型也难以"巧妇难为无米之炊"。
• Agentic RAG用时间换智能，通过多轮迭代获得更准确的答案。但这也意味着更高的延迟和Token消耗，在生产环境中需要在响应速度和答案质量之间做权衡。
• 未来趋势：Agentic RAG正在向多Agent协作（Multi-Agent）、自适应检索策略、知识图谱融合等方向演进，与传统RAG的边界将越来越模糊。

对于大模型工程师而言，掌握Agentic RAG已经从"加分项"变成了"必备技能"。它不仅是技术的升级，更是思维方式的转变——从固定流程到智能决策。