我做高德地图 AI 实测那期时，在 MCP 和 CLI 之间挑了 CLI，写了三个放弃 MCP 的理由：门槛高、占脑容量、不能串流水线。

今天 Anthropic 发布 MCP 2026-07-28，我读完规范，发现这三个理由被一个个补上了：无状态化降门槛、列表缓存省脑容量、Tasks 支持长流程。

这不是一次普通的版本更新。MCP 月下载量已经 4 亿次，TS+Python 累计 10 亿次，Claude 应用商店 950+ 服务器。这次更新把 MCP 从"能连"变成"能上线"，是 AI 智能体从玩具走向企业生产的分水岭。

我对 MCP 的判断，从"能力最弱"变成了"绕不开的那一层"。

读完这篇你就知道，为什么我说 MCP 这次不是版本号迭代，是判断要重写的节点。

做高德地图 AI 实测那期时，我在 MCP 和 CLI 之间挑了 CLI。当时高德给了三样东西：MCP、CLI、还有一个桌面窗口，我最后挑了 CLI。理由很实在——MCP 当时有三个让我绕不开的痛点，我那期文章里写得很直白：MCP 给 AI 的是一个按钮，只能一个一个按；CLI 给的是一门语言，能串成流水线。

这个判断我扛了挺久。直到今天读完 2026-07-28 规范，我才发现，我当时的三个理由，这次被一个个补上了。

我当初为什么放弃 MCP

先说清楚我当时放弃了什么。我当时给 MCP 的定位是"给 AI 装工具的通行标准"，地位我认，但实操里我没选它。三个理由：

理由一：门槛高。 老 MCP 要求你的 AI 软件本身支持它、要改配置文件、要重启。CLI 不用，任何一个能敲命令的 AI 立刻就能用上。这是最大公约数。

理由二：占 AI 的脑容量。 MCP 一连上，就得先把所有工具的说明书塞进 AI 脑子里，占着地方。CLI 是"要用的时候才去翻说明书"，不用的时候一点不占。

理由三：不能串成流水线。 这条最实在。MCP 只能一次一次地按，做不到让 AI 写个小循环一口气跑完几十条。CLI 能。

还有一层我当时没明说但写进了文章：品牌防守。MCP 是中立地带，工具长什么样用户看不见。而自己搞一个窗口，至少那张底图上还印着自己的 logo。在一个"界面正在消失、品牌跟着消失"的年代，这是为数不多还能露脸的地方。

这四个理由，就是我当时对 MCP 的全部判断。它没错，但不够好用。我扛到今天。

三个理由，被四个补丁定向爆破

读完规范我才发现，这次更新不是漫无目的的修修补补。Anthropic 在过去 18 个月里从海量生产环境汲取教训，把开发者放弃 MCP 的那些理由，一个一个定向爆破掉了。我当时的理由，正好对上补丁。

痛点①门槛高 → 补丁：无状态化。 核心改成请求/响应模型，删掉握手、删掉 Session-Id，每个请求在 _meta 里自描述。任意节点接手，Serverless、Edge、轮询负载均衡器全部打通。以前挂个负载均衡器都没法跑，现在挂上就能跑。

痛点②占脑容量 → 补丁：列表缓存。 tools/list 协议层自带生存时间（ttlMs）和缓存作用域，客户端能制定最优缓存策略。Prompt cache 就是钱，这是把缓存策略从"各写各的"统一成协议约定。

痛点③不能串流水线 → 补丁：Tasks 扩展。 基于轮询的 tasks/get 和 tasks/update，变更通知统一到 subscriptions/listen 数据流。断线能续跑，这才是 Agent 工作流的协议层支持。以前跑个"分析 100GB 日志"这种几小时的任务，协议层根本接不住。

痛点④品牌看不见 → 补丁：MCP Apps。 服务器在聊天界面的沙盒 iframe 里渲染交互式 UI。查营收直接出动态报表，操作云服务器直接弹控制面板。品牌回来了，界面也回来了。

四个理由，四个补丁，不是巧合，是定向爆破。我那期写的那三个理由，本质上是所有 MCP 开发者都会撞到的墙。这次更新不是加功能，是把"能连"和"能上线"之间那堵墙拆了。

