MCP 无状态之后：被少报的那一半，是网关终于读得懂智能体流量

本站在 08-01 把 2026-07-28 那版 MCP 规范发成 critical，讲的是无状态化带来的部署形态变化：废除握手与会话 id，任何请求都能落到任意实例。那条是对的，但它和当时绝大多数报道一样，只写了一半。

被少报的那一半：请求本身也变了

MCP 消息是 HTTP 上的 JSON-RPC，此前关于一个请求的信息只存在于 JSON 正文里——网关必须解析正文，才知道这是在列工具、调工具还是读资源。

新规范要求 Streamable HTTP 请求必须带两个标头：Mcp-Method 与 Mcp-Name。一次工具调用到达时是 Mcp-Method: tools/call 加 Mcp-Name: search，负载跟在后面。于是网关、限流器或 WAF 可以直接读标头，按方法或按工具采取动作，用的正是它已经在所有其他 API 上跑着的那套机制。规范甚至允许把工具参数复制进标头做自定义路由。

方向的变化才是重点。 智能体治理此前一直从另一头长：Cloudflare 的智能体追踪、Azure API Management 的 AI Gateway，都是坐在协议之上的独立控制层。这次发布把元数据放进传输层，让基础设施团队已经在运行的系统读得懂它——不需要为智能体流量再建一套。

人在回路那一步被拆开了

服务器发起的请求过去要保持一个打开的流。现在改成多轮往返：服务器返回 input_required，客户端收集答案，然后重试调用。

一次审批从「保持一条连接」变成了「两个请求」。 部署确实更简单，但代价写在同一句话里——等待人工响应的过程不再位于单次调用内部。这一点直接落在本站《人在回路的审查》上：审查点的位置没变，承载它的机制变了，而超时、重试与状态归属都要跟着重画。

授权也一并收紧，而且带日期：动态客户端注册已弃用、计划 2027 年夏季之后移除；采用 RFC 9207 做颁发者标识；客户端把规范服务器 URI 作为 RFC 8707 的 resource 发送，确保令牌只被该受众接受。

社区吵的不是「无状态好不好」

Hacker News 上的分歧尖锐，但分歧点不在无状态是不是进步——在于这个进步揭示了什么。

一派认为它证明这个协议从一开始就不该有状态：剥掉状态之后 MCP 实际上就是另一个 REST 端点，于是负载均衡、API 网关、渐进发布这些现成基础设施全都能用。有人把它归为业界反复重学的一课，并回溯到 Sun RPC 得出的同一结论。最直白的一句是：发明一个有状态协议，发现状态难扩展，剥掉状态，最后得到「发一个 POST 就行」。

辩护的一方不否认这种相似，只是不同意由此得出的结论：MCP 实际上就是 JSON-RPC，真正被发明出来的是一套模型已经被训练得会用的约定。用一句话概括就是——它的核心优势在于这是一项获得 AI 提供商认可的标准，因此人们有强烈动机真的去实现它。

另一条并行讨论问：智能体是不是根本不需要协议，用 shell 调普通命令行工具就够了。反驳很具体——那个立场默认使用者是开着终端的开发者，而大多数使用场景来自手机应用、网页聊天和嵌入式组件。

两个方向相反的数字

Anthropic 报告 MCP SDK 月下载量已超过 4 亿次，今年增长三倍。采用情况没有争议。

但一家咨询公司在审计客户的服务器时发现：三个月记录了 61 次工具调用，其中 58 次来自客户自己的工程师。 他们的结论是团队把「智能体能够访问」当成了「智能体愿意访问」。作者主动披露 MCP 工作在其咨询收入中占很大比例——这个披露让这个数字更可用，不是更不可用。

这是本站昨天那条开放模型生态报告的同一个问题，往下一层。 下载量衡量的是可得性，调用次数衡量的是使用；把其中一个当作另一个的代理，是这一周里第二次踩到。那篇咨询帖自己的收尾也指向同一处：钱正在流向网关、注册中心和鉴权层，而不是服务器本身——而这恰好就是这次规范改动服务的那一层。

迁移是有成本的，而路径是明确的

依赖协议会话、服务器到客户端请求或独立流的服务器，可以在现有有状态路由旁边跑一条无状态路由，把功能迁过去，排空活动会话，再在弃用窗口内移除旧路径。规范以及更新后的 TypeScript、Python、Go 与 C# SDK 均已提供。

边界

本条为二手报道（InfoQ 中文译自 InfoQ 英文），社区观点均转引自 Hacker News 讨论，本站未独立核实各条发言。4 亿次月下载来自 Anthropic 自述；61 次工具调用来自单一咨询公司对一个客户的审计，样本为一，且作者有已披露的利益相关——它是一个提醒，不是一个行业比例。