企业官网建设流程全解析

做一个MCP Client的并发与异步设计，听起来像是一个"把请求发出去、等结果回来"的小事，真正动手之后才发现，里面全是细节。我先说结论：MCP协议本身基于JSON-RPC 2.0，每个请求都有独立的id，天然具备并发基础，但因为Client要同时面对多个会话、多个Server、长耗时Tool和不可靠网络，一旦把并发数提上去，连接管理、调度策略、超时控制、取消传播这些事会一起压过来，任何一个环节偷懒，都会在高并发下现出原形。

这篇东西是我在设计一个供内部Agent框架使用的MCP Client SDK时积累下来的实践总结，从架构选型、调度逻辑、生命周期管理到压测验证和踩坑复盘都有涉及，适合正在写MCP Client、或者打算把已有客户端改造成高并发形态的开发者参考。我会把每个设计决策背后的理由和踩过的坑一起讲清楚，而不是只给一份能跑的代码。

1. 并发从哪来：MCP Client 的请求生命周期与瓶颈定位

动手写并发之前，先别急着铺线程池和队列，我建议先把一个MCP请求从发起到返回的完整路径摊开，找到哪些环节能并发、哪些环节天生串行、哪些环节才是真正的瓶颈。这步不做，后面所有优化都是瞎调参。

1.1 完整请求链路拆解

一个典型的MCP请求长这样：客户端序列化JSON-RPC消息，写入传输层（stdio管道或者HTTP流），服务端解析消息、路由到对应的工具处理器，工具执行完后把结果封装成JSON-RPC响应，再沿原路返回，客户端解析响应，通过requestId找到当初发起请求的Future并唤醒它。

发请求侧：构造请求体 -> 分配requestId -> 登记到pending表 -> 写入传输层 服务端侧：读取消息 -> 路由分发 -> 执行Tool -> 组装响应 -> 写回传输层 收响应侧：读取响应 -> 按id查pending表 -> 赋值Future -> 唤醒调用方

在这条链路上，每个环节的并发能力完全不同。序列化和反序列化是CPU轻操作，单线程完全够；传输层写入需要保证消息完整性，同一个连接上不能并发乱写，必须串行化；服务端的Tool执行是最容易成为瓶颈的地方——如果服务端是单worker串行消费，客户端并发再高也没用；响应回调是最容易出Bug的地方，搞不好就跨了线程、丢了上下文。

我做压测时遇到过一个很典型的现象：同样的Client代码，连本地Mock Server时并发200轻松跑满，切到真实Server后并发50就开始大面积超时。原因就是真实Server的Tool内部加了一个串行的数据库锁，导致服务端消费能力跟不上。这个排查过程让我意识到，客户端并发设计再完美，也必须在链路视角下和服务端能力匹配，否则只是把压力从一个瓶颈挪到了另一个瓶颈。

1.2 高并发场景的真实来源

不是所有MCP Client都需要高并发，我总结了实际中真正会push并发量上去的几类场景：

• 多会话网关：一个Client进程同时服务多个用户的Agent会话，每个会话都在独立推进自己的工具调用链，并发度等于会话数乘以每会话并行请求数。
• 单会话内批量工具调用：Agent一次推理中可能同时调用"查天气""读数据库""搜文档"三个工具，它们之间无依赖，完全可以并行发起。
• 数据分片抓取：某个Tool支持按时间范围或ID区间分片，客户端为了加速会把一个大任务拆成几十个并行子请求。

上面三种场景对并发模型的要求不太一样。网关场景更看重会话隔离，不能因为一个会话的慢请求拖垮其他会话；批量工具调用更看重请求级别的独立超时和取消；数据分片场景则更依赖并发上限控制和结果聚合。

我在设计时先列了一张表，把所有可能的瓶颈点标出来，作为后续选型的依据：

这张表我在设计过程中反复回看，每次遇到"并发上不去"的问题，都是先回到这张表，定位是哪个环节出了问题，而不是盲目加大Client侧的并发数。

2. 会话与连接管理：线程模型选型和多会话隔离

MCP Client的并发设计，第一个核心决策是线程模型。选对了，后面的事顺理成章；选错了，你会陷入各种锁和共享状态的泥潭。

2.1 为什么我选了单事件循环而不是线程池

