2026 年再聊 AI Agent 开发你会发现一个很有意思的现象市面上的教程标题越来越夸张“吊打付费”“全套实战”“从入门到企业级”但真正把原理讲透、把代码跑通、把坑说清楚的内容反而更难找了。这篇教程不想用“吊打”这种词来吸引眼球只想踏实做一件事把 LangChain、LangGraph、MCP、Agent 这四个高频关键词放在同一张技术地图里讲清它们分别解决什么问题、如何协作、以及怎么在一个企业级最小项目中真正跑起来。如果你正准备入门 AI Agent 开发或者已经写了一段时间 LangChain但总感觉停留在“调 API 拼 Prompt”的阶段那么这篇文章值得看完。它会帮你绕开市面教程最常见的几个认知误区同时给出一套可以直接复用的代码骨架。先给出全文的核心判断LangChain 是组件库LangGraph 是编排引擎MCP 是工具接入协议Agent 是最终产品形态。它们不在同一层根本不能互相替代。很多人学了很久其实是在把这四层混在一起学所以才越学越乱。1. 为什么 2026 年做 AI 应用绕不开 Agent 架构先回到一个根本问题大模型的能力已经很强了为什么还要搞 Agent如果你只是做一个“问答机器人”那确实只需要一个 Prompt 一个模型 API 就够了。但企业级 AI 应用很少停留在问答层面。真实业务往往长这样用户问帮我查一下华东区最近一周的订单异常情况并给业务部门发一封摘要邮件。用户问根据这份合同把风险条款提取出来写入 CRM 系统的风险台账。用户问今天库存低于安全线的 SKU 有哪些自动发起补货审批流。这些请求有一个共同点模型只靠自身参数无法完成必须调用外部系统、读取实时数据、执行连续操作并且在整个过程中保持状态一致。这就是 Agent 架构存在的意义。RAG 解决的是“模型不知道”的问题Agent 解决的是“模型不能做”的问题。RAG 把检索结果塞进上下文让模型回答得更准确Agent 则把模型从“只输出文本”变成“能调用工具、能做决策、能执行多步动作”的智能体。但“能做”和“能稳定地在生产环境做”是两回事。从 2024 年到 2026 年AI 应用开发的一个明显趋势是单模型能力竞赛逐渐降温工程架构的比拼开始成为主流。同样一个 GPT/Claude/Qwen 级别的模型有人只能写出一个聊天 Demo有人能做出一套带权限控制、人工审批、完整日志链路的生产系统。差距不在模型而在工程。于是LangChain、LangGraph、MCP 这些工具开始浮出水面。它们不是模型而是让模型能力“安全、可控、可复用”地输出到业务系统中的工程基础设施。2. 四个核心概念先把它们放对位置很多初学者最容易犯的错是把 LangChain 和 LangGraph 当成同一类东西又搞不清 MCP 到底和 Agent 是什么关系。这里直接用一张表给出定位。概念所属层级核心解决的问题常见误解LangChain组件库提供模型调用、Prompt 管理、输出解析、记忆等基础能力以为它是一个完整的 Agent 框架LangGraph编排引擎用状态图定义 Agent 的流程、分支、循环、并行、子图以为它只是 LangChain 的一个插件MCP协议统一大模型与外部工具、数据源之间的接入方式以为它是一项模型能力Agent产品形态把模型 工具 流程 记忆组合成能独立完成任务的系统以为它只是“调用一次工具”2.1 LangChain 和 LangGraph 的区别用一个例子讲清楚LangChain 更像一个“工具箱”里面装着各种预制件PromptTemplate、LLM、OutputParser、Memory、DocumentLoader等等。你用这些预制件可以快速拼出一个能跑的 Demo但一旦需求变成“如果用户输入包含 A 就走分支一否则走分支二分支二执行完后要回到主流程继续跑”LangChain 的线性 Chain 就会迅速变得难以维护。LangGraph 换了一种思路它把整个应用描述成一张有向图。状态State整个流程中共享的数据结构。节点Node一个执行单元可以是模型调用、工具调用、普通 Python 函数。边Edge节点之间的连接关系。条件边Conditional Edge根据当前状态决定下一步走哪个节点。这种设计让它天然适合表达复杂业务流程。你可以在图里画循环而循环检测、状态回滚、并行分支都变成了图本身的能力而不是靠脆弱的 Python 控制流硬撑。最直观的区别是LangChain 强调链式调用LangGraph 强调状态机。如果你的流程是“A 到 B 到 C 到 D”两者都能做LangChain 更快如果你的流程是“根据条件决定走 C 还是 DD 结束后回到 A 重新检查”LangGraph 才是更稳的选择。2.2 MCP 到底是个什么协议MCP 全称 Model Context Protocol翻译过来是“模型上下文协议”。它的作用很像给 AI 应用装了一个通用的“USB-C 接口”。在 MCP 出现之前每个 Agent 要接外部工具都得单独写一套调用逻辑接数据库写一套数据库客户端接飞书写一套飞书 API接内部系统再写一套 HTTP 封装。工具越多代码越碎Agent 的可迁移性越差。MCP 做的事情是定义了一套统一的工具发现、调用、返回格式。MCP Server 负责把工具能力暴露出来MCP Client 负责让 Agent 以标准方式去调用工具。这样同一个 Agent 可以接入不同的 MCP Server而不同 Agent 也可以复用同一个 MCP Server。顺便说一句网上常有人问“Agent Skill 和 MCP 有什么区别”。简单理解Skill 是 Agent 的能力单元描述了 Agent 在某个细分任务上的行为模板MCP 是工具访问协议解决的是 Agent 如何与外部系统通信。一个偏行为层一个偏通信层。两者可以配合使用但定位完全不同。3. 2026 年做 Agent 开发应该先用哪套技术栈这可能是读者最关心的选型问题。我的判断非常明确如果你要从零搭一个企业级 Agent 应用优先上 LangGraph。LangChain 不需要系统学把它当“辅助工具库”即可。MCP 是必学项因为它是 Agent 工具生态的通用语言。为什么这么说因为 2026 年的 Agent 开发核心早就不是“谁能写出一个能调工具的 Demo”而是“谁能把它做成一个可控、可测、可运维的系统”。LangGraph 有明确的状态管理、支持断点续跑、支持人在回路Human-in-the-loop、支持子图复用这些特性都是 LangChain 线性 Chain 难以直接提供的。至于 LangChain它攒下的组件经验仍然有价值比如 Prompt 模板、输出解析器、文档加载器。你完全可以在 LangGraph 的某个节点内部继续使用 LangChain 组件二者并不排斥。选型建议可以总结成一句话如果目标是快速验证一个点子用 LangChain 拼如果目标是做生产系统用 LangGraph 编排用 LangChain 组件辅助用 MCP 接工具。4. 环境准备与基础安装本文示例假设你在一个干净的 Python 3.10 或更高版本环境里操作。具体版本以实际项目为准但建议使用虚拟环境避免污染全局 Python。python -m venv .venv source .venv/bin/activate # Windows 用户请使用 .venv\Scripts\activate接下来安装核心依赖pip install langchain langgraph langchain-openai mcp补充说明如果你用的是 OpenAI 兼容接口的模型目前国内主流模型和本地部署模型大多支持langchain-openai这个包可以通过设置base_url来连接不同服务不需要改代码逻辑。配置环境变量。新建.env文件OPENAI_API_KEYyour-api-key OPENAI_API_BASE_URLhttps://your-model-endpoint如果你在局域网内部署模型还要注意两个细节模型响应延迟通常远高于 OpenAI 官方接口LangGraph 中要合理设置超时时间。并发能力有限时不要把 Agent 的并行分支开得太大否则容易把模型服务打满。下面验证安装是否成功from langchain_openai import ChatOpenAI llm ChatOpenAI( modelyour-model-name, api_keyyour-api-key, base_urlhttps://your-model-endpoint ) result llm.invoke(你好请回复模型连接成功) print(result.content)这一段跑通后再往下学 LangGraph 编排。5. LangGraph 核心机制拆解状态、节点、边LangGraph 和普通 LangChain 最大的不同在于你的大脑要从“线性思维”切换到“图思维”。5.1 State一切共享数据的容器在 LangGraph 中State 是一个 TypedDict 或者 Pydantic BaseModel是整个流程中所有节点共享的数据结构。每个节点执行完返回的字段会更新到 State 里。from typing import Annotated, TypedDict from langgraph.graph.message import add_messages class AgentState(TypedDict): messages: Annotated[list, add_messages] next_action: str order_count: int这里用到了Annotated[list, add_messages]它告诉 LangGraph当多个节点往messages字段追加内容时使用列表拼接而不是覆盖。5.2 Node 和 Edge把流程画出来节点可以是一个简单的 Python 函数。函数的输入是当前 State输出是更新后的 State 片段。用代码演示一个最简单的“检测 - 分析 - 总结”流程from langgraph.graph import StateGraph, START, END def detect_node(state: AgentState): # 模拟检测逻辑 return {next_action: normal} def analysis_node(state: AgentState): # 模拟分析逻辑 return {order_count: 100} def summary_node(state: AgentState): # 模拟总结逻辑 return {messages: [{role: assistant, content: f处理完成订单数 {state[order_count]}}]} graph StateGraph(AgentState) graph.add_node(detect, detect_node) graph.add_node(analysis, analysis_node) graph.add_node(summary, summary_node) graph.add_edge(START, detect) graph.add_edge(detect, analysis) graph.add_edge(analysis, summary) graph.add_edge(summary, END) app graph.compile()可以看到LangGraph 的写法就是把 Node 和 Edge 搭成一张图最后compile()编译成可执行应用。这张图既能被测试也能被可视化不过本文不展开可视化。5.3 条件路由让 Agent 自己决定下一步真实业务里几乎不存在一条直线走到底的流程。条件路由Conditional Edge是 LangGraph 必学点。from langgraph.graph import StateGraph, START, END def check_node(state): # 模拟判断 order_count state.get(order_count, 0) return {order_count: order_count} def high_volume_node(state): return {messages: [{role: assistant, content: 订单量高需要重点关注}]} def normal_volume_node(state): return {messages: [{role: assistant, content: 订单量正常无需处理}]} def route_by_order_count(state): if state.get(order_count, 0) 1000: return high_volume return normal_volume graph StateGraph(AgentState) graph.add_node(check, check_node) graph.add_node(high_volume, high_volume_node) graph.add_node(normal_volume, normal_volume_node) graph.add_edge(START, check) graph.add_conditional_edges( check, route_by_order_count, { high_volume: high_volume, normal_volume: normal_volume } ) graph.add_edge(high_volume, END) graph.add_edge(normal_volume, END)这里的关键是route_by_order_count返回一个字符串 keymapping字典再根据这个 key 找到下一个节点。如果你发现 Agent 总是走到错误的节点优先检查这个函数里的判断条件。5.4 循环和循环检测图结构天然支持但要防死循环LangGraph 支持循环节点。最简单的循环是一个节点处理完后通过条件边回到处理前的节点反复迭代。这在 Agent 多轮反思、自我修正的场景中很有用。但循环也带来风险如果终止条件写错Agent 可能无限执行下去。因此建议在每个执行单元里设置最大迭代次数。class AgentState(TypedDict): messages: Annotated[list, add_messages] iteration: int max_iterations: int 5 def reflect_node(state: AgentState): iteration state.get(iteration, 0) 1 if iteration state[max_iterations]: return {messages: [{role: assistant, content: 已到达最大迭代次数停止}], iteration: iteration} # 模拟反思处理 return {iteration: iteration} def route_after_reflect(state): if state[iteration] state[max_iterations]: return end return continue这类显式的终止条件是生产环境 Agent 的保命配置。宁可少跑一轮也不能让它无限循环。6. MCP 接入让 Agent 获得实时数据与工具能力前面我们说的 Agent 还只能调本地函数。真正的企业级场景Agent 必须能连接数据库、内部 API、消息系统等外部工具。这就是 MCP 的舞台。6.1 MCP Server 最小示例先用 FastMCP 写一个最简单的 MCP Server。假设我们提供一个订单查询工具from mcp.server.fastmcp import FastMCP mcp FastMCP(order-service) mcp.tool() def get_order_count(region: str) - str: 查询指定区域的订单数量示例为模拟数据 # 真实项目里这里会去查数据库或调用订单中心 API mock_data { 华东: 1580, 华南: 860, 华北: 920 } count mock_data.get(region, 0) return f{region} 区域当前订单量{count} if __name__ __main__: mcp.run()这段代码的核心是mcp.tool()装饰器。它把一个 Python 函数暴露成一个符合 MCP 协议的工具函数签名和 docstring 会被 MCP 自动整理成工具描述供大模型识别。6.2 LangGraph 中调用 MCP 工具的接线方式在 LangGraph 的某个 Node 里我们需要启动一个 MCP Client把 MCP 工具拉回来再转换为 LangChain 可用的 Tool 格式。这里给出一个通用的接线示意from mcp import ClientSession, StdioServerParameters from mcp.client.stdio import stdio_client from langchain_mcp_adapters.tools import load_mcp_tools # 这里的 server.py 就是上面 MCP Server 的文件 server_params StdioServerParameters( commandpython, args[mcp_server_order.py] ) async def call_order_tool(query: str): async with stdio_client(server_params) as (read, write): async with ClientSession(read, write) as session: await session.initialize() tools await load_mcp_tools(session) # 将 tools 交给 Agent 节点使用 return tools注意MCP 的 stdio 通信方式启动了一个子进程生产环境里要充分评估它带来的部署复杂度。如果要接入远程 MCP Server官方也提供 Streamable HTTP 等传输方式但配置会更复杂建议先跑通本地再上远程。6.3 为什么 MCP 能让“工具生态”活起来传统开发中每个 Agent 都要为每一个工具写一套调用代码而 MCP 把工具调用标准化了。这意味着同一个 MCP Server 可以被不同 Agent 复用。同一个 Agent 可以按需动态发现并挂载新的 MCP Server。前端设计工具可以暴露成 MCP数据库可以暴露成 MCP内部系统可以暴露成 MCPAgent 的应用边界一下子打开了。这也是为什么现在很多工具链都在做 MCP 支持。它本质上是在重新定义 Agent 和工具之间的连接标准。7. 完整示例一个带工具调用的企业级 Agent前面把概念拆开了现在把它们组装起来。这个示例的目标是一个企业级工单查询助手它接收用户输入判断是否需要查询订单数据工具然后根据查询结果生成回复。整个流程用 LangGraph 编排MCP 负责提供订单工具同时加入记忆机制。7.1 定义 Statefrom typing import Annotated, TypedDict from langgraph.graph.message import add_messages class AgentState(TypedDict): messages: Annotated[list, add_messages] need_tool: bool final_answer: str7.2 创建带记忆的 LangGraph Agent这里使用MemorySaver保存会话状态让 Agent 能记住历史消息。在生产环境中你可以将 MemorySaver 替换为 Redis 或数据库存储。from langgraph.graph import StateGraph, START, END from langgraph.checkpoint.memory import MemorySaver from langchain_openai import ChatOpenAI from langchain_core.tools import tool from langgraph.prebuilt import ToolNode # 模拟一个订单查询工具真实场景中可以从 MCP Server 获取 tool def query_order_count(region: str) - str: 根据区域查询订单数量支持华东、华南、华北。 data {华东: 1580, 华南: 860, 华北: 920} count data.get(region, 0) return f{region} 区域当前订单量为 {count} tools [query_order_count] llm ChatOpenAI( modelyour-model-name, api_keyyour-api-key, base_urlhttps://your-model-endpoint ) llm_with_tools llm.bind_tools(tools) def should_use_tool(state: AgentState): 判断是否需要调用工具 last_message state[messages][-1] if last_message.tool_calls: return tools return respond def agent_node(state: AgentState): Agent 决策节点决定是调用工具还是直接回答 result llm_with_tools.invoke(state[messages]) return {messages: [result]} def respond_node(state: AgentState): 根据工具结果生成最终回复 last_message state[messages][-1] return {final_answer: last_message.content} graph StateGraph(AgentState) graph.add_node(agent, agent_node) graph.add_node(tools, ToolNode(tools)) graph.add_node(respond, respond_node) graph.add_edge(START, agent) graph.add_conditional_edges( agent, should_use_tool, { tools: tools, respond: respond } ) graph.add_edge(tools, agent) graph.add_edge(respond, END) checkpointer MemorySaver() app graph.compile(checkpointercheckpointer) config {configurable: {thread_id: customer-service-001}}这段代码是整个教程最核心的部分也是 LangGraph Tool 调用 记忆的标准骨架。当你跑通它之后后续加 MCP 工具、加多节点、加人工审批都只是在这个骨架上做扩展。user_input 帮我查一下华东区的订单量 result app.invoke( {messages: [{role: user, content: user_input}]}, configconfig ) print(result[final_answer])第二轮提问时因为同一个thread_id下的记忆还在Agent 会记得刚才查过华东区订单量user_input2 那华南呢 result2 app.invoke( {messages: [{role: user, content: user_input2}]}, configconfig )这就是记忆的价值Agent 不需要每次都得用户把上下文重新说一遍。8. 运行结果与效果验证运行上面代码你应该能看到类似下面的输出Agent 第一次决策调用工具 工具返回华东 区域当前订单量为 1580 Agent 最终回复华东区域当前订单量为 1580 单。判断是否成功可以按这个顺序检查模型有没有发起工具调用如果 Agent 忽略了工具直接回答“我无法查询”问题大概率出在模型对工具描述的理解上可以优化tool里的 docstring。ToolNode 有没有真正执行在工具函数里加一行print(tool executed:, region)确认工具节点被触发。最终回复是否正确引用工具结果如果 Agent 给出了和工具结果不一致的数字检查 Prompt 或模型输出解析逻辑。如果第一轮就失败优先看 LLM 的调用日志和 LangGraph 的节点执行顺序不要急着改代码。先定位是“模型没调工具”还是“工具执行抛异常”。9. 常见问题与排查思路问题现象可能原因排查方式解决方案pip 安装 langgraph 时报依赖冲突langchain 和 langgraph 版本不兼容pip list查看已安装版本pip check检查依赖统一升级到最新稳定版本避免混装老版本Agent 启动后不调用任何工具Prompt 中没有明确工具使用规则或模型版本不支持 function calling打印模型返回的完整消息对象确认tool_calls字段是否为空优化工具描述或更换支持工具调用的模型Agent 调用工具超时报the agent execution provider did not respond in time模型服务响应太慢或 MCP Server 启动时间过长检查模型服务和 MCP Server 的日志测量接口响应耗时增加超时时间为 MCP Server 增加预热机制MCP Server 连接失败stdio 子进程启动失败或参数配置错误先单独运行python mcp_server_order.py看是否报错检查 Python 环境和依赖确认 MCP 服务可独立启动LangGraph 节点反复执行陷入死循环条件路由的终止条件写错或循环节点缺少迭代上限在路由函数里打印当前 State 的迭代字段显式设置max_iterations并在达到上限后强制END多轮对话中记忆丢失未配置 checkpointer或thread_id不固定检查compile()是否传入 checkpointer使用MemorySaver或替换为 Redis/数据库存储并固定thread_id工具返回的字段无法被模型正确解析工具返回结构复杂超出了模型的解析能力打印模型最终回复对比工具返回原文让工具返回结构化 JSON并在 Prompt 中说明字段含义10. 最佳实践与生产建议10.1 先画图再写代码LangGraph 最大价值的背后是它逼着你先把流程想清楚。强烈建议在写代码之前用一张白纸画出有哪些节点。每个节点需要读哪些 State 字段、输出哪些字段。哪些地方有分支哪些地方有循环。哪些步骤允许 Agent 自主决策哪些步骤必须人工确认。画不清楚的流程写出来的代码一定乱。10.2 工具返回必须结构化企业级 Agent 的工具返回不要用大段文本尽量使用 JSON。结构化数据便于模型解析也便于输出校验和日志审计。{ region: 华东, order_count: 1580, alert_level: high, unit: 单, timestamp: 2026-05-20T10:30:00Z }10.3 大模型擅长判断但不擅长精确计算不要让模型自己做订单量加总、金额计算。这类操作交给 Python 函数或 SQL 完成模型只负责解析用户意图和生成最终文案。这样既提高准确率也降低模型幻觉风险。10.4 安全边界与最小权限原则这一点值得单独强调。Agent 一旦能调用工具就意味着它拥有了访问外部系统的能力。必须遵循以下原则每个工具只授予完成该任务所需的最小权限不要使用管理员账号。涉及删除、修改、审批、转账等高风险操作时保留人工智能身份验证和人工审批环节。工具的 API Key 和敏感配置放在密钥管理系统中不能硬编码在代码里。生产环境开启完整日志链路记录每一次工具调用的入参、出参和耗时。10.5 引入可观测性体系LangGraph 应用可以接入 LangSmith 或自行打点记录每个节点的输入输出、执行耗时、模型 token 消耗。没有可观测性的 Agent 系统在生产环境等于盲飞。如果团队还没有这套能力先从简单的结构化日志开始至少保证每个节点执行时有明确的 traceId。10.6 提供合理的并发与超时配置在compile()之后的调用里要根据模型能力来设计并发分支数量。本地模型并发能力弱就应串行执行或减小并行度外部 API 响应不稳定就应设置合理的超时和重试策略。这里最稳妥的路线是先小流量压测再逐步放量。11. 总结与后续学习方向这篇文章真正想讲清楚的不是某一行代码的写法而是 Agent 开发中的一个底层坐标系LangChain 提供组件LangGraph 提供编排MCP 提供工具协议Agent 是它们组合出来的产品形态。学任何一门教程时先问自己当前内容属于哪一层我缺的是组件能力、编排能力还是工具接入能力把这个问题想清楚学习效率会高出很多。如果要说学习路径我的建议是先用 LangGraph 手写一个最简单的带工具调用的 Agent把 State、Node、Edge、条件路由全部跑通。再用 MCP 把第二个外部工具接进来体会“工具标准化”带来的开发效率提升。接着给 Agent 加记忆和人工审批节点理解企业级应用为什么需要 checkpointer 和 Human-in-the-loop。最后把应用接到真实数据库和内部 API 上引入可观测性和权限控制体系。不用急着追每一个新概念。Agent 应用的核心复杂度在工程侧不在模型侧。你能把“可控编排 工具协议 可观测”这条线打通就已经超越了大多数停留在 Demo 阶段的团队。这也是“从入门到实战”真正要跨过的门槛。