2026 年做 AI 应用最尴尬的事情是什么是你还在让大模型“背课文”别人已经让大模型“自己干活”了。这里的“干活”不是生成一段文字而是让模型自己判断先查什么数据、调用哪个工具、处理什么中间结果、最后拼凑成什么答案。这就是 Agent。但这篇文章不是来给你讲概念的而是要解决一个实打实的痛苦LangChain、MCP、LangGraph 这三样东西放在一起到底该怎么学、按什么顺序用、各自解决什么问题很多新手一上来就混着看LangChain 还没搞明白又冒出 MCP然后又看到 LangGraph直接懵在原地。如果你也在犹豫“到底学哪个”或者已经把三样东西的所有文档都收藏了一遍但迟迟没有跑通那这篇文章就是为你准备的。我会先讲清楚三者的边界和关系再给出一套真正能跑通的实战样例从最快速的 create_react_agent到 LangGraph 手动控制流程再到 MCP 协议接入统一工具。你可以照着文章一步步操作理解 Agent 的基本运行原理同时避开新手最容易掉进去的坑。1. 这篇文章真正要解决的问题先说结论LangChain、MCP、LangGraph 不是同一个层面的东西它们并不互相替代。LangChain 是一个 LLM 应用开发组件库MCP 是一个工具接入协议LangGraph 是一个 Agent 流程编排引擎。真正的 Agent 应用往往是三者配合使用。那为什么新手会分不清因为表面上它们都跟“AI 应用开发”有关很多时候教程里也会把三个名词混在一起讲。再加上官方文档更新快网上资料参差不齐很容易被各种“Agent 全家桶”文章带偏。这篇文章的核心目的是帮你建立起一张清晰的认知地图LangChain 负责“基础组件”模型接入、Prompt 管理、Retriever、输出解析。MCP 负责“工具标准化”让 Agent 可以统一发现和调用任意支持 MCP 协议的工具。LangGraph 负责“流程可控”定义 Agent 的状态、节点、边、循环、中断和人工确认。换句话说LangChain 是工具箱MCP 是插头标准LangGraph 是流水线控制台。把这三件事想清楚再去看任何 Agent 开源项目你都不会再觉得乱。2. LangChain 核心价值与使用边界2.1 LangChain 到底解决了什么问题在没有 LangChain 的时代写一个调用大模型的接口其实也不难response openai.ChatCompletion.create( modelgpt-4o-mini, messages[{role: user, content: 你好}] )但如果你的应用稍微复杂一点问题就来了要接多个模型怎么办Prompt 要统一管理怎么办输出要解析成结构化 JSON 怎么办需要做 RAG 怎么办这些问题本身不难但每个都要自己写一遍工作量就变得很大。LangChain 做的是把这一层能力标准化。它提供了一套统一的接口抽象ChatModel统一封装不同厂商的模型调用。PromptTemplate可复用的提示词模板。Retriever对接向量数据库、搜索引擎。OutputParser把模型输出解析成 JSON、 Python 对象等结构化数据。Tool把任意函数包装成模型可以调用的工具。LangChain 最大的价值是让你在项目早期不用重复“造轮子”把更多精力花在业务逻辑上。2.2 LangChain 的边界在哪里LangChain 并不是万能的。它的早期设计里面应用逻辑通常是一条固定的 Chain比如“先检索 → 再组织 Prompt → 再调用模型 → 再解析输出”。这种链式结构适合流程确定的场景比如 RAG 问答。但真正的 Agent 应用有两个特点第一运行过程不确定模型先调用哪个工具、调用几次都是动态的第二需要复杂的循环和分支控制。比如 Agent 先判断用户有没有给城市名没给就先追问给了再去调天气工具拿到结果后再决定要不要继续查别的信息。如果你用固定 Chain 来实现这种动态逻辑代码会非常别扭最后大概率会写出一堆 if-else。LangChain 团队后来也意识到了这一点所以在生态体系里推出了 LangGraph用图结构来解决动态流程编排问题。这里有一个很常见的误区很多人以为 LangGraph 是 LangChain 的替代品要“抛弃 LangChain”转 LangGraph。实际上 LangGraph 底层仍然大量依赖 LangChain 的组件比如 ChatModel、Tool、BaseMessage 这些核心抽象。两者是分工合作而不是你死我活的关系。3. MCP 协议把工具变成标准服务3.1 MCP 是什么MCP 全称是 Model Context Protocol模型上下文协议。它最早由 Anthropic 在 2024 年底提出目标非常明确统一 AI 应用与外部工具、数据源之间的连接方式。简单理解MCP 就是 AI 世界的 USB-C 接口。过去你给 AI 应用接入一个工具要单独写一套对接逻辑接两个工具要写两套接十个工具代码里到处都是工具定义的重复劳动。MCP 提出了一种标准做法工具能力的提供方做成 MCP ServerAI 应用作为 MCP Client通过统一的协议去发现工具、调用工具。MCP 的核心交互过程大致是MCP Server 声明自己能提供哪些工具每个工具的参数是什么。MCP Client 从 Server 获取工具列表并和这些工具打交道。大模型决定调用哪个工具时Client 把具体命令发给 Server 执行再把结果返回给模型。这种设计最大的好处是解耦同一个 MCP Server可以被 Claude Desktop、Cursor、自研 Agent 等任意客户端复用不需要为每个应用单独开发接口。3.2 MCP 和 Function Calling 的区别这是新手最容易混淆的地方。很多人问模型不是已经有 Function Calling 了吗为什么还要 MCP我的理解是Function Calling 是“模型接口层”的能力。它解决的是让模型输出结构化工具调用参数的问题。比如你告诉模型有两个函数模型判断该调哪个并输出对应的 JSON 参数。MCP 是“应用协议层”的标准。它解决的是客户端与工具服务之间如何发现、连接、调用的问题。它不一定关心模型是不是支持 Function Calling更多关注的是程序之间的通信格式。实际开发中两者经常配合出现LangGraph 里的 Agent 通过 Function Calling 让模型决定调什么工具然后执行工具时底层可以用 MCP Client 去调用远端或本地的 MCP Server。MCP 还有一个优势工具被封装成独立进程或独立服务之后可以进行权限控制、独立部署、复用给不同团队。这种“工具即服务”的思想对中大型团队尤其有价值。3.3 MCP 生态为什么热度这么高从网络搜索热词可以看到MCP 已经不只属于 AI 圈连蓝湖 MCP、Unity MCP、Cocos MCP、Matlab MCP 都开始出现。这意味着设计稿工具、游戏引擎、科学计算软件都在尝试用 MCP 把自己的能力暴露给 AI 应用。这种趋势背后的逻辑很直接谁掌握了工具入口谁就掌握了 Agent 的能力边界。对开发者来说MCP 是 2026 年前后必须补的一课因为你以后接的工具会越来越多靠“一个工具写一套代码”的老路已经走不通了。4. LangGraphAgent 的执行引擎4.1 LangGraph 核心思想LangGraph 是 LangChain 团队推出的 Agent 编排框架。它的核心理念可以概括为把 Agent 应用定义成一张图。图中的“节点”是函数或逻辑单元图中的“边”是状态流转关系。Agent 每运行一步就从一个节点走到下一个节点。节点之间可以形成循环也可以根据条件走不同分支。LangGraph 有四个关键概念概念说明类比State整个图的全局状态节点之间通过它传递数据流水线上的记录单Node一个具体函数负责处理状态并返回更新流水线上的一个工位Edge决定状态下一个流向哪里连接工位之间的传送带Conditional Edge根据当前状态动态决定走向哪个节点传送带上的分拣器除了这些LangGraph 还支持 Checkpointer检查点可以在每步执行时保存状态。这意味着 Agent 可以在任意节点暂停、断点续跑甚至实现“人工确认后再执行下一步”的流程。4.2 LangChain 和 LangGraph 的区别可以这样理解LangChain 提供的是“积木”LangGraph 提供的是“图纸搭建场地”。你用 LangChain 的 ChatModel 拿到模型响应。你用 LangChain 的 Tool 定义工具。但你要如何控制 Agent 的完整运行流程如何实现工具调用失败重试如何插入一个人工审批节点这些“流程控制”问题LangChain 本身并不能很好地解决需要交给 LangGraph。正因为 LangGraph 更底层、更灵活所以 LangChain 官方后来也把推荐的高级 Agent 实现迁移到了 LangGraph 之上。比如create_react_agent看起来是“LangChain 的 Agent”实际上它的运行内核就是 LangGraph 的图执行引擎。理解了这一点你就看懂了官方技术栈的演进方向未来的 Agent 开发核心是 LangGraph。5. 三者如何组合成现代 Agent 架构把它们放到同一个架构里看关系会非常清晰最外层是业务需求用户提问、Agent 回答、执行工具、返回结果。中间层是 LangGraph定义 Agent 状态机、工具调用循环、条件分支、人工确认。基础层是 LangChain提供模型接口、Tool 封装、Prompt 解析等组件。横切层是 MCPAgent 要用的工具并不在代码里写死而是通过 MCP Client 动态发现和调用 MCP Server。举个例子假设你正在开发一个“智能客服 Agent”它能查天气、查订单、查物流。如果用传统 Function Calling 方式你需要把天气 API、订单 API、物流 API 全部在代码里封装成 Tool再给每个 Tool 写 JSON Schema。如果之后要增加一个“查库存”的能力你得改代码、改配置、重新部署。如果用 MCP 方式你可以把订单服务部署为一个 MCP Server。Agent 通过 MCP Client 连接它获取工具列表模型根据用户意图决定调用哪一个。后续新增工具只需要升级 MCP ServerAgent 侧几乎不用改代码。这个架构的优势在工具数量少的时候还不明显但当工具超过 10 个、团队超过 3 个人、需要跨项目复用时协议标准化的价值就会体现得非常明显。6. 环境准备与依赖安装在动手写代码之前先准备好运行环境。本文以 Python 为例。6.1 环境要求Python 3.10 或更高版本。Agent 相关的依赖包更新很快建议使用新版本 Python。支持工具调用的模型。可以用 OpenAI 的模型也可以使用 DeepSeek、Qwen 等国内模型的 OpenAI 兼容接口。建议使用 venv 创建独立虚拟环境避免包冲突。建议准备一个.env文件存放模型 API Key。6.2 安装依赖先创建一个虚拟环境python -m venv agent_env source agent_env/bin/activate # Windows: agent_env\Scripts\activate然后安装核心依赖pip install --upgrade pip pip install langchain langchain-openai langgraph mcp langchain-mcp-adapters python-dotenv版本说明LangChain 和 LangGraph 的迭代节奏非常快具体包版本以安装时为准本文不锁定旧版本。只要 API 语法发生变化优先以官方文档为准。6.3 配置模型在项目目录下创建.env文件OPENAI_API_KEYsk-your-key-here如果你用的是 OpenAI 兼容接口的国内模型可以通过修改环境变量来指定 Base URL 和模型名称这个后面章节会给出示例。7. 实战一用 create_react_agent 快速搭建 Agent7.1 场景目标先做一个最小可跑通的 Agent用户问天气Agent 自主决定调用天气查询工具并返回结果。7.2 定义工具在项目中创建文件quick_agent.pyfrom langchain.tools import tool tool def get_weather(city: str) - str: 查询指定城市的当前天气参数 city 是城市名例如北京、上海。 # 这里用模拟数据实际项目中可以替换为真实天气 API weather_data { 北京: 晴25℃空气质量优, 上海: 多云28℃空气质量良, 广州: 小雨30℃空气质量良, 深圳: 阴29℃空气质量良, } return weather_data.get(city, f暂未收录 {city} 的天气数据)工具函数上方的 docstring 非常重要。LangGraph 在把工具绑定给模型时会把 docstring 作为工具的描述发送给模型。模型就是根据这段描述来判断“什么时候该调用这个工具”的。如果你不写 docstring模型很可能不知道这个工具是做什么的。7.3 创建 Agent继续编辑quick_agent.pyfrom dotenv import load_dotenv from langchain_openai import ChatOpenAI from langgraph.prebuilt import create_react_agent load_dotenv() llm ChatOpenAI( modelgpt-4o-mini, temperature0, ) agent create_react_agent(llm, tools[get_weather]) if __name__ __main__: result agent.invoke({messages: [{role: user, content: 北京今天天气怎么样}]}) print(result[messages][-1].content)运行python quick_agent.py预期输出会类似北京今天的天气是晴25℃空气质量优。出门不用带伞注意防晒。create_react_agent 的命名来自 ReAct 模式。ReAct 是 Reasoning Acting 的组合意思是模型在推理过程中不断决定“下一步要做什么”然后调用工具获取信息再基于新信息继续推理。它很适合快速验证一个 Agent 原型。这个小 Demo 看起来很简单但它已经把 Agent 最核心的闭环跑通了模型分析问题 → 决定调用 get_weather → 拿到工具返回结果 → 组织最终回答。后面所有复杂的 Agent本质上都是在这个闭环上增加更多节点、更多状态、更多控制逻辑。8. 实战二用 LangGraph 手动控制 Agent 流程create_react_agent 很省事但它把流程控制逻辑都封装起来了。如果你要加人工确认、要做多步骤任务、要精确控制哪一步该走哪条分支就需要自己定义 LangGraph 图。这个章节我们手写一个等价但更可控的 LangGraph 版本从底层理解 Agent 的运行机制。8.1 设计状态图整个 Agent 由两个核心节点组成assistant 节点调用大模型让模型判断是否需要调用工具。tools 节点执行模型要求调用的工具。执行流程是START 进入 assistant → 如果模型返回的是工具调用请求则进入 tools → tools 执行完后回到 assistant → 如果模型认为已经可以回答则走向 END。这个“回到 assistant 再判断”的设计就是 Agent 循环的核心。新建文件graph_agent.pyfrom typing import Annotated, TypedDict from dotenv import load_dotenv from langchain.tools import tool from langchain_openai import ChatOpenAI from langgraph.graph import END, START, StateGraph from langgraph.graph.message import add_messages from langgraph.prebuilt import ToolNode, tools_condition load_dotenv() tool def get_weather(city: str) - str: 查询指定城市的当前天气参数 city 是城市名例如北京、上海。 weather_data { 北京: 晴25℃空气质量优, 上海: 多云28℃空气质量良, 广州: 小雨30℃空气质量良, 深圳: 阴29℃空气质量良, } return weather_data.get(city, f暂未收录 {city} 的天气数据) # 1. 定义全局状态 class AgentState(TypedDict): messages: Annotated[list, add_messages] # 2. 定义 assistant 节点 def assistant(state: AgentState): llm ChatOpenAI(modelgpt-4o-mini, temperature0) llm_with_tools llm.bind_tools([get_weather]) response llm_with_tools.invoke(state[messages]) return {messages: [response]} # 3. 构建图 graph StateGraph(AgentState) graph.add_node(assistant, assistant) graph.add_node(tools, ToolNode([get_weather])) graph.add_edge(START, assistant) graph.add_conditional_edges(assistant, tools_condition) graph.add_edge(tools, assistant) app graph.compile()8.2 分析核心逻辑这个代码里最关键的是两个点第一AgentState里用Annotated[list, add_messages]。这个声明表示 messages 字段在每次节点更新时不是直接覆盖而是把新的消息追加到旧消息后面。如果没有这个注解后面的消息会把前面的对话历史覆盖掉多轮对话就会失真。第二tools_condition是 LangGraph 提供的预置条件函数。它会检查 assistant 返回的响应里有没有tool_calls。如果有就进入 tools 节点如果没有就进入 END。这个“条件边”就是 Agent 控制循环的开关。8.3 修改主执行逻辑把graph_agent.py继续补充完整if __name__ __main__: result app.invoke({messages: [{role: user, content: 上海和广州今天天气怎么样}]}) # 打印完整流转过程 for message in result[messages]: if getattr(message, tool_calls, None): print(【模型决定调用工具】, message.tool_calls) elif message.type tool: print(【工具返回结果】, message.content) elif message.type ai: print(【模型回答】, message.content) elif message.type human: print(【用户提问】, message.content)运行python graph_agent.py输出会包含 Agent 内部的决策过程比如【用户提问】 上海和广州今天天气怎么样 【模型决定调用工具】 [{name: get_weather, args: {city: 上海}, ...}] 【工具返回结果】 上海多云28℃空气质量良 【模型决定调用工具】 [{name: get_weather, args: {city: 广州}, ...}] 【工具返回结果】 广州小雨30℃空气质量良 【模型回答】 上海今天多云...看到这个输出你就能直观感受到 Agent 和普通问答的区别模型没有一次性生成最终答案而是先拆解问题连续调了两次天气工具拿到结果后才组织最终回答。这就是 LangGraph 手动控制流程的意义。create_react_agent 做了一套默认的图而你现在有能力在这张图上做任何修改增加人工确认节点、增加消息过滤、增加失败重试逻辑都不再受限于封装函数。9. 实战三通过 MCP 接入统一工具协议前两个实战中工具都是直接定义在代码里的。这一节我们把工具搬到 MCP Server 上演示如何用 MCP 协议把工具接入 Agent。这一步做完你就能感受到“工具即服务”的真正用法。9.1 创建 MCP Server新建mcp_weather_server.pyfrom mcp.server.fastmcp import FastMCP mcp FastMCP(weather-server) mcp.tool() def get_weather(city: str) - str: 查询指定城市的当前天气参数 city 是城市名例如北京、上海。 weather_data { 北京: 晴25℃空气质量优, 上海: 多云28℃空气质量良, 广州: 小雨30℃空气质量良, 深圳: 阴29℃空气质量良, } return weather_data.get(city, f暂未收录 {city} 的天气数据) if __name__ __main__: mcp.run(transportstdio)FastaMCP 是 MCP Python SDK 提供的高层封装用mcp.tool()装饰普通函数就能把函数发布为一个标准的 MCP 工具。transportstdio表示通过标准输入输出通信也就是当前 MCP 最常用的本地进程通信方式。9.2 在 Agent 中接入 MCP新建mcp_agent.pyfrom dotenv import load_dotenv from langchain_mcp_adapters.client import MultiServerMCPClient from langchain_openai import ChatOpenAI from langgraph.prebuilt import create_react_agent load_dotenv() # 通过 MCP 客户端连接 mcp_weather_server.py 提供的工具 with MultiServerMCPClient( { weather: { command: python, args: [mcp_weather_server.py], transport: stdio, } } ) as client: tools client.get_tools() llm ChatOpenAI(modelgpt-4o-mini, temperature0) agent create_react_agent(llm, tools) result agent.invoke( {messages: [{role: user, content: 北京今天天气怎么样}]} ) print(result[messages][-1].content)运行python mcp_agent.py如果一切正常你会看到和前面两个实战一致的天气回答。差别在于这个 Agent 里没有任何工具函数实现它只是作为 MCP Client从远程/本地 MCP Server 动态获取了工具。以后 mcp_weather_server.py 里增加一个get_air_quality(city)工具Agent 代码不需要做任何修改下次运行就能自动发现并调用新工具。9.3 MCP 接入需要注意什么stdio transport 适合本机单进程使用生产环境一般会使用 SSE 或 Streamable HTTP 这类远程传输方式。command 建议写成绝对路径避免在复杂环境下找不到 Python 解释器。MCP Server 应该遵循最小权限原则只暴露必要的工具不要把所有内部能力都暴露出去。10. Agent 开发常见问题与排查思路写 Agent 应用时新手遇到的大部分问题都有规律可循。下面是几个最常见的问题。问题现象可能原因排查方式解决方案模型完全不会调用工具模型不支持 function calling或工具没有绑定到当前模型查看模型文档打印绑定后的模型是否能输出 tool_calls换用支持工具调用的模型确认代码里调用了 bind_toolsAgent 进入无限循环反复调用工具工具返回结果没有让模型得到足够信息或模型判断逻辑不收敛打开完整消息流日志检查工具的返回内容是否清晰给工具返回更明确的结果设置 recursion_limit增加重试限制多轮对话时历史消息被覆盖State 里 messages 字段没有使用 add_messages 注解检查 TypedDict 定义使用Annotated[list, add_messages]MCP 连接失败找不到命令command 不是绝对路径或虚拟环境路径不对在终端手动执行命令确认 Server 能否启动使用绝对路径确认当前 Python 环境正确403 / 401 认证失败API Key 没有正确加载检查 .env 文件打印 os.getenv 内容确认 KEY 名称和代码中一致工具运行抛异常导致图中断工具函数内部没有捕获异常查看异常堆栈在工具函数内捕获异常并返回可读的错误信息给模型一个比较容易忽略的问题是Agent 的“工具调用”过程天然具有不确定性。同一个问题模型有可能调工具也有概率直接凭记忆回答。所以在生产环境中要给 Agent 增加足够的日志追踪甚至用 LangSmith 之类的工具记录每一步的输入输出这样排查问题时才不至于盲猜。11. 最佳实践与工程建议11.1 工具设计要像写 API 文档一样工具是 Agent 和外部世界交互的接口。工具函数的名称、docstring、参数定义本质上就是在给模型写使用文档。工具命名要清晰动词开头比如get_order_status。docstring 要说明工具的用途、副作用、异常情况。参数要尽量少而明确能传字符串就不要设计复杂 JSON 对象。一个工具只做一件事。工具职责越单一模型越容易正确调用。11.2 控制工具数量当一个 Agent 绑定的工具超过 20 个时模型的选择准确率会明显下降。这不是代码问题而是模型本身在“工具挑选”上的能力限制。工程上的做法是按业务域拆成多个 Agent每个 Agent 只负责一组相关工具。比如“订单 Agent”只绑订单类工具“客服 Agent”只绑咨询类工具。复杂的任务可以拆成多级编排流程而不是让一个 Agent 面面俱到。11.3 工具要有容错和反馈工具函数内部不要直接抛异常。一旦工具抛异常Agent 的图执行可能直接中断整个对话就失败了。更稳妥的做法是在工具内部捕获所有异常返回一个可读的消息比如“查询超时请稍后重试”或“订单号不存在请确认后重新输入”。这样模型可以把错误信息纳入上下文继续引导用户而不是直接崩溃。11.4 人工确认和权限隔离不是所有工具都要给模型全权执行。涉及支付、删除、发送消息、修改配置等敏感操作必须加入人工确认节点。LangGraph 的 Checkpointer 可以把 Agent 中断在某个节点之前。模型说“我要调删除接口”之后系统可以先暂停等待人工审批通过后再继续。往 Agent 里塞一个不受控的删除工具相当于给线上数据库留了一个随时可能引爆的接口这在生产环境里是不可接受的。11.5 状态与记忆管理多轮对话的 Agent必须考虑会话状态的持久化。LangGraph 用 Checkpointer 保存每一步的状态但长时间运行的 Agent 还需要考虑消息压缩、历史摘要、Token 成本控制。我建议项目早期就把“会话 ID”这个概念设计好每一条外部请求都带上会话 ID。后续做日志追踪、状态恢复、流量分析都会方便很多。11.6 安全和合规边界接入 MCP Server 时要对工具能力做白名单控制禁用危险操作。同时要避免在日志里打印敏感信息包括用户隐私、API Key、内部地址。如果你部署的是远程 MCP Server务必加上认证和鉴权逻辑。MCP 协议本身只解决“工具如何调用”的问题不解决“谁有权限调用”的问题。权限设计是应用层必须自己做好的事情。12. 总结与后续学习方向到了这里LangChain、MCP、LangGraph 三者之间的关系应该已经比较清楚了。LangChain 提供了模型接入、Prompt、Tool 等基础组件是整个应用开发的地基。MCP 把工具变成标准服务让你不用再为每一个新工具写定制化对接代码。LangGraph 负责 Agent 的状态流转和流程控制是复杂 Agent 应用的执行引擎。从实战角度看你至少应该跑通三件事用 create_react_agent 快速搭建一个 Agent用 StateGraph 手写控制 Agent 循环把工具搬到 MCP Server 上体验“工具即服务”的开发模式。下一步如果要继续深入建议按这个顺序学习先熟练 ReAct 模式与工具调用再学习 LangGraph 的 Checkpointer、人工中断、流式输出然后研究 Multi-Agent 架构多个 Agent 之间如何互相协作最后结合消息队列、任务调度把 Agent 放入真正的生产系统里。Agent 开发的门槛从不在“调用模型”而在于你能否设计出稳定、可控、可维护的流程。理解 LangChain、MCP、LangGraph 三者各自的角色然后动手把最小闭环跑通你就已经超过了绝大多数停留在“收藏教程”阶段的开发者。