今天，我们很高兴发布一个更新的模型上下文协议（MCP）路线图，涵盖下一个规范版本及其后续内容。该路线图为未来几个月的协议工作设定了方向。它是由核心维护者与我们的维护者社区和工作组共同开发的。探索路线图 → 优先领域 该路线图分为五个优先领域。其中几个领域是之前路线图所列出即将到来的工作，包括服务器发起的事件、结果类型改进和代理身份，这些领域现在已经成熟到足以成为独立的优先事项。每个领域由一组核心维护者和一个或多个工作组负责。 代理消息原语 现代代理工作负载不再符合标准的请求与响应模式。循环可以运行更长时间，服务器可以推送流式结果，并且在处理中明确需要引导工作。MCP正在不断发展以满足这些需求，引入了任务、订阅/监听和进度通知。我们希望确保不仅提供适合工作的正确原语，而且它们能够很好地协同工作。这里的工作涉及服务器发起的事件（webhook 和通道，以便客户不必一直轮询结果）、跨代理、传输和触发器与事件工作组的组合审查，以及使任务扩展（SEP-2663）成熟，以便它可以进入规范。 HTTP原生传输统一与加固 随着2026年7月28日的发布，远程MCP服务器与任何其他HTTP工作负载没有区别，因此在开发人员和组织已经用于其API和服务的任何基础设施上，托管和操作变得容易。该模型已经证明可以扩展，并且我们希望扩大它以涵盖其他部署模式，包括通过标准输入输出的本地服务器与可流式HTTP进行通信。统一一种传输方式使我们能够进一步简化MCP服务器和客户端的开发。 代理身份和企业级安全性 目前，MCP授权是在浏览器中由个人批准访问。这适用于交互式客户端，但越来越多的调用者是以自己的身份作为云工作负载运行的代理，在代表不在场的用户行动，或向子代理授权更窄的权限。我们希望MCP服务器有一种标准化的方法来识别和信任这些代理身份，基于现有标准，而不是复制的API密钥和长期有效的令牌。这里的工作包括最终确定拥有权证明（DPoP）并推动其采用，以及通过工作负载身份联合定义代理身份和委托的明确路径，这是企业管理授权背后的ID-JAG补助和标准令牌交换。我们还将继续加强与OAuth标准机构的合作，包括IETF OAuth和WIMSE工作组，以帮助基础标准与代理身份所需的构建模块共同演变。 改进的原语 工具调用是大多数开发人员首次接触的MCP部分，并且在协议的整个生命周期中表现良好。然而，它在结果处理上稍显不足。工具/调用响应可以以多种形式携带相同的输出，而今天的服务器开发人员无法知道给定客户端将以哪种形式展示模型。我们的目标是通过标准化一个明确的合同来简化这一点。我们需要解决的另一个用于原语使用的挑战是其不断增长的规模。连接到有一百个工具的服务器意味着在用户提出第一个问题之前，模型已为整个表面付费，并且随着列表的增长，工具选择的情况往往会变得更糟。我们开始了一个渐进式发现项目，以便服务器可以提供一个小的切入点，并在对话逐渐缩小时逐步显示其更多目录。 改进SDK开发者体验 我们的SDK是开发人员体验MCP的方式。我们正在投资于其人机工程学和与规范的一致性，致力于使其在我们支持的每个平台和语言上直观且文档详尽。现在，这一点尤为重要，因为许多开发人员通过将代理指向我们的库来构建MCP客户端和服务器，清晰的API和准确的文档决定了代码是否能够以最小的摩擦正常工作。 提案优先级 在这些优先领域内的规范增强提案（SEPs）将得到快速审查，并有最好的被接受的机会。外部提案不会被自动拒绝，但维护者的审查时间稀缺并优先用于路线图。如果您正在考虑一个SEP，请确定它所属的优先领域，并与相关工作组进行沟通，并与其成员合作来完善您的提案。路线图上每个领域都注明了负责的核心维护者，任何有兴趣做出贡献的人都可以通过Discord联系他们。我们对此感到兴奋。