MCP 从“能连工具”到“像 Web 一样部署”——无状态核心、扩展框架与企业级 Agent 基础设施的真正分水岭

当一个技术协议开始被拿来类比 HTTP，最容易犯的错误，是只看"连接了多少工具"，而忽略它能否像 HTTP 一样进入普通基础设施、普通安全体系和普通运维流程。MCP 在 2024 年底出现时解决的是一个非常直观的问题：模型需要访问文件、数据库、代码仓库、SaaS 应用和企业内部系统，但每一种 AI 产品都在重复开发自己的连接器。MCP 用 Host、Client、Server 和标准化能力描述，把"模型如何接入外部世界"抽象成一个开放协议。

但**"接口统一"只是第一阶段。真正决定协议能否成为基础设施的，是第二阶段的问题**：服务器如何扩容，网络如何路由，身份如何治理，长任务如何恢复，交互式界面如何安全嵌入，旧能力如何弃用，以及企业是否能把它纳入既有的网关、IAM、审计与可观测体系。

2026-07-28 规范之所以重要，正是因为 MCP 开始集中回答这些问题。它不再只是"给 Agent 一个标准工具接口"，而是在重新定义 Agent 基础设施应该如何被部署和管理。对企业技术负责人而言，这次升级最值得关注的不是某个新 RPC，而是 MCP 的默认架构假设已经改变：协议状态从连接中剥离，请求开始自描述；复杂能力从核心协议中剥离，通过扩展独立演进；身份与授权进一步回到 OAuth/OIDC 和企业 IdP 的成熟轨道；可观测、缓存和路由开始与现有 Web 基础设施对齐。

一、真正的变化不是"多了几个能力"，而是协议的默认世界观变了

（一）五次规范迭代，构成了一条清晰的生产化路线

1、2024-11-05：先解决"有没有统一接口"

MCP 第一版正式规范的关键词是 JSON-RPC、Resources、Prompts、Tools，以及有状态连接。它建立了 Host---Client---Server 的基本边界：Host 是承载 AI 体验的应用，Client 是 Host 内与某个 Server 通信的连接器，Server 则暴露资源和工具。这个抽象非常关键，因为它把原本散落在每个 AI 产品内部的"插件协议"变成了可复用的开放接口。

从产业视角看，第一阶段的价值主要是降低 N×M 集成成本。假设企业内部有 N 个业务系统，外部有 M 个 AI 助手，如果没有公共协议，最坏情况下需要维护 N×M 组适配；有了 MCP，业务系统可以向协议靠拢，AI 产品也向协议靠拢，理论上可以把大量重复工作压缩为 N+M 的连接关系。这个逻辑解释了为什么 MCP 在开发者工具和企业集成场景中传播速度很快：它击中了集成层最直接的重复劳动。

但第一版的"有状态连接"也埋下了后续生产问题。它适合本地进程、桌面工具和开发环境，却并不天然等价于现代云基础设施中的弹性 HTTP 服务。

2、2025-03-26：远程 MCP 开始向 Web 基础设施靠拢

2025 年 3 月的更新加入基于 OAuth 2.1 的授权框架，并以 Streamable HTTP 替换此前的 HTTP+SSE 传输，同时增加工具行为注解等能力。这一版的意义是：MCP 不再只是"本机工具协议"，而开始系统回答远程服务器如何安全暴露、如何通过标准 HTTP 访问的问题。

然而，"使用 HTTP"与"具备 HTTP 原生的无状态部署特征"并不是同一回事。2025 年版本仍保留初始化握手与协议级会话。也就是说，传输层已经进入 HTTP 世界，但生命周期仍带着长连接/会话协议的思维。

3、2025-06-18 与 2025-11-25：生产需求逐渐暴露

2025 年 6 月的规范继续强化结构化工具输出、OAuth Resource Server、安全约束和 elicitation；到 2025 年 11 月，OIDC 发现、增量授权、Tasks 等能力进一步进入规范。尤其是 Tasks 的出现，说明 MCP 已经从"查询和短工具调用"进入"Agent 工作流可能持续数十秒、数分钟甚至更久"的场景。

这时协议面临一个典型成熟期矛盾：**核心协议不断吸收新能力，功能越来越强，但部署、互操作、生命周期和演进成本也随之提高。**如果所有交互都依赖协议级会话，那么负载均衡、故障恢复、弹性扩容、长任务恢复都会与会话绑在一起；如果所有新能力都直接进入核心协议，不同实现之间的兼容压力也会快速上升。

