> ## Documentation Index
> Fetch the complete documentation index at: https://mcp.zhcndoc.com/llms.txt
> Use this file to discover all available pages before exploring further.

# 路线图

> 我们演进模型上下文协议的计划

<Info>最后更新：**2026-03-05**</Info>

本页描述了我们的战略优先级，以及我们期望 **工作组** 和 **兴趣小组** 据此交付的内容。

<Note>
  此处提出的想法并非承诺。我们解决这些挑战的方式可能与描述不同。某些项目可能根本不会实现。这也不是一个 *详尽* 的列表。我们可能会纳入此处未提及的工作。
</Note>

## SEP 优先级

**属于以下优先领域的 SEP 将获得加速审查，并且接受的可能性最高。** 这些领域之外的 SEP 不会被自动拒绝，但贡献者应预期更长的审查时间和更高的理由说明标准。维护者的精力是有限的。我们会优先将其投入到这些优先级上。

如果您正在考虑提出 SEP，请检查它是否与以下某个领域一致，在相关的 [工作组或兴趣小组](/community/working-interest-groups) 中讨论，并获得该小组的支持。获得工作组支持且与路线图有明确联系的 SEP 进展最快。请参阅 [SEP 指南](/community/sep-guidelines) 了解完整流程。

## 优先领域

### 1. 传输演进与可扩展性

Streamable HTTP 为 MCP 提供了生产就绪的传输方式，但在大规模运行时揭示了围绕水平扩展、无状态操作和中间件模式方面的差距。

**我们想要实现的目标：**

* **下一代传输**：演进 Streamable HTTP 以在多个服务器实例上无状态运行，并在负载均衡器和代理后面正确行为。
* **可扩展会话处理**：定义会话如何创建、恢复和迁移，以便服务器重启和扩展事件对连接的客户端透明。
* **MCP 服务器卡片**：一种通过 `.well-known` URL 暴露结构化服务器元数据的标准，以便浏览器、爬虫和注册表无需连接服务器即可发现其能力。

**工作组所有权：**

* **传输工作组** 拥有传输和会话工作：一系列涵盖线路格式、会话模型和恢复协议的 SEP，以及针对 SDK 作者的一致性指南。
* **服务器卡片工作组** 拥有服务器卡片格式及其分发，并与更广泛的行业 AI 目录工作协调。

本周期我们**不会**引入额外的官方传输方式。保持集合较小可保护生态系统兼容性；社区应通过自定义传输进行实验。

### 2. 代理通信

