LangChain新版本实战路线：从RAG、Agent到MCP与LangGraph

LangChainRAGReAct
于 2026-08-30 04:00:51 修改
·本内容遵循CC 4.0 BY-SA版权协议

如果你最近打开 LangChain 官方文档，再对照网上那些两三年以前的教程，很可能会有一种“我是不是学了一个假框架”的错觉。以前一个 LLMChain 就能跑通的任务，现在打开 IDE 全是 deprecated 警告；以前 initialize_agent 一行代码就能生成 Agent，现在官方示例却频繁出现 LangGraph 的状态图。于是社区里出现了两种声音：一种说 LangChain 学了就废，另一种说它是 LLM 应用开发绕不开的抽象层。

我的判断是：LangChain 的价值从来不在“Chain”本身，而在于它把 LLM 应用的共性能力标准化了——模型接入、提示词管理、工具调用、记忆、检索、Agent 编排。理解这一点，你才会明白为什么 RAG、ReAct、MCP、LangGraph 这些名词会反复出现在同一类教程里。它们不是相互独立的新概念，而是同一个问题在不同层面的解法：如何让大模型在真实业务里稳定可靠地工作。

这篇文章不是官方文档的翻译，而是一条从“照着跑通示例”到“理解企业场景怎么选型”的完整路线。我们会从一个最小的大模型调用开始，逐步完成 RAG 知识库问答、ReAct Agent 实战、MCP 工具接入、MapReduce 长文档处理，最后落地到企业项目真正需要关心的工程问题。你可以把它当作一份能跟着敲的教程，也可以当作一次框架认知的梳理。

1. 为什么还要学 LangChain：框架的价值与争议

很多初学者会问：现在直接调 OpenAI SDK 不就行了吗？为什么要多套一层 LangChain？

这个问题的答案，取决于你要做的是“调用模型”还是“构建应用”。如果只是写一个脚本让模型回复一句话，直接调 SDK 完全够用。但一旦你开始做知识库问答、多工具调用、长流程任务编排，代码量会快速膨胀。你要自己处理文档加载、文本切分、向量存储、提示词组装、工具协议、上下文管理、失败重试，这些工作跟“调用大模型”本身没有关系，但又绕不过去。

LangChain 做的就是把这一层公共能力沉淀成标准接口。模型可以换，向量库可以换，工具可以换，但上层的编排逻辑不需要大改。这也是它在 2023 年到 2024 年快速流行、又在 2025 年被频繁讨论“是否过时”的原因。

坦白说，LangChain 的 API 变动确实剧烈。0.1 时代的 LLMChain、AgentExecutor，到 0.3 时代大力推广 LCEL 和 LangGraph，很多旧代码跑不起来。但这并不意味着框架不值得学。更合理的判断是：新版本的演进方向，恰好代表了 LLM 应用开发的趋势——从“写死链路”走向“动态规划”。你在旧教程里看到的大量 Chain 组合，今天更多被 Agent 和状态图取代。看懂这种演进，比背熟某个 API 更重要。

所以本文写给三类读者：

  • 刚入门 LLM 应用开发，想系统了解 LangChain 核心模块的新手；
  • 正在做 RAG 知识库或 Agent 项目，需要避开常见坑的开发者；
  • 技术选型阶段，想判断 LangChain 和 LangGraph、MCP 到底什么关系的架构师。

如果你已经熟练使用 LangGraph 和 LangSmith，本文的前半部分可以当作查漏补缺，第 6 章之后的工程实践部分仍然值得一看。

2. LangChain 核心概念与新版体系

在学习代码之前，先把 LangChain 的核心抽象讲清楚。它不是一个大而全的“AI 框架”，而是一组面向 LLM 应用的工具集合。在最新版本里，这几个模块最常被用到。

2.1 模型层：ChatModel 与 Message

现在的 LangChain 统一使用 ChatModel 接口，不再区分旧版的 LLM 和 ChatLLM。它接收的是 Message 列表，而不是纯字符串。常见的消息类型包括系统消息、人类消息和 AI 消息，这让多轮对话和角色设定变得非常自然。

很多旧教程里 llm.predict("你好") 的写法已经不建议使用，新版更推荐 llm.invoke([...]) 或直接配合 LCEL 使用。

2.2 LCEL：LangChain 表达式语言

LCEL 是 LangChain 在 0.2 之后大力推行的语法，用管道符 | 把组件串联起来。它的核心价值是让代码从“过程式”变成“声明式”，并且天然支持流式输出和异步调用。

举个例子，一个最简单的“提示词 -> 模型 -> 输出解析”流程，在 LCEL 里只需要三行代码，这在后续的 RAG 和 Agent 示例中会频繁出现。

2.3 工具调用：Tool 与大模型 Function Calling

工具调用是 LangChain Agent 的基础。LangChain 提供了统一的 tool 装饰器，可以把任意 Python 函数封装成大模型可以调用的工具。函数名、函数描述、参数签名会自动成为模型的工具描述。

PYTHON
from langchain_core.tools import tool
 
@tool
def multiply(a: int, b: int) -> int:
"""将两个整数相乘，用于数学计算。"""
return a * b

模型本身不会直接执行这个函数，它只是在对话中输出一个“需要调用该工具”的结构化请求，真正执行仍然在本地完成。这种“模型负责决策，代码负责执行”的分工，是整个 Agent 体系的核心设计。

2.4 Agent 与 ReAct 范式

Agent 可以理解为一个“会自己决定下一步做什么”的链。它不再是一套写死的流程，而是循环执行：思考当前问题、决定调用哪个工具、观察工具输出、继续思考，直到得到最终答案。

