MCP 新路线图：对正在基于它构建系统的人意味着什么

8 月 22 日，Model Context Protocol 维护者发布了更新后的路线图，覆盖未来六到十二个月的协议工作。它列出五个优先领域、每个领域对应的 Core Maintainer，以及一条安静但很重要的规则：哪些提案会被优先审查。上一版路线图在 3 月发布，当时承诺了四件事，其中大部分都已经在 7 月的规范版本里兑现，所以这次值得认真读。我的判断是：MCP 正在有意变成普通的 Web 基础设施。对开发者真正有用的问题，不是它有没有“变大”，而是你的技术栈里哪一层会先被它改变。

要点速览 - 路线图设定五项优先事项：智能体消息、统一的 HTTP 原生传输、智能体身份与企业安全、更干净的工具原语，以及直接从规范生成的 SDK。 - 落在这些领域内的规范增强提案（SEP）会得到加速审查。落在优先领域之外，就要预期更长的队列和更高门槛。 - 3 月路线图里的承诺大多已经进入 2026-07-28 规范：无状态核心、可缓存的列表结果，以及多轮往返请求。 - 最可能在一年内直接改到你代码的两项，是智能体身份（DPoP 和工作负载身份联合）以及面向大型工具目录的渐进式发现。 - 把路线图当方向，不要当承诺。维护者自己也这么说。别为了它暂停正在做的系统。

MCP 维护者到底宣布了什么？

先看事实。更新后的 MCP 路线图日期为 2026 年 8 月 22 日，它把下一轮规范工作组织成五个优先领域，每个领域都有具名 Core Maintainer，并由一个或多个 Working Group 支撑：

1. 智能体消息原语： 增加服务器主动事件，包括频道、订阅和 webhook，让客户端不必继续轮询；同时重新审视组合方式，让 Tasks、触发器和进度通知共享同一套生命周期。

2. HTTP 原生传输统一与加固： 让 Streamable HTTP 成为唯一绑定方式，未来本地服务器也通过 stdio 承载同一协议；缓存进一步扩展到 ETag。

3. 智能体身份与企业级安全： 完成 DPoP（Demonstrating Proof of Possession）的规范化，并基于现有 IETF 标准，为智能体身份与委托定义一条更明确、更有主见的实现路径。

4. 改进基础原语： 重新设计 tools/call 的结果结构，并推进新的渐进式发现机制，让客户端按需了解服务器工具目录，而不是一次性吞下全部内容。

5. 改进 SDK 开发体验： 定义扩展契约，并实验直接从规范生成一个一级 SDK 及其快速入门示例。

五个领域之外还有一条会影响其他一切的规则：属于优先领域的 SEP 会得到加速审查，有 Working Group 支持的提案推进最快。维护者自己说得很直接：“维护者的审查时间很稀缺，我们会先把时间花在这些地方。”路线图同时明确表示，这只是当前思路，不是不可更改的承诺，所以具体项目可能延期，也可能以不同形式出现。

2026 年 8 月 22 日发布的 MCP 路线图为未来六到十二个月设定五个优先领域：智能体消息、HTTP 原生传输、智能体身份、改进工具原语，以及由规范生成 SDK。落在这些领域的提案会获得加速审查，其他提案则要面对更长队列。

为什么这份路线图值得看？

因为上一份路线图真的交付了。年轻开源项目的路线图经常只是愿望清单，最后安静地过期。但 MCP 这份路线图现在有了履历。2026 年 3 月版本提出四项优先事项，其中大部分在五个月后进入了2026-07-28 规范版本：

采用规模让路线图更有分量。到 2026 年 7 月，协议的一级 SDK 已经达到每月接近 5 亿次下载，TypeScript 和 Python SDK 的累计下载量则各自超过 10 亿。当一个规模到这里的协议告诉你接下来准备往哪走，最好还是看看地图。

来源：MCP 2026 年 3 月与 8 月路线图，以及 2026-07-28 规范发布公告。

2026 年 3 月 MCP 路线图承诺推进传输演进、智能体通信、治理成熟化和企业就绪。五个月后，2026-07-28 规范交付了无状态协议核心、Tasks 扩展、多轮往返请求，以及最短过渡窗口为十二个月的正式弃用政策。

