MCP 传输层选型：Stdio vs SSE 怎么挑？

在公司里推行 AI Agent 落地时，最让人头疼的不是模型能力，而是怎么让这些工具（Tools）稳健地跑起来。最近我们在部署 MCP (Model Context Protocol) 服务时，卡在了一个关键抉择上：是用 Stdio 还是 SSE？这直接决定了我们的架构是走本地进程还是走网络微服务。

简单来说，这两者的底层逻辑完全不同：

• Stdio (标准输入输出)： 走的是 Unix 管道。Host 进程直接用 child_process.spawn() 启动 Server，通过 stdin/stdout 传 JSON-RPC 消息。最大的爽点是零配置，不需要管端口、防火墙，而且 Server 的生命周期跟 Host 绑定，Host 挂了 Server 自动被回收，非常干净。适合做本地开发者工具或简单的内部脚本。
• SSE (Server-Sent Events)： 走的是 HTTP。客户端发 POST 请求给服务器，服务器通过一个长连接（text/event-stream）把结果推回来。这种模式把 Server 变成了独立的服务端，可以部署在任何有 IP 的地方。如果你要搞多租户 SaaS 或者分布式架构，SSE 是唯一选择。

实际踩坑经验来看，如果只是给几个同事写个本地增强插件，强推 Stdio，部署成本几乎为零。但如果要推到公司级平台，必须上 SSE，否则你没法做负载均衡，也没法监控各个 Server 的健康状态。

给大家贴一个基于 TypeScript 的简单 Stdio Server 实现逻辑，方便参考：

import { Server } from "@modelcontextprotocol/sdk/server/index.js";
import { StdioServerTransport } from "@modelcontextprotocol/sdk/server/stdio.js";

const server = new Server({
  name: "my-company-tool",
  version: "1.0.0",
}, {
  capabilities: {
    tools: {},
  },
});

// 绑定 Stdio 传输层
const transport = new StdioServerTransport();
await server.connect(transport);

对于需要远程调用场景的 SSE 配置，核心在于处理好那个长连接的生命周期，防止被公司网关或 Nginx 自动断开。