最后更新：2026-08-22
此路线图反映的是当前思路，而不是坚定承诺。优先级可能会发生变化，某些项目的交付方式可能与描述不同或被推迟，未在此列出的工作也可能仍会被纳入发布版本。
SEP 优先级
**属于以下优先领域的规范增强提案（SEPs）将获得加速审核，并最有可能被接受。**不属于这些领域的 SEPs 不会被自动拒绝，但预计会面临更长的排队时间和更高的论证门槛。维护者的审核时间十分有限。我们会优先投入在这些领域。 如果你正在考虑编写 SEP，请先确定它属于哪个优先领域，并与相关工作组沟通，然后在提案中获得该工作组的支持。有工作组支持且与本路线图有明确联系的 SEPs 推进最快。完整流程请参阅SEP 指南。 每个优先领域都会列出负责该领域的核心维护者，任何有兴趣参与贡献的人都可以通过Discord联系他们。每个领域下列出的项目是本路线图周期内的优先交付成果。每个领域的其余部分属于开放范围，工作组应在其中进一步定义并贡献工作。优先领域
1. 智能体消息传递原语
核心维护者：Caitie McCaffrey、Clare Liguori、Peter Alexander 智能体工作负载需要超越请求和响应的消息传递模式：运行数分钟的工作、主动推送的服务器、流式传输的结果，以及在工作进行期间对其进行引导的方式。MCP 已经围绕这些需求形成了一组概念，包括Tasks、subscriptions/listen和进度通知，它们分散在多个工作组中。风险在于，当“服务器还没完成”时出现三种彼此不同的处理方式，而它们没有共享生命周期、取消模型或错误呈现方式。我们希望让它们能够组合使用。
本路线图周期内：
- 服务器发起的事件：Triggers & Events WG。用于推送交付的通道和订阅，包括 Webhook。随着我们通过 Tasks 和其他事件处理异步工作负载，我们需要一些扩展，让服务器能够在工作完成时通知客户端，而不是完全依赖成本高昂的客户端轮询。
- 组合审查：Agents、Transports 和 Triggers & Events 工作组。正在形成的原语（例如 Tasks 和 Triggers）需要彼此干净地组合，并适用于具体用例。
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）。作为这项工作的一部分，我们希望将缓存方案扩展为支持 ETag，从而可以对原语的结果进行版本控制，尤其是工具调用的结果。
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令牌交换，并与 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 原生传输统一与强化下缓存工作的交互方式。
- 原语注解：Core Primitives WG。规范中的内容注解声明了一段内容的目标受众和优先级。将其应用于工具结果和资源，可能有助于解决SEP-2200中描述的可见性混淆问题，但大多数实现者尚未采用这些注解，也可能不了解其用途。如果它们没有用处，我们应考虑弃用它们。
5. 改进 SDK 开发者体验
核心维护者：Den Delimarsky、David Soria Parra 我们的 SDK、参考服务器和快速入门内容都是手工维护的。虽然这种方式可行，但我们认为，规范和经过人工审查的一致性测试套件可以作为事实来源，并据此生成更多这些产物，从而让 SDK 和示例在每次发布时都能重新生成并重新验证，而不是在发布后修复。 本路线图周期内：- 扩展契约：SDK WG与核心维护者共同推进。扩展绑定的角色是什么（主机、客户端、服务器、智能体），以及在声明该能力时每个角色要做什么；SDK 必须原生支持哪些内容；扩展如何打包；以版本化变更的方式向扩展添加能力；将认证作为独立领域处理。
- 生成产物实验：SDK WG。根据规范生成一个候选的Tier 1 SDK及其配套快速入门示例，使用一致性测试套件对二者进行验证，并发布包含下一周期建议的研究结果，包括哪些层应采用确定性代码生成，哪些层应采用模型辅助。