InfoQ 9 月 26 日报道，MCP（Model Context Protocol）规范完成一轮关键修订，协议从「有状态」转向「无状态」。这是 MCP 自诞生以来最重要的架构变更之一，直接改变了远程 MCP Server 的部署方式。

变了什么

• 移除 initialize 握手与 Mcp-Session-Id 请求头：任何请求都可以路由到任意服务器实例，不再需要黏性会话（sticky session）或共享会话存储。
• server/discover 取代预先能力协商：客户端按需发现服务器能力，而不是在连接建立时一次性交换。
• 新增 Mcp-Method、Mcp-Name 请求头，支持 W3C Trace Context：网关可以据此做路由、限流和分布式追踪。
• 服务器主动请求改为多请求模式：不再依赖保持打开的长连接流。

为什么值得关注

在此之前，部署一个远程 MCP Server 必须维护会话亲和性：同一个客户端的请求要始终落到同一个实例上，或者所有实例共享一份会话存储。这让 MCP Server 的运维成本远高于普通 API 服务，也基本排除了 Serverless 部署的可能。

无状态化之后，AWS Lambda 这类 Serverless 目标成为可行选项，普通负载均衡器即可水平扩展。对想在企业内部大规模铺开 MCP 的团队来说，这是从「Demo 友好」走向「生产可用」的关键一步——MCP Server 的部署难度开始向普通 REST API 看齐。

一个注意点：存量客户端仍依赖会话语义，AWS 的建议是保留旧的会话基础设施，直到旧客户端完成迁移。

同周另一块拼图：SDK 层的安全补强

MCP TypeScript SDK 2.1.0（9 月 23 日发布）引入了两项安全能力：客户端侧的 DPoP（RFC 9449）发送方约束令牌，和服务端请求时的 OAuth scope 挑战。

简单说：过去 MCP 客户端（编码 agent、定时任务这类长驻进程）持有的是普通 Bearer Token，一旦从日志、崩溃转储里泄露，攻击者可以直接重放。DPoP 把令牌绑定到客户端的私钥上，每次请求附带签名证明——被盗的令牌离开私钥就是废纸。这对把 MCP Server 接入 Docusign、NetSuite 这类生产系统的团队，是第一个 SDK 级别的安全基线。

协议层走向无状态、SDK 层补上安全短板，一周之内两连发，MCP 基础设施的成熟度正在明显加速。对企业来说，评估「要不要把内部系统 MCP 化」的技术障碍又少了两条。