MCP协议握手与LangGraph多Server调用编排实战

MCP（Model Context Protocol）技术分享这两年一直是 Agent 工程领域绕不开的话题，但大多数人只停留在“能把工具挂上去”的程度，真正把协议握手到 LangGraph 多 Server 调用整条链路吃透的人并不多。这篇内容我打算从最底层开始讲，带着你走一遍 MCP 的初始化握手、能力协商、传输选型，再落到 LangGraph 里如何稳定地协调多个 Server 一起工作。适合正在做 MCP Client 接入、准备用 LangGraph 编排复杂 Agent 工作流、或者已经从“demo 能跑”走向“线上要稳”的开发者，认真看完能帮你少踩大半年的坑。

1. 先把 MCP 讲明白：它到底解决什么问题

1.1 没有 MCP 之前，工具接入有多痛

在 MCP 出现之前，Agent 要调用一个外部工具，基本是“建模一次，写死一次”。每个大模型厂商有自己的一套函数调用格式，每个工具提供方又有自己的鉴权方式、参数风格和返回结构。你接入一个天气接口，要写一个适配层；接入一个内部数据库查询，又要写一套完全不同的封装。工具一多，适配层之间互相纠缠，维护成本直接失控。

我见过很多项目最终都变成了“工具末日”：代码库里充满了call_weather_api、query_sales_db这类硬编码函数，每个函数里塞满了请求构造、错误处理和鉴权逻辑。模型侧只要换一家，整套适配层就要重写一遍。这本质上不是能力问题，是接口规范缺失的问题。

MCP 想做的，就是把“模型如何发现工具、如何调用工具、工具如何返回结果”这个交互流程彻底标准化。它把工具提供方抽象成一个 Server，把模型侧抽象成一个 Client，两边通过一份协议对话。你只需要让 Server 侧实现协议，让 Client 侧理解协议，剩下的接入问题就变成一个“插上就能用”的标准化动作。

1.2 MCP 的“USB-C”式设计哲学

MCP 的设计思路非常好理解，你把它想成 USB-C 接口就通了。早年的电子设备各有各的充电口，出门要带一堆线；USB-C 出现后，设备和充电头只要都遵循同一个物理标准，随便插哪台设备都能通电。MCP 之于 AI 工具调用，就是那个 USB-C。

一个 MCP Server 对应一类或一组工具能力，它独立运行在自己的进程或者服务里，只负责把“能力”翻译成协议规定的结构。MCP Client 是模型侧的统一嘴，负责发现 Server、拉取工具列表、发起调用、接收结果。两边不关心对方内部怎么实现，只关心协议帧是否合法。

这个“协议即边界”的设计带来的最实际好处是：你可以把一个已经写好的 MCP Server 无缝复用在任何支持 MCP 的 Client 上。今天在 A 项目里用的数据库查询 Server，明天可以直接被 B 项目的 Agent 使用，不需要改一行业务代码。这就是为什么我觉得 MCP 不是又一个“中间层玩具”，而是一个值得投入时间去理解的基础设施。

1.3 协议栈速览：JSON-RPC、工具、资源

MCP 的协议栈并不复杂，底层消息传输基于 JSON-RPC 2.0。JSON-RPC 是一种很轻量的远程调用协议，核心就几个字段：jsonrpc声明版本，id对应请求编号，method表示要调用的方法，params是参数，result或error是响应。MCP 在这之上定义了若干领域方法，比如initialize用于握手、tools/list用于拉取工具列表、tools/call用于执行工具调用。

在 MCP 的领域模型里，有三类核心能力：Tools、Resources、Prompts。Tools 是“可以执行的动作”，比如查询数据库、调用接口，模型可以自主决定是否调用；Resources 是“可以读取的资料”，比如一份文档、一张表，更像只读数据源；Prompts 是“可以复用的提示词模板”，用于标准化用户请求。这三者中，Tools 是 Agent 场景里最常用的，也是 LangGraph 集成时最关心的部分。

2. 协议握手拆解：一次典型的 MCP 会话是怎么建立的

2.1 生命周期五步走：从 initialize 到 tools/call

MCP 会话不是“建立连接就能直接调用”的，它有一套严格的生命周期。第一步，Client 发起initialize请求，带上自己的协议版本、能力声明和客户端信息；第二步，Server 返回初始化响应，声明自己的协议版本、能力列表和服务端信息；第三步，Client 发送notifications/initialized通知，告诉 Server“初始化已经完成，可以开始干活”；第四步，Client 调用tools/list拉取可用工具；第五步，Client 根据模型决策调用tools/call执行具体工具。

