MCP 路线图不是发布计划，也不是兼容性承诺
MCP 的规范、扩展、SDK 和传输层正在以不同速度演进。路线图中的优先事项并不会让两个产品实现互操作。
Model Context Protocol（MCP）路线图列出了维护者希望推进的五个领域，从代理消息传递和传输层变更，到工作负载身份和 SDK 一致性。它并不会让这些能力在同一个版本中发布。
这种差异具有运营层面的影响。MCP 的 2026-07-28 规范目前已经可用，但 8 月 22 日路线图中的若干项目仍是提议中的设计、正在成熟的扩展，或尚未进入核心协议的工作。即使是已经发布的行为，也可能需要显式的 SDK 设置，而不是随着包版本变化自动到来。
安全的部署规则是：只有当协议状态、确切的 SDK 行为、目标客户端和服务器、回退方案、一致性证据以及回滚路径全部一致时，才批准一项 MCP 能力。 对已经发布但表现不均一的行为使用功能标志。不要把路线图意图放进生产依赖。
一个 MCP 功能可能有四种不同的成熟度标签
官方路线图称，它涵盖的是维护者对未来六到十二个月的当前思路，而不是确定的承诺。优先事项可能移动，设计可能改变，工作也可能延期。它列出的五个领域很有用，因为它们揭示了规范审查和工作组工作将集中在哪里。但它们不会告诉运营人员某个特定的客户端和服务器今天就能互操作。
2026-07-28 规范发布是另一种类型的产物。它用自描述请求取代了协议层面的会话和初始化握手，引入了 server/discover，增加了标准 HTTP 路由标头和缓存提示，正式确定了扩展，并强化了授权。这些是已经发布的协议决策。
SDK 仍可能暴露更窄的默认行为。当前的 TypeScript 迁移指南称，除非选择版本协商，否则客户端会使用旧版 2025 握手。mode: 'auto' 会通过 server/discover 探测并可以回退；固定使用 2026-07-28 则会拒绝不提供该修订版的服务器。因此，安装现代 SDK 并不能证明已部署的连接使用了现代线路行为。
四种标签必须彼此分开：
| 标签 | 它能确立什么 | 它不能确立什么 |
|---|---|---|
| 路线图优先级 | 维护者打算在此投入审查和设计工作 | 最终设计、发布日期或可互操作的实现 |
| 规范或扩展状态 | 项目在规定的生命周期阶段定义了版本化契约 | 团队实际部署的语言、版本、主机、网关和对等端是否支持 |
| SDK 支持 | 某条库版本线暴露了契约的某种实现 | 它的默认配置、另一个 SDK 的行为，或端到端兼容性 |
| 部署证据 | 一对固定版本的客户端和服务器通过了团队的夹具与回滚测试 | 任一端点、扩展、网关或策略发生变化后的兼容性 |
软件包徽章会把这些标签压缩成一个概念。部署记录必须保留它们之间的区别。
已发布和计划中的 MCP 功能处于不同阶段
下面的矩阵将当前路线图和已发布的规范转换为保守的默认决策。“发布”并不意味着普遍安全，而是意味着底层行为已经发布，并且在通过指定的实现和互操作性门槛后可以进入生产环境。
| 能力和当前证据 | 证据支持的做法 |
|---|---|
2026-07-28 无状态核心、自描述请求和 server/discover。 已在有日期的核心规范中发布；当前官方 SDK 版本线支持它，但各语言的迁移行为不同。 | 发布，但仅针对固定版本的一对端点。 记录客户端和服务器的 SDK 版本，启用预期的协议模式，验证发现或直接版本错误，测试路由标头，并保留旧版回退或明确的拒绝策略。 |
迁移期间的双时代协商。 TypeScript v2 客户端通过显式的 legacy、auto 或现代固定模式实现；其他 SDK 需要各自的证据。 | 使用功能标志。 测试现代到现代、现代到旧版、授权失败、超时和回滚路径；记录协商出的修订版，不要从包版本推断它。 |
| Tasks 扩展。 这是一个已发布的扩展；路线图称维护者希望让它成熟，最终纳入核心。 | 使用功能标志。 固定扩展版本，验证两个对等端都声明并实现了它，测试轮询和取消语义，并在能力协商失败时拒绝使用。 |
| Enterprise-Managed Authorization。 项目引用的稳定扩展，但不是每种 MCP 部署通用的身份层。 | 使用功能标志。 将授权服务器、客户端、服务器、授权授予、令牌受众、委托边界和撤销行为作为一条经过测试的路径进行验证。 |
| 通过 Webhook 或通道由服务器发起的事件。 这项路线图交付旨在减少轮询；它与 Tasks 及其他事件工作的最终组合仍在开发中。 | 观察。 等待版本化契约和目标 SDK 支持，然后测试投递、身份验证、重放、顺序、取消、重试和回退。 |
| HTTP over stdio 传输统一。 这一路线图方向旨在通过本地进程 I/O 携带 Streamable HTTP 语义。 | 观察。 要求已接受的规范或扩展、两个端点中的已发布支持、成帧和关闭测试，以及回退到当前受支持的传输方式。 |
| DPoP 采用、工作负载身份和代理委托。 路线图工作借鉴了现有身份标准；MCP 特定的路径还不是一个已经发布、可以直接使用的完整功能。 | 观察。 要求版本化的 MCP 契约，以及颁发者、受众、证明密钥、令牌交换、委托、过期、撤销和跨租户测试。 |
| 重新设计的工具结果和渐进式发现。 路线图工作旨在明确结果保真度，避免一开始就加载大型工具目录。 | 观察。 等待稳定的模式和 SDK 实现；测试模型可见的保真度、缓存行为、发现完整性、授权过滤以及完整目录回退。 |
| 生成的 SDK 产物和更广泛的一致性自动化。 路线图实验旨在测试哪些 SDK 和快速入门层可以生成并重新验证。 | 观察。 将已发布的一致性结果仅视为特定套件、修订版、SDK 提交和所测试角色的证据；不要仅因生成输出来自该实验就部署它。 |
这个矩阵有意采用不对称的标准。一个已发布的扩展可以先获得“功能标志”状态，再考虑是否属于核心。路线图功能不会因为某个供应商暴露了一个名称相似的东西，就获得“发布”状态。产品特定的行为可能有用，但必须记录为该供应商的扩展，而不是 MCP 的普遍支持。
已发布的行为在运行时仍可能不同
一个具体的连接包括客户端、服务器、两个 SDK 实现、传输层、授权路径、协议修订版以及任何扩展。“MCP 兼容”把所有这些变化中的部分压缩成了一个标签。
协商出的修订版可能不同于依赖版本所暗示的修订版。较旧的对等端可能触发回退或明确拒绝，网关规则可能改变线路行为，而已声明的扩展可能不存在或只实现了一部分。Arcade 的独立迁移指南预计公共服务会经历双栈时期，正是因为客户端不会同时更新。
TypeScript 让软件包与运行时之间的区别格外明显。其 v2 指南记录了三种连接策略：默认使用旧版、通过自动发现并回退，以及仅使用现代版本固定模式。平台团队可以合理地为公共服务选择自动协商，为受控集群选择仅使用现代版本固定模式。即使两个部署使用同一 SDK 版本，它们也是不同的风险决策。
每个变化中的层都可能使兼容性失效
当协议、扩展、客户端 SDK、服务器 SDK、主机产品、网关、授权配置、功能标志或一致性套件发生实质性变化时，兼容性就会过期。路线图提案变成已发布扩展时，兼容性也可能过期：这正是重新开启审查的理由，而不是自动提升旧的观察项目。
为每一行标注日期，并把源 URL 放在旁边。规范变更日志是已发布核心行为的基线；路线图解释预期方向；SDK 文档解释某个实现如何暴露契约。它们分别回答不同的问题。
因此，路线图最有价值的生产教训并不是某一项功能，而是 MCP 正在多个层面同时移动这一警告。分别记录这些层的团队可以采用已经发布的改进，而不会把项目势头误认为互操作性。