Tasks 原语 ([SEP-1686](https://github.com/modelcontextprotocol/modelcontextprotocol/issues/1686)) 为代理提供了可靠的即时调用/稍后获取模式。在生产环境中运行它暴露了生命周期语义方面的差距，**代理工作组** 应弥补这些差距：

* **重试语义**：当任务暂时失败时会发生什么，以及谁决定是否重试。
* **过期策略**：完成后结果保留多长时间，以及客户端如何得知结果已过期。

这些是我们今天能指出的差距。代理工作组还应收集和分类生产部署中的操作问题——随着生态系统中更多部分大规模运行 Tasks，此列表将会增长。

### 3. 治理成熟度

MCP 已发展成为 Linux 基金会下的多公司开放标准。[SEP-1302](https://github.com/modelcontextprotocol/modelcontextprotocol/issues/1302) 正式化了工作组和兴趣小组，[SEP-2085](https://github.com/modelcontextprotocol/modelcontextprotocol/issues/2085) 建立了继任和修订程序。下一步是为社区提供一条清晰的领导路径，以便项目不依赖于少数个人。

**治理工作组** 应交付：

* **贡献者阶梯 SEP** 定义从社区参与者 → 工作组贡献者 → 工作组协调人 → 主要维护者 → 核心维护者的进展，每一步都有明确的提名和审查标准。
* **委托模型** 允许有良好记录的工作组在其领域内接受 SEP 并发布扩展更新，无需完整的核心维护者审查周期。
* **章程模板** 每个工作组和兴趣小组公开维护：范围、活跃交付物、成功标准和退休条件，每季度审查。

### 4. 企业就绪

企业正在大规模部署 MCP，并遇到了协议尚未解决的差距。

我们需要明确问题陈述和方向性提案的领域：

* **审计跟踪和可观察性**：端到端可见性，了解客户端请求了什么以及服务器做了什么，形式为企业可将其输入现有日志和合规管道。
* **企业管理的身份验证**：铺平从静态客户端密钥走向 SSO 集成流程 ([跨应用访问](https://xaa.dev)) 的道路，以便 IT 部门可以像管理其他内容一样管理 MCP 访问。
* **网关和代理模式**：当客户端不直接连接到服务器而是通过中介路由时的明确定义行为。这可能包括授权传播、会话语义以及网关允许看到的内容。
* **配置可移植性**：一种配置服务器一次并使该配置在不同 MCP 客户端上工作的方法。

我们期望成立一个 **企业工作组** 来负责此事。大部分输出可能会作为扩展而非核心规范变更落地。

## 未来展望

这些领域具有社区兴趣和核心维护者的兴趣，但不是最高优先级。我们将支持其中任何一个社区形成的工作组，并在时间允许的情况下审查关于这些主题的 SEP。

* **触发器和事件驱动更新** — 客户端目前通过轮询或保持 SSE 连接打开来了解服务器端状态变化。标准化的回调机制（webhooks 或类似机制）将使服务器在新数据可用时主动通知客户端，并在所有传输方式上定义排序保证。
* **结果类型改进** — 工具调用、资源读取和任务结果都是完整且内联到达的。流式结果将使客户端能够在交互场景（生成的文本、音频、视频帧）中增量接收输出；基于引用的结果将使客户端决定何时将大型负载拉入上下文，而不是默认污染它。这是跨领域的：流式传输涉及传输，引用涉及模式。
* **安全与授权** — 更细粒度的最小权限范围，关于避免 OAuth 混淆攻击的更清晰指南，客户端和服务器上的安全凭据管理，以及通过 Linux 基金会路由的社区驱动漏洞披露计划。赞助工作已经在进行中：[SEP-1932 (DPoP)](https://github.com/modelcontextprotocol/modelcontextprotocol/pull/1932) 和 [SEP-1933 (工作负载身份联合)](https://github.com/modelcontextprotocol/modelcontextprotocol/pull/1933)。
* **扩展生态系统** — `ext-auth` 和 `ext-apps` 轨道是扩展机制有效的早期证明。成熟化它们，调查用于组合能力的 Skills 原语，以及向注册表添加一流扩展支持，都将加强从实验到标准的路径。

## 验证

协议规范的好坏取决于遵循它的实现。除了上述领域外，我们继续投资于：

* **一致性测试套件**：自动验证客户端、服务器和 SDK 是否正确实现了规范，覆盖率随每个新功能领域扩展。
* **SDK 层级**：[SEP-1730](https://github.com/modelcontextprotocol/modelcontextprotocol/issues/1730) 中引入的层级系统为开发人员提供了清晰的信号，表明哪些 SDK 最紧密地跟踪规范。
* **参考实现**：新功能的规范实现，以锚定社区开发并为早期采用者扫清障碍。

## 参与其中

MCP 的路线图由其社区构建：

* **加入工作组或兴趣小组**：查看 [工作组和兴趣小组](/community/working-interest-groups) 页面和 [社区沟通渠道](/community/communication) 以联系上述每个领域活跃的小组。
* **提出或评论 SEP**：审查 [SEP 指南](/community/sep-guidelines) 并开启或权衡提案。
* **启动实验性扩展**：[SEP-2133](https://github.com/modelcontextprotocol/modelcontextprotocol/issues/2133) 允许任何工作组或兴趣小组在需要正式 SEP 之前在 `experimental-ext-` 仓库中进行实验。
* **为项目做贡献**：阅读 [贡献指南](/community/contributing) 了解如何参与规范、SDK 和工具的开发。