前两步是“握手”的正式部分，很多人误以为initialize返回了就万事大吉，实际上如果漏发了notifications/initialized，部分严格实现的 Server 可能不会正常响应后续的工具调用请求。我曾经就在这个细节上栽过跟头，本地自测没问题，换了一个 Server 实现后工具列表一直拉不到，最后发现就是初始化通知没发完整。

这一步的设计其实是有讲究的。initialize阶段的目的不是真的去执行什么任务，而是让双方先确认“我们能不能一起工作”。协议版本是否兼容、能力集是否匹配、认证信息是否有效，全部在这个阶段完成。确认之后再进入正式工作状态，可以避免在后续调用过程中频繁出现协议层面的争吵。

2.2 实际报文长什么样：一次完整握手的抓包体感

只看概念容易飘，我习惯把报文直接拆开看。一次典型的 MCP 初始化握手，报文长这样。Client 发出：

{ "jsonrpc": "2.0", "id": 1, "method": "initialize", "params": { "protocolVersion": "2025-03-26", "capabilities": { "roots": { "listChanged": true }, "sampling": {} }, "clientInfo": { "name": "my-mcp-client", "version": "1.0.0" } } }

Server 应答：

{ "jsonrpc": "2.0", "id": 1, "result": { "protocolVersion": "2025-03-26", "capabilities": { "tools": { "listChanged": true } }, "serverInfo": { "name": "demo-tool-server", "version": "0.3.0" }, "instructions": "This server provides database query tools." } }

随后 Client 发送初始化完成通知：

{ "jsonrpc": "2.0", "method": "notifications/initialized" }

然后请求工具列表：

{ "jsonrpc": "2.0", "id": 2, "method": "tools/list" }

Server 返回：

{ "jsonrpc": "2.0", "id": 2, "result": { "tools": [ { "name": "query_sales", "description": "Query sales data by date range", "inputSchema": { "type": "object", "properties": { "startDate": { "type": "string" }, "endDate": { "type": "string" } }, "required": ["startDate", "endDate"] } } ] } }

可以看到，tools/list返回的每个工具都带有name、description、inputSchema，这三个字段组成了模型侧的“菜单”。模型通过description理解这个工具是干什么的，通过inputSchema学会怎么构造参数。所以工具的描述写得是否清晰、schema 是否严谨，直接决定模型能否正确调用，这一点后面 LangGraph 部分还会再强调。

2.3 能力协商：protocolVersion、capabilities 与 instructions

握手里最容易被略过、却最影响兼容性的，是能力协商。protocolVersion字段决定了双方用哪一版协议规则沟通，Client 发自己支持的版本，Server 在回包里给一个它在使用的版本。如果两边版本差太多，行为就会有差异。我一般建议在 Client 侧明确声明自己支持的版本，并检查 Server 返回的版本是否在已知范围内，不匹配时宁可报错也不要硬跑。

capabilities字段是双方各自能力的自我声明。Client 可以声明自己支持采样（sampling）、支持 root 文件列表；Server 可以声明自己支持工具、资源或提示词。注意，这里的声明是“我能做什么”，不是“你必须做什么”。一个只声明了 tools 能力的 Server，你去找它要 resources 列表就会得到空数组或不支持的错误。

instructions字段很有意思，它不是必须的，但一些 Server 会通过它给 Client 传递额外使用说明。这些说明通常带有强指导性，比如“调用本服务前必须先调用 auth 工具获取凭证”“时间参数一律使用 ISO 8601 格式”“批量操作单次最多 100 条”。如果在接入时忽略instructions，你的 Agent 很可能会在调用中反复犯同样的低级错误，排半天查不出来。

2.4 三条容易翻车的握手细节

握手阶段有三条细节，我每次接入新 Server 都会先检查。第一，notifications/initialized是通知（notification），不是请求，它没有id，也不期待响应。很多手写 JSON-RPC 的开发者习惯性给它加id，有的服务端不会报错但行为异常，有的直接忽略。第二，tools/list请求不一定只能在 initialized 之后发，但严谨的流程一定要在 initialized 通知之后再发，避免在服务端状态未就绪时拿到空列表。第三，部分 Server 支持的协议版本比较旧，会返回比你请求版本更早的版本号，此时要以 Server 返回的为准，不要用你请求的版本去解析后续所有交互。

另外还有一个我在生产环境踩过的坑：有些 Server 为了调试方便，会在 stdout 或日志里打印额外信息，但如果传输方式是 stdio，这些输出会被 MCP Client 当成协议帧去解析，直接导致消息乱掉。这个问题的排查非常痛苦，表现在这一层的问题往往会被错误地归结为“工具列表为空”或“消息格式非法”。遇到这种情况，先检查 Server 是否污染了标准输出流，再检查初始化报文是否完整。

