MCP这个词最近快被刷屏了。从Anthropic把它开源出来到现在SQL Server、Figma、Unreal Engine甚至IDA都有人在做MCP Server适配层这套被戏称为“AI外设USB接口”的协议几乎成了智能体工具链里绕不开的一环。不过我发现大部分教程还停留在“怎么配置一个MCP客户端连上某个Server”很少有人把协议握手的细节和LangGraph多Server编排放在一起讲。这篇文章就把我最近在一个实际Agent项目里踩完的坑、跑通的流程完整记录一下从MCP协议的initialize握手开始讲到capabilities协商再到用LangGraph同时挂载数据库和文件系统两个Server让模型自己决定先查哪个库、再调哪个接口。适合谁看已经在用LangChain或LangGraph写Agent、但对MCP内部机制还有点发怵的开发者以及想把手头工具统一接到AI能力里的后端工程师。看完至少能搞懂三件事MCP握手到底在握什么、多个Server怎么共存、LangGraph里工具调用的路由怎么设计得不容易翻车。1. 为什么我要研究 MCP LangGraph 这套组合1.1 Function Calling 的老路到底堵在哪里在MCP出现之前给大模型接工具基本是“各写各的”。OpenAI有自己的一套function calling格式Claude走tool use本地模型可能又是另一套每个工具都要自己处理鉴权、参数校验、错误重试数据源一变工具函数和prompt里的描述又要跟着改。我最早做Agent的时候最烦的不是模型推理而是“给工具写接入层”这件事——同一个查询接口为了适配不同模型经常要写三份差不多的代码。MCPModel Context Protocol的思路是把大模型需要的外部能力统一抽象成三类Tools可调用的工具、Resources可读取的数据资源、Prompts提示模板。底层消息走JSON-RPC 2.0本地进程用stdio传输远程服务走HTTP。这么一来一个MCP Server写好了任何支持MCP的客户端都能直接用。类比一下以前每个设备都要自己的充电线现在统一成USB-C插上就通。这波生态起来的速度也很快已经有人给Unreal Engine 5.8接了MCP让AI能直接操作场景里的对象IDA和x32dbg有了MCP插件能把逆向调试变成模型的可调用工具Altium Designer也开始出现AI接口的MCP Server。MCP显然已经不是玩具协议而是实打实的工具接入标准。1.2 编排层为什么选了 LangGraph而不是手写循环工具接入解决了但Agent的流程控制是另一件事。如果只是“模型调一个工具拿结果”手写循环当然够用。一旦任务变成多步决策比如“先查订单表结构再按状态统计订单最后把结果写成报告文件”纯手写循环就会非常痛苦中间结果放哪、工具调用失败要不要重试、模型幻觉参数怎么兜底全是自己写。LangGraph把Agent流程建模成一张有向图节点是模型推理或工具执行边是条件和数据流转消息和状态放在一个可序列化的state里。它能把“查库→写报告→归档文件”这种多步协作显式地画出来还支持持久化、人工介入和流式输出。我选LangGraph还有一个很现实的原因LangChain生态里的langchain-mcp-adapters能直接把MCP Server的工具批量转成LangChain Tool接入成本比手写HTTP轮询低太多。1.3 我实际用的架构一个 Agent多个 Server先把架构用文字描述清楚后面所有代码都围绕它展开用户问题进入LangGraph的Agent节点Agent手里拿的是多个MCP Server合并后的工具列表它推理出下一步要调用哪个工具由ToolNode路由到对应的MCP Client再通过stdio或HTTP打到具体ServerServer执行完返回结构化结果流回Agent继续决策。我项目里挂着两个Server一个负责SQLite数据库的订单查询与写入一个负责本地文件读取和报告归档。你可以把这两个替换成自己业务域里的任何Server——公司内部API、对象存储、消息队列只要它们能包一层MCP协议就能被LangGraph统一调度。2. 协议握手MCP 连接建立的核心机制2.1 传输层选型stdio 与 HTTP 两条路MCP的传输层主要有两条路。第一条是stdio客户端直接拉起一个子进程通过标准输入输出和Server通信。这条路的优点是启动快、不暴露网络端口、安全边界清晰适合本地执行的Server比如文件系统操作、SQLite查询。我本地调试阶段基本都是stdio。第二条是HTTP早期叫HTTPSSE现在不少SDK支持Streamable HTTP适合把Server部署在远程机器上、多个Agent共享同一个能力池的场合。选型建议很直接本地单机、工具数量不多无脑stdio如果Server要部署在多台机器、或者要给多个客户端复用再考虑HTTP。一个容易踩的坑是stdio模式下不要把调试日志打到stdout——那会污染协议流导致客户端解析失败。所有日志一律走stderr或者日志文件这个我后面还会再强调。2.2 三步握手initialize → initialized 通知 → tools/listMCP的连接建立不是一上来就能喊“给我工具”。规范上是三步严格有序首先是initialize请求。客户端发一条JSON-RPC消息带上自己支持的协议版本、客户端能力声明和客户端信息。服务端收到后回一条响应包含它实际使用的协议版本、服务端能力声明和附加说明。这一步本质上是在互相确认“咱俩能按什么规矩说话”。然后是notifications/initialized通知。客户端确认初始化完成后发一条不带id的通知给服务端意思是“我这边准备好了可以开始正式干活”。注意这一步是notification不需要服务端回复。最后才是tools/list。客户端问“你有哪些工具”服务端返回工具清单每个工具包含name、description和inputSchema。后面真正调用时走tools/call把工具名和参数带过去。我最早犯过一个错初始化响应还没拿到就急着调tools/list结果工具列表是空的。MCP的SDK内部其实会规范这个顺序但如果你是自己手写JSON-RPC客户端一定要严格按这个时序来。2.3 capabilities 与协议版本协商MCP握手时客户端和服务端都会通过capabilities声明自己支持什么。服务端那边主要看三个能力位tools、resources、prompts。比如一个只读的数据源Server可能只声明resources而不支持tools一个工具型Server则主要声明tools。客户端拿到这些能力信息后才知道该用资源加载还是工具调用。协议版本协商也发生在initialize响应里。客户端习惯声明最新版本比如“2025-03-26”但如果服务端是个老版本只支持“2024-11-05”它会在响应里返回自己实际支持的版本客户端必须接受并降级后续消息的语义。所以做多Server接入时我强烈建议把各个Server的MCP SDK版本一起升级否则新server端字段在老client解析时容易被忽略行为会很诡异。2.4 握手阶段怎么调试日志和认证问题调试握手最直接的办法是开SDK日志。mcpPython SDK和langchain-mcp-adapters都有日志开关打开之后能看到initialize请求和响应、tools/list返回的工具数量。看到工具列表长度为0优先怀疑握手没完成或协议版本不匹配而不是Server本身没工具。远程HTTP模式还有一个高频报错登录失败提示token exchange failed。这本质是OAuth或token授权流程没跑通常见原因包括Server的鉴权回调地址配置错误、token过期、或者client用的authorization header没传全。排查方向就是去看Server的认证日志看token endpoint到底返回了什么错误而不是反复重启客户端。3. 多 Server 设计如何组织你的工具生态3.1 Server 粒度怎么切才不会被自己绕晕多Server架构里最忌讳把一个Server做成万能网关。我见过有人把所有工具塞进同一个Server结果prompt上下文里工具描述几百个模型光选工具就选半天还经常选错。正确做法是按业务域拆数据库一个Server、文件存储一个Server、搜索一个Server、消息通知一个Server。每个Server内部只暴露和自己领域相关的工具。拆的好处有三个权限最小化比如文件系统Server只开放指定目录的读写独立升级数据库Server的查询逻辑改了不会影响文件Server复用性好同一个Server可以被不同Agent按需挂载。我的sqlite_server只暴露订单相关操作filesystem_server只允许操作./data目录下的文件绝不把任意路径读写权交给AI。3.2 工具名冲突与命名空间隔离多个Server合并到LangGraph后第一个撞墙的问题就是工具名冲突。两个Server可能都有read_file或者都有write。模型调用时到底该走哪个这不能靠赌。langchain-mcp-adapters在聚合工具时有些版本会做一定处理但我的建议是自己做一层兜底给来自不同Server的工具加前缀或命名空间并且在description里写清楚归属。下面是我实际用的对照表现象原因解决两个Server都有read_file模型混乱未做命名空间隔离加载时重命名如sqlite__write_result、fs__write_file模型总调用错误的Server工具描述太模糊在description里写明“来自订单数据库Server”同名工具参数schema不同上下游定义冲突重命名后重新生成工具描述避免LLM按错误schema传参工具描述这件事模型比人更依赖文本。描述里写清楚“此工具来自订单数据库Server用于查询订单状态”模型选错率会低很多。3.3 Resources 和 Prompts 也不能忽略MCP不止有Tools还有Resources和Prompts。Resources是给模型“看”的数据不是“调用”的功能。比如把数据库表结构、项目文档作为resource暴露出来模型在生成SQL前先读一遍schema查询准确率会明显提升。多Server场景下resource URI要做好命名空间规划比如sqlite://schema/orders、file://docs/report.md避免两个Server资源撞名。Prompts则是服务端预定义的提示模板适合固定流程比如“每周订单汇总生成”。在LangGraph里resources一般不会自动进入模型上下文我会在agent节点里主动读取后塞进消息但要注意控制资源大小塞太多会把上下文撑爆反而影响推理质量。3.4 连接生命周期别一上来就挂十个ServerServer一多连接管理就成了问题。每个stdio Server都是一个子进程每个HTTP Server都有一条长连接。如果Agent启动时把所有Server全部连接光是握手和进程拉起可能就要好几秒内存占用也跟着涨。我的做法是分级加载核心Server启动时就挂载冷门Server等模型真正要调用时再懒加载。LangGraph的ToolNode支持动态工具列表吗严格说不支持但你可以把冷门工具提前注册好、让Server进程延迟启动到第一次调用前。另外每个Server都应该有独立的错误处理不能因为一个Server超时就把整个Agent拖垮我通常在ToolNode外面包一层超时和异常捕获。4. LangGraph 多 Server 调用实战4.1 环境准备推荐用Python 3.10以上用uv建一个干净虚拟环境。需要安装的包pip install langchain langgraph langchain-openai langchain-mcp-adapters mcp如果跑官方npm上的MCP Server还要确保本机有Node环境。版本冲突是这里最常见的坑尤其是LangChain和langchain-mcp-adapters的版本匹配问题我建议装之前先看下官方文档的兼容矩阵或者直接都用最新稳定版。模型方面我这套用的是OpenAI的接口换成别家也可以但必须确认模型支持function calling或tool calling否则bind_tools会直接报不支持。4.2 先写一个 SQLite MCP Server用FastMCP写Server非常快核心代码大概是这样from mcp.server.fastmcp import FastMCP import sqlite3 mcp FastMCP(sqlite-server) mcp.tool() def query_orders(status: str all) - list[dict]: 查询订单列表status 可选 all/pending/shipped/done conn sqlite3.connect(shop.db) cur conn.cursor() if status all: cur.execute(SELECT id, customer, status, amount FROM orders) else: cur.execute(SELECT id, customer, status, amount FROM orders WHERE status ?, (status,)) rows cur.fetchall() conn.close() return [{id: r[0], customer: r[1], status: r[2], amount: r[3]} for r in rows]注意docstring就是给模型看的工具描述写得越具体模型越不会乱传参数。这个文件保存为mcp_sqlite_server.py后面用stdio拉起。4.3 用 MultiServerMCPClient 同时聚合多个 Server多Server接入直接用官方适配器里的MultiServerMCPClient它内部会完成initialize握手、发initialized通知、拉取tools/list这整套流程不需要自己写JSON-RPCfrom langchain_mcp_adapters.client import MultiServerMCPClient async with MultiServerMCPClient( { sqlite: { command: python, args: [mcp_sqlite_server.py], transport: stdio, }, filesystem: { command: npx, args: [-y, modelcontextprotocol/server-filesystem, ./data], transport: stdio, }, } ) as client: tools await client.get_tools() # 到这里握手已完成tools 是多个 Server 的合并工具列表一个关键经验工具执行必须发生在async with上下文内部因为Server子进程是靠这个上下文管理的。如果with块结束Server进程就被杀掉了后面再调工具肯定会失败。所以我会把整个Agent执行逻辑也放进这个上下文里而不是只拿tools出来。4.4 构建 LangGraph用工具路由让模型“先查库再写文件”拿到tools之后可以用create_react_agent快速搭一个完整Agent。它内置了Agent节点和ToolNode会自动循环到模型不再调用工具为止适合原型验证from langgraph.prebuilt import create_react_agent agent create_react_agent(model, tools) result await agent.ainvoke({ messages: [{role: user, content: 统计今天已发货的订单并写入 report.txt}] })但如果你想对流程有更细的控制比如在某个节点加人工审批那就手写一个简单的StateGraphfrom langgraph.graph import StateGraph, MessagesState, START, END from langgraph.prebuilt import ToolNode graph StateGraph(MessagesState) graph.add_node(agent, model.bind_tools(tools)) graph.add_node(tools, ToolNode(tools)) def should_continue(state): if state[messages][-1].tool_calls: return tools return END graph.add_edge(START, agent) graph.add_conditional_edges(agent, should_continue, {tools: tools, END: END}) graph.add_edge(tools, agent) app graph.compile()这个图的意思是用户消息先进agent节点如果模型产出了tool_calls就进tools节点执行执行完把结果作为新消息传回agent节点继续推理如果模型不再调用工具就直接结束。数据库查询、文件写入这些工具调用都由ToolNode路由到正确的MCP ServerAgent只负责决定下一步做什么。4.5 流式输出与工具结果落盘工具结果如果很大比如查询出200行订单直接塞回对话上下文容易撑爆token。处理办法是双向截断Server端限制返回行数Agent端在工具返回后不把原始全文回流给模型只留一个摘要和文件路径。流式输出我一般用astream加stream_modeupdates能看到每个节点产出的内容方便把模型中间输出实时写文件async for chunk in app.astream( {messages: [{role: user, content: 统计已发货订单并写入 report.txt}]}, stream_modeupdates, ): for node_name, value in chunk.items(): if node_name tools: for msg in value[messages]: print(工具调用结果, msg.content)实操里我让模型先调sqlite的query_orders拿到统计结果再调filesystem的write_file把报告写进./data/report.txt。文件Server返回的只是“已写入文件路径”完整内容留在磁盘里不会在对话上下文里反复传输。这套组合跑多步任务非常稳。5. 常见问题排查速查下面这堆问题都是我实际撞过的整理成一张速查表按现象、原因、解决三步来问题现象常见原因排查与解决get_tools返回空列表握手未完成或SDK版本不匹配打开MCP日志看initialize响应确认client与server协议版本兼容两个Server工具名冲突未做命名空间隔离加载工具时重命名加前缀在description里写清楚Server归属stdio进程直接退出npx包没装好、Python脚本报错先单独跑一遍server命令看stderr输出确认日志不要打到stdoutWindows下报“拒绝访问 (os error 5)”标准输入输出被占用或权限异常用普通用户终端启动避免非管理员环境下daemon模式冲突远程Server报token exchange failedOAuth/token授权流程没配好检查Server的认证回调、token过期时间与client的授权headerLangGraph报不支持的消息类型模型没有bind_tools或ToolNode收到异常消息确认模型支持tool calling检查工具返回是否为合法消息结构模型生成参数总是错inputSchema太复杂、缺少约束简化schema枚举值用enum限定必填字段给默认值Agent执行到一半Server断开上下文管理器提前退出或子进程被杀确认MultiServerMCPClient的async with覆盖完整Agent执行过程这里面最隐蔽的是Windows下的os error 5。它看着像权限问题实际上很多时候是stdin/stdout被占用或者进程在后台daemon模式下和终端交互冲突。我吃了一次亏之后学乖了stdio Server在Windows上调试要么用非提升权限的普通终端直接启动要么把日志重定向到stderr文件避免和协议流竞争。另一个高频问题是“模型选错了Server”。看起来像是模型智商问题其实根子在于工具描述没写清楚。同一个语义下比如“保存文件”文件Server和数据库Server可能都暴露了write工具模型肯定懵。我处理办法是给每个工具描述加上“来自XX Server用于XX场景”这样的限定模型选错率会明显下降。6. 生态延展MCP 还能接进哪些重工具MCP最让我兴奋的是它已经不只是接数据库和文件系统了。Unreal Engine 5.8有人在做MCP让模型能操作场景节点逆向领域有IDA和x32dbg的MCP插件硬件设计软件Altium Designer也出现了AI接口的MCP Server日常办公里Figma、蓝湖这些设计协作工具同样被接进来过。你可以理解成只要有人写了一个MCP Server那个工具就变成了模型可调用的“外设”。协议本身没变变的只是Server怎么适配场景。比如Dify这类低代码平台里加了浏览器MCP可以让Agent直接读页面内容IDE插件通过MCP连Oracle数据库也算常见玩法。甚至像Ruoyi-Vue-Pro这种企业脚手架也开始有人做MCP功能合并。这说明MCP的接入范式已经稳定剩下的都是业务适配问题。最后说点我自己的体会。这套组合里MCP解决的是“AI能摸到什么”LangGraph解决的是“AI怎么有节奏地用这些东西”两者其实是分工关系。我在实际项目里最深的感受是把工具调用日志全部打开之后才发现很多看似模型变笨的问题根源在握手阶段就埋下了——工具列表不对、版本协商失败、Server进程退出表象全是“模型回答错误”。所以这篇文章我才坚持从握手开始讲而不是直接丢一堆LangGraph代码。如果你也要上这套组合建议先跑通两个Server的最小闭环把协议流程看清楚再往上堆复杂度也不迟。 
长河君 · 2026/10/7 6:21:05 · 阅读 1.2k MCP协议与LangGraph多Server编排实战：从握手到工具调用
MCP这个词最近快被刷屏了。从Anthropic把它开源出来到现在SQL Server、Figma、Unreal Engine甚至IDA都有人在做MCP Server适配层这套被戏称为“AI外设USB接口”的协议几乎成了智能体工具链里绕不开的一环。不过我发现大部分教程还停留在“怎么配置一个MCP客户端连上某个Server”很少有人把协议握手的细节和LangGraph多Server编排放在一起讲。这篇文章就把我最近在一个实际Agent项目里踩完的坑、跑通的流程完整记录一下从MCP协议的initialize握手开始讲到capabilities协商再到用LangGraph同时挂载数据库和文件系统两个Server让模型自己决定先查哪个库、再调哪个接口。适合谁看已经在用LangChain或LangGraph写Agent、但对MCP内部机制还有点发怵的开发者以及想把手头工具统一接到AI能力里的后端工程师。看完至少能搞懂三件事MCP握手到底在握什么、多个Server怎么共存、LangGraph里工具调用的路由怎么设计得不容易翻车。1. 为什么我要研究 MCP LangGraph 这套组合1.1 Function Calling 的老路到底堵在哪里在MCP出现之前给大模型接工具基本是“各写各的”。OpenAI有自己的一套function calling格式Claude走tool use本地模型可能又是另一套每个工具都要自己处理鉴权、参数校验、错误重试数据源一变工具函数和prompt里的描述又要跟着改。我最早做Agent的时候最烦的不是模型推理而是“给工具写接入层”这件事——同一个查询接口为了适配不同模型经常要写三份差不多的代码。MCPModel Context Protocol的思路是把大模型需要的外部能力统一抽象成三类Tools可调用的工具、Resources可读取的数据资源、Prompts提示模板。底层消息走JSON-RPC 2.0本地进程用stdio传输远程服务走HTTP。这么一来一个MCP Server写好了任何支持MCP的客户端都能直接用。类比一下以前每个设备都要自己的充电线现在统一成USB-C插上就通。这波生态起来的速度也很快已经有人给Unreal Engine 5.8接了MCP让AI能直接操作场景里的对象IDA和x32dbg有了MCP插件能把逆向调试变成模型的可调用工具Altium Designer也开始出现AI接口的MCP Server。MCP显然已经不是玩具协议而是实打实的工具接入标准。1.2 编排层为什么选了 LangGraph而不是手写循环工具接入解决了但Agent的流程控制是另一件事。如果只是“模型调一个工具拿结果”手写循环当然够用。一旦任务变成多步决策比如“先查订单表结构再按状态统计订单最后把结果写成报告文件”纯手写循环就会非常痛苦中间结果放哪、工具调用失败要不要重试、模型幻觉参数怎么兜底全是自己写。LangGraph把Agent流程建模成一张有向图节点是模型推理或工具执行边是条件和数据流转消息和状态放在一个可序列化的state里。它能把“查库→写报告→归档文件”这种多步协作显式地画出来还支持持久化、人工介入和流式输出。我选LangGraph还有一个很现实的原因LangChain生态里的langchain-mcp-adapters能直接把MCP Server的工具批量转成LangChain Tool接入成本比手写HTTP轮询低太多。1.3 我实际用的架构一个 Agent多个 Server先把架构用文字描述清楚后面所有代码都围绕它展开用户问题进入LangGraph的Agent节点Agent手里拿的是多个MCP Server合并后的工具列表它推理出下一步要调用哪个工具由ToolNode路由到对应的MCP Client再通过stdio或HTTP打到具体ServerServer执行完返回结构化结果流回Agent继续决策。我项目里挂着两个Server一个负责SQLite数据库的订单查询与写入一个负责本地文件读取和报告归档。你可以把这两个替换成自己业务域里的任何Server——公司内部API、对象存储、消息队列只要它们能包一层MCP协议就能被LangGraph统一调度。2. 协议握手MCP 连接建立的核心机制2.1 传输层选型stdio 与 HTTP 两条路MCP的传输层主要有两条路。第一条是stdio客户端直接拉起一个子进程通过标准输入输出和Server通信。这条路的优点是启动快、不暴露网络端口、安全边界清晰适合本地执行的Server比如文件系统操作、SQLite查询。我本地调试阶段基本都是stdio。第二条是HTTP早期叫HTTPSSE现在不少SDK支持Streamable HTTP适合把Server部署在远程机器上、多个Agent共享同一个能力池的场合。选型建议很直接本地单机、工具数量不多无脑stdio如果Server要部署在多台机器、或者要给多个客户端复用再考虑HTTP。一个容易踩的坑是stdio模式下不要把调试日志打到stdout——那会污染协议流导致客户端解析失败。所有日志一律走stderr或者日志文件这个我后面还会再强调。2.2 三步握手initialize → initialized 通知 → tools/listMCP的连接建立不是一上来就能喊“给我工具”。规范上是三步严格有序首先是initialize请求。客户端发一条JSON-RPC消息带上自己支持的协议版本、客户端能力声明和客户端信息。服务端收到后回一条响应包含它实际使用的协议版本、服务端能力声明和附加说明。这一步本质上是在互相确认“咱俩能按什么规矩说话”。然后是notifications/initialized通知。客户端确认初始化完成后发一条不带id的通知给服务端意思是“我这边准备好了可以开始正式干活”。注意这一步是notification不需要服务端回复。最后才是tools/list。客户端问“你有哪些工具”服务端返回工具清单每个工具包含name、description和inputSchema。后面真正调用时走tools/call把工具名和参数带过去。我最早犯过一个错初始化响应还没拿到就急着调tools/list结果工具列表是空的。MCP的SDK内部其实会规范这个顺序但如果你是自己手写JSON-RPC客户端一定要严格按这个时序来。2.3 capabilities 与协议版本协商MCP握手时客户端和服务端都会通过capabilities声明自己支持什么。服务端那边主要看三个能力位tools、resources、prompts。比如一个只读的数据源Server可能只声明resources而不支持tools一个工具型Server则主要声明tools。客户端拿到这些能力信息后才知道该用资源加载还是工具调用。协议版本协商也发生在initialize响应里。客户端习惯声明最新版本比如“2025-03-26”但如果服务端是个老版本只支持“2024-11-05”它会在响应里返回自己实际支持的版本客户端必须接受并降级后续消息的语义。所以做多Server接入时我强烈建议把各个Server的MCP SDK版本一起升级否则新server端字段在老client解析时容易被忽略行为会很诡异。2.4 握手阶段怎么调试日志和认证问题调试握手最直接的办法是开SDK日志。mcpPython SDK和langchain-mcp-adapters都有日志开关打开之后能看到initialize请求和响应、tools/list返回的工具数量。看到工具列表长度为0优先怀疑握手没完成或协议版本不匹配而不是Server本身没工具。远程HTTP模式还有一个高频报错登录失败提示token exchange failed。这本质是OAuth或token授权流程没跑通常见原因包括Server的鉴权回调地址配置错误、token过期、或者client用的authorization header没传全。排查方向就是去看Server的认证日志看token endpoint到底返回了什么错误而不是反复重启客户端。3. 多 Server 设计如何组织你的工具生态3.1 Server 粒度怎么切才不会被自己绕晕多Server架构里最忌讳把一个Server做成万能网关。我见过有人把所有工具塞进同一个Server结果prompt上下文里工具描述几百个模型光选工具就选半天还经常选错。正确做法是按业务域拆数据库一个Server、文件存储一个Server、搜索一个Server、消息通知一个Server。每个Server内部只暴露和自己领域相关的工具。拆的好处有三个权限最小化比如文件系统Server只开放指定目录的读写独立升级数据库Server的查询逻辑改了不会影响文件Server复用性好同一个Server可以被不同Agent按需挂载。我的sqlite_server只暴露订单相关操作filesystem_server只允许操作./data目录下的文件绝不把任意路径读写权交给AI。3.2 工具名冲突与命名空间隔离多个Server合并到LangGraph后第一个撞墙的问题就是工具名冲突。两个Server可能都有read_file或者都有write。模型调用时到底该走哪个这不能靠赌。langchain-mcp-adapters在聚合工具时有些版本会做一定处理但我的建议是自己做一层兜底给来自不同Server的工具加前缀或命名空间并且在description里写清楚归属。下面是我实际用的对照表现象原因解决两个Server都有read_file模型混乱未做命名空间隔离加载时重命名如sqlite__write_result、fs__write_file模型总调用错误的Server工具描述太模糊在description里写明“来自订单数据库Server”同名工具参数schema不同上下游定义冲突重命名后重新生成工具描述避免LLM按错误schema传参工具描述这件事模型比人更依赖文本。描述里写清楚“此工具来自订单数据库Server用于查询订单状态”模型选错率会低很多。3.3 Resources 和 Prompts 也不能忽略MCP不止有Tools还有Resources和Prompts。Resources是给模型“看”的数据不是“调用”的功能。比如把数据库表结构、项目文档作为resource暴露出来模型在生成SQL前先读一遍schema查询准确率会明显提升。多Server场景下resource URI要做好命名空间规划比如sqlite://schema/orders、file://docs/report.md避免两个Server资源撞名。Prompts则是服务端预定义的提示模板适合固定流程比如“每周订单汇总生成”。在LangGraph里resources一般不会自动进入模型上下文我会在agent节点里主动读取后塞进消息但要注意控制资源大小塞太多会把上下文撑爆反而影响推理质量。3.4 连接生命周期别一上来就挂十个ServerServer一多连接管理就成了问题。每个stdio Server都是一个子进程每个HTTP Server都有一条长连接。如果Agent启动时把所有Server全部连接光是握手和进程拉起可能就要好几秒内存占用也跟着涨。我的做法是分级加载核心Server启动时就挂载冷门Server等模型真正要调用时再懒加载。LangGraph的ToolNode支持动态工具列表吗严格说不支持但你可以把冷门工具提前注册好、让Server进程延迟启动到第一次调用前。另外每个Server都应该有独立的错误处理不能因为一个Server超时就把整个Agent拖垮我通常在ToolNode外面包一层超时和异常捕获。4. LangGraph 多 Server 调用实战4.1 环境准备推荐用Python 3.10以上用uv建一个干净虚拟环境。需要安装的包pip install langchain langgraph langchain-openai langchain-mcp-adapters mcp如果跑官方npm上的MCP Server还要确保本机有Node环境。版本冲突是这里最常见的坑尤其是LangChain和langchain-mcp-adapters的版本匹配问题我建议装之前先看下官方文档的兼容矩阵或者直接都用最新稳定版。模型方面我这套用的是OpenAI的接口换成别家也可以但必须确认模型支持function calling或tool calling否则bind_tools会直接报不支持。4.2 先写一个 SQLite MCP Server用FastMCP写Server非常快核心代码大概是这样from mcp.server.fastmcp import FastMCP import sqlite3 mcp FastMCP(sqlite-server) mcp.tool() def query_orders(status: str all) - list[dict]: 查询订单列表status 可选 all/pending/shipped/done conn sqlite3.connect(shop.db) cur conn.cursor() if status all: cur.execute(SELECT id, customer, status, amount FROM orders) else: cur.execute(SELECT id, customer, status, amount FROM orders WHERE status ?, (status,)) rows cur.fetchall() conn.close() return [{id: r[0], customer: r[1], status: r[2], amount: r[3]} for r in rows]注意docstring就是给模型看的工具描述写得越具体模型越不会乱传参数。这个文件保存为mcp_sqlite_server.py后面用stdio拉起。4.3 用 MultiServerMCPClient 同时聚合多个 Server多Server接入直接用官方适配器里的MultiServerMCPClient它内部会完成initialize握手、发initialized通知、拉取tools/list这整套流程不需要自己写JSON-RPCfrom langchain_mcp_adapters.client import MultiServerMCPClient async with MultiServerMCPClient( { sqlite: { command: python, args: [mcp_sqlite_server.py], transport: stdio, }, filesystem: { command: npx, args: [-y, modelcontextprotocol/server-filesystem, ./data], transport: stdio, }, } ) as client: tools await client.get_tools() # 到这里握手已完成tools 是多个 Server 的合并工具列表一个关键经验工具执行必须发生在async with上下文内部因为Server子进程是靠这个上下文管理的。如果with块结束Server进程就被杀掉了后面再调工具肯定会失败。所以我会把整个Agent执行逻辑也放进这个上下文里而不是只拿tools出来。4.4 构建 LangGraph用工具路由让模型“先查库再写文件”拿到tools之后可以用create_react_agent快速搭一个完整Agent。它内置了Agent节点和ToolNode会自动循环到模型不再调用工具为止适合原型验证from langgraph.prebuilt import create_react_agent agent create_react_agent(model, tools) result await agent.ainvoke({ messages: [{role: user, content: 统计今天已发货的订单并写入 report.txt}] })但如果你想对流程有更细的控制比如在某个节点加人工审批那就手写一个简单的StateGraphfrom langgraph.graph import StateGraph, MessagesState, START, END from langgraph.prebuilt import ToolNode graph StateGraph(MessagesState) graph.add_node(agent, model.bind_tools(tools)) graph.add_node(tools, ToolNode(tools)) def should_continue(state): if state[messages][-1].tool_calls: return tools return END graph.add_edge(START, agent) graph.add_conditional_edges(agent, should_continue, {tools: tools, END: END}) graph.add_edge(tools, agent) app graph.compile()这个图的意思是用户消息先进agent节点如果模型产出了tool_calls就进tools节点执行执行完把结果作为新消息传回agent节点继续推理如果模型不再调用工具就直接结束。数据库查询、文件写入这些工具调用都由ToolNode路由到正确的MCP ServerAgent只负责决定下一步做什么。4.5 流式输出与工具结果落盘工具结果如果很大比如查询出200行订单直接塞回对话上下文容易撑爆token。处理办法是双向截断Server端限制返回行数Agent端在工具返回后不把原始全文回流给模型只留一个摘要和文件路径。流式输出我一般用astream加stream_modeupdates能看到每个节点产出的内容方便把模型中间输出实时写文件async for chunk in app.astream( {messages: [{role: user, content: 统计已发货订单并写入 report.txt}]}, stream_modeupdates, ): for node_name, value in chunk.items(): if node_name tools: for msg in value[messages]: print(工具调用结果, msg.content)实操里我让模型先调sqlite的query_orders拿到统计结果再调filesystem的write_file把报告写进./data/report.txt。文件Server返回的只是“已写入文件路径”完整内容留在磁盘里不会在对话上下文里反复传输。这套组合跑多步任务非常稳。5. 常见问题排查速查下面这堆问题都是我实际撞过的整理成一张速查表按现象、原因、解决三步来问题现象常见原因排查与解决get_tools返回空列表握手未完成或SDK版本不匹配打开MCP日志看initialize响应确认client与server协议版本兼容两个Server工具名冲突未做命名空间隔离加载工具时重命名加前缀在description里写清楚Server归属stdio进程直接退出npx包没装好、Python脚本报错先单独跑一遍server命令看stderr输出确认日志不要打到stdoutWindows下报“拒绝访问 (os error 5)”标准输入输出被占用或权限异常用普通用户终端启动避免非管理员环境下daemon模式冲突远程Server报token exchange failedOAuth/token授权流程没配好检查Server的认证回调、token过期时间与client的授权headerLangGraph报不支持的消息类型模型没有bind_tools或ToolNode收到异常消息确认模型支持tool calling检查工具返回是否为合法消息结构模型生成参数总是错inputSchema太复杂、缺少约束简化schema枚举值用enum限定必填字段给默认值Agent执行到一半Server断开上下文管理器提前退出或子进程被杀确认MultiServerMCPClient的async with覆盖完整Agent执行过程这里面最隐蔽的是Windows下的os error 5。它看着像权限问题实际上很多时候是stdin/stdout被占用或者进程在后台daemon模式下和终端交互冲突。我吃了一次亏之后学乖了stdio Server在Windows上调试要么用非提升权限的普通终端直接启动要么把日志重定向到stderr文件避免和协议流竞争。另一个高频问题是“模型选错了Server”。看起来像是模型智商问题其实根子在于工具描述没写清楚。同一个语义下比如“保存文件”文件Server和数据库Server可能都暴露了write工具模型肯定懵。我处理办法是给每个工具描述加上“来自XX Server用于XX场景”这样的限定模型选错率会明显下降。6. 生态延展MCP 还能接进哪些重工具MCP最让我兴奋的是它已经不只是接数据库和文件系统了。Unreal Engine 5.8有人在做MCP让模型能操作场景节点逆向领域有IDA和x32dbg的MCP插件硬件设计软件Altium Designer也出现了AI接口的MCP Server日常办公里Figma、蓝湖这些设计协作工具同样被接进来过。你可以理解成只要有人写了一个MCP Server那个工具就变成了模型可调用的“外设”。协议本身没变变的只是Server怎么适配场景。比如Dify这类低代码平台里加了浏览器MCP可以让Agent直接读页面内容IDE插件通过MCP连Oracle数据库也算常见玩法。甚至像Ruoyi-Vue-Pro这种企业脚手架也开始有人做MCP功能合并。这说明MCP的接入范式已经稳定剩下的都是业务适配问题。最后说点我自己的体会。这套组合里MCP解决的是“AI能摸到什么”LangGraph解决的是“AI怎么有节奏地用这些东西”两者其实是分工关系。我在实际项目里最深的感受是把工具调用日志全部打开之后才发现很多看似模型变笨的问题根源在握手阶段就埋下了——工具列表不对、版本协商失败、Server进程退出表象全是“模型回答错误”。所以这篇文章我才坚持从握手开始讲而不是直接丢一堆LangGraph代码。如果你也要上这套组合建议先跑通两个Server的最小闭环把协议流程看清楚再往上堆复杂度也不迟。