MCP的传输层形态主要有stdio和Streamable HTTP两种，但消息模型都是JSON-RPC 2.0——请求和响应通过id一一对应，消息之间天然无状态。这种模型和事件循环的契合度极高。

我把整个Client分成三层：

• API层：提供给应用层的异步方法，返回Future/CompletableFuture。
• 核心调度层：负责requestId分配、pending表维护、超时管理、取消传播。
• 传输层：负责具体协议的读写，stdio走子进程管道，HTTP走连接池。

这三层全部跑在一个事件循环（或者单线程调度器）上。API层调用核心层时只做状态变更和IO注册，不执行任何阻塞操作；传输层的读写都是非阻塞的，依赖事件循环的通知机制。

为什么敢用单事件循环扛高并发？因为一个MCP Client的瓶颈几乎永远不在CPU和内存上，而在网络IO和Server端执行时间上。事件循环在等待IO期间可以去处理其他请求，理论上单线程就能管理上千个在途请求，这也符合我在多个语言生态看到的实践经验：Node.js单事件循环扛高并发毫不在意，Python asyncio同样如此，Java里也可以用Netty的事件循环，Go虽然有goroutine但你依然可以让所有连接复用同一个调度器。

2.2 连接管理器：核心数据结构

连接管理器是Client的心跳，它负责维护当前所有活跃连接的状态，并保证每个连接上的消息严格有序写入。我给出一个简化版但足够说明问题的Python asyncio实现：

class ConnectionManager: def __init__(self, max_concurrency: int = 50): self._connections: dict[str, MCPConnection] = {} self._pending: dict[int, asyncio.Future] = {} self._semaphore = asyncio.Semaphore(max_concurrency) self._request_seq = itertools.count(1) self._lock = asyncio.Lock() async def call(self, conn_id: str, method: str, params: dict) -> Any: async with self._semaphore: conn = self._connections.get(conn_id) if conn is None: raise ConnectionNotFoundError(conn_id) request_id = next(self._request_seq) fut = asyncio.get_running_loop().create_future() async with self._lock: self._pending[request_id] = fut try: await conn.send(request_id, method, params) return await fut finally: self._pending.pop(request_id, None) def on_response(self, conn_id: str, request_id: int, result: Any): fut = self._pending.get(request_id) if fut and not fut.done(): fut.set_result(result) def on_error(self, conn_id: str, request_id: int, error: dict): fut = self._pending.get(request_id) if fut and not fut.done(): fut.set_exception(MCPError.from_dict(error))

这段代码里有几个值得细看的点。

_semaphore决定了全局并发上限，这是防止客户端无限发请求把Server打挂的保险丝。_pending是requestId到Future的映射，相当于一个"事务表"，响应回来时通过id定位到等待者。_lock保护_pending的读写，因为多个协程可能同时往里注册。conn.send只负责把消息写入传输层，真正等待回复是靠await fut挂起，不占用事件循环。

这里有一个关键设计：写入和等待是分离的。写入侧保证同一连接上消息有序，等待侧每个请求独享自己的Future，两者互不干扰。这样即使有上千个在途请求，事件循环也只需要在消息到达时做一次字典查找，开销极低。

2.3 多会话隔离：避免请求串号事故

网关型Client一次可能挂几十个MCP会话，每个会话对应不同的用户上下文和不同的Server端状态。最忌讳的做法是共享同一个pending表，把不同会话的请求混在一起。

某次我图省事，把所有连接的Future都塞进一个全局pending表，结果生产环境出现了一个诡异问题：A会话的请求响应，居然被B会话的调用方收到了。排查半天发现是requestId只在连接维度唯一，两个连接各自从1开始编号，全局表一混就串了。

后来我改成"连接维度隔离"：连接管理器下面挂多个连接对象，每个连接对象维护自己的pending表和requestId序列。请求归属哪个会话，就从哪个连接对象发起，响应也只会回到那个连接对象的pending表里，天然隔离，不需要加全局锁。

class MCPConnection: def __init__(self, transport): self.transport = transport self._pending: dict[int, asyncio.Future] = {} self._request_seq = itertools.count(1) self._write_lock = asyncio.Lock()

