MCP 无状态更新：如何扩展 AI 智能体基础设施

随着您部署智能工作流并扩大用户规模，您的瓶颈也会发生变化。当模型上下文协议（MCP）在2024年底首次引入时，它提供了一个优雅的、面向会话的框架，使大型语言模型能够协商功能、调用外部工具并检索上下文资源。对于在本地机器上单个客户端与单个服务器的通信而言，它非常完美，并针对标准输入输出进行了优化。

但当我们在谷歌开始在云原生基础设施上部署MCP服务器时，我们遇到了一个严重的瓶颈。原始的协议级会话模型需要持久状态、握手以及会话固定。简而言之，它是建立在有状态传输之上的，这破坏了现代云原生可扩展性的核心原则。

为了解决这个问题，谷歌牵头推进：https://github.com/modelcontextprotocol/modelcontextprotocol/pull/2575，将协议与有状态传输约束解耦。我们的团队需要MCP能够在谷歌云上处理数百万并发查询，我们也知道你们都希望MCP能够为真实企业规模做好准备。与Hugging Face及其他行业合作伙伴密切合作，我们共同成立了MCP传输工作组。

今天，我们非常高兴地庆祝这项工作的成果：2026-07-28模型上下文协议规范发布候选版，该版本已被广泛采用：https://aaif.io/blog/the-ecosystem-responds-to-stateless-mcp。这一里程碑式的发布完全移除了传输级会话管理，为您提供一个无状态的协议核心，可在普通HTTP负载均衡基础设施上扩展。这是自MCP发布以来规范最大的变化，如果您不阅读本文其余部分，请放心，这是一项改进——更高的可扩展性、更安全、同样易用。

在原始协议模型（规范版本2025-11-25）[392]中，通过HTTP连接到MCP服务器需要一个有状态的初始化过程：

服务器会以Mcp-Session-Id头响应。要进行任何后续的工具调用或资源查询，客户端必须在每个请求中包含该唯一会话ID，将客户端固定到持有其内存会话状态的特定容器或Pod。

这一有状态限制破坏了云原生工程师依赖的水平扩展模型：

新的 2026-07-28 规范通过使协议核心完全无状态来解决这个问题。握手被取消。初始化/已初始化握手（SEP-2575）和逻辑 Mcp-Session-Id 头（SEP-2567）已被完全移除。

取而代之的是，现在每个请求都是自描述且独立的。协议版本、客户端信息以及以前在连接建立时只交换一次的客户端能力，现在都会作为 _meta 字段在每个请求中内联传输。

在新的 2026-07-28 规范下，无状态工具调用如下所示：

在没有协议会话的情况下，我们需要标准机制来高效路由和管理流量。在传输工作组（Transports Working Group）下工作时，我们帮助设计了 SEP-2243（HTTP 标准化）[302, 542]。

可流式 HTTP POST 请求现在携带特定的 HTTP 头：

这些头会与 JSON-RPC 主体进行镜像匹配。如果不一致，服务器会以 -32020 头不匹配代码拒绝请求。

通过将这些值提升为标准 HTTP 头，代理、网关和负载均衡器可以在不检查请求体的情况下进行路由、限流和审计流量。对于安全和日志团队来说，这是一个巨大的胜利，可以大幅降低网关层的延迟和处理开销。

为了消除仅为监控工具或提示列表变化而保持长连接的服务器发送事件（SSE）连接的需求，该规范引入了基于 HTTP Cache-Control 模型的缓存字段。工具和资源结果现在可以返回 ttlMs（以毫秒为单位的生存时间）和 cacheScope。客户端可以准确知道工具/列表响应的有效时间，以及是否可以跨多个用户安全缓存。

在无状态环境中，我们面临的最复杂挑战之一是如何处理服务器到客户端的请求。在以前的版本中，如果 MCP 服务器在工具调用期间需要用户澄清（"引导提示"）或确认，它必须保持 SSE 连接以将该请求推送给客户端。

多轮往返请求（SEP-2322）通过将交互生命周期重构为自包含步骤，完美地解决了这个问题：

服务器不会阻塞线程或保持连接开启，而是立即返回一个带有 requestState 负载、包含序列化上下文的 InputRequiredResult [398]：

客户端提示用户，收集布尔答案，并使用 inputResponses 以及回显的 requestState 重新发起调用。由于 requestState 包含恢复任务所需的所有信息，因此任何位于负载均衡器后的服务器实例都可以处理重试请求！

有时候，工具调用只是执行时间较长。数据库备份、CRM 同步或者通过支付网关进行退款可能需要 10 到 60 秒。保持客户端连接开启会阻塞客户对话，并造成大量连接排队。

