MCP 走向无状态:在下一次上线智能体前读懂 2026-07-28 规范

·阅读约12分钟·Evergreen Tools Team

2026 年 9 月 17-18 日,AGNTCon + MCPCon Europe 在阿姆斯特丹举行。这届大会之所以值得开发者关注,是因为它是 Model Context Protocol 归属基金会治理后,第一次把「规范怎么演进」和「生产环境怎么落地」放在同一个会场里讨论。而在此之前,MCP 已经在 2026 年 7 月 28 日发布了一版改动极大的规范:协议核心从有状态改为无状态。这篇文章只做一件事——把这一版规范里真正会打断你集成的东西讲清楚。

无状态核心让 MCP 更接近普通 Web 基础设施

无状态核心让 MCP 更接近普通 Web 基础设施

一、先看治理结构,它决定了「稳定」的含义

按 Linux 基金会 2026 年 4 月 2 日的新闻稿,Agentic AI Foundation(AAIF)是智能体 AI 开放标准的「中立之家」,创始项目包括 Model Context Protocol(MCP)、goose 与 AGENTS.md,执行董事为 Mazin Gilbert。2026 年的活动行程以 AGNTCon + MCPCon Europe(9 月 17-18 日,阿姆斯特丹)与 AGNTCon + MCPCon North America(10 月 22-23 日,圣何塞)为旗舰,另有贯穿全球的 MCP Dev Summit 系列:纽约(4 月 2-3 日)、班加罗尔(6 月 9-10 日)、孟买(6 月 14-15 日)、首尔(8 月 13-14 日)、上海(9 月 6-7 日)、东京(9 月 10-11 日)、多伦多(10 月 5-6 日)、内罗毕(11 月 19-20 日)。协议不再由单一厂商掌控,这对你的集成路线图来说是结构性利好。

# 1. The governance picture as of late September 2026
AAIF = {
    "name": "Agentic AI Foundation",
    "host": "The Linux Foundation",
    "founding_projects": ["Model Context Protocol (MCP)", "goose", "AGENTS.md"],
    "executive_director": "Mazin Gilbert",
    "flagship_events_2026": {
        "AGNTCon_MCPCon_Europe": "Sept. 17-18, Amsterdam",
        "AGNTCon_MCPCon_North_America": "Oct. 22-23, San Jose, California",
    },
    "dev_summit_series": [
        "New York, Apr. 2-3", "Bengaluru, Jun. 9-10", "Mumbai, Jun. 14-15",
        "Seoul, Aug. 13-14", "Shanghai, Sept. 6-7", "Tokyo, Sept. 10-11",
        "Toronto, Oct. 5-6", "Nairobi, Nov. 19-20",
    ],
}
# The protocol is now governed by a foundation, not by a single vendor.
# That changes what "stable" means for your integration roadmap.

二、核心变化:协议变成无状态

2026-07-28 版规范的总结写得很直白:新的无状态协议核心,是「把 MCP 从双向有状态协议,改造成请求/响应式的无状态协议」。具体地:initialize / initialized 握手被正式取消,Mcp-Session-Id 头部被移除;每个请求自带协议版本、客户端身份与客户端能力(放在 _meta 里);如果客户端想在动手前了解服务端能力,有一个新的、可选的 server/discover RPC;于是「任何请求都可以落在轮询负载均衡器后面的任意一个实例上」,不需要共享存储。规范同时提醒:取消协议层会话,不等于你的应用必须无状态——推荐做法是从工具里签发一个显式 handle,让模型把它当参数传回来,因为模型能看见的状态,比藏在传输层的状态更好用。

# 2. The headline change: the protocol is stateless
OLD_MODEL = {
    "handshake": "initialize / initialized exchange",
    "session": "Mcp-Session-Id header",
    "transport": "bidirectional, stateful stream",
    "consequence": "requests are sticky to the instance that holds the session",
}

