Anthropic 在 7 月 28 日发布了《Bringing MCP 2026-07-28 to Claude》，宣布第五版 Model Context Protocol 规格上线，并开始向 Claude 产品滚动支持。
表面看，这是一篇产品公告：MCP 变成无状态核心，授权更接近生产级 OAuth/OIDC，MCP Apps 和 Tasks 进入标准化扩展框架，Claude 连接器目录继续扩大。
但它真正重要的地方不在“Claude 又支持了一个新版本”。
更准确地说，MCP 正在从“让模型调用工具的协议”，变成 AI 应用连接外部世界的基础设施层。这次 2026-07-28 规格做的几件事，几乎都指向同一个目标：让 MCP 服务器像普通 Web 服务一样部署、扩容、观测、授权、缓存和治理。
这对 Agent 工程的影响很大。过去做 MCP，重点是“把工具接进去”；下一阶段做 MCP，重点会变成“让连接器能在企业生产环境里长期运行”。
一、这次官方到底发布了什么
Anthropic 原文给了几个关键信号。
第一，MCP 2026-07-28 是第五次规格发布。官方称，MCP 最近已经超过 4 亿次月度 SDK 下载量，今年增长 4 倍，并且已经成为连接 AI agents 与应用的行业标准之一。
第二，新规格最核心的三项变化是：
- Stateless core：MCP 从双向、有状态协议转向 request/response 模型。服务器可以部署在 serverless 和 edge 基础设施上，不再被会话状态绑定。
- Standardized extensions：MCP Apps 和 Tasks 进入版本化扩展框架。开发者可以在不改变核心协议的前提下，加入交互式 UI 和长任务能力。
- Auth hardening：授权机制对齐生产环境里的 OAuth 2.0 / OIDC 部署，MCP 服务器可以更自然地接入 Entra、Okta 这类企业身份系统。
第三，Claude 产品侧也在同步推进。Anthropic 说，Claude 连接器目录里已经有超过 950 个 MCP servers，每天被数百万用户使用；今年 Claude 还加入了 MCP Apps、Enterprise-managed auth、连接器开发者观测面板，以及 MCP tunnels 研究预览。
这几件事合起来，说明 Anthropic 对 MCP 的定位已经很清楚：它不只是 Claude 的工具调用接口，而是 Claude 应用生态的连接器底座。
二、无状态核心为什么是关键变化
这次规格里最值得看的是 stateless core。
旧 MCP 的问题不在于“有状态”本身不好，而在于协议层的会话状态会把服务器运行方式锁住。只要协议依赖 initialize/initialized 握手、Mcp-Session-Id、长连接、服务端主动请求，部署方就要处理一堆 Web 基础设施最不喜欢的问题：会话粘滞、连接保持、断线恢复、实例间共享状态、负载均衡路由。
2026-07-28 的做法是把这些协议级状态拆掉。
根据官方规格变更，新的 MCP：
- 移除了
initialize/notifications/initialized握手； - 移除了 Streamable HTTP 里的
Mcp-Session-Id； - 每个请求都在
_meta里携带协议版本、客户端能力、客户端信息； - 服务端通过
server/discover暴露支持的协议版本、能力和身份； - HTTP 请求必须带
Mcp-Method和Mcp-Name等头，方便网关、WAF、限流器、鉴权层直接按头部路由和治理。
这等于把 MCP 重新塑造成一个普通 HTTP workload。
普通 HTTP workload 的价值不是“形式更优雅”，而是能直接吃到过去几十年 Web 基础设施的红利：round-robin 负载均衡、边缘部署、无服务器伸缩、API gateway、WAF、缓存、日志、trace、限流、熔断、灰度发布。
对大规模 MCP 服务商来说，这个变化非常实际。以前一个 MCP server 如果要支持大量用户，就要小心维护连接和会话；现在任何请求理论上都可以落到任意实例。Netlify 在 Anthropic 原文里的评价很直接：新规格让 MCP 成为“一等 HTTP workload”，不再需要围绕 session management 设计额外工作。
三、无状态不等于没有状态
这里容易误解：MCP 变成 stateless，并不是应用就不能有状态。
官方规格说得很明确：如果服务器需要跨调用保留状态，可以由工具显式创建一个 handle，再让模型把这个 handle 当作参数传回来。
这是一条很重要的设计原则：状态不再藏在传输层，而是显式出现在模型和工具的交互里。
这会改变 MCP server 的设计方式。
过去你可能会把状态存在 session 里：用户当前操作到第几步、上一次查询的结果、某个临时资源 ID、长任务上下文。模型不一定知道这些状态在哪里，只是依赖底层连接一直活着。
新模式下，状态要变成显式对象：
- 一个搜索会话可以是
searchSessionId； - 一个部署流程可以是
deploymentId； - 一个批处理任务可以是
taskId； - 一个临时工作区可以是
workspaceHandle； - 一次人类审批可以是
approvalRequestId。
这种方式更啰嗦，但更适合 Agent。因为模型能“看见”状态句柄，也能在后续工具调用里主动传递它。状态从隐式连接副作用，变成了可解释、可记录、可审计的业务对象。
这也是 MCP 生产化的关键：企业系统不喜欢“状态藏在连接里”，更喜欢“状态有 ID、有权限、有生命周期、有日志”。
四、MRTR：把服务端主动请求改成可重试流程
无状态化会带来一个问题：如果服务器在工具执行中途需要用户输入怎么办？
例如，一个 Supabase MCP 工具准备创建新项目，执行前需要用户确认成本；一个财务工具要发起付款，必须让用户二次确认；一个代码工具发现参数缺失，需要让用户补齐。
旧模式可以依赖服务端主动请求客户端，或者维持双向流。新规格引入了 Multi Round-Trip Requests，也就是 MRTR。
它的做法是：服务器不再主动发起一个新的请求，而是在原请求结果里返回 resultType: "input_required"，同时带上需要客户端回答的 inputRequests。客户端拿到用户或模型的回答后，再用 inputResponses 重试原来的请求。
这看起来像绕了一圈，但它符合无状态模型：每一步都是请求/响应，每次重试都携带必要上下文，不需要假设某条双向连接一直存在。
对 Agent 产品来说，MRTR 的意义是把“中途问人”变成协议级模式。很多真实工作流都不是一次工具调用就结束的：审批、确认、选择、补参、风险提示，都是 Agent 进入生产环境后绕不开的环节。
五、Tasks：长任务终于有了正式位置
另一个关键扩展是 Tasks。
很多工具调用天然不是秒级返回：CI pipeline、批量导入、云部署、报告生成、视频处理、代码迁移、人审流程，都可能持续几分钟甚至几小时。强行保持连接等待结果，既不稳定，也不适合移动端、浏览器、网关和 serverless 环境。
新规格把 Tasks 从实验核心中移出，放进 io.modelcontextprotocol/tasks 官方扩展。它的核心模式很朴素：服务器可以返回一个 durable task handle，客户端通过 tasks/get 轮询状态，通过 tasks/update 提交中途需要的输入，必要时通过 subscriptions/listen 接收通知。
这其实是在给 Agent 工作流补一个基础构件。
如果说普通工具调用适合“查一条数据、改一个字段、发一封邮件”，Tasks 适合的是“让系统去做一件可持续跟踪的事”：部署一个环境、跑一批任务、等待人审批、处理一组文件、执行一轮评估。
长任务能力一旦进入标准扩展，MCP server 就可以从“函数集合”变成“工作流入口”。这会让连接器的产品形态发生变化：它不只是给模型几个 API，而是能把外部系统里的异步工作带进对话。
六、MCP Apps：连接器开始有界面
MCP Apps 是另一条重要线索。
传统 MCP 工具返回文本、图片、资源或结构化数据；MCP Apps 允许服务器返回可交互 UI，让图表、表单、仪表盘、文件预览、审批页面直接出现在对话里。
Anthropic 原文说，MCP Apps 可以让服务器在对话中直接渲染交互界面，用户能看到连接器正在做什么，并且在不切换标签页的情况下完成操作。
这点非常关键。Agent 产品不能永远停留在纯文本问答里。
现实工作里，用户经常需要：
- 看图表并切换维度；
- 在表单里确认多个参数；
- 预览 PDF、图片、视频或 3D 模型；
- 在多条候选结果中逐个审核；
- 对高风险操作点击确认或修改。
这些场景用对话来回问很低效，用独立网页又会割裂上下文。MCP Apps 给了第三种形态：UI 留在对话里，权限和工具仍走 MCP，渲染运行在 host 控制的沙箱 iframe 中。
这意味着 MCP server 不再只是后端 API 适配器，也可以带一小块前端体验。对企业连接器来说，这会很重要：复杂工具如果没有 UI，用户很难建立信任；但如果每个连接器都跳到外部网页，Claude 这样的主工作台又会失去连续性。
七、授权硬化：企业部署的门槛被正面处理
MCP 要进企业，最大门槛往往不是工具调用，而是身份与权限。
这次规格对授权做了不少硬化。官方变更包括：
- 授权服务器应返回 RFC 9207 的
iss参数，客户端在换取 token 前必须验证已有iss； - 客户端凭证必须绑定到发行它们的 issuer，不能跨授权服务器复用；
- Dynamic Client Registration 被正式弃用，未来转向 Client ID Metadata Documents；
- HTTP 授权对齐 OAuth 2.1、OIDC discovery、Protected Resource Metadata、Resource Indicators 等生产环境机制；
- 访问 token 必须通过 Authorization header 发送，不能放进 URL query；
- MCP server 必须验证 token 是为自己的 resource 签发的。
这些细节看起来偏协议，但背后是很现实的安全边界。
企业不可能接受一个“随便连上就能调内部工具”的 Agent 生态。管理员需要知道：谁授权了哪个连接器、用户继承了哪些 IdP 组权限、token 发给了哪个资源、能不能集中撤销、能不能避免凭证串用、能不能接入 Entra/Okta。
Anthropic 在 Claude 产品侧推出 Enterprise-managed auth，也是在解决同一个问题：管理员一次授权连接器，用户通过现有 IdP 组继承访问权限，首次登录即可连接，终端用户零配置。
这会改变 MCP 连接器的竞争点。早期连接器拼的是“能不能接上”；生产阶段拼的是“能不能被企业安全团队批准”。
八、缓存与可观测：MCP 服务器开始像平台服务
这次规格还有两个容易被低估的变化。
第一，列表结果开始可缓存。tools/list、prompts/list、resources/list、resources/read 等响应会携带 ttlMs 和 cacheScope，并要求确定性顺序。
这件事对 LLM 应用很实际。工具列表、资源列表如果每次都变，模型 prompt cache 命中率会下降；客户端反复拉取也会给服务器带来压力。确定性顺序加缓存提示，等于是承认 MCP 的“目录信息”也需要像普通 API 元数据一样被缓存和治理。
第二，Claude 给已发布连接器提供观测面板。开发者可以看到连接器在 Claude 各产品面的表现，追踪采用情况、错误、延迟，并按产品拆分使用情况。
这说明 MCP server 正在从“开发者本地工具”变成“有运营指标的产品”。一旦连接器进入目录，被数百万用户使用，开发者就必须关注延迟、错误率、采用率、留存、不同产品面的行为差异。
协议的 stateless、headers、cache hints，产品侧的 observability，本质上是一组配套动作：让 MCP server 可以被当作平台服务来运营。
九、MCP tunnels：内网工具进入 Claude 的另一条路
Anthropic 还提到 MCP tunnels 研究预览：它可以把 Claude 连接到私有网络里的 MCP servers，而不需要把这些服务器暴露到公网，也不需要入站防火墙规则、公开端点或源站 IP allowlisting。
这对企业内网工具很重要。
很多真正有价值的工具并不在公网：内部数据平台、工单系统、风控系统、财务系统、知识库、CI/CD 控制面。让 Claude 调用这些工具，最难的不是写 MCP server，而是网络与安全架构：公网暴露风险太高，VPN/allowlist 又增加运维复杂度。
MCP tunnels 如果成熟，会让“内部工具接入 Claude”从网络工程问题变成连接器配置问题。当然，它也会带来更高的审计要求：谁打开了隧道、连接到哪个内部服务、走了哪些工具、传了什么数据，都必须清晰可追踪。
十、真正的变化：MCP 从协议实验走向生产治理
把这些变化放在一起看，可以看到 MCP 2026-07-28 的主线：
- stateless core 解决部署和扩容；
- headers 解决网关路由和策略执行；
- cache hints 解决目录稳定性和性能；
- Tasks 解决长任务和断线恢复；
- MRTR 解决中途交互；
- MCP Apps 解决复杂 UI；
- OAuth/OIDC hardening 解决企业身份；
- deprecation policy 解决生态升级节奏；
- observability 解决连接器运营。
这不是单点功能更新，而是一次生产化补课。
早期协议最重要的是把生态跑起来，所以要快、要简单、要让开发者容易接工具。现在 MCP 已经有足够多的连接器、SDK 下载、企业试点和真实用户，问题自然变了：怎么让它规模化？怎么让企业敢用？怎么让网关和安全团队看得懂？怎么让连接器开发者能运维？怎么让扩展能力不把核心协议拖碎？
2026-07-28 给出的答案是：核心变薄、状态外显、扩展版本化、授权标准化、治理机制补齐。
十一、开发者该怎么调整 MCP server 设计
如果你正在做 MCP server，这次规格带来的不是“升级 SDK”这么简单。
更合理的设计方向是：
- 默认按无状态服务设计：不要依赖连接级 session，不要求请求落到同一个实例，跨调用状态用显式 handle 表达。
- 把工具名和方法当治理维度：既然
Mcp-Method和Mcp-Name能进入 HTTP 头，就应该让命名稳定、清晰、可授权、可限流。 - 给列表结果确定性顺序和缓存策略：工具目录不应该每次随机变动，否则会影响客户端缓存和模型上下文稳定性。
- 长任务不要硬扛连接：分钟级、小时级工作应优先设计成 Tasks，而不是让一次工具调用阻塞到结束。
- 把授权当产品能力：企业连接器要先想清楚 IdP、scope、resource、issuer、token 存储、撤销、审计，而不是上线后再补。
- 慎用扩展，但要跟踪扩展矩阵：MCP Apps、Tasks 都很有价值，但客户端支持不一定一致。连接器需要根据目标 host 做能力降级。
- 为观测预留结构：错误码、延迟、用户操作路径、工具调用成功率，都应该能被看见。
一句话：不要再把 MCP server 当“给模型开的几个函数”，而要把它当“面向 Agent 的生产 API 产品”。
十二、风险也在变大
这次更新也不是没有代价。
第一，迁移成本是真实存在的。依赖 Mcp-Session-Id、初始化握手、HTTP+SSE、旧 Tasks、Roots、Sampling、Logging 的实现，都要面对兼容期和改造成本。官方给了至少 12 个月的弃用窗口，但这仍然需要生态同步。
第二，状态外显会把复杂度推给应用层。显式 handle 更清晰，但也要求开发者管理生命周期、权限、过期、泄露风险和模型传参准确性。
第三，长任务从阻塞变成轮询或订阅，并不自动让体验变好。Tasks 需要设计好状态语义、进度消息、失败恢复、取消策略和用户输入流程，否则只是把复杂度换了个地方。
第四，授权更标准，也更复杂。OAuth/OIDC 对企业友好，但对小团队和本地开发者门槛更高。MCP 生态需要足够好的 SDK、模板和部署平台，才能避免“安全正确但开发痛苦”。
第五，扩展框架可能带来碎片化。MCP Apps、Tasks、Skills over MCP 等扩展都很有用，但如果不同 host 支持矩阵差异太大，开发者仍然要写大量兼容逻辑。
这些风险不否定新规格，反而说明 MCP 正在进入更真实的阶段。生产基础设施的复杂度不会消失，只会从协议灰区转移到明确的设计面上。
结语：Claude 需要的不是更多工具，而是更稳的连接层
Anthropic 这篇文章最值得记住的一点是：Claude 不是简单“支持 MCP 新版本”，而是在把 MCP 变成 Claude 应用生态的连接层。
当连接器目录超过 950 个、每天有数百万用户使用，当企业希望把内部工具接入 Claude，当开发者想把 UI、长任务、观测、权限都放进同一个连接器体系，MCP 就不能只停留在 demo 协议。
MCP 2026-07-28 的方向很清楚：让 Agent 连接外部系统这件事，尽量回到成熟 Web 基础设施能处理的形态。
无状态、可缓存、可路由、可授权、可观测、可弃用，这些词听起来不如“智能体”性感，但它们才是 Agent 真正进入生产环境的前提。
如果说过去一年 MCP 证明了“模型可以标准化连接工具”，那么 2026-07-28 这一版开始回答下一个问题：这些连接器能不能像基础设施一样可靠地运行。
参考：
- Anthropic Claude Blog：《Bringing MCP 2026-07-28 to Claude》
- Model Context Protocol Blog：《The 2026-07-28 Specification》
- Model Context Protocol：《2026-07-28 Specification》
- Model Context Protocol：《2026-07-28 Changelog》