主题
路线图
Model Context Protocol 路线图，涵盖核心维护者与工作组为下一个规范修订版所推进的优先领域，以及这些领域如何影响 SEP 评审。
INFO
最后更新：2026-08-22
本页概述了核心维护者对协议在未来六到十二个月的愿景，重点介绍面向下一次规范更新及更长远的目标。它描述了我们的主要战略目标，以及工作组与兴趣小组的预期交付成果。
NOTE
本路线图反映的是当前思路，而非坚定承诺。优先级可能发生变化，部分事项的交付方式可能与描述不同或被推迟，未在此列出的事项仍可能纳入本次发布。
SEP 优先级排序
规范增强提案（SEP）若属于以下优先领域，将获得加急评审，且最有可能被接受。 不属于这些领域的 SEP 不会被自动拒绝，但预计排队时间更长，且论证门槛更高。维护者的评审时间十分有限，我们会优先投入到这些领域。
如果你正在考虑撰写 SEP，请先确定它属于哪个优先领域，并与相关工作组沟通，然后带着该工作组的支持来提交提案。有工作组背书、且与本路线图有清晰关联的 SEP 推进最快。完整流程见 SEP 指南。
每个优先领域都列出了负责该领域的核心维护者，任何有兴趣贡献的人都可以通过 Discord 联系他们。每个领域下列出的事项是本路线图周期内优先交付的成果。每个领域的其余部分属于开放范围，工作组应在其内定义并贡献更多工作。
优先领域
1. 智能体消息原语
核心维护者：Caitie McCaffrey、Clare Liguori、Peter Alexander
智能体工作负载需要超越请求与响应的消息模式：运行数分钟的工作、服务端主动推送、结果流式传输，以及在工作进行中对其进行引导的方式。MCP 为此发展出一系列概念，包括 Tasks、subscriptions/listen 和进度通知，它们分散在多个工作组中。风险在于，对“服务端尚未完成”这一问题存在三种答案，而它们并不共享同一生命周期、取消模型或错误面。我们希望它们能够组合使用。
本路线图周期：
- 服务端发起的事件：Triggers & Events WG。用于推送投递的通道与订阅，包括 webhooks。随着我们通过 Tasks 和其他事件承接异步工作负载，我们需要扩展，让服务端能够在工作完成时告知客户端，而不必完全依赖代价高昂的客户端轮询。
- 组合性评审：Agents、Transports 和 Triggers & Events 工作组。正在形成中的原语，例如 Tasks 和 Triggers，需要彼此干净地组合，并契合具体用例。
除此之外，我们预计 Tasks（SEP-2663）将继续推进，最终将该扩展纳入核心协议。
2. HTTP 原生传输的统一与加固
核心维护者：Kurtis Van Gent、Nick Cooper
2026-07-28 发布版使远程 MCP 服务端成为一种普通的 HTTP 工作负载，我们也越来越依赖 HTTP 的具体特性（如头和状态码）来承载传输层信息。每个 HTTP 原生特性都需要另一套 stdio 专用设计，否则就无法在本地工作。SDK 维护着两条传输管线，协议元数据如今重复存在于 HTTP 头和消息字段中，服务端必须对二者交叉校验。我们希望只有一种传输模型，并在其上叠加标准 HTTP 实践。
本路线图周期：
- 基于 stdio 的 HTTP：Transports WG。以 Streamable HTTP 作为唯一绑定，通过 stdin/stdout 为本地服务端承载。我们相信可以使用基于 stdio 的 HTTP/2，在保留子进程安全与生命周期保证的同时，获得多路复用的 HTTP 传输。
- 缓存：Transports WG。最近的协议修订版在缓存方面取得了进展，为列表结果和资源读取添加了
ttlMs和cacheScope（SEP-2549）。作为这项工作的一部分，我们希望扩展缓存方案以支持 ETags，从而为原语的结果（尤其是工具调用）提供版本化能力。
除此之外，我们还想研究所有界面上的标准化错误处理、SEP-2575 之后工具列表的能力范围界定，以及以安全方式为服务端提供配置选项。
3. 智能体身份与企业级安全
核心维护者：Paul Carleton、Den Delimarsky
MCP 授权假设在同意时刻有一个带浏览器的人在场。但越来越多的调用方是智能体：一种拥有自身身份的云工作负载，代表不在场的用户行事，或派生出权限应比其父级更窄的子智能体。现有的 MCP 服务端依赖粘贴的 API 密钥和长期有效的刷新令牌。我们需要一种标准化方式，让 MCP 服务端处理智能体身份，并将继续通过采纳现有标准来改进安全性。
本路线图周期：
- DPoP：Agent Identity WG（在本路线图周期内组建）。敲定 Demonstrating Proof of Possession (DPoP) 规范，并重点推动其广泛采用。
- 代理身份与委托：Agent Identity WG。我们希望为 MCP 服务端提供一种明确的途径，使代理能够通过自身身份或用户委托的身份访问服务端。相关工作将聚焦于 Workload Identity Federation（SEP-1933）、Enterprise-Managed Authorization 所使用的 Identity Assertion JWT Authorization Grant (ID-JAG)，以及 RFC 8693 token exchange，并与 IETF OAuth 和 WIMSE 工作组协同推进。
除上述内容外，还有若干其他议题正在讨论中，并可能随着工作组的组建而纳入范围，包括用于区分交互式客户端与无头代理的人类在场证明，以及其他代理身份相关议题。
4. 改进原语
核心维护者：Kurtis Van Gent、Peter Alexander、Den Delimarsky
MCP 的工具调用接口一直表现良好。然而，tools/call 允许同时返回 content 和 structuredContent，这让服务端和客户端作者都感到困惑，并产生了各不相同的实现。我们希望在本路线图周期内改进 tools/call 接口的形态，以实现更一致的语义。我们还反复听到社区反馈，服务端需要更多选项来引导客户端浏览大量工具、资源和其他原语，因此我们启动了一项专门围绕渐进式发现的工作，以定义实验性的服务端发现机制应当是什么样子。
本路线图周期：
- 工具结果形态：Core Primitives WG（在本路线图周期内组建）。重新设计
tools/call接口，以解决各返回类型之间的保真度差异，并简化结构化与非结构化输出的处理。 - 渐进式发现：Core Primitives WG。客户端按需了解服务端的工具和资源，而不是预先摄取完整目录，并与 HTTP-Native Transport Unification and Hardening 下的缓存工作定义明确的交互方式。
- 原语注解：Core Primitives WG。规范中的内容注解声明了一段内容的预期受众和优先级。将其应用于工具结果和资源，可能解决 SEP-2200 中描述的可见性困惑，但大多数实现者尚未采用这些注解，也可能不了解其用途。如果它们没有用处，我们应考虑将其弃用。
此外，File Uploads WG 将继续推进限定范围的文件操作和类文件系统资源语义（范围读取、分层列表）。
5. 改进 SDK 开发者体验
核心维护者：Den Delimarsky、David Soria Parra
我们的 SDK、参考服务端和快速入门都是手工维护的。虽然这样可行，但我们相信规范以及经过人工审查的一致性测试套件可以作为事实来源，从中派生更多此类产物，从而使 SDK 和示例在每次发布时都重新生成并重新验证，而不是在发布之后再修补。
本路线图周期：
- 扩展契约：SDK WG 与核心维护者。扩展绑定哪个角色（宿主、客户端、服务端、代理），以及当声明该能力时各方做什么；SDK 必须原生支持什么；扩展如何打包；能力新增作为扩展的版本化变更；认证作为独立领域处理。
- 生成产物实验：SDK WG。从规范生成候选的 Tier 1 SDK 及其配套快速入门示例，对照一致性测试套件验证两者，并发布发现结果以及对下一周期的建议，包括哪些层应采用确定性代码生成，哪些应采用模型辅助。
除上述内容外，我们希望重新审视参考服务端和快速入门仓库的归属与新鲜度预期，并将生成失败所暴露的规范清晰度问题视为文档缺陷。
参与其中
上述每个优先领域背后都有一个工作组，或正在围绕其组建工作组，且它们都有容纳更多贡献者的空间。有几种参与方式：