Google 联手 Hugging Face 拆掉 MCP 会话层，Agent 协议跑上 Serverless

2026 年 8 月 5 日，Google 开发者博客发表，由 Google Cloud Data 的 Kurtis Van Gent（Senior Staff Software Engineer）和 Google Cloud AI 的 Alan Blount（Technical Product Manager）联合执笔，详解 Model Context Protocol（MCP）2026-07-28 规范候选版本的无状态化改造。该规范于 2026 年 7 月 28 日正式发布，Google 称其与 Hugging Face 等共同发起 MCP Transports Working Group 推动落地，是 MCP 自 2024 年底问世以来最大的一次架构变更。

核心改动只有一句话：传输层会话管理被完全移除。协议从双向有状态协议变成请求/响应的无状态协议，不再需要 initialize 握手、不再需要 Mcp-Session-Id、不再需要 sticky session，MCP 服务器可以直接部署在标准 HTTP 负载均衡和 serverless 基础设施之上。

四件事彻底变了，三件事被判了死刑

新规范带来了四个架构层面的根本变化，同时正式废除了三项旧功能。

第一，握手协议消失。旧版 MCP（2025-11-25）要求客户端先发 initialize 请求，服务器返回 Mcp-Session-Id，之后所有请求都携带这个 Session ID。新版（2026-07-28）中，initialize/initialized 握手（SEP-2575）和 Mcp-Session-Id 头（SEP-2567）被彻底删除。协议版本、客户端身份、客户端能力这些原本在连接建立时一次性交换的信息，现在通过 _meta 字段在每一笔请求中自描述携带。

第二，HTTP Header 级路由。 Mcp-Method 和 Mcp-Name 被提升为标准 HTTP 头（SEP-2243），网关和负载均衡器不用解析 JSON body 就能做路由、限流和审计。如果 Header 与 JSON-RPC body 不一致，服务器返回 -32020 错误码直接拒绝。

第三，Multi Round-Trip Requests（MRTR）替代了长连接轮询。过去服务器需要向客户端索要用户确认（elicitation）时，必须保持 SSE 长连接。MRTR（SEP-2322）改为：服务器立即返回 InputRequiredResult，内含序列化的 requestState；客户端收集用户输入后重新发起调用，任何一台负载均衡后的实例都能接手恢复执行。

第四，Tasks Extension 正式转正。长任务（数据库备份、CRM 同步、退款处理，耗时 10–60 秒不等）不再阻塞客户端连接。服务器立即返回 taskId，后台异步执行，客户端通过 tasks/get 和 tasks/update 轮询或订阅进度。

同时，三项旧功能被正式标记为 Deprecated（SEP-2577），进入最少 12 个月的过渡窗口：Roots 被显式工具参数、资源 URI 或服务器配置替代；Sampling 被直接调用 LLM provider API 替代；Logging 被 stderr（stdio 连接）或 OpenTelemetry（云端）替代。这是 MCP 历史上第一次引入正式的功能生命周期策略。

四个生产故障，逼出了这次重写

MCP 最早设计于 2024 年底，面向的场景是单客户端通过 stdio 连接单服务器，session 模型足够好用。但当 Google 开始把 MCP 服务器部署到云原生基础设施上时，Van Gent 和 Blount 写道，"旧的 session 模型直接撞墙"。

他们在博客中列出了四个生产级故障模式：

负载均衡税。标准轮询负载均衡器不知道哪个容器持有哪个内存中的 session。在 Kubernetes 集群上部署三个 pod，客户端的第二笔请求随机落到另一个 pod 就会返回 400 Session Not Found。

Sticky Routing 的代价。开发者不得不在负载均衡层配置 sticky session 亲和规则，导致流量无法均匀分布，自动伸缩效率极低。

零容错。 Pod 重启或崩溃，session 状态瞬间丢失，活跃的客户端对话直接抛 transient error。

基础设施膨胀。运行远程 MCP 服务器需要共享 Redis session 存储，或复杂的网关层包检测，引入大量延迟和运维成本。

旧版协议的初始握手流程需要客户端先发送：

json

{  "jsonrpc": "2.0",  "id": 1,  "method": "initialize",  "params": {    "protocolVersion": "2025-11-25",    "capabilities": {},    "clientInfo": { "name": "my-app", "version": "1.0" }  }}

{  "jsonrpc": "2.0",  "id": 1,  "method": "initialize",  "params": {    "protocolVersion": "2025-11-25",    "capabilities": {},    "clientInfo": { "name": "my-app", "version": "1.0" }  }}

服务器返回 Mcp-Session-Id 后，后续每次工具调用都必须带上这个 ID，把客户端钉死在持有其内存状态的那台容器上。

