大家好我是陈哥。这段时间内, 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 美元。所以, 对于任何, 自带成熟官方 CLI 的工具, 开发人员能够统一地, 用 CLI 和 Skill 文件, 去替换 MCP。错误 2 专业合规场景误用 CLICLI通常运用预配置好的共享密钥凭证, 它并不契合多租户SaaS产品架构。简而言之, 所有用户的AI会共同采用同一套账号身份, 存在A用户误操作对B用户的数据造成干扰现象的风险。并且CLI并没有适配针对每个个体用户的审计跟踪举措, 这不符合一些企业所具备的合规要求, HIPAA、PCI-DSS以及SOC 2都规定要记录“谁在何时干了何事”, 然而原始的CLI根本没办法对这个问题予以解答。所以, 针对面向客户的业务流程, 或者是高合规要求的集成场景, 这里建议统一运用MCP。四、为什么大家一夜间都在用CLI前不久, 禅道也顺着形势推出了禅道CLI, 安装完成之后, 凭借让 AI 通过特定方式去实现对禅道的调动。现阶段大家的需求, CLI能够适配, 所以CLI这才成为当下AI Agent开发的主流选择。最终, 技术向来是以实用主义为最高准则, 当能够凭借最为简单的门路去处理难题时, 就绝对不会增添繁杂的架构。你如今是更倾向于运用MCP, 还是CLI, 欢迎于评论区去讲讲你的真切体验。你提供的内容不完整且表述模糊, 不太明确具体需求, 请补充完整准确的句子以便我恰当改写。