如果你正在基于 MCP 构建系统，这意味着什么？

对开发者而言，五个领域的直接影响并不均匀。其中两个很可能在一年内改到你的代码，另外三个更多会改变协议在你周围被治理和维护的方式。下面逐项翻成实践语言。

智能体消息：轮询开始退场

真实智能体工作从来不完全符合请求和响应模型。任务可能跑几分钟，服务器完成时客户端甚至没有在看，而今天客户端唯一能做的往往就是轮询，又贵又难看。路线图把服务器主动事件放进优先级：频道、订阅和 webhook，让服务器能在工作完成时主动告诉客户端。组合审查同样重要。Tasks、subscriptions/listen 和进度通知现在有可能变成三个不同版本的“服务器还没做完”，维护者希望它们最终共享生命周期、取消模型和错误界面。如果你在做长时间运行的工具，这是值得在 Discord 上持续盯的领域。

一套传输，到处都讲同一种语言

2026-07-28 版本已经把远程 MCP 服务器变成普通 HTTP 工作负载。新路线图现在想抹平远程和本地之间的分裂：让 Streamable HTTP 成为唯一传输绑定，本地服务器则通过 stdin 和 stdout 承载同一套协议。HTTP/2 提供多路复用，同时子进程继续保留原本的安全和生命周期保证。今天，每个 HTTP 原生功能要么还得再做一套 stdio 特殊设计，要么本地就不能用，SDK 也要维护两条传输管线。统一模型以后，这类重复会少很多。缓存也会继续扩展，在 7 月刚加入的 ttlMs 和 cacheScope 提示之上，再支持 ETag，让工具调用结果可以按版本判断，而不是每次重新获取。

智能体身份：最早会真正咬到你的那一项

MCP 的授权模型最初假设，授权时有一个真人坐在浏览器前面。现在调用方越来越可能是智能体：一个拥有自身身份的云端工作负载，代表并不在场的用户行动；或者它还会生成子智能体，而这些子智能体应该只拿到比父级更窄的权限。Honeycomb 在7 月版本公告中被引述称，它每月交互式查询里已经有接近 20% 来自智能体。与此同时，很多生产 MCP 服务器仍然依赖手工粘贴 API key 和长期刷新令牌，而这正是新工作要逐步淘汰的模式。计划包括最终完成并采用 DPoP，同时通过 Workload Identity Federation（SEP-1933）、Enterprise-Managed Authorization 背后的 ID-JAG 授权方式，以及 RFC 8693 token exchange 建立标准委托路径，并与 IETF OAuth 和 WIMSE Working Group 协调。

MCP 的授权模型最初面向“真人在浏览器里批准访问”，但调用方正在变成智能体。路线图把 DPoP 和基于工作负载身份联合、RFC 8693 token exchange 的标准委托路径列为优先事项，让服务器能够识别智能体身份，而不是继续依赖手工粘贴 API key 或长期 token。

工具结果和渐进式发现

这里要修两个长期让人困惑的问题。第一，tools/call 现在会同时返回 content 和 structuredContent，结果不同实现逐渐分叉，因为服务器作者根本无法知道客户端最终会把哪一种交给模型。这个契约会被重新设计。第二是规模：连上一台有一百个工具的服务器，模型在用户问第一个问题之前，就已经要为整个工具表面支付上下文成本，而且工具越多，选择质量越差。这不是理论上的 token 账单。Cloudflare 在 2026 年 2 月的测试里发现，把一个拥有 2,500 个端点的 API 暴露成 MCP 工具定义，大约消耗 117 万 token，而通过代码调用方式只需要约 1,000。渐进式发现就是拟议中的回答：先暴露一个很小的入口，随着对话范围收窄，再逐步揭示更多目录内容，并与前面提到的缓存工作结合。我以前写过什么时候这种额外开销会让普通 API 反而更合适。渐进式发现就是 MCP 试图缩小这个差距的办法。

从规范直接生成 SDK