3. 传输层选型与多 Server 部署：别让握手成为瓶颈

3.1 STDIO、SSE、Streamable HTTP：三种传输怎么选

MCP 支持多种传输方式，最常用的三种是 STDIO、SSE 和 Streamable HTTP。STDIO 模式下，Client 直接以子进程方式启动 Server，通过标准输入输出传 JSON-RPC 消息。这种方式的优点是部署简单、无网络开销、本地开发极其顺手；缺点是 Server 与 Client 生命周期绑定、不支持远程访问、进程崩溃需要自己管理重启。

SSE（Server-Sent Events）模式曾经是远程接入的主流方式，Client 通过 HTTP 发送请求，Server 通过单向事件流推送响应。但使用体验一般，因为 SSE 是单向的，Client 往往需要额外建立一个回连端点，复杂度和灵活性都不够理想。现代 SDK 基本都在向 Streamable HTTP 迁移，我遇到的新项目也普遍优先考虑这个。

Streamable HTTP 是目前我推荐的主要远程传输方式。它统一了传输机制，Client 和 Server 之间通过 HTTP 双向交互，支持流式响应，也支持在同一个连接上复用多个请求。它解决了 SSE 时代“回调端点”绕来绕去的问题，整个交互模型更接近普通 HTTP 调用。选型时可以按场景来：本地实验、进程内工具用 STDIO；跨机器、多 Server 共享场景，优先 Streamable HTTP。

3.2 多 Server 架构：进程隔离、命名空间与统一入口

当你有多个 MCP Server 时，第一个要思考的是进程边界。每个 Server 如果都作为独立进程运行，好处是故障隔离明确，一个 Server 挂了不至于拖垮整个 Agent；坏处是每个进程占用的资源和启动时间都会被放大。我的建议是：独立的、关键的工具用独立进程；轻量的、可插拔的小工具可以合并到一个进程里减少资源开销。

第二个问题是命名空间。多个 Server 很可能暴露同名工具，比如“文档检索 Server”和“知识库 Server”都可能有一个叫search的工具。模型面对两个同名工具时会非常困惑，甚至会因为描述不清而选错。因此在多 Server 架构里，我倾向于在 Client 层做一次工具名规范化，给每个工具加上 Server 前缀，或者为每个 Server 单独维护一套工具名映射。

第三个问题是统一入口。不要让 Model 直接面对一堆 Server 地址，否则接入逻辑会散落在代码各处。我个人习惯做一个轻量的 MCP 网关层，它负责维护多个 Server 的连接、统一做生命周期管理、集中做超时与重试策略。这个网关不一定要引入额外的框架，一个管理类就能搞定。

3.3 超时、重试、连接池：握手层最容易忽略的细节

很多人把 MCP 握手当成本地函数调用，觉得就是毫秒级的事，结果上了生产环境被现实狠狠教育。首先是超时问题：initialize阶段如果 Server 需要加载模型、初始化连接池、鉴权等操作，耗时可能远超几十毫秒。我的实践是给握手单独设置超时，不要和工具调用超时混为一谈，一般握手超时给 10 秒以上，工具调用超时按具体任务类型给 10 秒到 60 秒不等。

其次是重试策略。握手失败不一定要立刻报错，如果是网络抖动或者 Server 刚刚启动，重试一到两次往往是有效的。但重试要带退避，不要死循环打爆服务端。我常用的策略是首次失败后等待 1 秒重试，再次失败等待 3 秒，最多重试三次。重试时还要小心幂等性：initialize可以重复发，但重复发送后的 Server 状态一定要重新确认，不能默认和上次一样。

连接池同样值得关注。当一个 Server 被多个 Agent 任务共享时，客户端如果每个任务都创建新连接，很容易耗光服务端句柄。此时要引入连接复用，让同一个 Server 的多个请求走共享连接池。但连接池不是越大的越好，要结合实际并发量设置合理上限，否则会拖垮 Server 进程。具体数值我没法给你一个“万能值”，只能建议先从 5 到 10 开始，压测后逐步调整。

4. LangGraph 多 Server 调用：把协议能力编排成工作流

4.1 为什么用 LangGraph：状态机、持久化、可控性

说到多 Server 调用就绕不开 LangGraph。有人会问，直接写一个while循环反复调模型不行吗？能跑，但到多工具、多 Server、有状态、要持久化的场景就崩了。LangGraph 的核心价值是把 Agent 的思考-行动-观察循环建模成一个显式的状态图，每个节点执行一个明确动作，每条边决定下一步走向。这种显式建模带来的最大好处是可控：你能清楚看到 Agent 现在走到哪一步，可以中途插入人工审核，可以回滚状态，也可以把中间状态持久化到数据库。

