2026 年 7 月 28 日，MCP（Model Context Protocol）发布了自 2024 年 11 月诞生以来最大规模的架构重构：取消协议层 Session，改为每次请求携带完整处理信息。

同一天，A2A 协议庆祝一周年并宣布 150+ 组织生产部署；同一周，中国发布 GB/Z 185-2026《智能体互联互通》，29 国在上海签署 WAICO 创始文件。这一周被称为 Agent 协议层的"Kubernetes 时刻"。

协议不再替你记事，这是一次划界

这次重构常被描述成一次性能优化。但它不是。

MCP 做的事情是把状态管理的责任从协议层踢给应用层——协议不再替你记住任何东西，你自己想办法存。这不是性能取舍，是一次产业分工的划界：协议层收缩到只管传输语义，状态存在哪、断线后怎么恢复，这些全部下沉为应用侧或云厂商的生意。

如果只是性能优化，不会在同一周同时出现 A2A 的 150+ 生产部署、中国的互联互通国标和 29 国的多边文件。协议改版和标准动作扎堆，说明各方在抢的是同一件东西的定义权。

分界线不在毫秒，在能不能加机器

旧版 MCP 要求客户端与服务器维持长连接会话。这在单机调试时毫无问题，搬进生产环境就会连环触发三件事。

Pod 一重启，整个会话丢失；为了不让请求跑到别的实例上，负载均衡被迫做粘性路由；粘性路由一开，Kubernetes 的水平扩缩容形同虚设——加了十个副本，流量还是黏在原来那一个上。

用一个更直观的对照：旧版像去银行必须先开一个房间，办事期间房间一直占着，柜员换班就得从头再来一遍，而且下次来还必须找同一个柜员。新版是每次办业务自带全套证件，任何一个窗口都能接单，人多了就多开窗口。

这是能不能水平扩容的分界线，不是快几毫秒的问题。

MCP 工程负责人 Mazin Gilbert 说得很直接："有状态 Session 是企业从试点走向数万 Agent 规模部署的首要障碍。"

幂等做漏了，只会安静地多扣一笔钱

无状态协议下，上下文与任务进度必须由应用自己持久化，工具调用历史也一样。存储介质可以是 Redis，也可以是数据库或专门的状态服务。开发者要多写这一层，运维要多管一套存储。

还有一个更隐蔽的转移：幂等性。

每次请求自带完整信息、任何实例都能接单，同时也意味着重试变得廉价而频繁。如果一次请求触发的是"下单"或"转账"这类有副作用的工具调用，网络抖动导致的重发就可能变成重复执行。旧版靠会话上下文还能勉强判断"这个请求我见过"，无状态之后，去重键怎么生成、幂等窗口留多久，协议一概不管。

这半份责任同样被推给了应用层，而且比状态存储更难做对——存储写错了会报错，幂等做漏了只会安静地多扣一笔钱。

协议变简单了，系统没有。这恰恰是分工发生的标志：一层把复杂度推出去，另一层就会长出来接住它，并且往往由不同的公司来卖。

商业侧的反应已经出现。阿里云、腾讯云、百度云的 MCP 广场同步接入新规范，恒生聚源等数据平台在上线首日完成适配。云厂商跑得快是有道理的——状态被推到应用层，托管状态服务就成了一门可以计费的生意。

MCP 做减法，Agent Substrate 做加法

同一周还有另一件事：Google 推出 Agent Substrate，定位是 Agent 时代的统一基础设施层。

把两者摆在一起看，方向完全相反。MCP 把状态管理推出协议层交给应用；Agent Substrate 则把状态管理、工具调用、记忆存储、安全沙箱、多 Agent 协调统统收进一套统一 API，让开发者不必关心底层实现。

一个做减法，一个做加法。这不是谁对谁错，是两种商业模型：MCP 靠中立换取被所有人接入，Agent Substrate 靠承接复杂度换取用户留存。

中立也有代价。不承接复杂度就无法直接向使用者收费，Anthropic 从协议里拿到的不是收入，是让自己的模型成为默认接入方的位置。这是一笔用标准影响力换分发的交易，能不能兑现取决于协议是否一直保持中立——而这恰恰是所有开放标准最难守住的东西。

Google 的路径和当年 Kubernetes 如出一辙：开源一个设计精良的抽象层，吸引参与者在其上构建，最终以生态锁定坐实事实标准。

区别在对手数量。Kubernetes 当年主要面对 Docker Swarm 和 Mesos，是相对单一的技术竞品。现在这张桌子上坐着 MCP、A2A、Agent Substrate、微软 Copilot 平台，外加一份中国国家标准。五方混战，谁都还没拿到 Kubernetes 那种统治级份额。

招标文件里"支持 MCP"这句话，从今天起要带版本号

对开发者：改造成本前置了。原先靠会话内存兜住的状态，现在必须显式选型和持久化，还得处理重启后的恢复语义与重试去重。换来的是终于能在 K8s 上正常扩缩容——多写的这层代码，是为规模化提前付的账。已经上线的旧版实现不会自动获得这个好处，迁移是一次真实的工程量，不是升级依赖版本就能了事。

对企业采购：招标文件里"支持 MCP"这句话从今天起必须带版本号。旧版实现在容器编排环境下跑不到规模，验收环节应当要求供应商演示 Pod 重启后的任务连续性，而不是只看一次成功的调用截图。同时建议在合同中明确状态存储的归属方——它现在是一项独立的、可以被单独计费的服务。

对普通用户：几乎无感。这一层的变化不会改变任何界面，唯一可能被察觉的是 Agent 类服务在高并发时段的稳定性有所改善，原因恰恰是它现在可以靠加机器解决问题了。

答案在年底的招标条款里

GB/Z 185-2026 是指导性技术文件，不是强制性国家标准。这个区别决定了它当下的分量：它提供的是参照系，不是门槛。

第 一个验证时点在今年年底：观察是否有云厂商或国企采购把它写进招标文件的硬性条款。一旦进了条款，指导性文件就获得准强制的执行力，各家的适配优先级会立刻改变。

第二个信号来自 Anthropic：下一版 MCP 规范是否把 A2A 的协商机制纳入自身。纳入，说明协议层还在继续收敛，五方混战会提前收场；不纳入，说明各家已默认当前的分工边界，接下来比的是谁的实现跑得更稳。