为什么大厂突然放弃MCP?

原创
🌻
陈哥聊测试
2026-08-14 16:00:00
30
摘要:为什么大家从使用MCP转向使用CLI?两种方案到底适合什么场景?普通开发者该怎么选?

大家好,我是陈哥。


最近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-and-cli-1

二、为什么大家不再用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-and-cli-1

三、那是不是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。

mcp-and-cli-3

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

前段时间,禅道也顺势推出了禅道CLI。大家可以备注【CLI】联系小助理了解详情:
禅道联系方式阿道

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

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

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


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


*参考资料:https://medium.com/@krishnan.srm/mcp-vs-cli-vs-skills-lets-get-a-better-understanding-87a2d52ff42b

推荐阅读

需求模糊?总被甩锅?四步厘清需求,新手产品经理必看

新手产品经理如何有效梳理需求,提升团队和客户的满意度?
🚜
禅道
07-14

破局 “卡脖子”,国产替代加速度!

近年来,网络安全事件频发,中美贸易摩擦、俄乌冲突引发的技术断供也足以见得国际局势的复杂性,在不同领域处于垄断地位的国外产品肆意涨价、频繁变动规则……这桩桩件件无一不推动我们加速摆脱对国外技术的依赖,构建自主可控的体系。
💍
禅道
2025-02-14

华为造车究竟成没成功,这个责任谁来担?

华为造车,一种很新的造车方式。
💍
IPD
2024-05-29

小公司管理:警惕大厂的“成功方程式”​

那些为上万人规模设计的流程,真的适合我们这几十人的团队吗?
💍
禅道
2025-07-23
返回顶部
客服头像
杨苗
高级客户经理
客服微信
13165050229
2692096539
统一服务热线 4006-8899-23
我要提问提问有任何问题,您都可以在这里提问。问题反馈反馈点击这里,让我们聆听您的建议与反馈。
gtm跟踪器
gtag
UET