MCP 协议生命周期定义了 Client 与 Server 从建立连接到断开连接的完整过程。理解生命周期是正确实现 MCP 集成、处理异常和设计健壮系统的前提。

一、基本定义

MCP 协议生命周期（Protocol Lifecycle）是指一个 MCP Client 与一个 MCP Server 之间从传输建立到连接关闭的完整过程。

它涵盖以下关键活动：

• 传输通道的建立（stdio pipe 或 HTTP 连接）
• 协议版本协商
• 能力声明与交换
• 正常运行期间的请求-响应和通知
• 能力的动态变更通知
• 操作的取消
• 连接的优雅关闭或异常断开处理

生命周期是 MCP架构总览 中「控制面」的核心组成部分——它管理的是连接本身，而非业务数据。

二、为什么需要标准化生命周期

如果没有标准化的生命周期：

• 每个 Client 和 Server 的连接逻辑各不相同，集成成本高
• 能力发现时机不确定，Client 不知道何时可以安全调用工具
• 无法优雅处理 Server 崩溃或网络中断
• 协议版本升级时无法协商兼容性
• 取消操作和错误传播缺乏统一机制

标准化生命周期的价值：

1. 确定性：Client 和 Server 对每个阶段的行为有明确预期
2. 可靠性：异常情况下有标准的恢复路径
3. 可演进性：版本协商机制允许协议平滑升级
4. 可组合性：不同厂商的 Client 和 Server 可以互操作

三、完整生命周期阶段

3.1 启动阶段

生命周期从进程或连接启动开始，具体方式取决于传输层（参见 MCP通信与传输）：

stdio 传输：

• Host 启动 Server 子进程
• 建立 stdin/stdout 管道
• stderr 用于日志输出（不参与协议通信）
• Server 进程退出即视为连接终止

Streamable HTTP 传输：

• Client 向 Server 的 endpoint 发起 HTTP 连接
• 通过 HTTP POST 发送 JSON-RPC 消息
• 可选通过 SSE（Server-Sent Events）接收 Server 推送的通知
• 连接断开可能由网络问题、超时或服务端主动关闭引起

3.2 初始化握手

传输建立后，Client 必须首先完成初始化握手。

第一步：Client 发送 initialize 请求

Client 向 Server 发送 initialize 请求，包含：

• protocolVersion：Client 支持的协议版本
• capabilities：Client 自身的能力声明（如 sampling、roots 等）
• clientInfo：Client 的名称和版本信息

第二步：Server 返回 initialize 响应

Server 收到请求后：

• 选择一个双方都支持的 protocolVersion
• 声明自身的 capabilities（如支持的 tools、resources、prompts、logging 等）
• 返回 serverInfo（Server 名称和版本）

如果 Server 无法支持 Client 请求的协议版本，应返回错误。

第三步：Client 发送 initialized 通知

Client 收到 initialize 响应后，发送 initialized 通知（注意这是一个 notification，不是 request，不需要 Server 回复）。

至此，初始化握手完成，进入正常运行阶段。

3.3 能力协商

能力协商发生在 initialize 请求/响应中，是握手的核心部分。

Server 能力（server.capabilities）可能包括：

能力	含义
tools	Server 提供可调用的工具，可能包含 listChanged: true 表示会动态变更
resources	Server 提供可读取的资源，可能包含 listChanged: true 和 subscribe
prompts	Server 提供预定义的提示模板，可能包含 listChanged: true
logging	Server 支持日志消息发送

Client 能力（client.capabilities）可能包括：

能力	含义
sampling	Client 支持 Server 请求模型推理（sampling）
roots	Client 提供文件系统根目录列表

能力协商的关键规则：

• 只有双方都声明支持的能力才能使用
• 能力声明中附带的能力特性（如 listChanged）决定了后续行为
• 未声明的能力不可假设存在

更详细的能力发现机制参见 MCP能力发现。

3.4 正常运行阶段

初始化完成后，Client 和 Server 进入正常运行阶段。此阶段的交互模式包括：

请求-响应（Request-Response）：

• tools/list：查询可用工具列表
• tools/call：调用指定工具
• resources/list：查询可用资源列表
• resources/read：读取指定资源
• resources/subscribe / resources/unsubscribe：订阅/取消订阅资源变更
• prompts/list：查询可用提示列表
• prompts/get：获取指定提示
• logging/setLevel：设置日志级别

通知（Notification，无需响应）：

• notifications/tools/listChanged：工具列表已变更
• notifications/resources/listChanged：资源列表已变更
• notifications/resources/updated：某个资源内容已更新
• notifications/prompts/listChanged：提示列表已变更
• notifications/message：日志或进度消息

采样请求（Sampling，Server → Client）：

如果 Client 声明了 sampling 能力，Server 可以反向请求 Client 进行模型推理。这是一个特殊的请求-响应流程，方向与通常相反。

3.5 能力变更

Server 的能力列表在运行期间可能动态变化。当 initialize 响应中某能力的 listChanged 为 true 时，Server 可以在能力列表发生变化时发送对应的 listChanged 通知。