4、2026-07-28：从"协议功能集合"转向"基础设施底座"

第五次正式规范更新直接改写了上述假设。官方将其称为自发布以来最大的修订之一，核心包括：无状态协议核心、Multi Round-Trip Requests（MRTR）、基于 HTTP Header 的路由、可缓存列表结果、授权强化、正式扩展框架、Tasks 扩展化，以及至少 12 个月的弃用窗口。

这组变化放在一起看，逻辑非常一致：核心协议要尽可能稳定、简单、无状态；需要复杂生命周期或垂直能力的部分，通过明确的扩展机制演进；网络基础设施应该能够在不理解 JSON-RPC 业务正文的情况下完成路由、限流和审计；身份系统应该复用企业已经成熟的 OAuth/OIDC 与 IdP 体系。

因此，把 2026-07-28 理解成"又新增 Apps、Tasks 和企业认证"会低估它。它更像一次协议的"云原生化与治理化"。

（二）为什么"无状态"是这次升级的轴心，而不是其中一个功能点

1、此前的痛点不是 HTTP 不够现代，而是会话状态绑住了扩容

在 2025-11-25 版本中，远程 MCP 调用通常先经过 initialize 握手，服务端返回 Mcp-Session-Id，后续请求继续携带这个会话标识。对于单机服务，这很自然；对于多实例生产部署，它意味着负载均衡器要保证后续请求能够回到同一个实例，或者所有实例必须共享会话存储。

于是，一个看似普通的工具服务器会引入额外基础设施：粘性会话、共享状态层、会话过期策略、实例故障后的恢复逻辑，以及围绕会话状态建立的监控与故障排查。Serverless 和边缘运行时的价值恰恰在于实例短暂、弹性、可随请求创建和销毁，而协议级会话与这种运行模型存在天然摩擦。

2、2026-07-28 把连接状态改成请求自描述

新规范移除 initialize/initialized 握手和 Mcp-Session-Id。版本、客户端身份与能力等信息被放入每次请求的 _meta，服务器还提供可选的 server/discover，让客户端在需要时预先发现服务器能力。任何一个请求原则上都可以落到任意一个兼容实例上。

这一步的价值不只是"少一次握手"。它实际上把服务端横向扩展的责任从 MCP 特有的会话机制中释放出来：普通 round-robin 就可以工作；实例可以独立扩缩；无须共享协议会话；故障实例不再天然吞掉某个长期会话的所有后续请求。

2.1 协议无状态，不等于业务无状态

这里最容易产生误解。MCP 取消的是协议级隐藏会话状态，不是禁止应用保存状态。购物篮、浏览器实例、数据库事务、工作流执行等业务场景仍然可以有状态，只是状态要通过显式句柄表达，例如 basket_id、browser_id 或 workflow_id，再由模型或客户端在后续调用中作为普通参数传回。

这种变化把状态从"网络连接背后的隐式上下文"变成"协议消息中可见的业务对象"。可见性会带来几个直接好处：模型可以在多个工具之间传递句柄；日志可以明确记录某个状态对象的生命周期；状态迁移和持久化由业务自行选择；网关不必理解和维护 MCP 专有会话。

2.2 显式状态也意味着企业要重新设计状态安全

无状态核心并不会自动让系统更安全。相反，当状态句柄进入普通工具参数后，企业需要把它视为一种可能敏感的能力凭证或对象引用。句柄是否可猜测、是否绑定用户、是否有过期时间、是否允许跨租户重放，都应由业务服务显式定义。

所以**"去会话"不是消灭状态，而是把状态治理从协议层还给应用层。**对于成熟工程团队，这是利好；对于依赖 SDK 隐式管理生命周期的团队，则意味着需要补上过去被会话机制遮蔽的设计责任。

二、MRTR：没有长连接之后，Agent 仍然可以"中途问你一句"

（一）无状态协议真正难的不是请求，而是反向交互

1、传统工具调用天然适合请求/响应

如果工具调用只是"输入参数---执行---返回结果"，HTTP 无状态非常自然。但 Agent 场景经常更复杂：服务器执行到一半发现缺少信息，需要用户确认删除；工具准备创建云资源，需要展示预计成本；服务器希望调用客户端侧的采样能力；某个步骤需要用户补充字段后才能继续。

旧版可以在持续打开的流上做 server-to-client 请求。但如果目标是让请求可以随时落到任意实例，就不能把关键交互建立在"同一条连接永远还在"这个假设上。

2、MRTR 把"服务器反向请求"重构成可重试的多轮请求

