MCP 2.0移除会话握手:云原生化与Agent安全回摆

MCP 2.0移除会话握手:云原生化与Agent安全回摆

MCPAI InfrastructureAgent Security

数据源:HN + web research

告别 initialize:单次 HTTP 请求完成工具调用

2026 年 7 月 28 日,Model Context Protocol(MCP)迎来了自 2024 年 11 月由 Anthropic 发布以来最重大的一次规范更新。MCP 2.0 正式移除了 initialize 握手阶段与 Mcp-Session-Id 会话状态,将过去需要两次 HTTP 请求的交互压缩为单次自包含请求。这一变更彻底解开了 MCP 在云端分布式部署时的物理枷锁。

在旧版规范中,客户端必须先发送 POST 请求建立握手并获取会话 ID,随后在调用 tools/call 时携带 Mcp-Session-Id 标头。新版规范下,客户端只需在单个 POST 请求中传入 MCP-Protocol-Version: 2026-07-28Mcp-Method: tools/call 请求头,并在 _meta 结构中传递能力描述。少了一次往返,少了一个需要维护的会话 ID,实时交互场景的响应路径被明显缩短。

通信链路的极致简化标志着协议层面的成熟。每个 HTTP 请求都具备了独立解析的完整语义,不再依赖特定的物理连接。

拆除粘性会话:负载均衡器后面的云原生协议

在旧版有状态架构下,服务器必须在内存中维持客户端会话状态,导致常规的 L4/L7 轮询负载均衡失效。请求一旦被分发至未持有该会话的后端节点,调用就会因找不到上下文状态而立即中断。

运维团队此前不得不开启粘性会话(Sticky Sessions)配置,这极易引发集群节点间的负载倾斜。一旦某个服务器实例发生故障重启,与其绑定的全部会话随之丢失,客户端被逼重新发起握手过程。设计文档 SEP-2575 由 gRPC 作者 Mark Roth 与 Kurtis Van Gent 等人联合起草,其核心目标正是消除这种阻碍水平扩展的物理限制。

无状态化重构后,每一个 HTTP POST 请求都在自身载荷中携带了完备的版本与能力声明,任何集群节点均可独立完成逻辑响应。运维团队只需将 MCP 工具服务器部署于通用的 Nginx 或 Kubernetes Ingress 负载均衡器之后,即可轻松实现弹性扩容。MCP 协议由此完成了从本地单机进程间通讯向云原生基础设施协议的跨进。

mcp-explorer 调用的无状态架构交互流程 图:mcp-explorer 调用的无状态架构交互流程。来源:Simon Willison 博客

按需付费原则:精简协议核心与剥离冗余

MCP 2.0 确立了按需付费(pay as you go)的设计哲学,将状态维护退化为系统的最后选择。长连接场景改由 SEP-2567 提出的服务器句柄(server-minted handles)进行显式传递,极大地降低了协议核心的常驻开销。

伴随会话状态的移除,多项边缘机制被同步清理。notifications/initializedlogging/setLevel 接口被直接废除,Roots 与 Sampling 机制(SEP-2577)进入弃用阶段,Streamable HTTP 传输协议(SEP-2596)与 Tasks 模块也被剥离出核心规范转为官方扩展。动态客户端注册(DCR)被基于客户端 ID 元数据文档(CIMD)的新方案替代,消除了授权服务器维护注册表的状态负担。

当服务器需要向外部透传自身支持的能力与规范版本时,可通过全新的 server/discover RPC 接口进行响应。这种轻量级的探测机制允许客户端在发起实际调用前快速完成能力探知与兼容性校验。

终端热度的退潮:给 Agent 一把刀还是一个工具箱

在 2025 年,MCP 一度受到 Anthropic 发布的 Skills 架构冲击。当时技术社区普遍认为,为 Agent 提供一个具备终端命令行与 curl 工具的容器环境便能覆盖大部分调用需求,且具备更高的操作自由度。

然而,直接向大语言模型开放通用终端伴随着严峻的安全隐患与极高驾驭门槛。Simon Willison 的措辞是「fraught with risk」——终端加互联网访问的组合,只有足够强的模型才驾驭得住;命令注入、数据外泄的风险面远大于一组结构化的工具调用。

曾经提出 Prompt 注入 Lethal Trifecta 概念的 Simon Willison 重新转向押注 MCP。直接执行任意 Shell 命令的系统极其缺乏防护边界,而规范化的 MCP 工具定义了显式的输入输出 JSON Schema,为系统审计与权限隔离提供了清晰的防护空间。Agent 的安全范式迎来了一次回摆,社区正在从放任 Agent 使用终端的暴烈模式回归到受控工具箱模式。

Model Context Protocol 官方标识 图:Model Context Protocol 官方标识。来源:modelcontextprotocol.io

从轻量探测到生产打通:生态爆发的驱动力

协议无状态化大幅降低了客户端与服务器的开发门槛,使得笔记本上能跑的小模型也能稳定驱动 MCP 工具调用——这是 Simon Willison 回心转意的直接原因之一:小模型没有能力驾驭一个开放的终端环境,但生成一次结构化的工具调用请求绰绰有余。

规范发布后不到一周,Simon Willison 连续开源了三个实用项目:命令行探针 mcp-explorer、集成 /-/mcp 端点的 datasette-mcp 插件,以及为 LLM CLI 打造的 llm-mcp-client。Freeletics 等团队也在 SDK 2.0.0 发布后的三天内基于新规范写出了自己的 MCP 服务器。

社区讨论呈现出多元的技术视角。一部分工程团队赞赏无状态化带来的吞吐提升与水平扩展能力,另一部分团队则提醒,在涉及跨请求上下文保留或长流水线场景时,应用层仍需自行构建状态凭证的透传机制。

协议进化背后的安全与架构重组

MCP 2.0 的无状态化变革超越了单纯的代码重构与接口清理。它让 MCP 协议摆脱了单机运行环境的束缚,获得了云原生基础设施所需的弹性扩展能力。

这场演进揭示了 AI Agent 在安全架构选择上的深层回摆。当自动化系统从放任 Agent 在 Shell 终端中自由试错,重新回到由结构化 Schema 和无状态 RPC 守护的受控工具箱时,AI 应用在大规模生产环境落地的工程可预测性与安全性才真正找到了支点。

参考链接:

  • SEP-2575: Make MCP Stateless 提案设计文档
  • Simon Willison 博客:Stateless MCP day 实践记录
  • Model Context Protocol 2.0 官方规范与 SDK 发布公告
  • GoFranz:Client ID Metadata Documents 在无状态认证中的应用