8 月 22 日，MCP 核心维护者发布了 2026 年路线图。这不是一个新版本——7 月 28 日的无状态化规范已经落地——而是告诉你接下来几个月，协议往哪走、谁在推、你该关注什么。

五个优先方向，没有固定发布日期，治理模式从「Anthropic 内部项目」正式转向「Linux Foundation 下的行业基础设施」。

一、Agent 身份：MCP 最大的缺口

MCP 现在的授权模型依赖浏览器 OAuth 流——人类在浏览器里点「允许」，连接就建立了。这对桌面客户端没问题，但你的 Agent 跑在 Kubernetes Pod、Lambda 函数、Cloud Run 服务里的时候，没有浏览器，没有人在旁边点确认。

今天的 workaround 是静态凭据。安全团队听了想辞职。

路线图瞄准了这个问题，两个活跃提案：

• SEP-1932（DPoP）：把 token 密码学绑定到请求它的客户端上。拦截了 token 也没用——攻击者没有匹配的私钥。
• SEP-1933（Workload Identity Federation）：Agent 直接用云平台已有的身份（AWS IAM、GCP Workload Identity、Azure Managed Identity）认证，不需要新建凭据，不需要轮换计划。

两个提案都标注为「on the horizon」——活跃 SEP，但不保证本周期落地。考虑到 78% 的企业 AI 团队已经在生产环境跑 MCP，大多数在用 workaround 硬扛这个身份缺口。这些提案一旦落地，那些 workaround 就可以扔了。

二、渐进式发现：治工具列表撑爆上下文窗口的病

一组生产数据说明了问题的严重性：

一个 Agent 连 10 个 MCP server，每个 server 暴露 20 个工具，平均 JSON schema 500 token——还没等用户打第一个字，10 万 token 就烧掉了。更扎心的是，工具选择准确率从 5-7 个工具时的 90%+ 暴跌到 100+ 工具时的 13%。

这不是假设。这是大规模生产部署的真实数字。

渐进式发现（Progressive Discovery）在协议层解决这个问题。不再在会话开始时把完整工具目录一股脑塞给模型，而是让 server 暴露一个小的入口点，随着对话收窄再展开完整 schema。

之前每个团队都在自己 hack 上下文饱和的问题，渐进式发现把解决方案标准化了。对于跑大型企业 MCP 部署的团队，这是路线图上最立竿见影的改动。

三、Agent 消息原语：从「一问一答」到「长跑循环」

现代 Agent 工作负载早就不是标准请求-响应模式了。循环跑得更久，server 可以推送流式结果，还需要中途调整方向。

路线图在这一块的工作包括：

• Server 发起的事件（webhook 和 channel），让客户端不用轮询等结果；
• Tasks 扩展（SEP-2663）成熟化，把长时间运行的任务搬进核心规范——视频渲染、批量研究这类多步骤工作，不再需要持续保持连接。

跨 Agents、Transports、Triggers & Events 三个 Working Group 做组合审查，确保这些原语拼在一起能跑通。

四、HTTP 原生传输统一：本地和远程一套代码

7 月 28 日的发布已经让远程 MCP server 变成了普通的 HTTP 工作负载——挂负载均衡、滚动部署，不用管会话粘滞。

路线图要更进一步：本地 server 也用 Streamable HTTP over stdio，把本地和远程的传输代码路径合并成一条。对 server 和 client 开发者来说，维护成本进一步下降。

五、放弃发布日期，Working Group 主导交付

路线图明确放弃了基于版本的发布时间线。原文是：「Working Groups drive the timeline for their deliverables。」

这不是坏信号——成熟的开放标准就是这么运作的。Linux 内核不会绑在一个核心维护者的 review 队列上发版。MCP 现在在 Linux Foundation 下的 Agentic AI Foundation 治理，走的是同一条路。

具体机制：有成绩记录的 Working Group 可以接受 SEP（Specification Enhancement Proposal）并在自己领域内发布扩展更新，不需要全核心维护者 review。贡献者阶梯从社区参与者到核心维护者，每级 WG 都有公开章程、范围、交付物和成功标准，季度审查。

实际影响：如果你的团队习惯按 MCP spec 版本号做路线图规划，这个模式要改了。跟踪单个 SEP 通过 Working Group 的进展，而不是等一个 spec 发布公告。

六、SDK 开发者体验：为「Agent 写代码」做准备

SDK 是开发者体验 MCP 的第一触点。路线图投入改善 SDK 的人体工程学、规范一致性和文档质量。

这一点在 2026 年格外重要：越来越多开发者是让 Agent 去写 MCP server 和 client 代码的。清晰的 API 和准确的文档直接决定代码能不能一次跑通。模糊的接口和过时的文档，在「人读文档写代码」的时代是摩擦，在「Agent 读文档写代码」的时代是故障。

怎么看这条路线图

五个方向拼在一起，讲的是同一个故事：MCP 正在从「开发者便利工具」变成「需要安全审计的生产基础设施」。

• Agent 身份解决的是企业最痛的安全合规缺口——没有这一层，企业 MCP 部署永远活在 workaround 里。
• 渐进式发现解决的是规模化问题——工具多了，不解决这个问题，Agent 就会变笨。
• 消息原语和 Tasks 扩展解决的是长任务编排——Agent 不再只做「一问一答」的事。
• HTTP 传输统一降低运维复杂度——一套代码管本地和远程。
• SDK 体验适配的是 Agent 写代码的新范式。

路线图没有承诺日期，但方向足够清晰。对正在做 MCP server 或企业 Agent 平台的团队，建议尽早参与对应 Working Group——影响协议演进的最佳方式不是等公告，而是加入讨论。

（本周另一篇关注 Agent 运行时之战：OpenAI 开源 Codex Harness、Anthropic 四大 API 转正、DeepSeek 周末半价——三件事拼在一起，Agent 基础设施层的竞争正在白热化。）