ReAct 是 Reasoning + Acting 的缩写，它和前端框架 React 没有任何关系。ReAct 的核心思想是让模型在每一轮都输出“思考过程”和“具体行动”，然后通过执行环境得到观察结果，再进入下一轮。这种“一步步来”的模式可以显著提升大模型在复杂任务上的推理可靠度。

2.5 记忆与检索：Memory 和 RAG

Memory 解决的是多轮对话的上下文问题，而 RAG（Retrieval-Augmented Generation，检索增强生成）解决的是“模型不知道私有知识”的问题。RAG 的思路是：把文档切块、向量化、存入向量数据库，用户提问时先检索相关片段，再把片段拼进提示词，让模型基于片段回答。

2.6 LangGraph 与 AgentExecutor 的关系

这是最容易混淆的地方。新版 LangChain 官方推荐用 LangGraph 构建 Agent，而不是早期版本的 AgentExecutor。LangGraph 把 Agent 流程建模为一张状态图，节点是“调用模型”“调用工具”“路由判定”，边是状态流转，这让流程可控性大幅提升。

两者对比可以这样理解：

维度 AgentExecutor LangGraph
流程模型 写死的循环 显示状态图
可控性 较弱，难以插入人工节点 强，可定义暂停、回退、并行
调试体验 靠日志 可视化状态与轨迹
适用场景 快速验证原型 企业级复杂流程
学习成本 低 中高

实际项目里，快速 Demo 用 AgentExecutor 没有问题，但进入生产环境后，状态可控、可观测的 LangGraph 才是更好的选择。

老版本中的 LLMChain、SimpleSequentialChain 等概念在最新版本中已经不再是官方主推，但在大量存量代码和旧教程中仍然存在。如果你维护老项目，需要知道它们；如果你从零开始，建议直接把重心放到 LCEL + LangGraph 上。

3. 环境准备与最小示例

在写代码之前，先准备好运行环境。本文假设你使用 Python 3.10 以上版本，具体版本以你的项目实际为准。为了避免包版本冲突，建议在虚拟环境里操作。

BASH
python -m venv venv
source venv/bin/activate # Windows 下使用 venv\Scripts\activate
pip install --upgrade pip

然后安装核心依赖：

BASH
pip install langchain langchain-openai langchain-community langchain-text-splitters langchain-chroma

如果你的项目还要用 MCP 协议和 LangGraph，可以一并安装：

BASH
pip install langgraph mcp langchain-mcp-adapters

这里有一个很重要的提醒：当前版本的 LangChain 包拆分很细，langchain 主包主要负责编排和链逻辑，模型提供商都有自己的独立包，比如 langchain-openai、langchain-anthropic、langchain-ollama。不要在代码里直接写 from langchain.llms import OpenAI，这种旧写法在新版本里已经废弃。

如果你使用 OpenAI 兼容接口的本地模型，比如 Ollama 或 vLLM 部署的 Qwen 系列，只需要设置 base_url 指向本地服务地址即可。下面是最小示例：

PYTHON
# demo/01_basic_chat.py
from langchain_openai import ChatOpenAI
 
# 使用 OpenAI 兼容接口。如果调用官方服务，只需配置 OPENAI_API_KEY；
# 如果调用本地模型，这里替换为本地服务地址。
llm = ChatOpenAI(
model="gpt-4o-mini",
temperature=0,
base_url="https://api.openai.com/v1", # 本地模型时改为 http://localhost:8000/v1
)
 
resp = llm.invoke("用一句话解释什么是 RAG")
print(resp.content)

运行后如果一切正常，你会看到一句关于 RAG 的解释。resp.content 是模型回复的文本内容，resp.response_metadata 里可以看到 token 消耗等元数据。

这里要特别提醒 Windows 用户：很多开发者在安装 langchain-chroma 时遇到编译错误，根源往往是本地缺少 C++ 编译环境。更简单的做法是优先用 pip 安装预编译版本，如果还是报错，检查 Python 版本是否过新或过旧，也可以临时换用内存向量存储 langchain_core.vectorstores.InMemoryVectorStore 跑通流程。

运行成功之后，我们就有了第一个可运行的 LangChain 程序。接下来把复杂度往上加一层，做一个完整的 RAG 知识库问答系统。

4. 从零构建一个 RAG 知识库问答系统

RAG 是企业落地 LLM 应用最常用的模式。它解决的问题很清楚：大模型没有你的内部文档、产品手册、售后记录，直接问它会“一本正经地胡说八道”。RAG 的做法是提前把文档内容向量化，用户提问时先检索最相关的片段，再让模型基于这些片段生成答案。

整个流程可以拆成五个环节：文档加载、文本切分、向量化存储、检索、生成回答。我们逐个来看。

4.1 文档加载与文本切分

LangChain 提供了非常多的文档加载器。下面以文本文件为例，如果你想加载 PDF、Markdown、HTML，只需要换掉 TextLoader，比如 PyPDFLoader、UnstructuredMarkdownLoader。

真正的关键步骤是切分。直接按字符数硬切会破坏语义，比如把一句话从中间切开；按段落切分又可能导致单个片段太长，超出模型上下文窗口。更推荐的做法是用递归字符切分器 RecursiveCharacterTextSplitter，它会在遇到换行、句号、空格时优先断句，尽可能让每个片段保持语义完整。

PYTHON
# demo/02_rag.py
from langchain_community.document_loaders import TextLoader
from langchain_text_splitters import RecursiveCharacterTextSplitter
 
# 1. 加载文档
loader = TextLoader("docs/knowledge.txt", encoding="utf-8")
documents = loader.load()
 
# 2. 切分成 chunk
text_splitter = RecursiveCharacterTextSplitter(
chunk_size=500, # 每个片段最大字符数
chunk_overlap=50, # 相邻片段重叠，避免关键信息被切断
separators=["\n\n", "\n", "。", "！", "？", " "],
)
chunks = text_splitter.split_documents(documents)
print(f"切分后共 {len(chunks)} 个片段")

