一句话总结：MCP 把“说什么”和“怎么送”拆开了。stdio 是本地子进程的悄悄话，Streamable HTTP 是远程服务的标准邮件——平时寄封信就走，需要直播时才开流。** 选哪种，不看哪个“高级”，只看 Server 离你有多远、是一个人用还是一群人在用。
一、先搞懂三个词：Host、Client、Server
MCP 全称是 Model Context Protocol（模型上下文协议） ，你可以把它理解成一套“AI 和外部工具之间的通用插头标准”。它采用 Host → Client → Server 的三层结构。
Host（宿主） 就是你正在用的 AI 应用，比如 Claude Desktop、Cursor 或者公司内部的 AI 助手。它是“总指挥”，负责管理所有连接、控制权限、决定哪些工具可以用。
Client（客户端） 是 Host 内部的一个“联络员”。每一个 Server 都对应一个专属的 Client，一对一绑定，不会串线。
Server（服务端） 是真正干活的程序。它可以是本机上的一个小工具，也可以是部署在云端的远程服务。Server 负责暴露工具、资源和提示词，但它看不到完整的对话历史，只拿到自己需要的那一小块上下文。
用一句话概括：Host 是老板，Client 是秘书，Server 是外部专家。老板不会直接联系专家，而是让秘书一对一去对接。
二、传输方式只有两种：stdio 和 Streamable HTTP
MCP 的消息格式用的是 JSON-RPC（一种结构化的“信件格式”），但“信怎么送”由传输层决定。2026 年的主线只有两种标准传输方式：stdio 和 Streamable HTTP。
传输方式只决定“消息怎么搬”，不改变工具本身的含义。同一个工具，不管用哪种传输，参数和结果都是一样的。
三、stdio：面对面说悄悄话
原理：Host 直接把 Server 拉起来，作为自己电脑上的一个子进程。双方通过标准输入（stdin）和标准输出（stdout）传话，一行一条 JSON-RPC 消息。
什么时候用：Server 装在你本机上，比如读本地文件、操作本机 Git、连本地数据库。Host 启动子进程，生命周期归 Host 管，用完就回收。
优点：不走网络，延迟最低，部署最简单，数据不出本机。缺点：只能本地用，单连接，别人连不进来。
四、Streamable HTTP：打长途电话，但不用一直占线
原理：Server 是一个独立进程，可以部署在远程，同时服务多个 Client。Client 每发一条消息，就是一次普通的 HTTP POST 请求，打到同一个 MCP 端点上。
关键点在于“响应形态” ：Server 收到请求后，可以返回一个普通的 JSON 对象（一问一答，立刻结束），也可以把这次响应临时升级成 SSE 流（Server 慢慢往外吐数据，直到说完）。
选了 HTTP，并不是一定建立长连接一直连着。
- 平时：查个天气、读个配置，就是一次短连接，发完请求、收到 JSON、连接关闭，非常省资源。
- 需要时：生成长文、处理大文件、实时推送进度，才在这一个请求内部临时开启 SSE 流，说完就断。
SSE 本身没有消失，它从“整个会话强制长连接”降级成了“按请求可选的流式通道”。
五、旧版 HTTP+SSE 为什么被淘汰
旧方案是两个端点 + 强制长连接：一个 GET /sse 永远挂着用来收消息，另一个 POST 端点用来发消息。
问题很实在：连接断了没法从断点恢复，只能重来；服务器必须一直维持高可用长连接，并发一高资源就被吃光；而且在安全和基础设施层面也很难处理——长连接一旦建立，中间件往往只检查一次身份，之后门就一直开着。所以它被 Streamable HTTP 取代了。
六、企业内部怎么选：看“服务对象是一个人，还是一个组织”
个人桌面工具 → stdio。员工本机用的效率工具，优先 stdio。零网络暴露，权限就是当前系统用户，客户端退出子进程就回收。企业要做的是在 stdio 外面加沙箱和权限管控，而不是换传输方式。
团队共享服务 → Streamable HTTP。一旦工具连的是公司共享资源（内部代码仓库、工单系统、共享数据库），或者需要集中升级和审计，就必须让 Server 作为独立服务跑起来，用 Streamable HTTP 对内暴露。
企业场景下有几个硬要求：必须上 HTTPS，内网也不例外；认证不能省，MCP 的授权模型以 OAuth 2.1 为基础；通常会引入 MCP 网关做统一收口——工具的注册发现、权限过滤、调用审计、敏感动作管控都在网关层完成。
