为什么越来越多的大厂抛弃MCP，转向CLI？

一、MCP的底层原理在理解MCP的问题之前我们先看看它的工作原理。MCPModel Context Protocol是一个客户端-服务器架构的协议专门用来把外部工具如文件系统、数据库、GitHub API“包装”成AI模型可以调用的函数。MCP Server启动时会通过JSON-RPC向Client发送一个tools/list消息里面包含了该Server提供的所有工具的名称、描述、参数Schema。Client收到后会在AI模型的系统提示词中动态插入这些工具定义。然后当AI决定调用某个工具时Client会构造一个tools/call消息Server执行后返回结果。这个过程听起来很标准但问题恰恰出在“把所有工具定义塞进上下文”这一步。二、MCP的四大致命缺陷2.1 上下文臃肿还没干活Token已烧完。MCP的“全量加载”机制是它最根本的性能杀手。下图展示了MCP加载工具时的上下文构成连接3个MCP Server仅工具定义就占用约143K token。在200K token的模型上72%的上下文被工具定义吃掉。对于AI来说上下文窗口是它拥有的最宝贵的“房地产”而MCP的设计下Agent还没开始干活就已经“满”了。更严重的是上下文中的无关内容越多模型对真正重要内容的关注就越弱。研究人员记录了一个现象——“上下文腐烂”随着工具数量的增加工具选择的准确率从43%下降到14%以下。矛盾的是工具越多工具的使用效果反而越差。2.2 架构复杂初始化不稳定认证繁琐。MCP的架构涉及多个独立进程和网络边界每一步都可能出错在实践中MCP Server经常无法正常启动有时需要反复重试有时甚至需要清空状态推倒重来。失败跨越多个边界——模型推理、协议转换、网络调用、下游服务——任何一个环节出问题都可能导致整个链路失败排查极其困难。有人调侃说“配置MCP的时间比写代码的时间还长。”认证方面同样糟糕使用多个MCP工具就需要在每个工具上都要重新过一遍认证。各个服务的认证流程五花八门OAuth2、API Key、个人访问令牌Agent无法统一管理给开发者带来极大的运维负担。2.3 安全风险架构级的隐患MCP的威胁远超大多数人的想象。2026年1月CoSAI发布了《MCP安全白皮书》指出MCP引入的架构级安全风险无法通过补丁或配置修改来解决。随后Netskope的研究进一步证实MCP存在三类固有漏洞间接提示注入攻击者可以通过在共享文档或API响应中植入恶意指令让MCP Server无意中执行危险操作。工具投毒恶意MCP Server可以注册名称相似的工具诱导AI调用错误工具。Rug Pull攻击攻击者先发布合法MCP Server积累信任后突然更新恶意代码。安全研究人员已发现近7,000个暴露在公网的MCP服务器其中约半数没有任何授权控制。更令人担忧的是Cloudflare的“Block AI Bots”设置新域名默认开启会直接阻止Anthropic后端服务器访问你的MCP端点而且这个设置是全有或全无——无法只允许Anthropic而阻止其他AI爬虫。2.4 被动工具设计Agent无法自己探索MCP工具是“被动暴露”的Server提供什么AI就用什么。Agent无法主动发现新工具、无法探索更高效的用法。而Agent真正需要的是能够像人类开发者一样主动探索和学习的能力。例如一个人类开发者想了解gh命令会执行gh --help而MCP下的Agent只能等待开发者预先配置好所有工具。三、CLI的底层原理为什么“老古董”突然焕发第二春CLI命令行界面是计算机历史上最古老的交互方式之一。但恰恰是这种“古老”让它成为了AI Agent的理想操作界面。Andrej Karpathy在X上评价道“CLI is super exciting precisely because they are legacy.”3.1 渐进式发现告别上下文污染MCP的问题是“开局全塞”CLI的做法是“按需加载”。下图展示了CLI的发现机制Agent执行gh --help看有什么命令需要时再gh pr --help看子命令参数最后才执行带参数的命令。信息按需加载不是开局全塞。有实测表明CLI方案比MCP方案便宜17倍可靠性接近100%。更多项目实战在Java突击队网susan.net.cn/project3.2 管道操作组合能力强MCP工具返回结果如果需要后处理得写额外代码。CLI直接通过管道Pipe就能搞定这是Unix哲学的精髓Agent输出几个命令用|连起来后处理就搞定了。更简单、更灵活、维护成本更低。3.3 LLM天生就会用CLILLM的训练数据里包含了几十年的Unix文档、Stack Overflow的回答、GitHub上无数的shell脚本。模型天生就认识git、curl、grep、docker、kubectl。你不需要给Agent写复杂的工具Schema它自己就知道怎么用。3.4 可调试性极强当AI执行出错时工程师可以直接在终端里跑一遍同样的指令确认AI到底看到了什么。而在MCP的黑盒架构下你只能去翻冷冰冰的JSON日志。3.5 生态成熟稳定性高CLI有成熟的身份验证体系如OAuth2、API Key有标准化的错误码和输出格式如/dev/stdout、/dev/stderr、退出状态码数十年的工程实践已经让它极其稳定可靠。四、MCP vs CLI vs Skills是什么关系很多人觉得这三者是同一类东西其实不是。它们分别解决不同层面的问题。维度SkillMCPCLI核心作用告诉AI“懂什么”告诉AI“怎么接”告诉AI“怎么做”实现方式Markdown指令文件JSON-RPC协议 Server标准化命令接口Token消耗极低30-50 token待命极高每个工具几千token按需加载稳定性高中Server易崩溃极高安全性可控架构级风险成熟调试难度低高极低五、如何让AI通过CLI干活5.1 让Claude Code操作GitHub安装GitHub CLI# macOS brew install gh # Linux (Ubuntu/Debian) curl -fsSL https://cli.github.com/packages/githubcli-archive-keyring.gpg | sudo dd of/usr/share/keyrings/githubcli-archive-keyring.gpg echo deb [arch$(dpkg --print-architecture) signed-by/usr/share/keyrings/githubcli-archive-keyring.gpg] https://cli.github.com/packages stable main | sudo tee /etc/apt/sources.list.d/github-cli.list /dev/null sudo apt update sudo apt install gh # Windows (winget) winget install --id GitHub.cli登录gh auth login在Claude Code中使用在Claude Code中直接告诉它用GitHub CLI操作用GitHub CLI查看我所有的open状态PR列出编号和标题Claude Code会自动执行gh pr list --state open --json number,title --jq .[] | \(.number): \(.title)5.2 进阶组合管道操作找到所有包含“bug”的PR提取编号和创建者Claude Code会执行gh pr list --state open --json number,title,author --jq .[] | select(.title | test(bug)) | \(.number) by \(.author.login)5.3 桥接工具mcpkit把MCP Server“降级”成CLI。虽然CLI有很多优势但MCP生态中已经有大量现成的Server直接扔掉太可惜。mcpkit就是专门解决这个问题的——它是一个MCP客户端能把任何MCP Server变成CLI命令和轻量级Agent Skills零上下文膨胀。安装npm install -g balakumar.dev/mcpkit安装GitHub MCP Server作为CLI工具mcpkit install npx -y modelcontextprotocol/server-github --name github调用工具mcpkit call github search_repositories {query:mcpkit}5.4 桥接工具unmcp直接从终端调用MCP工具。unmcp是一个更轻量的选择让你直接从终端调用MCP Server工具没有协议开销。安装uvx unmcp调用工具uvx unmcp filesystem read_file --path /tmp/example.txt输出为JSONuvx unmcp filesystem --json read_file --path /tmp/example.txt六、大厂为何纷纷拥抱CLI飞书开源了官方CLI——200多条指令涵盖11个业务领域内置19种Agent Skills。Google推出了用于Google Workspace的gwsCLI。Zilliz发布了Zilliz CLI让你直接从终端管理Milvus向量数据库。这些大厂的选择揭示了一个趋势CLI Skills模式正在迅速成为企业级Agent工具的默认模式。原因很现实AI要真正进入业务流程就必须具备执行能力。而GUI是为人类设计的AI在图形界面上的操作效率很低。CLI的优势在于命令清晰、无歧义、易自动化对AI来说执行成本更低。总结MCP并非“已死”但它的适用范围正在缩小。CLI也并非要“取代”MCP两者各有适用场景。选择MCP需要标准化协议、需要跨平台工具共享、有多Agent协作的场景。选择CLI追求极致性能、需要低成本、追求稳定可靠、AI需要自主探索。一个值得关注的趋势是混合架构用CLI处理高频、简单的执行任务用MCP处理复杂的、需要标准化集成的场景。而mcpkit、unmcp这类桥接工具恰好让这种混合架构成为可能。