MCP 2026-07-28 协议史上最大更新：切断握手、无状态化，AI Agent 基础设施被重写

deepseek23

321人浏览 · 2026-07-29 14:52:34

deepseek23 · 2026-07-29 14:52:34 发布

昨天，AI Agent 的「连接协议」被重写了底层假设

2026 年 7 月 28 日，Model Context Protocol 的维护团队发布了一个版本规范。官方措辞很克制——"这是发布以来最大的一次修订"。但如果你逐行读完变更列表，会发现这不仅是修订，而是对协议底层假设的一次完整替换。

旧 MCP 假设每个 Agent 和一个工具服务器之间有一条长连接，类似 SSH 会话——建立时握手、保持期间交换身份、断开后清理。新 MCP 不再做这个假设。它把每一条请求都当作独立交易来处理，去掉了握手阶段，去掉了会话 ID，去掉了粘性路由依赖。一个请求可以发到任意服务器实例，不需要事先建立任何关系。

这个转变的直接触发因素很务实：当 MCP 从本地开发者工具扩展到企业级分布式部署时，有状态会话成了瓶颈。一个需要粘性路由和共享会话存储的协议，天然无法在水平扩展的 Kubernetes 集群里高效运行。规范中编号 SEP-2567 和 SEP-2575 的两个提案直接删除了 Mcp-Session-Id 头和 initialize/initialized 握手，从协议层面消除了这个瓶颈。

三个结构性变更，每一个都在改规则

2026-07-28 版本规范包含三个核心变更，它们各自独立，但放在一起就构成了一幅完整的画面：MCP 正在从"工具连接协议"进化成"Agent 通信协议"。

一、无状态化（SEP-2567）

Mcp-Session-Id 头和协议层的会话概念被彻底移除。这意味着你的 MCP Server 可以部署在任意数量的实例后面，每条请求通过负载均衡器抵达任意实例都能被正确处理。不需要 Redis 共享会话存储，不需要粘性 Cookie，不需要会话迁移逻辑。

代价是什么？协议版本、客户端信息、能力声明这些原来在握手阶段一次性交换的数据，现在通过 _meta 字段附着在每条请求上传输。换句话说，用微量的冗余数据换取了部署架构的自由度。

二、握手消失（SEP-2575）

每个 MCP 连接开头的两阶段握手（initialize → initialized）被移除。客户端不再需要先声明自己能做什么、再等服务器确认自己能做什么，才能开始实际通信。新增的 server/discover 方法让客户端可以按需拉取服务器能力，而不是在连接时一次性获取。

这个变更对开发者最直接的影响是：你不能再假设连接建立时服务器能力是固定的。服务器可以在运行过程中增删工具、调整参数——客户端通过 server/discover 实时感知这些变化。对动态 Agent 系统来说，这是一个质的飞跃。

三、服务端发起请求被严格约束（SEP-2260）

服务器端发起的请求现在只能在处理客户端请求的过程中发出。规范从"建议如此"升级为"要求如此"。这意味着 Agent 永远不会在用户毫无触发的情况下收到来自工具的主动通知。

这个变更直接回应了上半年多起 AI Agent 安全事件暴露的问题——当工具服务器可以在任意时刻主动向 Agent 推送数据时，攻击面是无限的。约束到请求上下文内，至少保证了每条服务器消息都能回溯到用户的某个操作。

旧 MCP vs 新 MCP：一张表看清差异

维度	旧 MCP（2025 规范）	新 MCP（2026-07-28）
连接模型	有状态会话，需粘性路由	无状态，任意请求到任意实例
握手	initialize/initialized 两阶段	已移除，通过 _meta 字段携带
会话存储	需要共享存储（Redis 等）	不需要，协议层无会话概念
能力发现	连接时一次性声明	通过 server/discover 按需拉取
服务端推送	推荐在请求上下文内	强制在请求上下文内
水平扩展	需要会话亲和性	原生支持，无额外配置
多轮交互	通过 SSE 保持流打开	通过 InputRequiredResult 返回

为什么「无状态」对生产部署是质变

我去年帮一个团队设计 MCP Server 的 Kubernetes 部署时，最大的痛点就是会话亲和性。MCP Server 是无状态的业务逻辑，但 MCP 协议的会话层要求同一个客户端的请求必须落在同一个 Pod 上。这个矛盾导致我们不得不引入 Stickiness 配置、Ingress 会话保持、甚至用 Redis 做会话同步——一套微服务架构为了兼容一个有状态的协议层，绕了一个大圈。

新规范直接消除了这个问题。你可以在一个 Deployment 后面跑 20 个 MCP Server 副本，客户端发来 20 条请求可能落在 20 个不同的 Pod 上，每条请求独立处理，完全不需要会话亲和性。这对 Kubernetes 原生的部署模型来说是回归了直觉——Pod 应该是可互换的，不应该有身份。

Cloudflare 的 Workers AI 团队在规范发布当天就宣布支持新版 MCP。原因是 Workers 的架构天然无状态，旧 MCP 的会话模型和 Workers 的按需执行模型存在根本冲突。无状态化让 MCP 终于适配了边缘计算的原生模式。

多轮请求的语义变了

SEP-2322（Multi Round-Trip Requests）引入了一个微妙的机制变化。过去，当 MCP Server 需要向客户端索要更多信息时（比如用户确认），它会保持 Server-Sent Events 流打开，等待客户端通过同一个连接回传。

新规范用 InputRequiredResult 替代了这种保持打开的模式。服务器在处理请求的过程中，如果发现需要额外输入，会返回一个特殊的 Result 对象，而不是保持连接等待。客户端收到这个 Result 后可以自由决定何时、通过哪条连接提交所需信息。

