你去银行办一次业务，旧流程要求先领号、登记，再拿着专属号码去柜台；新流程则尽量让你一次交齐材料，任何空闲柜台都能接手。7 月 28 日发布的新版 Model Context Protocol specification，做的正是类似的改变：服务器不再必须长期记住每段会话，MCP 因而更容易部署到云端，也更像一块能承载大规模 Agent 的基础设施。
这版规范常被 Simon Willison 非正式地称作“MCP 2.0”，但它并不是官方版本号。Willison 将其评价为 MCP 发布以来最重大的规范变化。不过，目前供稿只有他的一篇个人博客，相关判断没有独立测试或多方材料交叉验证。
MCP 为什么需要为规模化补课？
MCP——Model Context Protocol，模型上下文协议——由 Anthropic 在 2024 年 11 月推出。它规定 AI 应用怎样以统一方式连接外部工具和数据源，类似一套供不同厂商共同遵守的接口语言。
它在 Agent 基础设施里扮演“连接层”：Agent 负责理解任务和决定下一步，MCP 则规定它怎样发现、调用外部能力，以及怎样接收结果。这样，开发者不必为每种工具重新设计一套连接办法。
旧版 MCP 的麻烦在于“有状态”。服务器需要记住客户端此前建立的会话。在 Willison 引用的一个基础调用示例中，客户端先发送一次 HTTP 请求初始化会话，取得 Mcp-Session-Id；随后再发送第二次请求，实际调用工具。
单次看，这只是多一个步骤。到了云端，问题会被放大。大量请求通常需要通过负载均衡——也就是把流量分给多台机器，避免一台服务器过载。服务器一旦保存会话状态，后续请求往往还要找到了解这段会话的机器，调度、扩容和故障接替都会更麻烦。
这里需要谨慎一点：材料展示的是一种基础调用流程，不能据此断言旧版 MCP 的所有交互都必然、且永远恰好需要两次请求。
无状态，改变的不只是少一次请求
新版规范正式引入 stateless MCP，也就是无状态 MCP。所谓“无状态”，不是系统完全没有上下文，而是服务器不必长期替每个客户端保管一份会话记忆。请求尽量携带完成处理所需的信息，因此可以交给任意一台可用机器。
这就像把完整工单放进每次派送的文件袋：接单的人不必先找到上一位经办者留下的笔记。对应到云端部署，请求更容易被负载均衡分发；某台机器出故障时，其他机器也更容易接替。
我们在 7 月 22 日的报道中已经解释过，放宽 session ID 要求为什么有利于扩容。7 月 28 日这版规范更值得关注的地方，是无状态设计不再只是一个部署方向，而被纳入一次正式、系统性的协议升级。协议规范影响的不是某个单独产品，而是所有按照这套语言连接工具的客户端、服务器和 Agent 框架。
据 Willison 的个人体验，新规范显著降低了 MCP client 和 server 的实现复杂度。他受此启发开发了 mcp-explorer 和 datasette-mcp，并称自己一周内构建了三个 MCP 客户端或服务器实现。这能说明新设计至少让个人开发者感到更轻便，但材料没有提供代码量、开发时间对比或基准测试，因此还不能把这种体验直接推广到整个生态。
为什么 MCP 又值得看了？
Willison 回顾称，MCP 在 2025 年迅速走红，后来受到 Skills 和“terminal + curl”方案的挤压。后一种办法让 Agent 直接操作终端，并通过 curl 访问网络，灵活性更高，许多任务不再一定需要专门的 MCP 接口。
但灵活也意味着更大的权限边界。按照 Willison 的判断，向 Agent 开放 shell——也就是可直接执行命令的系统环境——和互联网访问，风险更难控制，而且需要能力较强的模型来正确操作。相比之下，MCP 工具暴露的是预先定义好的能力，更容易检查它能做什么、限制它能访问什么；接口也更简单，较小的本地模型仍可能合理调用。
这些仍是作者判断，材料没有给出安全事件统计、小模型成功率或市场使用量。不过，它点出了 MCP 的另一条价值线：它未必是最自由的工具连接方式，却可能更适合需要权限管理、审计和稳定部署的 Agent 系统。
无状态升级把这条路线向前推了一步。MCP 原本解决的是“工具怎样统一接入”，现在开始补上“接入之后怎样大规模运行”。对云端 Agent 服务而言，后一个问题同样关键：接口再统一，如果服务器难以横向扩容、故障后难以接替，也很难成为可靠的公共基础设施。
局限与未知
- 目前材料只有 Simon Willison 的个人博客。关于“最重大变更”、复杂度下降、安全性和小模型适用性的判断，均缺少独立验证。
- 材料没有披露无状态 MCP 在延迟、吞吐量、资源消耗或故障恢复方面的量化结果，也没有说明迁移旧版服务的成本。
- 示例中的
protocolVersion为2025-11-25，材料没有解释它与 2026-07-28 规范之间的兼容关系，因此不宜据此推断具体版本迁移规则。