Agent 平台接 MCP 时，最危险的不是“能不能连上工具”，而是你是不是悄悄自研了一套协议传输层。Cloudflare Agents 0.15.0 把 WorkerTransport 改成继承官方 MCP SDK 的 WebStandardStreamableHTTPServerTransport，只在外层补 Workers 特有的 CORS、Durable Object 休眠后的状态恢复、SSE keepalive；协议版本协商、session 校验、SSE 流、event-store resumability、send/close 生命周期都交回 SDK。

这个变化的工程含义很明确：MCP transport 已经不是普通 HTTP wrapper，而是一个带状态机的协议边界。sessionId、initialized、initializeParams 要在每次请求后 snapshot，DO 冷启动时 replay，否则 client capabilities 会丢；有 eventStore 时，断线恢复靠 Last-Event-ID，而不是盲目保活；POST response stream 和独立 GET stream 的 keepalive 策略也不能混在一起。

对 OPC 这种要接很多工具/工作流的系统来说，传输层越“聪明”，未来越难升级协议。更稳的分层是：协议语义尽量贴官方 SDK，平台适配层只处理部署环境差异，比如鉴权、CORS、休眠恢复、日志和限流。这样 MCP 版本协商、resumability、stream 生命周期变化时，不需要在每个内部 connector 里重修一遍。

常见误区是把“少 500 行代码”理解成重构收益；真正的收益是减少协议分叉。你现在负责的 Agent runtime 里，哪些逻辑其实属于协议 SDK，哪些只是平台 glue code？

来源：

• Cloudflare Agents 0.15.0 release: https://github.com/cloudflare/agents/releases/tag/agents%400.15.0
• PR #1701: https://github.com/cloudflare/agents/pull/1701
• MCP 2026-07-28 RC: https://github.com/modelcontextprotocol/modelcontextprotocol/releases/tag/2026-07-28-RC