Q62 · MCP 的流式 HTTP 传输核心优势是什么？

公司有一个客服 Agent，运行在应用服务器上；订单查询工具由另一组团队维护，部署在远处的服务里。用户问：“订单 A123 现在到哪了？”如果工具只在 Agent 本机的子进程里运行，跨服务部署和独立维护都不方便。MCP 的 Streamable HTTP 让客户端通过 HTTP 向远程 MCP 服务发消息：每条消息都是发到同一个 MCP 端点的一次 POST；服务端可按这次请求的需要，返回一次性 JSON，或者在这次请求的 SSE 响应流里先报告相关进度、最后给出结果。MCP 2026-07-28 Streamable HTTP 规范

它的核心优势可概括为：**远程部署更自然，复用现有 HTTP 网关与鉴权等设施；同一端点同时支持快速的一次性结果和耗时请求的渐进反馈；每条请求有明确边界，便于独立处理和取消。**但“流式”不是所有调用都会边生成边回，不自动降低工具总耗时，也不自动解决权限、重试与结果可信度。尤其要注明协议版本：2026-07-28 版已经移除了旧版的 GET 流入口和协议级会话，旧教程中的握手、会话头或独立 GET SSE 流不能直接照搬到新版。MCP 传输概览、Streamable HTTP 版本说明

术语解释：先知道每层是什么

词或符号	通俗解释	本题例子
MCP	规定 AI 应用怎样发现、调用外部能力及交换资料的协议	Agent 通过标准方式查询订单
Host	持有用户对话并决定把哪些能力交给模型使用的应用	客服 Agent 所在的应用
MCP Client	Host 内负责和某个 MCP Server 通信的组件	向售后服务发协议消息
MCP Server	对外提供 Tools、Resources 或 Prompts 的服务	订单查询服务
Transport（传输）	消息如何在两个进程或服务器之间送达	本题使用 HTTP，而非本地 stdio
HTTP POST	客户端把一份请求正文送到服务器的 HTTP 方法	向 /mcp 发送 tools/call
/mcp	示例端点路径；实际服务可自行选择路径	多种 MCP 方法共用同一 URL
JSON-RPC	消息的外层格式，包含方法、请求 ID、参数及响应	method="tools/call" 表示调用工具
id	当前 JSON-RPC 请求的标识，用于把响应对应回请求	id: 7 的结果回给 7 号请求
SSE	Server-Sent Events，服务器在一条 HTTP 响应里按事件逐条向客户端发送内容	查询较慢时先告知进度，再给结果
application/json	服务器一次返回一个 JSON 对象的响应类型	查缓存订单很快，直接返回结果
text/event-stream	SSE 流的响应类型	跨系统汇总订单进度时逐步发事件
网关或反向代理	HTTP 请求进入业务服务前经过的转发层	统一路由、鉴权、日志或限流
请求范围	一条 SSE 流只服务于发起它的那次请求	A123 的进度不会随意混入 B456 的流

这里的 A123、B456 是虚构订单号；“查订单”只是示例工具。POST A、POST B 指两次不同的 HTTP 请求，并非 MCP 规定的字段。文中说的“渐进反馈”是服务端可发送与请求有关的进度通知，不是模型回答必然逐 token 输出。

一次快查询和一次慢查询，返回方式为什么不同

图中两封信都从左侧的应用发向右侧的 MCP Server。上面的 POST A 很快，服务器沿红色返回路线一次返回 JSON；下面的 POST B 较慢，服务器沿蓝色路线把“进度 1、进度 2、最终结果”逐次送回。图里的网关只表示 HTTP 基础设施可参与转发和安全控制，不表示只要用了网关就自动完成鉴权；身份、权限和代理配置仍由部署者负责。

按当前 2026-07-28 规范，客户端把每条 JSON-RPC 请求或通知分别发到同一个 MCP HTTP 端点，服务端对请求可以选择 application/json 或 text/event-stream。客户端必须能处理这两种响应；不能写成“此端点永远只有 SSE”，也不能把 SSE 当成必须存在的第二个永久 GET 通道。若是 SSE 响应，进度通知必须和发起的请求有关，最终返回该请求的 JSON-RPC 结果或错误。规范建议最终响应后结束流。Streamable HTTP：Sending Messages / Receiving Messages

