路线图

本页面描述了我们的战略优先级，以及我们期望工作组 (Working Groups) 和兴趣小组 (Interest Groups) 针对这些优先级交付的成果。

​

SEP 优先级排序

落入以下优先领域的 SEP 将获得快速审核，并有最高的机会被采纳。 处于这些领域之外的 SEP 不会被自动拒绝，但贡献者应预期更长的审核周期，并需要更高的论证标准。维护者的精力有限，我们将首先投入到这些优先级任务中。 如果您正在考虑提出一份 SEP，请检查它是否与以下领域之一相符，在相关工作组或兴趣小组中进行讨论，并获得该小组的支持。有工作组支持且与路线图有明确关联的 SEP 进展最快。请参阅 SEP 指南以了解完整流程。

​

优先领域

​

1. 传输机制演进与可扩展性

可流式传输的 HTTP (Streamable HTTP) 为 MCP 提供了生产就绪的传输层，但在大规模运行中，其在横向扩展、无状态操作和中间件模式方面显现出了不足。 我们希望实现的目标：

• 下一代传输协议：改进可流式传输的 HTTP，使其能够在多个服务器实例之间实现无状态运行，并在负载均衡器和代理服务器之后正常工作。
• 可扩展的会话处理：定义会话的创建、恢复和迁移方式，以便服务器重启和横向扩展事件对连接的客户端透明。
• MCP 服务器卡片 (Server Cards)：一种通过 .well-known URL 公开结构化服务器元数据的标准，以便浏览器、爬虫和注册表无需连接即可发现服务器的功能。

工作组所有权

• 传输工作组 (Transports WG) 负责传输和会话工作：包括涵盖线路格式、会话模型和恢复协议的一系列 SEP，以及为 SDK 作者提供的合规性指南。
• 服务器卡片工作组 (Server Card WG) 负责服务器卡片格式及其分发，并与更广泛的行业 AI 目录工作进行协调。

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

​

2. 智能体 (Agent) 通信

任务原语 (Tasks primitive, SEP-1686) 为智能体提供了可靠的“立即调用/稍后获取”模式。在生产环境中运行该模式后，暴露出了生命周期语义上的缺失，智能体工作组 (Agents WG) 应填补这些空白：

• 重试语义：当任务发生瞬时故障时会发生什么，以及由谁决定是否重试。
• 过期策略：结果完成后的保留时长，以及客户端如何得知结果已过期。

这是我们目前发现的不足之处。智能体工作组还应收集和分类来自生产部署的操作问题——随着生态系统中大规模运行任务的增加，此列表将会增长。

​

3. 治理成熟度

MCP 已发展成为 Linux 基金会旗下的多家公司参与的开放标准。SEP-1302 正式确立了工作组和兴趣小组，而 SEP-2085 建立了继任和修订程序。下一步是为社区提供明确的领导力路径，使项目不再依赖于少数个人。 治理工作组 (Governance WG) 应交付：

• 贡献者阶梯 SEP，定义从社区参与者 → 工作组成员 → 工作组协调员 → 首席维护者 → 核心维护者的晋升路径，并在每一步提供明确的提名和审核标准。
• 授权模型，允许有良好记录的工作组在无需完整核心维护者审核周期的情况下，在其领域内接受 SEP 并发布扩展更新。
• 章程模板，要求每个工作组和兴趣小组公开维护：范围、活跃交付物、成功标准和退出条件，并按季度进行审查。

​

4. 企业级就绪

企业正在大规模部署 MCP，并遇到了协议尚未解决的缺口。 我们需要明确问题陈述和方向性建议的领域：

• 审计追踪与可观测性：对客户端请求和服务器操作的端到端可见性，并以企业能够接入其现有日志和合规性管道的形式呈现。
• 企业托管认证：从静态客户端密钥转向 SSO 集成流（跨应用访问）的便捷路径，以便 IT 部门能够像管理其他系统一样管理 MCP 访问。
• 网关与代理模式：在客户端不直接连接服务器而是通过中介路由时的明确行为定义。这可能包括授权传播、会话语义以及网关被允许查看的内容。
• 配置可移植性：一种配置服务器一次即可在不同 MCP 客户端中通用的方法。

我们期望成立一个企业工作组 (Enterprise WG) 来负责此事。大部分产出可能会以扩展而非核心规范变更的形式落地。

​

未来展望

这些领域受到社区和核心维护者的关注，但并非首要任务。我们将支持在这些领域成立社区工作组，并在时间允许的情况下审查相关主题的 SEP。

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

​

验证

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

• 一致性测试套件：自动化验证客户端、服务器和 SDK 是否正确实现了规范，覆盖范围将随着每个新功能领域同步扩展。
• SDK 分级：SEP-1730 中引入的分级系统为开发者提供了明确信号，表明哪些 SDK 最紧密地追踪了规范。
• 参考实现：新功能的标准实现，旨在锚定社区开发并帮助早期采用者快速入门。

​

参与进来

MCP 的路线图由其社区构建

• 加入工作组或兴趣小组：参阅 工作组与兴趣小组 页面以及 社区交流渠道，与上述各领域的活跃小组取得联系。
• 提议或评论 SEP：查阅 SEP 指南，并针对提案发表意见或参与讨论。
• 启动实验性扩展：SEP-2133 允许任何工作组或兴趣小组在正式要求 SEP 之前在 experimental-ext- 仓库中进行实验。
• 为项目做出贡献：阅读 贡献指南，了解如何参与规范、SDK 和工具的开发。