昨天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-2567Mcp-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一张表看清差异维度旧 MCP2025 规范新 MCP2026-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-2322Multi 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, jsonpayload, timeout10) 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, jsonpayload, timeout30) return resp.json() # 演示连接到任意 MCP Server 实例每个请求独立 client StatelessMCPClient(https://mcp.example.com) caps client.discover() print(f服务器能力: {json.dumps(caps, indent2)}) result client.call_tool(search_docs, {query: MCP stateless migration}) print(f工具调用结果: {json.dumps(result, indent2)})这段代码的核心在于没有构造函数里建立连接的步骤没有会话保持的逻辑每个方法调用都是一次独立的 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 规范的升级路径比想象中平坦。核心变更集中在协议层——客户端库和服务器框架的维护者需要更新实现但作为使用者你通常只需要更新依赖版本然后检查部署配置。三个需要手动处理的变更点如果你使用了粘性路由或会话亲和性配置如 Nginxip_hash、AWS ALBstickiness、KubernetessessionAffinity可以直接移除——新 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 应该主动询问而不是被动接收。前者可审计、可回溯、可控制后者引入了不可预测的外部输入源——安全团队在过去一年反复强调的风险正是在于此。这不是终局是基础设施分化的起点MCP 2026-07-28 规范的最大意义不是它改了什么而是它暗示了一个方向——AI Agent 协议正在从一个标准通吃所有分化成不同场景不同协议。SQLite 的创立者有一个著名判断每一代软件都会从单体走向分层从统一走向分化。MCP 正在经历这个阶段。现在 MCP 处理的是工具连接的通用部分。未来我们可以预见更专门的子协议面向实时通信的低延迟变体、面向 IoT 设备的带宽优化变体、面向金融交易的一致性优先变体。2026-07-28 版本拆掉了有状态会话这个通用假设为这些专业化的协议变体清出了空间。对于正在构建 AI Agent 的开发者今天的 MCP 更新传递了一个比技术细节更重要的信号基础设施正在从能用走向适合。选择协议和工具的标准正在从能不能跑通变成在什么规模下跑得最顺。