NEW_MODEL = {
    "handshake": "none required; optional server/discover RPC for capability lookup",
    "session": "removed from the protocol",
    "per_request_meta": [
        "protocol version",
        "client identity",
        "client capabilities",
    ],
    "consequence": "any request can land on any instance behind a round-robin load balancer",
}

# Dropping protocol-level sessions does not force your app to be stateless.
# The recommended pattern: mint an explicit handle from a tool and have the
# model pass it back as an argument. State the model can see beats state hidden
# in the transport.
头部路由把网关、限流与鉴权放回它们该在的位置

头部路由把网关、限流与鉴权放回它们该在的位置

三、路由与缓存下沉到 HTTP 层

两个改动会直接影响你怎么部署。第一是头部路由:Streamable HTTP 请求现在必须带 Mcp-Method 与 Mcp-Name,这样网关、限流器或 WAF 可以直接基于头部做路由与计量,而不必解析 JSON 正文。第二是列表结果可缓存:tools/list、prompts/list、resources/list 与 resources/read 的响应会带上 ttlMs 与 cacheScope,并带有确定性顺序,好处有两个——客户端可以缓存工具目录;上游的 prompt 缓存能在重连之间保持稳定。官方示例请求已经把这三件事摆在一起:POST /mcp,头部传 MCP-Protocol-Version、Mcp-Method、Mcp-Name,正文里用 _meta 携带客户端身份。

// 3. Routing and caching move to the HTTP layer where gateways live
const requestEnvelope = {
  method: "POST",
  path: "/mcp",
  headers: {
    "MCP-Protocol-Version": "2026-07-28",
    "Mcp-Method": "tools/call",
    "Mcp-Name": "search",
  },
  body: {
    jsonrpc: "2.0",
    id: 1,
    method: "tools/call",
    params: {
      name: "search",
      arguments: { q: "otters" },
      _meta: { "io.modelcontextprotocol/clientInfo": { name: "my-app", version: "1.0" } },
    },
  },
};

const cacheableLists = {
  appliesTo: ["tools/list", "prompts/list", "resources/list", "resources/read"],
  fields: ["ttlMs", "cacheScope"],
  why: [
    "clients can cache tool catalogues",
    "deterministic ordering keeps upstream prompt caches stable across reconnects",
  ],
};

四、鉴权、生命周期与扩展框架

鉴权是官方承认「实现者花时间最多」的部分,这一版继续收紧:授权服务器应按 RFC 9207 返回 iss 参数,客户端必须在兑换 code 前验证它(堵住授权服务器混淆的漏洞);客户端在注册时应设置 application_type,这样桌面与 CLI 应用的 localhost 重定向就不会再被拒;客户端凭据与签发它的授权服务器绑定,不能跨服务器复用;Dynamic Client Registration 被正式弃用,转向 Client ID Metadata Documents(CIMD),DCR 为兼容继续可用但会在未来版本移除。生命周期方面,这一版确立了正式弃用政策,最短十二个月窗口;Roots、Sampling、Logging 以及旧版 HTTP+SSE 传输被标记为弃用(仍可用但新实现不应采用);Tasks 从实验性核心移入 io.modelcontextprotocol/tasks 扩展,提供轮询式 tasks/get 与新的 tasks/update;变更通知则改为单一的 subscriptions/listen 流,按通知类型选择性订阅。

# 4. Authorization, lifecycle and the extensions framework
AUTH = {
    "issuer_validation": "authorization servers should return iss per RFC 9207; "
                         "clients must validate it before redeeming a code",
    "client_registration": "Dynamic Client Registration is deprecated in favour "
                           "of Client ID Metadata Documents (CIMD)",
    "credential_binding": "client credentials are bound to the issuing authorization server",
    "desktop_cli": "set application_type during registration so localhost "
                   "redirects stop being rejected",
}

