MCP的口碑出现了反转, CTO等一众大佬纷纷转向了CLI加上API的轻量化方案。Token的浪费高达32倍, 架构存在冗余情况, 安全漏洞成为了三大痛点。不过MCP并未过时, 选型要看具体场景, 小规模注重效率的选择CLI, 大规模注重规范的选择MCP。本文对两者的优劣进行了深度解析, 帮助你精准避开坑。就在最近, AI这个圈子里又出现了新的改变情况, 而那MCP原本的口碑开始出现了反向转变。一众属于行业里大佬级别的人物, 其中涵盖了CTO, 还有Y核心团队等, 都公开表明态度说要舍弃掉MCP, 优先去选用CLI加上API那般的轻量化方案来开展Agent的开发工作。为啥众人由运用MCP转而运用CLI? 那两种方案究竟适用于啥场景? 普通的开发者该做出怎样的选择?本篇文章过长建议大家收藏后观看。一、MCP和CLI是什么我的那些读者朋友几乎全都是技术方面出身的, 只是呢, 为了能够让大家更加好地去进行了解, 我先来简单地介绍一下, MCP到底是什么, CLI到底是什么。MCPModel, 从简单的方面去对其进行理解, 它实际上就是那样一套用于AI工具调用的统一标准协议 , 它有着挺好的初心 , 仅仅是想要制作出那样一套通用中间层 , 不论到底是何种工具 , 只要是将其进行接入MCP , 那么大模型就能够实现统一识别 , 然后进行调用此外还能进行管理 , 它所主打强调的是“一次接入、全域通用”。CLI, 也就是大家极为熟知的那种传统命令行模式呢。它能够借助指令去调用工具, 还能够执行脚本, 进而达成交互。理论上大家应该更倾向于去使用MCP而不是CLI。二、为什么大家不再用MCP了这得从今年3月份说起。展开了七十五个基准测试, 公布了一份报告, 运用统一模型4, MCP的成本相较于CLI, 至多有高出三十二倍的情况。严重的Token浪费这是第一个也是最主要的原因。MCP进行所谓全量标准化时, 会强制行动, 将所有工具的完整定义拿去加载, 把参数描述加载进大模型上下文中, 把身份验证流程加载进去, 还把协议规范也加载进大模型上下文中。不管你仅仅是所需用到一个简易的查询功能, 系统都会去加载整套工具库的所有数据。于实验当中, 当开展执行一项名为“这个仓库是什么语言”的不太复杂的任务之时, CLI仅仅只需1,365个, 然而MCP却需要44,026个。MCP只要进行对话, 就得注入43个工具定义, 这就如同每次开门时, 都得将整栋房子的结构图全部看上一遍。工具数量越多, 场景越是复杂, Token浪费的问题便越是严重。第二个原因是架构冗余复杂开发运维成本极高。MCP并非单纯的接口对接, 原本那些只需用CLI通过一行命令便可完成的操作, 在接入MCP之后, 得去搭建服务, 还得配置协议等等, 开发的工作量直接就翻倍了。我身旁那些搞开发的表述, 言道运用MCP来搞开发, 占据八成左右时间的是在维系协议以及相关的服务供应, 仅仅只有剩下的两成时间是用于从事核心业务方面的工作。它好似一套极为繁杂的行业标准手册, 若要拧一颗螺丝, 居然得事先通读整册手册, 极大地拖累了开发效率。并且, 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 来讲, 去执行同样的任务时, 其成本仅仅只有 3 美元。因此, 针对任意自带成熟官方命令行界面的工具而言, 开发人员能够以统一的方式, 借助命令行界面以及技能文件去替换主控制处理器句号。错误 2 专业合规场景误用 CLICLI通常运用预先配置妥当的共享密钥凭证, 而并不契合多租户SaaS产品架构。简而言之, 所有用户的 AI会共享一份账号身份, 存在A用户的误操作致使 B用户的数据受干扰的风险。并且CLI并没有针对每一位用户的审计跟踪, 无法满足某些企业的合规要求。HIPAA要求记录“谁在何时做了何事”, PCI-DSS也要求记录“谁于何时干了什么”, 还有SOC 2同样要求记录“何人在啥时候做了何事”, 然而原始CLI根本就没办法回答这个问题。于是, 针对于面向客户的那一些业务流程, 或者处于高合规要求状况下的集成场景而言, 给出的建议是统一把MCP拿来使用。四、为什么大家一夜间都在用CLI前一阵子, 禅道也顺着形势推出了禅道CLI, 安装完毕之后, 就能够经由使你的AI去促使禅道。当下AI Agent开发的主流选择是CLI, 这是因为二者阶段大家的需求它进行了适配:最终, 技术向来是以实用主义为最高准则, 倘若能够运用最为简便的途径去化解问题, 那么就绝对不会增添繁杂的架构。参考资料你提供的内容似乎不完整且不太明确, 请检查补全并清晰表述后, 以便我能准确按照要求改写。