MCP 2026-07-28 规格发布后，最受关注的变化是移除了协议会话（protocol sessions）。到目前为止，外界对此的解读基本集中在“这是一次扩展性胜利”——这个判断没有错。但同一版本还新增了两个必填的 HTTP 请求头，而正是这两个请求头，让网关可以在完全不打开请求体的情况下，对 Agent 流量进行路由、限流和计量。 旧版传输协议以 initialize 和 initialized 交换开场，建立起一个会话，并通过 Mcp-Session-Id 头来追踪。后续的每个请求都必须找到与该会话绑定的状态。这套机制给基础设施带来了连锁负担：自动扩缩容必须保留会话，部署时需要排空或迁移会话，负载均衡几乎不可行——因为客户端被固定地绑定在持有其会话的那个实例上。 新协议把握手、会话头和协议会话一并从核心请求路径上移除。每个请求自身携带协议版本、客户端身份以及所需的 capabilities，任意请求可以落在任意实例上。 但真正被忽视的部分，是请求本身的形态变化。MCP 消息本质上是跑在 HTTP 之上的 JSON-RPC，而关于请求的信息此前只存在于 JSON 请求体内部——网关必须解析整个请求体，才能知道这个请求是在列出工具、调用某个工具，还是读取某个资源。 现在，Streamable HTTP 请求上新增了两个必填头：Mcp-Method 和 Mcp-Name。一个工具调用的请求，会以 `Mcp-Method: tools/call`、`Mcp-Name: search` 的形式抵达，JSON-RPC 负载跟在后面。Cloudflare 的 Matt Carey 明确指出了这带来的实际价值：网关、限流器或 WAF 可以直接读取这两个头，按方法或按工具粒度执行策略——用的就是它们早已用来处理所有其他 API 的同一套基础设施。评论区用户 evalstate 还注意到规格走得更远：工具参数可以被复制进自定义头，用于定制化的路由规则。 在此之前，Agent 治理一直是从另一个方向切入的。Cloudflare 的 Agent 追踪和 Azure API Management 的 AI Gateway 层级都架设在协议之上。现在，随着请求头标准化，治理能力被下沉到了网关层本身。这个变化的成本是零——只需要读取两个头字段。 从架构演进的角度看，这次规格更新真正绕开了体层解析这道高成本环节：请求头是明文，网关无需解包、无需缓冲、也不需要 TLS 终止后再重建连接。无论是按方法名还是按工具名进行计量，所有信息都在数据包的最前面。对于云厂商和 API 网关来说，这意味着他们第一次可以用处理普通 REST API 的方式，来处理 MCP 流量。 至于代价，也不是没有。对于调用方而言，客户端和服务端都必须同步升级到新协议；旧有的会话状态若仍然依赖服务端内存，在新规格下就失去了官方支持。而把工具参数复制进请求头，固然方便了路由，但同时也意味着调试日志里可能多出一些本不该出现的敏感数据。这是工程权衡，不是免费午餐。 不过，从市场规模和部署现实来看，这一刀切掉的是 Agent 流量接入网关的最大痛点多处。MCP 从 JSON-RPC over HTTP 变成了带路由元数据的 JSON-RPC over HTTP，这一字之差，决定了 Agent 流量是否真正具备了被当作“普通流量”来经营的前提。规格的去会话化，是协议层的一次瘦身；而两个新头的引入，才是运营层那次真正的开门。
热门跟贴