chunk_size 和 chunk_overlap 是 RAG 项目里最值得调的两个参数。chunk_size 太小，检索到的信息可能不完整；太大，会增加向量化成本和模型上下文压力。一般来说，中文场景下 300 到 800 字是比较常见的范围，具体取决于你的文档类型和问答粒度。如果文档是产品规格书，可能需要更小的块方便精确检索；如果是长篇技术文档，可以适当放大。

4.2 向量化与向量数据库

切分完成后，需要把每个片段转成向量。Embedding 模型选择很关键：如果你用的 LLM 是 OpenAI 或国产闭源模型，通常搭配该厂商提供的 Embedding 接口；如果做本地私有化部署，可以用 BAAI/bge-m3、m3e-base 等开源模型。

下面代码使用 OpenAI 兼容的 Embedding 接口，并写入 Chroma 向量库。from_documents 方法会把文档切片、向量化并持久化到本地目录。

PYTHON
# demo/03_embed_and_store.py
from langchain_openai import OpenAIEmbeddings
from langchain_chroma import Chroma
 
# 3. 向量化并入库
embedding = OpenAIEmbeddings(model="text-embedding-3-small")
 
vectorstore = Chroma.from_documents(
documents=chunks,
embedding=embedding,
persist_directory="./chroma_db", # 向量库持久化目录
)
 
print(f"向量库已创建，路径: ./chroma_db")

第一次运行会耗时较长，因为要逐条调用 Embedding 接口。之后再次运行，如果目录已存在，可以直接用 Chroma(persist_directory="./chroma_db", embedding_function=embedding) 加载已有数据，不需要重新切分向量化。

4.3 构建检索问答链

向量库建好后，剩下的工作就是“检索”和“生成”。LangChain 提供了两个核心方法：create_stuff_documents_chain 负责把检索到的文档内容“塞”进提示词让模型回答；create_retrieval_chain 负责把检索器和上面的文档链串起来。

注意这里的 retriever 就是向量库的检索接口，你可以通过 vectorstore.as_retriever(search_kwargs={"k": 4}) 控制每次检索返回的片段数量。k 值越大，给模型的信息越丰富，但也可能掺入无关内容，影响回答准确度。

PYTHON
# demo/04_rag_chain.py
from langchain_openai import ChatOpenAI
from langchain_chroma import Chroma
from langchain_core.prompts import ChatPromptTemplate
from langchain.chains import create_retrieval_chain
from langchain.chains.combine_documents import create_stuff_documents_chain
 
# 加载已有向量库
embedding = OpenAIEmbeddings(model="text-embedding-3-small")
vectorstore = Chroma(persist_directory="./chroma_db", embedding_function=embedding)
retriever = vectorstore.as_retriever(search_kwargs={"k": 4})
 
llm = ChatOpenAI(model="gpt-4o-mini", temperature=0)
 
# 给模型设定回答规则
prompt = ChatPromptTemplate.from_messages([
("system", "你是一个严谨的文档助手。请只根据检索到的资料回答问题，"
"不要编造资料中没有的内容。如果资料不足以回答，请明确说明。"),
("human", "资料：\n{context}\n\n问题：{input}"),
])
 
combine_docs_chain = create_stuff_documents_chain(llm, prompt)
rag_chain = create_retrieval_chain(retriever, combine_docs_chain)
 
# 提问
result = rag_chain.invoke({"input": "公司产品的退货政策是什么？"})
print(result["answer"])

这里有一个新手容易误解的地方：create_stuff_documents_chain 默认会把所有检索到的文档“一股脑”塞进 context 变量。如果你的文档很多，检索回来的片段很多，提示词会变得很长。入门阶段可以先不纠结，但到生产环境，建议对检索结果做重排（Rerank）或者用 MapReduce 方式分段处理，避免上下文超限。

4.4 运行结果与验证

运行上面的脚本后，预期输出是一段基于文档内容的回答。如果回答里出现了明显与文档无关的信息，优先检查两处：

  • retriever 检索回来的片段是不是正确的？可以在 invoke 之前调用 retriever.invoke("退货政策是什么") 打印片段内容进行验证。
  • chunk_size 是否太小，导致关键信息被切碎了？可以尝试调大 chunk_size 并增大 chunk_overlap。

这一步跑通之后，你已经拥有了一个最简可用 RAG 系统。从企业角度看，接下来要考虑的是：文档更新怎么同步、向量库选择什么、权限怎么隔离。这些放到第 8 章再展开。

5. ReAct Agent 与工具调用实战

如果说 RAG 解决的是“让模型知道更多信息”，Agent 解决的就是“让模型能做更多事情”。当你需要模型根据用户请求去查数据库、算数学题、调内部 API 时，就需要 Agent 体系登场。

5.1 ReAct 循环到底在循环什么

先用一个比喻理解 ReAct。想象你让一个实习生帮你订会议室，他不会一次性把所有事情做完，而是先看你给定的信息，查询会议室系统，发现时间冲突，再换一间，最后确认，每一步都基于上一步的结果。

ReAct Agent 就是这样的实习生。模型在每一轮都会输出：

  1. 思考：基于当前问题，我该做什么？
  2. 行动：我应该调用哪个工具，参数是什么？
  3. 观察：工具返回了什么结果？

然后进入下一轮，直到模型认为自己得到了最终答案。LangChain 的 AgentExecutor 负责执行这个循环，你只需要提供工具清单和系统提示词。

5.2 定义工具并构建 ReAct Agent

下面我们构建一个能进行数学计算的 Agent。为了让示例更有说服力，我们故意不告诉模型计算公式，让它通过工具去计算。