Tasks 扩展从实验性功能升级为健全的一级协议扩展。现在，当客户端调用运行时间长的工具时，服务器会立即返回一个 taskId，并在后台启动执行：

随着管理状态的职责从传输层转移到应用层，安全性变得至关重要。2026-07-28 规范带来了几项关键的安全增强：

MCP 首次引入了正式的弃用政策。功能会经历结构化的 Active -> Deprecated -> Removed 生命周期，并有至少 12 个月的过渡期。今天有三个功能进入弃用阶段：

所有四个一级 SDK（TypeScript、Python、Go 和 C#）已经提供了支持 2026-07-28 规范的测试版。我们强烈建议您今天就在您的预发布环境中开始测试它们。

在 Python 中，MCPServer 装饰器 API 完全兼容 [303]。您可以直接使用以下命令安装测试版：

TypeScript v2 用模块化、针对性的小型库取代了单一的 @modelcontextprotocol/sdk 包，以保持您的依赖轻量化。安装方式如下：

提供了一个方便的 codemod 用于处理标准 API 重命名（例如将 .tool() 重命名为 registerTool）：

2026-07-28 规范标志着模型上下文协议的重要转折点，将其从一个有前景的本地集成层转变为企业 AI 应用的基础开放基础设施。

感谢所有 MCP 传输工作组的大力付出：https://github.com/modelcontextprotocol/transports-wg/blob/main/GOVERNANCE.md#members 以及来自多家公司的其他团队共同努力促成这一成果。同时感谢维护 Go MCP SDK 的 Google 团队：https://github.com/modelcontextprotocol/go-sdk，并于 7 月 28 日发布了 v1.7.0：https://github.com/modelcontextprotocol/go-sdk/releases/tag/v1.7.0，该版本在发布当天即可使用，并支持诸如 Github MCP Server 的主要集成：https://github.blog/changelog/2026-07-23-github-mcp-server-supports-the-next-mcp-specification/。

Google 推动无状态传输的初衷源于需求。我们需要一种能够应对全球开发者庞大规模的稳健协议，并希望确保每位开发者，无论是在 Google Cloud 上开发，还是在其他任何地方开发，都能使用高可靠性、安全且可无限扩展的智能基础设施。

通过将状态与传输层解耦，我们使负载均衡变得轻松，自动伸缩变得无缝，并使无服务器部署成为现实。我们迫不及待想看到大家在这一新的无状态基础上构建的极具可扩展性的 AI 代理！

通过会话感知负载均衡，扩展实时 AI 代理

Gemini 企业代理平台中的代理和模型评估现已 GA（全面可用）

As you deploy agentic workflows and scale up your users, your bottlenecks change. When the Model Context Protocol (MCP) was first introduced in late 2024, it provided an elegant, session-oriented framework that allowed LLMs to negotiate capabilities, invoke external tools, and retrieve contextual resources. It was perfect for a single client talking to a single server on a local machine and optimized for stdio.

But when we at Google began deploying MCP servers across our cloud-native infrastructure, we hit a hard wall. The original protocol-level session model required persistent state, handshakes, and session pinning. In short, it was built on stateful transports that broke the core tenets of modern cloud-native scalability.

To solve this, Google led the charge：https://github.com/modelcontextprotocol/modelcontextprotocol/pull/2575 to decouple the protocol from stateful transport constraints. Our teams needed MCP to scale across millions of concurrent queries on Google Cloud, and we knew that you all needed MCP to be ready for real-world enterprise scale too. Working closely with Hugging Face and other industry partners, we co-founded the MCP Transports Working Group.

Today, we are thrilled to celebrate the culmination of that work: the 2026-07-28 Model Context Protocol specification release candidate , which is already being widely adopted：https://aaif.io/blog/the-ecosystem-responds-to-stateless-mcp. This landmark release removes transport-level session management entirely, giving you a stateless protocol core that scales on ordinary HTTP load-balanced infrastructure. It’s the biggest change to MCP spec since launch, and if you don’t read the rest of this article, rest assured, it’s a change for the better - more scale, more secure, just as easy .

In the original protocol model (specification version 2025-11-25) [392], connecting to an MCP server over HTTP required a stateful initialization process:

The server responded with an Mcp-Session-Id header. To make any subsequent tool call or resource query, the client had to include that unique session ID on every request, pinning the client to the specific container or pod that held its in-memory session state.

This stateful constraint breaks the horizontal scaling models that cloud-native engineers depend on:

