很多开发者第一次接触 Agent 开发时最容易陷入一种“貌似懂了一跑就废”的状态。你照着网上的 Demo 复制了一段代码模型也确实启动了工具也注册了但真正到了现场演示或者接进业务系统时Agent 要么不调用工具要么多轮对话后状态错乱要么换一个模型就要重写整条链路。2026 年这个时间节点Agent 开发的门槛已经不在大模型本身——模型能力早已高度同质化真正的分水岭在于你能否把 Agent 当作一个有状态、可控制、工具标准化的工程系统来设计。这篇文章不会带你复读一遍官方文档而是从工程落地视角重新梳理 LangChain、MCP、LangGraph 和 Agent 之间的关系。先说结论LangChain 负责提供工具和编排的“积木”MCP 负责把外部工具变成统一接口LangGraph 负责让 Agent 具备状态、分支、循环和恢复能力而 Agent 本身则是“模型决策 工具执行 观察结果”的循环系统。读完这篇文章你会清楚它们各自解决什么问题、什么项目该用哪套组合、如何从零跑通一个带工具调用的真实 Agent以及生产环境里最容易踩的坑在哪里。1. Agent 开发最容易翻车的三个地方先聊一个观察。过去两年我见到大量 Agent 项目Demo 阶段效果惊艳进入测试或者生产环境就原形毕露。问题往往不是模型选得不好而是开发者在架构层面犯了三个非常典型的错误。第一个错误是把 Agent 当成一次普通的模型调用。很多人理解的 Agent 就是“大模型 工具列表”实际写代码时也只是在用户提问后调用一次模型让模型返回一段 JSON 格式的 tool_calls然后就结束了。真正的 Agent 是一个循环系统模型先决定要不要调用工具系统执行工具返回结果模型再根据结果继续推理直到它认为任务完成。开发者一旦漏掉这个循环Agent 就只能做“一次思考”无法处理需要多步工具协作的复杂任务。这也是为什么很多 Agent 项目遇到数学计算、多轮检索就崩溃。第二个错误是完全忽略状态管理。Agent 一旦进入多轮对话或者多步骤任务就必须管理消息历史、中间结果、已执行工具和当前进度。你用全局变量临时凑合时短期跑通没问题一旦接入 Web 服务、异步任务或者多人会话状态错乱几乎是必然的。LangGraph 这类图编排框架之所以在 2025 年之后迅速成为 Agent 开发的事实标准本质上就是因为它在框架层面内置了状态对象、检查点机制和循环控制让开发者不用自己手写一套状态机。第三个错误是工具接入没有统一标准。每个新工具都要为 Agent 写一套适配代码不同 Agent 框架之间的工具定义互不兼容。你为 A 项目写了天气查询工具换个项目想复用发现签名、描述格式、鉴权方式全都对不上。MCPModel Context Protocol解决的就是这个痛点它把工具调用抽象成标准协议让 Agent 与工具之间有了类似“USB-C 接口”的统一插口。如果你正在摸索 Agent 开发或者已经踩过上述某一个坑这篇文章就是按“概念 → 选型 → 实操 → 排错 → 最佳实践”的顺序帮你把整条链路跑通的。2. LangChain、LangGraph、MCP、Agent 到底是什么关系在进入代码之前先把四个概念的关系彻底理清。很多新手的困惑在于LangChain 和 LangGraph 都是 LangChain 生态的东西为什么还要区分MCP 又从哪里冒出来的可以这样理解LangChain 是一个 AI 应用开发的“工具箱和积木库”。它封装了模型调用、Prompt 模板、文档加载、向量存储、工具调用链Chain等常用组件。它的核心价值是让你用统一的 API 去对接不同模型同时把“拿文档检索、拼接 Prompt、调模型、拿输出”这类常见流程变成标准化模块。对于 RAG 应用、简单的链式任务、快速原型验证LangChain 是非常顺手的。LangGraph 则是基于图模型的 Agent 编排引擎由 LangChain 团队推出但它解决的是 LangChain 原本不擅长的场景有状态的复杂工作流。你可以把 LangGraph 想象成一个“工作流状态机”开发者定义节点Node和边EdgeAgent 在图里流动每一步都能读写共享状态并且天然支持循环、分支、暂停恢复。一个 Agent 要完成“检索资料 → 写报告 → 调用工具核对数据 → 修改报告”这种多步骤任务用 LangGraph 来表达远比用一条线性 Chain 要清晰。MCP 是另一层的东西它不关心你用什么编排框架只关心“AI 应用怎么和外部工具对话”。在 MCP 出现之前每个 Agent 框架都要自定义工具协议每个工具接入方也要按不同框架各写一套。MCP 的思路是把工具服务化工具提供方实现一个 MCP Server暴露统一的工具列表和调用接口AI 应用作为 MCP Client 通过标准协议调用。底层传输走 JSON-RPC支持本地 stdio 和远程 HTTP整个设计借鉴了 IDE 的 Language Server Protocol所以它也被很多人称为“AI 应用的 LSP”。最后是 Agent。Agent 不是具体某个框架而是一种程序模式大模型作为“决策大脑”根据用户目标和当前状态决定调用哪些工具、以什么顺序调用然后观察工具返回值并继续推理直到目标完成。它和传统程序的本质区别在于控制流不再由开发者硬编码而是由模型根据上下文动态决定。四者关系总结如下表组件核心解决的问题类比LangChain提供模型封装、Prompt、文档处理、工具等基础组件工具箱LangGraph提供有状态的图执行引擎支持循环、分支、记忆工作流状态机MCP统一 AI 应用与外部工具之间的通信协议USB-C 标准接口Agent由模型驱动的“决策-执行-观察”循环模式员工或自动驾驶系统一句话概括它们的关系LangChain 提供工具包MCP 统一工具插口LangGraph 决定 Agent 怎么跑模型决定 Agent 怎么想。2026 年主流的 Agent 工程架构基本就是“LangGraph MCP 任意模型”的组合LangChain 更多作为组件库参与其中。3. 选型判断什么项目用 LangChain什么项目用 LangGraph不是所有项目都需要一上来就上 LangGraph。搞清楚选型边界比学会 API 更重要。如果你的需求是一条比较固定的链路比如“用户问题 → 检索知识库 → 拼接 Prompt → 生成回答”或者只是给现有系统加一个智能问答接口LangChain 的 Chain 模式足够。它的优点是上手快、代码直观、社区案例多一个几百行的脚本就能完成。团队如果刚接触 AI 开发用 LangChain 做第一个内部工具是性价比最高的路径。如果你要构建一个真正的 Agent 系统问题就复杂了。真正的 Agent 意味着模型可能要做多次推理、多次工具调用可能在不同分支之间切换可能需要在关键节点暂停等待人工审批还可能因为异常中断需要在恢复后续跑。这时候线性 Chain 无法描述控制流你需要一个图执行引擎——LangGraph 是当前最成熟的选项。判断要不要用 LangGraph可以从四个维度问自己。第一流程是否存在分支。比如根据意图走不同处理路径有的问题需要调数据库有的问题只需要大模型直接回答。第二是否需要循环。比如“生成内容 → 工具校验 → 不合格就重新生成”这种循环逻辑在 Chain 里很难优雅表达。第三是否有状态恢复和人工干预需求。生产级系统经常要把某个节点暂停等人确认后再继续。第四是否有多智能体协作。多个 Agent 分别负责不同子任务相互传递状态这基本上是 LangGraph 的舒适区。另外还要注意LangGraph 并非要取代 LangChain它本身就是 LangChain 生态的一部分内部大量复用 LangChain 的模型封装、消息类和工具抽象。两者不是替代关系而是上下层关系用 LangGraph 编排流程用 LangChain 组件处理模型和工具细节这是 2026 年最普遍的组合。除了框架本身还有一个重要的选型思考Agent 控制面要不要和业务系统解耦。如果你做的是企业级应用Agent 不是孤立存在的它需要对接权限系统、审批流、监控告警。LangGraph 的 StateGraph 天然适合这种场景因为它把执行过程变成了可观测、可控制的图节点之间的状态流转可以记录、追踪、审计这一点是普通脚本式 Agent 根本无法做到的。4. 环境准备与依赖安装开始写代码前先准备一个干净的 Python 环境。建议使用 Python 3.10 及以上版本推荐 3.11 或更高因为新版本对类型注解和异步支持更完整。下面按虚拟环境 依赖安装 环境变量配置三步走。mkdir langgraph-agent-demo cd langgraph-agent-demo python -m venv .venv source .venv/bin/activate # Windows 使用 .venv\Scripts\activate激活虚拟环境后安装核心依赖。这里不锁定具体版本号因为 LangChain、LangGraph 和 MCP 的版本迭代很快项目应以你当前安装到的最新稳定版为准。如果遇到版本冲突可以按第 8 节的排查思路处理。pip install langchain langchain-openai langgraph mcp依赖安装完成后配置模型访问。篇幅原因示例代码统一使用 OpenAI 风格的 API。如果你的模型服务是兼容 OpenAI 接口的国内大模型只需额外设置 base_url 即可Agent 代码无需任何改动。export OPENAI_API_KEYyour-api-key export OPENAI_BASE_URLhttps://your-model-endpoint # 使用兼容 OpenAI 接口的服务时设置执行完上述步骤可以快速验证环境是否正常。运行 python -c import langchain, langgraph, mcp; print(env ok) 如果没有报错说明基础依赖装好了。接下来分别用 LangChain 和 LangGraph 各实现一个 Agent 示例对比两者的写法和适用场景。5. LangChain 实战20分钟跑通第一个带工具的 Agent这一节先用 LangChain 快速实现一个能调用工具的 Agent。我们做一个简单的“天气查询 简单计算”助手让模型自主判断用户问题是否需要调用工具。在项目目录下新建weather_agent.py代码如下# 文件路径weather_agent.py from langchain_openai import ChatOpenAI from langchain_core.tools import tool from langchain.agents import create_tool_calling_agent, AgentExecutor from langchain_core.prompts import ChatPromptTemplate tool def get_city_weather(city: str) - str: 查询指定城市的当前天气情况。输入应为城市名称例如北京、上海。 # 演示环境返回模拟数据生产环境应接入真实天气 API weather_map { 北京: 晴最高温度 26℃东北风 2 级空气质量良。, 上海: 多云最高温度 24℃东风 3 级空气质量优。, } return weather_map.get(city, f暂无 {city} 的天气数据请核实城市名称。) tool def calculate(expression: str) - str: 计算简单的数学表达式。输入应为标准数学表达式例如12 * 7 5。 # 演示环境使用 eval生产环境必须做安全校验不允许直接执行用户输入 return str(eval(expression)) model ChatOpenAI(modelgpt-4o-mini, temperature0) tools [get_city_weather, calculate] prompt ChatPromptTemplate.from_messages([ (system, 你是一个智能助手可以根据用户问题调用工具获取信息。), (human, {input}), (placeholder, {agent_scratchpad}), ]) agent create_tool_calling_agent(model, tools, prompt) executor AgentExecutor(agentagent, toolstools, verboseTrue) if __name__ __main__: result executor.invoke({input: 北京的天气怎么样另外帮我计算 12 * 7 5 的结果。}) print(回答, result[output])这段代码的关键逻辑有四处。第一tool装饰器把普通函数变成 LangChain 工具函数的 docstring 会作为工具描述传给模型模型据此判断何时该调用该工具所以描述一定要写清楚输入格式和用途。第二create_tool_calling_agent接收支持 tool calling 的模型内部会把工具列表传给模型如果模型不支持原生 tool calling这个函数会报错。第三Prompt 模板中的{agent_scratchpad}占位符专门存放中间推理步骤和工具调用结果这是 Agent 循环能够持续的依据。第四AgentExecutor负责执行循环——调用模型、解析工具调用、执行工具、把结果写回 scratchpad、再次调用模型直到模型不再请求工具为止。运行方式很简单python weather_agent.py预期会看到类似如下的输出 Entering new AgentExecutor chain... Invoking: get_city_weather with {city: 北京} 北京晴最高温度 26℃东北风 2 级空气质量良。 Invoking: calculate with {expression: 12 * 7 5} 89 Finished chain. 回答北京的天气是晴天最高气温 26℃。12 * 7 5 的结果是 89。如果你看到 Agent 一次性调用了两个工具并给出最终回答说明 Agent 循环已经跑通。这里最值得关注的是日志里的Invoking过程——它证明了模型确实在自主决策调用工具而不是只凭幻觉回答。很多新手在这一步会遇到一个典型问题Agent 完全不调用工具直接凭模型记忆回答。排查思路很简单优先检查工具描述是否足够清晰模型是否有 tool calling 能力以及是否使用了支持 bind_tools 的模型封装。关于这个问题的详细排查见第 8 节的表格。6. LangGraph 实战把 Agent 做成有状态、可恢复的图LangChain 的 AgentExecutor 适合快速验证但它的循环逻辑是一个黑盒状态存在内存里没有持久化能力没有跨分支控制也没有人工审批节点。当你的 Agent 需要进入生产环境时LangGraph 会是更稳妥的选择。LangGraph 的核心概念是 StateGraph你定义共享的 State 类型定义若干个 Node节点再定义节点之间的 Edge边Agent 执行就是一个在图里流动的过程。这样整个 Agent 的执行路径完全可视化状态流转可控并且天然支持循环。下面用 LangGraph 重写上一个示例并加上多轮对话记忆。代码文件命名为weather_agent_graph.py# 文件路径weather_agent_graph.py from typing import TypedDict, Annotated from langchain_openai import ChatOpenAI from langchain_core.tools import tool from langgraph.graph import StateGraph, START, END from langgraph.graph.message import add_messages from langgraph.prebuilt import ToolNode, tools_condition from langgraph.checkpoint.memory import MemorySaver tool def get_city_weather(city: str) - str: 查询指定城市的当前天气情况。输入应为城市名称例如北京、上海。 weather_map { 北京: 晴最高温度 26℃东北风 2 级空气质量良。, 上海: 多云最高温度 24℃东风 3 级空气质量优。, } return weather_map.get(city, f暂无 {city} 的天气数据请核实城市名称。) tool def calculate(expression: str) - str: 计算简单的数学表达式。输入应为标准数学表达式例如12 * 7 5。 # 演示环境使用 eval生产环境必须做安全校验 return str(eval(expression)) tools [get_city_weather, calculate] model ChatOpenAI(modelgpt-4o-mini, temperature0).bind_tools(tools) class AgentState(TypedDict): messages: Annotated[list, add_messages] def call_model(state: AgentState): response model.invoke(state[messages]) return {messages: [response]} graph_builder StateGraph(AgentState) graph_builder.add_node(agent, call_model) graph_builder.add_node(tools, ToolNode(tools)) graph_builder.add_edge(START, agent) graph_builder.add_conditional_edges(agent, tools_condition) graph_builder.add_edge(tools, agent) checkpointer MemorySaver() graph graph_builder.compile(checkpointercheckpointer) if __name__ __main__: config {configurable: {thread_id: demo-thread-1}} print( 第一轮提问 ) result1 graph.invoke( {messages: [(human, 北京的天气怎么样)]}, configconfig, ) print(result1[messages][-1].content) print(\n 第二轮提问携带上文记忆 ) result2 graph.invoke( {messages: [(human, 刚才问的是哪个城市顺便帮我算 3 * 14 等于多少)]}, configconfig, ) print(result2[messages][-1].content)这段代码比 LangChain 版本复杂不少但每一步都有明确职责。AgentState定义了图的全局状态这里使用消息列表作为状态并标注add_messages表示每次节点返回值都会追加到已有消息列表而不是覆盖。call_model是核心节点函数它接收当前状态、调用模型、把模型返回追加到消息列表。ToolNode是 LangGraph 预置的工具执行节点会自动读取模型输出中的 tool_calls 并执行对应工具。tools_condition是预置的边路由函数它的逻辑是如果模型最后一条消息包含工具调用请求就走tools节点否则任务完成走END。MemorySaver是最值得关注的部分。它把每一步图执行状态持久化到内存检查点并绑定thread_id。这意味着只要使用相同的 thread_idAgent 就能“记住”上一轮对话的所有消息。这个能力在 LangChain 的 AgentExecutor 里需要自己管理而 LangGraph 把记忆直接做进了执行引擎。运行结果应该类似 第一轮提问 北京市今天晴最高气温 26℃。 第二轮提问携带上文记忆 你刚才问的是北京。3 * 14 等于 42。关键点在于第二轮回答中Agent 准确记得第一轮问的是“北京”。这说明thread_id对应的会话状态在两次 invoke 之间被正确保存和读取。如果没有记忆模型根本无法回答“刚才问的是哪个城市”。这个示例虽然短但已经体现出了 LangGraph 相对 LangChain 的三个核心优势状态共享、循环可控、记忆持久化。后续你要加人工审批节点、多智能体协作、断点恢复都是在现有图结构上增加节点和边而不是推倒重写。7. MCP 实战一次实现让 Agent 连接到真实世界LangChain 和 LangGraph 解决了 Agent 内部的编排和状态问题但还有一个问题悬而未决Agent 要调用的工具从哪来如果每个工具都要用 Python 函数硬编码在代码里那么每接入一个新系统就要改代码、发版、联调。MCP 的出现改变了这个局面。可以把 MCP 理解为 AI 应用的工具标准化协议。工具提供方实现一个 MCP Server 并暴露工具列表Agent 应用作为 MCP Client 连接并动态发现工具然后按统一协议调用。这样工具和 Agent 完全解耦一个企业内部服务只需要实现一次 MCP Server就能被所有兼容 MCP 的客户端使用包括 Claude Desktop、Cursor、你自研的 LangGraph Agent以及许多主流 IDE 工具。先看服务端。用 MCP 官方 Python SDK 的 FastMCP 高层封装写一个最小工具服务代码文件命名为weather_mcp_server.py# 文件路径weather_mcp_server.py from mcp.server.fastmcp import FastMCP mcp FastMCP(demo-server) mcp.tool() def get_city_weather(city: str) - str: 查询指定城市的当前天气情况。输入应为城市名称例如北京、上海。 weather_map { 北京: 晴最高温度 26℃东北风 2 级空气质量良。, 上海: 多云最高温度 24℃东风 3 级空气质量优。, } return weather_map.get(city, f暂无 {city} 的天气数据请核实城市名称。) mcp.tool() def calculate(expression: str) - str: 计算简单的数学表达式。输入应为标准数学表达式例如12 * 7 5。 # 演示环境使用 eval生产环境必须做安全校验 return str(eval(expression)) if __name__ __main__: mcp.run(transportstdio)这段代码把之前定义的两个 Python 函数直接暴露成 MCP 工具。FastMCP帮开发者屏蔽了协议的底层细节你只需要关注工具函数本身的实现。传输方式使用stdio也就是客户端以子进程方式启动服务端通过标准输入输出交换数据适合本地场景。再看客户端。下面用 MCP 官方 SDK 连接上面这个 Server动态获取工具列表并调用get_city_weather# 文件路径mcp_client_demo.py import asyncio from mcp import ClientSession, StdioServerParameters from mcp.client.stdio import stdio_client async def main(): server_params StdioServerParameters( commandpython, args[weather_mcp_server.py], ) async with stdio_client(server_params) as (read, write): async with ClientSession(read, write) as session: await session.initialize() tools await session.list_tools() print( MCP Server 暴露的工具 ) for tool in tools.tools: print(f- {tool.name}: {tool.description}) result await session.call_tool( get_city_weather, arguments{city: 上海}, ) print(\n 调用 get_city_weather 的结果 ) for content in result.content: print(content.text) if __name__ __main__: asyncio.run(main())这是一个非常标准的 MCP Client 调用流程启动子进程连接 Server → 初始化会话 → 列出工具 → 调用工具。运行后预期输出会打印出两个工具的名字和描述然后返回上海的天气信息。你可能会问MCP 这里展示的明明只是把 Python 函数包装了一层价值在哪里价值在于工具与系统的解耦。刚才写的weather_mcp_server.py本身就是一个独立的进程它可以运行在任意机器上通过任意语言实现。你的 Agent 只需要知道它的地址和协议就能像插拔 U 盘一样接入工具。更重要的是这项工作正在形成生态。2025 年到 2026 年MCP 的接入范围已经扩展到游戏引擎、设计协作平台、桌面应用、仿真软件、数据库运维等领域Cursor、Claude Desktop 等客户端均原生支持 MCP。对开发者来说现在为一个系统封装 MCP Server等于让它在整个 AI 工具生态中“一次接入处处可用”。MCP 协议本身涉及初始化握手、工具列表、调用请求、错误处理等环节底层基于 JSON-RPC 2.0。这篇教程先通过 FastMCP 帮助你跑通最小链路等进入生产级工具开发后再深入协议细节不迟。8. 常见问题与排查思路Agent 开发中遇到问题时最忌讳盲目改代码。下面按“问题现象 → 可能原因 → 排查方式 → 解决方案”的维度整理五个最高频的问题。问题现象可能原因排查方式解决方案Agent 不调用工具直接凭记忆回答工具描述不清晰或模型不支持原生 tool calling打印模型输出查看是否返回 tool_calls检查工具 docstring重写工具描述明确输入格式和适用场景确认模型支持 tool callingAgent 调用工具后不继续处理对话中断工具返回结果后没有回到 agent 节点图缺少环检查 LangGraph 边配置确认tools节点之后有指向agent的边在状态图中添加graph_builder.add_edge(tools, agent)Agent 进入死循环反复调用同一个工具工具返回内容未改变模型状态模型无法判断任务完成开启详细日志查看每轮模型输出与工具返回值限制最大迭代步数拆分子任务为工具增加明确结束条件MCP Server 启动后客户端连不上stdio 子进程启动失败或传输参数写错先在命令行单独运行python weather_mcp_server.py验证无报错检查 server 文件路径、Python 解释器路径和依赖环境LangGraph 多轮对话记忆丢失未使用 checkpointer或每次请求 thread_id 不同检查 compile 时是否传入 checkpointer请求 config 中 thread_id 是否固定使用MemorySaver并保证同一会话使用相同 thread_id生产环境可替换为持久化存储依赖包版本冲突langchain 和 langgraph API 对不上本地安装了多版本或过时版本运行 pip listgrep langchain 查看版本阅读报错堆栈这里面最容易被忽视的是第二个问题。用 LangGraph 写 Agent 时很多人以为加完节点就完事了忘记tools节点还要指回agent节点。严格来说这构成的是“循环依赖”但正是这个环路让 Agent 能在“推理 → 执行工具 → 再推理”之间往返直到任务完成。另外如果你在项目里同时操作 LangChain、LangGraph、MCP 三个库尽量把它们放进同一个虚拟环境管理避免全局环境污染导致的 C 扩展冲突。遇到看起来莫名其妙的 AttributeError优先怀疑依赖版本不匹配而不是代码逻辑问题。9. 生产环境最佳实践与关键提醒最后聊一聊把 Agent 从 Demo 推向生产环境时真正决定成败的几个工程细节。这一节不展开具体代码但每一条都是实践中容易踩到真金白银的部分。第一控制工具数量和描述质量。工具过多会让模型每次决策都面对庞大的 schema既增加 Token 消耗也降低选对工具的概率。生产环境要把工具数量控制在合理范围内并为每个工具写清晰、唯一的描述。工具描述不要写废话但要写清楚何时该用、何时不能用。不同的工具之间职责边界要清晰否则模型会出现“选择困难”。第二重视安全边界和最小权限。这可能是 Agent 工程里最重要也最容易被忽略的点。Agent 一旦具备调用数据库、发送邮件、操作文件系统等能力就必须在工具层做权限校验。不要把所有工具权限直接暴露给模型更不要让工具函数直接执行用户传入的原始字符串。演示代码里的eval是为了展示完整流程生产环境必须替换为安全解析器并对每个敏感操作增加人工确认节点。LangGraph 的 interrupt 机制可以很方便地实现“Agent 执行到关键步骤时暂停等待人工审批后继续”。第三日志与可观测性必须前置。Agent 的行为具有不确定性线上出了问题如果日志只记录“用户问题”和“最终回答”中间的推理链、工具调用参数、每一步状态变更全都是黑的排查会非常痛苦。建议在 LangGraph 的每个节点记录输入输出使用 LangSmith 或自建追踪系统把所有工具调用的入参、出参、耗时、Token 消耗落库。第四做好成本与执行步数控制。Agent 越智能意味着它可能越“啰嗦”一个简单问题也可能造成大量模型调用。生产环境一定要设置单次会话的最大模型调用次数、最大 Token 上限、工具调用超时时间。一旦超过阈值返回“需要人工介入”并终止执行而不是无限循环烧钱。第五预留回滚和灰度能力。Agent 依赖的模型版本、Prompt、工具定义都会持续迭代。不要在不做 A/B 的情况下直接替换生产链路。代码层面要给每个 Agent 任务打上版本号至少能在出现大规模错误时快速切回上一版本。关于 LangChain、LangGraph、MCP 和 Agent 的工程化理论和示例说再多都不如亲手跑一遍。建议你从这篇文章的最小示例出发先跑通 LangChain 版本的天气助手理解 Agent 循环然后用 LangGraph 加上记忆和状态理解图编排最后用 FastMCP 写一个自己的工具服务换一个你实际业务中真正需要被调用的系统。这三个步骤走完你就已经超越了大量停留在“调大模型接口”阶段的开发者。至于团队内部到底是自研 Agent 框架还是基于 LangGraph完全取决于你的业务形态——但无论怎么选状态管理、工具标准化和可观测性这三件事都是绕不开的基石。只有把这些工程底座打牢Agent 才会真正从“能跑 Demo”变成“能上生产”。
LangChain、LangGraph与MCP实战：构建有状态Agent的完整指南
很多开发者第一次接触 Agent 开发时最容易陷入一种“貌似懂了一跑就废”的状态。你照着网上的 Demo 复制了一段代码模型也确实启动了工具也注册了但真正到了现场演示或者接进业务系统时Agent 要么不调用工具要么多轮对话后状态错乱要么换一个模型就要重写整条链路。2026 年这个时间节点Agent 开发的门槛已经不在大模型本身——模型能力早已高度同质化真正的分水岭在于你能否把 Agent 当作一个有状态、可控制、工具标准化的工程系统来设计。这篇文章不会带你复读一遍官方文档而是从工程落地视角重新梳理 LangChain、MCP、LangGraph 和 Agent 之间的关系。先说结论LangChain 负责提供工具和编排的“积木”MCP 负责把外部工具变成统一接口LangGraph 负责让 Agent 具备状态、分支、循环和恢复能力而 Agent 本身则是“模型决策 工具执行 观察结果”的循环系统。读完这篇文章你会清楚它们各自解决什么问题、什么项目该用哪套组合、如何从零跑通一个带工具调用的真实 Agent以及生产环境里最容易踩的坑在哪里。1. Agent 开发最容易翻车的三个地方先聊一个观察。过去两年我见到大量 Agent 项目Demo 阶段效果惊艳进入测试或者生产环境就原形毕露。问题往往不是模型选得不好而是开发者在架构层面犯了三个非常典型的错误。第一个错误是把 Agent 当成一次普通的模型调用。很多人理解的 Agent 就是“大模型 工具列表”实际写代码时也只是在用户提问后调用一次模型让模型返回一段 JSON 格式的 tool_calls然后就结束了。真正的 Agent 是一个循环系统模型先决定要不要调用工具系统执行工具返回结果模型再根据结果继续推理直到它认为任务完成。开发者一旦漏掉这个循环Agent 就只能做“一次思考”无法处理需要多步工具协作的复杂任务。这也是为什么很多 Agent 项目遇到数学计算、多轮检索就崩溃。第二个错误是完全忽略状态管理。Agent 一旦进入多轮对话或者多步骤任务就必须管理消息历史、中间结果、已执行工具和当前进度。你用全局变量临时凑合时短期跑通没问题一旦接入 Web 服务、异步任务或者多人会话状态错乱几乎是必然的。LangGraph 这类图编排框架之所以在 2025 年之后迅速成为 Agent 开发的事实标准本质上就是因为它在框架层面内置了状态对象、检查点机制和循环控制让开发者不用自己手写一套状态机。第三个错误是工具接入没有统一标准。每个新工具都要为 Agent 写一套适配代码不同 Agent 框架之间的工具定义互不兼容。你为 A 项目写了天气查询工具换个项目想复用发现签名、描述格式、鉴权方式全都对不上。MCPModel Context Protocol解决的就是这个痛点它把工具调用抽象成标准协议让 Agent 与工具之间有了类似“USB-C 接口”的统一插口。如果你正在摸索 Agent 开发或者已经踩过上述某一个坑这篇文章就是按“概念 → 选型 → 实操 → 排错 → 最佳实践”的顺序帮你把整条链路跑通的。2. LangChain、LangGraph、MCP、Agent 到底是什么关系在进入代码之前先把四个概念的关系彻底理清。很多新手的困惑在于LangChain 和 LangGraph 都是 LangChain 生态的东西为什么还要区分MCP 又从哪里冒出来的可以这样理解LangChain 是一个 AI 应用开发的“工具箱和积木库”。它封装了模型调用、Prompt 模板、文档加载、向量存储、工具调用链Chain等常用组件。它的核心价值是让你用统一的 API 去对接不同模型同时把“拿文档检索、拼接 Prompt、调模型、拿输出”这类常见流程变成标准化模块。对于 RAG 应用、简单的链式任务、快速原型验证LangChain 是非常顺手的。LangGraph 则是基于图模型的 Agent 编排引擎由 LangChain 团队推出但它解决的是 LangChain 原本不擅长的场景有状态的复杂工作流。你可以把 LangGraph 想象成一个“工作流状态机”开发者定义节点Node和边EdgeAgent 在图里流动每一步都能读写共享状态并且天然支持循环、分支、暂停恢复。一个 Agent 要完成“检索资料 → 写报告 → 调用工具核对数据 → 修改报告”这种多步骤任务用 LangGraph 来表达远比用一条线性 Chain 要清晰。MCP 是另一层的东西它不关心你用什么编排框架只关心“AI 应用怎么和外部工具对话”。在 MCP 出现之前每个 Agent 框架都要自定义工具协议每个工具接入方也要按不同框架各写一套。MCP 的思路是把工具服务化工具提供方实现一个 MCP Server暴露统一的工具列表和调用接口AI 应用作为 MCP Client 通过标准协议调用。底层传输走 JSON-RPC支持本地 stdio 和远程 HTTP整个设计借鉴了 IDE 的 Language Server Protocol所以它也被很多人称为“AI 应用的 LSP”。最后是 Agent。Agent 不是具体某个框架而是一种程序模式大模型作为“决策大脑”根据用户目标和当前状态决定调用哪些工具、以什么顺序调用然后观察工具返回值并继续推理直到目标完成。它和传统程序的本质区别在于控制流不再由开发者硬编码而是由模型根据上下文动态决定。四者关系总结如下表组件核心解决的问题类比LangChain提供模型封装、Prompt、文档处理、工具等基础组件工具箱LangGraph提供有状态的图执行引擎支持循环、分支、记忆工作流状态机MCP统一 AI 应用与外部工具之间的通信协议USB-C 标准接口Agent由模型驱动的“决策-执行-观察”循环模式员工或自动驾驶系统一句话概括它们的关系LangChain 提供工具包MCP 统一工具插口LangGraph 决定 Agent 怎么跑模型决定 Agent 怎么想。2026 年主流的 Agent 工程架构基本就是“LangGraph MCP 任意模型”的组合LangChain 更多作为组件库参与其中。3. 选型判断什么项目用 LangChain什么项目用 LangGraph不是所有项目都需要一上来就上 LangGraph。搞清楚选型边界比学会 API 更重要。如果你的需求是一条比较固定的链路比如“用户问题 → 检索知识库 → 拼接 Prompt → 生成回答”或者只是给现有系统加一个智能问答接口LangChain 的 Chain 模式足够。它的优点是上手快、代码直观、社区案例多一个几百行的脚本就能完成。团队如果刚接触 AI 开发用 LangChain 做第一个内部工具是性价比最高的路径。如果你要构建一个真正的 Agent 系统问题就复杂了。真正的 Agent 意味着模型可能要做多次推理、多次工具调用可能在不同分支之间切换可能需要在关键节点暂停等待人工审批还可能因为异常中断需要在恢复后续跑。这时候线性 Chain 无法描述控制流你需要一个图执行引擎——LangGraph 是当前最成熟的选项。判断要不要用 LangGraph可以从四个维度问自己。第一流程是否存在分支。比如根据意图走不同处理路径有的问题需要调数据库有的问题只需要大模型直接回答。第二是否需要循环。比如“生成内容 → 工具校验 → 不合格就重新生成”这种循环逻辑在 Chain 里很难优雅表达。第三是否有状态恢复和人工干预需求。生产级系统经常要把某个节点暂停等人确认后再继续。第四是否有多智能体协作。多个 Agent 分别负责不同子任务相互传递状态这基本上是 LangGraph 的舒适区。另外还要注意LangGraph 并非要取代 LangChain它本身就是 LangChain 生态的一部分内部大量复用 LangChain 的模型封装、消息类和工具抽象。两者不是替代关系而是上下层关系用 LangGraph 编排流程用 LangChain 组件处理模型和工具细节这是 2026 年最普遍的组合。除了框架本身还有一个重要的选型思考Agent 控制面要不要和业务系统解耦。如果你做的是企业级应用Agent 不是孤立存在的它需要对接权限系统、审批流、监控告警。LangGraph 的 StateGraph 天然适合这种场景因为它把执行过程变成了可观测、可控制的图节点之间的状态流转可以记录、追踪、审计这一点是普通脚本式 Agent 根本无法做到的。4. 环境准备与依赖安装开始写代码前先准备一个干净的 Python 环境。建议使用 Python 3.10 及以上版本推荐 3.11 或更高因为新版本对类型注解和异步支持更完整。下面按虚拟环境 依赖安装 环境变量配置三步走。mkdir langgraph-agent-demo cd langgraph-agent-demo python -m venv .venv source .venv/bin/activate # Windows 使用 .venv\Scripts\activate激活虚拟环境后安装核心依赖。这里不锁定具体版本号因为 LangChain、LangGraph 和 MCP 的版本迭代很快项目应以你当前安装到的最新稳定版为准。如果遇到版本冲突可以按第 8 节的排查思路处理。pip install langchain langchain-openai langgraph mcp依赖安装完成后配置模型访问。篇幅原因示例代码统一使用 OpenAI 风格的 API。如果你的模型服务是兼容 OpenAI 接口的国内大模型只需额外设置 base_url 即可Agent 代码无需任何改动。export OPENAI_API_KEYyour-api-key export OPENAI_BASE_URLhttps://your-model-endpoint # 使用兼容 OpenAI 接口的服务时设置执行完上述步骤可以快速验证环境是否正常。运行 python -c import langchain, langgraph, mcp; print(env ok) 如果没有报错说明基础依赖装好了。接下来分别用 LangChain 和 LangGraph 各实现一个 Agent 示例对比两者的写法和适用场景。5. LangChain 实战20分钟跑通第一个带工具的 Agent这一节先用 LangChain 快速实现一个能调用工具的 Agent。我们做一个简单的“天气查询 简单计算”助手让模型自主判断用户问题是否需要调用工具。在项目目录下新建weather_agent.py代码如下# 文件路径weather_agent.py from langchain_openai import ChatOpenAI from langchain_core.tools import tool from langchain.agents import create_tool_calling_agent, AgentExecutor from langchain_core.prompts import ChatPromptTemplate tool def get_city_weather(city: str) - str: 查询指定城市的当前天气情况。输入应为城市名称例如北京、上海。 # 演示环境返回模拟数据生产环境应接入真实天气 API weather_map { 北京: 晴最高温度 26℃东北风 2 级空气质量良。, 上海: 多云最高温度 24℃东风 3 级空气质量优。, } return weather_map.get(city, f暂无 {city} 的天气数据请核实城市名称。) tool def calculate(expression: str) - str: 计算简单的数学表达式。输入应为标准数学表达式例如12 * 7 5。 # 演示环境使用 eval生产环境必须做安全校验不允许直接执行用户输入 return str(eval(expression)) model ChatOpenAI(modelgpt-4o-mini, temperature0) tools [get_city_weather, calculate] prompt ChatPromptTemplate.from_messages([ (system, 你是一个智能助手可以根据用户问题调用工具获取信息。), (human, {input}), (placeholder, {agent_scratchpad}), ]) agent create_tool_calling_agent(model, tools, prompt) executor AgentExecutor(agentagent, toolstools, verboseTrue) if __name__ __main__: result executor.invoke({input: 北京的天气怎么样另外帮我计算 12 * 7 5 的结果。}) print(回答, result[output])这段代码的关键逻辑有四处。第一tool装饰器把普通函数变成 LangChain 工具函数的 docstring 会作为工具描述传给模型模型据此判断何时该调用该工具所以描述一定要写清楚输入格式和用途。第二create_tool_calling_agent接收支持 tool calling 的模型内部会把工具列表传给模型如果模型不支持原生 tool calling这个函数会报错。第三Prompt 模板中的{agent_scratchpad}占位符专门存放中间推理步骤和工具调用结果这是 Agent 循环能够持续的依据。第四AgentExecutor负责执行循环——调用模型、解析工具调用、执行工具、把结果写回 scratchpad、再次调用模型直到模型不再请求工具为止。运行方式很简单python weather_agent.py预期会看到类似如下的输出 Entering new AgentExecutor chain... Invoking: get_city_weather with {city: 北京} 北京晴最高温度 26℃东北风 2 级空气质量良。 Invoking: calculate with {expression: 12 * 7 5} 89 Finished chain. 回答北京的天气是晴天最高气温 26℃。12 * 7 5 的结果是 89。如果你看到 Agent 一次性调用了两个工具并给出最终回答说明 Agent 循环已经跑通。这里最值得关注的是日志里的Invoking过程——它证明了模型确实在自主决策调用工具而不是只凭幻觉回答。很多新手在这一步会遇到一个典型问题Agent 完全不调用工具直接凭模型记忆回答。排查思路很简单优先检查工具描述是否足够清晰模型是否有 tool calling 能力以及是否使用了支持 bind_tools 的模型封装。关于这个问题的详细排查见第 8 节的表格。6. LangGraph 实战把 Agent 做成有状态、可恢复的图LangChain 的 AgentExecutor 适合快速验证但它的循环逻辑是一个黑盒状态存在内存里没有持久化能力没有跨分支控制也没有人工审批节点。当你的 Agent 需要进入生产环境时LangGraph 会是更稳妥的选择。LangGraph 的核心概念是 StateGraph你定义共享的 State 类型定义若干个 Node节点再定义节点之间的 Edge边Agent 执行就是一个在图里流动的过程。这样整个 Agent 的执行路径完全可视化状态流转可控并且天然支持循环。下面用 LangGraph 重写上一个示例并加上多轮对话记忆。代码文件命名为weather_agent_graph.py# 文件路径weather_agent_graph.py from typing import TypedDict, Annotated from langchain_openai import ChatOpenAI from langchain_core.tools import tool from langgraph.graph import StateGraph, START, END from langgraph.graph.message import add_messages from langgraph.prebuilt import ToolNode, tools_condition from langgraph.checkpoint.memory import MemorySaver tool def get_city_weather(city: str) - str: 查询指定城市的当前天气情况。输入应为城市名称例如北京、上海。 weather_map { 北京: 晴最高温度 26℃东北风 2 级空气质量良。, 上海: 多云最高温度 24℃东风 3 级空气质量优。, } return weather_map.get(city, f暂无 {city} 的天气数据请核实城市名称。) tool def calculate(expression: str) - str: 计算简单的数学表达式。输入应为标准数学表达式例如12 * 7 5。 # 演示环境使用 eval生产环境必须做安全校验 return str(eval(expression)) tools [get_city_weather, calculate] model ChatOpenAI(modelgpt-4o-mini, temperature0).bind_tools(tools) class AgentState(TypedDict): messages: Annotated[list, add_messages] def call_model(state: AgentState): response model.invoke(state[messages]) return {messages: [response]} graph_builder StateGraph(AgentState) graph_builder.add_node(agent, call_model) graph_builder.add_node(tools, ToolNode(tools)) graph_builder.add_edge(START, agent) graph_builder.add_conditional_edges(agent, tools_condition) graph_builder.add_edge(tools, agent) checkpointer MemorySaver() graph graph_builder.compile(checkpointercheckpointer) if __name__ __main__: config {configurable: {thread_id: demo-thread-1}} print( 第一轮提问 ) result1 graph.invoke( {messages: [(human, 北京的天气怎么样)]}, configconfig, ) print(result1[messages][-1].content) print(\n 第二轮提问携带上文记忆 ) result2 graph.invoke( {messages: [(human, 刚才问的是哪个城市顺便帮我算 3 * 14 等于多少)]}, configconfig, ) print(result2[messages][-1].content)这段代码比 LangChain 版本复杂不少但每一步都有明确职责。AgentState定义了图的全局状态这里使用消息列表作为状态并标注add_messages表示每次节点返回值都会追加到已有消息列表而不是覆盖。call_model是核心节点函数它接收当前状态、调用模型、把模型返回追加到消息列表。ToolNode是 LangGraph 预置的工具执行节点会自动读取模型输出中的 tool_calls 并执行对应工具。tools_condition是预置的边路由函数它的逻辑是如果模型最后一条消息包含工具调用请求就走tools节点否则任务完成走END。MemorySaver是最值得关注的部分。它把每一步图执行状态持久化到内存检查点并绑定thread_id。这意味着只要使用相同的 thread_idAgent 就能“记住”上一轮对话的所有消息。这个能力在 LangChain 的 AgentExecutor 里需要自己管理而 LangGraph 把记忆直接做进了执行引擎。运行结果应该类似 第一轮提问 北京市今天晴最高气温 26℃。 第二轮提问携带上文记忆 你刚才问的是北京。3 * 14 等于 42。关键点在于第二轮回答中Agent 准确记得第一轮问的是“北京”。这说明thread_id对应的会话状态在两次 invoke 之间被正确保存和读取。如果没有记忆模型根本无法回答“刚才问的是哪个城市”。这个示例虽然短但已经体现出了 LangGraph 相对 LangChain 的三个核心优势状态共享、循环可控、记忆持久化。后续你要加人工审批节点、多智能体协作、断点恢复都是在现有图结构上增加节点和边而不是推倒重写。7. MCP 实战一次实现让 Agent 连接到真实世界LangChain 和 LangGraph 解决了 Agent 内部的编排和状态问题但还有一个问题悬而未决Agent 要调用的工具从哪来如果每个工具都要用 Python 函数硬编码在代码里那么每接入一个新系统就要改代码、发版、联调。MCP 的出现改变了这个局面。可以把 MCP 理解为 AI 应用的工具标准化协议。工具提供方实现一个 MCP Server 并暴露工具列表Agent 应用作为 MCP Client 连接并动态发现工具然后按统一协议调用。这样工具和 Agent 完全解耦一个企业内部服务只需要实现一次 MCP Server就能被所有兼容 MCP 的客户端使用包括 Claude Desktop、Cursor、你自研的 LangGraph Agent以及许多主流 IDE 工具。先看服务端。用 MCP 官方 Python SDK 的 FastMCP 高层封装写一个最小工具服务代码文件命名为weather_mcp_server.py# 文件路径weather_mcp_server.py from mcp.server.fastmcp import FastMCP mcp FastMCP(demo-server) mcp.tool() def get_city_weather(city: str) - str: 查询指定城市的当前天气情况。输入应为城市名称例如北京、上海。 weather_map { 北京: 晴最高温度 26℃东北风 2 级空气质量良。, 上海: 多云最高温度 24℃东风 3 级空气质量优。, } return weather_map.get(city, f暂无 {city} 的天气数据请核实城市名称。) mcp.tool() def calculate(expression: str) - str: 计算简单的数学表达式。输入应为标准数学表达式例如12 * 7 5。 # 演示环境使用 eval生产环境必须做安全校验 return str(eval(expression)) if __name__ __main__: mcp.run(transportstdio)这段代码把之前定义的两个 Python 函数直接暴露成 MCP 工具。FastMCP帮开发者屏蔽了协议的底层细节你只需要关注工具函数本身的实现。传输方式使用stdio也就是客户端以子进程方式启动服务端通过标准输入输出交换数据适合本地场景。再看客户端。下面用 MCP 官方 SDK 连接上面这个 Server动态获取工具列表并调用get_city_weather# 文件路径mcp_client_demo.py import asyncio from mcp import ClientSession, StdioServerParameters from mcp.client.stdio import stdio_client async def main(): server_params StdioServerParameters( commandpython, args[weather_mcp_server.py], ) async with stdio_client(server_params) as (read, write): async with ClientSession(read, write) as session: await session.initialize() tools await session.list_tools() print( MCP Server 暴露的工具 ) for tool in tools.tools: print(f- {tool.name}: {tool.description}) result await session.call_tool( get_city_weather, arguments{city: 上海}, ) print(\n 调用 get_city_weather 的结果 ) for content in result.content: print(content.text) if __name__ __main__: asyncio.run(main())这是一个非常标准的 MCP Client 调用流程启动子进程连接 Server → 初始化会话 → 列出工具 → 调用工具。运行后预期输出会打印出两个工具的名字和描述然后返回上海的天气信息。你可能会问MCP 这里展示的明明只是把 Python 函数包装了一层价值在哪里价值在于工具与系统的解耦。刚才写的weather_mcp_server.py本身就是一个独立的进程它可以运行在任意机器上通过任意语言实现。你的 Agent 只需要知道它的地址和协议就能像插拔 U 盘一样接入工具。更重要的是这项工作正在形成生态。2025 年到 2026 年MCP 的接入范围已经扩展到游戏引擎、设计协作平台、桌面应用、仿真软件、数据库运维等领域Cursor、Claude Desktop 等客户端均原生支持 MCP。对开发者来说现在为一个系统封装 MCP Server等于让它在整个 AI 工具生态中“一次接入处处可用”。MCP 协议本身涉及初始化握手、工具列表、调用请求、错误处理等环节底层基于 JSON-RPC 2.0。这篇教程先通过 FastMCP 帮助你跑通最小链路等进入生产级工具开发后再深入协议细节不迟。8. 常见问题与排查思路Agent 开发中遇到问题时最忌讳盲目改代码。下面按“问题现象 → 可能原因 → 排查方式 → 解决方案”的维度整理五个最高频的问题。问题现象可能原因排查方式解决方案Agent 不调用工具直接凭记忆回答工具描述不清晰或模型不支持原生 tool calling打印模型输出查看是否返回 tool_calls检查工具 docstring重写工具描述明确输入格式和适用场景确认模型支持 tool callingAgent 调用工具后不继续处理对话中断工具返回结果后没有回到 agent 节点图缺少环检查 LangGraph 边配置确认tools节点之后有指向agent的边在状态图中添加graph_builder.add_edge(tools, agent)Agent 进入死循环反复调用同一个工具工具返回内容未改变模型状态模型无法判断任务完成开启详细日志查看每轮模型输出与工具返回值限制最大迭代步数拆分子任务为工具增加明确结束条件MCP Server 启动后客户端连不上stdio 子进程启动失败或传输参数写错先在命令行单独运行python weather_mcp_server.py验证无报错检查 server 文件路径、Python 解释器路径和依赖环境LangGraph 多轮对话记忆丢失未使用 checkpointer或每次请求 thread_id 不同检查 compile 时是否传入 checkpointer请求 config 中 thread_id 是否固定使用MemorySaver并保证同一会话使用相同 thread_id生产环境可替换为持久化存储依赖包版本冲突langchain 和 langgraph API 对不上本地安装了多版本或过时版本运行 pip listgrep langchain 查看版本阅读报错堆栈这里面最容易被忽视的是第二个问题。用 LangGraph 写 Agent 时很多人以为加完节点就完事了忘记tools节点还要指回agent节点。严格来说这构成的是“循环依赖”但正是这个环路让 Agent 能在“推理 → 执行工具 → 再推理”之间往返直到任务完成。另外如果你在项目里同时操作 LangChain、LangGraph、MCP 三个库尽量把它们放进同一个虚拟环境管理避免全局环境污染导致的 C 扩展冲突。遇到看起来莫名其妙的 AttributeError优先怀疑依赖版本不匹配而不是代码逻辑问题。9. 生产环境最佳实践与关键提醒最后聊一聊把 Agent 从 Demo 推向生产环境时真正决定成败的几个工程细节。这一节不展开具体代码但每一条都是实践中容易踩到真金白银的部分。第一控制工具数量和描述质量。工具过多会让模型每次决策都面对庞大的 schema既增加 Token 消耗也降低选对工具的概率。生产环境要把工具数量控制在合理范围内并为每个工具写清晰、唯一的描述。工具描述不要写废话但要写清楚何时该用、何时不能用。不同的工具之间职责边界要清晰否则模型会出现“选择困难”。第二重视安全边界和最小权限。这可能是 Agent 工程里最重要也最容易被忽略的点。Agent 一旦具备调用数据库、发送邮件、操作文件系统等能力就必须在工具层做权限校验。不要把所有工具权限直接暴露给模型更不要让工具函数直接执行用户传入的原始字符串。演示代码里的eval是为了展示完整流程生产环境必须替换为安全解析器并对每个敏感操作增加人工确认节点。LangGraph 的 interrupt 机制可以很方便地实现“Agent 执行到关键步骤时暂停等待人工审批后继续”。第三日志与可观测性必须前置。Agent 的行为具有不确定性线上出了问题如果日志只记录“用户问题”和“最终回答”中间的推理链、工具调用参数、每一步状态变更全都是黑的排查会非常痛苦。建议在 LangGraph 的每个节点记录输入输出使用 LangSmith 或自建追踪系统把所有工具调用的入参、出参、耗时、Token 消耗落库。第四做好成本与执行步数控制。Agent 越智能意味着它可能越“啰嗦”一个简单问题也可能造成大量模型调用。生产环境一定要设置单次会话的最大模型调用次数、最大 Token 上限、工具调用超时时间。一旦超过阈值返回“需要人工介入”并终止执行而不是无限循环烧钱。第五预留回滚和灰度能力。Agent 依赖的模型版本、Prompt、工具定义都会持续迭代。不要在不做 A/B 的情况下直接替换生产链路。代码层面要给每个 Agent 任务打上版本号至少能在出现大规模错误时快速切回上一版本。关于 LangChain、LangGraph、MCP 和 Agent 的工程化理论和示例说再多都不如亲手跑一遍。建议你从这篇文章的最小示例出发先跑通 LangChain 版本的天气助手理解 Agent 循环然后用 LangGraph 加上记忆和状态理解图编排最后用 FastMCP 写一个自己的工具服务换一个你实际业务中真正需要被调用的系统。这三个步骤走完你就已经超越了大量停留在“调大模型接口”阶段的开发者。至于团队内部到底是自研 Agent 框架还是基于 LangGraph完全取决于你的业务形态——但无论怎么选状态管理、工具标准化和可观测性这三件事都是绕不开的基石。只有把这些工程底座打牢Agent 才会真正从“能跑 Demo”变成“能上生产”。
