连接 AI 应用与外部工具的开放标准 Model Context Protocol（MCP），其核心维护者于 2026 年 8 月 22 日公布了新版路线图。这份路线图把下一个规范版本及之后要做的事情归纳为 5 个重点方向，其中超出单次工具调用的长时间处理，以及智能体如何证明自己的身份，位居前列。
起点是 7 月那次废弃会话的大改造
新路线图的前提，是上一轮工作刚刚告一段落。上一版发布于 2026 年 3 月，提出了传输层演进与可扩展性、智能体通信、治理成熟化、企业级就绪 4 个重点方向，其中大部分已经落在 2026 年 7 月 28 日的规范版本中。
影响最大的改动，是取消了协议层面的会话和初始化握手。服务器不再需要保存状态，因此可以直接横向扩展。客户端连接后不必立刻进入正题，而是可以调用 server/discover，先确认服务器支持哪些版本和能力。列表类请求的结果也变得可以缓存。
在智能体通信方面，Tasks 根据早期使用者的反馈重新设计，被移入官方扩展。原先由服务器主动发起请求的机制，则被全新的 Multi Round-Trip Requests 模式取代。这项改动的目的，是让需要多次往返的流程在无状态服务器上也能成立。
治理结构同样定型。用阶梯方式界定贡献者角色的 Contributor Ladder 被正式采用，各工作组开始分拣本领域的规范改进提案，功能的生命周期与废弃流程也有了明确政策。7 月版本中的废弃项目，正是首批按该政策执行的案例。
会让人等待的智能体，需要为等待而设计的零件
新路线图的第一个重点方向，是面向智能体的消息传递基础。如今智能体的工作方式，已经装不进"发出请求、收到答复"这种简单形态。循环会跑得更久，服务器会推送中间结果，有时还需要对正在运行的处理临时调整方向。
MCP 为此陆续补上了 Tasks、subscriptions/listen、进度通知等零件。路线图追问的不是零件是否齐全，而是它们彼此能否咬合。列出的工作包括由服务器侧触发的事件，也就是引入 Webhook 和通道，让客户端不必反复轮询结果。与此同时，Agents、Transports、Triggers & Events 各工作组将跨组检查这些零件的组合方式。把仍停留在扩展阶段的 Tasks 提升进规范本体，也写入了目标。
也想让本地服务器用 HTTP 说话
第二个方向是传输方式的统一。经过 7 月的改动，远程 MCP 服务器已经与普通的 HTTP 工作负载没有区别，可以直接跑在开发者和企业本来就用于 API 和服务的基础设施上。这套做法在规模层面已被验证可行，因此维护者希望把它推广到其他运行形态。
被点名的是在本地运行的服务器，方向是让它们在标准输入输出之上使用 Streamable HTTP。如果本地与远程不再需要各自维护一套传输方式，服务器和客户端的实现会进一步简化。
已经没人守在旁边点"同意"了
第三个方向是智能体身份与企业级安全，出发点是现行授权模型的前提正在瓦解。今天 MCP 的授权，围绕"人在浏览器里批准访问"设计。这对交互式客户端很合适，但越来越多的调用方是云上工作负载，拥有自己的身份，代替不在场的用户行动，还要向下级智能体移交范围更窄的权限。
维护者的目标，是让服务器基于既有标准识别并信任这些智能体身份，而不是依赖粘贴的 API 密钥和长期有效的令牌。具体工作包括：完成把访问令牌与密钥绑定的 Demonstrating Proof of Possession（DPoP）并推动其普及；结合 Workload Identity Federation、企业级授权背后使用的 ID-JAG 授权方式，以及标准的令牌交换，明确身份与委托的推荐路径。与 IETF 的 OAuth 工作组和 WIMSE 的协作也会继续。
不在用户提问前就把 100 个工具全摊开
第四个方向是基础能力本身的改进。工具调用是开发者接触 MCP 时最先用到的部分，一直没出大问题，薄弱环节在结果的处理上。tools/call 的响应可以用多种形式承载同一份内容，而服务器开发者无从得知面前的客户端会把哪一种形式呈给模型。这里的方针是收敛到一份明确的约定。
另一个问题是规模。连上一台公开了 100 个工具的服务器，意味着用户还没提问，模型就要先吃下全部信息；而且列表越长，选择工具的判断越容易失准。为此将启动渐进式披露的工作：先只给出一个小入口，随着对话聚焦再逐步展开剩余的目录。
SDK 要按"智能体会来读"的前提来打磨
第五个方向是 SDK 的开发者体验。对许多开发者来说，SDK 就等同于 MCP 本身。维护者表示会在易用性、与规范的一致性，以及各语言、各平台文档的准确度上持续投入。
理由很有当下的味道：越来越多的开发者是把库交给智能体去读、由它来写 MCP 客户端和服务器，于是 API 是否清晰、文档是否准确，直接决定生成出来的代码能不能跑。
提案能否通过的门槛变了
路线图也直接影响哪些提案会被优先审阅。落在这 5 个重点方向内的规范改进提案（SEP），审阅会走快速通道，被采纳的可能性也更高。方向之外的提案不会被自动否决，但路线图明确写道，维护者的时间有限，会优先分配给这些重点方向。
对于打算提案的人，建议先判断自己的想法属于哪个重点方向，带到对应的工作组，与组内成员一起打磨成形。每个方向都写明了负责的核心维护者。
总结
7 月的规范修订让 MCP 接近一个不保存状态的普通 HTTP 服务，而这份路线图给出了在此基础上的下一步：整理长时间处理所需的零件、把传输方式统一到包含本地在内、以无人可批准为前提验证智能体身份、用渐进式披露让工具增多后依然选得准，以及 SDK 的质量，共 5 条。它们的共同点，是一点点拆掉"有人在旁边看着"这个前提，这与把智能体放进生产环境的团队真正关心的问题高度重合。
来源: https://blog.modelcontextprotocol.io/posts/mcp-roadmap/
