「告别握手」系列 · 第 篇

旧版握手的观点是，隐藏在“连接”背后的痛点

在 MCP 的早期设计里一个完整的工具调用被拆成三步：initialize会话签发、后续每次请求携带 Mcp-Session-Id。看似简单，却把所有状态都塞进了连接层。

这一步骤对分布式环境造成了四大痛点：

1. 粘性路由成硬核需求——必须把同一会话请求送回同一台实例，否则会话无效。
2. 共享存储成新瓶颈——多实例部署时需要 Redis 等外部存储保存会话表；单点失效就导致整个集群不可用。
3. 实例宕机瞬间毁掉所有上下文——一台机器挂掉。它持有的所有会话全部失效，Agent 必须重新走握手流程。
4. 网关负担加重——因为方法名藏在 JSON 体内。负载均衡器和限流程序必须解析请求体，额外消耗 CPU 与 I/O。

为什么“握手+会话”让生产难以伸缩？

#1 粘性路由 & #2 共享存储 – “服务端必须保持同一个实例”的宿命论。

• SLA 下降：A 实例重启或扩容时新实例无法识别旧会话；流量被强行分配到老节点，导致热点与冷点严重。其实，
• CACF：MCP 本身没有办法判断何时应该重新路由。只能依赖外部监控与人工干预。
• AWS ALB / Nginx 需要 Lua/NJS 才能支持粘性路由和 JSON 解析：ECS 上部署 Nginx 时需要额外插件来实现粘性与限流，增加运维成本。
• SSE 流断裂恢复成本高：MCP 在旧版使用 SSE 时如果网络抖动导致断链。需要服务器维护完整消息队列和已发送进度，恢复极其复杂。

再看典型场景演练，采购 Agent 的痛苦循环

1. "search_suppliers" → 返回候选列表；Agent 调 "create_request" → 服务端返回 request_id:R1234
2. "get_request_status" → 若服务端所在实例宕机，这个 ID 立刻失效；Agent 必须重新走一次 Mcp-Session-Id-握手链条才能继续查询。
3. "place_order" → 一样受制于实例状态，不一致的会话导致业务中断。

新版无状态主要：每个请求自带完整上下文

MCP 在最新规范中彻底移除了握手与会话概念。取而代之的是在每个请求中携带以下信息：

This design消除了四大痛点：

• No sticky session required – any instance can serve any request.
• No external session store – state is explicit in request.
• No instant loss on instance restart – request context travels with it.
• No JSON parsing at gateway – method name & tool name are in headers.
.

版本兼容与升级友好

MCP 新规范把版本协商变成每个请求级别的操作。如果某个实例不支持当前协议版本，它只需返回错误并列出可接受版本。客户端可以即时调整，而不会影响其他正在运行的请求。 这样，即使旧版与新版共存，也不会因为一次全量切换而造成停机。Pain point relief: 老旧负载均衡器无需改造即可支持多协议版本；自动降级功能减少了运维人员对版本冲突的干预。

server/discover – 能力发现但不是握手

The new “discover” endpoint lets clients fetch server capabilities once and cache m locally. It’s optional and doesn't create any session state.

• No handshake dependency – you can skip discover entirely.
.

业务状态显式化：从隐式 Session 到显式句柄

MCP 鼓励业务层把跨调用状态放在显式句柄（如 request_id) 中，而不是协议层记忆。这样做有三大优势：

1. Your model can see and manipulate it!话说回来，– 模型可以比较、传递并引用该句柄。实现更细粒度控制，
.
.
.
I18N advantage:- The handle is language agnostic;cross-language SDKs can reuse it without translation overhead.
• Auditing becomes straightforward—trace a handle through logs rar than hunting a connection ID across instances.
• Retry logic simplifies—if a request fails due to network or instance failure,just resend same request without re‑handshaking.

去除连接级特性：Ping / Logging / SSE 缺省化

The protocol no longer exposes features that depend on persistent connections:

No ping endpoint;- health checks are performed by sending a real tool call. No global log level;- log level is per-request via _meta.io.modelcontextprotocol/logLevel. SSE stream break handling removed;- a broken stream invalidates current operation;client must retry with a fresh request ID.

工作量评估 & 部署简化

• MCP 客户端/SDK 实现者需要更新代码以移除 initialize/Mc-session-handling，并改为显式 _meta 字段填充；老实说，这一变更主要影响基于旧协议库的项目，但不会破坏向后兼容功能。• 业务代码需从协议层解耦，将跨调用状态迁移到显式句柄或业务数据库；这通常是几行代码就可以完成。•   - 部署简化：不再需要 Sticky Session 配置或 Redis 会话存储。运维人员可将集中式缓存拆除，只保留基本 HTTP 方法。•   - 运维成本下降：因为没有连接管理与续期逻辑，监控报警规则也可以更精简。•   - 兼容窗口期长达数月，因为新旧协议可共存且互相独立。

—— 无状态主要。让你真正摆脱“握手”束缚

MCP 的无状态化并不是削弱功能，而是将“连接”这层抽象完全剥离，让协议专注于交互本身。对最终使用者而言，无需关注内部会话机制。一切操作都像普通 HTTP 请求一样直观可靠；对运维团队而言，也省去了 Sticky Session、Redis 会话表等一系列繁琐维护任务。正如标题所说“拆解无状态主要”，我们终于拥有了真正可伸缩、高可用且易于管理的工具调用框架。*这篇文章基于 MCP 2026‑07‑28 发布的新规范撰写*.

• The MCP 2026 Specification — 官方发布公告 MCP 架构总览— 官方文档 MCP 变更日志— 官方文档 SEP‐xxxx ：无状态化与移除初始化握手 SEP‐xxxx ：移除协议级 session 与 Mcp‑Session‑Id Model Context Protocol 官方仓库