Multi Round-Trip Requests 的核心思想是：服务器不必保持一条双向通道等客户端回复，而是返回 resultType: "input_required"，同时说明还需要哪些输入。客户端收集用户答案后，重新发起原始请求，并把 inputResponses 与 requestState 一起带回。

从分布式系统角度看，这相当于把"等待中的连接状态"转化成"可序列化的工作状态"。第二轮请求可以被另一个实例处理，因为恢复执行所需的信息已经进入消息本身。

（二）MRTR 对人机协作的意义比技术细节更大

1、它把"审批点"变成协议的一等公民

企业 Agent 真正难规模化的地方，不是让模型多调用几个 API，而是如何在高风险操作前稳定插入审批。删除数据、转账、发布配置、创建高成本资源、访问敏感信息，都需要"人仍然掌握关键决策权"。

MRTR 让这类交互不再依赖客户端和服务器之间的私有长连接实现。一个工具可以明确告诉客户端："我需要一个确认、一个字段或一个授权升级才能继续。"客户端则可以用自己的 UI、移动端审批、桌面弹窗或其他交互收集答案，再恢复原请求。

2、它也为断点续作和跨设备交互留下空间

**规范本身并不自动提供完整工作流引擎，但 MRTR 的结构天然适合"暂停---收集输入---恢复"。**如果再与 Tasks 的持久任务句柄结合，一个长任务可以先返回 task handle，运行到高风险步骤时要求输入，再继续执行。

这意味着 MCP 开始具备一种更适合企业流程的组合能力：短调用保持 HTTP 简单性，长任务由 Tasks 管理生命周期，中途人机交互由 MRTR 表达。 这三者组合后，很多此前需要专门 Agent 编排协议才能实现的流程，可以在统一连接层之上完成。

三、路由、缓存与可观测：MCP 开始服从"普通 Web 运维"的规则

（一）Header-based Routing 让网关不必解析 JSON-RPC 正文

1、`Mcp-Method` 与 `Mcp-Name` 把业务意图暴露给基础设施

2026-07-28 要求 Streamable HTTP 请求携带 Mcp-Method 和 Mcp-Name 等标准头。网关、WAF、API Gateway、限流器因此可以直接根据"这是 tools/call""调用的是哪个工具"进行策略判断，而不需要解包 JSON-RPC body。

这件事看起来很小，但对企业平台团队非常重要。大型组织不会允许所有工具调用绕过统一网关直接进入业务服务。它们需要按工具名做权限、配额、成本统计、灰度、阻断与审计。如果每个中间层都要理解 MCP 的 JSON 结构，基础设施团队就必须维护一套专用解析逻辑；Header 化之后，MCP 流量更像普通 HTTP API。

2、策略可以从"服务器代码"上移到"基础设施层"

例如企业可以在网关层定义：search 工具允许高并发，delete_customer 工具必须来自特定客户端身份；某个高成本模型工具每用户每分钟只能调用两次；某类财务工具只允许工作日执行。因为方法与工具名进入头部，这些策略可以更早地生效。

这也是 MCP 从"开发者接口"走向"平台接口"的标志：真正的企业协议必须让安全、SRE、FinOps 和治理团队参与，而不只是让应用开发者能调用成功。

（二）Cacheable Results 解决的是 Agent 场景中被忽视的"目录成本"

1、工具目录本身也会消耗网络、计算与模型上下文

在 Agent 系统中，tools/list、resources/list 等列表经常被重复获取。工具数量一多，重复拉取不仅浪费服务器资源，还会让客户端频繁重建工具描述，甚至影响上游 Prompt Cache 的稳定性。

新规范为多个列表和资源读取结果加入 ttlMs 与 cacheScope。客户端因此能知道结果可以缓存多久，以及是否可被共享缓存。官方还要求工具列表尽量保持确定性顺序，这对模型提示缓存尤其重要：内容相同但顺序不断变化，会造成不必要的缓存失效。

2、缓存语义意味着 MCP 开始关心"规模下的总成本"

协议早期最关注功能正确性；成熟协议更关注重复请求、缓存命中、负载峰值、可预测性能。对大型企业来说，100 个员工调用一个 MCP Server 与 10 万个 Agent 同时发现工具目录，完全是两种工程问题。

因此，缓存提示不是锦上添花，而是 MCP 从"能工作"向"在大规模并发下经济地工作"迈出的一步。

（三）OpenTelemetry 语义让一次 Agent 行为可以跨系统追踪