以前是"能连"，今天是"能上线"

别家博主都说"从玩具到基础设施"，但没讲清楚为什么这次是分水岭、以前不是。答案很简单：五块拼图一起补齐，缺任何一块都不是。

这五块是：无状态（解决扩容）、MCP Apps（解决交互）、Tasks（解决长流程）、OAuth/OIDC（解决安全）、Tunnels（解决内网）。之前的任何一版 MCP，都只补了其中一两块。能连和能上线之间，差的恰恰就是这五件事。2026-07-28 一次把五块全补齐，这才是"分水岭"三个字的真正含义。

细节里还有三个被低估的工程务实点：

MRTR（多往返请求）取代长连接。 工具执行到一半需要用户输入时，服务器返回 input_required 并附带问题，客户端回答后带着 inputResponses 重新发起调用。完美契合无状态，砍掉了冗余的长连接。

Header 路由。 可流式 HTTP 请求现在必须包含 Mcp-Method 和 Mcp-Name 两个请求头。网关、限流器、WAF 防火墙不用再解析 JSON 主体就能路由计费。这把 MCP 从"应用层协议"提升到了"基础设施友好协议"——HTTP 当年也是靠 Header 路由撑起整个 CDN 生态。

Auth 硬化。 这次不是简单"支持 OAuth"，是定向爆破 OAuth 落地最恶心的几个坑：RFC 9207 发行者验证堵死授权服务器混淆、弃用 DCR 转向 CIMD 解决 CLI 客户端的 localhost redirect_uri 毒瘤。这个 redirect_uri 的坑我去年折腾 MCP OAuth 时亲自踩过，能多花半天查 Stack Overflow，这次更新把它彻底拔了。

它走的和 HTTP 是同一条路

"分水岭"这三个字不是 Anthropic 自己喊出来的，是协议走过一条完整的治理路径才到的。这条路径，和 HTTP 当年几乎一模一样。

MCP 的时间线：2024-11 首版（Anthropic 自家协议，我做高德那期用的就是这版，那时候它还是"能用但不够好用"）→ 2025-06 第三版（首次支持远程，但双向有状态，部署扩容很难，这就是我放弃它的技术背景）→ 2025-12 捐给 Linux 基金会（治理中立化，成为行业标准的必要条件）→ 2026-07-28 第五版（核心改无状态、扩展升级为一等公民、Auth 硬化，五块拼图齐到位）。

HTTP 呢？1991 年诞生在 CERN 自家 → 1995 年捐给 IETF 中立治理 → 1997 年 HTTP/1.1 稳定下来一统天下 20 年。三步走：诞生 → 中立治理 → 企业稳定版。

MCP 走完了同样的三步：2024 自家协议 → 2025 捐 Linux 基金会 → 2026-07-28 企业稳定版。我那期讲的 MCP 是第一步的 MCP，今天的 MCP 是第三步的 MCP。它们叫同一个名字，但已经不是同一个东西了。

不是嘴上祝贺，是真贡献

任何协议能不能成为行业标准，不光看底层技术，更看顶尖商业生态买不买账。但这次背书里，最值钱的不是贺电，是真贡献。

Google 的 OSS 团队 co-led 了 Transport 工作组，把 Google Cloud 数据库 MCP 工具的扩容经验写进了协议——不是来站台子的，是来干活的。Netlify 因为 Serverless 基因和无状态化天然契合，day-one 支持。Figma 验证了无状态架构能跟着用量一起扩、配合 MCP Apps 让设计和代码在一个连接流里保持同步。Intuit 需要金融级的绝对安全认证，Zoom 需要极低延迟的通信响应，新版 MCP 同时满足了这两个看似矛盾的生产级需求。

这五家放一起看，规律很明显：每家都从自己的业务痛点出发，验证了 MCP 2026-07-28 满足某一项生产级需求。Google 验证扩容、Netlify 验证 Serverless、Figma 验证交互、Intuit 验证安全、Zoom 验证延迟。这不是 PR 稿里"我们很兴奋支持 XX"的客套话，是每家都拿自己的核心场景下注。