Client 收到通知后应重新查询对应的列表（如 tools/list）以获取最新状态。

典型场景：

• 工具依赖的外部服务上线或下线
• Server 热加载了新的工具配置
• 资源对应的文件被创建或删除

3.6 取消操作

对于正在执行的请求，Client 可以发送 $/cancel 通知来取消操作。

• 取消是一个 notification，不等待 Server 确认
• Server 收到取消请求后应尽力终止对应操作
• 被取消的请求可能返回错误，也可能返回部分结果
• 取消是否生效取决于 Server 实现——对于不可中断的操作，Server 可能忽略取消

取消机制的典型使用场景：

• 用户主动中断了长时间运行的工具调用
• Host 决定放弃当前推理路径
• 超时后 Client 主动取消

3.7 关闭连接

优雅关闭：

• Client 主动关闭连接
• 对于 stdio 传输：关闭 stdin 管道，等待 Server 进程退出
• 对于 HTTP 传输：关闭 HTTP 连接
• 应确保所有进行中的请求已完成或已取消

Server 侧关闭：

• Server 可以主动关闭连接（如维护、配置更新）
• Client 应能检测到连接关闭并优雅处理
• 不应有进行中的请求被静默丢弃

3.8 异常断开

异常断开是不可避免的现实情况：

异常类型	触发原因	Client 应对策略
Server 进程崩溃	代码错误、内存溢出	检测到进程退出，标记连接不可用
网络中断	网络故障、防火墙超时	检测到连接错误，触发重连或通知用户
超时	Server 长时间无响应	发送取消请求，超时后关闭连接
协议错误	消息格式错误、版本不兼容	记录错误，关闭连接
资源耗尽	内存不足、文件描述符耗尽	优雅降级，通知用户

异常断开与优雅关闭的关键区别：异常断开时，进行中的请求不会有正常的错误响应，Client 必须自行判断请求状态。

四、状态管理

Client 管理的状态

• 协议版本（协商后确定）
• Server 能力列表（来自 initialize 响应，可能因 listChanged 通知而更新）
• 缓存的工具/资源/提示列表
• 连接状态（已连接、断开、重连中）
• 进行中的请求及其取消令牌

Server 管理的状态

• 协议版本
• Client 能力列表
• 连接级别的会话状态（如果有）
• 活跃的资源订阅
• 当前设置的日志级别

状态恢复分析

状态	是否可恢复	恢复方式
协议版本	✅ 可恢复	重新初始化握手
能力列表	✅ 可恢复	重新初始化握手
工具/资源/提示列表	✅ 可恢复	重新调用 list 接口
资源订阅	❌ 需重建	重新发送 subscribe 请求
日志级别	❌ 需重建	重新发送 setLevel 请求
进行中的请求	❌ 丢失	需要重新发起

重连后的标准处理流程：

1. 重新建立传输连接
2. 执行完整的初始化握手
3. 重新获取能力列表和工具/资源/提示列表
4. 重新建立必要的资源订阅
5. 重新发起因断连而丢失的请求

注意：MCP 协议本身不定义自动重连机制。重连策略由 Client 实现决定。

五、初始化失败的错误处理

初始化握手可能因多种原因失败：

协议版本不兼容：

• Client 和 Server 无法就协议版本达成一致
• 应返回明确的错误信息，包含各自支持的版本范围

Server 拒绝连接：

• Server 可能因认证失败、负载过高等原因拒绝初始化
• Client 应能根据错误类型决定重试或报告用户

传输层错误：

• stdio：Server 进程启动失败、立即崩溃
• HTTP：连接超时、DNS 解析失败、TLS 握手失败

处理原则：

1. 初始化失败不应静默忽略——必须通知用户或上层系统
2. 区分可重试错误（网络瞬断）和不可重试错误（版本不兼容）
3. 重试应有退避策略，避免快速循环重试
4. 记录详细的错误日志用于诊断

六、能力变化的动态更新

能力动态更新是 MCP 支持运行时灵活性的关键机制。

Client 处理 listChanged 通知时应注意：

• 通知本身不携带变更内容，只表示「列表可能已变化」
• 必须重新调用 list 接口获取完整最新列表
• 在 list 请求返回之前，缓存的旧列表仍然可用
• 如果短时间内收到多次通知，可以合并为一次 list 请求（防抖）

七、会话中断的处理策略

会话中断的处理需要根据中断类型和影响范围制定策略：

策略一：静默重连

• 适用场景：网络瞬断、Server 短暂重启
• 行为：Client 自动重连，重新初始化，对用户透明
• 风险：进行中的请求可能丢失或重复

策略二：通知用户

• 适用场景：Server 长时间不可用、多次重连失败
• 行为：Client 通知用户连接已断开，提供重试选项
• 适用于：交互式应用场景

策略三：降级运行

• 适用场景：某个 Server 不可用但其他 Server 正常
• 行为：Host 标记该 Server 提供的工具不可用，继续使用其他 Server 的能力
• 适用于：多 Server 拓扑场景

