MCP 2.0深度解析：无状态协议如何重塑AI Agent通信标准

MCP走过近两年：一个社区驱动的协议如何成长

Model Context Protocol（MCP，模型上下文协议）诞生至今已近两年。它于2024年11月首次发布，此后经历了多次迭代——2025年发布三个版本，2026年7月又推出一次官方更新。据MCP核心维护者、微软技术团队成员在此次"State of MCP"分享中透露，团队已经在筹备2026年的第二个版本，暂定于12月15日发布（时间仍非常初步）。

作为一个社区驱动的项目，MCP的增长数据颇为亮眼：包下载量已达5.14亿次并持续攀升，GitHub仓库的commit贡献者数量不断增加，fork数量也在稳步增长。这些指标共同说明——开发者正在积极使用、实验并推动这一协议演进。MCP的定位始终清晰：为模型带来上下文、支持agentic工具调用，成为连接大模型与外部能力的通用框架。

从路线图到MCP 2.0：一次"撕掉创可贴"的重大变革

2026年1月，MCP团队发布了首份路线图，明确了几个核心方向：传输层与可扩展性、消息类型扩展、治理成熟度以及企业级就绪能力。基于这份路线图，团队在7月28日推出了被称为"MCP 2.0"的版本——这被认为是自首个版本以来最大的一次发布。

之所以称之为"最大"，是因为团队做出了一些艰难的决定，引入了破坏性变更（breaking changes）。用维护者的话说，这是为了让协议在未来"更持久、更具防御性"。7月发布的内容几乎逐条对应了1月路线图设定的目标：围绕传输演进做了大量工作使MCP变为无状态、无会话；将tasks更新为无状态并转为官方扩展；完善治理流程；强化企业就绪能力。

核心变革：为什么MCP要变成无状态、无会话？

MCP 2.0最受关注的改动，是将协议改为无状态（stateless）、无会话（sessionless）。这是一个破坏性变更，团队为此进行了大量讨论并广泛征求社区意见。

协议开销过高是最直接的痛点

来自大型组织的反馈显示，旧协议的消息开销极高。由于需要维护状态、要求initialize握手，团队内部统计发现，某些服务器50%甚至更多的消息只是协议消息——比如initialize、list tools等。随着MCP日益流行、越来越多的agent调用它，这种高达一半的额外开销变得难以承受，尤其是在你无法从中获得明显收益时。

所谓"协议消息"，是指在真正的业务逻辑调用发生之前，双方为建立共识而交换的元信息。MCP 1.0 遵循 JSON-RPC 2.0 规范，要求客户端在首次连接时发送 initialize 请求，服务器返回自身能力描述，客户端确认后才能发出业务请求。在本地 STDIO 场景下，这套握手一次性完成，成本可忽略不计。但在云端 HTTP 部署中，每当客户端实例重启、负载均衡将流量路由到新节点，或 serverless 函数冷启动时，握手就必须重新进行。对于高频、短生命周期的 agent 调用而言，这种固定开销会被急剧放大——这正是"50% 消息只是协议消息"这一数字背后的现实场景。

持久连接与会话的现实困境

旧版MCP（1.0）要求远程服务器使用持久连接或粘性路由（sticky routing）。对于本地STDIO传输这不成问题，但对HTTP传输却是挑战。而团队观察到的现实是：大多数被构建和部署的MCP服务器其实只提供无状态工具，这给了团队信心——应该让主流场景变得简单易用、运维负担更低。

此外，会话（session）的作用域定义模糊，协议本身并未明确规定。当同一个使用了会话的MCP服务器从VS Code迁移到ChatGPT或Claude时，各家host的行为略有差异，实际效果并不理想，而且很少有服务器真正尝试这么做。综合这些因素，团队最终"撕掉创可贴"，决定打造无状态、无会话的协议。

无状态之后：这些机制如何替代旧模式