PYTHON
# demo/05_react_agent.py
from langchain.agents import AgentExecutor, create_react_agent
from langchain_core.prompts import PromptTemplate
from langchain_core.tools import tool
from langchain_openai import ChatOpenAI
 
# 自定义工具：计算两个数的乘积
@tool
def multiply(a: int, b: int) -> int:
"""将两个整数相乘。适用于数学运算场景。"""
return a * b
 
# 自定义工具：获取当前年份
@tool
def get_current_year() -> int:
"""返回当前年份。适用于需要知道时间日期的场景。"""
return 2025
 
tools = [multiply, get_current_year]
 
llm = ChatOpenAI(model="gpt-4o-mini", temperature=0)
 
# 官方 ReAct 提示词要求必须包含这些占位符
prompt = PromptTemplate.from_template(
"你是一个智能助手，请尽可能借助工具回答问题。\n"
"可用工具如下：\n{tools}\n"
"工具名列表：{tool_names}\n"
"请严格按以下格式回答：\n"
"思考：你需要做什么\n"
"行动：工具名称\n"
"行动输入：{{\"参数\": \"值\"}}\n"
"观察：工具返回结果\n"
"... 重复以上过程直到你得到答案 ...\n"
"最终答案：你的回答\n\n"
"用户问题：{input}\n"
"历史记录：{agent_scratchpad}"
)
 
agent = create_react_agent(llm=llm, tools=tools, prompt=prompt)
agent_executor = AgentExecutor(
agent=agent,
tools=tools,
verbose=True, # 打印每步思考与行动
max_iterations=5, # 防止死循环
handle_parsing_errors=True, # 模型输出格式异常时自动重试
)
 
result = agent_executor.invoke(
{"input": "计算 1234 乘以 5678 的结果，并告诉我当前是哪一年。"}
)
print(result["output"])

这段代码里有两个值得关注的点。

第一，@tool 装饰器会把 Python 函数的 __doc__ 作为工具描述发给模型，因此函数的 docstring 要写清楚“这个工具是干什么的、适合什么场景”，这会直接影响模型能否正确选择工具。

第二，handle_parsing_errors=True 在生产环境中非常重要。大模型偶尔会输出不符合格式要求的内容，如果解析失败直接抛异常，用户体验会很差；开启后 LangChain 会把解析错误反馈给模型，让它重新生成，提高任务成功率。

5.3 运行观察

带着 verbose=True 运行，你会看到控制台逐行打印模型内部的 ReAct 循环过程。你会看到模型先输出“思考：我需要调用 multiply 工具来计算……”，然后调用工具，看到结果后继续思考，再调用 get_current_year，最终拼出答案。

这个过程中最容易出现的问题是：模型死循环调用同一个工具，或者一直在“思考”但拿不出行动。解决办法是调低 max_iterations，并在工具层做防重入和超时控制。

如果你希望进一步控制流程，比如先调用 A 工具校验参数，再决定是否调用 B 工具，那 AgentExecutor 就不太好用了。此时应该转向 LangGraph，把每一步建模为图中的节点，通过条件边控制分支。这也是为什么在企业级 Agent 项目中，LangGraph 越来越受重视。

6. MCP：标准化 Agent 工具层

讲到 Agent，绕不开 MCP。MCP（Model Context Protocol，模型上下文协议）是 2024 年底开始走红的一个开放协议，目标是让大模型应用通过统一方式接入外部工具、数据源和文件系统。

6.1 MCP 到底解决了什么问题

在 MCP 出现之前，每接一个工具，开发者在代码里写一个对应的 Function Calling 封装，工具多了之后维护成本非常高。而且不同 Agent 框架对工具的描述格式各不相同，可复用性差。

MCP 的角色更像一个“Agent 世界的中间件”。它把工具的能力统一暴露成标准接口，Agent 只需要通过 MCP 客户端去发现工具、调用工具，不需要关心工具背后是数据库、浏览器、设计软件还是内部 API。你可以在本地起一个 MCP Server，加载一堆工具，然后在任意支持 MCP 的客户端里使用它们。

用表格对比一下常见概念：

概念 作用层次 举例
Agent Skill 面向 Agent 的能力封装 教会 Agent 完成某一类任务的方法
MCP Server 面向工具的标准化接入层 暴露数据库查询、浏览器操作等能力
Function Calling 模型输出结构化调用意图 模型在输出里请求调用某个函数
Tool 装饰器 代码侧把函数暴露给模型 @tool 定义的 Python 函数

简单说，MCP 更偏向“协议”，Skill 更偏向“行为指导”。两者不是替代关系，而是可以配合使用。MCP 让工具接入标准化，Skill 让 Agent 更聪明地使用工具。

6.2 写一个最简 MCP Server

下面用 Python 官方 MCP SDK 写一个最简单的数学工具服务。这个服务暴露一个 add 工具，远程客户端可以直接发现并调用。

PYTHON
# mcp_server.py
from mcp.server.fastmcp import FastMCP
 
# 创建一个 MCP 服务，名字叫 "math-tools"
mcp = FastMCP("math-tools")
 
@mcp.tool()
def add(a: int, b: int) -> int:
"""计算两个整数之和，适合基本加法运算。"""
return a + b
 
@mcp.tool()
def subtract(a: int, b: int) -> int:
"""计算两个整数之差，适合基本减法运算。"""
return a - b
 
if __name__ == "__main__":
mcp.run()

FastMCP 是 MCP Python SDK 提供的高层封装，它会自动根据函数签名生成工具描述，并处理通信细节。运行这个文件后，服务会在本地启动一个标准输入输出通道，等待客户端连接。你可以在其他支持 MCP 的客户端里加载这个脚本路径，动态发现 add 和 subtract 两个工具。

6.3 在 LangChain 中加载 MCP 工具

在 LangChain 项目中，可以通过 langchain-mcp-adapters 将 MCP Server 暴露的工具加载成 LangChain 的 Tool 对象，然后直接喂给 Agent 使用。

