面经策

MCP 协议支持哪些模式？ ​

  • 标签：大模型、AI、MCP、协议设计

🏛 业务架构师 ​

MCP 的"模式"我从两个维度回答——生命周期模式和传输模式，业务上更关心前者：

生命周期上的两种模式：

  • 本地模式（stdio）：MCP Server 作为子进程跑在用户本机，通过标准输入输出通信。适合个人工具（本地文件、IDE 集成），零部署，但企业管控弱。
  • 远程模式（Client-Server，HTTP/Streamable HTTP）：Server 独立部署为网络服务，支持 OAuth2 鉴权、审计日志、集中治理。这是 2025 年协议规范更新的重点，也是企业级落地的主流——工具能力收归平台统一管控，而不是散落在每个人电脑上。

协议交互模式：请求-响应（调用工具、读资源）、通知（单向事件）、服务端流式推送（长任务进度）。

业务选型建议：个人效率工具用本地模式，快；凡是要进生产流程的（CRM、ERP、内部数据），一律远程模式+网关层统一鉴权审计——否则"哪个 Agent 用了什么数据干了什么"都说不清，合规一票否决。2026 年企业落地的明显趋势是：自建 MCP Gateway 把三方和内部 Server 统一收口，像管理 API 一样管理 MCP 服务。

🏗 系统架构师 ​

MCP 的"模式"我分两个维度回答——生命周期模式和传输模式，面试常考的是前者：

生命周期三阶段：

  • Initialization（初始化）：Client 与 Server 握手，交换 protocolVersion 和 capabilities（支持哪些原语、哪些特性），协商出双方可用的能力交集；
  • Operation（运行）：正常的请求/响应交互——tools/list、tools/call、resources/read 等消息交换，包括通知（cancellation、progress）；
  • Shutdown（关闭）：优雅断开，释放连接与子进程资源。

传输模式两种：

  • stdio：Server 作为本地子进程，标准输入输出通信——零网络开销、进程隔离，适合本地开发工具（IDE 场景）；
  • Streamable HTTP（取代旧的 HTTP+SSE 双端点设计）：远程 Server 走 HTTP POST，响应可升级为 SSE 流式推送——适合企业级集中部署、多客户端共享。

架构权衡：stdio 部署简单但每客户端一个进程实例，无法集中治理；HTTP 模式支持统一网关收口（鉴权、限流、审计），是生产标配。远程模式还引入了断线重连与消息幂等问题，长任务依赖 progress 通知 + 可恢复会话。我的实践：本地开发 stdio 快速验证，生产一律 Streamable HTTP + 网关治理。

💻 全栈开发专家 ​

MCP 的「模式」要从两个层面回答：

1. 通信传输模式：

  • stdio：Host 把 Server 当子进程拉起，标准输入输出上跑 JSON-RPC。本地开发、个人工具的默认方式，配置零网络开销；
  • Streamable HTTP（取代旧 HTTP+SSE 双端点）：单 HTTP 端点，支持 POST 双向消息和 SSE 流式推送，服务端可无状态水平扩展，是企业内远程 MCP 的标准形态。

2. 消息交换模式（JSON-RPC 2.0）：

  • Request/Response：initialize 握手、tools/list、tools/call、resources/read 等，一问一答；
  • Notification：单向通知，无响应，如 notifications/initialized、工具列表变更 tools/list_changed；
  • 流式：长任务 tools/call 过程中通过 progress notification 推进度（notifications/progress），结果可分块返回。

初始化序列：client 发 initialize（协议版本+capabilities）→ server 回应自己的 capabilities → client 发 initialized 通知 → 进入正常工作。

踩坑记录：Streamable HTTP 经过代理要确认支持 SSE 长连接（Nginx 关 buffering、加读超时）；协议版本协商不一致（2024-11-05 vs 2025-03-26 vs 2025-06-18）会出现静默降级，跨版本集成时抓包对齐版本号。