7月28日，MCP（Model Context Protocol）将发布史上最大规模协议修订。无状态核心、Tasks扩展、MCP Apps 交互界面三大变化，彻底改变 AI Agent 连接外部工具的底层架构。

开篇：MCP 的"USB-C 时刻"来了

如果你在 2026 年做 AI Agent 开发，MCP 已经是绕不开的协议。截至今年 5 月，OpenAI、Google、Microsoft、Anthropic 全部接入 MCP，GitHub 上 4 万+ MCP Server 覆盖了从数据库到 IDE 的几乎所有工具。

但 MCP 有一个底层问题一直存在：它是基于会话（session）的有状态协议。

这意味着：
- 每台 MCP 服务器必须和客户端维持 sticky session
- 水平扩容需要共享 session store
- 网关需要深度包检测才能路由
- 部署复杂度远超普通 REST API

2026 年 7 月 28 日，这一切将彻底改变。

MCP 2026-07-28 规范发布候选版（Release Candidate）已于 5 月 21 日锁定，最终版本将在 10 天后 正式发布。这是 MCP 自 2024 年 11 月诞生以来最大的一次协议修订，核心变化可以用三个词概括：无状态、可扩展、更安全。

核心变化 1：从有状态到无状态

旧协议（2025-11-25）的工作方式

在旧版 MCP 中，调用一个工具需要先建立会话：

// 第一步：初始化握手（必须）
POST /mcp HTTP/1.1
Content-Type: application/json

{
  "jsonrpc": "2.0",
  "id": 1,
  "method": "initialize",
  "params": {
    "protocolVersion": "2025-11-25",
    "capabilities": {},
    "clientInfo": {"name": "my-app", "version": "1.0"}
  }
}

// 服务器返回 Mcp-Session-Id: 1868a90c-3a3f-4f5b

// 第二步：带上 session ID 调工具
POST /mcp HTTP/1.1
Mcp-Session-Id: 1868a90c-3a3f-4f5b
Content-Type: application/json

{
  "jsonrpc": "2.0",
  "id": 2,
  "method": "tools/call",
  "params": {
    "name": "search",
    "arguments": {"q": "otters"}
  }
}

问题显而易见：Mcp-Session-Id 把客户端锁定到了某一台服务器实例。负载均衡器必须支持 sticky routing，水平扩容需要共享 session store，运维复杂度直接翻倍。

新协议（2026-07-28）的工作方式

同一个调用，在新协议中变成了一次自包含的请求：

// 一步到位，无需握手
POST /mcp HTTP/1.1
MCP-Protocol-Version: 2026-07-28
Mcp-Method: tools/call
Mcp-Name: search
Content-Type: application/json

{
  "jsonrpc": "2.0",
  "id": 1,
  "method": "tools/call",
  "params": {
    "name": "search",
    "arguments": {"q": "otters"},
    "_meta": {
      "io.modelcontextprotocol/clientInfo": {
        "name": "my-app",
        "version": "1.0"
      }
    }
  }
}

关键变化：

这对 AI 创业者意味着什么？ 如果你们团队自建了 MCP Server（如知识库搜索、内部 API 封装），升级后可以直接放在普通 HTTP 网关后面水平扩容，不需要任何 session 管理。对于 SaaS 类 MCP 服务（如数据库查询、代码执行），这意味着可以像传统 API 一样做负载均衡和零宕机部署。

有状态应用怎么办？

协议层无状态，不等于你的应用必须无状态。新规范推荐了一个更优雅的模式：让模型自己管理状态句柄。

# 服务端：工具返回一个 handle
@app.tool("create_browser")
def create_browser():
    browser_id = launch_browser()  # 创建浏览器实例
    return {"browser_id": browser_id}

# 客户端：模型把 browser_id 传回下一个调用
@app.tool("navigate")
def navigate(browser_id: str, url: str):
    browser = get_browser(browser_id)
    browser.goto(url)
    return {"status": "loaded", "browser_id": browser_id}

这个模式比隐藏的 session 状态更强——模型能看见状态，可以跨工具组合使用，也可以在步骤之间传递。

核心变化 2：Extensions 成为一等公民

旧版 MCP 中，Extensions 存在但没有正式流程。新规范（SEP-2133）将其正式化：

• 用 reverse-DNS ID 标识（如 io.modelcontextprotocol.tasks）
• 通过 extensions map 在客户端和服务端能力中协商
• 独立的 ext-* 仓库，独立版本管理
• 有专门的 Extensions Track 从实验阶段走向官方

MCP Apps：服务器渲染 UI

SEP-1865 引入了一个新能力：MCP 服务器可以附带交互式 HTML 界面。

┌──────────────────────────────────────┐
│  Host（Claude/ChatGPT/Cursor）       │
│  ┌────────────────────────────────┐  │
│  │  Sandboxed iframe              │  │
│  │  ┌──────────────────────────┐  │  │
│  │  │  MCP Server 提供的 UI    │  │  │
│  │  │  表单/图表/操作面板      │  │  │
│  │  └──────────────────────────┘  │  │
│  └────────────────────────────────┘  │
│  UI 操作 → JSON-RPC → 审计路径       │
└──────────────────────────────────────┘

