一、为什么这份路线图是 2026 年下半年最重要的事

MCP(Model Context Protocol)从 Anthropic 在 2024 年底推出的一个工具连接协议,到 2025 年被 OpenAI、Google、Microsoft、Block 等公司同时采纳,再到 2026 年成为 Agent 工具调用的事实标准,演化速度比想象中快得多。

2026 年上半年,MCP 维持了 2025 年 11 月的最后一个 spec 版本,没有再发新版本。但项目本身没有停——它从"个人维护者拼 spec"的工作模式,转入了"Working Groups + SEP + 正式治理"的工程模式。这本身就是一个信号:MCP 已经过了"协议能不能用"的阶段,进入"协议怎么被大规模生产用"的阶段。

2026 年下半年发布的 MCP 2026 Roadmap 是这种范式转变的第一份正式文件。它不是"下一个 spec 版本会加什么功能"的发布清单,而是"哪些问题在 2026 年最值得 Working Group 集中攻克"的方向图。

二、最重要的转变:从 Releases 到 Working Groups

旧版路线图围绕"版本发布"组织——"下次 spec 什么时候发、发什么、再下次发什么"。这种组织方式在项目小、人少的时候合理。

新版路线图完全围绕"优先领域"组织,不再承诺具体时间表。原文:

"Working Groups are now the primary vehicle for protocol development, and the roadmap needed to reflect that. The new document is organized around priority areas, rather than around dates."

中文:Working Groups 是协议开发的主要载体,路线图要反映这一点。新文档围绕优先领域组织,而不是围绕日期组织。

这背后是一个诚实的承认:开源标准工作很少有可预测的发布节奏,旧版路线图隐含的"按时交付"暗示是不真实的。新版路线图更诚实地告诉社区:哪些问题是核心、哪些人在解决、你能在哪里参与。

三、四大优先领域

核心维护者排了个序,4 个领域成为 2026 年集中投入的方向。SEPs 在这些方向上会获得加急审查,核心维护者精力主要投在这里。

领域一:Transport Evolution and Scalability

MCP 的 Streamable HTTP 是让 MCP Server 从"本地进程"升级为"远程服务"的传输层——这是 MCP 进入生产部署的关键解锁。

但在规模化运行时,Streamable HTTP 暴露了一组一致的 gap:

  • 有状态 session 跟负载均衡器打架——传统负载均衡器按连接做哈希,但 MCP 的 session 是有状态的
  • 横向扩展需要 workaround——多实例部署时,session 状态在哪个实例是个问题
  • 没有标准元数据格式——registry 或 crawler 想在不连服务器的情况下知道服务器能做什么,没标准协议

这领域的工作分两块:

  • 演进传输 + session 模型,让 server 能横向扩展、不需要持状态
  • 标准化元数据格式,通过 `.well-known` 暴露,让 server 能力可发现

路线图明确说:本周期不增加新的官方传输,只演进现有传输。"保持传输集合小"是 MCP 设计原则的刻意选择。

领域二:Agent Communication

Tasks primitive(SEP-1686)作为实验性功能已经发布,工作良好。但生产环境暴露了一组具体的生命周期 gap:

  • 任务瞬时失败时的重试语义
  • 任务完成后结果保留多久的过期策略

这类迭代只有在真实部署里才能发现。MCP 团队的策略是:先发实验版,收集生产反馈,再迭代——这个策略会沿用到 MCP 其他部分。

领域三:Governance Maturation

现在每个 SEP 都要全部 Core Maintainer 审核,不分领域。这是瓶颈,拖慢了已经在自己领域有专业能力的 Working Groups。

目标是不牺牲质量的前提下移除瓶颈:

  • 贡献者阶梯(contributor ladder)——从社区参与者到维护者有清晰路径
  • 委托模型(delegation model)——信任的 Working Groups 可以自行批准本领域 SEP,不必等 core 全员审核

Core Maintainers 保留战略监督,Working Groups 获得行动空间。

领域四:Enterprise Readiness

企业部署 MCP 时遇到一组可预测的问题:

  • 审计 trail(操作审计)
  • SSO 集成的身份验证
  • 网关行为
  • 配置可移植性(同一份配置能不能在不同环境跑)

这是 4 个领域里定义最少的,刻意的——MCP 团队希望"正在经历这些挑战的人"来共同定义工作。专门的 Enterprise WG 还没有成立,这是一个开放邀请:任何在企业基础设施里跑 MCP 的人,都应该来牵头这个 WG。

四、On the Horizon:暂时不进 top 4 但持续观察的方向

不是所有 MCP 关心的领域都进了 top 4,有些被放到了"On the Horizon"——有真实社区兴趣但本周期不是重点:

  • Triggers 和 event-driven updates(事件驱动更新)
  • Streamed 和 reference-based result types(流式结果类型)
  • 更深入的安全和授权工作
  • Maturating the extensions ecosystem(扩展生态成熟)

已经进入评审的具体提案包括 SEP-1932(DPoP) 和 SEP-1933(Workload Identity Federation)——两个都直接对应"非人类身份"在分布式系统里的认证问题。

On the Horizon 不等于"我们不想要"。这些领域欢迎社区牵头成立新 WG,核心维护者会在 SEP 评审上配合,但本周期不主动建立工作组。

五、企业 Agent 部署的"Four A's"框架:MCP Hosts 的身份盲点