用 A123 举例：Agent 决定查物流，Host 的 MCP Client 发 tools/call 给远程服务。若订单服务马上查到“已出库”，一份 JSON 结果就足够，没必要为了“流式”额外保持响应。如果需要依次向仓储和快递系统查询，服务器可在这次请求的 SSE 流里送“已连接仓储”“正在核对快递”等进度通知，最后送最终结果。用户界面是否展示这些进度，由 Host 决定；业务上能否相信“已出库”，还要看查询来源与权限。

一个只展示核心形状的 HTTP 示例是：

POST /mcp HTTP/1.1
Content-Type: application/json
Accept: application/json, text/event-stream
MCP-Protocol-Version: 2026-07-28
Mcp-Method: tools/call
Mcp-Name: get_order_status

{ "jsonrpc": "2.0", "id": 7, "method": "tools/call",
  "params": { "name": "get_order_status", "arguments": { "order_id": "A123" },
    "_meta": {
      "io.modelcontextprotocol/protocolVersion": "2026-07-28",
      "io.modelcontextprotocol/clientInfo": { "name": "SupportHost", "version": "1.0.0" },
      "io.modelcontextprotocol/clientCapabilities": {}
    }
  }
}

Mcp-Method 与正文的 method 都表示“调用工具”；Mcp-Name 与正文中的 name 都指 get_order_status；order_id 是工具的业务参数；_meta 里的版本和客户端能力是本次请求附带的协议元数据。头和正文相应字段必须一致，不能由网关看到一种方法、业务服务却执行另一种方法。示例省略了实际 Host 需要准备的身份凭证、服务地址与权限配置，因此不是可直接复制进生产环境的完整请求；格式依据当前传输规范。Streamable HTTP：Request Metadata / Server Validation

三个核心优势分别从哪里来

远程部署与现有基础设施相配。stdio 方式适合 Host 启动本地子进程并通过标准输入输出通信；Streamable HTTP 则适合服务器作为独立进程，接收多个远程客户端连接。团队能把订单工具部署在自己的服务中，再经过已有的 HTTPS 入口、网关、监控和权限系统对外提供。HTTP 头还镜像了一些请求元数据，使网关能在不解析 JSON 正文时做路由与观测；正文仍是协议元数据的真实来源，服务端应校验头与正文一致。“更适合远程”是架构便利，不是说 HTTP 一定比本机 stdio 更快。MCP 传输概览、Streamable HTTP：Request Metadata

响应形式可以按请求选择。同一端点的快速调用直接返回一个 JSON，慢调用可返回 SSE，先给与本次请求相关的进度通知，再给最终响应。用户可以更早知道“正在核对仓储”，而不用盯着空白界面；但进度反馈改善的是等待体验，通常不代表服务器更早完成工作。如果反向代理缓存了 SSE 数据，页面仍可能等到最后才收到进度，所以规范建议在发起 SSE 时使用 X-Accel-Buffering: no，并考虑代理和客户端的超时配置。Streamable HTTP：Receiving Messages

每次请求的边界清楚。A123 和 B456 各有自己的 HTTP POST 与响应，按 JSON-RPC 的请求 ID 对应结果。对于一个进行中的 SSE 请求，客户端关闭该请求的响应流可表示取消；服务端应尽快停止该请求相关的工作，并不再给它发消息。不同请求可以由服务端独立处理，但这不等于无限并发：线程池、连接数、订单后端容量、租户限额以及写操作冲突仍需要应用控制。当前协议还强调无协议级会话：服务端不能仅凭“是同一条 HTTP 连接”推断它属于同一轮对话，需要跨请求的业务状态必须有显式标识。MCP Base Protocol：Statelessness、Streamable HTTP：Cancellation

不要把新版与旧版教程混在一起

