对于需要连接外部数据或工具的 AI 应用，MCP 现在值得学习，也适合从低风险场景开始试点。 协议升级还不足以支撑团队直接把付款、生产发布或敏感数据操作迁入关键业务流程。
事实。 2026-07-28 版 MCP 移除协议级会话、Mcp-Session-Id 和初始化握手。每个请求携带协议版本、客户端身份和能力信息；需要跨调用保存状态时，服务端可签发显式句柄，再把句柄作为普通工具参数传递。
这次真正改变了什么
官方变更记录写明：新版本把请求做成自包含，减少服务端为维持协议会话而处理粘性路由、长连接和会话协调的负担。Cloudflare 据此说明，不需要业务协调状态的 MCP 服务可以运行在普通的请求级 Worker 上。
这里有一条边界必须守住。协议无状态，不等于业务无状态。 订单、审批、长任务和用户授权仍要由应用保存、校验和审计。
为什么它开始更像基础设施
新版规范开始处理生产环境关心的细节，包括标准请求头、OpenTelemetry 上下文、确定性列表顺序、缓存提示和明确的弃用周期。这些变化降低网关识别、追踪、缓存与迁移的摩擦，但不会自动替团队完成可观测性或兼容性建设。
与此同时，Cloudflare 把 WebMCP 带到网页侧，让浏览器代理可以发现网站主动暴露的工具。这说明 MCP 的接口形态正在扩展；该能力目前仍是开发者预览，更适合作为方向信号，而不是成熟度证明。
现在该怎么做
可以按风险分三层推进。
- 现在就学。 理解 tools、resources、权限边界和错误模型。
- 小范围试点。 优先选择只读、低权限、可撤回、可人工复核的任务。
- 验证后再进关键业务流程。 至少补齐最小权限、明确确认、审计日志、幂等、失败恢复、降级方案和客户端兼容测试。
官方规范明确提醒，MCP 本身不能在协议层强制落实所有安全原则；用户同意、授权、访问控制和数据保护仍是实现方责任。判断 MCP 是否“可用”，不能只看能否连通，还要看一次错误调用会造成什么后果，以及系统能否发现、阻止和恢复。
判断。 更准确的问题不是“MCP 热不热”，而是要在哪个风险层级接入。生产成熟度最终取决于你的控制面，协议版本只是其中一部分。
限制
- 未在本预览中复测 2026-08-13 之后的规范修订。
- Cloudflare 部署说明是厂商一手资料，不是全行业采用率。
- WebMCP 仍是开发者预览。
- 本篇不是工具评测，也不构成接入或采购建议。
- 内部选题 brief 只用于发现角度，不单独承担外部事实证明。
商业关系
无 affiliate、赞助或赠品。OnBalls 配置里的工具候选账户均未在本篇使用。