Glama 2026 年 7 月 25 日的文章 "Who's Calling? MCP Hosts Are an Identity Blind Spot" 揭示了一个 MCP 路线图没明说但同样重要的问题:

MCP 协议的授权层(client → server)是干净的——发现、动态客户端注册、PKCE 授权码、scoped tokens,都写得很清楚。

但 MCP host(宿主)没有自己的身份。Host 是装所有 client 和所有凭据的容器,但 spec 里的 OAuth 图不把 host 画成"需要认证自己"的 actor。WSO2 的 Ayesha Dissanayaka 在 MCP Dev Summit Mumbai 2026 上把这个 gap 点得很直:这就是企业部署悄悄崩盘的地方。

她提出 Four A's 框架,把 Agent 身份问题拆成四个问题:

  • Administer(管理):你存不存在?——注册、所有权、停用、注销
  • Authenticate(认证):怎么证明是你?——证明、零信任验证、短时 token、凭据轮换、workload identity
  • Authorize(授权):你能干什么?——最小权限、即时授权、工具级 scoping、自动动作 vs 需人签字的分界线
  • Audit(审计):你能证明你做了什么吗?——审计 trail、合规证据、决策溯源、异常检测、可重放

企业里每条边(调用方 → host、host → LLM 提供方、host → sub-agent、host → 内部或外部工具)都需要这四个问题的答案。现在大多数部署里,没有一条边能答上。

具体机制是 On-Behalf-Of(OBO)OAuth 2.0 扩展,这是 WSO2 已经提交到 IETF 的草案:

  • `requested_actor` 参数:在用户授权时明确指定哪个 agent
  • `actor_token` 参数:agent 在 code 换 token 时自己认证

最终 token 是 JWT,带 `sub`(用户)、`client_id`(客户端)、嵌套 `act`(为用户行事的 agent)。下游任何看到这个 token 的服务都能区分:"用户做的" vs "agent 代用户做的"——这是普通 API key 或标准 JWT 都表达不了的。

六、为什么路线图里没有"AI 模型"这一项

读完整个 MCP 2026 Roadmap,你会发现:没有"模型支持"或"模型相关"作为优先领域。

这不是疏忽,这是设计。

MCP 的目标是模型无关的协议层——Anthropic Claude、OpenAI GPT、Google Gemini、Meta Llama、本地模型,都该能同样用 MCP。这意味着 MCP 不应该押注任何特定模型的功能。模型层的事,留给模型层。

MCP 关心的是模型下面的事(工具、上下文、身份)和模型旁边的事(多 Agent 协作、通信、任务生命周期)。这是协议的本分。

七、对企业的现实启示

短期(立刻):

  • 自检:你的 MCP 部署路线图跟上了吗?你可能正在用 2025 年 11 月的 spec,这套 spec 仍然可用,但生产部署需要的 .well-known 元数据、Streamable HTTP 横向扩展、任务生命周期这些是 Roadmap 的重点
  • 不要自己造 MCP proxy 去解决 Enterprise Readiness 问题——MCP 团队明确邀请企业基础设施工程师参与 Enterprise WG 的共建
  • OAuth token 设计采用 OBO 模型,把"用户做的"和"agent 代做的"显式分开,这是未来 12 个月会变成标配的事

中期(3-6 个月):

  • 关注 SEP-1932(DPoP)和 SEP-1933(Workload Identity Federation)的进展——这两个是 MCP 身份层的基础
  • 关注 Enterprise WG 的成立,加入而不是自己重造
  • 内部 Agent 治理:用 Four A's 框架自检——Administer / Authenticate / Authorize / Audit 四条边各答一遍

长期(1 年+):

  • MCP 作为协议层的位置已经稳定,企业应该接受"MCP 是 Agent 工具调用的事实标准",而不是赌自家 API
  • 多 Agent 协作(Agent-to-Agent)将成为 MCP 的下一个主战场——On the Horizon 里的"event-driven"和"reference-based results"都是为这个铺路
  • 身份 + 授权 + 审计是 Agent 行业从"工具"走向"基础设施"必须解决的三大工程问题,On-Behalf-Of 模式会成为企业 Agent 的事实标准

八、回到题目:New MCP Roadmap 真正告诉了我们什么

这份路线图最反直觉的一点是:它没有承诺任何新功能。

不是"我们会发 MCP 2.0 加上 X、Y、Z",而是"我们认为 X、Y、Z 这四个领域最重要,Working Groups 在做,你可以在哪里参与"。

这是协议治理的成熟标志——从"中心化发布"转向"分布式共建"。

对一个 Agent 行业的从业者来说,这份路线图的真正意义是:

  • MCP 已经稳了——它不会再回到"协议能不能用"的争议,而是进入"怎么用得更好"的演进
  • 四个优先领域就是未来 12 个月的工程重点——任何押注 MCP 的企业都应该盯着这四条线
  • 企业 readiness 不是 MCP 团队单独能做的——它在邀请企业基础设施工程师参与共建,而不是等官方给出答案

2026 年的 MCP 路线图,是 Agent 行业从"百花齐放"走向"标准收敛"的关键节点。对企业来说,问题不再是"用不用 MCP",而是"怎么用 MCP 跟上这条路线图"。

对生态而言,真正的护城河不再是"我用 MCP",而是"我参与了 MCP 的演进"。