MCP 协议支持哪两种模式？
这道题考的是对 MCP 协议传输层设计的理解，属于基础概念题。面试官想看你知不知道 MCP 协议是怎么实现通信的，以及什么时候该用什么模式。
我从三个方面来讲：先说 MCP 协议是什么，再详解两种传输模式，最后聊聊为什么这么设计。
MCP 协议是什么
MCP，全称 Model Context Protocol，是 Anthropic 在 2024 年底推出的开放协议标准。说白了，它就是给 AI 应用定了一套"怎么跟外部资源打交道"的规则。
有什么用？解决 AI 应用的数据孤岛问题。
以前 AI 模型想访问你的数据库、文件系统、API，得针对每个数据源单独写代码。有了 MCP，就像有了一个通用的"插口"——不管什么数据源，只要实现 MCP 协议，AI 模型就能统一调用。
你可以把它理解成 AI 应用的"USB-C 端口"。不管什么品牌的设备，插上就能用，实现 AI 模型与数据源、工具的即插即连。
MCP 的架构里有四个核心组件：
- Host：AI 应用的主入口，比如 Claude Desktop 或者你的聊天机器人
- Client：运行在 Host 里的客户端，负责与 Server 保持连接
- Server：暴露能力的服务端，比如文件服务器、数据库服务器
- 基础协议：定义了 Client 和 Server 之间怎么通信——也就是今天要讲的两种传输模式
两种传输模式详解
MCP 协议支持 STDIO 和 HTTP + SSE 两种传输模式。这俩不是"可选功能"，而是覆盖了不同的通信场景。
STDIO 模式
STDIO 就是标准输入输出。进程 A 把数据写到标准输出，进程 B 从标准输入读进来，数据直接在进程间"流淌"。
这种模式的特点：
- 延迟极低，因为不走网络
- 部署简单，不需要额外配置
- 只能用于本地进程间通信
典型场景：你在 IDE 里装个 MCP 插件，插件作为 Host 直接调用本地 MCP 服务器。这种情况下进程就在同一台机器上，STDIO 是最优解。
HTTP + SSE 模式
HTTP + SSE 结合了 HTTP 的请求-响应机制和 Server-Sent Events 的服务端推送能力。
为什么需要 SSE？因为 AI 场景里，Server 经常需要主动给 Client 推送消息。比如你问了一个复杂问题，Server 处理完了得主动告诉你结果，不能等你一直轮询。
这种模式的特点：
- 支持网络远程通信
- 能穿透防火墙，跨机器调用
- 支持服务端主动推送
- 适合分布式部署场景
典型场景：你的 AI 应用要连接云端的各种服务，或者团队有多台服务器需要共享 MCP 能力，这时候用 HTTP + SSE。
简单记：本地直连用 STDIO，云端部署用 HTTP + SSE。
为什么设计两种模式
设计两种模式，不是为了增加复杂度，而是为了覆盖实际工作中的两种典型场景。
本地开发场景
你在本地开发 AI 应用，需要快速调试、即时响应。用 STDIO 模式，进程直接通信，延迟可以忽略不计。配置也简单，不用开端口、不用管网络，直接跑起来。
云端部署场景
应用上线了，部署到服务器上，可能需要调用多台机器上的不同服务。这时候 STDIO 就玩不转了——进程不在同一台机器上，没法直连。换成 HTTP + SSE，通过网络请求调用，还能利用 SSE 实时接收服务端推送。
说白了，这两种模式就像两套工具：
- STDIO 是"螺丝刀"，本地快速作业
- HTTP + SSE 是"电动工具套装"，远程复杂任务
MCP 协议的设计哲学就是：协议层统一抽象，传输层按需选择。你写业务代码的时候不用管底层用哪种模式，但面试的时候得能说清楚这两种模式的区别和适用场景。
面试怎么答
基础版（记住这一段就够了）：
MCP 协议支持 STDIO 和 HTTP + SSE 两种传输模式。STDIO 用于本地进程间通信，具有低延迟、部署简单的优势；HTTP + SSE 用于网络远程通信，支持服务端推送能力，适合分布式部署场景。
加分版（能讲出设计思路）：
MCP 的两种传输模式各有分工。STDIO 通过标准输入输出进行通信，适合 Host 应用直接调用本地 MCP 服务器的场景，延迟最低；HTTP + SSE 结合了 HTTP 请求响应和 Server-Sent Events 推送能力，适合跨机器、跨网络的分布式调用场景，部署更灵活。这种设计让 MCP 既能满足本地快速响应的需求，也能支持云端分布式部署。
一句话总结
MCP 协议用 STDIO 和 HTTP + SSE 两种模式，覆盖了本地低延迟通信和远程网络通信两种场景。