每一笔请求都自报家门

新版协议中，每一笔请求自包含所有身份和能力信息：

POST /mcp HTTP/1.1Host: mcp-server.exampleMCP-Protocol-Version: 2026-07-28Mcp-Method: tools/callMcp-Name: searchContent-Type: application/json
{  "jsonrpc": "2.0",  "id": 1,  "method": "tools/call",  "params": {    "name": "search",    "arguments": { "q": "otters" },    "_meta": {      "io.modelcontextprotocol/protocolVersion": "2026-07-28",      "io.modelcontextprotocol/clientCapabilities": {},      "io.modelcontextprotocol/clientInfo": {        "name": "my-app",        "version": "1.0"      }    }  }}

POST /mcp HTTP/1.1Host: mcp-server.exampleMCP-Protocol-Version: 2026-07-28Mcp-Method: tools/callMcp-Name: searchContent-Type: application/json
{  "jsonrpc": "2.0",  "id": 1,  "method": "tools/call",  "params": {    "name": "search",    "arguments": { "q": "otters" },    "_meta": {      "io.modelcontextprotocol/protocolVersion": "2026-07-28",      "io.modelcontextprotocol/clientCapabilities": {},      "io.modelcontextprotocol/clientInfo": {        "name": "my-app",        "version": "1.0"      }    }  }}

架构收益有四个：标准轮询路由——任何容器实例可以处理任何请求；serverless 部署——MCP 服务器可以跑在 Google Cloud Run 或 Cloud Functions 上，空闲时缩容到零；透明故障切换——Pod 重启、滚动更新、自动伸缩对客户端完全不可见；无需 Redis——GitHub MCP Server 已经升级到新规范，完全移除了 Redis session 存储，每次调用不再需要额外的数据库读写。

MRTR：用户中途插话，服务器不用死等

在无状态协议上处理"用户确认"曾是设计上最棘手的环节。旧版 MCP 中，服务器如果需要用户澄清参数或确认操作（比如"确定要删除这 3 个文件吗？"），必须保持 SSE 连接开启，等待客户端回传结果。

MRTR 把交互拆成了自包含的步骤。服务器不阻塞线程、不保持连接，立即返回 InputRequiredResult，内含 Base64 编码的 requestState：

json

{  "resultType": "inputRequired",  "inputRequests": {    "confirm": {      "type": "elicitation",      "message": "Are you sure you want to delete these 3 files?",      "schema": { "type": "boolean" }    }  },  "requestState": "eyJzdGVwIjoxLCJmaWxlcyI6WyJhIiwiYiIsImMiXX0="}

{  "resultType": "inputRequired",  "inputRequests": {    "confirm": {      "type": "elicitation",      "message": "Are you sure you want to delete these 3 files?",      "schema": { "type": "boolean" }    }  },  "requestState": "eyJzdGVwIjoxLCJmaWxlcyI6WyJhIiwiYiIsImMiXX0="}

客户端收到后提示用户、收集答案，然后携带 inputResponses 和原样 requestState 重新发起调用。因为 requestState 包含了恢复任务所需的全部上下文，负载均衡器后的任何实例都能接手续跑。

根据的发布说明，此前需要保持长连接的 elicitation/create、sampling/createMessage 和 roots/list 三类服务器到客户端请求，现在全部通过 MRTR 以请求/响应模式完成。

退款要跑 60 秒？先回 taskId，回头再取结果

另一个同步阻塞的痛点是长任务。支付网关退款、CRM 同步、数据库备份——耗时 10 到 60 秒，如果保持 HTTP 连接打开，会阻塞用户对话、制造连接队列堆积。

Tasks Extension（SEP-2663）从实验性功能升级为正式的一级协议扩展。客户端调用长任务工具时，服务器立即返回 taskId，后台异步执行：

typescript

server.tool("process_refund",  { orderId: z.string(), amount: z.number() },  async ({ orderId, amount }) => {    const taskId = randomUUID();    await setTaskState(taskId, { status: "working" });    processRefundAsync(taskId, orderId, amount);    return {      content: [{        type: "text",        text: JSON.stringify({          taskId,          status: "working",          message: `Refund of $${amount} for order ${orderId} is processing.`        })      }]    };  });

server.tool("process_refund",  { orderId: z.string(), amount: z.number() },  async ({ orderId, amount }) => {    const taskId = randomUUID();    await setTaskState(taskId, { status: "working" });    processRefundAsync(taskId, orderId, amount);    return {      content: [{        type: "text",        text: JSON.stringify({          taskId,          status: "working",          message: `Refund of $${amount} for order ${orderId} is processing.`        })      }]    };  });