无状态改造带来了一系列具体的机制变化，理解这些有助于开发者把握设计逻辑。

用Server Discover替代initialize握手

旧版的initialize承担了协议版本协商、能力协商和创建会话等多重职能。MCP 2.0引入了server discover特性：客户端可以查询服务器支持哪些协议版本和数据，并且可以缓存结果，无需每次请求或启动时重复进行。同时，每个MCP请求都变得自描述（self-describing）——请求在meta字段或HTTP头（使用streamable HTTP传输时）中携带客户端版本和支持的能力，服务器据此决定接受或拒绝。对使用官方SDK的开发者而言，这些大多在幕后完成，最直观的感受是启动和连接速度更快，因为省去了多轮握手。

用多轮请求处理elicitation与sampling

旧协议中，elicitation和sampling等特性需要会话和持久连接来承载。MCP 2.0引入了多轮往返请求（multi-round trip requests）：当工具调用需要更多信息时，服务器返回一个特殊错误码表示"需要额外输入"，客户端随后获取信息（弹窗询问用户或运行sampling），再带着补充信息重放请求。这一模式的关键在于引入了请求重放，从而实现无状态。

Elicitation 指服务器在工具执行过程中主动向用户索取额外输入的机制，例如要求用户确认某项操作或填写缺失参数；Sampling 则指服务器请求客户端（即 LLM）生成一段文本，从而实现"服务器驱动的推理"，常用于需要模型判断的中间步骤。在有状态协议中，这两者都依赖持久连接来保持调用上下文。改为无状态后，MCP 2.0 的解法是将整个交互拆成独立的 HTTP 往返：服务器以特定错误码挂起请求，客户端完成补充动作后携带完整上下文重放同一请求。这要求客户端实现"请求重放"逻辑，也意味着服务器端的工具必须设计为幂等的——相同输入多次调用不会产生副作用。

用订阅（subscriptions）处理通知

对于list change、进度更新等通知，MCP 2.0提供了订阅机制：客户端主动创建持久通道并保持长连接，服务器将事件推送下来。需要注意的是，通知的传递是尽力而为（best effort），并无送达保证（1.0时代亦如此）。订阅特性完全可选，更适合性能优化或实时应用场景。

用显式状态处理器模式替代会话

如果确实需要类会话行为，官方推荐使用显式状态处理器模式（explicit state handler pattern）：由MCP服务器提供一组管理会话作用域的工具。例如"创建购物车"工具返回一个购物车ID（handler），后续的"添加商品"调用需要携带该ID。这一模式经实践验证效果良好，还带来额外好处——可以同时创建多个会话（多个购物车），这是旧协议会话无法做到的。

Extensions：让协议可组合、可扩展而不臃肿

MCP 2.0正式支持了**扩展（extensions）**机制，它允许在不膨胀核心协议的前提下增加能力，也为社区提供了快速实验的空间。扩展分为三类：

• 官方扩展：属于MCP规范和GitHub组织的一部分，需经核心维护者审核，带有io.modelcontextprotocol前缀。MCP apps和tasks都已成为官方扩展。
• 实验性扩展：尚未正式采纳，如triggers and events扩展、skills over MCP扩展等，正通过工作组收集反馈和实现细节，目标是最终转正。
• 厂商特定扩展：在MCP组织之外开发，任何人都可创建，适合自己同时拥有host和client的定制化场景。若某个厂商扩展被证明具有更广泛的适用性，可以贡献回社区或提议成为官方扩展。

团队特别提出一个建议：想要修改协议的贡献者，应优先将想法实现为扩展，先获取真实世界的数据和反馈，而非直接为全新功能提交SEP。

治理成熟化：让企业敢于押注MCP

治理的演进虽然不体现在规范条文中，却是MCP成为"可信、稳定"协议的关键。