1、Agent 故障往往跨越 Host、Client、Server 与下游 API

传统应用的一次请求可能只经过浏览器、API、数据库；Agent 的一次操作可能先经过 Host 的推理逻辑，再经过 MCP Client，进入 MCP Server，继续调用多个 SaaS API、数据库、搜索服务和模型供应商。没有统一 Trace Context 时，"为什么这个 Agent 花了 18 秒""到底哪个工具重试了三次"会非常难回答。

规范明确了 traceparent、tracestate、baggage 等 OpenTelemetry/W3C Trace Context 相关键名的传播方式。这样，一条从用户指令开始的 trace 可以跨越 MCP 边界继续延伸。

2、可观测性会成为 Agent 平台的核心竞争力

未来企业判断一个 Agent 平台是否成熟，很可能不会只问"支持多少模型和工具"，而会问：一次工具调用能否定位到具体用户、具体模型决策、具体 MCP Server、具体下游 API？是否能统计每个工具的成功率和 P95 延迟？是否可以在安全事件发生后还原调用链？是否能把模型成本与业务动作关联？

2026-07-28 没有替企业完成这些治理，但它让协议层不再妨碍这些治理。

四、扩展框架：核心协议开始学会"克制"

（一）为什么扩展机制比新增某一个扩展更重要

1、协议成功之后，最大的风险之一就是核心膨胀

当 MCP 使用场景从 IDE 扩展到设计工具、财务系统、CRM、数据平台和自动化 Agent，不同社区会提出完全不同的诉求：有人需要 UI，有人需要异步任务，有人需要企业身份，还有人需要行业特定合规信息。如果所有需求都进入核心协议，核心会迅速变得庞大，SDK 必须同步实现所有能力，兼容性成本指数级上升。

正式扩展框架提供了一个更成熟的答案：**扩展拥有独立标识、独立协商和独立版本生命周期，Client 与 Server 通过 capabilities 中的 extensions map 明确声明支持。**核心协议因此可以保持较小且稳定，创新能力则在扩展层加速。

2、这相当于给 MCP 建立"内核---模块"边界

可以把它理解为操作系统内核与模块、HTTP 与应用层协议之间的关系：核心负责最普遍、最稳定、最需要互操作的语义；变化快、适用面窄或仍在实验的能力，不必绑架所有实现。

这种结构对标准治理尤其重要。协议真正成熟的标志不是"什么都内置"，而是知道哪些东西不应该进入核心。

（二）MCP Apps：工具不再只返回文本和 JSON

1、交互式 UI 让 MCP 从"调用接口"走向"体验接口"

**MCP Apps 允许 Server 提供交互式 HTML 界面，由 Host 在受限环境中渲染。**工具可以预先声明 UI 模板，使 Host 有机会在执行前预取、缓存和安全审查。UI 发起的动作仍通过 MCP 的 JSON-RPC 路径，因而能够复用同一套审计和用户同意机制。

这会改变很多 Agent 产品的交互方式。过去工具通常只能返回文字、Markdown、图片或结构化 JSON，Host 再自己决定怎么展示；**未来 Server 可以把"最适合这个工具的交互界面"一起交付。**例如数据分析工具返回可筛选图表，审批工具返回表单，设计工具返回可操作画布，视频工具返回播放器。

2、UI 扩展让"连接器"开始携带产品体验

这意味着 MCP Server 的价值边界可能扩大。一个高质量 Server 不再只是 API 适配器，还可以封装领域交互：一个财务 MCP 可以定义预算审批界面，一个数据库 MCP 可以提供查询结果浏览器，一个 CRM MCP 可以提供客户资料卡。

但与此同时，安全面也扩大了。**Server 提供的 UI 本质上是外部内容，Host 必须使用沙箱、内容安全策略、权限边界和明确的用户同意机制。**扩展框架的价值正在这里体现：UI 可以被标准化协商，而不是每个 Host 私下实现一个"插件 iframe"。

（三）Tasks：长期运行任务终于不必伪装成一次长请求

1、Tasks 从实验核心迁移为官方扩展

Tasks 在 2025-11-25 还是实验性核心能力，2026-07-28 则迁移到 io.modelcontextprotocol/tasks 扩展，并围绕无状态模型重新设计。Server 可以返回 task handle，Client 通过 tasks/get 轮询状态，通过 tasks/update 提供后续输入，通过 tasks/cancel 取消。

这个设计符合长任务的真实属性：它是一个有独立生命周期的业务对象，而不是一条"永远别断"的 HTTP 请求。

