MCP协议发布2026-07-28新版本，核心升级为无状态协议，支持请求/响应模式，提升可靠性和可扩展性。SDK月下载量近5亿，TypeScript和Python SDK总下载量均突破10亿。

好的，这是根据您的要求，对原文主要内容进行的中文重述，已保留关键细节并删减了与主题无关的社区赞誉内容。

标题：MCP 2026-07-28 规范发布：迈向无状态、可扩展的企业级协议

核心变化：协议核心转向无状态

MCP 协议迎来了重大版本更新 2026-07-28。本次更新的核心亮点是协议从双向有状态模型转变为请求/响应的无状态协议。这意味着：

• 告别握手与会话：正式移除了 initialize/initialized 握手流程和 Mcp-Session-Id 头部。每个请求都独立传输，并在 _meta 中携带协议版本、客户端身份和能力信息。
• 支持负载均衡：客户端无需预先发现服务器能力，任何请求都可以直接发送到轮询负载均衡器后的任意服务器实例，极大提升了可靠性和可扩展性。
• 应用状态管理：协议层不再强制管理状态。如果服务器需要跨请求保持状态，可以通过工具显式创建句柄，并由模型作为参数传递，这种方式比隐藏的会话状态更优。

其他关键更新

• 多轮往返请求 (MRTR)：取代了之前需要保持双向流开启的服务器发起请求（如采样、提示）。当工具需要用户确认或补充参数时，服务器可返回 input_required 状态，客户端在重试时附上答案即可。
• 可缓存列表结果：tools/list 等列表响应现在包含 ttlMs 和 cacheScope 字段，允许客户端制定缓存策略，减少不必要的重复请求。
• 授权与安全强化：
  • 授权服务器必须返回 iss 参数（RFC 9207），客户端需验证，以防范授权服务器混淆攻击。
  • 动态客户端注册 (DCR) 被正式弃用，转向客户端元数据文档 (CIMD)。
  • 客户端凭据与签发者绑定，禁止跨授权服务器复用。
• 任务 (Tasks) 扩展：任务功能从实验性核心移至正式扩展，支持基于轮询的 tasks/get 和新的 tasks/update 方法。
• 正式弃用政策：为 Roots、Sampling、Logging 以及传统的 HTTP+SSE 传输方式设定了至少12个月的弃用窗口期，以便开发者平稳过渡。

SDK 与生态支持

TypeScript、Python、Go 和 C# 四大一级 SDK 已同步更新至新规范，Rust SDK 也提供了测试版支持。新规范得到了包括 AWS、Google Cloud、Microsoft Foundry、Cloudflare 等在内的广泛生态伙伴的支持，他们普遍认为无状态核心、任务扩展和企业级授权等特性，使 MCP 真正成为可用于生产环境的、可扩展的企业级基础设施。

如何开始

开发者可以访问官方规范文档、完整变更日志和入门指南，立即开始基于新规范进行开发。

根据评论内容，总结如下：

主要观点与论据：

1. 支持无状态化（Stateless）：多数评论者认为MCP转向无状态HTTP是正确方向，能提升可靠性、降低服务器负担。关键引用：

   • "The actual tool calls are stateless anyway... it's just text going back into the context window" (firasd)
   • "Reliability up, problems down. TOON support is natural" (ilc)

2. 简化服务器架构：无状态化减少了会话管理的复杂性，便于部署到无服务器环境。关键引用：

   • "The server-side complexity required to handle sessions has been a large burden" (btbuilder)
   • "Why put the burden on the server? It is the job of client to remember" (osinix)

3. 对MCP必要性的质疑：部分评论认为MCP对多数用例并非必需，可直接使用HTTP/curl。关键引用：

   • "You can get better results with skills SKILL.md + linked .md files with curl commands inside" (jongjong)
   • "MCP mostly adds unnecessary work for a lot of cases" (jongjong)

4. 安全与信任问题：有评论对MCP的域名、代码审计和潜在风险提出担忧。关键引用：

   • "there's a lot of security issues here, that make it hard to distinguish a malicious actor from a legitimate one" (TZubiri)
   • "The code is vibecoded and auditing would take more time than it takes to actually write it" (TZubiri)

5. 迁移与兼容性：部分用户关心从MCP 1.x到2.x的过渡成本。关键引用：

   • "I wonder if it is possible to keep using MCP 1.x as well for now. Development is expensive" (flowofcontrol)
   • "I'm currently working on getting all my MCP tools ported over to HTTP" (rupertsworld)

平衡性说明：支持无状态化的评论占多数（约10条），质疑MCP必要性和安全性的评论各约2条，整体呈现积极但谨慎的态度。