8 月 22 日，Model Context Protocol（MCP）核心维护者 David Soria Parra 与 Den Delimarsky 在官方博客发布新版路线图，把协议未来 6 到 12 个月的工作归入五个优先领域：Agentic 消息原语、HTTP 原生传输统一与加固、代理身份与企业级安全、原语改进、SDK 开发体验。路线图页面同日更新，每个领域都指定了负责的核心维护者与工作组。这次调整距离上一个版本（3 月 5 日）不足半年，结构上完成了一次明显的重组。
从三月版到八月版：优先级如何重组
3 月的旧路线图列出四个优先领域：传输演进与可扩展性、代理通信、治理成熟化、企业就绪，另有一个"On the Horizon"观察清单，收录了服务端触发事件、结果类型改进、安全与授权等方向。八月版把观察清单里的多个条目转正：服务端事件、代理身份、结果类型改进各自升格为独立优先领域，治理成熟化则退出主列表。官方博文的解释是，这些方向「已经成熟到足以独立成为优先事项」。
路线图同时明确了 SEP（Specification Enhancement Proposal）的筛选机制：落在优先领域内的提案获得快速评审通道和最高的接受概率，领域外的提案不会自动拒绝，但评审周期更长、论证门槛更高。维护者的评审时间是稀缺资源，会优先投给路线图方向。对准备提交 SEP 的开发者，第一步是确认提案属于哪个领域，并在相关工作组内先行讨论、带上工作组背书。
领域一：Agentic 消息原语
请求-响应模式已经装不下现代 Agentic 工作负载：任务可能跑几分钟，服务器需要主动推送，中间还要能调整方向。MCP 为此长出了一组概念：Tasks 扩展、subscriptions/listen、进度通知，分散在多个工作组。
新路线图点出了风险所在：这三套机制等于对「服务器还没做完」给出了三个答案，而它们不共享生命周期、取消模型和错误面。维护者希望它们能够组合。本周期交付两件事：服务端发起事件（Triggers & Events 工作组负责，覆盖 channels、订阅和 webhook 推送，让客户端不用靠轮询拿结果），以及跨 Agents、Transports、Triggers & Events 三个工作组的组合评审。Tasks 扩展（SEP-2663）继续成熟，目标是进入核心协议。
Tasks 在 2026-07-28 版规范里刚完成一次搬家：从核心协议移入官方扩展 io.modelcontextprotocol/tasks，阻塞性的 tasks/result 方法被替换为 tasks/get 轮询，新增 tasks/update 承接客户端到服务器的输入，任务状态机覆盖 working、input_required、completed、failed、cancelled 五种状态，服务器返回的 CreateTaskResult 携带 taskId、ttlMs 与 pollIntervalMs。路线图要做的是把这套异步模式与订阅、进度通知统一到同一个生命周期之下。
领域二：HTTP 原生传输统一与加固
2026-07-28 版是这次工作的地基：协议层会话和 Mcp-Session-Id 头被移除，initialize 握手取消，每个请求通过 _meta 字段自报协议版本与客户端能力，新增 server/discover RPC 供客户端探测服务器支持的版本与能力。远程 MCP 服务器从此与普通 HTTP 工作负载无异，可以直接跑在任何现成的 API 基础设施上。
剩下的问题是双轨制：每个 HTTP 原生特性都要为 stdio 再设计一遍，SDK 维护两条传输管线，协议元数据在 HTTP 头和消息字段里重复出现，服务器还要交叉校验。本周期两项交付：其一，HTTP over stdio（Transports 工作组），以 Streamable HTTP 作为唯一绑定，本地服务器在 stdin/stdout 上跑 HTTP/2，在保留子进程安全与生命周期保证的同时获得多路复用传输；其二，缓存，上一版已通过 SEP-2549 给列表结果和资源读取加了 ttlMs 与 cacheScope，下一步扩展到 ETag，为工具调用等原语结果做版本化。此外还有标准化错误处理、SEP-2575 无状态化之后的工具列表能力作用域、服务器配置的安全下发。
官方同时明确：本周期不再引入新的官方传输。传输集合保持精简以保护生态兼容性，社区的定制传输实验不受限制。
领域三：代理身份与企业级安全
MCP 的授权模型目前假设 consenting 的是一个拿着浏览器的人。现实是越来越多的调用方是代理：以云工作负载身份运行、代表不在场的用户行事，或者派生出权限更窄的子代理。现有 MCP 服务器普遍依赖粘贴 API key 和长期刷新令牌。
本周期两项交付：DPoP（Demonstrating Proof of Possession，RFC 9449）完成定稿并推动广泛采用；代理身份与委托的成套方案，基于工作负载身份联邦（SEP-1933）、企业托管授权背后的 ID-JAG 授权许可、以及 RFC 8693 令牌交换，与 IETF OAuth 工作组和 WIMSE 工作组协同推进。讨论中的延伸题目包括人类在场证明，用于区分交互式客户端与无头代理。
领域四：原语改进
工具调用是开发者接触 MCP 的第一站，问题出在结果处理：tools/call 允许同时返回 content 与 structuredContent 两种形态，服务器开发者无从知道客户端会把哪种形态摆到模型面前，实现因此分化。本周期将重新设计 tools/call 接口（Core Primitives 工作组，组建中），统一结构化与非结构化输出的语义。
另一个被反复提出的痛点是规模：连接一个有一百个工具的服务器，模型在用户提问前就要为整个目录付出上下文成本，且工具列表越长选择越差。progressive discovery 计划让服务器先提供一个小入口，随对话收窄逐步展开目录，与领域二的缓存工作定义交互。原语注解（声明内容的受众与优先级）也进入审视范围：多数实现者没有采用，如果确认无用将考虑废弃（关联 SEP-2200 的可见性争议）。文件上传工作组继续推进作用域文件操作与类文件系统语义（范围读取、层级列表）。
领域五：SDK 开发体验
MCP 的 SDK、参考服务器和快速入门目前全部人工维护。维护者的判断是：规范加上人工审核的一致性测试套件可以作为唯一事实来源，SDK 与示例在每次发布时重新生成、重新验证，而非事后修补。两项交付：扩展契约（扩展绑定 host/client/server/agent 中的哪个角色、声明能力时各自做什么、SDK 必须原生支持什么、如何打包、能力变更如何版本化）；生成工件实验（从规范生成候选 Tier 1 SDK 及配套快速入门，对照一致性测试套件验证，发布结论并建议哪些层应该用确定性代码生成、哪些可以模型辅助）。这背后还有一个现实：大量开发者现在是让代理对着 MCP 库写代码，清晰的 API 和准确的文档直接决定代码能不能跑通。
社区反应
Hacker News 讨论串（77 分、53 条评论）集中在三处。progressive discovery 被认为来得偏晚，有开发者表示早就在客户端侧自行实现了 MCP 懒加载，正在转向 code mode 方案。代理身份部分有人质疑规范过度设计：把长期令牌放进配置、用秘密管理器托管，工程上已经够用；也有人认为浏览器人工授权是规模化瓶颈，方向没有问题。第三类讨论围绕 MCP 的存在价值：一部分开发者认为一个文档完善的 openapi.yaml 加 REST 端点对代理同样有效，另一部分指出 MCP 的价值在组织侧——指令集中更新分发、技能与 REST API 不会失步。无状态化改动获得普遍好评，初期 stdio 与 HTTP 传输、Bearer 与 OAuth 授权混杂造成的实现矩阵混乱被多次提及。
对不同的读者，这份路线图的用法也不同。SEP 作者按优先领域对齐提案并争取工作组背书；服务器与客户端实现者需要预留 tools/call 结果形态变更和大目录渐进发现的适配空间；企业平台团队可以按 DPoP 与工作负载身份联邦的时间线规划接入。路线图页面的免责声明值得留意：这些方向反映当前思路而非承诺，部分内容可能推迟或以不同方式交付。
来源：The New MCP Roadmap（MCP 官方博客，2026-08-22）；MCP Roadmap（2026-08-22 更新）；Specification 2026-07-28 Key Changes；Tasks 扩展文档；Hacker News 讨论串