PYTHON
# demo/06_mcp_client.py
import asyncio
from mcp import ClientSession, StdioServerParameters
from mcp.client.stdio import stdio_client
from langchain_mcp_adapters.tools import load_mcp_tools
from langchain.agents import create_react_agent, AgentExecutor
from langchain_core.prompts import PromptTemplate
from langchain_openai import ChatOpenAI
 
async def main():
# 以子进程方式启动 MCP Server
server_params = StdioServerParameters(
command="python",
args=["mcp_server.py"],
)
 
async with stdio_client(server_params) as (read, write):
async with ClientSession(read, write) as session:
# 自动发现并加载 MCP 工具
tools = await load_mcp_tools(session)
 
llm = ChatOpenAI(model="gpt-4o-mini", temperature=0)
prompt = PromptTemplate.from_template(
"你是一个智能助手，请借助工具回答问题。\n"
"工具：{tools}\n"
"工具名列表：{tool_names}\n"
"请以思考/行动/观察/最终答案的格式回答。\n"
"问题：{input}\n历史：{agent_scratchpad}"
)
 
agent = create_react_agent(llm=llm, tools=tools, prompt=prompt)
agent_executor = AgentExecutor(agent=agent, tools=tools, verbose=True)
 
result = await agent_executor.ainvoke(
{"input": "请计算 2 加 3 的结果，再计算 10 减 4 的结果。"}
)
print(result["output"])
 
if __name__ == "__main__":
asyncio.run(main())

这段代码的优点是：Agent 不再关心工具具体实现在哪里，只要 MCP Server 启动成功，客户端会自动发现工具。如果你想接入外部服务，比如 Figma、Playwright、数据库中间件，只需要把 command 和 args 换成对应服务的启动方式，代码逻辑不用改动。

需要提醒的是，langchain-mcp-adapters 仍在快速迭代中，不同版本的导入路径可能有差异。如果遇到 load_mcp_tools 导入失败，先检查这个包的版本和官方 README，而不要盲目改代码。

6.4 MCP 在企业场景中的价值

从材料看，MCP 已经从最初的 AI 编程辅助场景扩展到设计工具、数据库、IDE 工具链等多个方向。这说明 MCP 正在成为 Agent 工具接入的通用标准。对我们开发者的直接影响是：团队的内部工具库可以用 MCP Server 统一暴露，Agent 应用、IDE 插件、低代码平台都能复用同一套工具接口。虽然部署和调试成本客观存在，但从标准化角度看，方向已经很清晰。

7. MapReduce 与其他文档处理模式

Agent 和工具讲完之后，回到一个很实际的问题：当文档太长、上下文窗口放不下时，怎么办？这正是 MapReduce 这类文档处理链要解决的场景。

7.1 Stuff、MapReduce、Refine 的对比

在 LangChain 的文档处理体系里，有三种经典策略：

模式 工作方式 优点 缺点 适用场景
Stuff 把所有文档直接拼进提示词 简单，信息完整 受上下文窗口限制 文档量小
MapReduce 先逐段摘要，再合并摘要 可处理超长文档 可能丢失细节，成本高 长文档全局摘要
Refine 逐段迭代，边读边润色答案 保留上下文衔接 串行慢，误差累积 需要逐步归纳

MapReduce 的思路是：第一步对每个切块单独生成摘要，第二步把所有摘要再汇总成最终结果。这个过程和 Hadoop 里的 MapReduce 思想类似，只是处理对象从数据变成了文本片段。

在实际代码里，LangChain 提供了一个比较经典的 load_summarize_chain。不过新版官方更推荐用 LCEL 自行组合，下面给出一个基于经典 API 的可运行示例。

PYTHON
# demo/07_mapreduce_summary.py
from langchain.chains.summarize import load_summarize_chain
from langchain.text_splitter import CharacterTextSplitter
from langchain_community.document_loaders import TextLoader
from langchain_openai import ChatOpenAI
 
loader = TextLoader("docs/long_report.txt", encoding="utf-8")
docs = loader.load()
 
splitter = CharacterTextSplitter(chunk_size=1000, chunk_overlap=100)
split_docs = splitter.split_documents(docs)
 
llm = ChatOpenAI(model="gpt-4o-mini", temperature=0)
 
# map 阶段生成单段摘要，reduce 阶段汇总成最终摘要
chain = load_summarize_chain(
llm=llm,
chain_type="map_reduce",
map_prompt="请用不超过100字概括以下内容：\n{text}",
combine_prompt="请综合以下摘要，生成一段完整报告摘要：\n{text}",
)
 
summary = chain.invoke(split_docs)
print(summary["output_text"])

运行之后，你会得到一个比原文短很多的摘要。注意 chain_type="map_reduce" 的调用方式是旧版 API，但在很多存量代码里仍然出现。如果在企业新项目里，我更推荐用 LCEL 自己组合 MapReduce 流程：用 RunnableLambda 或 LangGraph 的 Map 节点处理每个分块，再用 combine_documents 汇总。这样每一步的输入输出都清晰可控，便于监控和恢复。但这个写法的完整示例比较长，初学者可以不急着在第一步掌握。

7.2 MapReduce 在企业落地中的坑

MapReduce 的第一个坑是成本。每个文本分块都要调用一次模型，如果长文档切成 100 个块，地图阶段就是 100 次调用，费用和时间都会显著上升。在实际项目中，可以先用聚类或关键词过滤掉无关分块，再做摘要。

第二个坑是信息丢失。单块摘要会丢弃很多细节，汇总阶段只基于摘要做二次归纳，最终结果往往只保留大方向。如果业务要求严格保留数据细节，MapReduce 并不合适，应优先考虑增大上下文窗口或使用 Refine。

