MCP 2026-07-28 正式版落地：无状态核心来了，我连夜盘点了 Server 作者的升级作业

背景与热点吐槽

昨天（7 月 28 日）MCP 官方博客把 2026-07-28 正式版规范推了出来，我晚上刷到的时候人是麻的——不是因为意外，RC 早在 5 月 21 日就冻结了，十周 SDK 验证期大家都知道这天要来。麻的是清单拉出来一看：stateless core、废弃 Roots / Sampling / Logging、OAuth 加固、JSON Schema 2020-12，四件事里三件是破坏性变更。

我手上维护着好几个内部 MCP Server，去年为了 session 管理专门写的粘性路由配置、为了 Sampling 做的"服务端反向调模型"骚操作，这次基本都要送进回收站。打工人最怕的不是学新东西，是刚学会的东西被官方亲手宣布过时。

但吐槽归吐槽，说句公道话：这次重构方向是对的，而且是我盼了很久的方向。下面按我自己的理解拆一遍。

技术原理拆解

1. Stateless Core：终于不用伺候会话了

旧版 MCP 的核心痛点是有状态：客户端和服务端要先握手（initialize）建立会话，后续请求都绑定在这个会话上。这在本地 stdio 场景无所谓，但一放到生产环境的 HTTP 部署就是灾难——你必须做粘性会话（sticky session）或者集中式 session 存储，普通的无状态负载均衡器直接歇菜。我们团队之前为了在 K8s 上横向扩容一个 MCP Server，被迫上了 Redis 存会话状态，纯纯的架构税。

新规范把核心协议做成了 stateless：取消会话握手，每个请求自带完整上下文，服务端不需要记住"你是谁、聊到哪了"。带来的直接红利：

普通 LB 即可承载 MCP 流量，Nginx/ALB 随便轮询，扩缩容不再看会话脸色；
Serverless 部署（Lambda / Cloud Functions）从"能跑但别扭"变成一等公民；
故障恢复简单了，节点挂了请求打到别的节点照常处理。

需要状态的场景怎么办？答案是下沉到 Extensions（后面讲的 Tasks 就是干这个的），核心协议保持干净。这个"无状态内核 + 有状态扩展"的分层，和 HTTP 本身无状态、靠 Cookie/Token 叠加状态的思路一脉相承，属于协议设计的经典正道。

2. 三大能力正式废弃：Roots、Sampling、Logging

Sampling（服务端反过来请求客户端调用 LLM）：想法很美，实际生态里客户端支持稀稀拉拉，服务端作者根本不敢依赖。废弃合理，需要模型调用就自己拿 API key 直连。
Roots（客户端暴露文件系统根目录）：安全边界模糊，实践中大多数 Host 也没实现好。
Logging：被更通用的机制取代，服务端日志本来就该走自己的可观测体系，塞进协议里一直很拧巴。

如果你的 Server 用了这三个能力，这次升级就不是"改改版本号"，而是要动架构。

3. JSON Schema 2020-12 + OAuth 加固

工具定义全面支持 JSON Schema 2020-12，意味着 $defs、prefixItems、条件校验（if/then/else）这些都能用了。以前为了绕开老 draft 的限制，我把复杂参数拍平成一堆字符串字段让模型自己拼，现在终于可以写有尊严的 Schema 了。OAuth 侧则是授权模型加固，配合无状态化，token 校验每请求独立进行，对企业接入是利好。

4. Extensions 框架：MCP Apps 和 Tasks

首批官方扩展两个：MCP Apps 提供沙盒化的服务端 UI（服务端可以给用户渲染交互界面，不再只有干巴巴的 JSON），Tasks 处理长耗时任务（提交任务、轮询/订阅进度，替代以前用 Sampling + 自定义协议硬凑的方案）。核心协议瘦身、能力靠扩展叠加，以后 MCP 的演进主战场大概率在 Extensions。

代码示例或实操演示

升级前后对比。旧版本你的 Server 大概长这样（伪代码，以 TypeScript SDK 风格示意）：

// 旧版：有会话，initialize 握手后才能干活
const server = new McpServer({ name: "my-server", version: "1.0.0" });
server.onInitialize((session) => {
  session.state = { userPrefs: loadPrefs(session.clientInfo) }; // 状态挂会话上
});

新版无状态写法，状态要么进请求上下文，要么外置：

