概述
如果说 2025 年的 MCP 重点是“把协议做出来”，那么 2026 年的重点就是“把协议做成可规模化、可治理、可企业部署的基础设施”。过去几个月，MCP 的重点已经不再只是 Tools / Resources / Prompts 这些基础原语，而是围绕四个问题收敛：
- 远程传输怎么在负载均衡、代理和多实例环境里稳定运行
- 任务与会话怎么在生产环境里恢复、迁移和过期
- 协议治理怎么从“核心维护者主导”走向 Working Group 常态化
- 企业到底怎么做审计、SSO、代理层授权和配置移植
所以这篇文章的核心判断也要更新：2026 年的 MCP，最值得关注的不是“又多了什么能力”，而是它开始解决真正影响企业落地的那一层问题。
关键时间线
| 时间 | 事件 | 影响 |
|---|---|---|
| 2025-06-18 | 协议大版本更新 | OAuth 分类、Elicitation、结构化输出、移除 JSON-RPC batching |
| 2025-11-25 | 协议更新 | 异步操作、无状态指引、服务器身份、SDK 分层 |
| 2025-12-09 | 捐赠给 Agentic AI Foundation | 正式治理、工作组、公开注册表 |
| 2026-03-05 | 2026 Roadmap 发布 | 优先级从功能扩展转向 transport、tasks、治理和 enterprise readiness |
| 2026 Q1-Q2 | 生态持续扩展 | 官方开始强调 conformance、SDK tiers、reference implementations |
| 2026-05 | Registry 预览 + Server Cards 提案 | SEP-1649 进入设计阶段，公开预览上线 |
2026 最重要的变化
1. Streamable HTTP 进入“规模化修正”阶段
2025 年大家更关心“远程 MCP 能不能跑起来”；2026 年的 roadmap 关注的是“它能不能在真实生产环境里稳定跑”。
- 无状态化：Streamable HTTP 下一步要支持跨多实例无状态运行
- 负载均衡 / 代理兼容：协议要在 load balancer、gateway、proxy 后面行为正确
- 可恢复会话：客户端需要知道 session 如何创建、恢复、迁移
- Server Cards：通过
.well-known暴露结构化 server metadata，方便浏览器、registry 和 crawler 发现能力
对开发者的意义：如果你做的是远程 MCP Server，现在已经不能只把 stdio 服务器“包一层 HTTP”就算完工。你要开始设计 session、resumption、metadata discovery 和代理层行为。
2. OAuth 2.1 不再是“加分项”，而是远程部署默认路径
MCP 官方授权文档已经把远程授权路径讲得很明确：远程 HTTP 服务器默认应按 OAuth 2.1 思路实现，而不是继续使用自定义 token 拼接方案。
- 401 +
WWW-Authenticate：服务端通过标准方式告诉客户端需要鉴权 - Protected Resource Metadata：客户端从 well-known 路径发现资源与授权要求
- Authorization Server Discovery：继续发现 auth server 能力
- Authorization Code + PKCE：按 OAuth 2.1 习惯完成授权
- 可审计：用户是谁、访问了什么、授了哪些 scope，终于有了标准化抓手
对开发者的意义：远程 MCP 如果要进企业环境，鉴权链路、scope、audience、日志和用户级限流都要补齐。
3. Tasks 原语开始补“生产语义”
Tasks 已经把 MCP 从同步工具调用推向了 call now / fetch later 的异步任务模式，但 2026 roadmap 明确指出，生产落地里仍然缺几块语义：
- Retry semantics：瞬时失败时由谁决定是否重试
- Expiry policies：结果保留多久、过期后客户端怎么知道
- 长期运行任务：更多生产部署后暴露出的运维问题还在持续收集
对开发者的意义：如果你准备把 MCP 用在长时间运行的工作流里，最好不要把任务状态、保留时长和重试策略硬编码死，后面还会继续演化。
4. 协议重点从“新功能”转向“治理和验证”
MCP 现在越来越像一个真正的开放标准项目，而不是单一厂商文档：
- Working Groups / Interest Groups：开始成为推进标准的主力
- SEP prioritization：路线图内的提案会优先审查
- SDK tiers：Official / Community / Experimental 的信号更明确
- Conformance suites：协议正确实现开始有自动化验证目标
- Reference implementations：新能力会更强调参考实现，而不是只给文档
Registry 与 Server Cards 当前状态
截至 2026 年 5 月，MCP Registry 和 Server Cards 仍处于 标准制定和预览阶段，尚未成为正式协议规范的一部分。
MCP Registry
- 公开预览已上线：官方已推出 registry preview，社区可以浏览和注册公共 MCP Server
- 发现层仍然缺失：当前最大的缺口是域名级自动发现——SEP-1649 明确指出，Server Cards 的目标正是填补这个空白
- 定位：开放目录而非私有能力商店，与 Agentic AI Foundation 的治理方向一致
Server Cards
- 目标：通过
.well-known路径暴露结构化 server metadata，让浏览器、registry 和 crawler 可以自动发现 MCP Server 能力 - 当前状态：设计提案阶段（SEP-1649），协议设计中而非正式规范
- 预期影响：一旦落地，远程 MCP Server 的发现将不再依赖人工配置或中心化目录
对开发者的实际影响
| 你的情况 | 现在需要做什么 |
|---|---|
| 维护远程 MCP Server | 开始为 .well-known metadata 做准备，但不急着实现 |
| 做 MCP 客户端 | 关注 Server Cards 规范进展，预留发现层接口 |
| 使用本地 MCP Server | 无影响 |
| 做 MCP 集成平台 | 关注——Registry 和 Server Cards 会改变你的分发和发现策略 |
迁移与架构影响
你现在应该怎么判断自己是否需要动作？
| 你的情况 | 需要做什么 | 优先级 |
|---|---|---|
| 只用本地 stdio server | 更新 SDK，关注错误类型与结果大小限制即可 | 低 |
| 做远程 MCP server | 重新审视 transport、OAuth、session、proxy 行为 | 高 |
| 做 MCP client / 平台接入 | 支持 PRM discovery、Protocol-Version、resumption | 高 |
| 做企业内部网关 / 安全接入 | 提前设计 audit trail、SSO、gateway 模式 | 高 |
| 做 SDK / 框架 | 跟进 conformance、SDK tiers、reference implementations | 高 |
对远程 MCP Server 开发者，2026 最值得做的 5 件事
- 把授权做标准化：优先按 OAuth 2.1 路线实现，不再自造 token 方案。
- 把会话做成可恢复：不要假设单机常驻，考虑 resumption 和迁移。
- 把 server metadata 暴露出来：为 Server Card 和 registry 兼容提前准备。
- 把代理层当一等公民：提前考虑 LB、gateway、proxy 和中间层看见什么。
- 把日志和审计补上：企业真的会先问“谁调用了什么”，再问“你支持多少 tools”。
2026 roadmap 的四个优先级
1. Transport Evolution and Scalability
- 让 Streamable HTTP 在多实例与无状态环境中工作
- 明确 session 创建、恢复与迁移语义
- 推出 MCP Server Cards 作为发现层能力
2. Agent Communication
- 围绕 Tasks 补齐 retry 与 expiry 语义
- 持续收集生产部署中的异步任务问题
3. Governance Maturation
- Contributor Ladder
- WG delegation model
- charter template 与季度审查
4. Enterprise Readiness
- 审计与可观测性
- 企业托管授权
- gateway / proxy 行为
- 配置可移植性
这四条优先级说明了一件事：MCP 正在从“协议规范”升级成“可运营的生态标准”。
谁最需要关注这轮变化？
1. 远程 MCP Server 团队
- 影响最大
- 重点看 OAuth 2.1、Streamable HTTP、session 恢复和 gateway 行为
- → 参见 MCP 协议详解 和 MCP Inspector 调试实战
2. SDK / 框架开发者
- 需要跟进 conformance、reference implementations 和 SDK tiers
- 如果 SDK 只实现了“最小可跑通”，后面会越来越难接上生态
3. 企业平台和安全团队
- 会更关心 audit、SSO、gateway、config portability
- 这决定 MCP 能不能进入正式采购和合规流程
是否需要行动？
| 情况 | 建议 |
|---|---|
| 只用本地 MCP Server（stdio） | 低优先级——更新 SDK 版本即可 |
| 部署远程 MCP Server | 尽快——按 OAuth 2.1 + Streamable HTTP + 会话恢复思路重审架构 |
| 开发 MCP 客户端 | 尽快——支持 PRM discovery、Protocol-Version、resumption |
| 只是使用 Claude Code / Cursor 接 MCP | 暂时不需要——大部分变化会由客户端吸收 |
| 维护 MCP SDK | 关注 conformance、SDK tiers、reference implementations |
一句话结论
2026 年的 MCP，不再只是“给 Agent 接工具”的协议，而是在向“远程、可审计、可治理、可接企业网络”的标准底座演进。对本地玩具级 server 来说变化不大；对远程 server、平台接入和企业落地来说，这一轮变化非常实。