团队发布了新的贡献阶梯（contribution ladder）指南，明确了不同角色及晋升路径；引入了特性生命周期与弃用政策——任何新特性至少支持12个月，并有正式的弃用流程（sampling现已被弃用）。这一点对企业尤为重要：它们可以放心押注MCP，因为所用版本或特性至少还有12个月的支持窗口。

此外，所有新的SEP和新特性都必须包含一致性测试（conformance tests），以维护协议的互操作性，帮助SDK开发者对齐规范。团队还转向更长的候选版本（RC）周期——设立专门的反馈窗口，让SDK维护者、服务器和host创建者有充足时间试用草案协议，只接受重大bug修复后才最终定稿。

SEP（Specification Enhancement Proposal） 是 MCP 采纳自开源社区的标准化提案机制，类似于 Python 的 PEP 或 TC39 的 Stage 流程。任何人都可以提交 SEP，描述新特性的动机、设计方案、安全影响和向后兼容性，经工作组讨论和核心维护者审核后才能进入规范草案。一致性测试（conformance tests）则是与 SEP 配套强制要求的自动化测试套件，用于验证某个 SDK 或实现是否完整、正确地支持了对应特性。对于协议标准化而言，这两个机制共同构成了"说到做到"的闭环——提案有流程、实现有验证，而非仅凭文档描述约定行为。

下一步：从消息模式到企业级安全

2026年8月，团队发布了新路线图，延续并新增了若干主题：

• Agentic消息原语：继tasks和长时运行操作之后，agent的快速演进需要更多消息原语。
• 统一的HTTP原生传输：探索让本地MCP服务器也采用HTTP风格传输替代STDIO，避免在HTTP头和meta字段中重复造轮子。这一议题正在传输工作组讨论，大概率不会赶上12月版本，但需要提前启动。
• Agent身份与企业级安全：持续应对新的OAuth挑战，强化安全能力。
• 改进核心原语：如工具调用的文件上传、更丰富的交互，以及控制哪些数据不应发送给LLM等。

深入agentic消息模式

维护者特别强调，标准的"请求-响应"模式对某些agentic负载和工具调用并不适用——比如向Azure部署资源往往不会立即返回结果。MCP用tasks扩展处理长时运行操作，而团队正计划将这个官方扩展纳入核心协议。

当前tasks仅通过轮询（polling）运作。triggers and events工作组正在探索更多事件消息模式：轮询、通过webhook推送变更、以及通过流式连接传递实时事件。团队还将补充中间结果（intermediary results）相关原语——让长时工具调用或agent能报告"我正在做什么"，并支持**引导（steering）**机制，让客户端提供反馈、调整方向。

值得玩味的是，维护者刻意使用"消息模式与原语"而非"agent"这一表述——因为agent领域仍在快速演进，团队希望先看看仅凭消息模式和原语能走多远，再评估下一步。

轮询（polling） 是客户端定期向服务器查询任务状态的模式，实现简单但存在延迟和无效请求的代价；Webhook 则反转方向，由服务器在状态变化时主动向客户端预先注册的 URL 推送通知，延迟更低但要求客户端具备公网可达的接收端点；流式连接（如 Server-Sent Events 或 WebSocket）在单次 HTTP 连接上持续传递事件，兼顾实时性与防火墙穿透能力，是浏览器和 serverless 环境的常见选择。MCP 当前 tasks 扩展仅支持轮询，triggers and events 工作组正在评估后两种模式的适用边界，核心挑战在于如何在无状态协议框架下让服务器"知道"该向哪里推送、以及如何保证事件不丢失。

如何参与：这是一个社区驱动的项目

MCP反复强调其社区属性。想参与的开发者可以：加入工作组或兴趣组（每个组每周或定期开会，并有Discord频道）；在工作组内提议或评论SEP；启动实验性扩展或厂商特定扩展来尝试新想法；或参与规范、SDK及周边工具的建设。正如维护者所言，MCP能走到今天离不开社区，未来也将由社区共同推动演进。