第三个坑是顺序依赖。某些文档的逻辑是层层递进的，各块之间有关联。MapReduce 默认把每个块当独立单元，容易丢失前后逻辑。对这种文档，可以按章节切分，而不是按固定字符数切分。

8. 企业项目实战：工程问题与最佳实践

跑通示例和上线之间，还隔着很多工程问题。这一章把实际项目中最常遇到的问题和做法总结出来。

8.1 常见问题与排查思路

问题现象 可能原因 排查方式 解决方案
新版代码报 DeprecationWarning 使用了旧版 API 查看警告信息中的替代方案 改用 LCEL / LangGraph，或先锁定旧版本运行
RAG 回答答非所问 检索片段不相关 打印 retriever.invoke 结果检查召回内容 调整切分参数，调大 k，增加重排环节
向量库启动报错 依赖版本冲突 查看错误堆栈，检查 langchain-chroma 版本 统一依赖版本，或用 InMemoryVectorStore 先验证流程
Agent 死循环 模型反复选择同一个工具 开启 verbose 观察循环 设置 max_iterations，增加工具调用唯一性校验
MCP Server 启动后客户端找不到工具 包版本或通信方式不匹配 先独立测试 MCP Server，再测试客户端加载 检查 SDK 版本，参考官方 README 调整
生产环境响应太慢 串行调用过多 查看链路的日志和耗时分布 增加缓存、并行调用、异步处理

排查问题时，最忌讳一上来就怀疑模型能力。大部分 LangChain 问题都出在数据格式、工具描述、依赖版本和提示词结构上。建议先打印模型收到的完整提示词和工具返回结果，往往一眼就能定位。

8.2 工程实践 1：锁版本，不要盲目追新

LangChain 的版本变化之快，在 Python 生态里也算少见。一个项目今天跑得好好的，明天升级一个小版本就可能出现导入错误。企业项目一定要在 requirements.txt 或 pyproject.toml 里锁定版本范围，并且把升级当成一次独立的测试任务来做。

TXT
langchain>=0.3,<0.4
langchain-openai>=0.2,<0.3
langgraph>=0.2,<0.3

依赖锁定虽然简单，却是成本最低的防故障手段。很多线上事故都源于“顺手升级了一个依赖”。

8.3 工程实践 2：可观测性必须前置

LLM 应用的最大特点是“不确定”。同一个问题，模型今天回答和明天回答可能不一样。因此，日志记录不能只记录结果，还要记录提示词、模型输出、token 消耗、耗时、工具调用序列。

如果你还没有接入 LangSmith 或 Langfuse，也可以先用最朴素的方式：在每个关键节点打印结构化日志。生产环境建议把完整的调用轨迹写入日志系统，方便出问题时回放。

8.4 工程实践 3：工具层要加权限和风控

Agent 可以调用工具，就意味着模型一旦被注入恶意指令，可能触发危险操作。比如你给 Agent 一个删除数据库记录的工具，提示词注入可能让模型在用户诱导下执行危险调用。

所以工具函数内部必须做权限校验和参数白名单校验。模型输出的参数只是“建议值”，真正执行时要在代码里二次确认。尤其是删除、修改、发送消息这类高影响操作，建议加入人工审批节点。Agent 工具的权限设计原则是最小权限：只给执行任务所需的工具，不给多余能力。

8.5 工程实践 4：从 AgentExecutor 平滑迁移到 LangGraph

如果你的 Agent 逻辑越来越复杂，比如需要用户确认、需要回退到上一步、需要多个 Agent 协作，建议尽早迁移到 LangGraph。迁移时不需要推翻重来，可以把原有工具函数原样保留，只把外层循环改成图结构。

简单来说，LangGraph 的三个基本节点是：Agent 节点、工具节点、条件边。Agent 节点负责决定调用哪个工具，工具节点负责执行，条件边根据工具结果决定下一步是继续还是结束。虽然概念上比 AgentExecutor 多一层，但它带来的可控性和可调试性，在企业项目里非常值得。

9. 总结与后续学习建议

回到开头那个问题：LangChain 学了到底有没有用？我的答案是有用，但你要盯着新版本的核心方向学，而不是照着旧教程背 API。

这篇文章真正想讲清楚的一件事是：大模型应用开发的技术栈已经从“搭一条写死的链”变成“搭一个可控的智能体流程”。RAG 是给模型补充知识，ReAct 是让模型有推理和行动能力，MCP 是让工具接入标准化，LangGraph 是让整个流程状态可控。LangChain 的价值，就是把这些能力统一在同一个编程模型里，让你不必自己从零实现分布式向量库、工具协议和状态机。

如果你现在还有点乱，建议按这样的顺序练习：

  1. 先不加任何框架，直接用大模型 SDK 体验 Function Calling，理解模型如何输出工具调用意图；
  2. 再使用 LangChain 的 @tool 和 create_react_agent 跑通一个最小 Agent；
  3. 然后做 RAG，重点调优切分参数和检索质量；
  4. 接着用 LangGraph 把上述 Agent 流程画成一张状态图；
  5. 最后再研究 MCP 怎么把团队内部工具有效暴露出来。

这个顺序背后的逻辑是：先用最底层的方式理解原理，再用 LangChain 提高效率，最后用 LangGraph 和 MCP 解决生产问题。每一步都有明确的目标，不会陷入“学了 API 就忘”的循环。

在实际项目中，你还会遇到模型选型、Embedding 模型评测、Prompt 版本管理、成本控制、数据权限隔离等一系列问题，这些靠一篇文章讲不完。但只要你理解了框架的核心抽象，新概念和新工具出现时，你都能快速判断它在整个体系里处于哪一层、解决什么问题。这比记住某一个 API 重要得多。

