2026 年 7 月 28 日Anthropic 发布了 Model Context ProtocolMCP的第五版规范2026-07-28。官方将其定义为自协议发布以来最大的一次修订——这不是营销话术新规范移除了会话握手、删除了三个核心特性、重写了授权模型并引入了扩展框架。同一天GitHub 宣…这件事的分量在于数字MCP 月 SDK 下载量已突破 4 亿年内翻了 4 倍。当一个协议的下载量达到这个量级它就不再是Claude 生态的私有协议而变成了整个 AI 编程行业的事实标准。Claude Code、Cursor、Copilot、Gemini 都开始说同一种协议语言。但这次改版的核心不是用的人多了而是协议本身做了一次结构性减法。本文拆解这次改版的三处关键架构决策——无状态内核、扩展框架、认证硬化——并给出可执行的迁移路径。所有事实均来自官方规范、SEP 提案与权威分析交叉验证。一、无状态内核为什么必须干掉会话1.1 旧模型在分布式环境下崩塌2025-11-25版本的 MCP 是为单个 AI 应用连接一个本地进程设计的客户端打开连接执行initialize/initialized握手双方在整个会话周期内记住彼此。会话由Mcp-Session-Id头部追踪。这个模型在单机环境下没问题但一旦你把 MCP 服务部署到负载均衡器后面、Kubernetes 集群里、或跨多个云区域有状态就成了瓶颈三个问题会叠加放大负载均衡失效客户端被钉在持有其会话的那个实例上标准轮询负载均衡器无法分发流量必须引入粘性会话或共享会话存储。连接脆弱一个中断的 SSE 流意味着整个会话状态丢失客户端需要复杂的重连和重新初始化逻辑。协议啰嗦维护长会话带来大量保活开销即使没有实际工作发生。2026-07-28用六个规范增强提案SEP把内核改成了无状态请求/响应模型。设计哲学是按需付费的复杂性默认无状态只有当某个特性显式需要时才引入状态。官方在发布说明中强调这是 2025 年 12 月《MCP 传输未来》一文中规划方向的实际落地。1.2 握手与会话头被移除initialize/initialized握手被移除SEP-2575。协议版本、客户端身份、能力标志现在通过每个请求的_meta对象携带。Mcp-Session-Id头部也被移除SEP-2567——这是运维影响最大的改动远程 MCP 服务此前需要的粘性会话、共享会话存储、网关深度包检测都不再必要。对比旧版与新版的一次工具调用。旧版2025-11-25需要两步且第二步被钉在固定实例# 第一步初始化获取会话ID POST /mcp HTTP/1.1 Content-Type: application/json {jsonrpc:2.0,id:1,method:initialize, params:{protocolVersion:2025-11-25,capabilities:{}, clientInfo:{name:my-app,version:1.0}}} 服务端响应 Mcp-Session-Id: 1868a90c-3a3f-4f5b 第二步每次后续请求必须携带会话ID客户端被钉在该实例上 POST /mcp HTTP/1.1 Mcp-Session-Id: 1868a90c-3a3f-4f5b Content-Type: application/json {jsonrpc:2.0,id:2,method:tools/call, params:{name:search,arguments:{q:otters}}}新版2026-07-28是一次自包含请求任何实例都能处理POST /mcp HTTP/1.1 MCP-Protocol-Version: 2026-07-28 Mcp-Method: tools/call Mcp-Name: search Content-Type: application/json {jsonrpc:2.0,id:1,method:tools/call, params:{name:search,arguments:{q:otters}, _meta:{io.modelcontextprotocol/clientInfo: {name:my-app,version:1.0}}}}注意新增的Mcp-Method和Mcp-Name头部SEP-2243——它们让负载均衡器和网关无需解析 JSON body 就能按操作路由流量服务端会拒绝头部与 body 不一致的请求。配合列表与资源读取结果新增的ttlMs和cacheScope字段SEP-2549借鉴 HTTPCache-Control客户端能精确知道tools/list响应的新鲜期长连接 SSE 不再是感知列表变更的唯一途径。1.3 无状态协议有状态应用一个常见疑问是我的服务需要跨多次工具调用追踪状态没有会话怎么行答案与 HTTP API 几十年来的做法一致显式句柄。服务端从一个工具调用中铸造一个标识符basket_id、browser_id、workflow_id作为结果返回模型在后续调用中把这个标识符作为普通参数传回1. 客户端调用: create_checkout({items: [widget-a, widget-b]}) 服务端返回: {basket_id: bsk_8f3a, status: created} 客户端调用: add_shipping(basket_id: bsk_8f3a, address: {...}) 服务端返回: {basket_id: bsk_8f3a, status: ready_to_pay} 客户端调用: confirm_order({basket_id: bsk_8f3a}) 服务端返回: {order_id: ord_91cb, status: confirmed}这不仅是权宜之计往往比隐藏的会话状态更好。模型可以对句柄进行推理、跨工具组合、在工作流步骤间传递——而这些是传输元数据里隐藏的会话状态永远做不到的。协议不再替你管理状态但也不阻止你自己管理。官方维护者在发布说明中明确指出把状态对模型可见而非隐藏在传输元数据中是更强大的模式。二、扩展框架让协议插件化内核变瘦后高级行为被建模为扩展——可选的、自包含的模块客户端和服务端可独立采用。扩展获得反向 DNS 标识符、独立仓库、委托维护者版本独立于主规范演进SEP-2133。本次随候选版发布两个官方扩展。2.1 MCP Apps服务端渲染的交互式 UI旧版 MCP 工具只返回结构化数据JSON、文本、资源 URI。用户需要与这些数据交互探索仪表盘、填表单、审阅文档时客户端要自己搭 UI——每个客户端搭得都不一样或干脆不搭。MCP AppsSEP-1865允许服务端声明交互式 HTML 界面宿主在沙箱 iframe中渲染。架构有三个组件声明服务端注册工具通过_meta.ui.resourceUri指向ui://资源。工具提前声明 UI 模板宿主可在运行前预取、缓存并做安全审查。渲染工具被调用时宿主在会话内的沙箱 iframe 中渲染 HTML/JS。沙箱阻止 UI 访问宿主页面、Cookie 或容器外的任何东西。双向通信UI 与宿主及通过宿主回到服务端通过postMessage上的 JSON-RPC 通信。用户在 UI 中的操作触发服务端逻辑服务端更新推送回 UI无需重新加载 iframe。关键在于每个 UI 发起的动作都走与直接工具调用相同的审计与同意路径。这是把 MCP 从开发者集成层变成面向用户生态的基础原语。若宿主不支持 MCP Apps服务端可回退为返回纯文本或结构化数据工具依然可用。2.2 Tasks长任务的持久化生命周期旧版工具调用是同步的客户端发请求服务端处理返回结果。如果操作需要几分钟CI/CD 流水线、批量数据迁移、复杂分析连接可能超时。每个需要异步行为的服务端都得自己发明轮询机制。Tasks 扩展引入标准化的异步模式围绕无状态模型重新设计任务创建服务端不再阻塞返回CreateTaskResult含唯一taskId、初始状态、建议轮询间隔。任务创建由服务端主导客户端声明支持扩展服务端决定某次调用是否应作为任务运行。轮询客户端调用tasks/get检查进度状态包括working、input_required、completed、failed、cancelled。中途交互任务进入input_required如部署流水线等待人工审批时客户端通过tasks/update发送输入实现单任务内多步交互工作流。取消客户端可请求取消服务端在可能时尊重它。终态任务到达completed/failed/cancelled后不可变结果或错误详情可在终态对象上获取。任务句柄设计为可承受连接中断——客户端断开重连后可用同一个taskId继续轮询。需要注意的是tasks/list端点被移除因为它在没有会话的情况下无法安全地做作用域限定。任何在2025-11-25实验性 Tasks API 上构建的实现都需迁移到新生命周期。三、认证硬化从能用到企业可用旧版 MCP 的认证是自带令牌式的企业环境中常处于安全合规的灰色地带。2026-07-28把授权对齐到 OAuth 2.1 和 OpenID Connect使其真正企业级可用。六个 SEP 共同硬化授权规范改动SEP解决的问题客户端必须按 RFC 9207 验证iss参数SEP-2468防止单客户端多服务端场景下的混淆攻击客户端注册时声明application_typeSEP-837避免桌面/CLI 客户端被默认为 web 而拒绝 localhost 回调凭证绑定到授权服务器 issuer资源迁移时重新注册SEP-2352防止跨授权服务器的凭证混用文档化 refresh token 请求方式SEP-2207旧版 refresh token 行为未定义各实现各异阐明 step-up 授权时的 scope 累积SEP-2350渐进式权限请求更可控Resource IndicatorsRFC 8707直接解决了混淆代理问题客户端请求令牌时必须指定令牌目标 MCP 服务端为服务端 A 颁发的令牌无法对服务端 B 重放——这在协议层强制而非依赖应用层检查。更值得关注的是 Enterprise-Managed AuthorizationEMA扩展IT 管理员可通过身份提供商集中配置 MCP 服务端访问权限用户登录时自动连接所需服务端无需逐应用 OAuth 弹窗。这是对企业级反馈的直接回应——很多组织无法在不掌控员工连哪些服务端的情况下采用 MCP。四、治理与迁移12 个月废弃窗口4.1 正式废弃策略2026-07-28引入正式的特性生命周期策略SEP-2596任何标记废弃的特性必须保持功能至少 12 个月才能移除废弃特性记录在公共注册表中并有明确时间线。这是 MCP 首次拥有结构化的规范演进流程。本次三个核心特性被标记废弃SEP-2577最早 2027 年 7 月 28 日后移除特性废弃原因迁移路径Roots文件系统假设不适用于远程/云环境作为工具参数或服务端配置传递路径Sampling服务端反向调用客户端 LLM复杂化信任边界服务端直接对接 LLM 提供商 APILogging协议级日志非标准化stdio 用 stderrHTTP 用 OpenTelemetry这是注解式废弃——方法、类型和能力标志在本版本及此后一年内发布的所有规范版本中继续工作移除任一特性都需在生命周期策略下走单独 SEP。此外Standards Track SEP 在有匹配场景进入一致性套件前不得达到 Final 状态SEP-2484与新的 SDK 分级系统共同保证实现质量。4.2 迁移清单如果你在生产环境运行 MCP 服务端按官方建议执行迁移检查会话依赖找出所有基于Mcp-Session-Id存取状态的位置替换为显式句柄。负载均衡器上的粘性路由可在迁移完成后移除。更新授权实现若接受未认证连接现在是接入 OAuth 2.1 的时机。服务端需暴露.well-known/oauth-protected-resource端点或通过WWW-Authenticate头携带resource_metadata。使用 Dynamic Client Registration 的需规划迁移到 Client ID Metadata Documents。更新工具 schema规范现支持完整 JSON Schema 2020-12SEP-2106允许oneOf/anyOf/$ref组合输出 schema 不再受限。更新客户端每个请求须携带MCP-Protocol-Version、Mcp-Method、Mcp-Name头部initialize握手已移除用server/discover获取能力令牌请求须包含 Resource Indicators。测试多实例部署在轮询负载均衡器后部署多个实例跑测试套件任何失败的测试都指向一个漏掉的会话依赖。检查错误码缺失资源的错误码从 MCP 自定义的-32002改为 JSON-RPC 标准的-32602Invalid ParamsSEP-2164按字面值匹配错误码的客户端需更新。局限性本文基于2026-07-28候选版规范分析部分被描述为强制/移除/最终的细节仍需对照 7 月 28 日正式版核实。以下几点值得注意无状态内核解决了传输层与会话管理问题但未定义如何信任外部数据协议规定了数据怎么传却没规定如何判断服务端返回的数据可信。Agent 通过完美协议连上数据库、却被返回内容里的恶意指令操纵的风险仍需上层防护。Mcp-Method/Mcp-Name头部让网关路由更便捷但未提供协议级的速率限制与配额标准仍需基础设施层补充。EMA 扩展虽回应了企业集中管控诉求但其具体实现细节依赖身份提供商支持落地成本在异构 IdP 环境下未经验证。本文未对迁移后的性能做基准测试标准轮询负载均衡可用是规范设计目标而非实测结论。结论MCP2026-07-28的价值不在新增了多少特性而在于它做了一次结构性的减法把会话从协议层剥离让 AI Agent 的工具调用能跑在标准 HTTP 基础设施上。这与 HTTP 当年标准化推动上层应用繁荣的逻辑一致——不是因为技术多先进而是因为它形成了所有人说同一种语言的网络效应。对开发者而言一个新基础设施层正在形成二十年前你需要懂 HTTP 才能做 Web 开发不久后你可能需要懂 MCP 才能做 Agent 开发。本次改版的迁移窗口已经打开建议在正式版发布后尽快验证多实例部署移除粘性路由把状态从传输层迁移到应用层显式句柄。Intuit、Figma、Block、Apollo 等公司已基于 MCP 构建生产级产品当头部玩家用你的协议定义下一代数据流时标准便已锁定。相关可视化与工程实践项目含交互式 SVG 实验室已开源https://github.com/wangzifan396-wzf/TW
拆解 MCP 2026-07-28：AI Agent 协议为何放弃会话、走向无状态内核
2026 年 7 月 28 日Anthropic 发布了 Model Context ProtocolMCP的第五版规范2026-07-28。官方将其定义为自协议发布以来最大的一次修订——这不是营销话术新规范移除了会话握手、删除了三个核心特性、重写了授权模型并引入了扩展框架。同一天GitHub 宣…这件事的分量在于数字MCP 月 SDK 下载量已突破 4 亿年内翻了 4 倍。当一个协议的下载量达到这个量级它就不再是Claude 生态的私有协议而变成了整个 AI 编程行业的事实标准。Claude Code、Cursor、Copilot、Gemini 都开始说同一种协议语言。但这次改版的核心不是用的人多了而是协议本身做了一次结构性减法。本文拆解这次改版的三处关键架构决策——无状态内核、扩展框架、认证硬化——并给出可执行的迁移路径。所有事实均来自官方规范、SEP 提案与权威分析交叉验证。一、无状态内核为什么必须干掉会话1.1 旧模型在分布式环境下崩塌2025-11-25版本的 MCP 是为单个 AI 应用连接一个本地进程设计的客户端打开连接执行initialize/initialized握手双方在整个会话周期内记住彼此。会话由Mcp-Session-Id头部追踪。这个模型在单机环境下没问题但一旦你把 MCP 服务部署到负载均衡器后面、Kubernetes 集群里、或跨多个云区域有状态就成了瓶颈三个问题会叠加放大负载均衡失效客户端被钉在持有其会话的那个实例上标准轮询负载均衡器无法分发流量必须引入粘性会话或共享会话存储。连接脆弱一个中断的 SSE 流意味着整个会话状态丢失客户端需要复杂的重连和重新初始化逻辑。协议啰嗦维护长会话带来大量保活开销即使没有实际工作发生。2026-07-28用六个规范增强提案SEP把内核改成了无状态请求/响应模型。设计哲学是按需付费的复杂性默认无状态只有当某个特性显式需要时才引入状态。官方在发布说明中强调这是 2025 年 12 月《MCP 传输未来》一文中规划方向的实际落地。1.2 握手与会话头被移除initialize/initialized握手被移除SEP-2575。协议版本、客户端身份、能力标志现在通过每个请求的_meta对象携带。Mcp-Session-Id头部也被移除SEP-2567——这是运维影响最大的改动远程 MCP 服务此前需要的粘性会话、共享会话存储、网关深度包检测都不再必要。对比旧版与新版的一次工具调用。旧版2025-11-25需要两步且第二步被钉在固定实例# 第一步初始化获取会话ID POST /mcp HTTP/1.1 Content-Type: application/json {jsonrpc:2.0,id:1,method:initialize, params:{protocolVersion:2025-11-25,capabilities:{}, clientInfo:{name:my-app,version:1.0}}} 服务端响应 Mcp-Session-Id: 1868a90c-3a3f-4f5b 第二步每次后续请求必须携带会话ID客户端被钉在该实例上 POST /mcp HTTP/1.1 Mcp-Session-Id: 1868a90c-3a3f-4f5b Content-Type: application/json {jsonrpc:2.0,id:2,method:tools/call, params:{name:search,arguments:{q:otters}}}新版2026-07-28是一次自包含请求任何实例都能处理POST /mcp HTTP/1.1 MCP-Protocol-Version: 2026-07-28 Mcp-Method: tools/call Mcp-Name: search Content-Type: application/json {jsonrpc:2.0,id:1,method:tools/call, params:{name:search,arguments:{q:otters}, _meta:{io.modelcontextprotocol/clientInfo: {name:my-app,version:1.0}}}}注意新增的Mcp-Method和Mcp-Name头部SEP-2243——它们让负载均衡器和网关无需解析 JSON body 就能按操作路由流量服务端会拒绝头部与 body 不一致的请求。配合列表与资源读取结果新增的ttlMs和cacheScope字段SEP-2549借鉴 HTTPCache-Control客户端能精确知道tools/list响应的新鲜期长连接 SSE 不再是感知列表变更的唯一途径。1.3 无状态协议有状态应用一个常见疑问是我的服务需要跨多次工具调用追踪状态没有会话怎么行答案与 HTTP API 几十年来的做法一致显式句柄。服务端从一个工具调用中铸造一个标识符basket_id、browser_id、workflow_id作为结果返回模型在后续调用中把这个标识符作为普通参数传回1. 客户端调用: create_checkout({items: [widget-a, widget-b]}) 服务端返回: {basket_id: bsk_8f3a, status: created} 客户端调用: add_shipping(basket_id: bsk_8f3a, address: {...}) 服务端返回: {basket_id: bsk_8f3a, status: ready_to_pay} 客户端调用: confirm_order({basket_id: bsk_8f3a}) 服务端返回: {order_id: ord_91cb, status: confirmed}这不仅是权宜之计往往比隐藏的会话状态更好。模型可以对句柄进行推理、跨工具组合、在工作流步骤间传递——而这些是传输元数据里隐藏的会话状态永远做不到的。协议不再替你管理状态但也不阻止你自己管理。官方维护者在发布说明中明确指出把状态对模型可见而非隐藏在传输元数据中是更强大的模式。二、扩展框架让协议插件化内核变瘦后高级行为被建模为扩展——可选的、自包含的模块客户端和服务端可独立采用。扩展获得反向 DNS 标识符、独立仓库、委托维护者版本独立于主规范演进SEP-2133。本次随候选版发布两个官方扩展。2.1 MCP Apps服务端渲染的交互式 UI旧版 MCP 工具只返回结构化数据JSON、文本、资源 URI。用户需要与这些数据交互探索仪表盘、填表单、审阅文档时客户端要自己搭 UI——每个客户端搭得都不一样或干脆不搭。MCP AppsSEP-1865允许服务端声明交互式 HTML 界面宿主在沙箱 iframe中渲染。架构有三个组件声明服务端注册工具通过_meta.ui.resourceUri指向ui://资源。工具提前声明 UI 模板宿主可在运行前预取、缓存并做安全审查。渲染工具被调用时宿主在会话内的沙箱 iframe 中渲染 HTML/JS。沙箱阻止 UI 访问宿主页面、Cookie 或容器外的任何东西。双向通信UI 与宿主及通过宿主回到服务端通过postMessage上的 JSON-RPC 通信。用户在 UI 中的操作触发服务端逻辑服务端更新推送回 UI无需重新加载 iframe。关键在于每个 UI 发起的动作都走与直接工具调用相同的审计与同意路径。这是把 MCP 从开发者集成层变成面向用户生态的基础原语。若宿主不支持 MCP Apps服务端可回退为返回纯文本或结构化数据工具依然可用。2.2 Tasks长任务的持久化生命周期旧版工具调用是同步的客户端发请求服务端处理返回结果。如果操作需要几分钟CI/CD 流水线、批量数据迁移、复杂分析连接可能超时。每个需要异步行为的服务端都得自己发明轮询机制。Tasks 扩展引入标准化的异步模式围绕无状态模型重新设计任务创建服务端不再阻塞返回CreateTaskResult含唯一taskId、初始状态、建议轮询间隔。任务创建由服务端主导客户端声明支持扩展服务端决定某次调用是否应作为任务运行。轮询客户端调用tasks/get检查进度状态包括working、input_required、completed、failed、cancelled。中途交互任务进入input_required如部署流水线等待人工审批时客户端通过tasks/update发送输入实现单任务内多步交互工作流。取消客户端可请求取消服务端在可能时尊重它。终态任务到达completed/failed/cancelled后不可变结果或错误详情可在终态对象上获取。任务句柄设计为可承受连接中断——客户端断开重连后可用同一个taskId继续轮询。需要注意的是tasks/list端点被移除因为它在没有会话的情况下无法安全地做作用域限定。任何在2025-11-25实验性 Tasks API 上构建的实现都需迁移到新生命周期。三、认证硬化从能用到企业可用旧版 MCP 的认证是自带令牌式的企业环境中常处于安全合规的灰色地带。2026-07-28把授权对齐到 OAuth 2.1 和 OpenID Connect使其真正企业级可用。六个 SEP 共同硬化授权规范改动SEP解决的问题客户端必须按 RFC 9207 验证iss参数SEP-2468防止单客户端多服务端场景下的混淆攻击客户端注册时声明application_typeSEP-837避免桌面/CLI 客户端被默认为 web 而拒绝 localhost 回调凭证绑定到授权服务器 issuer资源迁移时重新注册SEP-2352防止跨授权服务器的凭证混用文档化 refresh token 请求方式SEP-2207旧版 refresh token 行为未定义各实现各异阐明 step-up 授权时的 scope 累积SEP-2350渐进式权限请求更可控Resource IndicatorsRFC 8707直接解决了混淆代理问题客户端请求令牌时必须指定令牌目标 MCP 服务端为服务端 A 颁发的令牌无法对服务端 B 重放——这在协议层强制而非依赖应用层检查。更值得关注的是 Enterprise-Managed AuthorizationEMA扩展IT 管理员可通过身份提供商集中配置 MCP 服务端访问权限用户登录时自动连接所需服务端无需逐应用 OAuth 弹窗。这是对企业级反馈的直接回应——很多组织无法在不掌控员工连哪些服务端的情况下采用 MCP。四、治理与迁移12 个月废弃窗口4.1 正式废弃策略2026-07-28引入正式的特性生命周期策略SEP-2596任何标记废弃的特性必须保持功能至少 12 个月才能移除废弃特性记录在公共注册表中并有明确时间线。这是 MCP 首次拥有结构化的规范演进流程。本次三个核心特性被标记废弃SEP-2577最早 2027 年 7 月 28 日后移除特性废弃原因迁移路径Roots文件系统假设不适用于远程/云环境作为工具参数或服务端配置传递路径Sampling服务端反向调用客户端 LLM复杂化信任边界服务端直接对接 LLM 提供商 APILogging协议级日志非标准化stdio 用 stderrHTTP 用 OpenTelemetry这是注解式废弃——方法、类型和能力标志在本版本及此后一年内发布的所有规范版本中继续工作移除任一特性都需在生命周期策略下走单独 SEP。此外Standards Track SEP 在有匹配场景进入一致性套件前不得达到 Final 状态SEP-2484与新的 SDK 分级系统共同保证实现质量。4.2 迁移清单如果你在生产环境运行 MCP 服务端按官方建议执行迁移检查会话依赖找出所有基于Mcp-Session-Id存取状态的位置替换为显式句柄。负载均衡器上的粘性路由可在迁移完成后移除。更新授权实现若接受未认证连接现在是接入 OAuth 2.1 的时机。服务端需暴露.well-known/oauth-protected-resource端点或通过WWW-Authenticate头携带resource_metadata。使用 Dynamic Client Registration 的需规划迁移到 Client ID Metadata Documents。更新工具 schema规范现支持完整 JSON Schema 2020-12SEP-2106允许oneOf/anyOf/$ref组合输出 schema 不再受限。更新客户端每个请求须携带MCP-Protocol-Version、Mcp-Method、Mcp-Name头部initialize握手已移除用server/discover获取能力令牌请求须包含 Resource Indicators。测试多实例部署在轮询负载均衡器后部署多个实例跑测试套件任何失败的测试都指向一个漏掉的会话依赖。检查错误码缺失资源的错误码从 MCP 自定义的-32002改为 JSON-RPC 标准的-32602Invalid ParamsSEP-2164按字面值匹配错误码的客户端需更新。局限性本文基于2026-07-28候选版规范分析部分被描述为强制/移除/最终的细节仍需对照 7 月 28 日正式版核实。以下几点值得注意无状态内核解决了传输层与会话管理问题但未定义如何信任外部数据协议规定了数据怎么传却没规定如何判断服务端返回的数据可信。Agent 通过完美协议连上数据库、却被返回内容里的恶意指令操纵的风险仍需上层防护。Mcp-Method/Mcp-Name头部让网关路由更便捷但未提供协议级的速率限制与配额标准仍需基础设施层补充。EMA 扩展虽回应了企业集中管控诉求但其具体实现细节依赖身份提供商支持落地成本在异构 IdP 环境下未经验证。本文未对迁移后的性能做基准测试标准轮询负载均衡可用是规范设计目标而非实测结论。结论MCP2026-07-28的价值不在新增了多少特性而在于它做了一次结构性的减法把会话从协议层剥离让 AI Agent 的工具调用能跑在标准 HTTP 基础设施上。这与 HTTP 当年标准化推动上层应用繁荣的逻辑一致——不是因为技术多先进而是因为它形成了所有人说同一种语言的网络效应。对开发者而言一个新基础设施层正在形成二十年前你需要懂 HTTP 才能做 Web 开发不久后你可能需要懂 MCP 才能做 Agent 开发。本次改版的迁移窗口已经打开建议在正式版发布后尽快验证多实例部署移除粘性路由把状态从传输层迁移到应用层显式句柄。Intuit、Figma、Block、Apollo 等公司已基于 MCP 构建生产级产品当头部玩家用你的协议定义下一代数据流时标准便已锁定。相关可视化与工程实践项目含交互式 SVG 实验室已开源https://github.com/wangzifan396-wzf/TW
