Agentic RAG实战教程：用LangGraph实现智能检索增强生成

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

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

这些问题的根源在于传统RAG的固定流程——检索一次、生成一次、结束。2025年，Agentic RAG已经成为大模型工程师的必备技能，它让RAG系统从"一条直线走到底"进化为"可循环、能思考的闭环系统"。

本文将从传统RAG的实现原理讲起，逐步揭示它如何进化为Agentic RAG，并通过LangChain和LangGraph的代码演示完整的实现过程。

Agentic RAG流程概览

传统RAG的实现原理

离线链路：文档切片→向量化→存储

传统RAG可以分为两个核心部分。第一部分是离线链路，与用户无关，主要完成数据准备工作：

文档加载：将PDF、Word、TXT等文档加载到内存中
文本切片：由于文档内容可能有数万字，无法一次性全部输入大模型，需要将文档切分为固定长度的段落（如256个字符），段落之间保持一定重叠
向量化（Embedding）：使用Embedding模型将每个段落转换为固定维度的向量
向量存储：将向量存入向量数据库（如ChromaDB、Milvus）

文本切片（Chunking）是RAG系统中最容易被低估却影响巨大的环节。切片策略直接决定了检索质量：切片太大，向量表示会被稀释，语义模糊；切片太小，上下文信息丢失，模型无法理解片段含义。RecursiveCharacterTextSplitter是LangChain中最常用的切分器，它会按照段落、句子、字符的优先级递归切分，尽量保持语义完整性。而Embedding模型的选择同样关键——不同模型在不同语言、不同领域的表现差异显著，中文场景下BGE、M3E等国产模型往往优于通用的OpenAI Embedding。

离线链路示意图

在线链路：检索→拼接Prompt→生成回答

第二部分是在线链路，处理用户的实时查询：

Query改写：用户的问题不一定适合直接检索，需要进行改写优化
双路检索：先用BM25进行关键词检索，再用向量相似度匹配，两路结果合并
重排序（Rerank）：对合并后的片段进行重排序，选出最相关的Top-K结果
Prompt拼接：将检索结果注入到提示词模板的Context中
大模型生成：基于完整Prompt生成最终回答

关于双路检索，BM25是一种经典的基于词频统计的检索算法，属于稀疏检索（Sparse Retrieval），它擅长精确匹配关键词，对专有名词、型号编码等精确查询效果极佳。向量检索则属于稠密检索（Dense Retrieval），通过语义相似度匹配，能理解同义词和语义近似表达。两者各有盲区：BM25无法理解"汽车"和"轿车"的语义等价，向量检索则可能在精确术语匹配上不如关键词搜索。双路检索（Hybrid Search）将两者结合，通常使用RRF（Reciprocal Rank Fusion）算法融合排序结果，在实际生产环境中能显著提升召回率。

重排序（Rerank）则是提升精度的关键环节。初始检索阶段（无论BM25还是向量检索）本质上是对query和document分别编码后计算相似度的"双塔模型"，效率高但精度有限。Rerank模型则采用"交叉编码器"（Cross-Encoder）架构，将query和document拼接后一起输入模型，能捕捉更细粒度的语义交互。代表性的Rerank模型包括Cohere Rerank、BGE-Reranker、Jina Reranker等。虽然Rerank的计算成本更高，但由于它只需要对初始检索返回的少量候选文档（通常20-50条）进行重排，整体延迟可控，却能将最终Top-K结果的相关性提升30%-50%。

整个过程是单向、固定、一次性的。如果第一轮检索没有找到想要的内容，传统RAG无法重新检索或换一种方式获取信息——这正是它最大的短板。

Agentic RAG：从固定流程到智能决策

核心理念：将检索能力工具化

Agentic RAG是对整个RAG流程的根本性升级。它将RAG中的各个环节——Query改写、向量检索、关键词搜索等——全部封装为可调用的工具（Tool），并允许大模型在生成答案之前进行自主决策、多轮调用以及动态调整。

简单来说，Agentic RAG不再是一条直线走到底，而是一个从思考→调用工具→观察结果→再思考→再行动的闭环，直到生成满意的最终答案。这个闭环正是基于ReAct（Reasoning + Acting）框架实现的。ReAct由Yao等人在2022年提出，是Agentic RAG的理论基石。传统的Chain of Thought（CoT）只让模型进行推理但不与外部环境交互，而ReAct将推理和行动交织进行：模型先产生一个思考（Thought），基于思考选择一个行动（Action），执行后获得观察结果（Observation），再基于观察继续思考。这个循环持续进行直到模型认为已获得足够信息。ReAct的核心优势在于它让模型的推理过程可追溯、可调试——每一步的思考和行动都有明确记录，出现问题时可以精确定位是推理错误还是工具调用错误。

Agentic RAG实现逻辑

Agentic RAG的三大核心能力

Agentic RAG的实现依赖模型具备以下三类能力：

规划能力（Planning）：体现在CoT（Chain of Thought）推理过程中，模型能规划执行步骤
工具调用能力（Tool Use）：模型能识别并调用合适的工具，支持多Agent协作
多步迭代能力（Multi-step Reasoning）：在回答最终答案之前，能够进行多步工具调用和结果验证

