大家好，我是陈哥。

最近 AI 圈又有了新变化，MCP 口碑开始发生反转。包括 Perplexity CTO、Y Combinator 核心团队在内的一众行业大佬，都公开表态要放弃 MCP，优先采用 CLI+API 的轻量化方案开发 Agent。

为什么大家从使用 MCP 转向使用 CLI？两种方案到底适合什么场景？普通开发者该怎么选？

本篇文章过长，建议大家收藏后观看。

一、MCP 和 CLI 是什么？

我的读者朋友基本上都是技术出身，但为了让大家更好地了解，我先简单介绍一下 MCP 和 CLI 是什么。

MCP（Model Context Protocol），简单理解就是一套 AI 工具调用的统一标准协议。它的初心很好，就是想做一套通用中间层，不管什么工具，只要接入 MCP，大模型就能统一识别、调用和管理，主打 “一次接入、全域通用”。

CLI（命令行工具），就是大家最熟悉的传统命令行模式。它可以直接通过指令调用工具并执行脚本，从而完成交互。

理论上，大家应该更倾向于去使用 MCP 而不是 CLI。

二、为什么大家不再用 MCP 了？

这得从今年 3 月份说起。

Scalekit 进行了 75 个基准测试，发布了一份 benchmark 报告：使用统一模型（Claude Sonnet 4），MCP 的成本比 CLI 最多高出 32 倍。

严重的 Token 浪费，这是第一个也是最主要的原因。

MCP 为了实现所谓的全量标准化，会强制把所有工具的完整定义、参数描述、身份验证流程、协议规范等，全部加载进大模型上下文中。

哪怕你只需要用到一个简单的查询功能，系统也会加载整套工具库的全部数据。

在 Scalekit 的实验中，对于执行 “这个仓库是什么语言” 这个简单的任务，CLI 只需要 1,365 个 Tokens，但 MCP 需要 44,026 个。

MCP 每次对话都要注入 43 个工具定义，就相当于每次开门，都要把整栋房子的结构图全部看一遍。工具越多、场景越复杂，Token 浪费的问题就越严重。

第二个原因是架构冗余复杂，开发运维成本极高。

MCP 不是简单接口对接，原本用 CLI 一行命令就能搞定的操作，接入 MCP 后，需要搭建服务、配置协议等，开发工作量直接翻倍。

我身边有开发说，用 MCP 开发，80% 的时间都在维护协议和服务，只有 20% 的时间在做核心业务。

它就像一套过度繁琐的行业标准手册，想要拧一颗螺丝，就得先通读整本手册，严重拖累开发效率。

而且 MCP 没有统一安全体系，每新增一个 MCP 服务，开发者都要重新做一遍账号、权限、密钥校验，每个服务单独维护一套身份权限。

这不仅增加开发负担，还会埋下大量安全隐患，完全违背了简化开发的初心。

第三个原因是存在原生架构安全漏洞，无法根治。

OWASP 中国发布的 MCP 安全白皮书指出，MCP 存在模型错误绑定、上下文欺骗、提示状态操纵、不安全的内存引用以及隐蔽信道滥用等问题。在涉及智能体 AI、模型链、多模态编排和动态角色分配的场景中，这些风险会更加显著。

换句话说，攻击者可以篡改上下文内容，诱导 Agent 越权执行高危操作。这个风险根植于协议底层，无法通过简单配置或者版本更新修复，对于企业级 Agent 应用来说，是绝对无法容忍的隐患。

三、那是不是 MCP 彻底没用了？

很多人在了解到 MCP 的弊端后，都会有个疑问：是不是 MCP 已经被淘汰了，没必要再用了？

MCP 的适用场景只是被压缩了，但只要开发场景合适就可以用 MCP。

这里给大家一句好记的选型准则：小规模重效率，选 CLI；大规模重规范，选 MCP。

接下来，我想讲讲日常开发中，大家容易踩的三个选型错误，帮大家精准避坑，实现两种工具的最优搭配。

错误 1：简单场景强行用 MCP

明明是普通简单的任务，用 CLI 就可以高效完成，开发者却硬要接入 MCP 服务器。

举个典型的例子：

当你用 MCP 服务器执行一个简单的任务时，哪怕你只需要用到 S3 功能，MCP 也会在正式执行任务前，一次性将 4 万 -8 万个 Token 都写入 AI 的上下文中。

在多步骤任务中，这个问题会被无限放大，直接压缩 AI 的的推理空间。一旦上下文被填满，AI 仅调用 3-4 次工具，就会遗忘之前的操作步骤，出现逻辑断层。

此外，MCP 服务器采用远程运行模式。一方面，会出现 TCP 超时、冷启动问题，导致任务执行过程中失败。

另一方面，规模化后，成本差异会非常显著：MCP 在 1 万次操作的情况下每月成本约为 55 美元，而 CLI 执行同等 GitHub 任务的成本仅为 3 美元。

所以，对于任何自带成熟官方 CLI 的工具，开发人员可以统一用 CLI 和 Skill 文件替换 MCP。

错误 2 ：专业合规场景误用 CLI

CLI 一般使用预配置好的共享密钥凭证，并不适配多租户 SaaS 产品架构。简单来说，所有用户的 AI 会共用一套账号身份，会出现 A 用户误操作干扰 B 用户的数据的风险。

而且 CLI 也没有针对每个用户的审计跟踪，不满足一些企业的合规要求。HIPAA、PCI-DSS 和 SOC 2 要求记录 “谁在什么时候做了什么”，而原始 CLI 根本无法回答这个问题。

因此，面向客户的业务流程或者高合规要求的集成场景，建议统一使用 MCP。

四、为什么大家一夜间都在用 CLI？

CLI 之所以会成为当下 AI Agent 开发的主流选择，是因为它适配现阶段大家的需求：

• CLI 比较轻量化，按需调用、即用即走，大幅降低推理成本和响应延迟。
• CLI 可调试性拉满。作为沿用数十年的开发模式，CLI 的日志、报错、排查链路极其完善，出问题能快速定位修复。
• CLI 可组合性极强。开发者可以自由组合指令来适配业务场景，更贴合一线落地场景。

最后，技术永远是实用主义至上，能用最简单的方式解决问题，就绝不叠加复杂架构。

你现在更喜欢用 MCP 还是 CLI？欢迎在评论区聊聊你的真实体验。

* 参考资料：Krishnan Sriiam:MCP vs CLI vs Skills -- Let’s get a better understanding.