MCP 路线图

社区译文；来源： MCP dae694f6

本页概述核心维护者对未来六到十二个月协议发展的判断，重点说明下一次规范更新及后续阶段的目标、主要战略方向，以及工作组和兴趣组的预期交付物。

SEP 优先级

属于下列优先领域的规范增强提案（SEP）会获得更快评审，也最有可能被接受。 不属于这些领域的 SEP 不会被自动拒绝，但通常需要等待更久，并提供更充分的理由。维护者的评审时间有限，会优先投入这些方向。

如果准备编写 SEP，应先确定它属于哪个优先领域，与相关工作组讨论，并在提交提案时说明工作组的支持。获得工作组支持且与本路线图关系明确的 SEP 推进最快。完整流程参见 SEP 指南。

每个优先领域都列出负责的核心维护者。任何有意参与的人都可以通过 Discord联系他们。各领域列出的事项是本路线图周期内的优先交付物；其余范围保持开放，由工作组继续定义和推进。

优先领域

1. 智能体消息原语

核心维护者：Caitie McCaffrey、Clare Liguori、Peter Alexander

智能体工作负载需要超出请求与响应的消息模式：任务可能持续数分钟，服务器需要主动推送，结果需要流式返回，运行中的工作还需要被引导。MCP 已形成一组相关概念，包括 Tasks、subscriptions/listen 和进度通知，但这些工作分散在多个工作组。如果三套机制都在回答“服务器尚未完成”，却没有共享生命周期、取消模型和错误表面，就会形成割裂。目标是让它们可以组合。

本路线图周期：

• 服务器发起的事件：Tasks & Events 工作组（英文）。为推送交付定义通道和订阅，包括 webhook。随着 Tasks 和其他事件承载异步工作负载，需要让服务器在工作完成时通知客户端，而不是完全依赖成本较高的客户端轮询。
• 组合性评审：Tasks & Events 工作组（英文）、Transports 工作组和 Agents 兴趣组（英文）共同评审。Tasks、Triggers 等正在形成的原语需要彼此正确组合，并适配具体用例。

此外，Tasks（SEP-2663（英文））将继续推进，目标是最终纳入核心协议。

2. HTTP 原生传输统一与加固

核心维护者：Kurtis Van Gent、Nick Cooper

2026-07-28 版本让远程 MCP 服务器成为常规 HTTP 工作负载，也越来越依赖 header 和状态码承载传输层信息。每项 HTTP 原生功能都需要第二套 stdio 专用设计，否则本地环境无法使用；SDK 维护两套传输管线，协议元数据又同时存在于 HTTP header 和消息字段中，服务器必须交叉校验。目标是形成一个统一传输模型，并在其上采用标准 HTTP 实践。

本路线图周期：

• HTTP over stdio：Transports 工作组。以 Streamable HTTP 作为统一绑定，通过 stdin/stdout 通信。HTTP/2 over stdio 有望在保留子进程安全和生命周期保证的同时提供多路复用的 HTTP 传输。
• 缓存：Transports 工作组。最新协议版本通过为列表结果和资源读取增加 ttlMs 与 cacheScope，推进了缓存能力（SEP-2549（英文））。下一步计划支持 ETag，从而为原语结果建立版本标识，尤其是工具调用结果。

此外，还将研究所有表面的标准化错误处理、SEP-2575（英文）之后工具列表的能力范围，以及如何安全地向服务器提供配置选项。

3. 智能体身份与企业级安全

核心维护者：Paul Carleton、Den Delimarsky

MCP 授权当前假设同意授权时有人使用浏览器，但调用方越来越多地变为智能体：它可能是具有自身身份的云工作负载，可能代表不在场的用户执行操作，也可能派生权限应更窄的子智能体。现有 MCP 服务器往往依赖粘贴的 API key 和长期 refresh token。协议需要标准方式处理智能体身份，并继续采用既有标准提升安全性。

本路线图周期：

• DPoP：本周期内组建 Agent Identity 工作组。完成 Demonstrating Proof of Possession（DPoP）规范并推动广泛采用。
• 智能体身份与委派：Agent Identity 工作组。为服务器通过智能体自身身份或用户委派身份接受访问提供明确方案。工作重点包括 Workload Identity Federation（SEP-1933）、企业托管授权使用的 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 工作组。重新设计 tools/call 接口，解决不同返回类型的保真度差异，简化结构化和非结构化输出的处理。
• 渐进式发现：Core Primitives 工作组。客户端按需了解服务器的工具和资源，而不是一次性加载完整目录；同时明确它与 HTTP 原生传输统一与加固中缓存工作的关系。
• 原语注解：Core Primitives 工作组。规范中的内容注解声明内容的目标受众和优先级。把它应用到工具结果和资源，可能解决 SEP-2200所描述的可见性混乱；但多数实现者尚未采用这些注解，也可能不了解其目的。如果它们没有实际价值，应考虑弃用。

此外，File Uploads 工作组（英文）将继续推进限定范围的文件操作和类文件系统资源语义，包括范围读取和分层列表。

5. 改进 SDK 开发体验

核心维护者：Den Delimarsky、David Soria Parra

SDK、参考服务器和快速入门目前由人工维护。虽然这种方式可行，但规范和经过人工评审的一致性测试套件可以成为更强的真相源，使更多产物在每次发布时重新生成并验证，而不是在发布后修补。

本路线图周期：

• 扩展合同：SDK 工作组（英文）与核心维护者共同明确扩展绑定的角色（host、client、server、agent）、声明能力后各角色的行为、SDK 必须原生支持的内容、扩展的打包方式、扩展能力如何进行版本化变更，以及授权为何需要作为独立领域处理。
• 生成产物实验：SDK 工作组。根据规范生成候选 Tier 1 SDK及配套快速入门示例，使用一致性测试套件验证二者，并发布结论与下一周期建议，包括哪些层适合确定性代码生成，哪些层适合模型辅助。

此外，还将重新审视参考服务器和快速入门仓库的所有权与新鲜度要求，并把生成失败暴露出的规范清晰度问题作为文档缺陷处理。

参与方式

以上每个优先领域都有对应工作组，或正在组建工作组，并且都欢迎更多贡献者参与：

• 加入工作组或兴趣组：参见工作组与兴趣组以及社区渠道。
• 提出或评论 SEP：先阅读 SEP 指南，再发起提案或参与讨论。
• 创建实验性扩展：SEP-2133（英文）允许任何工作组或兴趣组在 experimental-ext- 仓库中实验，然后再进入正式 SEP。
• 直接贡献：贡献指南介绍如何参与规范、SDK 和工具开发。