2026年7月28日发布的MCP规范取消协议会话，新增必需的HTTP标头，让网关无需解析请求正文即可路由和限制智能体流量。无状态化让MCP更像普通REST API，也直接影响企业上云架构。结合云服务器ECS与阿里云代金券，本文拆解变化与应对。
MCP新规范改了什么
旧版MCP要干活，得先来一次initialize握手，然后靠Mcp-Session-Id标头维持会话状态。这个设计在单个服务器上跑没问题，一旦放到负载均衡后面，麻烦就来了：用户第一次请求落在A机器，下一次可能被转到B机器，B机器没有那段会话，要么重新握手，要么把会话迁过去。迁过去还要处理排空，旧连接不能立刻断，得等它把活干完。
新规范直接砍掉了这套逻辑。每个请求都自带协议版本、客户端身份和能力，服务器不需要记住“这个客户端是谁”，看请求本身就知道。网关也一样，不用再解析请求正文去猜要调哪个工具，因为请求头里写得明明白白。
两个必填HTTP标头让网关更省事
Streamable HTTP请求现在必须带两个标头：Mcp-Method和Mcp-Name。Mcp-Method告诉网关这次调用的方法，Mcp-Name告诉它工具名称。网关、速率限制器、WAF都能基于这两个字段做策略，比如限制某个工具每秒最多调用100次，或者封禁某个方法。以前这些事得把请求体解出来，逐层翻JSON才能判断，现在一个头就搞定。
工具参数也能放进标头，用来做自定义路由。比如某个大模型请求要访问高权限工具，网关可以直接根据标头把请求导到专用节点，不用看正文。
服务器发起的请求变成两段式
以前服务器想向客户端要信息，会保持一条开放流，慢慢等客户端回应。新规范改成多轮往返：服务器返回input_required，客户端收集完答案后，再发起一次重试调用。审批流程也跟着变了，原来一次连接能完成的事，现在要拆成两个请求。
这个改动对网络更友好，连接不用长时间挂着，但应用逻辑得调整。如果你自己写了MCP客户端，不能假设回调还在原来的流上。
授权机制收紧
- 动态客户端注册被弃用，计划在2027年夏季之后彻底移除。以后客户端身份得提前配置好。
- 采用RFC 9207做颁发者标识，防止令牌被别家服务器冒用。
- 客户端要把规范的服务器URI作为RFC 8707 resource发送，用来限定令牌的受众范围。
这套组合拳下来，令牌的适用范围更窄，跨站伪造的难度更高。代价是接入方要改配置，不能再靠动态注册省事。
社区吵的不是无状态，是MCP的定位
新规范一出来，有人直接说：MCP这不就是普通REST API吗？会话没了，状态没了，和平时调HTTP接口有什么区别。辩护的人说，MCP的核心价值本来就不是协议多创新，而是拿到了AI提供商的标准认可，同时把身份验证和工具处理理顺了。
数据也能说明一点：MCP SDK月下载量已经超过4亿次，比去年增长三倍。但流量热闹不等于服务器赚钱。有咨询机构审计了一个MCP服务器，三个月里61次工具调用，58次来自客户自己的工程师，真正外部用户只占三次。资金正在流向网关、注册中心和身份验证层，而不是工具服务器本身。
架构调整的三个方向
如果团队已经上了MCP，新规范其实给了个机会：把无状态服务放到云服务器ECS上，横向扩展不用再担心会话粘滞。网关层用Mcp-Method和Mcp-Name做限流，WAF做拦截，整个链路比之前干净。
不想从零折腾网关和鉴权，可以找 易枫顺 - 阿里云官方旗舰级代理商 这类服务商，把MCP网关、注册中心和身份验证层托管在云服务器ECS上，顺便用阿里云代金券冲抵初期成本。把服务器搬到云端不是终点，MCP无状态化之后，架构设计反而更依赖云原生的网关和可观测性组件。
FAQ
Q: MCP无状态化后，旧版长连接应用还能继续用吗？
A: 旧版客户端和服务端如果不升级，还是能按老协议跑，但网关和负载均衡会越来越难做。新规范把会话去掉之后，服务端不再维护客户端状态，升级的关键是让每个请求带上完整信息。
Q: Mcp-Method和Mcp-Name标头能带来什么实际好处？
A: 网关不用解析请求体，就能按方法或工具名做路由、限流和封禁。比如某个工具被恶意刷调用，直接在WAF上按Mcp-Name拦截，几秒钟生效，不用改应用代码。
Q: 动态客户端注册被移除后，接入MCP会更麻烦吗？
A: 初期配置会更重，因为客户端身份要提前登记。但换来的是更清晰的审计和更安全的令牌边界。对需要合规的团队来说，这个取舍值得。
关于易枫顺
深圳市易枫顺网络科技有限公司是阿里云官方旗舰级代理商。提供云服务器ECS、云数据库RDS、对象存储OSS等阿里云全系产品官方特惠折扣与代金券申请，以及多云成本优化、企业上云一站式服务。客服热线：19520841949 - 易枫顺
来源：InfoQ
