1. 从一个真实困境说起：为什么单 Server 的 MCP 不够用
去年下半年我开始把 MCP 往实际项目里落，最开始的想法很简单：搭一个 Server，把几个常用工具挂上去，让模型能调用就够了。单 Server 跑通的那一刻确实很爽，协议握手、能力协商、工具列表拉取、调用返回，整条链路走下来不到两百行代码。但真正把它放进一个稍微复杂点的业务场景里，问题立刻就暴露了。
最典型的场景是这样的：我需要模型先查一批结构化数据，再根据结果去调一个外部的检索服务，最后把两边的内容做一次汇总生成。这三个动作分别属于三个不同的能力域，如果全塞进一个 Server，代码会迅速膨胀成一个什么都往里装的“万能工具箱”。工具描述越来越长，模型在选择工具时的准确率肉眼可见地下降，而且任何一个工具出问题都要重启整个 Server，其他能力跟着一起挂。
这就是多 Server 架构要解决的核心矛盾。MCP 的设计本身是支持一个 Client 连接多个 Server 的，每个 Server 只负责一块清晰的能力边界，Client 侧做统一的编排。但很多人第一次接触 MCP 时只看到了“单 Server 跑通”的 Demo，没意识到真正的工程价值在于多 Server 的协同。这篇内容我就把从协议握手到 LangGraph 里做多 Server 调用的完整链路拆开讲，包括握手阶段到底发生了什么、多 Server 的连接怎么管理、LangGraph 里怎么把多个 MCP Server 的工具统一编排进一张图，以及我在实测中踩过的那些坑。
适合的读者是已经跑通过单 Server MCP、想往工程化方向走的人。如果你还没接触过 MCP，建议先把单 Server 的握手和工具调用跑一遍再来看这篇，不然中间的一些细节会有点跳。下面所有代码和配置都是我在实际项目里验证过的，工具名和业务逻辑做了脱敏，但结构和参数是真实的。
2. 协议握手阶段到底在交换什么信息
2.1 握手不是一次请求，而是一轮能力协商
很多人以为 MCP 的握手就是发一个请求、收一个响应，其实它是一轮双向的能力协商。Client 和 Server 建立连接后，双方要互相声明自己支持哪些能力，然后根据对方的声明决定后续用什么方式通信。这个过程如果理解不到位，后面多 Server 场景下会出现“明明连上了但工具调不动”的诡异问题。
握手阶段的核心交换内容包括三块：协议版本、能力集、以及可选的实现信息。协议版本决定了双方能用哪些特性，如果 Client 声明的版本比 Server 支持的更新，Server 会返回自己支持的版本，Client 需要据此降级。能力集是重点，Server 侧会声明自己是否支持工具、资源、提示模板这几类能力，Client 侧则声明是否支持采样、根目录等。只有双方都声明支持的能力，后续才能正常使用。
我在实测中遇到过一个典型问题：某个 Server 声明了工具能力，但工具列表拉取时返回空。排查了半天发现是握手时 Client 声明的协议版本和 Server 不匹配，Server 虽然接受了连接，但按旧版本协议处理，工具列表的字段结构对不上，解析出来就是空的。所以握手阶段的版本协商一定要打日志，别默认它一定成功。
2.2 初始化请求的字段结构与常见误填
初始化请求里几个关键字段需要特别注意。protocolVersion是必填的，建议填你实际测试过的版本，不要盲目填最新。capabilities里 Client 侧一般声明roots和sampling，如果你不需要 Server 反向请求采样，sampling可以不声明，减少不必要的交互。clientInfo里的名称和版本虽然看起来是装饰性的，但有些 Server 会据此做兼容性判断，填一个有意义的值比填默认值稳。
Server 的初始化响应里，capabilities字段是你要重点解析的。如果tools字段存在，说明支持工具调用；resources存在说明支持资源读取；prompts存在说明支持提示模板。多 Server 场景下，你需要在 Client 侧维护一张表，记录每个 Server 支持哪些能力，后续编排时按能力分发请求，而不是无脑往所有 Server 发。
这里有个容易忽略的点：初始化完成后，Client 需要发送一个initialized通知，表示握手正式完成。这个通知不带参数，但必须发，否则部分 Server 会认为握手未完成，拒绝后续的工具列表请求。我一开始就是漏了这一步，导致工具列表一直拉不到，日志里也看不出明显错误，最后对着协议文档逐条比对才发现。
2.3 多 Server 握手时的连接管理策略
单 Server 时握手就是一次性的，多 Server 时你要考虑连接的生命周期管理。我的做法是在 Client 侧维护一个连接池，每个 Server 对应一个连接对象，包含它的能力集、工具列表缓存、以及健康状态。握手在连接建立时执行一次，之后工具列表可以缓存，但要注意缓存失效策略。
连接池的管理有几个实操要点。第一，握手要并行发起，不要串行，否则 Server 数量一多启动时间线性增长。第二，每个连接的握手失败要独立处理，不能因为一个 Server 挂了就阻塞其他 Server 的初始化。第三，要记录每个 Server 的握手耗时和失败原因，这在排查“为什么某个工具调不到”时非常有用。
我实测下来，五个 Server 并行握手的总耗时基本等于最慢那个 Server 的握手时间，比串行快了将近四倍。但如果你的 Server 里有需要冷启动的（比如要加载大模型或连接数据库），握手超时要设得宽松一点，默认的几秒可能不够。
3. 多 Server 场景下的工具发现与命名冲突
3.1 工具列表拉取的正确姿势
握手完成后，每个 Server 都可以通过tools/list拉取工具列表。单 Server 时你直接遍历就行，多 Server 时要把所有 Server 的工具聚合成一张总表，同时保留每个工具来自哪个 Server 的映射关系。这个映射关系是后续调用的关键，因为工具调用时要路由到正确的 Server。
工具列表的返回结构里，每个工具包含名称、描述、输入参数的 JSON Schema。多 Server 聚合时，我建议在内存里维护一个结构，键是“Server 标识 + 工具名”，值是这个工具的完整定义和所属 Server 的连接引用。这样调用时先按工具名找到候选，再根据 Server 标识路由。
这里有个性能上的细节：工具列表不需要每次调用前都拉，握手后拉一次缓存起来就行。但如果你的 Server 支持动态注册工具（有些框架允许运行时增删工具），那就需要定期刷新或者监听变更通知。我目前的项目里工具是静态的，所以缓存一次就够，省了不少往返。
3.2 命名冲突的三种处理方案与取舍
多 Server 最容易踩的坑就是工具重名。两个 Server 都提供了一个叫search的工具，模型调用时你根本不知道它想调哪个。这个问题在单 Server 时不存在，多 Server 时几乎必然遇到。
我试过三种方案。第一种是加前缀，把工具名改成serverA_search、serverB_search，简单直接，但工具名变长后模型选择的准确率会受一点影响，而且前缀命名要统一规范，不然会很乱。第二种是命名空间隔离，在工具定义里加一个namespace字段，调用时模型输出命名空间加工具名，这个方案对模型更友好，但需要 Server 侧配合改造，不是所有 Server 都支持。第三种是优先级路由，给每个 Server 设优先级，重名时优先用高优先级的，这个方案最简单但最危险，因为模型可能想调的是低优先级的那个，结果被路由错了。
我最后选的是第一种加前缀的方案，原因是它不依赖 Server 改造，纯 Client 侧就能搞定，而且前缀本身对模型来说也是一种语义提示。前缀命名我用的是能力域缩写，比如数据类的用data_，检索类的用retrieval_，比用 Server 编号更有意义。实测下来模型对带语义前缀的工具名选择准确率反而比裸名字更高，因为它多了一个判断维度。
3.3 工具描述的质量直接决定调用准确率
多 Server 场景下工具数量翻倍，模型要在更多选项里做选择，这时候工具描述的质量就变得极其关键。我见过太多 Server 的工具描述写得像天书，什么“执行操作”“处理数据”，模型看了根本不知道什么时候该用它。
好的工具描述应该包含三要素：这个工具做什么、什么时候用、输入输出是什么。比如一个查询工具，描述里要写清楚它查的是什么数据、适合什么场景、返回什么格式。参数描述也要具体，不要写“查询条件”，要写“用户 ID，格式为字符串，必填”。
我在项目里做过一个对比测试，把工具描述从模糊改成具体后，模型选错工具的比例从大概三成降到了一成以内。这个提升在多 Server 场景下尤其明显，因为选项多了，描述就是模型唯一的判断依据。所以如果你发现模型老是调错工具，先别怀疑模型能力，去看看工具描述是不是写得太敷衍。
4. LangGraph 里编排多 MCP Server 的完整链路
4.1 为什么选 LangGraph 而不是手写编排
多 Server 的工具调用本质上是一个编排问题：模型要根据当前状态决定调哪个工具、调完之后根据结果决定下一步。手写编排当然可以，一个 while 循环加一堆 if-else 也能跑，但一旦流程复杂起来，状态管理、错误重试、条件分支这些逻辑会迅速把代码搞成一团乱麻。
LangGraph 的价值在于它把编排显式化成了一张图，节点是动作，边是流转条件，状态在节点间传递。多 Server 场景下，每个工具调用可以是一个节点，工具返回后的判断是条件边，整个流程一目了然。而且 LangGraph 对中断、重试、并行分支都有原生支持，这些在多 Server 场景下都是刚需。
我选 LangGraph 还有一个实际原因：它和 MCP 的集成已经有现成的适配层，不需要自己从零写 Client 和工具调用的胶水代码。适配层会把 MCP Server 的工具自动转换成 LangGraph 能识别的工具节点，省了大量样板代码。当然适配层不是万能的，后面会讲它有哪些坑。
4.2 把多个 MCP Server 挂进一张图的配置方式
配置的核心是创建一个多 Server 的 Client，把每个 Server 的连接信息传进去，然后让 LangGraph 的工具节点去引用这些 Server 的工具。连接信息一般包括 Server 的启动命令或地址、握手参数、以及前面提到的命名前缀。
配置时要注意几个点。第一，每个 Server 的连接是独立的，一个 Server 启动失败不应该影响其他 Server，所以初始化要加容错。第二，工具前缀要在配置阶段就定好，不要等到运行时再拼，否则映射关系容易乱。第三，要给每个 Server 设独立的超时，因为不同 Server 的响应速度可能差很多，统一超时会导致快的被慢的拖累。
我实际项目里的配置大概是这样的结构：一个 Server 列表，每项包含名称、连接方式、前缀、超时；然后一个 Client 工厂根据这个列表创建多 Server 连接；最后 LangGraph 的图定义里，工具节点通过前缀加工具名来引用具体工具。这个结构清晰且好维护，加一个新 Server 只需要在列表里加一项。
4.3 图的状态设计与工具节点的衔接
LangGraph 的图是围绕状态转的，所以状态设计是重中之重。多 Server 场景下，状态里至少要包含：对话历史、当前待执行的工具调用、工具返回结果、以及一个记录已调用工具的集合（防止重复调用）。
工具节点的衔接有两种模式。一种是模型驱动，模型输出工具调用请求，图根据请求路由到对应工具节点，执行完把结果塞回状态，再回到模型节点判断下一步。另一种是固定流程，图里预先定义好工具调用的顺序，模型只在每个节点内部做参数填充。前者灵活但不可控，后者可控但不灵活，实际项目里往往是混合的：主干流程固定，分支处让模型决策。
我在项目里用的是混合模式。主干是“查询数据 → 检索补充 → 汇总生成”三步，每步内部让模型决定具体调哪个工具、传什么参数。这样既保证了流程的可控性，又保留了模型在细节上的灵活性。实测下来这种模式在稳定性和灵活性之间平衡得最好。
4.4 工具调用失败时的图级重试与降级
多 Server 场景下工具调用失败是常态，网络抖动、Server 重启、参数错误都可能导致失败。LangGraph 的图级重试机制可以在这里派上用场，但重试策略要设计好，不能无脑重试。
我的策略是分错误类型处理。参数错误不重试，直接把错误信息返回给模型让它修正参数；网络类错误重试两到三次，每次间隔递增；Server 不可用则触发降级，切换到备用 Server 或者跳过这个工具用其他方式完成。降级逻辑要在图里显式定义，不能靠模型自己判断，因为模型不知道哪个 Server 挂了。
这里有个实操心得：重试和降级都要记录日志，包括失败原因、重试次数、最终结果。这些日志在排查“为什么这次调用结果不对”时是唯一的线索。我一开始没记日志，出了问题只能靠猜，后来加了详细日志，排查效率提升非常明显。
5. 实测中踩过的坑与排查链路
5.1 握手成功但工具调不动的排查过程
这个坑我印象最深，因为现象很迷惑：日志显示握手成功，工具列表也拉到了，但一调用就报“工具不存在”。排查链路是这样的：先确认工具列表里确实有这个工具，确认了；再确认调用时传的工具名和列表里的一致，也一致；然后去看 Server 侧的日志，发现 Server 根本没收到调用请求。
问题出在路由层。多 Server 场景下，工具调用要先经过路由找到对应的 Server 连接，再发请求。我的路由逻辑是按工具名前缀匹配 Server，但有个工具的前缀配置错了，导致路由到了一个没有这个工具的 Server，Server 自然报“工具不存在”。修复就是把前缀配置对齐，同时加了一个路由校验，调用前先确认目标 Server 的工具列表里有这个工具，没有就直接报错，避免请求发出去才发现问题。
这个坑的教训是：多 Server 场景下，路由层是新增的故障点，一定要加校验和日志。单 Server 时不存在路由问题，多 Server 时路由错了比工具本身出错更难排查，因为错误信息会误导你以为是工具的问题。
5.2 工具返回结果过大导致图状态爆炸
MCP 工具返回的结果会塞进 LangGraph 的状态里，如果某个工具返回了几兆的数据，状态会迅速膨胀，后续每个节点都要带着这个大数据流转，内存和性能都会出问题。我遇到过一次，一个检索工具返回了完整的文档内容，几千条记录，状态直接爆了。
解决方案是在工具节点里做结果裁剪。返回结果先经过一个处理函数，只保留模型真正需要的字段，大文本做截断或摘要，列表做分页。裁剪逻辑要根据工具语义来定，不能一刀切。比如检索工具返回的文档，模型可能只需要标题和摘要，全文可以按需再取。
这个处理最好放在工具节点内部，而不是等结果进了状态再处理，因为状态一旦膨胀，后续所有节点都受影响。我在项目里给每个工具都配了一个结果处理器，返回前先过一遍，状态大小控制得很好。
5.3 多 Server 并行调用时的状态竞争问题
LangGraph 支持并行分支，多 Server 场景下可以并行调多个工具，理论上能提速。但并行调用会带来状态竞争：多个分支同时往状态里写结果，如果状态字段设计不当，会互相覆盖。
我踩过一次这个坑，两个并行分支都往results字段写，结果只有一个分支的结果保留下来，另一个丢了。排查时发现是状态更新用了覆盖而不是合并。修复方案是给每个分支的结果用独立的键，或者用支持合并的更新方式。LangGraph 的状态更新机制支持自定义 reducer，我给它配了一个列表合并的 reducer，并行分支的结果就都能保留。
并行调用还有个注意点：不是所有工具都适合并行。有依赖关系的工具必须串行，比如先查用户 ID 再查订单，这两个不能并行。判断依赖关系要靠人工设计，不能指望模型自己判断，因为模型看不到工具之间的依赖。
5.4 Server 冷启动导致的首次调用超时
有些 MCP Server 启动时需要加载资源，比如连接数据库、加载模型、读取配置文件，这个过程可能几秒到几十秒。如果握手后立刻调用工具，很可能撞上冷启动，首次调用超时。
我的处理是在握手完成后加一个预热步骤，主动调一个轻量级的工具或者发一个健康检查请求，等 Server 真正就绪了再标记为可用。预热失败的 Server 标记为不可用，后续调用直接跳过，避免每次都撞超时。
预热还有个好处是能提前发现 Server 的配置问题。有些 Server 握手能成功，但实际调用时才发现依赖没配好，预热阶段就能暴露这些问题，比等到正式调用时才发现要好得多。
6. 性能与稳定性上的几个优化点
6.1 工具列表缓存与失效策略
前面提过工具列表要缓存，这里展开讲失效策略。静态工具的 Server，缓存可以一直有效，握手后拉一次就行。动态工具的 Server，需要定期刷新，刷新频率根据工具变更频率来定，变更频繁的就短一点，不频繁的就长一点。
刷新时要注意不要阻塞正在进行的调用。我的做法是后台异步刷新，刷新期间用旧缓存，刷新完成后原子替换。这样调用方无感知，也不会因为刷新导致调用失败。刷新失败就保留旧缓存，记录告警，不要因为刷新失败把缓存清空，那样会导致所有调用都失败。
6.2 连接复用与超时参数的调优
MCP 的连接是可以复用的，不要每次调用都新建连接，那样握手开销会拖垮性能。连接池的大小根据并发量来定，并发高就多几个连接，并发低一两个就够。连接的空闲超时要设合理，太短会频繁重建，太长会占用资源。
超时参数要分层次设置。握手超时、工具列表拉取超时、工具调用超时是三个不同的超时，不能用一个值。握手和列表拉取可以短一点，工具调用要根据工具的实际耗时来定，查询类的可以长一点，计算类的可以短一点。我项目里工具调用超时是按工具配置的，每个工具可以有自己的超时值，这样最灵活。
6.3 监控指标：哪些数据必须采集
多 Server 场景下没有监控就是盲人摸象。必须采集的指标包括：每个 Server 的握手成功率、工具列表拉取耗时、工具调用成功率、调用耗时分布、错误类型分布。这些指标能帮你快速定位问题出在哪个 Server、哪个环节。
我还在项目里加了一个调用链路追踪，每次工具调用记录一个 trace ID，从路由到执行到返回全程可追。这样排查问题时能精确到某一次调用，而不是只能看聚合指标。trace ID 在日志里贯穿，配合日志检索工具，排查效率很高。
指标采集要注意不要影响主流程性能，异步上报是基本要求。另外指标要有告警阈值，成功率低于某个值、耗时超过某个值就告警，不要等用户反馈才发现问题。
7. 从单 Server 到多 Server 的迁移经验
如果你现在有一个跑通的单 Server 项目，想迁移到多 Server，我的建议是分步走，不要一次性重构。第一步先把单 Server 的代码抽象出 Client 接口，让工具调用通过接口走，这样后面加 Server 时不用改调用方。第二步加第二个 Server，验证多 Server 的连接管理和路由逻辑。第三步再把编排从手写改成 LangGraph，这时候流程已经清晰了，改起来风险小。
迁移过程中最容易出问题的是工具命名。单 Server 时工具名是裸的，多 Server 时要加前缀，所有引用工具名的地方都要改。我的做法是加一个映射层，内部用带前缀的名，对外暴露时按需转换，这样迁移时改动集中在一处。
还有一个经验是：多 Server 不是越多越好。每加一个 Server 都增加连接管理、路由、监控的复杂度。我项目里最后稳定在五个 Server，每个负责一块清晰的能力，再多了收益递减而复杂度上升。Server 的划分标准是能力边界，不是数量，一个 Server 能清晰覆盖的能力域就不要拆成两个。
8. 一些关于工具设计的心得
多 Server 场景下，工具的设计质量比单 Server 时更重要，因为模型要在更多工具里做选择。我的心得是工具要“小而专”，一个工具只做一件事，不要设计那种参数一大堆、行为根据参数变化的“万能工具”。万能工具的描述很难写清楚，模型也很难判断什么时候该用。
工具的参数设计也有讲究。必填参数要少，可选参数要有合理默认值。参数类型要明确，不要用模糊的字符串代替枚举。参数描述要具体，格式、范围、示例都写上。我见过一个工具的参数描述只写了“查询条件”，模型完全不知道怎么填，这种工具等于废的。
最后一点是关于工具的幂等性。多 Server 场景下重试是常态，如果工具不幂等，重试会导致重复操作。查询类工具天然幂等，写操作类工具要特别注意，要么设计成幂等，要么在重试前先检查是否已执行。这个在单 Server 时可能不明显，多 Server 加重试后就是必须考虑的问题了。
我在实际项目里把这些点都落了一遍之后，多 Server 的 MCP 编排才算真正稳定下来。回过头看，协议握手和多 Server 调用这两块，难点不在代码量，而在对协议细节的理解和对边界情况的处理。把握手阶段的版本协商、多 Server 的命名冲突、LangGraph 的状态设计这三块吃透，剩下的就是工程上的打磨了。