The new 2026-07-28 specification solves this by making the protocol core completely stateless. The handshake is gone . The initialize / initialized handshake (SEP-2575) and the logical Mcp-Session-Id header (SEP-2567) have been removed entirely.

Instead, every request is now self-describing and independent . Protocol version, client info, and client capabilities that used to be exchanged once at connection setup now travel in a _meta field inline on every single request.

Here is how a stateless tool call looks under the new 2026-07-28 specification:

Without protocol sessions, we needed standard mechanisms to route and govern traffic efficiently. Working under the Transports Working Group, we helped design SEP-2243 (HTTP Standardization) [302, 542].

Streamable HTTP POST requests now carry specific HTTP headers:

These headers are mirrored to match the JSON-RPC body. If they disagree, the server rejects the request with a -32020 header mismatch code.

By promoting these values to standard HTTP headers, proxies, gateways, and load balancers can route, rate-limit, and audit traffic without inspecting the request body . For security and logging teams, this is a massive win that drastically lowers the latency and processing overhead at the gateway layer.

To eliminate the need for long-lived Server-Sent Events (SSE) connections just to monitor if a tool or prompt list changed, the spec introduces caching fields modeled after HTTP's Cache-Control. Tool and resource results can now return a ttlMs (Time-to-Live in milliseconds) and a cacheScope . Clients know exactly how long a tools/list response is fresh and whether it is safe to cache across multiple users.

One of the most complex challenges we faced in a stateless world was how to handle server-to-client requests. Under previous versions, if an MCP server needed user clarification (an "elicitation prompt") or a confirmation during a tool call, it had to keep an SSE connection open to push that request to the client.

Multi Round-Trip Requests (SEP-2322) solves this problem beautifully by restructuring the interaction lifecycle into self-contained steps:

Instead of blocking the thread or holding a connection open, the server immediately returns an InputRequiredResult with a requestState payload containing serialized context [398]:

The client prompts the user, gathers the boolean answer, and reissues the call with inputResponses and the echoed requestState . Because the requestState contains everything needed to resume the task, any server instance behind your load balancer can pick up the retry request !

Sometimes a tool call simply takes a long time to run. A database backup, a CRM sync, or a refund through a payment gateway can take anywhere from 10 to 60 seconds. Holding the client connection open blocks the customer conversation and creates massive connection queues.

The Tasks Extension graduates from an experimental feature to a robust, first-class protocol extension. Now, when a client calls a long-running tool, the server immediately returns a taskId and kicks off the execution in the background:

As the responsibility of managing state shifts from the transport layer to the application layer, security becomes paramount. The 2026-07-28 spec delivers several crucial security enhancements:

For the first time, MCP now has a formal deprecation policy. Features move through a structured Active -> Deprecated -> Removed lifecycle with a minimum 12-month transition window . Three features enter deprecation today:

All four Tier-1 SDKs (TypeScript, Python, Go, and C#) already have beta releases available supporting the 2026-07-28 specification. We highly encourage you to start testing these in your staging environments today.

In Python, the MCPServer decorator API is fully compatible [303]. You can install the beta directly with:

TypeScript v2 replaces the monolithic @modelcontextprotocol/sdk package with modular, focused libraries to keep your dependencies light. Install them with:

A convenient codemod is available to handle standard API renames (like renaming .tool() to registerTool ):

The 2026-07-28 specification marks a watershed moment for the Model Context Protocol, transitioning it from a promising local integration layer into the foundational, open infrastructure for enterprise AI applications.

Thank you to the huge effort from all of the MCP Transports Working Group：https://github.com/modelcontextprotocol/transports-wg/blob/main/GOVERNANCE.md#members and other teams who worked to make this happen, from across many companies. Thanks also to the Google team who maintain the Go MCP SDK：https://github.com/modelcontextprotocol/go-sdk and shipped v1.7.0：https://github.com/modelcontextprotocol/go-sdk/releases/tag/v1.7.0 on July 28th which was ready on launch day and powers major integrations like Github MCP Server：https://github.blog/changelog/2026-07-23-github-mcp-server-supports-the-next-mcp-specification/.

Google’s push for stateless transports was born out of necessity. We needed a protocol robust enough to handle the massive scale of our global developers, and we wanted to ensure that every developer, whether building on Google Cloud or anywhere else, had access to highly reliable, secure, and infinitely scalable agentic infrastructure.

By decoupling state from the transport layer, we have made load balancing boring, autoscaling seamless, and serverless deployment a reality. We can’t wait to see the incredibly scalable AI agents you build on top of this new stateless foundation!

Scaling real-time AI agents with session-aware load balancing

Agent and Model Evaluations in Gemini Enterprise Agent Platform are now GA