2、长任务从网络连接中解耦后，可靠性设计更自然

文件批量处理、代码迁移、数据分析、模型训练任务、长时间浏览器自动化，都可能超出普通请求时长。如果任务拥有持久句柄，Client 可以在网络断开后恢复查询，Server 可以把执行转移到队列或后台 worker，任务状态可以落入持久化存储。

换言之，Tasks 与无状态核心并不矛盾。恰恰相反：协议请求是无状态的，任务对象可以是持久的。 这是分布式系统中更清晰的职责划分。

五、企业级认证：MCP 正在从"用户授权"走向"组织治理"

（一）OAuth/OIDC 对齐解决的是互操作，不只是登录

1、授权强化继续围绕成熟标准收敛

本次规范要求更严格地处理 authorization issuer，客户端需要验证 iss；客户端凭据必须绑定签发它的 issuer；Dynamic Client Registration（DCR）被正式标记为弃用方向，Client ID Metadata Documents（CIMD）成为更推荐的注册机制。规范还补充了 OIDC application_type、刷新令牌与发现路径等兼容性细节。

这些变化不如"无状态"显眼，但对企业落地非常关键。真实世界中的身份系统并不是一个理想化 OAuth Server，而是 Entra ID、Okta、企业 SSO、多个租户、多个授权服务器和复杂重定向策略的组合。规范越贴近成熟 OAuth/OIDC 部署方式，企业越少需要为 MCP 制作特殊绕过方案。

2、身份协议成熟后，MCP 才能进入高价值数据系统

开发者工具可以容忍手工 token，财务、人力、客户数据和生产控制系统则不能。企业真正需要的是可撤销、可审计、可按组织策略管理的身份链路。MCP 如果无法与既有 IAM 体系融合，就只能停留在低风险工具层。

因此，授权规范的价值不是让用户"更方便登录"，而是让安全团队能把 MCP 当成另一个标准资源服务来治理。

（二）Enterprise-Managed Authorization 把授权权力上移到组织 IdP

1、逐个 Server 授权在企业规模下会形成"授权税"

消费级应用中，用户逐个确认"允许这个应用访问那个服务"是合理的；企业环境里，如果员工每天面对几十个 MCP Server 的授权弹窗，就会形成明显摩擦，而且安全团队很难保证每个人的授权方式一致。

**Enterprise-Managed Authorization（EMA）引入企业 IdP 作为权威决策者。**管理员可以通过组织身份系统决定哪些用户、组或角色可以访问哪些 MCP Server。员工使用已有企业身份登录，授权规则由 IdP 的组、角色和条件访问策略统一执行。

官方文档明确举出了 Okta、Azure AD（现 Microsoft Entra 体系）或企业 SSO 作为典型 IdP；MCP 官方博客也说明该扩展已被 Anthropic、Microsoft、Okta 以及多个服务器生态采用。

2、从"用户点同意"到"组织可编排的访问策略"

这对企业有三个直接影响。第一，入职时可以按岗位批量获得所需 MCP 能力；第二，离职或角色变化时可以从中央身份系统统一撤销；第三，安全团队能够把 MCP 访问纳入现有条件访问、审计与合规流程。

这类能力会显著改变 MCP 的采购和平台化路径。过去业务团队可能各自搭建 Server、各自处理 token；未来更合理的模式是企业建设统一 MCP Gateway 或连接平台，背后接入 IdP、策略引擎、审计与密钥管理。

（三）认证强化并不等于"安全问题已经解决"

1、工具权限仍然需要最小化设计

OAuth 只能证明"谁在访问、拥有什么 scope"，不能自动判断某个工具设计是否过于宽泛。一个名为 database_admin 的工具如果同时包含查询、删除和权限修改，即使 OAuth 做得完美，也会形成巨大的授权面。

更成熟的 MCP Server 应把高风险操作拆分成粒度清晰的工具，配合明确 scope、参数校验、审批点和审计事件。工具描述也不能被盲目信任，Host 应把来自非可信 Server 的描述视为潜在不可信输入。

2、企业需要同时治理身份、工具与数据流

真正的 MCP 安全至少包括三层：身份层决定谁能访问；能力层决定能调用哪些工具；数据层决定工具能读写哪些对象。任何一层过宽，都可能导致"身份正确但行为越权"。

因此，EMA 的意义是把企业身份治理的地基补上，而不是宣告 MCP 已经天然安全。

六、为什么这是一次"代际迁移"，而不是普通版本升级

（一）部署模型发生变化，运维组织边界也会变化

