7月28日，MCP发布了诞生以来最大的一次规范修订，官方措辞是"largest revision since launch"——协议核心直接从有状态改成无状态。知乎41天过去，Tier-1 SDK已对齐新规范，Roots、Sampling、Logging的12个月弃用倒计时已经跑表。知乎对还在维护MCP Server的开发者来说，问题已经从"这次改动该不该吵"变成了"我的服务什么时候变成不合规"。
这篇不是规范翻译，而是过去41天知乎等平台上一线实践经验的合账，外加一份分层迁移清单。
一、这次改版，跟以前哪不一样
把五个版本放在一条线上（据@NNNNzs与@数据与AI爱好者两篇changelog梳理）：
2024-11：初版，Tools/Resources/Prompts三大原语，JSON-RPC 2.0；
2025-03-26：补OAuth 2.1，HTTP+SSE换成Streamable HTTP，`Mcp-Session-Id`诞生；
2025-06-18：结构化工具输出与Elicitation，上一版刚加的Batching被删；
2025-11-25：实验性Tasks、Extensions框架，属于填坑版本；
2026-07-28：移除握手与会话（SEP-2575/2567），新增`server/discover`做版本探测，MRTR取代服务端发起请求，Header路由（`Mcp-Param-`前缀），列表响应带`ttlMs`/`cacheScope`，Roots/Sampling/Logging正式弃用，旧HTTP+SSE传输进弃用期。
真正的破坏点就两处。第一，“先握手再通信"整个没了，每个请求用`_meta`字段自带协议版本和客户端能力，服务端不再维护会话——那句被收藏46次的判断是原话：之前所有基于「会话」写的MCP Server，基本要推倒重来。知乎第二，规范第一次写入正式生命周期策略（SEP-2596）：弃用功能必须保留至少12个月才能移除，也就是说，这次不是"改不改随你”，而是给了一个会到点的deadline。知乎
但砍掉的东西确实不心疼。断点续传、消息重发这些长连接红利，在MCP场景里收益有限，反而抬高实现和调试成本——这是@NNNNzs把"有点激进"改口成"简化值得"的原因。而无状态真正打开的是部署侧：Server可以扔进Lambda、Cloudflare Workers这类Serverless/边缘环境，挂在最普通的轮询负载均衡后面做水平扩展。知乎新智元
二、41天里，社区吵成了三派
务实派：迁移是排期问题，不是立场问题，如上。
骂声派：以@waterwu（24赞）为代表——无状态的方向是对的，但在他看来，这终究是"对MCP这个糟糕玩意的狗尾续貂"；蛋疼就蛋疼在它成了大家都对接的事实规范，“好吧，总比没有规范的强”。知乎他欣赏pi那种极简工具集路线（只有read/write/edit/bash，“再加一个http就行”）。
但这篇回答最有意思的是后半段：他自己做运营用MCP的做法，是先写CLI、再包装成MCP——就为了能接进WorkBuddy这类桌面应用，让非技术用户不用碰npm和node环境。知乎嘴上回归命令行，身体诚实地服从了生态。OpenClaw作者走的正相反（做mcporter把MCP包成CLI），两条路殊途，但都得穿MCP这层壳。
定位还原派：@数据与AI爱好者在"为什么skills优于MCP"（浏览36万+）下的判断：Skill是告诉模型"怎么做"的知识组件，MCP是供调用的工具，Skill里还能嵌套MCP工具，"谁优于谁"本身就是伪问题。知乎这个回答只有28赞——误解的传播速度远快于澄清。
至于"生态凉了没"，官方口径的数据（属厂商自披露）：MCP月度SDK下载量突破4亿、年内增长4倍。新智元Claude应用商店里的MCP服务器超过950个。跟"MCP死了"放一起看，才是完整的舆论现场。
把争吵收进框架的是@增殖的指名者那篇32赞回答：工程方案要放回基座模型能力的时间轴看。2024年模型的病是"说明写清楚也用不对工具"，MCP的重是为当时的模型能力付的工程补偿；今天模型强了，简单场景硬套MCP确实浪费token，CLI也香——但复杂权限、跨系统标准化接入、企业级治理，CLI不是最好的抽象。知乎没有谁赢，只有适用边界在移动。
三、比迁移更急的一笔账：你的工具清单吃掉多少token
@小爝拆过Chrome DevTools MCP：它带26个工具，你只想截个图，就得先把另外25个工具的完整说明全部装进上下文。知乎他给出的三组数字，是近两个月被引用最多的：
假设接10个中型Server × 20个工具 × 每个描述200 token：还没干活，4万token没了；
把26个工具的启动占用从5200压到380，砍掉93%——做法是把"发现"和"使用"拆成两级加载；
翻真实项目的调用记录：78%的工具描述从头到尾没用上，全程占着窗口、稀释注意力。
也就是说，Agent越用越笨，多数时候不是模型降智，是窗口被无关工具描述污染了。而lazy-load至今还是各家Client自己拼的野路子——官方SDK的`list_tools`把`inputSchema`捆在一起返回，没有协议层保障。知乎一个值得留意的对照：7-28版给列表结果加了`ttlMs`/`cacheScope`、要求工具列表确定性排序，相当于把"清单缓存+prompt cache命中"的地基打好了，但"分层披露"只走了一半。知乎
小爝的判断可以记进观察名单：协议原生引入工具元信息/schema分层、多Server路由索引，会是下一个中间件竞争点。知乎风险也要讲：懒加载把摘要质量变成新命门——写短了模型选不出，写长了退回全量加载，目前无通用解。
四、分层行动清单：三种人，三张任务单
你是谁 | 现在就得动 | 可以等 | 继续盯 |
|---|---|---|---|
只接别人Server的用户 | 查客户端是否还挂在已弃用的旧HTTP+SSE传输上（12个月过渡期） | SDK对齐是客户端的事 | 新Server是否声明支持2026-07-28 |
维护自建Server | 三件：去掉会话态、补`server/discover`；服务端发起的sampling/elicitation改写成MRTR的`input_required`两段式；DCR换成Client ID Metadata Documents并补RFC 9207 iss校验 | Tasks、MCP Apps按需再接（扩展是可选的）；Roots/Sampling/Logging只弃用未移除，明年7月前收口 | 需要跨调用保留状态的，用官方推荐的显式Handle当工具参数传，别藏传输层 |
准备写新Server | 直接按无状态起步，吃Serverless+负载均衡红利 | 无 | 工具描述按token预算写，一句话摘要写清"什么时候用我"；要接企业IdP（Entra/Okta）的，这版的EMA已经理顺 |
一句话给这三档人：这次迁移不是学新玩具，是给已有资产排到期日。
五、还有两个信号值得追
其一，MHS。8月27日Anthropic发布了面向物理设备的新标准ModelHardwareStandard（目前只是research preview），让Agent像调MCP工具一样操控显微镜、机械臂、液体处理器、激光器。机器之心但注意一个流传很广的误解——“Claude肉身降临接管全球设备”"硬件版MCP"这些爆款标题都扣错了对象：MHS是独立配套标准，不是MCP改硬件版，专门发澄清回答（23赞）才勉强跟上误读。知乎对做工具接入的开发者，值得盯的不是机器人本身，而是它与MCP的分工边界。
其二，弃用窗口的终点。12个月倒计时已走了三分之一。到明年年中，Roots/Sampling/Logging一旦被移除，没迁移的存量Server面对的就不是"不优雅"，而是"接不上新客户端"。手上正好有这类服务的，与其等deadline，不如当一次性的技术债清算。
模型还会继续变强，CLI派和协议派明年大概率还要再吵一轮。但对今天正在维护Agent工具链的人，规范已经把方向定死：状态要么显式建模成模型看得见的Handle，要么就不该存在。先把账算出来，再决定这个Sprint排什么——这是这件事值得所有Agent开发者停下来看一眼的全部理由。
