枫讯编辑部深度解读 · 依据公开资料整理，资料状态截至 2026-07-29。本文为信息解读，不构成医疗、法律、投资或其他专业建议；最新资料以原始来源为准。
一句话结论
MCP 2026-07-28 把协议核心改为无状态请求/响应模型。它让服务更容易扩容和接入网关，但不会让 AI 自动变聪明；依赖 initialize、Mcp-Session-Id 或长期流式回调的旧系统需要有计划地迁移。
先说清楚：什么变了，什么没变
MCP 让大模型应用连接外部工具、数据和工作流。旧版通常先初始化，再在后续请求中携带会话标识；这适合本地和单进程场景，但多实例部署往往需要粘性会话或共享存储。
新版协议移除了协议级的 initialize / initialized 交换，以及 Mcp-Session-Id 头。每个请求自行带上协议版本、客户端身份和客户端能力；客户端若想预先了解服务器能力，可调用新的 server/discover，但这不再是每次通信的前提。因此，一个请求可落到普通 round-robin 负载均衡器后的任一实例，不必依赖共享会话状态。
这里最容易误读：**协议无状态，不等于业务无状态。**如果工具需要持续处理同一个任务，例如“继续上一次的文档转换”或“读取上一次查询的分页结果”，服务端可以返回一个显式 handle，模型再在下一次工具调用中把 handle 当参数传回。状态没有消失，而是从隐藏在传输会话里，变成可见、可审计、可传递的业务数据。
对个人自动化有什么实际好处？
对只在一台电脑运行的本地脚本或 MCP 服务，短期未必有明显体感。但当服务开始经过反向代理、云端网关，或由多个实例承载时，价值会变得具体：
- 部署更简单：不需要“粘性会话”，请求可由普通负载均衡器分发。
- 故障恢复更好：单个实例重启后，下一次请求可以被另一实例接手；前提是业务所需的 handle 和持久化数据本身设计正确。
- 网关更容易治理：新版 Streamable HTTP 要求
Mcp-Method和Mcp-Name头。网关、限流器和 WAF 可以按工具或方法路由、计量与授权，不必先解析 JSON 请求体。 - 减少重复拉取：工具、提示词和资源清单等响应可以携带
ttlMs与cacheScope缓存提示，客户端能减少不必要的重新发现和读取。
这对“个人自动化”意味着：本地优先的简单 MCP 不必为了追新规范而重写；但如果你要把某个稳定工具公开给多个 AI 客户端、放进企业网关，或在将来迁到多实例运行环境，无状态设计会显著降低架构摩擦。
多轮交互怎么办？MRTR替代长期打开的通道
旧的双向流允许服务端在工具执行中主动向客户端索取用户输入、调用模型采样或读取 roots。新版用 Multi Round-Trip Requests（MRTR）处理同类需求：工具先返回 input_required 和它需要的问题；客户端收集回答后，再带着 inputResponses 重试原调用。
优点是 HTTP 请求不必一直保持打开。代价是实现者要把“暂停—补充输入—继续”的流程设计为可重试、幂等且可超时的工作流。对涉及付款、发邮件、删除数据等操作尤其重要：一次重试绝不能造成重复副作用。
安全性改进，不等于可以放松权限管理
新版加强 OAuth 边界：例如要求按 RFC 9207 校验授权响应中的 issuer，并把客户端凭证绑定到签发它的授权服务器；Dynamic Client Registration（DCR）被标为弃用方向，规范转向 Client ID Metadata Documents（CIMD）。
这些修改能降低一些授权服务器混淆和桌面/CLI 回调问题，但 MCP 仍能连接数据和执行工具。部署者依然要做最小权限、逐工具授权、敏感动作人工确认、日志审计，以及把密钥放在受控环境中。协议升级不能替代这些基本治理。
先别急着升级：截至7月29日的兼容性
现在能确认的是四个 Tier 1 SDK 已支持 2026-07-28，不等于所有 MCP 主机都已默认启用。GitHub 已明确表示 GitHub MCP Server 支持新规范；AWS AgentCore Gateway 也已支持，但采用多版本并存、由客户显式加入新版本的渐进方式。
几个常用个人工具仍要分别看：Codex 0.146.0 的发布记录只写明注册了 MCP 2026-07-28 feature flag，而官方 MCP 使用文档仍提到初始化阶段，因此不能据此宣称所有 Codex 安装已经默认兼容。Claude Code 的公开 changelog 截至本次核验未找到明确的 2026-07-28 支持说明，这只能标为“官方未确认”，不能反推它一定不支持。
对官方尚未明确说明支持状态的其他客户端，不应只看“已安装 MCP”就判定它能连接新版专用服务器。最稳妥的标准是：客户端、服务器和中间网关都通过同一协议版本的端到端测试。
给现有MCP服务的迁移清单
- 盘点是否依赖
initialize、Mcp-Session-Id、sticky session 或长期 SSE 流。 - 将跨请求状态改为显式 handle、数据库记录或可验证的任务ID；不要把状态藏在某台机器的内存会话里。
- 对会产生副作用的工具加入幂等键、确认步骤和可恢复日志。
- 更新或测试 TypeScript、Python、Go、C# SDK；官方称四个 Tier 1 SDK 已支持新版本，但仍要分别验证你使用的客户端和托管平台。
- 为
Mcp-Method/Mcp-Name设置网关路由、限流和授权策略。 - 评估旧 HTTP+SSE、Roots、Sampling、Logging 的迁移。官方给出的正式弃用窗口至少12个月；这不是“今天立刻断掉”，但不宜在新项目继续押注旧接口。
给个人自动化工作流的建议
目前更适合把 MCP 当作边界清晰的工具接口：一个工具只做一类可验证操作，输入输出写清 schema，长期任务返回任务ID，敏感操作仍由人工审核。无需为了“无状态”把本地脚本拆成复杂微服务；只有当工具要被多客户端、多实例或网关统一托管时，再优先按新版架构重构。