这样每个MCPConnection就是一个独立的异步上下文，连接与连接之间不共享任何可变状态。会话A的请求再慢、再超时，也不会影响会话B的请求。这也是做多租户Agent网关的必备基础。

3. 请求调度与优先级：异步API背后的排队逻辑

异步API的好处是调用方发完请求就挂起，不阻塞自身逻辑，但这只是表象。真正决定系统并发质量的，是API背后那套排队和调度逻辑。不把这层设计好，异步API只是把阻塞从调用方转移到了内部，系统该卡还是卡。

3.1 从同步到异步：调用模型对比

先看一个简单的对比，假设要调用三个无依赖的工具：

# 同步模型：总耗时 = t1 + t2 + t3 r1 = client.call("tools/call", {"name": "tool_a"}) r2 = client.call("tools/call", {"name": "tool_b"}) r3 = client.call("tools/call", {"name": "tool_c"}) # 异步并发模型：总耗时 ≈ max(t1, t2, t3) f1 = client.call_async("tools/call", {"name": "tool_a"}) f2 = client.call_async("tools/call", {"name": "tool_b"}) f3 = client.call_async("tools/call", {"name": "tool_c"}) r1, r2, r3 = await gather(f1, f2, f3)

看起来只是多了一个gather，但内部变化是本质性的：同步模型每个请求都要占用一个线程并阻塞等待，线程切换成本高，而且线程池大小就是并发上限，调大了内存飙升，调小了吞吐上不去；异步模型里请求注册后立即返回Future，真正挂起的只是一个协程，事件循环可以在等待期间处理其他请求，同样的资源能支撑高一个量级的并发数。

我做过一个直观的对比，同样在本地起一个Mock Server，每个Tool固定耗时200ms，串行调用50个请求需要10秒左右；改成并发50后，总耗时降到0.4秒左右，提升了20多倍，而Client侧的CPU和内存几乎没有明显变化。

3.2 优先级队列：为什么生命周期消息不能被工具调用堵住

并发请求多起来之后，一个容易被忽略的问题是：MCP的各类消息优先级并不相同。比如一个Agent正在发起50个工具调用，此时Server因为某种原因要求客户端重新握手（场景挺常见，比如Server端状态过期），如果重新握手要排在50个工具调用后面，最坏情况下整个会话要被拖住几十秒。

所以我在调度层加了一个双队列模型：

• 高优先级队列：生命周期消息，包括initialize、ping、notifications/cancelled、resources/list等元操作。
• 普通优先级队列：常规工具调用，比如tools/call、prompts/get。

调度器每次从高优先级队列取消息，没消息时再从普通队列取。因为生命周期消息数量很少，这种设计不会饿死普通请求，又能保证关键消息始终优先。

class PriorityScheduler: def __init__(self): self._high = asyncio.Queue() self._normal = asyncio.Queue() async def put(self, msg, high: bool = False): if high: await self._high.put(msg) else: await self._normal.put(msg) async def next(self) -> Message: if not self._high.empty(): return await self._high.get() return await self._normal.get()

这个设计的依据是MCP协议的会话生命周期特征：元操作是会话可用性的基础，工具调用是在会话可用之上的业务行为。业务行为再重，也不能本末倒置地阻塞基础协议行为。类似的想法也适用于普通HTTP客户端，比如连接池健康检查和业务请求如果共用FIFO队列，健康检查可能被拖到超时，导致客户端错误地认为连接不可用。

3.3 并发上限不是越大越好

在调度层之外，我还设计了显式的并发上限控制，用信号量实现。默认值是50，但这只是起步值，真实取值应该结合压测结果和服务端声明来调。

这里有一个比较反直觉的结论：并发数存在一个拐点，超过拐点后整体性能不升反降。原因多样——服务端线程池耗尽后请求排队、频繁的上下文切换、网络链路上排队、客户端自身的GC压力，等等。无脑调大"并发数"只会换来更大的延迟和更多的超时，而不是更高的吞吐。

我把并发上限的确定看成两部分：一部分是静态约束，比如Server在initialize返回的capabilities里可能声明了maxConcurrency，Client必须尊重；另一部分是动态探测，通过压测脚本逐档测试不同并发下的P99延迟，找到拐点后再预留20%的余量。

4. 超时、取消与背压：让系统在极端情况下依然可控

