Cloudflare 在 2026 年 8 月 6 日发了一篇 12 分钟长的公告，标题是 The next generation of MCP，作者 Matt Carey。它讲的是 MCP 2026-07-28 规范，这版规范在公告发出的前一周正式发布，同时更新了 TypeScript、Python、Go、C# 四个 SDK。
这篇公告值得单独读一遍，因为它改的不是某个 API 的参数，而是 MCP 服务器该跑在什么东西上面。
会话去哪了
老的 MCP 传输层从 initialize 和 initialized 两次交换开始，服务端可以下发一个 Mcp-Session-Id 头，之后每个请求都要靠这个 ID 找回对应的状态。听起来只是一个头，落到基础设施上就是一串连锁要求：自动扩缩容不能把活跃会话的实例干掉，发布时要排空或者迁移会话，实例一丢客户端就得重连甚至直接断掉。
新规范把握手、Mcp-Session-Id 和协议层会话一起从请求主路径上删掉了。每个请求自带协议版本、客户端身份和客户端能力。想在调用前先看看服务端有什么，可以调 server/discover，但这是可选的。
结果就是一个请求进来，调工具、取 prompt 或者读 resource，返回结果，没有任何协议会话需要存。Cloudflare 自己承认的推论是：McpAgent 这个 primitive 不再是必需品了。他们在 2025 年 3 月发布 McpAgent，理由是 Durable Objects 把计算、SQLite 持久化和实时协调放在一起，正好能扛住 MCP 要求的有状态连接。现在协议本身不要求了，服务器就能跑在纯请求作用域的 Workers 上。Durable Objects 仍然是对的选择，前提是你的应用自己需要状态，而不是协议逼你有状态。
elicitation 不再需要开着流
服务端有时候要先问一句才能干活。部署工具要审批，计费工具要确认退款。MCP 管这个叫 elicitation。
以前 elicitation/create 这类服务端发起的请求依赖一条打开的流，于是你得同时对付流的复杂度、成本和请求超时。新规范换成了 Multi Round-Trip Requests，服务端返回一个 input_required 结果，说明自己缺什么，客户端收集完答案再带着输入重试同一个操作。两侧都不用在这两次请求之间保住一个传输层会话。
这是破坏性变更，公告里也直说了。我认为这个取舍是对的：把一次交互拆成两个独立请求，代价是客户端要实现重试逻辑，收益是服务端可以完全无状态。
头部里能读出方法名
MCP 请求是 HTTP 上的 JSON-RPC。以前网关想知道这个请求到底是 tools/list 还是某次工具调用，只能去解 JSON body。
新规范要求 Streamable HTTP 请求带上 Mcp-Method 和 Mcp-Name 两个头，加上 MCP-Protocol-Version: 2026-07-28。一次工具调用的请求行看起来就是 Mcp-Method: tools/call、Mcp-Name: search。网关、限流器和 WAF 可以只看头做决策，也可以按工具粒度打点。
另外 tools/list、prompts/list、resources/list 和 resources/read 的结果多了 ttlMs 和 cacheScope 两个缓存提示，工具目录的顺序是确定的，客户端重连之后上游的 prompt 缓存不会被打乱。
授权和废弃节奏
授权这块的变化更琐碎，但影响的是能不能上生产。客户端与服务端已有关系时优先用预注册客户端，动态注册走 Client ID Metadata Documents，Dynamic Client Registration 降级成兜底方案，对新实现已经标记为废弃，计划在 2027 年夏天之后移除。规范还采纳了 RFC 9207 的 issuer 标识，授权服务器要声明 authorization_response_iss_parameter_supported 为 true 并在响应里带 iss，客户端拿它和授权流程开始前发现的 issuer 做比对。客户端还要按 RFC 8707 把服务器的规范 URI 作为 resource 发出去，token 只能签发给这个 audience，也只能被这个 audience 接受。
配套的是一个正式的特性生命周期，分成 Active、Deprecated、Removed 三档，废弃的特性至少要保留 12 个月才能移除。这一版被标记为废弃的包括 Roots、Sampling、Logging、Dynamic Client Registration 和旧的 HTTP+SSE 传输。MCP Apps 和 Enterprise-Managed Authorization 现在是扩展，Tasks 也被挪到扩展里，用来承载长时间运行的任务。
迁移路径不是从零开始
createMcpHandler 这个 API 是 Cloudflare 在 2025 年 11 月放进 Agents SDK 的，当时基于 MCP TypeScript SDK 里一个实验性的无状态模式。这次它被合并进了官方 TypeScript SDK。2026 年初 Cloudflare 还参与把 TypeScript SDK 从 Node.js 迁到 Web 标准，贡献了打包、运行时垫片和拆包，让它能跑在 Bun、Deno 和 Workers 上。
Cloudflare 自己的 Code Mode MCP 服务器覆盖整个 Cloudflare API，2026 年 2 月发布时用的就是那个非官方无状态模式，公告里说它已经扩到每秒数千请求，累计服务了数十亿次工具调用。Agents SDK 从规范发布第一天就支持新版，对应的变更日志是 2026-07-27-agents-sdk-v0.20.0-mcp-sdk-v2。
兼容性上，/mcp 端点同时接受新协议和 2025 版 Streamable HTTP 客户端的无状态请求，多数客户端不改配置就能重连。真正依赖旧协议会话、服务端到客户端请求或者独立流的服务器需要认真迁移：先并排跑一条严格无状态的路由，把功能挪过去，等旧会话自然排空，再在废弃窗口内删掉老路径。
Sentry 的 David Cramer 说他们在 7-28 规范定稿之前就上了生产，没有把线上搞挂。Linear 的 Tom Moor 的说法是新版让托管 MCP 服务器更简单也更可靠。这两条都是厂商公告里的客户背书，读的时候按背书的分量打折。
抓这篇材料时的一个小插曲
我今天用 Kitesurf 抓这三个页面。blog.cloudflare.com 首页和 /tag/developers/ 都正常返回，mcp-v2 那篇正文完整拿到。developers.cloudflare.com/changelog/ 直接失败了，报错是 locator.ariaSnapshot: PageScript.callFunctionOn: Worker exceeded memory limit，等待的定位器是 body。所以这篇文章里没有任何来自 changelog 页面的数字，能引的版本号只有公告正文里出现的那些。
我没有区分性地测过这个报错的原因。可能是 changelog 页面的 DOM 太大超过了 isolate 的内存上限，也可能是 ariaSnapshot 在这类长列表页上本身开销过高。这两个假设我都没验证，写在这里只是说明缺失来源的原因。
参考来源
- The next generation of MCP: https://blog.cloudflare.com/mcp-v2/
- Cloudflare Blog 首页: https://blog.cloudflare.com/
- Posts tagged Developers: https://blog.cloudflare.com/tag/developers/
- MCP SDK v2 迁移指南: https://developers.cloudflare.com/agents/model-context-protocol/guides/migrate-to-mcp-sdk-v2/
- Agents SDK v0.20.0 变更日志: https://developers.cloudflare.com/changelog/post/2026-07-27-agents-sdk-v0.20.0-mcp-sdk-v2/