LIFECYCLE = {
    "deprecation_policy": "formal, with a twelve-month minimum window",
    "deprecated_now": ["Roots", "Sampling", "Logging", "legacy HTTP+SSE transport"],
    "tasks": "moved to the io.modelcontextprotocol/tasks extension, with "
             "poll-based tasks/get and a new tasks/update",
    "notifications": "a single subscriptions/listen stream, opted in per type",
}
十二个月的弃用窗口,是给你排期用的

十二个月的弃用窗口,是给你排期用的

五、你的迁移清单

把上面这些落成动作:一,升级到说 2026-07-28 的一级 SDK(TypeScript、Python、Go、C#;Rust 处于 beta);二,移除对 Mcp-Session-Id 的依赖,需要连续性就返回显式 handle;三,在每次 Streamable HTTP 请求上输出 Mcp-Method 与 Mcp-Name;四,在列表与读取响应里发布 ttlMs 与 cacheScope;五,验证 iss、从 DCR 迁向 CIMD、把凭据限定在单一签发方;六,在十二个月窗口内迁离 Roots、Sampling、Logging 与 HTTP+SSE;七,如果有长任务,用 tasks 扩展而不是长期挂住连接。官方给出的规模数字说明了紧迫性:一级 SDK 每月下载量接近 5 亿次,TypeScript 与 Python SDK 均已跨过累计 10 亿次下载。

{
  "migration_checklist_mcp_server": {
    "sdk": "upgrade to a Tier 1 SDK that speaks 2026-07-28 (TypeScript, Python, Go, C#); Rust is in beta",
    "sessions": "remove reliance on Mcp-Session-Id; if you need continuity, return an explicit handle",
    "headers": "emit Mcp-Method and Mcp-Name on every streamable HTTP request so gateways can route",
    "caching": "publish ttlMs and cacheScope on list and read responses",
    "auth": "validate iss, move off DCR towards CIMD, scope credentials to one issuer",
    "deprecated_surfaces": "migrate off Roots, Sampling, Logging and HTTP+SSE inside the twelve-month window",
    "tasks": "if you run long jobs, adopt the tasks extension instead of holding a stream open"
  },
  "why_now": "SDK downloads are running at roughly half a billion per month; the ecosystem is already moving"
}

📌 常见问题 FAQ

2026-07-28 版规范最重要的改动是什么?

据官方博客,核心是把 MCP 从双向有状态协议改造为请求/响应式无状态协议:取消 initialize/initialized 握手与 Mcp-Session-Id,每个请求自带协议版本、客户端身份与能力,并新增可选的 server/discover RPC。

头部路由和缓存具体改了什么?

Streamable HTTP 请求必须包含 Mcp-Method 与 Mcp-Name,便于网关路由与计量;tools/list、prompts/list、resources/list 与 resources/read 的响应新增 ttlMs 与 cacheScope,并采用确定性顺序,便于客户端缓存工具目录并稳定上游 prompt 缓存。

哪些能力被弃用了?

Roots、Sampling、Logging 与旧版 HTTP+SSE 传输被标记为弃用,仍可使用但至少保留十二个月(新版确立了最短十二个月的正式弃用政策);Dynamic Client Registration 也被弃用,转向 Client ID Metadata Documents(CIMD)。

AGNTCon + MCPCon 是什么?由谁组织?

由 Agentic AI Foundation(AAIF,Linux 基金会旗下)组织。旗舰活动为 AGNTCon + MCPCon Europe(2026 年 9 月 17-18 日,阿姆斯特丹)与 AGNTCon + MCPCon North America(2026 年 10 月 22-23 日,圣何塞),另有全球 MCP Dev Summit 系列。

迁移成本大吗?SDK 情况如何?

官方表示存在一定迁移成本,尤其是依赖会话标识符的开发者,但已根据早期测试反馈做了优化。四个一级 SDK(TypeScript、Python、Go、C#)在发布当日即支持 2026-07-28,Rust 处于 beta。