最安静的一项，可能反而最能说明协议成熟方向。今天 SDK、参考服务器和快速入门示例都是人工维护的。路线图要做一个实验：直接从规范生成一个候选一级 SDK 和配套快速入门，再用一致性测试套件验证二者，最后公开结论，包括哪些层适合确定性代码生成，哪些层适合模型辅助。如果这条路跑通，规范里说不清楚的地方会直接以“生成失败”的形式暴露，而 SDK 也不容易再慢慢偏离它本来应该实现的文档。

现在应该做什么？

按紧迫程度，我会先做四件事：

1. 本周：停止在已弃用界面上开发新东西。 Roots、Sampling、Logging 和旧版 HTTP+SSE 传输已经在 2026-07-28 规范中被标记弃用，最短过渡窗口十二个月。它们现在还能工作，但新实现不该继续采用。

2. 本月：让服务器更适合缓存。 列表结果现在已经可以带 ttlMs 和 cacheScope，ETag 也在路上。今天就能输出合理缓存提示的服务器，等于提前完成一次迁移。

3. 本季度：审查你的智能体如何认证。 如果任何 MCP 服务器仍然让无人值守调用方依赖手工粘贴 API key 或长期刷新令牌，那正是 Agent Identity Working Group 存在的原因。与其自己发明一套委托方案，不如跟踪这个工作组。治理层面的关系，我在治理 AI 智能体里写得更详细。

4. 如果你想影响协议：把 SEP 写进优先领域。 先和对应 Working Group 沟通，再带着该组的支持提交。与路线图一致的提案会加速审查，优先领域之外的提案要排队。

还有两件事别做。不要为了下一版规范暂停正在建设的系统。当前规范就是稳定底座，而且新的弃用政策已经保证，任何破坏性变化都会至少提前十二个月警告。也不要把路线图当成承诺。它在开头就明确说了，优先级可能变化，没写在路线图上的工作也可能照样交付。如果你还处在更早阶段，我写的第一个 MCP 服务器动手指南，以及值得接入的服务器清单，会是更实际的起点。

2026-07-28 MCP 规范已经弃用 Roots、Sampling、Logging 和旧版 HTTP+SSE 传输，最短过渡窗口十二个月。发布公告确认这些能力在窗口期内仍会继续工作，但新实现不应该再采用它们。

更大的图景

退一步看，这是一套协议在公开环境里长大的过程。MCP 于 2025 年 12 月捐赠给 Linux Foundation 旗下、厂商中立的 Agentic AI Foundation，OpenAI 和 Block 是共同创始成员。此后，它陆续建立 Contributor Ladder、功能生命周期、弃用政策，现在又公开说明维护者会把注意力优先投向哪里。扩展框架也在安静地做一件很实在的事：SEP-2133 允许任何 Working Group 先在 experimental-ext- 仓库里做实验，不必一开始就提交正式提案，因此新想法可以被真正测试，而不会先把核心协议搞不稳定。

接下来两个季度，我最想看的是“基于 stdio 的 HTTP”能不能落地。如果本地和远程服务器真的收敛到同一种传输，“MCP 服务器”就不再是一类很特殊的软件，而会变成拥有标准接口的普通 Web 服务。到了那一步，协议本身会逐渐消失进基础设施管道里，而这本来就是好基础设施应该做到的事。

常见问题

MCP 现在够稳定，可以开始基于它构建了吗？

可以，前提是有迁移纪律。2026-07-28 规范引入正式弃用政策，最短窗口十二个月，SDK 也会为破坏性变化提供迁移说明。协议还会继续演进，但现在至少会提前一年告诉你，某个你依赖的东西什么时候要退出。

MCP 会话发生了什么？

它们在 2026-07-28 规范里退役了。initialize 握手和 Mcp-Session-Id 头都已经移除（SEP-2575、SEP-2567）。现在每个请求都自描述，通过 _meta 携带协议版本和客户端能力；如果客户端希望提前获取能力信息，可以选择调用 server/discover 来取代握手。任何请求都可以落到轮询负载均衡器后面的任意实例上。

我应该等下一版规范再开始构建吗？

不应该。路线图描述的是未来六到十二个月的方向，不是已经承诺的功能，维护者也明确这么说。当前规范已经稳定、可缓存且无状态。基于它继续构建，避开已弃用界面，并持续跟踪最可能直接影响你的两个 Working Group 就够了。