这看起来只是实现细节的调整，但实际影响很大：服务器不再占用连接资源等待用户输入。在大量并发请求的场景下，这个变更可以显著减少同时打开的连接数。

为了让你直观感受新版 MCP 的客户端实现，这里是一个用 Python 实现的基础 stateless 客户端，包含能力发现和工具调用：

import httpx
import json

class StatelessMCPClient:
    """演示新版 MCP 2026-07-28 无状态客户端"""

    def __init__(self, server_url: str, client_info: dict = None):
        self.server_url = server_url.rstrip("/")
        self.client_info = client_info or {
            "name": "demo-client",
            "version": "1.0.0"
        }

    def discover(self) -> dict:
        """按需拉取服务器能力——代替旧的握手"""
        payload = {
            "jsonrpc": "2.0",
            "method": "server/discover",
            "params": {
                "_meta": {"client": self.client_info}
            },
            "id": 1
        }
        resp = httpx.post(self.server_url, json=payload, timeout=10)
        return resp.json()

    def call_tool(self, tool_name: str, arguments: dict, request_id: int = 1) -> dict:
        """独立调用工具，不依赖任何前置会话"""
        payload = {
            "jsonrpc": "2.0",
            "method": "tools/call",
            "params": {
                "name": tool_name,
                "arguments": arguments,
                "_meta": {"client": self.client_info}
            },
            "id": request_id
        }
        resp = httpx.post(self.server_url, json=payload, timeout=30)
        return resp.json()


# 演示：连接到任意 MCP Server 实例，每个请求独立
client = StatelessMCPClient("https://mcp.example.com")
caps = client.discover()
print(f"服务器能力: {json.dumps(caps, indent=2)}")

result = client.call_tool("search_docs", {"query": "MCP stateless migration"})
print(f"工具调用结果: {json.dumps(result, indent=2)}")

这段代码的核心在于：没有构造函数里建立连接的步骤，没有会话保持的逻辑，每个方法调用都是一次独立的 HTTP 请求。你可以把 StatelessMCPClient 用在 Serverless Function 里、用在 CI/CD Pipeline 里、用在 Webhook Handler 里——任何不能维持长连接的场景。

对比旧版 MCP 客户端，通常会有一个 connect() 方法启动握手、一个 session 属性维护上下文、一个 close() 方法清理资源。新版客户端几乎退化成了普通的 HTTP 封装，这正是设计目标。

四大云厂商 day-zero 支持

Anthropic、AWS、Google Cloud、Microsoft 和 Cloudflare 都在规范发布当天宣布支持新版 MCP。这五个名字放在一起，信号很明确——MCP 已经从 Anthropic 自家的协议变成了行业标准。

各家的支持形式不同：AWS 将新版 MCP 集成到 Bedrock Agent 的运行时中；Google 在 Gemini Agent Platform 里提供了 MCP 的托管端点；Cloudflare 直接用 Workers 实现了参考服务器；Microsoft 则在 Copilot Studio 里增加了 MCP 工具连接器。

最值得关注的是 Anthropic 将新版 MCP 引入 Claude。这意味着通过 Claude Code 或 Claude API 调用的工具连接将默认使用无状态模式。存量应用需要一个迁移窗口——Anthropic 承诺在最终规范发布后保留 60 天的向后兼容期。

迁移成本：一次配置更新，不是架构重写

如果你已经在生产环境中运行 MCP Server，对 2026-07-28 规范的升级路径比想象中平坦。核心变更集中在协议层——客户端库和服务器框架的维护者需要更新实现，但作为使用者，你通常只需要更新依赖版本，然后检查部署配置。

三个需要手动处理的变更点：

如果你使用了粘性路由或会话亲和性配置（如 Nginx ip_hash、AWS ALB stickiness、Kubernetes sessionAffinity），可以直接移除——新 MCP 不再需要它们
如果你有基于 Mcp-Session-Id 的日志追踪或请求关联逻辑，需要替换为基于请求 ID 的关联——因为会话 ID 不再存在
如果你在连接时依赖 initialize 返回的服务器能力做静态配置，需要改用 server/discover 在运行时动态获取

对绝大多数团队来说，这三点变更加起来不超过两个小时的适配工作。相比带来的部署灵活性收益，迁移成本可以忽略不计。

几个容易被忽视的细节

无状态化并不意味着应用层不能维护自己的状态。协议不再强制会话，但你的工具完全可以在应用层使用 Token 或 API Key 来关联多次请求。区别在于：过去你必须遵守协议的会话机制，现在你可以选择自己的方式。

_meta 字段的引入也值得注意。原来的 initialize 数据现在附着在每条请求上，这意味着每条请求的体积多了一百到几百字节。对于低频调用，这个开销可以忽略。但对于高频微调用场景（比如 Agent 在循环中反复调用同一个工具），冗余数据量的累积值得关注。好在 MCP 使用 JSON-RPC 2.0，支持二进制传输优化，大规模部署时可以选择 CBOR 或 MessagePack 编码。

最后，SEP-2260 对服务器端发起的请求的约束，意味着以前那种"工具服务器定时推送告警给 Agent"的模式行不通了。如果你的系统依赖这种模式，需要用另一种方式实现——比如 Agent 主动轮询，或者通过消息队列中转。

这其实是在推动一种更健康的架构：Agent 应该主动询问，而不是被动接收。前者可审计、可回溯、可控制；后者引入了不可预测的外部输入源——安全团队在过去一年反复强调的风险正是在于此。