这个夏天，做 AI 插件开发的人，大概都被舆论晃了一下腰。一边是「MCP 已死，CLI 称王」喊得震天响；另一边，AWS、Cursor、Microsoft、OpenAI、Vercel、Google 六家公司 8 月初刚联合发布了一个新的插件规范，干的恰恰是把 MCP 服务器重新打包进统一插件的活。MCP 到底是凉了还是赢了？我把最近三周的事件和数据捋了一遍，文末附一张选型表，看完你再决定押哪条路线。
「MCP 抛弃派」有声音，也有数字
先看最硬的数字，炮火集中在 MCP 的「全量加载」机制上：连接3个MCP Server，仅工具定义就占用约143K token。在200K token的模型上，72%的上下文被工具定义吃掉。知乎Agent 还没开始干活，上下文窗口已经先满了。还有一个被反复提到的「上下文腐烂」现象：工具数量一多，模型选工具的准确率会从 43% 跌到 14% 以下——工具越多，选得越乱。
阵营也不小：从Perplexity CTO公开宣布放弃MCP，到Y Combinator CEO直言“MCP sucks”，再到飞书、钉钉、企业微信等大厂纷纷选择开源自家的CLI而非MCP。知乎他们共同转向的正是 CLI：几十年的 Unix 文档和 shell 脚本本来就在模型训练数据里，模型天生会用 git、curl、grep，不用写一行 schema，Karpathy 的说法是 CLI 让人兴奋正是因为它是遗产。有实测显示 CLI 方案比 MCP 方案便宜 17 倍，可靠性接近 100%，而且按需加载——Agent 要用先跑一下 --help，而不是开局把工具定义塞满上下文。
但说「MCP 已死」，数据也不答应
直接打脸抛弃派的第一件事：7月28日，MCP 官方发布了协议历史上最大的一次修订——2026-07-28 规范，协议核心从有状态彻底转向无状态，握手和会话双双被砍掉。知乎翻译成人话：每个请求自带身份和能力说明，可以落到负载均衡后面的任意实例，不再需要共享会话存储，像普通 HTTP 服务一样横向扩容。
市场数据同样不支持「崩盘论」：MCP的Tier 1 SDK月下载量已经逼近5亿，TypeScript和Python两个SDK的总下载量都已突破10亿大关。而在Claude这一侧，连接器目录里收录的MCP服务器已经超过950个，每天被数百万用户使用。知乎新规范发布当天，Anthropic 就宣布 Claude 系产品率先跟进适配。
有一个口径值得较真。抛弃派的文章说 MCP「月下载量一度超过9700万次」，繁荣派说「Tier 1 SDK 月下载逼近 5 亿」。两个数字乍看差了 5 倍，其实统计范围写得不一样：后者明确是四个官方 Tier 1 SDK 的合计现值，前者没说包含哪些 SDK、哪个时间段。两边都在挑对自己最有利的数字说事，所以别急着站队，先看结构。
安全是两边都不爱提的账
不管押 MCP 还是押 CLI，这笔账都绕不开：安全研究人员已发现近7,000个暴露在公网的MCP服务器，其中约半数没有任何授权控制。知乎你接进来的每个工具，本质上都是一组握着凭据的接口。
做企业安全的人说得更直白：我有一个核心判断——每接入一个工具，就等于给Agent、也给潜在的黑客，多发了一把钥匙。而多数企业发出去的，是一大串万能钥匙，不是用完即焚的临时门禁。36氪所以无论走哪条路线，网关、最小权限、全链路审计都是必选项，不是可选项。
再看一眼：他们争的其实是三层不同的东西
看到这里结论其实有了：两种叙事各对一半，因为它们争的是三个完全不同的层，而各自都只盯着自己那一层。
连接层，MCP 已经基本赢了。喊 CLI 喊得最响的阵营，反对的也不是「用标准协议连外部服务」本身，而是把全量工具定义塞进上下文的做法。新规范的方向很明确——无状态、可缓存、工具名直接进 HTTP 请求头、OAuth 对齐生产标准，全是冲着企业落地去的。有工程分析把这种位移说得很准：MCP 正从“Agent 的通用插座”，向“企业 AI 能力总线的线协议”靠近。知乎
轻量执行层，CLI 在回归。飞书开源的官方 CLI 有 200 多条指令，覆盖 11 个业务领域，内置 19 种 Agent Skills，Google、Zilliz 也都推了自家 CLI。这一层的逻辑是：能用命令加帮助文档解决的事，就别多一层协议，自用脚本和内部自动化尤其合适。
打包分发层，是这个月的新战场。Skill 和 MCP 服务器各自都可移植，不可移植的是外面那层包装。六家公司联合下场做的 Agent Plugins 规范，争的就是这一层。
Agent Plugins：一个目录，打包一切
它解决的痛点，维护过多端插件的人秒懂：如果同一套 AI 编程工具要同时给 VS Code、命令行 Agent 和桌面端 Copilot 使用，最容易出现的不是“不会配置”，而是三份配置慢慢不一样。今日头条Skill 本身是可移植的，MCP 服务器也是可移植的，不可移植的是外面那层包装——目录结构、manifest 字段、MCP 配置的形状，每个客户端都得重新发明一遍。
8月6日，一个叫Agent Plugins的规范发布了1.0.0版本。发起方是一个技术指导委员会，成员来自Amazon、Cursor、Microsoft、OpenAI和Vercel，Google同步宣布作为核心维护者加入。今日头条设计上它克制到几乎没有学习成本：一个插件就是一个目录，根目录的 plugin.json 只有两行实质内容——一个 schema 声明、一个 name 字段；skills/ 子目录放技能，mcp.json 声明 MCP 服务器，客户端私有内容塞进反向域名目录，不认识的客户端直接忽略，单个组件失败也不会拖垮整个插件。
落地节奏比想象中快：GitHub 官方 8 月 12 日发公告，确认标准已在 VS Code 和 GitHub Copilot 的 CLI、SDK、app 中普遍可用，原有的 skills 和 MCP 配置继续支持，没有强制迁移要求。但也要泼盆冷水：v1 只管打包，它不定义安装机制、不做权限模型、不做沙箱要求、不做信任验证——这些问题被刻意留白，写进了公开的 future considerations 文档里。
眼下最大的悬念是 Anthropic。官方 Compatible Clients 页面目前列出的兼容客户端是 Kiro、GitHub Copilot、Cursor、VS Code、ChatGPT & Codex。Anthropic / Claude Code在初期支持列表中也不处于核心位置。今日头条一边是把 MCP 和 Agent Skills 带火的公司，一边是不以它为中心的打包标准：后面跟进，这套规范就是事实上的行业标准；不跟进，插件生态就裂成两半。这是未来三个月最值得盯的变量。
对企业用户，新版 MCP 把后半程的活留给了你自己。有工程分析给出的建议是把企业架构分成四层，平台层负责共性控制，业务 Server 负责能力语义，不必再造一个万能 MCP 平台。知乎
选型表：五个场景，三条路线
最后给承诺的选型表，按你自己的处境对号入座：
你的场景 | 建议 | 一句话理由 |
|---|---|---|
自用、只服务一个客户端 | 维持现状，CLI + Skill 够用 | 只有一个客户端、一个简单 MCP server 时，保留现状最省时间 |
做对外开放的服务 | MCP，且直接按 2026-07-28 新规范写 | 无状态好扩容，请求头路由方便网关做策略，OAuth 对齐企业身份系统 |
能力要分发给多个客户端 | Agent Plugins 最小包 | plugin.json + skills/ + mcp.json，一次编写多端读取；但别指望它管权限和沙箱 |
企业内部落地 | MCP + 统一网关 | 版本协商、工具级鉴权、限流幂等、审计，统一收在网关层 |
传统浏览器 / IDE 插件开发 | 暂不受影响 | 这轮战火目前集中在 AI Agent 插件领域 |
补充一点：如果团队没有在多个客户端之间来回切换、配置也没复制到两三份，不必为了新标准硬迁移——标准化不是目的，减少重复维护才是。
再附送一个马上能动手的实操点：无论走哪条路线，把工具描述写好。LLM 选工具时真正参与计算的只有 name、description、inputSchema 三个字段。今年 6 月有论文扫描了 2,214 个 MCP Server 的 19,200 对描述-代码对，发现 9.93% 存在描述-代码不一致。知乎近一成的 server 描述说的是 A，代码干的是 B——先自查描述，再抱怨 AI 不调用你的工具。
接下来值得盯的四个信号
这件事还没完，四个信号值得标记追踪：
Anthropic / Claude Code 是否跟进支持 Agent Plugins——直接决定这套规范是事实标准还是半壁江山；
新规范的无状态、缓存与请求头路由，实际被多少客户端实现、会不会成为企业网关的采购标准；
暴露的 MCP 服务器风险，会不会从研究数据变成真实安全事故；
飞书、钉钉、企业微信们的 CLI + Skill 生态，能不能从官方开源走到第三方开发者真正用起来。
你的插件或工具现在走的是哪条路线？MCP、CLI，还是还在维护三份越改越不一样的配置？评论区聊聊。觉得表格有用就先收藏，下个月再来对一遍这四个信号。