1、MCP Server 从特殊长驻服务变成标准 HTTP 工作负载

过去团队部署远程 MCP 时，往往需要专门理解 session、SSE、连接恢复和 sticky routing。新规范把核心调用压回普通请求/响应模型后，Server 更接近其他 API 服务：可以放在 Cloudflare Workers、Lambda 类函数、容器自动扩缩平台或边缘运行时上，只要运行环境能够处理标准 HTTP 与必要的流式响应。

这会降低 MCP 的"基础设施特殊性"。一个平台团队不必为了 MCP 建一套完全不同的部署平台，而可以在现有 Kubernetes、Serverless、API Gateway、WAF、Service Mesh 和可观测体系上扩展少量协议支持。

2、扩缩容成本从"连接数"转向"请求与任务负载"

有状态长连接容易把实例数量与活跃会话数绑定；无状态请求则更容易依据 QPS、CPU、队列长度和任务数量自动扩缩。这不仅影响基础设施费用，也影响容量规划方法。

尤其对于调用峰值明显的 Agent 平台，无状态架构允许冷门工具在闲时接近零资源，高峰时快速拉起实例。对于全球化业务，请求也更容易被路由到不同区域，而不必维持跨区域会话粘性。

（二）协议治理模式发生变化，创新不再要求修改核心

1、稳定核心降低了生态同步升级压力

如果 Apps、Tasks、企业授权等能力都进入核心，任何一项变更都可能要求所有 SDK、Server、Client 同步升级。扩展机制让支持者可以选择性实现，生态能够以不同速度前进。

这对开放标准至关重要。一个标准要获得长期生命力，需要允许"最小实现"稳定存在，同时给高级场景足够创新空间。MCP 2026-07-28 正在形成这种结构。

2、正式弃用策略让企业第一次可以做版本生命周期规划

规范引入至少 12 个月的弃用窗口，并将 Roots、Sampling、Logging 以及遗留 HTTP+SSE 等能力标记为弃用或迁移方向。对企业来说，最怕的不是变化，而是不可预测的变化。只要生命周期透明，平台团队就能把协议升级纳入季度或年度技术债计划。

这也是"生产级"经常被忽视的组成部分：可预测的废弃机制，和新功能本身一样重要。

七、对企业 AI 架构的真正影响：MCP 层可能从"连接器目录"升级为"Agent 控制面"

（一）内部系统不必再为每个 AI 产品重复做适配

1、标准接口将推动"能力服务化"

如果企业已经有订单、客户、知识库、代码、数据仓库、审批等内部系统，最具长期价值的做法不是给每个 Chatbot 单独写插件，而是把这些能力抽象成稳定、受治理的 MCP Server。不同 Agent、IDE、自动化平台可以在权限允许时复用。

这种架构会促使企业重新审视 API 设计：过去 API 面向固定前端或后端开发者；MCP 工具面向模型调用，需要更明确的参数语义、更小的权限边界、更可解释的错误和更强的幂等性。

2、MCP Server 会成为新的"企业能力目录"

一旦工具目录可缓存、可发现、可治理，MCP 不只是技术连接方式，也可能成为企业能力目录的一部分。平台团队可以知道有哪些可供 Agent 使用的工具、每个工具属于哪个系统、由谁负责、需要什么权限、调用成本和风险等级是什么。

这会催生新的平台能力：MCP Registry、企业 Gateway、策略中心、审计平台、质量评分、工具版本管理和依赖图。

（二）Agent 平台的竞争焦点会从"模型接入"转向"治理与运行时"

1、模型本身越来越容易替换，连接与治理才是长期资产

企业不会永远只使用一个模型供应商。真正难迁移的是成百上千个工具连接、授权规则、审计流程和内部业务语义。如果这些能力建立在开放协议上，模型层就更容易被替换或组合。

这也是 MCP 的战略价值：它不是保证所有 Agent 都一样，而是把"连接外部世界"这层从具体模型产品中抽离出来。

2、开放协议减少锁定，但不会自动消除平台差异

即使大家都支持 MCP，不同 Host 在模型推理、权限提示、UI、缓存策略、任务调度、错误恢复和安全策略上仍会不同。HTTP 没有让所有 Web 平台变得一样，MCP 也不会。

因此，**企业采用 MCP 的合理目标不是"从此没有集成成本"，而是把集成成本从专有适配，转化为围绕一个公共协议的工程治理。**这个差别非常大，但仍然需要平台建设。

八、从旧规范迁移到 2026-07-28：企业应该怎么做

