Agents
MCP 的成人礼：放下状态，交出钥匙
2026-07-28 新版 MCP 规范发布。回看一年半里 MCP 的两次放手——协议层放下会话状态，治理层交出项目钥匙——一个协议如何慢慢长成公共基础设施。
5 分钟#mcp#protocol#agents#open-governance
2026-07-28 新版 MCP 规范发布。回看一年半里 MCP 的两次放手——协议层放下会话状态，治理层交出项目钥匙——一个协议如何慢慢长成公共基础设施。
2026 年 7 月 28 日，MCP（Model Context Protocol）新版规范正式发布。社区习惯把它叫作 "MCP 2.0"——变化确实够大，配得上一个大版本号。但有个细节值得玩味：官方从来不用这个名字。从诞生至今，规范一直用日期做版本号：2024-11-05、2025-03-26、2025-06-18、2025-11-25，到这次的 2026-07-28。
不做大版本号营销，只用日期，这是 HTTP、TLS 这类基础设施协议的做派。日期不承诺"革命"，只记录"演进"。一个协议选择用什么方式给自己命名，多少透露了它想成为什么。而回看这一年半，MCP 做了两次意味深长的放手。
早期的 MCP（2024-11-05 版本）是"有状态"的：客户端与服务器要先经过 initialize/initialized 握手建立会话，服务器要记住每一个客户端——会话状态、长连接，一样都不能少。
这有点像一家认脸的老店。店员记得每位常客的喜好，你一进门，热茶已经沏上。体贴，是真体贴。但这家店很难开分店：客人必须找到同一位店员才能续上之前的话头（负载均衡需要粘性会话）；店员请假，整段服务就断了（实例故障丢会话）；更别提在"随叫随到的临时摊位"上营业了（serverless 环境几乎无法承载这种模式）。
对个人开发者在本地跑一个 MCP 服务器来说，这些都不是问题。但当协议想服务成千上万的并发连接时，"记住每个人"就从体贴变成了负担。
转变分了两步。2025-03-26 版本引入 Streamable HTTP，是一次过渡：请求统一走 POST /mcp，会话从必需变为可选。到 2026-07-28 版本，通过 SEP-2575（"Make MCP Stateless"），转身彻底完成：initialize 握手与 Mcp-Session-Id 被移除，协议版本、客户端信息与能力声明改为每个请求随身携带——通过 MCP-Protocol-Version 请求头与 _meta 字段。
换句话说，客人不再依赖店员的记忆，而是自己把喜好写在随身的卡片上。任何一台服务器实例，都能接住任何一个请求。老店终于可以开成连锁店了。
如果说第一次放手发生在协议层，第二次则发生在治理层。
2025 年 12 月 9 日，Anthropic 宣布将 MCP 捐赠给 Linux Foundation 旗下新成立的 Agentic AI Foundation（AAIF）。共同发起方名单颇有意思：Anthropic、Block 和 OpenAI，而 Google、Microsoft、AWS、Cloudflare 等也都参与支持。
竞争对手坐在同一张桌子旁，共同维护同一个协议——这在商业竞争的语境里听起来有些反直觉，但在基础设施的历史里有先例可循。Kubernetes 就是最常被提起的一个：Google 把它交给 CNCF 之后，它才真正从"Google 的容器编排工具"变成了行业标准。竞争对手们愿意在它之上构建，恰恰因为它不再属于任何一家。
把两次放手放在一起看，会发现它们有一种同构性。技术上，无状态化去掉了协议对"某一台服务器"的依赖——任何实例都能服务任何请求；治理上，捐赠去掉了项目对"某一家公司"的依赖——任何厂商都能平等参与。两件事看似无关，方向却出奇一致：把一件产品，慢慢变成一件公共基础设施。
基础设施的特点，恰恰是"不属于谁"。没有人会说自来水管道是哪家公司的产品，也没有人在意 HTTP 属于谁。
当然，这两次放手都不是免费的。
无状态化意味着每个请求都要重复携带上下文，高频场景下的开销会略有增加。服务器主动发起请求的能力也被重新设计：原有的 sampling 机制进入弃用期（有 12 个月的移除窗口），由新的 MRTR（多轮往返请求）机制承接；订阅通知也改为由客户端显式发起 subscriptions/listen。
社区里有不同的声音。一种有代表性的担忧是："复杂度并没有消失，只是从协议层移到了应用层。"这话有道理——服务器不再记住状态，不等于状态不存在了，只是记忆的责任换了地方。这类担忧是合理的，值得时间来检验。
开放治理同样有成本。提案要走流程，决策要多方协调，一家公司拍板一天能定的事，基金会里可能要讨论几周。速度慢了，这是明摆着的。但 Kubernetes 等先例说明，用短期的决策速度换取长期的中立性与信任，这笔交换在长周期里通常是划算的。愿意在一个协议上押注未来的人，在意的往往不是它迭代多快，而是它会不会哪天变成某一家的私产。
判断一个协议能否走远，或许不必只看功能列表的长短，也可以看它愿不愿意做减法、愿不愿意放手。
功能是往上加的，加起来总是容易；而放手意味着承认"有些东西不该由我持有"——不该由某台服务器持有会话，不该由某家公司持有协议。这种判断做起来难，因为每一次放手，都是在放弃一部分控制力。
MCP 用一年半的时间做了两次放手：一次放下了状态，一次交出了钥匙。它会不会因此成为 Agent 时代的 HTTP，现在下结论还太早，剩下的交给时间。
倒是可以留一个问题慢慢想：如果"放手"是基础设施成熟的方向，那么下一个被放手的会是什么——Agent 的记忆？Agent 的身份？还是某个我们此刻还没意识到"不该由谁持有"的东西？