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

前言

最近在AI圈，有一个话题引发了巨大的争论------"MCP已死，CLI称王"。

从Perplexity CTO公开宣布放弃MCP，到Y Combinator CEO直言"MCP sucks"，再到飞书、钉钉、企业微信等大厂纷纷选择开源自家的CLI而非MCP，一场关于AI Agent如何与外部世界交互的范式转移正在发生。

MCP是Anthropic在2024年底推出的协议，旨在解决AI模型与外部工具之间的沟通问题，一度被称为AI界的"Type-C接口"，月下载量一度超过9700万次。

然而仅仅一年多后，这个曾经被誉为"行业希望"的协议，却正在被越来越多的人抛弃。

今天这篇文章专门跟大家一起聊聊这个话题，希望对你会有所帮助。

更多项目实战在Java突击队网：susan.net.cn

一、MCP的底层原理

在理解MCP的问题之前，我们先看看它的工作原理。

MCP（Model 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/project

3.2 管道操作，组合能力强

MCP工具返回结果如果需要后处理，得写额外代码。

CLI直接通过管道（Pipe）就能搞定，这是Unix哲学的精髓：

Agent输出几个命令用|连起来，后处理就搞定了。

更简单、更灵活、维护成本更低。

3.3 LLM天生就会用CLI

LLM的训练数据里包含了几十年的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是什么关系？

很多人觉得这三者是同一类东西，其实不是。它们分别解决不同层面的问题。

维度	Skill	MCP	CLI
核心作用	告诉AI"懂什么"	告诉AI"怎么接"	告诉AI"怎么做"
实现方式	Markdown指令文件	JSON-RPC协议 + Server	标准化命令接口
Token消耗	极低（30-50 token待命）	极高（每个工具几千token）	按需加载
稳定性	高	中（Server易崩溃）	极高
安全性	可控	架构级风险	成熟
调试难度	低	高	极低

五、如何让AI通过CLI干活？

5.1 让Claude Code操作GitHub

安装GitHub CLI：

bash 复制代码

# 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

bash 复制代码

gh auth login

在Claude Code中使用：

在Claude Code中，直接告诉它用GitHub CLI操作：

bash 复制代码

用GitHub CLI查看我所有的open状态PR，列出编号和标题

Claude Code会自动执行：

bash 复制代码

gh pr list --state open --json number,title --jq '.[] | "\(.number): \(.title)"'

5.2 进阶：组合管道操作

bash 复制代码

找到所有包含"bug"的PR，提取编号和创建者

Claude Code会执行：

bash 复制代码

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，零上下文膨胀。

安装：

bash 复制代码

npm install -g @balakumar.dev/mcpkit

安装GitHub MCP Server作为CLI工具：

bash 复制代码

mcpkit install "npx -y @modelcontextprotocol/server-github" --name github

调用工具：

bash 复制代码

mcpkit call github search_repositories '{"query":"mcpkit"}'

5.4 桥接工具：unmcp

直接从终端调用MCP工具。

unmcp是一个更轻量的选择，让你直接从终端调用MCP Server工具，没有协议开销。

安装：

bash 复制代码

uvx unmcp

调用工具：

bash 复制代码

uvx unmcp filesystem read_file --path "/tmp/example.txt"

输出为JSON：

bash 复制代码

uvx unmcp filesystem --json read_file --path "/tmp/example.txt"

六、大厂为何纷纷拥抱CLI？

飞书开源了官方CLI------200多条指令，涵盖11个业务领域，内置19种Agent Skills。

Google推出了用于Google Workspace的gws CLI。

Zilliz发布了Zilliz CLI，让你直接从终端管理Milvus向量数据库。

这些大厂的选择揭示了一个趋势：CLI + Skills模式正在迅速成为企业级Agent工具的默认模式。

原因很现实：AI要真正进入业务流程，就必须具备执行能力。

而GUI是为人类设计的，AI在图形界面上的操作效率很低。

CLI的优势在于命令清晰、无歧义、易自动化，对AI来说执行成本更低。

总结

MCP并非"已死"，但它的适用范围正在缩小。

CLI也并非要"取代"MCP，两者各有适用场景。

选择MCP：需要标准化协议、需要跨平台工具共享、有多Agent协作的场景。

选择CLI：追求极致性能、需要低成本、追求稳定可靠、AI需要自主探索。

一个值得关注的趋势是混合架构：用CLI处理高频、简单的执行任务，用MCP处理复杂的、需要标准化集成的场景。

而mcpkit、unmcp这类桥接工具，恰好让这种混合架构成为可能。

对于大多数开发者来说，在2026年，CLI + Skills的组合可能是最务实、最高效的选择。