并发上的天花板不是"能并发多少"，而是"并发上去后系统还稳不稳固"。超时和取消是这一步绕不开的两个问题，处理不好，高并发下任何一个慢请求都能把整个Client拖入雪崩。

4.1 分阶段超时，而不是一个全局超时

我见过不少客户端设计是在发请求时设一个全局超时，比如30秒，任何请求到了30秒就整体失败。这个设计的缺陷是它没法区分"排队排了25秒"和"Server执行了25秒"这两种情况。

MCP的Tool执行天然有长耗时场景，比如一个数据分析工具可能跑好几分钟。如果全局超时设为1分钟，长任务必死；如果设为10分钟，那么Server挂掉的请求也要白白等10分钟才能失败。两难。

我的做法是把一次调用拆成多个阶段，各阶段独立计时：

具体实现时，每个阶段用独立定时器管理，而不是一个总计时器。以流式执行为例，如果Server已经稳定推流，说明它活着，就应该持续重置超时；只有长时间没有新事件到达，才判定卡死。

提示：长任务场景下，宁可把流式空闲超时设得足够宽，也不要让一次较长的静默处理误杀一个正常请求。误杀的代价不只是这次调用失败，还可能因为取消传播打断Server端本可以完成的工作。

4.2 取消传播：让用户在点击停止之后真的能停

用户发起一个长耗时的Tool调用后想反悔，点了停止按钮。这个操作在MCP协议里对应两条路径：本地路径是把Future标记为canceled，让等待方立即返回；远端路径是发送notifications/cancelled协议通知，把取消意图传播给Server，让正在执行的Tool有机会提前终止。

本地Future的取消是必须做到的，这部分我在每个Future上绑定了取消回调。但真正的难点是远端取消。MCP的notifications/cancelled消息携带requestId和reason，我建议在Client内部实现一个CancelToken机制，把用户取消、请求级取消、连接级取消统一注册到同一套机制里：

class CancelToken: def __init__(self): self._cancel_event = asyncio.Event() self._cancelled = False def cancel(self): self._cancelled = True self._cancel_event.set()

UUID类token可以传给用户API，用户决定在什么时候触发取消，底层把取消事件转换成notifications/cancelled消息发出去。这里有一个实现细节：取消消息本身走高优先级队列，确保Server能尽快收到，而不是排在几十个工具调用后面。

也不要因为协议发了取消就认为Server一定会中断执行。很多MCP Server是同步执行Tool的，收到通知时Tool可能已经跑完了。所以取消传播是尽力而为的机制，能救回多少算多少，核心价值是让Server端的进度可以主动检查取消状态，而不是让客户端幻觉般地认为Server一定会配合。

4.3 背压：防止Server把客户端打满

并发和背压是一体两面。客户端发起请求时可以靠信号量限制并发，但Server主动推送的数据（比如进度通知、日志流、长任务中间结果）不受客户端主动并发控制约束。如果Server是"生产快、消费慢"，客户端的接收缓冲区会越积越大，内存最终被打爆。

处理方案是三管齐下：

• 有界接收队列：每个连接的接收队列有最大长度，超过后按策略处理（丢弃旧事件、拉高水位告警、主动暂停连接）。
• 有界信号量：对"处理一个事件"这个动作加并发限制，处理能力饱和时新增事件排队而不是无限堆内存。
• 消费速度上报：如果传输层支持流量控制，可以在消费慢时通知Server暂时降低推送频率。

实现上，受背压保护的事件处理循环大致是这样：

async def event_loop(self, conn: MCPConnection): while True: event = await conn.receive(timeout=conn.idle_timeout) if event is None: continue await self._process_semaphore.acquire() try: await self._handle_event(event) finally: self._process_semaphore.release()

这里的_process_semaphore就是显式限流点。没有它，极端情况下一次高吞吐的Tool可能一次性向客户端灌入百万级进度事件，客户端处理不完就在队列里堆积，表面上是"响应变慢"，本质上内存已经被吃掉了。

5. 错误处理与连接重建：并发场景下的失败隔离

并发请求的麻烦在于错误往往会连锁放大。一个连接断开，可能同时影响这个连接上所有在途请求；更麻烦的是，并发越高，一个请求失败时越难判断该不该重试、该不该关连接。这一节重点聊聊错误分层、失败隔离和重试的边界。