（一）第一阶段：先做依赖盘点，而不是直接升级 SDK

1、识别是否依赖协议级 Session

最重要的问题不是"当前 SDK 版本是多少"，而是业务有没有依赖 Mcp-Session-Id 保存跨调用状态。检查购物车、浏览器实例、事务上下文、分页游标、工作流上下文等状态是否被隐藏在 Server session 中。

**如果有，需要设计显式 handle，并明确 handle 的权限、生命周期、租户隔离和存储方式。**这一步是迁移中最需要架构思考的部分。

2、盘点 server-to-client 请求与 SSE 使用方式

**依赖 elicitation、sampling、roots 或长 SSE 流的实现，需要评估 MRTR、subscriptions/listen 以及弃用能力的替代方案。**尤其是自定义客户端，如果过去假设"服务器可以随时在同一连接上发起请求"，就必须更新状态机。

（二）第二阶段：把基础设施能力前移到网关与平台层

**升级后应尽量不要只把 MCP 当成"另一个后端服务"。**可以在 API Gateway 或 Service Mesh 中识别 Mcp-Method、Mcp-Name，建立工具级限流、黑白名单、成本预算和安全策略。

同时把 trace context 接入 OpenTelemetry，让调用链从 Host 到 MCP Server 再到下游服务保持连续。

2、根据 `ttlMs` 与 `cacheScope` 建立缓存策略

**平台应区分公共工具目录、用户私有资源与短时动态数据。**不是所有结果都适合共享缓存，但规范提供了足够语义让客户端减少不必要的重复发现。

（三）第三阶段：把 Apps、Tasks、EMA 当成"按需扩展"，不要一次全开

1、先按场景启用 Tasks

**只有确实存在长时间运行、可恢复、可取消工作的 Server 才需要 Tasks。**对于毫秒级查询工具，保持简单请求/响应反而更可靠。

2、MCP Apps 要先完成沙箱与前端安全评审

UI 扩展会引入新的内容执行面。企业 Host 在支持 Apps 前，应明确 iframe sandbox、CSP、网络访问、数据回传、用户确认和审计策略。

3、EMA 适合进入统一企业身份平台

如果组织已经使用 Entra、Okta 或其他企业 IdP，应由身份与平台团队共同规划 EMA，而不是让每个 Server 团队独立接入。权限模型、用户组、scope 命名和撤销流程需要全局一致。

九、这次升级仍然没有解决什么：理解边界比追捧标准更重要

（一）MCP 不是 Agent 编排器，也不是完整工作流引擎

1、协议解决"如何连接"，不替你决定"如何规划"

**MCP 定义工具、资源、消息与交互机制，但不会替 Agent 选择正确工具，也不会保证模型不会误调用。**工具选择策略、规划、反思、记忆、上下文压缩仍属于 Host 或 Agent Runtime 的职责。

Tasks 提供长任务句柄，也不等于提供完整 DAG、补偿事务、重试策略、调度优先级或工作流版本控制。复杂业务仍可能需要 Temporal、队列系统、工作流平台或企业自研编排层。

2、协议标准化不会自动带来工具质量

一个 MCP Server 可以符合规范，但工具描述仍然含糊，参数仍然难用，错误仍然不可恢复。随着工具数量增长，工具设计质量甚至会成为新的瓶颈。企业需要建立类似 API Design Review 的 MCP Tool Review：命名、输入模式、幂等性、错误、风险、scope、成本都应有标准。

（二）无状态会降低基础设施复杂度，但不会消除分布式系统复杂度

1、重试与幂等性会更重要

当请求可落到任意实例、网络中断后客户端可能重发，副作用工具必须清晰考虑幂等性。创建订单、付款、删除资源等操作如果没有 idempotency key 或业务去重，简单重试可能造成重复执行。

2、长任务依旧需要持久化和恢复机制

Tasks 只标准化了 Client 与 Server 之间如何表示任务，不会替 Server 保存任务状态。真正可靠的生产系统仍然需要队列、数据库、worker、超时、取消和补偿机制。

（三）开放协议的安全边界取决于生态实现质量

1、Host 必须把 Server 视为潜在不可信边界

工具描述、UI 模板、资源内容都可能来自第三方。Host 需要做权限确认、沙箱、数据最小化与提示注入防护。即使协议本身要求用户同意，实现不当仍然可能让"同意"流于形式。

2、企业 Registry 需要解决供应链问题