// 新版：每个请求自包含，认证信息随请求携带
server.tool(
  "query_orders",
  {
    // JSON Schema 2020-12：可以用 $defs 和条件校验了
    type: "object",
    properties: {
      filter: { $ref: "#/$defs/OrderFilter" },
    },
    $defs: {
      OrderFilter: {
        type: "object",
        properties: {
          status: { enum: ["paid", "shipped", "refunded"] },
          dateRange: { type: "array", prefixItems: [
            { type: "string", format: "date" },
            { type: "string", format: "date" },
          ]},
        },
      },
    },
  },
  async (args, ctx) => {
    const user = await verifyOAuthToken(ctx.request.auth); // 每请求独立鉴权
    return await queryOrders(user, args.filter);           // 不依赖任何会话状态
  }
);

长任务改用 Tasks 扩展的思路：工具调用立即返回 task id，客户端后续凭 id 查询进度，服务端把任务状态放自己的存储里（DB/Redis），协议层不背状态。

牛马实践建议

结合我这几个月折腾内部 MCP 平台的经验，给同行几条实在话：

先做废弃项审计，再谈升级。全局搜一下代码里有没有依赖 Sampling / Roots / Logging，有的话这就是工作量大头，先评估再排期，别拍脑袋跟老板说"一天搞定"。
无状态化别只改协议层。把 Server 里所有隐式状态（内存缓存的用户上下文、会话级配置）显式外置或塞进请求，否则协议无状态了、业务还是有状态，LB 轮询一开直接线上事故。
Schema 别急着炫技。JSON Schema 2020-12 很强，但工具参数 Schema 最终是给模型看的，嵌套太深的 $defs 和条件校验会降低模型填参正确率。我的经验是：校验能力用满，结构复杂度克制。
锁好 SDK 版本再灰度。官方 SDK 经过十周 RC 验证，但你的下游 Host（Claude、各家 Agent 框架）跟进速度不一。建议新旧两个端点并行跑一段时间，观察各客户端兼容性再切流。
关注 Tasks 扩展。如果你的工具有超过 30 秒的执行路径（跑报表、批量处理），趁这次升级直接改成 Tasks 模式，别再用"同步接口 + 超时重试"硬扛了。

总结与展望

这次 2026-07-28 版本，我愿称之为 MCP 从"能用的协议"走向"能规模化部署的协议"的成人礼。无状态核心解决了生产部署最大的架构税，Extensions 框架给协议演进留出了不污染内核的空间，废弃三件套虽然让存量作者（比如我）痛一下，但长痛不如短痛。

往后看，我个人的判断是：MCP Server 会加速"云原生化"——Serverless 部署成为主流形态，MCP Apps 会催生一批带 UI 的富交互工具，而 Tasks 会让 Agent 编排长任务的姿势彻底标准化。至于我自己？周末先把内部那三个 Server 的迁移方案写了。卷不动也得卷，毕竟协议不等人，需求更不等人。各位 MCP 同行，升级路上见。

FAQ

Q1：我的 MCP Server 还在用旧版规范，会立刻不能用吗？

不会立刻挂。主流 Host 和 SDK 通常会保留一段旧版本协商的兼容窗口，但这是过渡期而非常态。建议尽快审计对 Roots、Sampling、Logging 的依赖并排期迁移，越晚迁移，生态里支持旧行为的客户端越少，风险越高。

Q2：无状态化之后，需要多轮上下文或用户级配置的场景怎么办？

把状态从协议层移到应用层：认证走 OAuth token 每请求独立校验，用户配置存服务端自己的 DB/缓存并以请求参数或 token 声明关联，长耗时任务用官方 Tasks 扩展管理生命周期。核心原则是协议不背状态，状态由你的存储背。

Q3：Sampling 被废弃了，服务端想调用 LLM 该怎么替代？

直接在服务端集成模型 API（自备 key 直连模型服务商或内部网关），不再反向依赖客户端代理模型调用。这样可控性反而更好：模型选择、限流、计费都在自己手里，不受各家 Host 对 Sampling 支持参差不齐的制约。

Q4：JSON Schema 2020-12 支持后，工具参数应该写多复杂？

校验能力可以用满（enum、format、$defs 复用），但结构复杂度要克制。Schema 最终是给模型填参用的，嵌套过深或大量条件分支会显著降低模型的填参正确率。建议参数层级控制在两到三层内，复杂对象拆成多个语义清晰的工具。

Q5：MCP Apps 和 Tasks 这两个官方扩展现在值得跟进吗？

Tasks 建议优先跟进，只要你有超过几十秒的长耗时工具，它就是标准解，替代自造的轮询方案。MCP Apps 提供沙盒化服务端 UI，适合需要用户交互确认的场景（如审批、表单），可以先在非核心链路试点，等各 Host 渲染支持成熟后再铺开。