这意味着什么？想象一个数据库 MCP Server，你不在只能通过文字命令操作数据——它可以在 ChatGPT 的会话中直接渲染一个数据浏览面板，支持排序、筛选、导出。所有操作仍然走 MCP 的 JSON-RPC 协议，经过同样的授权和审计路径。

Tasks：长任务管理

旧版 Tasks 是实验性核心功能，生产实践暴露了大量问题。新版本将其重做为 Tasks 扩展：

tools/call → 服务器返回 task_handle
     ↓
tasks/get → 查询进度
tasks/update → 修改任务参数
tasks/cancel → 取消任务

创建权在服务端：客户端声明支持 Tasks 扩展，服务端决定什么时候把 tools/call 变成异步任务。tasks/list 被移除了（无状态模式下无法安全实现）。

核心变化 3：Authorization 加固

六个 SEP 一起收紧 MCP 的安全模型，主要内容：

1. iss 参数验证（SEP-2468）：客户端必须验证 OAuth 响应的 iss，防范 mix-up 攻击
2. Dynamic Client Registration 声明 application_type（SEP-837）：避免授权服务器把桌面/CLI 客户端错误识别为 web 客户端而拒绝 localhost 回调
3. 客户端绑定注册凭证到 authorization server 的 issuer（SEP-2352）
4. Refresh Token 支持（SEP-2207）

对于构建 MCP 服务的 AI 创业者，这些变化意味着你的授权服务器需要开始提供 iss 参数，并正确支持 application_type 区分。

核心变化 4：三大功能正式废弃

注意：这些只是标注性废弃（annotation-only deprecation），在 2026-07-28 及之后一年内发布的所有规范版本中仍然可用。删除任何一个都需要走单独的 SEP 流程。

核心变化 5：Full JSON Schema 2020-12

工具的 inputSchema 和 outputSchema 从受限的子集升级到完整的 JSON Schema 2020-12（SEP-2106）：

{
  "inputSchema": {
    "type": "object",
    "oneOf": [
      {"properties": {"query": {"type": "string"}}},
      {"properties": {"sql": {"type": "string"}, "params": {"type": "array"}}}
    ]
  }
}

这意味着 MCP 工具的参数定义可以用 oneOf/anyOf/allOf、条件逻辑、$ref 引用——以前只能用简单类型。

迁移行动清单

距离 7 月 28 日正式发布还有 10 天，以下是推荐行动：

如果你在维护 MCP Server（SaaS 服务/内部工具）

1. 立即：读取 draft specification 和 changelog
2. 本周：移除 initialize 握手和 Mcp-Session-Id 依赖；在 _meta 中读取客户端信息
3. 本周：检查是否用了已废弃的 Roots/Sampling/Logging，计划迁移
4. 本月：如果使用了旧版 Tasks API，迁移到新 Tasks 扩展的 tasks/get/tasks/update/tasks/cancel 模式
5. 本月：为授权服务器添加 iss 参数和 application_type 支持

如果你在使用 MCP Client（Claude Code/Cursor/Hermes Agent）

1. 关注上游 SDK 更新：Tier 1 SDK（Python/TypeScript）将在 7 月 28 日前发布支持
2. 检查自定义工具链：如果在 MCP 客户端中写了工具，检查是否依赖了 Mcp-Session-Id 或旧的 initialize 流程
3. 考虑缓存：新协议的 ttlMs 和 cacheScope 允许客户端缓存 tools/list 结果——可以显著减少请求量

如果你想在 MCP 生态中创业

这次升级带来了几个新机会：

• MCP Apps 开发：为现有 MCP Server 添加交互界面，提供更好的用户体验
• Tasks 扩展集成：长任务（数据处理、报告生成）的 MCP 化
• MCP 网关/代理服务：无状态协议让 MCP 网关更容易实现——路由、限流、审计都可以做在 HTTP 层

为什么这次升级对 AI 创业者很重要

MCP 从有状态到无状态，本质上是从"玩具协议"到"生产级基础设施"的转变。

• 部署成本降低：不再需要 sticky session 和共享存储，一个 MCP 服务可以用最简单的 HTTP 负载均衡
• 可观测性提升：W3C Trace Context 支持让分布式追踪贯穿 MCP 调用链
• 缓存标准化：ttlMs + cacheScope 让客户端自动缓存，减少服务器压力
• 扩展性增强：Extensions 框架意味着新能力可以独立发布，不需要等核心规范

对于计划在 AI 工具链中创业的团队，现在是用 MCP 构建生产级服务的最佳时机——协议本身已经准备好了。

总结

行动建议：今天就去读 draft specification，检查你的 MCP 服务是否依赖了即将移除的功能。10 天后的正式发布，不要让 legacy 代码拖慢你的节奏。

AI创业 #MCP #AI-Agent #工具协议 #一人公司