策略四：幂等重试

• 适用场景：请求可能已成功但响应丢失
• 行为：Client 重试请求，Server 需要支持幂等性
• 注意：并非所有工具调用都是幂等的，需要谨慎处理

八、完整生命周期时序图

九、协议状态图

十、设计原则

1. 初始化必须完整：在 initialized 通知发送之前，不应发送任何业务请求
2. 能力先行声明：所有能力在初始化阶段确定，运行时通过通知增量更新
3. 通知不携带数据：listChanged 只表示「请重新查询」，不传输变更内容
4. 取消是尽力而为：$/cancel 不保证操作一定被终止
5. 重连需要完整握手：不支持断点续传，重连后必须重新初始化
6. 错误不应静默：所有错误都应通过适当途径传递给上层
7. Server 无跨连接状态：每次连接都是独立的会话（除非 Server 实现显式管理）

十一、常见误区

1. 认为 initialized 需要 Server 回复：initialized 是 notification，不是 request，Server 不回复
2. 认为能力变更会自动推送完整列表：listChanged 只是一个信号，Client 需要主动调用 list 接口
3. 认为取消是同步的：$/cancel 是通知，不等待确认，也不保证立即生效
4. 认为重连后状态会自动恢复：订阅、日志级别等连接级状态需要重新设置
5. 忽略初始化顺序：必须先完成 initialize → initialized，才能发送其他请求
6. 认为 Server 崩溃时进行中的请求会返回错误：实际上请求会直接丢失，Client 必须自行处理
7. 混淆 stdio 和 HTTP 的生命周期差异：stdio 的生命周期绑定到进程，HTTP 的生命周期由连接状态决定
8. 认为 $/cancel 之后请求 ID 可以复用：被取消的请求 ID 不应被重用

十二、实践检查清单

• 实现完整的初始化握手流程（initialize → response → initialized）
• 正确处理协议版本协商，拒绝不兼容的版本
• 在初始化完成前不发送任何业务请求
• 处理 Server 能力中 listChanged 标志，实现动态列表刷新
• 实现 $/cancel 发送逻辑，支持用户取消长时间操作
• 检测并处理异常断开（进程退出、网络错误、超时）
• 实现重连策略（退避重试、最大重试次数、用户通知）
• 重连后重新执行完整的初始化和能力发现流程
• 优雅关闭时等待进行中的请求完成或取消
• 记录初始化失败和异常断开的详细日志
• 处理采样请求（sampling）的反向调用流程
• 测试 Server 崩溃场景下的 Client 行为

十三、与其他概念的关系

• MCP基础：生命周期中涉及的核心概念（Tool、Resource、Prompt）定义于此
• MCP架构总览：生命周期是架构中控制面的核心部分，三层架构（Host → Client → Server）决定了生命周期的启动方式
• MCP通信与传输：传输层（stdio / HTTP）决定了连接建立和断开的具体机制
• MCP能力发现：能力协商和动态更新是生命周期中初始化阶段和运行阶段的关键活动
• MCP错误处理：初始化失败、异常断开、取消操作都是错误处理的子场景
• MCP Client设计：Client 是生命周期的主要驱动方，负责发起握手、管理状态、处理异常
• MCP Server设计：Server 是生命周期的响应方，需要正确响应握手、声明能力、处理取消

十四、适用边界

本文描述的生命周期适用于：

• 所有遵循 MCP 规范的 Client 和 Server 实现
• stdio 和 Streamable HTTP 两种传输方式
• 单 Client 单 Server 的连接拓扑
• 需要处理连接异常和重连的场景

不适用于：

• MCP Gateway 的多路复用场景（Gateway 内部管理多个后端连接的生命周期）
• Server 之间的直接通信（MCP 不定义 Server-to-Server 协议）
• 非 MCP 协议的连接管理（如 WebSocket 长连接、gRPC stream）
• Agent 框架内部的状态管理（MCP 不管理 Agent 状态）

十五、延伸思考

1. 当前生命周期假设每次重连都是完整的重新初始化，是否有可能设计轻量级的会话恢复机制？
2. 能力变更通知（listChanged）采用「信号 + 重新拉取」模式，在大规模场景下是否会产生性能瓶颈？是否需要增量推送机制？
3. $/cancel 是尽力而为的通知，对于需要强一致性取消的场景（如分布式事务），是否需要更可靠的取消协议？
4. 当 Client 同时连接多个 Server 时，一个 Server 的异常断开是否应该影响其他 Server 的请求处理？如何设计隔离策略？
5. 采样请求（sampling）使 Server 可以反向调用 Client 的模型能力，这种双向调用模式是否会在未来扩展到更多场景？

十六、参考资料

• MCP 官方规范 - https://modelcontextprotocol.io/specification
• MCP 官方文档 - https://modelcontextprotocol.io/
• MCP GitHub - https://github.com/modelcontextprotocol
• MCP 规范 - Lifecycle 章节 - https://modelcontextprotocol.io/specification/#lifecycle