2024 年 10 月 15 日MCP 协议发布了自诞生以来最大的一次版本更新。主要从「双向有状态」改为「无状态」，握手与会话机制被移除。

关键词：

• • 无状态移除 initialize 握手和 Mcp-Session-Id
• • MRTR多轮往返请求，替代 Elicitation、Sampling、Roots
• • 框架新能力走 不必改主要协议

目前 MCP SDK 月下载量突破 1 亿次连接器目录收录超过 5000 台服务器。

一、旧架构的问题

有状态设计的代价

MCP 最早是双向有状态的协议，这套设计在早期够用，但在生产环境中暴露出以下痛点：

至于结果是，MCP 服务器没法像普通 HTTP 服务那样，直接扔到 Serverless 或边缘节点上扩容。怎么说呢，

社区对有状态架构有不少吐槽：

二、握手没了会话也没了

主要变化——从「握手」到「自描述」请求

-- 版本最大的变化：initialize/initialized 握手被移除。Mcp-Session-Id 请求头一并退休。

旧模式：

HTTP Request : POST /initialize → 返回 sessionId
HTTP Request : GET /sse → 建立双向流
HTTP Request : POST /tools/call

新模式：每个请求都是完整自描述的。

HTTP Request: POST /mcp
MCP-Protocol-Version: 1.0
Mcp-Method: tools/call
Mcp-Name: search
{
"jsonrpc": "2.0","id": 1,"method": "tools/call","params": {
"name"的观点是，"search"。"arguments": { "q": "otters" },"_meta": {
"io.modelcontextprotocol/clientInfo": {
从"name"来看，"my-app","version": "1.2.3"
}
}
}
}

每个请求自包含：协议版本、客户端身份、客户端能力全部塞进 字段。任何请求都可以随意落到负载均衡后面的任意实例，不再需要共享存储。说起来，

状态何去何从

No‑state 并不代表着服务器不能记事。如果业务需要跨调用保留状态，官方方案是让服务器返回一个显式的 handle。 由模型在后续调用里把该 handle 带回去。

"服务器主动返回一个显式的 handle，模型在后续调用里把这个 handle 传回去。" — 官方文档建议

"

This makes state explicit and avoids hidden session leakage.

配套改动

三、MRTR：多轮往返请求

旧问题的观点是，服务端如何反向请求客户端？