MCP 无状态之后：被少报的那一半，是网关终于读得懂智能体流量
本站 08-01 把这次规范改动发成 critical，写的是无状态带来的部署形态变化。这条补上被少报的另一半：两个新的必需标头让网关不打开请求正文就能路由、限流和计量智能体流量——智能体治理此前一直是协议之上的独立控制层，现在元数据进了传输层。附带一组方向相反的数字：SDK 月下载 4 亿次，而一次审计里某台服务器三个月只有 61 次工具调用。
Marked important, but published more than 30 days ago, so it moved down to this band.
On this page11 sections
This signal comes from a Chinese-language source and is written in Chinese.
Record
The signal
#本站在 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 次工具调用来自单一咨询公司对一个客户的审计，样本为一，且作者有已披露的利益相关——它是一个提醒，不是一个行业比例。
Why now
Why it matters
#08-01 那条信号写的是无状态化怎么改变部署形态；这一条补上它没写的另一半，而那一半决定谁能治理智能体流量。把方法名与工具名放进 HTTP 标头，意味着限流、计量、鉴权和路由可以由基础设施团队已有的系统承担，而不是再建一层。代价同样具体：人工审批从一条保持的连接变成两个请求，等待不再位于单次调用内部。
Background
Technical context
#Streamable HTTP 请求必须携带 Mcp-Method 与 Mcp-Name 两个标头，使网关无需解析 JSON-RPC 正文即可按方法或工具路由、限流与计量，规范并允许把工具参数复制进标头做自定义路由。服务器发起的征询由保持开放流改为多轮往返：服务器返回 input_required，客户端收集答案后重试。授权侧弃用动态客户端注册（计划 2027 年夏季后移除），采用 RFC 9207 颁发者标识，并要求客户端以 RFC 8707 的 resource 发送规范服务器 URI 以绑定令牌受众。迁移可在既有有状态路由旁并行一条无状态路由后排空切换。
Audience
Who should care
#Next
Learning path
#- 先读两个标头那一节，判断你现有的网关或 WAF 能不能直接按 tools/call 加工具名做策略——如果能，你少建一层
- 再读征询被拆开那一段，把「等待人工响应」从单次调用里挪出来之后，超时、重试与状态归属分别落在谁身上
- 把 61 次调用那个数字当成一个可执行的检查：去数你自己那台 MCP 服务器三个月里的真实调用，以及其中多少来自你自己人
- 读《API 契约与接口边界》，重点看弃用窗口那一节——动态客户端注册有一个到 2027 年夏季的日期
Network
Where it sits in the network
#How this signal connects to neighbouring technologies, skills and background knowledge. Follow any link to keep exploring.
Further thought
Follow-up questions
#- 把工具名放进 HTTP 标头之后，它就出现在了网关日志与访问日志里——这是你想要的可观测性，还是一条新的信息泄露路径？
- 审批变成两个请求之后，「等待人类」这段时间的状态存在哪里？谁负责它的超时？
- 你那台 MCP 服务器上，过去三个月有多少次调用来自你自己人以外？
- 如果剥掉状态之后它确实就是一个 REST 端点，那么继续用 MCP 换来的到底是协议，还是一套模型已经会用的约定？
Publication record
Featured in
#The briefings that carried this signal, newest first; the last row is the weekly review of its week. The tag is the section it ran in.
技术简报 - 2026-08-17
Immediate attentionWeekly review · Aug 10 – Aug 16
Worth tracking
Sources