MCP 的传输设计经历过变化。2024-11-05 版使用过 HTTP+SSE；2025-03-26 版引入 Streamable HTTP；2026-07-28 版进一步取消 GET 流入口与协议级会话。旧版本还可能出现 initialize 握手、会话 ID、服务器通过 SSE 流发起独立 JSON-RPC 请求等描述。今天讲新规范时，不能把它们不加版本标注地拼成一张“现行调用时序图”。若项目需要连旧 MCP 服务，应按官方的向后兼容流程检测版本并适配，而不是让新版客户端静默假设旧报文也符合新协议。Streamable HTTP：版本说明与兼容性、MCP 传输概览：Backward Compatibility

还要区分两类流：

流	如何建立	用来做什么
某次 tools/call 的 SSE 响应	发起该次 POST，服务器选择 SSE 响应	这次工具调用的进度和最终结果
长时间订阅变更	客户端发送 subscriptions/listen 请求，其响应保持为 SSE 流	监听已订阅的工具列表或资源更新等变化

订阅流仍是某个请求的响应，不是旧版那种独立 GET 流入口；tools/call 的进度通知也不应跑到订阅流里。当前规范还说明 SSE Last-Event-ID 续传不受支持，所以不能承诺“网络断开后从上一条事件无缝恢复”。若业务需要可靠长任务、断线恢复和结果查询，应在业务层设计任务 ID、状态查询和幂等逻辑。Streamable HTTP：Receiving Messages

实际接入时仍要补齐什么

首先是安全。远程 HTTP 服务要验证来源并做身份认证、授权；当前规范要求服务器验证传入的 Origin，若值存在但非法须返回 403，本地服务推荐只绑定回环地址。网关上有令牌并不意味着每个用户都能查每个订单：业务服务还要核实当前用户是否有权读取 A123，写工具必须再做更严格的审批与幂等。工具返回的文字只是外部数据，不能因为走的是标准 MCP 传输，就被当成可修改 Agent 指令的高权限内容。Streamable HTTP：Security & Endpoint、MCP 安全最佳实践

其次是故障处理。要区分 HTTP 网络错误、协议版本不兼容、JSON-RPC 错误、工具自己返回“订单不存在”以及 SSE 流中途断开。收到一次“已查询仓储”的进度，不等于已经有最终订单结果。写操作在网络超时后不能盲目重试，先查外部动作是否真的生效，再使用业务幂等键。对于读操作可设超时和有限重试，但要限制同时发出的请求数，避免订单系统被 Agent 的循环拖垮。日志至少记录请求 ID、方法、工具名、耗时、最终结果类别和失败层级；敏感订单内容要按业务规则脱敏。

最后是产品体验。只在用户确实需要等待反馈时展示进度，避免把底层每条通知原样刷到界面。若网关不支持流式透传，就回退成单次 JSON 或适配代理配置；不要依赖“有 SSE”就假设用户一定能看到实时信息。部署方便、反馈更及时、请求边界明确是这道题应该抓住的价值；安全、可靠性和业务正确性仍需单独建设。

面试时可以这样回答

MCP 的 Streamable HTTP 主要让远程 MCP Server 易于通过现有 HTTP 基础设施接入。按 2026-07-28 规范，每条 JSON-RPC 消息单独 POST 到同一个 MCP 端点；服务端可以对快速请求一次返回 JSON，对耗时请求在该请求的 SSE 响应里先发相关进度，再发最终结果。这样网关、鉴权、观测和独立部署更容易融入现有服务体系，客户端也能明确按请求处理结果和取消。但流式反馈不等于总耗时缩短，也不自动保证安全或可靠续传；代理缓冲、超时、权限、并发和写操作幂等仍要设计。还要注意当前版本已移除旧版 GET 流与协议级会话，不能把不同版本的时序混写。

如果追问“所有响应都必须走 SSE 吗”，回答：不需要；服务器可按请求返回一次性 JSON 或 SSE，客户端须支持两种。如果追问“取消 SSE 后是不是保证订单后端绝不会继续工作”，回答：规范要求服务器尽快停止与该请求有关的工作，但已经发生的外部副作用无法靠关闭连接自动撤销；应查询业务系统最终状态。

资料来源

• MCP 官方规范：Transports Overview（2026-07-28）
• MCP 官方规范：Streamable HTTP（2026-07-28）
• MCP 官方规范：Base Protocol / Statelessness（2026-07-28）
• MCP 官方文档：Security Best Practices