MCP 解决了“模型怎么调工具”的协议问题，LangGraph 解决了“模型在什么流程里调工具”的编排问题。两者结合，才是生产级 Agent 的完全体。我在对接多个 MCP Server 时，会把每个 Server 的工具作为图上节点的工具集，Agent 在状态循环里按需选择调用，这个模式比“把所有工具堆到一个大列表里让模型自己选”靠谱得多。

4.2 绑定工具：将 MCP server 的工具“翻译”给模型

LangGraph 不能直接调用 MCP 工具，需要通过适配层把 MCP 工具转换成模型可用的工具对象。这里最常用的是官方适配器里提供的客户端封装，它能自动完成initialize握手、tools/list拉取、tools/call调用，并把 MCP 工具包装成 LangChain/LangGraph 的BaseTool形式。

这个转换过程是纯机械的，但有一个环节非常值得关注：description字段在转换后会被直接作为模型的工具说明。也就是说，你在 MCP Server 里写工具描述的质量，会直接变成模型决策质量的一部分。描述写得含糊不清，模型就会在多个 Server 之间犹豫甚至选错；描述写得具体、包含参数边界和返回格式说明，模型的一次调用准确率会明显提升。

我建议在写 MCP 工具描述时，遵循一个简单的模板：这个工具做什么、适合什么场景、不适合什么场景、参数的关键约束、返回数据的格式。哪怕 Server 是被内部项目使用，也值得花时间写清楚。模型不是人，它不会“猜”你的意图，它只会根据你给的文字做选择。

4.3 三种多 Server 编排模式：路由、并行、回退

多 Server 场景下，我总结出三种常用的编排模式，你可以按需组合。第一种是语义路由模式：由一个“路由 Agent”先分析用户意图，决定后续走哪个 Server。这种模式适合工具集明确、领域边界清晰的场景。比如用户问数据库销量的，就直接进数据库 Server；用户问文档相关问题的，就进文档 Server。好处是不会让一个 Agent 面对太多工具，决策压力小、准确率高。

第二种是并行模式：多个 Server 的工具在同一步中被并发调用，最后汇总结果。这种模式适合要综合多个数据源才能回答的问题，比如“对比这个项目的销售数据和用户反馈”，就需要同时查询数据 Server 和文档 Server。LangGraph 里可以用并行节点来实现，但要注意每个 Server 的调用耗时和质量要基本匹配，否则整体响应时间会被最慢的那个拖住。

第三种是回退模式：主 Server 调用失败或返回结果不理想时，自动切换到备用 Server。比如有一个快速但粗糙的检索 Server，和一个慢速但精准的深度检索 Server，可以让 Agent 先用前者，结果不满意再调后者。这种模式能显著提升用户体验，但对编排层的容错能力要求更高，需要判断“什么样的结果算不满意”。

4.4 工具冲突与命名空间隔离：我踩过的坑

多 Server 接入里最隐蔽的坑，是工具冲突。我有一次同时接入了一个“订单查询 Server”和一个“物流查询 Server”，两者都有一个get_status工具，description 也都写得模棱两可。Agent 在需要查订单状态时，竟然经常去调用物流 Server 的工具，返回了一堆物流轨迹信息。起初我以为是模型能力问题，后来检查才发现，适配层把两个同名工具都暴露给了模型，模型只能靠 description 猜，猜错完全不奇怪。

解决办法是给工具名加命名空间前缀。在适配层做一层映射，把get_status重命名为order_status和logistics_status，并在 description 里进一步明确各自职责。这样模型在决策时就能清晰区分。这个经验我现在直接用在了所有多 Server 接入项目里：不管会不会冲突，统一加前缀，把 Server 的标识直接嵌入工具名，一劳永逸。

4.5 一个可运行的最小示例

下面的伪代码展示了一个 LangGraph 多 Server 调用的最小闭环。先创建一个多 Server 客户端，注册两个 Server（一个 HTTP，一个本地 stdio），然后拉取全部工具，交给 React Agent 使用。

import asyncio from langchain_mcp_adapters.client import MultiServerMCPClient from langgraph.prebuilt import create_react_agent from langchain_openai import ChatOpenAI async def main(): async with MultiServerMCPClient( { "sales": { "url": "http://localhost:8000/mcp", "transport": "streamable-http", }, "docs": { "command": "python", "args": ["mcp_docs_server.py"], "transport": "stdio", }, } ) as client: tools = await client.get_tools() model = ChatOpenAI(model="your-model-name", temperature=0) agent = create_react_agent(model, tools) result = await agent.ainvoke( {"messages": [{"role": "user", "content": "上个月的销售额是多少？"}]} ) print(result["messages"][-1].content) if __name__ == "__main__": asyncio.run(main())

