先说一下我对 Streamable HTTP 的定位这是 MCPModel Context Protocol传输层的一次重要收敛。如果你之前折腾过 MCP 的 HTTP 传输一定见过旧版那套让人头皮发麻的多端点设计——/initialize、/messages、/notifications 各管一段客户端要拼不同的 URL 去请求不同功能配置起来绕排查起来更绕。Streamable HTTP 把这一切揉进一个东西里一个端点、一条 URL、POST 命令走天下。从 2025 年的实际体验来看它已经成了 MCP Server 接入的首选方式尤其适合要对接远程服务、又对实时性有要求的场景。这篇文章不打算做教科书式科普而是站在实际搭建和联调的角度把 Streamable HTTP 为什么这么设计、底层怎么工作、手把手怎么落地、以及我踩过的那些坑一次讲清楚。无论你是刚接触 MCP 的新手还是已经在跑 MCP Server、想从旧版 HTTP 迁移的老手这篇都能给你省下不少排查时间。1. 从 HTTP 到 Streamable HTTPMCP 传输层为什么非要折腾一次1.1 旧版 HTTP 传输到底别扭在哪MCP 协议在设计之初传输层其实是有分叉的本地用 stdio远程用 HTTP。HTTP 这套在很长一段时间里走的是“多端点 JSON 响应”老路子客户端发一条 JSON-RPC 消息服务端回一条 JSON-RPC 响应看起来规矩实际上全是坑。第一个坑是端点太多。以当时的 MCP HTTP 为例客户端要交互至少得面对几个不同的 URL 路径初始化得请求一个地址后续的消息投递又得走另一个地址通知类消息可能还要再单独处理。你说这有啥大不了的但在配置权限、反向代理、网关白名单的时候多一个端点就多一层过滤规则。我有一次帮朋友调他的 MCP 服务他在 Nginx 里只放行了一个路径结果消息投递那步死活不通报错日志翻半天才想起来还有个 /messages 路径没放行。这就是典型的多端点设计带来的运维摩擦。第二个坑是服务端没法主动“说话”。旧版 HTTP 的响应模型基于经典的一问一答客户端必须持续轮询才能拿到服务端的状态变化。而 MCP 的场景里服务端经常要主动推送消息——比如某个工具执行到一半要给客户端回传一个进度更新或者一个长时间运行的任务要发一条通知。用纯 JSON 响应模式做这件事要么客户端自己定时拉要么就得在服务端和客户端之间额外搭一套长连接。我见过有人为了做这个硬生生在旁边挂了个 WebSocket 网关等于一个 MCP 服务要维护两套传输机制想想都头大。第三个坑是流式输出的实现成本高。MCP 的很多工具返回的是流式数据典型的就是大模型生成文本一边生成一边吐 token。旧版 HTTP 里你要实现这种效果得自己定义流式格式、自己搞分片、自己设计客户端解析规则。说句不好听的这已经不是 MCP 协议该管的事了但现实是你不自己搞客户端就拿不到实时输出体验直接回到“转圈圈等全部返回”。所以旧版 HTTP 这套本地小范围用用还能凑合一旦要上生产、要跨网络、要对接各种 Agent 客户端它的设计短板就会暴露得特别明显。这也是为什么 MCP 社区后来力推 Streamable HTTP——它就是针对上面这些痛点来补的。1.2 Streamable HTTP 的核心设计目标Streamable HTTP 的设计目标说白了就是三句话端点收敛、流式内建、状态可恢复。端点收敛先把“一个功能一个 URL”的旧思路打破改成只暴露一个端点。客户端只认一个 URL所有 JSON-RPC 消息都往这一个地址上 POST服务端自己根据消息内容做分发。这种设计在架构上省掉了一大堆路由配置和网络白名单也让 MCP Server 对网关和代理的适配变得极其简单。流式内建则是把对 text/event-stream 的支持作为传输层的基本要求客户端发起请求的时候声明自己愿意接受流式响应服务端就可以随时切换成流式推送。这个能力最直接的好处就是服务端不用再“攒够一整个结果才返回”而是处理到哪就推到哪客户端体验从“等待完整响应”变成“实时接收增量”。状态可恢复稍微进阶一点它允许客户端在一个请求上指定从某个位置继续接收数据流。你听着可能觉得陌生实际用起来非常关键——长任务执行到一半网络抖了一下客户端只要拿着之前的会话标识和游标再发一次请求就能从断点把剩下的数据接上而不是整个任务从头再跑一遍。这一条对于跑大模型推理、长时间数据分析这类场景来说不是锦上添花是刚需。这三个目标合并起来本质上回答了一个问题MCP 作为 AI 与工具之间的“对话总线”它的传输层到底应该长什么样社区给的答案很明确——像 HTTP 一样简单像流一样实时像可靠的消息队列一样不丢数据。当然任何设计都有取舍后面我会讲到它在实际部署中不那么完美的地方。1.3 HTTP 流与 WebSocket另一个维度的对比聊 Streamable HTTP很难不让人拿它跟 WebSocket 做比较。毕竟 WebSocket 也是做双向实时通信的老选手了为什么 MCP 不直接选 WebSocket 做传输层我的理解是这样的WebSocket 是一种全双工长连接协议它本身确实很适合高频互推的场景一旦连接建立两端随时都能发数据延迟极低。但它的短板也很明显——不是一个严格遵循请求-响应语义的协议。这对 MCP 这种以 JSON-RPC 为核心的场景是不太友好的因为 MCP 的大多数交互本质还是一问一答只是问和答之间可能夹杂着流式推送。要把 JSON-RPC 塞进 WebSocket你就得自己在帧里定义消息边界、设计心跳、处理粘包这些工作协议本身不给你管最后还是要自己写一遍。还有一个更实际的考虑基础设施兼容性。HTTP 生态的成熟度比 WebSocket 高太多了Nginx、云负载均衡、防火墙、边缘网关这些网络设施对 HTTP 的优化和容忍机制都非常完善。Streamable HTTP 在普通 HTTP 之上增加了流式响应能力但底层仍然是标准 HTTP这就意味着它可以直接享受一套成熟的链路治理能力不会因为要上 WebSocket 而把运维体系推倒重来。我实际部署下来的感受是Streamable HTTP 对于想快速把 MCP 服务跑起来、又不想被网络设施折腾的人来说确实是当前最省心的一条路。2. 单一端点一个 URL 承载全部 JSON-RPC 交互2.1 为什么“少即是多”在协议设计里同样成立很多人看到“单一端点”的第一反应是一个地址能搞定所有事会不会太挤了我最初也有这个疑虑但深入了解后才发现单一端点并不是把功能揉成一团浆糊而是把“路由责任”从客户端转移到服务端。在旧版多端点设计里客户端要自己判断“我这条 initialize 应该发给谁”“那条 notification 又该发给谁”路由逻辑散落在客户端代码里。一旦服务端的结构变了客户端得跟着改两端耦合得厉害。而单一端点的思路是所有消息都发到同一个入口由服务端根据消息的 method 字段统一分发。客户端不再关心服务端内部把哪个能力放在了哪个路径下面它只认一个地址服务端怎么处理是服务端的事。这种设计对客户端 SDK 的简化是立竿见影的。我之前用过的几个 MCP 客户端库在旧版 HTTP 模式下都要专门维护一串端点配置写上好几个 URL还要对应写清每个 URL 的用途。到了 Streamable HTTP配置项变成了一个 baseUrl初始化的时候填一次剩下的事情库内部全部自动处理。对于开发者来说少一个配置项就少一类潜在错误这在实际运维里的价值远大于它听起来的样子。2.2 一看就会的端点路由逻辑单一端点上跑的是完整的 JSON-RPC 2.0 消息服务端的路由判断主要依赖两个信息method 字段和消息方向。method 决定了这条消息要调用的是哪一类能力方向则决定了这条消息是客户端请求还是服务端推送。举个实例客户端发一条 method 为 initialize 的请求服务端收到后识别到这是初始化指令就执行握手流程返回协议版本、能力列表这些信息。后面再收到 tools/call 这种请求就转到工具执行模块。整个过程都在同一个 URL 上完成就像你去一家餐厅菜单上的菜都从同一个厨房出而不是每道菜要跑到不同的后厨窗口去取。有一种情况要特别注意Streamable HTTP 把“请求通道”和“响应通道”在逻辑上分开了。客户端发起一个 POST 请求服务端可以根据需要选择直接返回一个普通 JSON 响应也可以返回一个 SSE 流。而服务端后续主动下发的消息比如通知类事件会放在流里随响应一起推给客户端。这就意味着客户端在处理这个 URL 的响应时必须同时做好两套解析准备JSON 模式和 SSE 事件流模式。很多第一次接触 Streamable HTTP 的朋友在这上面吃过亏——明明请求发出去了服务端也返回了但客户端解析不了后来发现是响应头的 Content-Type 是 text/event-stream而客户端还在按 application/json 去读。2.3 会话管理与端点发现它们是表兄弟关系单一端点要正常工作光有一个 URL 是不够的还得有人记住“当前跟它对话的是谁”。这就是会话管理的职责。Streamable HTTP 里服务端会为每个客户端分配一个会话标识通常放在 MCP-Session-Id 这个响应头里返回。客户端在后续请求中要把这个标识带在请求头里回传服务端据此恢复之前的对话上下文。会话管理和端点发现之间存在一种微妙的关系客户端怎么知道这个端点支不支持会话支不支持流式响应这要靠握手阶段的能力协商。MCP 的 initialize 请求会触发服务端返回一份 server capabilities 清单里面会声明它支持哪些协议特性、传输模式。客户端拿到这份清单后才知道后面该用 JSON 模式还是 SSE 模式继续交互。我在实际联调中遇到过一种情况服务端声明自己支持 SSE 和通知但客户端 SDK 实现只在初始化时请求了一次后面拿不到任何主动通知。排查到最后发现问题不在协议层面而在于客户端在初始化之后没有保持连接或没有正确携带 Session-Id 重连。所以理解会话管理不是可有可无的细节它是整个流式通信能持续运转的地基。3. 按需流式从“等待完整响应”到“实时增量接收”3.1 流式响应的协议层实现逻辑Streamable HTTP 的“流式”本质上是把 HTTP 响应体从“一整块 JSON”变成了“持续输出的 SSE 事件流”。SSEServer-Sent Events并不是新东西它是一套已经标准化的服务器推送协议用 text/event-stream 作为 Content-Type按行解析事件数据。Streamable HTTP 做的就是把这套机制巧妙地嵌入到 JSON-RPC 的响应通道里。客户端在请求头里声明 Accept: application/json, text/event-stream服务端看到这个声明后就知道客户端具备消费流式响应的能力。接下来服务端有两种选择如果请求的结果可以一次性算完就返回普通 JSON如果请求是一个长任务或者结果适合分片推送就返回 SSE 流。前者省事后者实时全凭服务端对消息类型的判断。流的内容也不复杂每一段 SSE 事件都携带一个 JSON-RPC 消息可能是部分结果、可能是通知、也可能是错误信息。客户端每当收到一个事件就对里面的 JSON-RPC 消息做一次完整解析和处理。从用户的视角看这有点像下载一个大文件时看到的进度条——服务端一边处理一边吐数据客户端一边收一边渲染而不是傻等着整个文件传完才动手。3.2 请求阶段与响应阶段为什么要分开管这里有个容易忽略的设计点Streamable HTTP 把请求和响应在生命周期上做了分离。一个 POST 请求发出后服务端返回的不一定是一次性的东西而可能是一段“持续一段时间”的响应流。在这段时间里客户端和服务端的连接保持着数据不断流过来直到服务端主动结束流或者客户端主动断开。这个分离带来的实际影响是客户端不能用一个简单的“发请求-等响应-解析响应”三段式来处理所有交互。它必须引入“流生命周期”的概念——连接建立是起点数据到达是过程流结束是终点。中间任何一个环节都可能出错所以客户端的处理逻辑要写成事件驱动式的监听数据事件、监听错误事件、监听流结束事件而不是阻塞式地等一个返回值。我刚开始做 Streamable HTTP 集成时犯过一个很典型的错误在服务端代码里调用了返回流的方法却没注意客户端底层用的是“一次性读取完再解析”的模式导致客户端把所有流事件读完才一次性处理。功能上没错但流式带来的实时性优势全没了跟开个视频通话结果对方只发截图一样搞笑。后来把客户端切到事件驱动模式效果立竿见影工具的 token 输出像打字机一样一行一行往外蹦。3.3 可恢复流断点续传如何在实际场景中救命可恢复流真的是 Streamable HTTP 里最容易被忽视、但实战价值极高的能力。它允许客户端在请求头里带上 Last-Event-ID 或者类似的游标信息服务端识别后可以从该游标之后的数据开始继续推送而不是从零开始重新执行。举个例子。我在本地跑过一个长时间的数据分析任务MCP Server 一开始计算便通过流式响应不停地推中间结果。跑到一半公司网络抽风连接断了。在旧版模型里对不起整个计算从头再来一遍几分钟的工作量白费了。但在 Streamable HTTP 的可恢复流机制下客户端重连时带上会话标识和上一次收到的事件游标服务端直接从断点附近继续推数据任务得以无缝续跑。当然可恢复流并不是万能的。它的前提是服务端自己实现了对该机制的支持且业务逻辑本身允许从断点续算。如果服务端代码是无状态的那就别想恢复流了一切还得重来。所以我的建议是长任务类 MCP Server 在设计时最好把任务状态、事件游标这些信息持久化下来这样不管连接断多少次只要数据在任务就能接着走。我在自己的项目里甚至把游标写进了数据库配合定时任务做了自动恢复体验相当顺滑。4. 实操落地把 Streamable HTTP MCP Server 跑起来4.1 环境准备与依赖安装在开始实现之前先列一下我的实验环境方便你有参考坐标语言/框架Python 3.10 FastAPIMCP SDK官方 mcp Python SDK当前版本对 Streamable HTTP 支持已经比较稳定测试客户端MCP Inspector官方调试工具和 TypeScript SDK 自建的一个最小客户端部署形态本地直连 Nginx 反向代理两种都试过安装依赖没什么花活直接一条命令pip install mcp[streamable-http]1.2.0 fastapi uvicorn注意一点MCP Python SDK 的传输层模块在早期版本里对 Streamable HTTP 的支持还不完整装的时候务必把版本抬高一点别用老版本硬扛。我最初图省事装了个 1.0.x 的版本结果代码里连 StreamableHttpTransport 这个类都找不到排查了十分钟才反应过来是版本问题。4.2 一个最小可用的单端点实现官方 SDK 对 Streamable HTTP 的抽象已经很友好不需要自己手写 SSE 解析。下面是我跑通的最小实现代码做了精简但保留了核心逻辑from mcp.server.fastmcp import FastMCP from mcp.server.sse import SseServerTransport from starlette.applications import Starlette from starlette.routing import Route, Mount from starlette.responses import JSONResponse mcp FastMCP(demo-server) mcp.tool() def add(a: int, b: int) - int: 计算两个整数的和 return a b # 单一端点所有 MCP 消息都走 /mcp sse SseServerTransport(/mcp) async def handle_mcp(request): # 流式传输的核心把 JSON-RPC 消息处理逻辑挂到 SSE 通道上 async with sse.connect_sse(request.scope, request.receive, request._send) as streams: await mcp._mcp_server.run(streams[0], streams[1]) app Starlette( routes[ Route(/mcp, handle_mcp, methods[POST, OPTIONS]), ], )这段代码的核心就一句话所有 POST 到 /mcp 的请求全部交由同一个处理函数接管函数内部通过 sse.connect_sse 建立流式通道再把通道交给 MCP 运行时去处理 JSON-RPC 消息。看到这里你就能明白SDK 在框架层已经帮我把“单端点 流式”的复杂逻辑封装好了我只需要关心工具业务本身。运行起来也很简单uvicorn server:app --host 0.0.0.0 --port 8000然后打开 MCP Inspector把传输方式选成 Streamable HTTP填上 http://localhost:8000/mcp点连接正常情况下就能看到初始化握手成功、工具列表正常返回。4.3 客户端配置别忽略 Accept 头和会话标识服务端起来只是第一步客户端能不能顺利连上还得看几个配置细节。这里我重点说三个我踩过的点你照着查基本能躲开大部分坑。第一请求头必须声明能接受流式响应。不管用官方 SDK 还是自己发 HTTP 请求Accept 头都要写成 application/json, text/event-stream。如果你只留 application/json服务端可能会按普通 JSON 模式处理流式响应就没了。第二会话标识要保存好。第一次响应的 MCP-Session-Id 头一定要取出来存住后续请求都得带上否则服务端不知道你是谁会话直接断掉。我用 MCP Inspector 测试时就见过它自动处理 Session-Id但换到自建客户端时完全靠手动加忘了带就是 404 或者异常断连。第三CORS 别漏设置。如果你的 MCP Server 要供浏览器里的客户端访问OPTIONS 预检请求必须被正确响应CORS 头也得加上否则浏览器直接拦截从现象上看就是“连接失败”但其实不是 MCP 的问题。一个我特别推荐的调试方式是先用 curl 手动发一条初始化请求完全绕开 SDK 的封装看看裸的 HTTP 交互到底是什么样。我在调试时就是靠这一步确认了 Session-Id 的返回位置和 Accept 头的影响比盲目翻代码快太多。等到 curl 层面的交互都符合预期了再上 SDK定位问题就清晰得多。4.4 Nginx 反向代理下要注意的坑本地直连跑通之后很多人会想着挂到公网上供远程客户端使用这时候 Nginx 反向代理就上来了。Streamable HTTP 本质是 HTTP SSE所以大部分常规代理配置没问题但有三个点需要特殊处理否则连接就是不稳定。第一个是关闭缓冲。Nginx 默认会对响应做缓冲SSE 流可能被攒着不往外吐表现形式就是客户端迟迟收不到数据。解决办法是在 location 里加上 proxy_buffering off。第二个是超时时间拉长。长任务跑几分钟甚至几十分钟是常态默认的 proxy_read_timeout 60s 肯定不够建议调成 300s 或更大否则流到一半被网关掐断客户端拿到的就是一个残缺的连接。第三个是必须保证 HTTP/1.1。SSE 对连接模型有要求Nginx 默认用 HTTP/1.0 去连后端必须显式配置 proxy_http_version 1.1 才能让 keep-alive 生效。这是一段参考配置我实际用过基本没有坑location /mcp { proxy_pass http://127.0.0.1:8000; proxy_http_version 1.1; proxy_set_header Connection ; proxy_set_header Host $host; proxy_set_header X-Real-IP $remote_addr; proxy_buffering off; proxy_cache off; proxy_read_timeout 300s; proxy_send_timeout 300s; }这块配置踩完之后我的服务就正式从“本地玩具”变成了“可对外服务的工具”远程客户端连接、流式推送都没有再出过问题。5. 常见问题与排查技巧实录5.1 连接失败从请求头到防火墙的全面排查Streamable HTTP 最常见的报错就是文章开头热搜里那个场景——刚建好的服务客户端一连接就报 streamable http connect failed 或者 error posting to endpoint。我总结了一个排查顺序按这个来基本不会漏第一步查请求头。客户端有没有设置 Accept: application/json, text/event-stream如果没有一些严格实现的服务端会直接拒绝连接。第二步查路径。客户端连的是不是服务端实际暴露的端点MCP 服务可能挂在 /mcp 下也可能挂在你自定义的路径下URL 写错了那必然连不上。第三步查会话标识。如果服务端要求会话标识而客户端没带服务端可能会判定为无效会话。第四步查网络链路。本地 curl 能通说明服务端没问题就要往前查代理、查防火墙、查安全组放行。第五步查日志。这一步最直接——MCP Server 的日志会明确写出来是哪个环节挂了不用瞎猜。这里需要强调一下排查连接问题的时候一定要把“服务端日志”当最重要的信息来源。很多时候客户端报的错误信息已经被 SDK 吞了一半只给一个笼统的 connect failed根本不告诉你真实原因。我在自己的服务端里加了结构化日志把每个请求的方法、路径、头信息和错误堆栈全部打出来排查效率直接翻倍。5.2 响应流中断超时、网络抖动与游标恢复流式响应跑到一半断掉是 Streamable HTTP 场景里第二高频的问题。现象是客户端收到一部分数据后连接突然关闭后续数据全部丢失。我的排查顺序是先看是不是服务端主动断的——查日志有没有打 shutdown 或者异常再看是不是代理断的——查 Nginx 的错误日志重点看 timeout 和 upstream prematurely closed最后看是不是客户端干的——有些客户端 SDK 在读流时遇到暂时无数据会触发超时逻辑主动断开。如果是超时导致的中断解决方案就两句话调大代理的 read 超时或者让服务端定期发心跳 SSE 事件保活。如果是网络抖动导致的中断那就得靠可恢复流机制了客户端重连带上 Last-Event-ID服务端续推。这里有个独家技巧即使服务端没实现完整可恢复流只要它在推送事件的时候带上合理的 ID客户端至少能知道丢了多少数据方便做补偿处理别小看这个信息它能让你的数据对账简单很多。5.3 会话失效Session-Id 丢了、过期了、串线了关于会话实际中遇到最多的三类问题我都碰到了。Session-Id 丢失发生在服务端返回响应后客户端没有正确提取和保存它后续请求不带服务端就只能每次都当作新会话处理。排查这种问题最简单的办法就是对比连续两次请求的请求头看 Session-Id 是否一致。Session-Id 过期是因为服务端设了会话超时时间客户端太久没发请求再发就被判定失效。解决方式一般是客户端定期保活或者服务端放宽超时上限。Session-Id 串线比较隐蔽我是在多客户端并发测试时发现的——服务端在同一时间收到了多个不同客户端的请求但会话管理模块没做好隔离把 A 的上下文带到了 B 的响应里。这个问题如果不做并发测试单链路调试根本发现不了。后来我把会话存储从进程内字典换成了按 Session-Id 分片的独立存储结构每一个会话一个独立上下文彻底解决了串线问题。5.4 一个从日志入手快速定位问题的实战案例说一个我印象很深的真实排障经历。那一次我搭建的 Streamable HTTP MCP Server 在本地测试一切正常但一挂到公网客户端连接就时报 connect failed。按我平时的习惯先打日志结果服务端的访问日志里干干净净一条请求记录都没有。这说明请求根本没到服务端问题必然在网络链路的前端。我逐层排查先在公网服务器上本地 curl 服务端口通。然后从另一台机器 curl 公网 IP通。再用客户端的网络环境 curl不通。最后查安全组策略发现该服务器的安全组只放行了 80 端口没放行我的 8000 端口但我在测试时用的那台机器恰好在内网段没有触发安全组规则所以一直没暴露问题。后来我把流量改成走 80 端口的 Nginx 反向代理问题立刻消失。这个案例给我的启发是排查网络类问题网络路径上的每一跳都要单独验证不能因为“内网通”就默认“全网通”。安全组、防火墙、代理层任何一个环节漏了配置都会导致客户端连接失败而这种失败往往不会在后端日志里留下任何痕迹。5.5 常见问题速查表下面这份速查表是我实际排查中使用频率最高的几条整理出来供你直接抄作业。症状可能原因排查动作解决方案连接直接失败请求头缺少流式声明检查 Accept 头改为 application/json, text/event-stream初始化握手失败路径不对或服务未启动用 curl 直连测试验证服务状态和 URL 路径能连接但收不到推送Nginx 缓冲未关闭查代理配置设置 proxy_buffering off流跑到一半断掉代理超时时间太短查代理错误日志调大 proxy_read_timeout主动通知不触发客户端未保持连接查看会话状态事件驱动模式处理 SSE 事件多客户端上下文串线会话存储未隔离做并发测试复现按 Session-Id 独立存储上下文CORS 问题导致失败预检请求被拦截看浏览器控制台服务端配置 CORS 头6. 迁移评估从旧版 HTTP 切换的注意点与收益分析6.1 迁移前需要做出的关键决策如果你手头已经跑着旧版 HTTP 的 MCP Server回到要不要迁移到 Streamable HTTP 这个问题上我建议先评估三点而不是无脑跟风。第一你的客户端是否支持。很多 MCP 客户端 SDK 已经默认切到 Streamable HTTP但仍有部分旧版本 SDK 只认识旧版传输格式。迁移前先确认你的客户端升级到支持 Streamable HTTP 的版本否则服务端切了客户端不认等于白切。第二你的网络设施是否就绪。Streamable HTTP 对公网服务的依赖比 stdio 重得多如果你的服务只能在内网跑客户端的访问链路要先铺好。第三你的长任务是否依赖流式与恢复。如果只是简单的工具调用一次性返回结果也能接受那迁移的收益不大如果涉及长时间推理、大数据流式处理那 Streamable HTTP 的按需流式几乎是不能放弃的特性。6.2 迁移路径最小改动平滑过渡我的迁移策略是“双轨并行逐步切换”。新代码直接按 Streamable HTTP 风格写同时保留旧版传输入口对客户端无感切换。具体操作是MCP Server 里同时挂两个传输层实现——旧的保持不动新的挂在 /mcp-v2 路径下。客户端先在测试环境指向新端点并跑通全部用例然后逐步灰度切换生产流量。这个过程很稳即使新端点出了问题随时把客户端指回旧端点服务不会中断。等新端点稳定运行一段时间后再考虑停掉旧入口。这个节奏既保证了迁移的平滑性又给了自己充足的回滚空间。我强烈建议你不要做“一步到位”式迁移尤其是公网服务用户可不会等你慢慢修故障。6.3 迁移后我实际感受到的收益迁到 Streamable HTTP 之后最直观的变化是配置简洁了。以前要配一堆端点列表现在一个 baseUrl 搞定SDK 内部自己处理路由和会话我的运维配置项肉眼可见地减少。第二个明显收益是推流顺畅了以前服务端想主动给客户端推消息要额外搭通道现在流式响应天然支持进度更新、日志推送、中间结果都能直接写在流里客户端实时接收不需要任何额外机制。第三个收益是问题定位更快了。单一端点意味着日志入口集中排查链路从“查多个路径”简化成“查一个路径”效率翻倍。如果你还在用旧版 HTTP 的 MCP Server我的建议很明确只要客户端支持越早迁越好。这个协议演进方向已经非常明确早迁早受益。7. 写在最后的实操心得与扩展建议7.1 关于 Streamable HTTP我实际体验后的三点体会第一不要把“单一端点”想象得太玄乎。它的本质是路由逻辑前置服务端根据消息内容做分发而不是按路径做分发。理解这一点你设计 Server 内部结构时就自然知道该按什么粒度拆分模块——按能力拆而不是按路径拆。第二流式响应一定要在项目早期就定好数据格式。哪怕你现在只需要一次性 JSON 响应也要预留好 SSE 事件的结构和事件 ID 的生成规则。我见过太多项目后期要加流式时因为早期没留好事件 ID导致恢复流完全没法做只能大改。第三会话管理千万别用进程内变量裸奔。一旦你的服务要水平扩展进程内会话状态根本没法跨节点共享。提前把会话存储外置到 Redis 这类中间件后面扩容时你会感谢自己当时多花的这几小时。7.2 这个协议还可以怎么扩展Streamable HTTP 给了 MCP 传输层一个很好的底座让它可以直接往更多方向扩展。一个方向是结合服务发现机制做集群化部署。因为客户端只依赖一个端点服务端内部可以按需把请求路由到不同的后端节点配合上会话状态外置整个集群的伸缩性会非常好。另一个方向是接入观测体系。单一端点的特性让链路追踪变得极其方便——只要在这个端点上埋好中间件所有 MCP 交互的日志、指标都能统一采集不需要为不同端点分别埋点。还有一个方向是往边缘计算场景延伸。流式响应天然适合边缘节点就近输出客户端不需要维护多条连接只需要一个端点边缘即可动态分配最合适的后端。这些方向我都陆续在实验目前最让我期待的是集群化 会话外置的组合玩法一旦跑通MCP Server 的容量规划会灵活很多。做 MCP 相关开发这一年多我最大的感受就是协议层稳定了上层能玩的花样才会多。Streamable HTTP 虽然不见得是传输层的终极形态但它把复杂留给了协议实现把简单还给了开发者。就冲这一点我就很愿意把它推荐给每一个正在搭建 MCP 服务的人。