随着 MCP Server 数量上升，未来的风险会越来越像软件供应链：这个 Server 谁维护？版本是否可信？依赖是否被篡改？工具权限是否发生变化？企业需要对 MCP Server 做来源验证、版本锁定、漏洞扫描和发布审查，而不只是"能连接就加入目录"。

十、MCP 会成为 Agent 时代的 HTTP 吗？更准确的类比是"正在争夺 HTTP 之上的公共层"

（一）类比 HTTP 有启发，但也容易夸大

1、相似之处在于它降低了连接世界的共同成本

HTTP 的伟大不在于定义了网页长什么样，而在于让客户端和服务器共享一套普遍通信语义。MCP 的方向类似：让 AI 应用和外部能力拥有一个共同接口，从而避免每个模型产品发明自己的插件协议。

2026-07-28 进一步强化了这个类比，因为它主动拥抱无状态请求、Header 路由、缓存、OAuth/OIDC 和 OpenTelemetry 等 Web 世界已经验证过的设计。这说明维护者不再试图建立一套完全特殊的 Agent 网络栈，而是在学习 Web 基础设施几十年的经验。

2、不同之处在于 Agent 工具调用具有更强的行为风险

HTTP 本身并不知道浏览器是人在点击还是程序在调用；MCP 的调用者经常是概率性模型。模型可能误解意图、被提示注入影响、组合多个工具形成超出单个工具预期的行为。因此，MCP 的安全问题天然比普通 API 更强调用户同意、工具语义和行为边界。

这意味着 MCP 即使成为事实标准，也仍需要 Agent Runtime、政策引擎和安全产品共同补齐上层治理。

（二）真正值得关注的信号，是生态开始围绕"生产部署"而不是"Demo 连接"说话

1、接近 5 亿月下载量说明开发者触达已经越过早期试验

官方称 Tier 1 SDK 月下载量接近 5 亿，TypeScript 和 Python SDK 累计下载量均超过 10 亿。下载量不是活跃生产实例的等价指标，不能直接推导企业采用数量；但如此规模至少说明 MCP 已进入主流开发工具链，生态不再是少量爱好者试验。

同一发布页中，AWS、Cloudflare、Figma、Google Cloud、Microsoft、Netlify、Supabase、Xero 等生态参与者都从各自角度讨论可扩展性、企业身份、无状态部署和交互能力。这里最重要的不是品牌名单本身，而是他们谈论的议题已经从"我们支持 MCP"转向"我们如何在大规模生产环境运行 MCP"。

2、标准的下一阶段将从"连接数量"转向"治理质量"

未来判断 MCP 是否真正成为 Agent 时代基础层，应该看四个指标：第一，跨 Host/Server 的互操作是否稳定；第二，企业身份和权限能否形成统一治理；第三，Server 供应链与安全审计是否成熟；第四，版本升级是否能在不破坏大规模生态的情况下持续进行。

2026-07-28 没有完成这四件事，但它第一次在架构上为这四件事提供了更合理的地基。

十一、结语：MCP 的关键转折，是"协议开始不再要求基础设施适应它"

回看 MCP 的发展路径，2024 年的核心问题是"AI 如何标准化访问外部数据和工具"；2025 年的核心问题逐渐变成"如何把这种访问安全地放到远程环境"；到 2026 年 7 月，问题已经升级为"如何让这套协议像成熟 Web 服务一样被部署、扩缩、路由、缓存、追踪和治理"。

这正是 2026-07-28 的根本意义。

移除握手和协议级 Session，让请求可以在普通负载均衡后自由落到任意实例；MRTR 保留了 Agent 场景需要的人机多轮交互，又不重新引入长连接依赖；Header 路由、缓存提示与 Trace Context 让网关、缓存和可观测体系可以真正理解 MCP；扩展框架让 Apps、Tasks、企业认证不必继续膨胀核心；OAuth/OIDC 与 Enterprise-Managed Authorization 则把身份治理拉回企业已经熟悉的标准轨道。

因此，这次更新最值得记住的一句话，不是"MCP 支持 serverless 了"，而是：MCP 开始主动适配现代互联网基础设施，而不再要求现代互联网基础设施为 MCP 的特殊会话模型让路。

如果这个方向持续成立，MCP 的长期价值也许不会体现在某个单一 AI 产品上，而会体现在一个更基础的问题上：当企业同时使用多个模型、多个 Agent、多个 SaaS 和大量内部系统时，是否终于可以拥有一层相对稳定、开放、可治理的能力连接标准。

这才是"从工具协议走向 Agent 基础设施"真正发生的地方。