7 月 28 日，Model Context Protocol（MCP）发布了自 2024 年 11 月开源以来最大的一次修订。核心变化只有一句话：MCP 的协议核心从有状态双向连接，变成了无状态请求-响应。

听起来像是个实现细节，但它实际上改变了 MCP 能走多远。如果说之前的 MCP 更像是一个「本地桌面扩展协议」，这次修订后，它开始像 AI Agent 的 HTTP。

什么变了：从握手到自包含请求

在 2026-07-28 修订之前，MCP 远程连接需要一次 initialize 握手，并维护一个 Mcp-Session-Id 来保持会话状态。服务器和客户端之间维持着一条持久的双向连接——通常是 SSE（Server-Sent Events）。这对本地 stdio 场景没问题，但在云环境里很别扭：水平扩展需要会话亲和性，serverless 函数很难保持长连接，负载均衡器也得特殊配置。

新版把这一切都拆了。现在每个请求都是自包含的：协议版本、客户端能力、身份上下文全部放在请求 metadata 里发过去，服务器不需要记住上一个请求是谁。官方维护者 David Soria Parra 和 Den Delimarsky 在发布公告里把它称为「MCP 远程化以来最重要的一次更新」。

具体变化包括：

• 无状态协议核心：移除 initialize 握手和 Mcp-Session-Id；
• 多轮往返请求（Multi Round-Trip Requests）：复杂交互不再依赖单一长连接；
• 基于 header 的路由：更友好地适配 CDN、网关、负载均衡；
• 可缓存的 list 结果：减少重复查询开销；
• 鉴权强化：OAuth 2.1 资源服务器语义更严格；
• Extensions 框架：首批官方扩展包括 Tasks（长运行任务）和 MCP Apps（服务器渲染 UI）；
• 正式弃用政策：任何功能从标记弃用到真正移除，至少 12 个月缓冲期。

这些改动加在一起，目标只有一个：让 MCP server 可以像普通 Web 服务一样部署。

为什么重要：协议层开始像基础设施

MCP 最初的设计灵感是「给 AI 一个 USB-C 接口」：写一个 server，任何兼容的 client 都能用。这个想法在本地和中小规模场景里跑通了，但当它要进入企业生产环境时，有几个硬门槛：

1. 扩展性：有状态连接意味着扩容必须先解决会话粘性；
2. serverless/edge：Lambda、Cloudflare Workers 这种无状态环境天然不喜欢长连接；
3. 网关集成：企业 API 网关通常按无状态 HTTP 设计；
4. 可观测性：有状态连接让 tracing 和日志聚合更复杂。

无状态化之后，这些问题都变得普通了。你可以在 Kubernetes 后面放 100 个 MCP server 副本，前面随便挂一个负载均衡器；可以把 server 跑在 serverless 函数上，按调用计费；可以用标准的 OpenTelemetry 链路追踪。

换句话说，MCP 正在从「一个让 Claude Desktop 能连本地工具的协议」，变成「让任何 AI Agent 都能调用任何企业服务的协议层」。

2026 路线图的四张牌

MCP 指导委员会在 2026 路线图中提了四个优先方向，正好对应协议从「好玩」到「能跑生产」的四个缺口：

1. 传输演进与无状态会话 这就是 7/28 修订在做的事。Streamable HTTP 预计在 2026 Q3 进入规范草案，Q4 支持无状态会话。stdio 和 SSE 会长期保留，但新 server 应该面向无状态 HTTP 设计。

2. Agent 通信的可靠语义 当 MCP 从「调一个工具」变成「运行一个长任务」时，重试、超时、消息过期就变得关键。路线图要 formalize retry semantics 和 expiration，让 client 知道一个调用是暂时失败、永久失败、还是正在后台跑。

3. 治理成熟化：SEP 与贡献者阶梯 MCP 引入了 SEP（Specification Enhancement Proposal）流程，类似 Python 的 PEP。这意味着协议演进不再是单一公司拍板，而是社区提案、讨论、批准的开放过程。对于想成为基础设施的协议来说，这是必要一步。

4. 企业就绪：审计、SSO、Server Cards 企业级 MCP 需要知道「谁调了什么工具、什么时候、结果如何」，也需要让 agent 自动发现可用的 server。MCP Server Cards（.well-known/mcp-server-card）就是让 agent 像抓 robots.txt 一样自动发现工具能力；审计轨迹和 SSO 则是合规刚需。

MCP 与 A2A：不是竞争，是分工

2026 年 4 月，Google、AWS、Microsoft、Salesforce、SAP、ServiceNow 等 150 多家组织发布了 Agent-to-Agent（A2A）协议 1.0 GA。很多人问：A2A 会不会替代 MCP？

答案是不会，它们是互补的。

• MCP 解决 agent-to-tool：一个 agent 怎么调用数据库、API、文件系统、SaaS 应用；
• A2A 解决 agent-to-agent：多个 agent 之间怎么协商任务、交换上下文、确认完成。

用一个不严谨但好记的类比：MCP 是员工调用公司内部系统的接口规范；A2A 是员工之间发邮件、开会的协议。两者都需要，且都不应该由某一家公司私有。

Gartner 把 MCP 和 A2A 的广泛采用称为 AI Agent 的「TCP/IP 时刻」——这不是夸张。HTTP 把计算机连成互联网，MCP+A2A 有可能把软件、数据、API 和 agent 连成一个由 AI 编排的网络。

对开发者的实际影响

如果你正在写 MCP server，最值得注意的只有一条：不要再依赖连接状态。新的远程 server 应该假设每个请求都是独立的，能力发现通过每请求的 metadata 完成，而不是通过一次性的 handshake。

如果你正在写 client 或 agent 框架，需要把 transport 抽象做好：stdio 用于本地、SSE 用于兼容、Streamable HTTP 用于云原生。同时开始关注 MCP Server Cards，未来 agent 的工具发现大概率会走这个机制。

如果你在企业里评估 AI 集成架构，MCP 现在可以进入「基础设施层候选名单」了。它不再是 Anthropic 的私货，OpenAI、Google、Microsoft、Salesforce 都在支持或集成；协议治理也在走向开放。选对协议，比选对某一家模型更重要。

参考来源

• MCP Specification 2026-07-28 Revision Changelog (official MCP documentation)
• David Soria Parra & Den Delimarsky, MCP stateless core announcement (2026-07-28)
• OpenLLM / Wavise, "MCP 2026 Roadmap: Four Priorities Reshaping AI Agents" (2026)
• Stellary, "What MCP changes for AI coding tools (Sept. 2026)" (2026-09-01)
• BestHub, "Large Models as Engines, Tool Ecosystems as Limbs" (2026)
• Ars Technica / Percettiva coverage on MCP stateless overhaul (2026-07-30)
• A2A Protocol 1.0 GA announcement (2026-04)