我对 MCP 的判断，从"最弱"变成"绕不开"

我那期给 MCP 的定位是"给 AI 装工具的通行标准"，但实操里挑了 CLI。今天读完 2026-07-28，我对 MCP 的定位要改成另一句话：AI 智能体上生产的基础设施。

HTTP/0.9（1991 年）只能传 HTML，是玩具。HTTP/1.1（1997 年）核心稳定、可扩展、企业可用，一统天下 20 年。HTTP/0.9 到 HTTP/1.1 之间，差的不是"能传数据"，是"能上生产"。MCP 走的是同一条路：以前的 MCP 像 HTTP/0.9，能连；2026-07-28 像 HTTP/1.1，能上线。再加上 2025 年 12 月捐给 Linux 基金会这一步（对应 HTTP 1995 年捐给 IETF），治理路径完全对齐。

HTTP 用了 6 年从玩具变成一统天下的协议，MCP 用了 18 个月走完同样的路。

这些代价，必须说清楚

判断改了，但该泼的冷水得泼。这次大改不是没有代价：

• MCP Tunnels 还是研究预览版，不是稳定版，企业生产环境别急着 all-in，等正式发布。
• Rust SDK 还在 Beta，四大 Tier 1 SDK（TypeScript、Python、Go、C#）已同步更新，Rust 生态要再等等。
• 12 个月弃用政策：旧版 Roots、Sampling 以及旧的 HTTP+SSE 传输机制在未来一年内依然能工作，但一年后强制下线。迁移不是明天的事，但也不是能一直拖的事。
• 无状态化的代价：会话状态从传输层上移到工具层，你要自己设计 Handle 的生命周期、过期策略、清理逻辑。这是把复杂度挪了位置，不是消除。
• 生态换血需要时间：950 个服务器里，大部分还是按老规范写的，新版红利要等生态逐步迁移。我那期测的高德 MCP，现在也还没说什么时候迁移。
• CLI 不是没用：CLI 的最大公约数优势还在，短期里 CLI 和 MCP 会并存，不是二选一。但长期看，MCP 这次补齐后，CLI 的优势窗口在收窄。

我那期说 MCP 是"能力最弱的那个选项"。今天读完 2026-07-28，我要把这句话收回来。它不是能力最弱，是当时还没长好。

如果说曾经 HTTP 协议将全世界的电脑连成了互联网，那么现在 MCP 协议正在把全世界的软件、数据和 API，连接成一个由 AI 大脑统一调度的全新网络。而 2026-07-28，就是这张网从"能连"变成"能跑生产"的那一刀。

资料来源（关键数据均回原文逐字核实）

• Anthropic 官方博客：claude.com/blog/bringing-mcp-2026-07-28-to-claude（2026-07-28）
• MCP 规范 2026-07-28：modelcontextprotocol.io/specification/2026-07-28
• GitHub Release：modelcontextprotocol/modelcontextprotocol · tag 2026-07-28
• ClaudeDevs 官推：x.com/ClaudeDevs/status/2082164248697069935
• Google OSS 官推：x.com/GoogleOSS/status/2082223674128814080（co-led Transport WG）
• Netlify 官博：netlify.com/blog/mcp-goes-stateless-and-extensible
• 36 氪报道：新智元 2026-07-29《Claude 最大规模 MCP 升级，月下载狂飙破 4 亿》
• 我之前的 MCP 判断文章（高德那期）：本文"以前"部分的锚点

本文信息交叉自 6 路来源：官方博客 + GitHub Release + ClaudeDevs/GoogleOSS 官推 + Netlify 官博 + 36 氪报道 + 我之前的实测判断。所有数据带时点：4 亿月下载 / 10 亿累计 / 950+ 服务器均为 2026-07-28 官方披露快照。12 个月弃用政策自 2026-07-28 起算。MCP 是开源协议，本文与 Anthropic 及各厂商无利益相关。

你现在用 MCP 还是 CLI？评论聊聊，我按密度排后面怎么讲。

关注我，每周拆一套能直接抄的 AI 工作流。