客户端可以继续对话、告知用户任务在处理中，通过 tasks/get 轮询进度，或通过 tasks/update 订阅状态变更通知。

安全三连加固，外加缓存让工具列表不再反复拉取

安全方面，新规范引入了三项加固：Issuer Verification（RFC 9207）要求公开客户端验证授权响应的 iss 参数，防止多服务器架构中的 session 劫持；Resource Indicators（RFC 8707）让客户端显式声明 token 的目标服务器，解决"混淆代理"问题；工具输入 Schema 全面升级为 JSON Schema 2020-12，支持 oneOf、anyOf、allOf 等高级组合结构和本地 $ref 定义。

HTTP 标准化还带来了缓存能力。tools/list、prompts/list 等接口现在可以返回 ttlMs（毫秒级存活时间）和 cacheScope（SEP-2549），客户端不再需要通过 SSE 长连接监控工具列表是否变化。Google 博客将这一机制描述为"模仿 HTTP Cache-Control 的缓存字段"。

GitHub MCP Server 已经扔掉 Redis 了

新规范发布仅一周多，已有数个大型生产级 MCP 服务器完成迁移。

Google 博客明确点名 GitHub MCP Server 已经升级到 2026-07-28 规范，完全移除了 Redis session 存储，"消除了每次调用中的数据库写入和读取，让交互更快"。Google 自家的 Go MCP SDK 在 7 月 28 日规范发布当天即推出 v1.7.0，为 GitHub MCP Server 等重大集成提供支撑。

MCP 官方博客在发布文章中收录了多家公司的背书。Anthropic 的 David Soria Parra（MCP 联合发明人）称："这次发布是远程 MCP 上线一年多以来最重要的一次，它吸收了 18 个月的经验教训，为 MCP 的未来提供了坚实基础。"AWS 的 Swami Sivasubramanian（VP of Agentic AI）确认 Amazon Bedrock AgentCore 已支持新规范的无状态核心，并指出 Tasks Extension 由 AWS 贡献。Cloudflare 的 Brendan Irvine-Broque（Senior Director of Product Management）表示 Workers 平台从第零天即支持新规范。Microsoft Foundry 的 Tina Schuchman（CVP of Engineering）称 MCP 是 Foundry 统一 MCP 端点的"基础"，新规范让"治理、身份和可观测性更容易集中"。

中出现了一些来自一线开发者的不同声音。运营 MCP 网关 Glama 的开发者 punkpeye 指出，在他索引的 62,726 个开源 MCP 服务器中，过去 30 天内有 18,707 个（约 30%）仍在活跃维护。然而新协议是双向 wire-incompatible 的——"只更新 SDK 不够，服务器和客户端都需要重构"。他同时判断这对 MCP 网关是机会，可以充当新旧协议之间的互操作层。

HN 上另外几位开发者关注的是文件传输问题。jakobgm 抱怨 MCP 客户端在处理二进制数据时仍然只能靠 base64 编码，"污染 context window"。MCP 核心维护者 somnium_sn 在回复中承认文件上传是已知痛点，但因为优先级问题被推迟到了下个版本，"现在是加入工作组、推动这个需求上路线图的最好时机"。

12 个月过渡期，够不够？

MCP 第一次引入了正式的功能废弃策略：Active → Deprecated → Removed，最少 12 个月过渡窗口（SEP-2577）。Roots、Sampling、Logging 三项功能已进入 Deprecated 状态。旧版 HTTP+SSE 传输也被正式标记为 Deprecated，有一年的离场期。

四款 Tier 1 SDK——TypeScript、Python、Go、C#——均已发布支持 2026-07-28 规范的 beta 版本。Python 用户可以直接 pip install "mcp[cli]==2.0.0b1" 安装；TypeScript v2 将原本单体式的 @modelcontextprotocol/sdk 包拆为 @modelcontextprotocol/server 和 @modelcontextprotocol/client 两个模块化包，并提供了自动化 codemod 工具协助迁移。

但 punkpeye 的统计数字给出了一个具体参照：即便活跃维护的服务器也只占开源 MCP 生态的 30%。新协议的 wire-incompatible 特性意味着迁移不是升级 SDK 版本号就能完成的事。MCP 生态能否在 12 个月内消化这次架构变更，取决于两件事：Tier 1 SDK 的稳定发布节奏，以及 MCP 网关类工具能否有效充当新旧协议的适配层。

参考链接

Kurtis Van Gent, Alan Blount. "Scaling AI Agent Infrastructure with the MCP Stateless updates." Google Developers Blog, 2026-08-05.
"The 2026-07-28 Specification." Model Context Protocol Blog, 2026-07-28.
"MCP 2026-07-28 Specification: transport going stateless." Hacker News, 2026-07-29.