MCP 的传输层有哪些方式，stdio 和 Streamable HTTP 分别适合什么场景？｜腾讯 C/C++面经解析

60 秒回答模板

MCP 可以理解为让模型应用连接外部工具、资源和提示的一套协议，它把 Host、Client、Server 之间的能力发现、工具调用、资源读取和通知机制标准化。问通信协议时要谨慎区分协议语义和传输层：MCP 的消息使用 JSON-RPC，请求、响应和通知有统一结构；传输层可以有不同实现。本地插件或命令行工具常用 stdio，优点是简单、低部署成本、适合单机进程；远程服务可用 HTTP 类传输，旧规范中有 HTTP+SSE 传输；当前远程回答应以 Streamable HTTP 为主，同时说明 SSE 仍可能作为 Streamable HTTP 中服务端流式消息的一种承载方式。选型时看部署位置、连接生命周期、双向流式需求、鉴权、安全隔离、代理兼容和运维成本。不要把某一种旧的 SSE 说成唯一标准，面试里更稳妥的回答是 MCP 抽象协议稳定，传输层按本地和远程场景取舍。

考点 协议定位

难度 真实面经题

回答目标 讲清协议形态和工程取舍

深入解析

先说明 MCP 解决什么问题

MCP 的核心是让模型应用以统一方式发现和调用外部能力。Host 承载用户和模型交互，Client 负责和某个 MCP Server 连接，Server 暴露工具、资源和提示。它解决的是上下文和工具接入标准化，而不是单纯发 HTTP 请求。

协议语义和传输层要分开

面试官问通信协议时，容易把消息格式和传输方式混在一起。更准确的说法是：MCP 有统一的请求、响应、通知和能力协商语义，消息使用 JSON-RPC；这些消息可以跑在不同传输上。

stdio 适合本地进程集成

stdio 传输适合本地工具、桌面应用和开发环境。Client 启动 Server 子进程，通过标准输入输出交换消息，部署简单、权限边界相对清楚，但不适合多用户远程服务，也不天然解决网络鉴权和水平扩展。

HTTP 类传输适合远程 MCP Server

远程 MCP Server 更适合 HTTP 类传输，因为它能接入网关、鉴权、负载均衡、日志和云服务运维。历史上会看到 HTTP+SSE 传输；当前回答应把 Streamable HTTP 作为远程传输中心，同时说明 SSE 仍可能承载服务端流式消息，而不是把旧 SSE 表述固定成唯一答案。

选型看连接和安全要求

如果工具只在本机运行，stdio 成本低；如果要服务多个客户端、跨网络访问、做 OAuth 或企业鉴权、记录审计日志，就更适合 HTTP 类方案。还要考虑连接保活、断线重连、流式消息、代理兼容、超时、限流和敏感工具隔离。

回答要避免把 MCP 等同于 Agent 框架

Agent 框架可以使用 MCP，但 MCP 本身不是完整 Agent 框架。它不替你决定规划、记忆、反思或任务拆解，而是规范模型应用如何连接工具和上下文。传输层只是其中一部分，不能只背一个协议名。

易错点

把 MCP 说成一个 Agent 框架，而不是模型应用连接工具和上下文的协议。
只背 SSE 一个词，没有说明 stdio、本地进程、当前远程 Streamable HTTP 和历史 HTTP+SSE 语境的取舍。
把 JSON-RPC 消息语义和底层网络传输混为一谈。
忽略鉴权、授权、审计、限流和工具隔离，导致回答只有协议名没有工程判断。
认为 stdio 只能玩具使用，没有说明它在本地工具和桌面集成里的优势。
把远程 MCP 当成普通 REST 调用，漏掉能力发现、工具 schema、资源和通知等语义。

面试官追问

MCP 和普通 REST API 有什么区别？

REST API 通常是业务接口集合，MCP 更关注模型应用如何发现工具、读取资源、发送结构化调用并处理上下文能力，语义更贴近模型工具接入。

为什么本地 MCP Server 常用 stdio？

因为本地场景可以由客户端直接启动子进程，标准输入输出足够交换消息，部署简单，也避免为每个本地工具开网络端口。

远程 MCP Server 为什么更适合 HTTP 类传输？

远程服务需要鉴权、网关、负载均衡、审计、限流和跨网络访问，HTTP 生态更成熟，也更容易和企业基础设施结合。

回答 MCP 传输时最容易踩的坑是什么？

最容易把某个历史实现当成唯一标准。更稳妥的回答是说明 MCP 的协议语义，再按本地 stdio、当前远程 Streamable HTTP 和旧 HTTP+SSE 历史语境做传输取舍。