MCP可能会引入新的数据传输方式：[RFC] 使用新的“可流式传输的 HTTP”传输方式取代 HTTP+SSE

用简单易懂的方式讲解 GitHub 上 modelcontextprotocol/specification 仓库中 pull request #206 的内容。

想象我们是在聊一个“快递系统”的升级！

---

这个 Pull Request 是啥？

这个 pull request（简称 PR）就像是给一个软件规则（Model Context Protocol）提了个改进建议。它的目标是升级“快递系统”（传输方式），让信息在电脑和服务器之间传递得更简单、更顺畅。

原来的快递系统（HTTP+SSE）是啥样？

以前，信息传递用的是 HTTP（普通网页请求）加 SSE（一种服务器主动推消息给你的方式）。就像：

- 你（客户端）写信给服务器要东西，用的是普通快递。

- 服务器回了封信，还顺便开了个“实时快递通道”（SSE），专门给你推送消息，比如“你的包裹到哪了”。

但这个系统有点麻烦：

- 需要两个不同的“快递站”：一个普通站（`/message`），一个专门的推送站（`/sse`）。

- 如果快递中断（比如网络断了），就容易乱套。

新建议：升级成“Streamable HTTP”

这个 PR 说：“咱们别用两个快递站了，弄一个更聪明的‘超级快递站’吧！”新系统叫“Streamable HTTP”，大概是这样：

1. 一个站搞定所有  

   - 以后只用一个快递站（叫 `/message`），你寄信也好，收推送也好，都走这里。

2. 服务器自己决定咋送 

   - 你寄信给服务器时，服务器可以选择“哎呀，这个得实时推送”，然后把普通快递升级成“实时快递”（SSE），直接给你发消息。

3. 加个身份牌 

   - 你寄信时得带上一个“会话 ID”（就像快递单号），告诉服务器“你是谁”，这样它知道该给谁回信。

4. 简单启动实时消息 

   - 想让服务器一直给你发消息？寄个空信（空的 GET 请求）就行，服务器就知道要开“实时通道”了。

 为啥要改？

- 更简单：一个快递站比两个好管，不用跑来跑去。

- 更灵活：服务器能自己决定啥时候用普通快递，啥时候用实时快递。

- 更靠谱：老系统容易因为网络问题出错，新系统更聪明，能处理得更好。

举个生活例子

想象你在网上买东西：

- 老系统：你下单用一个App（`/message`），查物流得用另一个App（`/sse`），物流信息还老断线。

- 新系统：一个App全搞定，下单、查物流都在里面，店家还能随时推送“货已到楼下”。

现在咋样了？

这个建议（PR #206）是 2025 年 3 月 18 日前的状态，可能还在讨论中。就像大家在开会说：“这个新快递系统好不好？还得改啥？”如果大家都同意，就会正式用起来。

---

小结

这个 PR 是想把原来有点乱的“快递规则”改成一个更简单、更厉害的版本。用一个“超级快递站”取代两个旧站，让信息传递更快、更顺。是不是听起来很棒呀？

如果你还有啥不明白的，比如“会话 ID 是啥”或者“为啥要升级”，随时问我，我再给你讲得更清楚！

从Workflow到Agent，Workflow类产品只是个过渡态？