5.1 MCP错误分层：协议层、传输层、工具层

MCP基于JSON-RPC 2.0，错误天然分两类：协议错误和传输错误。协议错误来自Server返回的JSON-RPC错误对象，携带错误码和描述；传输错误则来自底层连接，比如管道写入失败、连接被对方关闭、读超时。

我建议把所有错误统一成层级类型，每层处理策略不同：

这里最关键的一条经验是：协议错误绝不轻易关闭连接。一个Tool的参数错误只是它自己的问题，把这个连接上其他正在执行的请求一起杀掉，是典型的连带伤害。只有在传输层或者生命周期层确认连接已不可用时，才关闭连接并统一fail所有pending Future。

5.2 连接重建后，在途请求怎么办

当连接真的断了，一个最基本的问题是：这条连接上的pending Future全部要立即fail，而不是继续傻等。我维护了一个连接状态机，从connected到closed的同时，遍历该连接的所有pending请求，把它们统一标记为ConnectionClosedError。

这步必须在"事件循环内部同步完成"，千万不能异步慢慢清理。原因是Future不立即fail，等待方就会继续挂着，直到自己的超时兜底，那样的话用户感知到的延迟会从"毫秒级fail"变成"等了几十秒后才报错"，并发场景下这个延迟会放大为整体雪崩。

重建连接后，已经fail的请求不要无脑重放。MCP没有对普通Tool调用提供幂等语义，一个请求到达Server后Server可能已经执行了一部分甚至全部，客户端重放可能造成重复副作用。在我的设计里，只有两类操作允许自动重试：一是有明确幂等保证的元操作如ping，二是连接建立阶段的initialize（带上限的指数退避重试）。其余请求一律fail到API层，由上层业务逻辑决定是否重试。

5.3 超时与重试的组合策略

超时和重试放在一起，会出现很有意思的联动问题。比如一个慢请求在"Server正在执行"阶段触发了流式空闲超时，client判定超时后发取消通知。此时如果Client盲目重试，Server可能还在处理第一个请求，第二个请求只能继续排队，结果两个请求都超时，白耗资源。

给一套我验证过的组合策略：

• 请求级超时使用分阶段设计，阶段不同则超时不同。
• 重试只针对可重试错误，比如连接中断；可重试错误用指数退避：1s、2s、4s、8s，上限10s，并加入20%的随机抖动，避免多个并发请求在重连后同时撞向Server。
• 初始化阶段的重试最多3次，超过后直接标记连接不可用。
• Tool调用不自动重试，但上层可以通过传入retry_policy参数显式声明。

这样做的核心思想是：超时负责"别无限等待"，重试负责"能救则救"，两者通过错误的可重试性解耦，而不是简单地把重试次数乘超时时间作为一个总预算。如果一个操作既不可重试又很慢，那就让它按自己的节奏跑，超时兜底。

6. 实测压测：数字背后的真实瓶颈

设计完不算数，跑过压测才算数。我做了一轮比较完整的压测，核心目标是找到并发数与延迟、吞吐、资源消耗之间的关系。下面把过程和结果原样分享出来。

6.1 测试环境与方法

为了排除网络干扰，我在本地起了一个MCP Server进程，工具执行耗时模拟为200ms，无外部依赖；Client就是我设计的异步SDK，跑在同一台机器上。压测脚本分别用Python asyncio和JMeter两种方式发请求，JMeter负责模拟HTTP网关视角，asyncio脚本负责直接测SDK的纯并发能力。

测试变量是并发数，从1逐档升到500，每轮固定发500个请求，记录总耗时、QPS、P99延迟和Client侧的内存占用。

6.2 结果数据与曲线分析

这组数据有几个值得掰开揉碎看的点。

第一，并发从1涨到200，QPS单调上涨，但涨幅在明显收窄。50到100只涨了60%，100到200只涨了25%，典型的边际收益递减。第二，P99延迟从并发50开始就明显变差，500并发时P99已经到3.5秒，将近工具本身执行时间的17倍。第三，并发500时总耗时反而比200时更长，QPS也跌了，说明性能拐点就在200附近，超过之后Client的调度开销、Server端的上下文切换和GC压力开始反噬。

