可选插件不应阻塞核心会话：MCP 启动隔离与优雅降级
内容提要
MCP 多服务器串行启动时，任一可选插件超时都会阻塞整个会话。改进方案：配置区分必需与可选服务；用 Tokio 并发探测并设独立超时；失败插件降级并过滤其工具，同时提示前端。核心能力可秒级启动，可选插件故障不再阻塞主会话。
延伸解读
串行启动的隐藏成本
文章指出，传统 MCP 客户端用简单串行循环初始化服务器，总启动时间是各服务器握手时间之和。一个慢服务器卡住 5 秒，整个代理就延迟 5 秒。更严重的是，核心文件系统工具与辅助搜索工具共享同一生命周期，外部超时会被升级为致命崩溃，导致用户连基本提问或编辑本地文件都无法进行。
关键与可选的显式区分
改进方案在配置模式中增加 criticality 标志：required: true 表示代理无法缺少的工具，失败会干净地中止并给出明确错误；required: false 为可选增强，失败触发熔断而不影响主会话。这种显式区分让系统能根据业务重要性决定故障处理策略，避免辅助插件拖垮核心能力。
并发探测与独立超时
利用 Tokio，每个 MCP 服务器在专用异步任务中探测，并包裹 tokio::time::timeout。所有服务器并发握手，冷启动延迟由最慢的单个服务器决定，而非累加总和。若可选服务器在 3 秒内未连接或崩溃，错误被捕获并标记为 Degraded，不会向上冒泡导致整个初始化失败。
动态过滤与前端感知
所有探测任务结束后，成功初始化的工具注册到会话上下文；来自降级服务器的工具被过滤掉，防止模型幻觉调用已损坏的工具。同时向前端发送轻量通知，告知哪个可选插件失败，而主聊天保持完全可用。这样既保证核心能力秒级启动，又让用户了解降级状态。
Q&A
MCP 多服务器串行启动有什么问题？
串行启动会导致累积启动延迟，总启动时间是所有服务器握手时间的总和；同时缺乏故障隔离，核心文件系统工具和辅助搜索工具共享同一生命周期，外部超时可能升级为致命崩溃。
如何区分 MCP 服务是必需还是可选？
在配置模式中添加 criticality 标志：required: true 表示关键服务，失败会干净地中止并给出明确错误；required: false（默认）表示可选增强，失败会触发熔断而不影响主会话。
MCP 启动时如何实现并发探测和超时隔离？
使用 Tokio，每个 MCP 服务器在专用的异步任务（tokio::spawn）中探测，并用 tokio::time::timeout 包裹。所有服务器并发握手，冷启动延迟由最慢的单个服务器决定，而不是它们的总和。如果可选服务器在 3 秒内连接失败或崩溃，错误会被捕获并标记为降级，而不是向上传播。
可选插件失败后，工具和前端如何处理？
成功初始化的工具注册到会话上下文中；来自降级服务器的工具被过滤掉，防止模型幻觉调用损坏的工具。同时，轻量级通知告知前端哪个可选插件失败，而主聊天保持完全可操作。
改进后的 MCP 启动流程有什么好处？
核心能力可在亚秒级启动，即使网络不稳定或 MCP 插件配置损坏，可选插件故障不再阻塞主会话。插件系统必须为失败而设计，可选功能的问题不应破坏核心工具的可用性。
MCP 启动隔离方案的核心设计原则是什么？
核心原则是：可选插件不应阻塞核心会话。通过显式区分关键与可选服务、并发探测与独立超时、动态工具过滤与 UI 感知，实现优雅降级，确保核心能力快速启动且不受可选插件故障影响。