需要说明的是，上面示例里的模型名和地址你需要替换成实际可用的值。实际项目中，我通常会在此基础上再加一个前置路由节点，先判断意图属于哪个域，再把对应的 Server 工具子集传给 Agent。这样可以减少模型面对的工具数量，提高调用准确率。

5. 常见问题与排查技巧实录

5.1 工具列表是空的，怎么办

工具列表为空是 MCP 接入初期的最高频问题。先检查 Server 是否在 initialize 之前就暴露了工具定义，有些 SDK 要求工具的注册必须在服务启动前完成；再检查 Server 是否声明了tools能力，如果 capabilities 里根本没有 tools，列表自然为空；最后检查 Server 是否在 initialized 通知后才注册工具，这种情况属于生命周期实现问题，只能等 Server 修复或走其他方式绕过。

还有一种容易被忽略的情况：stdout 被日志污染。STDIO 模式下，日志一旦打到标准输出，Client 解析下一行消息时就会认为收到一个非法 JSON-RPC 帧，表现为工具列表拉取失败。排查时不要只盯应用日志，先确认进程的标准输出没有夹带任何非协议内容。

5.2 initialize 成功但 tools/call 一直超时

initialize能成功，说明握手通路没问题，问题大概率出在 Server 执行工具的实际逻辑上。先看工具本身是不是耗时操作，比如大数据量查询、外部 API 调用，这类工具天然慢，需要调大客户端超时时间。再看 Server 是否在 tools/call 处理里发生了阻塞，比如等待某个锁、数据库连接池打满、调用了外部依赖但依赖无响应。

我在生产里遇到过一个很有意思的超时案例：Server 工具本身执行很快，但返回结果很大，传输层的流式 buffer 被塞满，导致 Client 迟迟等不到完整响应。排查到最后发现不是处理慢，是传输慢。这类问题建议把工具返回的分页逻辑做好，限制单次返回体量，同时确认传输层支持大消息流式读取。

5.3 同名工具互相覆盖

多个 Server 暴露同名工具时，适配层可能发生后注册的覆盖先注册的，导致其中一个 Server 的工具“凭空消失”。你从工具列表里看起来只有一份，但实际是拼错了 Server。排查方法很简单：把拉取到的工具列表打出来，检查有没有名字重复、description 张冠李戴的情况。根治办法就是按 4.4 节说的，统一做命名空间前缀映射，从源头避免冲突。

5.4 循环调用、递归卡死与流式 buffer

Agent 反复调用同一个工具不收敛，是 LangGraph 场景里的常见问题。先看是不是工具描述有歧义，导致模型误以为还需要再次调用才能拿到最终结果；再看是不是模型在收到结果后没有正确判断“任务已结束”。解法上，一方面可以优化工具描述和系统提示词，另一方面可以给 Agent 设置recursion_limit，达到上限强制中止，避免无限制消耗 token。

流式 buffer 的问题在 Streamable HTTP 场景里尤其常见。当 Server 返回的内容很长，或者流式事件没有正确终止时，Client 可能一直等不到结束标志。排查时可以先用简单请求测试传输层是否正常，再逐步加大返回数据量找临界点。平时写 MCP Server 时也养成好习惯：返回内容设置上限，流式事件结束后明确发送终止标志。

5.5 排查速查表

6. 写在最后：一点实操心态

做了这么多 MCP 相关项目，我最大的体会是：协议层的东西不难，复杂的是环境。MCP 把“工具调用”这个动作标准化了，但 Server 的启动速度、网络的抖动、模型对工具描述的理解偏差、以及编排层的状态管理，每一个环节都可能翻车。所以我每次接入一个新 Server，不会急着写业务逻辑，而是先花半小时把握手报文打通、把工具列表拉出来、把一次最简单的手动调用跑通，确认链路完整了再往上堆业务。

这也是为什么我特别强调“协议握手”这四个字。很多问题你看似出在 LangGraph 的编排里，往下追一层，根因往往就在握手或传输层。你越是能把底层机制吃透，越能在上层调度时做出合理的取舍。另外一个小习惯：在多 Server 项目里，我会给每个 Server 打上独立的版本号和超时配置，这样定位问题时，能快速判断是哪个服务拖慢了整体链路，不用每次从头查起。希望这篇内容能帮你在 MCP 和 LangGraph 的踩坑路上少走几步。