JMeter模拟100用户并发报告的结果也吻合：在纯HTTP调用场景下，100并发时Avg响应时间约340ms，P99约850ms，和asyncio直接测SDK的数据基本对齐，说明SDK本身没有引入额外的协议层退化。

6.3 从压测结果反推设计参数

压测数据直接指导了几个关键参数的选择：

• 默认并发上限50：对于一个服务端工具耗时在200ms量级的系统，50并发能在QPS和P99延迟之间取得平衡，不会过早触发拐点。
• 高并发模式下要单独放宽P99预期：如果业务必须追求极限吞吐，需要接受P99延迟的劣化，而不是指望既快又高并发。
• 流式空闲超时设为120秒：压测中极少出现无事件静默超过2分钟的正常场景，但长了容易拖住失败的请求，短了会误杀慢任务。
• 动态调节器：Client运行时可以根据Server反馈（比如频繁出现超时）主动降低本地并发上限，这是应对真实环境波动的最后一道防线。

压测教会我的最重要一课是：并发设计不是单纯把并发数调大，而是找到系统所有环节共同支撑的均衡点。数字不会骗人，但前提是你愿意花时间把数字背后的因果逻辑逐个看透。

7. 踩坑记录：设计迭代中几个值得复盘的细节

最后分享几个真实踩过的坑。这些坑单独看都不起眼，组合在一起差点让整个SDK返工，写出来帮大家避雷。

7.1 全局共享状态导致的会话串号

最早版本把所有连接的pending表都放在一个全局字典里，一度觉得"代码写得真简洁"。上线后遇到多会话场景，出现了A会话调用工具、B会话收到结果的严重事故。排查时发现，两个连接的requestId都从1开始编号，全局表里后注册的请求把先注册的Future覆盖了。

教训是：连接维度的状态一定要归连接所有，requestId序列、pending表、超时定时器都不能跨连接共享。这个看起来像"实现细节"的决策，直接影响多租户场景的正确性。

7.2 在事件循环里同步执行阻塞Tool

早期某个版本的代码中，我在收到Server请求后直接在事件循环里调用第三方SDK的同步方法，就是一个简单的数据库查询。并发一高，整个事件循环被阻塞，所有连接的请求全部排队，表现为"一个慢查询拖垮全站"。

修复方案是引入执行器池，把CPU密集或阻塞型操作丢到独立线程池，结果再投递回事件循环。这里要特别强调：不是所有操作都适合丢线程池，纯粹的内存计算直接并发执行反而更快，关键是区分"IO阻塞"和"CPU计算"，前者靠异步，后者靠多线程或进程池。

7.3 把"等待时间"和"执行时间"混在一个超时里

最早统一用一个30秒超时覆盖所有请求阶段，结果长任务频繁被误杀，短任务失败时又要傻等30秒。后来改成前面提到的分阶段超时模型，才真正解决了"长短任务共存"的问题。

具体实现时还有一个细节：总超时不是各阶段超时的简单相加。因为有些阶段可能被跳过，有些阶段会反复发生（比如流式执行中每次心跳都算一次活动）。我维护了一个deadline字段，每个阶段开始时根据剩余时间动态计算，而不是用固定的全局deadline。

7.4 高并发下日志反而成了最大瓶颈

有一次压测时发现，并发200的时候Client端CPU占用突然飙升，查了半天定位到日志库。因为我把每个请求的收发、每次取消、每个调度决策都打了info日志，高并发时一个请求能产生十几条日志，序列化和写盘本身成了最重的负担。

这个问题在压测中十分普遍，但实操里反而容易被忽视。优化方案很直接：请求级日志全部降级为debug，只保留连接级和调度级的关键事件；生产环境用抽样日志，比如1%的请求打全量，配合全链路traceId定位问题。调整后同样并发下的CPU占用下降了30%还多。

这些坑的共性在于：单独看都是"小事"，但高并发会放大每一个不够严谨的细节。并发设计不是把代码写出来然后等压测通过，而是从第一行代码开始就要考虑每个状态对象的归属、每个定时器的生命周期、每个日志带来的开销。MCP Client的异步设计，本质上是把这种严谨性落实到每一次请求的完整生命周期里。