其中，工具调用能力是Agentic RAG的技术前提。OpenAI在2023年6月首次引入Function Calling功能，随后各大模型厂商纷纷跟进。其核心机制是：在API请求中附带工具的JSON Schema描述（包括函数名、参数类型、功能说明），模型在生成过程中如果判断需要调用工具，会输出一个结构化的JSON而非自然语言文本，应用层解析这个JSON后执行对应函数，再将结果回传给模型继续生成。并非所有模型都支持工具调用——这也是后文ChatBoss设计中需要先判断模型是否支持工具调用的原因。对于不支持的模型，通常需要通过精心设计的Prompt来模拟工具调用行为，但稳定性和准确率会明显下降。

Agentic RAG与传统RAG的关键区别

维度	传统RAG	Agentic RAG
流程	固定单向	动态循环
检索	一次检索	多轮迭代检索
决策	无决策能力	模型自主决策
失败处理	直接返回"不知道"	改写Query重试
上下文补充	不支持	主动读取前后片段

开源实践：ChatBoss的Agentic RAG实现

整体架构设计

以开源项目ChatBoss为例，它的Agentic RAG实现逻辑非常清晰：用时间换取模型的智能。

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

不支持工具调用：通过Prompt判断问题是否需要检索。不需要则直接回复；需要则进行语义搜索后生成答案
支持工具调用：将所有工具注册到模型中，由模型自主决策调用哪些工具

这种设计比在Prompt中让模型忽略无关Context更优，因为它用两个模型做决策，理论上效果更好。

ChatBoss实现对比

四个核心工具定义

ChatBoss设计了四个特色工具，覆盖了RAG场景中的常见需求：

Search Query：基础的语义检索工具，执行向量相似度匹配
List Files：列出知识库中的文件清单，解决"你有哪些文档"这类传统RAG无法回答的问题
Read File：根据文档ID精确读取特定片段，当信息不完整时主动读取前后片段补充上下文
Gather File Meta：读取文件元数据信息，如文件大小、创建时间等

这些工具的组合使得系统不仅能做基础检索，还能回答文件列表查询、精确读取指定内容、主动补充上下文——这些都是传统RAG做不到的。

Agentic RAG代码实现详解

传统RAG实现（基于LangChain）

离线部分的核心代码逻辑：

# 1. 加载文档
loader = TextLoader(\"your_file.txt\")
docs = loader.load()

# 2. 文本切分
text_splitter = RecursiveCharacterTextSplitter(
    chunk_size=256,
    chunk_overlap=50
)
chunks = text_splitter.split_documents(docs)

# 3. 向量化 + 存储到ChromaDB
embedding = OpenAIEmbeddings(model=\"qwen-embedding-0.6b\")
vectorstore = Chroma.from_documents(
    documents=chunks,
    embedding=embedding,
    persist_directory=\"./chroma_db\"
)

在线部分则是加载向量库、执行相似度检索、拼接Prompt后调用大模型生成答案。实测中，如果检索到的片段不包含答案信息，模型只能回答"不知道"——这就是传统RAG的天花板。

Agentic RAG实现（基于LangGraph）

Agentic RAG的实现借助LangGraph中的create_react_agent。LangGraph是LangChain团队推出的用于构建有状态、多步骤AI Agent的框架，它基于图（Graph）的抽象来定义Agent的工作流。与LangChain的链式（Chain）调用不同，LangGraph允许定义节点（Node）和边（Edge），支持条件分支、循环和状态持久化，天然适合实现Agentic RAG这类需要多轮迭代的场景。LangGraph的状态管理机制使得Agent可以在多轮工具调用之间保持上下文，记住之前检索过什么、哪些路径已经尝试过，从而避免重复检索。在生产环境中，LangGraph还支持检查点（Checkpoint）机制，可以在任意节点暂停和恢复执行，这对于需要人工审核的场景尤为重要。

代码结构如下：

from langgraph.prebuilt import create_react_agent

# 1. 定义工具集
tools = [search_query, list_files, read_file, gather_file_meta]

# 2. 编写系统提示词（需严格限制输出格式）
system_prompt = \"你是一个Agentic RAG助手，请按以下步骤...\"

# 3. 创建React Agent
agent = create_react_agent(
    llm=chat_model,
    tools=tools,
    system_message=system_prompt
)

# 4. 运行Agent
result = agent.invoke({\"messages\": [user_query]})

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

注意事项：系统提示词中必须对模型的回复格式进行严格限制，否则模型可能会去掉引号或括号，导致工具调用的JSON解析失败。

总结：从检索到决策的进化

传统RAG是固定流程：文档切片→向量化→存储→检索→拼接Prompt→生成。简单直接，但缺乏灵活性，无法应对检索失败或信息不完整的情况。

Agentic RAG的核心是将检索、文件读取等能力封装为工具，赋予大模型自主决策的权利。模型可以根据任务需求动态规划、调用工具、观察结果并进行多轮迭代，真正体现了智能体的行为模式。

你可能没注意到，很多国内的"套壳"应用，其核心逻辑其实就是这套Agentic RAG的实现方式。掌握了这个核心模式，你就能理解大部分RAG产品背后的技术本质。

工具赋予能力，智能在于选择。真正的Agentic RAG，始于检索，成于决策。