LangChain 1.3 实战指南：RAG、Agent、MCP与LangGraph企业级应用
carwinloo
LangChain + MCP 实战：从零搭建 MCP Server 并集成 Agent
暗黑游侠
LangChain与LangGraph实战：从模型调用到构建AI Agent智能体
暗黑游侠
LangChain、LangGraph与DeepAgent：AI Agent开发技术栈全解析与实战选型指南
暗黑游侠
LangChain、LangGraph与DeepAgent：AI Agent开发三件套详解与选型指南
暗黑游侠
大模型开发实战演进：从Prompt工程到Agentic RAG与MCP协议
莫仝汉
LangChain入门到Agent实战：模型调用、工具编排与记忆管理
通人情
LangChain、LangGraph与DeepAgent：从组件到智能体的AI应用开发指南
暗黑游侠
LangChain实战：从Model调用到Agent智能体开发全流程
通人情
LangChain零基础实战：从Model模型接入到Agent智能体开发
往后清白
LangChain+LangGraph+MCP+Agent：企业级智能体开发实战路线
本文系统讲解LangChain、LangGraph、MCP和Agent四大技术在企业级智能体开发中的定位与协同：LangChain作为基础框架提供模型调用与RAG能力；LangGraph作为有状态图编排引擎，支撑条件路由、循环、子图与人工审核；MCP作为开放工具接入协议，实现标准化外部系统集成；Agent则依托三者构建具备规划、工具调用、记忆与人机协同的自主执行体。重点涵盖MCP Server落地、LangGraph工作流设计、API封装及性能优化。
weixin_34319374
672
2026 AI Agent 学习路线图：从小白到实战，系统掌握智能体开发
本文系统梳理2026年AI Agent开发的核心技术与四阶段学习路径：从LLM API调用、ReAct循环实现，到LangGraph编排、MCP工具服务开发，再到AutoGen/CrewAI多智能体协作，最后延伸至Agent安全、评估体系与企业级平台设计。涵盖Agent架构四层模型、四大核心模式（ReAct/Plan-and-Execute/Multi-Agent/Reflexion）及关键技术栈，强调工程落地与实战项目驱动。
实中陈冠希
11560
LangChain、LangGraph与MCP实战：构建企业级AI Agent
本文深入解析LangChain、LangGraph与MCP在AI Agent开发中的协同机制：LangChain提供基础组件（模型封装、提示词、工具定义），LangGraph实现有状态的条件路由与执行循环，MCP则统一标准化外部工具接入。通过企业级知识库查询Agent实战，覆盖MCP Server搭建、LangGraph状态图设计、多轮工具调用、长期记忆集成及生产级排错与工程规范，强调工具层与编排层解耦、最小原子工具设计、上下文控制与可观测性等关键实践。
weixin_30291791
323
LangChain实战：从RAG到Agent，构建可控大模型应用工作流
本文系统阐述如何利用LangChain生态（RAG、Agent、MCP、LangGraph）构建可控、可扩展的大模型应用工作流。重点解析RAG解决知识截止与长文档处理，Agent赋予模型工具调用能力，MCP实现工具标准化接入，LangGraph建模复杂有状态工作流。强调从MVP渐进式演进，覆盖设计、评估、工程化与持续迭代全流程。
weixin_34341229
450
LangChain与MCP实战：Agent工具接入标准化的完整指南
本文系统讲解LangChain与MCP协同构建Agent的技术路径，厘清LangChain（高层编排）、LangGraph（流程控制）和MCP（工具通信协议）的分层定位；重点演示如何通过MCP Server暴露工具、利用LangChain MCP Adapter动态接入，并实现Agent对标准化工具的自动调用；涵盖环境配置、最小Server实现、调试验证及工程最佳实践。
weixin_34218579
474
LangChain与LangGraph实战：从零构建AI Agent智能体
本文系统讲解如何使用LangGraph构建有状态、可循环的AI Agent，涵盖LangChain与LangGraph的关系、条件路由、工具调用循环、MCP协议接入外部工具、短期与长期Memory实现机制，并提供完整Python代码及常见问题排查方案，聚焦Agent工程化落地核心能力。
weixin_33912246
419
LangChain 1.3 实战指南：从 RAG 到 Agent 与 LangGraph 的智能应用开发
本文系统讲解LangChain 1.3框架的核心应用，涵盖RAG知识库构建、Agent工具调用与LangGraph工作流编排三大关键技术。内容包括环境配置、模型I/O、提示工程、向量检索、ReAct智能体设计、状态化图工作流实现，以及本地模型接入、RAG优化、Agent设计原则和LangGraph生产级实践，面向开发者提供可复现的AI应用开发路径。
bo o ya ka
532
MCP与LangChain实战：统一Agent工具接入与编排
本文聚焦AI Agent工具接入的标准化与工程化，详解MCP协议如何统一工具发现、调用与返回，对比LangChain AgentExecutor与LangGraph在Agent编排中的定位差异，并基于DeepSeek模型实现MCP Server开发、LangChain MCP适配器集成及LangGraph图状态编排的完整链路。内容涵盖环境配置、代码实现、运行验证及生产级最佳实践，突出协议抽象、框架分层与可观测性设计。
weixin_34199405
367
MCP与LangChain Agent实战：从协议原理到生产级应用开发
本文深入解析Model Context Protocol（MCP）协议原理，涵盖其三层架构、JSON-RPC 2.0消息格式及Server/Client角色分工；详解LangChain Agent与LangGraph的定位差异与协同机制；提供从环境搭建、远程MCP Server开发、鉴权集成到LangGraph Agent编排的完整生产级实现流程；并总结工具设计、安全边界、异步处理等工程最佳实践。
chuannaoxuan4674
307
从RAG到LangGraph：AI Agent开发全链路学习路线
本文系统梳理AI Agent开发技术栈，涵盖RAG（检索增强生成）知识库构建、MCP（模型上下文协议）工具标准化接入、LangChain组件化开发框架及LangGraph图编排引擎。内容聚焦从LLM API调用起步，经RAG最小闭环、LangChain组件整合、MCP工具集成，到LangGraph状态机编排与企业级落地（日志可观测性、权限控制、效果评估指标），提供可执行的学习路线与工程实践要点。
Marco Liu
321
AI Agent开发实战：从RAG、MCP到LangGraph的完整技术栈串联指南
本文系统串联AI Agent开发核心技术栈，涵盖RAG知识增强、MCP工具调用协议、LangChain基础组件与LangGraph工作流编排。通过构建“智能技术问答助手”实战项目，详解环境配置、本地知识库搭建、MCP工具封装、多步骤决策图编排等关键环节，并提供工程化部署、错误排查与性能优化的最佳实践。
Maggie H
211
LangChain与MCP组合实战：构建Agent工具调用与生产级应用
本文详解LangChain与MCP（Model Context Protocol）协同构建Agent的工程实践，涵盖概念辨析、环境配置、自建MCP Server、LangChain工具接入、联网检索/RAG/记忆/多工具编排等扩展能力，并重点阐述异步并发、日志设计、失败重试、幂等性及生产化验收要点。强调MCP标准化工具接入与LangChain应用编排的职责分离，突出从Demo到可维护系统的落地路径。
weixin_34408624
331
LangChain实战指南：从RAG到Agent，构建企业级大模型应用
本文系统讲解LangChain框架在企业级大模型应用中的落地实践，聚焦RAG知识库问答系统与ReAct Agent工具调用两大核心路径。内容涵盖MapReduce长文本处理、RAG全流程（文档加载/切分/向量化/检索/生成）、Agent任务规划与安全管控，并延伸至LangGraph图编排与MCP协议集成。强调工程化最佳实践，包括LCEL链式构建、依赖锁定、重试降级、Prompt分离、权限控制与可观测性建设。
weixin_33847182
294
LangChain、LangGraph、MCP、Agent企业级AI应用实战：从入门到部署
本文聚焦LangChain、LangGraph、MCP与Agent技术栈的企业级落地，涵盖环境配置、最小Agent构建、LangGraph图编排、RAG集成、工具调用验证、API服务封装及批量任务处理。强调2026新版实践路径，突出LangGraph作为核心工作流引擎的地位，详解节点编排、状态管理、并行处理与资源优化，并提供合规安全边界、日志排查和生产级最佳实践。
要上进的柯同学
325
企业级AI应用实战：Agent、RAG与MCP技术栈深度集成指南
本文详解企业级AI应用中Agent、RAG与MCP三大技术的深度协同：RAG提供精准知识检索以抑制幻觉；Agent实现任务规划与多工具自动执行；MCP作为标准化协议，解耦模型与企业内部工具系统。涵盖架构设计、LangChain/LangGraph实现、Chroma/Milvus向量库选型、MCP Server封装、FastAPI服务暴露，以及权限控制、混合检索、异步处理、审计日志等生产级最佳实践。
weixin_30715523
406
LangGraph实战指南：用状态图编排可控的Agent流程
本文系统讲解LangGraph作为Agent流程编排框架的核心机制：基于状态机的节点、条件路由、循环、子图与并行分支设计；强调其不负责模型调用，专注状态管理与流程控制；详解如何集成RAG、MCP工具、多轮记忆（checkpointer）及调试方法；指出LangGraph与LangChain、MCP的定位差异，突出工程落地中的状态一致性、退出条件、并发安全等关键实践要点。
weixin_34416649
577
LangChain + MCP 实战：打造可上生产的 Agent 智能体
本文系统讲解如何基于LangChain与MCP协议构建可上生产的Agent智能体。内容涵盖Agent核心概念辨析、LangGraph最小Demo实现、MCP Server开发与Adapter集成、工具标准化接入、全流程可观测性调试（LangSmith/消息轨迹）、生产部署要点（FastAPI封装、权限控制、超时熔断、日志追踪）及高频面试问题解析，聚焦工程落地中的标准化、可控性与安全性。
chuange6363
366
LangGraph与MCP实战：从LangChain到生产级Agent的流程编排指南
本文系统阐述LangChain、LangGraph与MCP在Agent开发中的角色分工：LangChain负责模型接入与组件抽象，LangGraph提供基于状态和图结构的流程编排能力，MCP实现工具调用的标准化协议。重点解析状态管理、条件边设计、MCP工具集成、企业级工程开关（持久化、审批流、限流、可观测性、上下文压缩、权限控制）及故障排查方法，强调从演示到稳定生产的工程化落地路径。
黑虾电影
269
【图书介绍】《AI Agent智能体与MCP开发实践：基于Qwen3大模型》
本书以Qwen3大模型为核心，系统讲解AI Agent智能体开发全链路技术，涵盖环境配置、RAG与提示工程、Agent架构设计、A2A/MCP协议、多Agent协作及LangGraph框架应用。通过跨境电商客服、高德地图MCP调用、arXiv科研服务、旅游规划、住宅投研等5个真实项目，实现从理论到工程落地的完整实践。所有代码经测试可运行，配套源码、课件与技术交流群。
夏天又到了
1278
LangChain与LangGraph实战：从零构建企业级AI智能体应用
本文系统梳理LangChain与LangGraph构建企业级AI智能体的核心路径，涵盖环境搭建、基础链与Agent开发、LangGraph多步骤工作流编排、RAG问答系统实现、MCP协议集成、FastAPI封装API及批量任务处理。重点突出智能体的工具调用、状态管理、流程控制与生产部署能力，强调提示工程、可观测性、安全护栏和成本优化等关键技术实践。
自我修炼的小石头
385