MCP 概览AI Agent 的＂USB-C 接口＂正在被 CLI 抢走

MCP，全称 Model Context Protocol（模型上下文协议），由 Anthropic 在 2024 年 11 月推出。

到 2026 年，它已经成为 AI Agent 工具调用的事实标准——Claude Code、Cursor、Gemini CLI、OpenCode 等主流工具全部原生支持，GitHub 上冒出上千个开源 MCP 服务器。

但几乎在同一时间，它遭遇了来自 CLI 的强劲挑战。2026 年 3 月前后，"MCP 已死、CLI 永生"一度成为开发者社区最热的讨论之一。

这篇文章把这波争论拆开：MCP 是什么、从哪来、为什么大家开始嫌它、谁在弃用它、什么场景它仍然无可替代。

MCP 的定位非常单纯：它是 Agent ↔ 外部工具 之间的标准协议。

它把"每个工具如何被调用"封装成统一的 schema，模型只要按这个 schema 写请求，就能接入任何遵循 MCP 协议的工具。它和"程序 ↔ API"的接口在精神上类似，但专门为大模型的上下文窗口做了优化和标准化。

Anthropic 这个比喻点出了 MCP 的雄心：让 Agent 调用工具这件事，像插 USB-C 一样统一。理论上很好，现实里却撞上了几个硬约束。

2024 年 11 月，Anthropic 正式推出 MCP 开放标准，把"Agent 怎么调用工具"这件事从各家自定变成一个统一规范。

2025 年，Claude Code、Cursor、Gemini CLI、OpenCode 等主流 AI 开发工具陆续原生支持 MCP；GitHub 上开始涌现上千个开源 MCP 服务器，覆盖数据库、浏览器、代码仓库、本地文件等几乎所有常见场景。

2026 年，MCP 已经是 AI Agent 工具调用的事实标准——如果一个新出的 Agent 不支持 MCP，反而会显得奇怪。

2026 年 3 月前后，风向突变。一批代表性公司和人物开始公开弃用 MCP、转投 CLI，"MCP 已死 / CLI 永生"的讨论刷屏开发者社区。

很多人把 MCP 和 CLI 看作两套对立的方案，这是一个常见误解。实际上 MCP 本身的"实现"就跑在 CLI 上——你启动一个 MCP 服务器，它就是一个命令行进程；Agent 和它之间的"对话"，本质上就是命令行调用。

所以 MCP 和 CLI 不是对立，而是互补：MCP 提供"统一接口的规范"，CLI 提供"被调用的实现通道"。但正因为两者底层共用 CLI，一些原本被 MCP"标准化"藏起来的问题，在 CLI 阵营里反而被放大了。

MCP 不是被竞争对手打败的，而是被自己的设计限制拖慢了脚步。社区普遍提到三个固有问题：

这三点叠在一起，就给"反 MCP 阵营"提供了完整弹药：成本高、调试难、组合弱——而这三件事，恰恰是 CLI 的传统强项。

把"反 MCP"从社区情绪推向行业判断的，是 2026 年 3 月前后几个标志性事件：

· Perplexity CTO 在 2026 年 3 月的开发者大会上公开宣布：内部正在全面转向 API 和 CLI 工具，放弃 MCP。作为头部 AI 搜索公司，这一声明被视为"产业风向标"。

· 某知名 CEO（字幕中可能为 Y Combinator CEO）也公开选择 CLI 而不用 MCP，给整个创业圈放出明确信号。

· open cloud 这类 2026 年爆火的项目，内部几乎不用 MCP——它们直接把 CLI 作为 Agent 调用的首选通道。

三个事件指向同一波转向："MCP 已死 / CLI 永生"一度成为 2026 年 3 月开发者社区最热的讨论标签。

把 MCP 一棒子打死并不公平。在一些特定场景里，它仍然比 CLI 更有优势：

① 多租户与严格权限控制——国内一些 Agent 云平台允许用户上传自定义的 Python/Node MCP 包，统一鉴权、统一沙箱。这套机制能跑得通，靠的正是 MCP 标准化的安装包与健全的规范。

② 统一分发——CLI 没有标准化安装包，也没有统一的健全标准；想在云端做"统一安装分发"非常困难。MCP 在这一点上几乎是唯一成熟的方案。

③ 复杂推理——MCP 适合"需要 AI 推理的步骤"；CLI 适合"不需要推理的确定性操作"。两类任务天然有分工，强行用一边替代另一边都不划算。