最近AI圈里有个话题吵得挺热：“MCP已死，CLI称王”。从Perplexity的CTO公开宣布放弃MCP，到Y Combinator的CEO直言“MCP sucks”，再到国内飞书、钉钉、企业微信等大厂纷纷选择开源自家的CLI工具而非拥抱MCP。这似乎预示着，关于AI Agent如何与外部世界交互的底层范式，正在发生一场静默但深刻的转移。
MCP（Model Context Protocol）是Anthropic在2024年底推出的协议，旨在解决AI模型与外部工具之间的沟通问题，一度被寄予厚望，月下载量曾超过9700万次。然而，仅仅一年多后，这个曾被誉为“行业希望”的协议，其光环正在迅速褪色。今天，我们就来深入聊聊MCP的困境、CLI的复兴，以及这场技术路线之争背后的逻辑。欢迎你也在 云栈社区 分享你的看法。
一、MCP的底层原理与设计初衷
在剖析MCP的问题之前，我们先理清它的工作机制。MCP本质上是一个客户端-服务器架构的协议，专门用来将外部工具（如文件系统、数据库、GitHub API）“包装”成AI模型可以直接调用的函数。
其工作流程大致如下：
- 服务注册：MCP Server启动时，会通过JSON-RPC向Client发送一个
tools/list 消息，其中包含了该Server提供的所有工具的名称、描述和参数Schema。
- 上下文注入：Client收到这些信息后，会将其动态插入到AI模型的系统提示词中。
- 工具调用：当AI模型决定调用某个工具时，Client会构造一个
tools/call 消息发送给Server，Server执行实际操作并返回结果。
这个过程听起来标准化且合理，但问题的种子，恰恰埋在了“把所有工具定义一次性塞进上下文”这一步。
二、MCP面临的四大现实挑战
1. 上下文臃肿：未战先损的“房地产”
MCP的“全量加载”机制是其最根本的性能瓶颈。想象一下，你刚启动一个Agent，还没让它干任何正事，宝贵的上下文窗口就被工具定义文档占满了。
如图所示，仅连接3个MCP Server，工具定义就可能占用约14.3K token。在一个200K token的模型上下文里，超过70%的“房产”已被工具文档“占用”。对于AI而言，上下文窗口是其思考的“工作内存”，MCP的设计导致Agent还没开始思考，内存就已告急。
更严重的是，研究表明，上下文中的无关内容越多，模型对核心任务的注意力就越分散，甚至出现“上下文腐烂”现象：随着工具数量的增加，模型选择正确工具的准确率会显著下降。这形成了一个悖论：工具越多，工具的使用效果反而越差。
2. 架构复杂：初始化与认证的噩梦
MCP架构涉及多个独立进程和网络边界，每一步都可能是故障点，使得整个系统变得脆弱。
实践中，MCP Server经常无法正常启动，有时需要反复重试，排查问题宛如大海捞针，因为故障可能发生在模型推理、协议转换、网络调用或下游服务中的任何一环。有开发者调侃：“配置和调试MCP的时间，比写业务逻辑的时间还长。”
认证同样是痛点。使用多个MCP工具意味着要在每个工具上重复进行OAuth2、API Key、个人访问令牌等五花八门的认证流程，给AI Agent的统一管理和安全运维带来了巨大负担。
3. 安全风险：架构层面的固有隐患
MCP引入的安全威胁可能远超多数人的预估。2026年初发布的《MCP安全白皮书》指出，其架构级安全风险无法通过简单补丁修复。主要漏洞包括：
- 间接提示注入：攻击者可通过对共享文档或API响应植入恶意指令，操控MCP Server执行危险操作。
- 工具投毒：恶意Server注册名称相似的伪工具，诱导AI调用错误工具。
- Rug Pull攻击：攻击者先发布合法Server积累信任，再通过更新植入恶意代码。
安全研究人员已发现近7000个暴露在公网的MCP服务器，其中约半数无任何授权控制。更麻烦的是，像Cloudflare的“Block AI Bots”这类通用防护设置，会无差别地阻断包括Anthropic在内的所有AI后端对MCP端点的访问，且难以精细配置。
4. 被动工具设计：缺乏探索能力的Agent
MCP工具是“被动暴露”的：Server提供什么，AI就只能用什么。Agent无法像人类一样，通过 --help 去主动探索、发现新命令或学习更高效的用法。这限制了Agent的自主性和适应性。
三、CLI为何成为新宠？
就在MCP遭遇质疑时，古老的CLI（命令行界面）却意外焕发了第二春。正如Andrej Karpathy所言：“CLI is super exciting precisely because they are legacy.” 其“古老”的特性，反而成为了AI Agent的理想操作界面。
1. 渐进式发现，按需加载
CLI完美解决了MCP“开局全塞”的问题。AI Agent可以像人类一样，通过 --help 命令进行渐进式探索。
Agent先执行 gh --help 查看有哪些顶层命令，需要时再 gh pr --help 查看子命令，最后才执行带具体参数的命令。信息完全按需加载，几乎不产生不必要的上下文开销。实测表明，CLI方案在成本上可比MCP方案便宜17倍，且可靠性接近100%。
2. 强大的管道与组合能力
这是Unix哲学的精华所在。如果需要对工具返回的结果进行后处理，MCP方案往往需要编写额外的代码。而在CLI中，一个管道符号 | 就能优雅地解决。
Agent可以自然地输出一连串用 | 连接的命令，组合能力极强，维护成本也更低。
3. LLM的“母语”优势
大型语言模型的训练数据中包含了海量的Unix文档、Stack Overflow问答和GitHub脚本。因此，模型对 git、curl、grep、docker、kubectl 等命令有着天生的“理解”。你无需为Agent编写复杂的工具Schema，它自己就知道这些命令大致怎么用。
4. 无可比拟的可调试性
当AI执行的命令出错时，工程师可以轻松地在终端中复制粘贴并重新运行同样的命令，亲眼确认输入、输出和错误信息。而在MCP的黑盒架构下，你通常只能面对冰冷的JSON日志进行猜测。
5. 成熟稳定的生态
CLI拥有数十年积累下来的成熟身份验证体系（如OAuth2）、标准化的错误码、输出流（stdout/stderr）和退出状态码。这套久经考验的基础设施，为AI Agent的执行提供了极高的稳定性保障。
四、MCP、CLI与Skills的关系辨析
很多人将MCP、CLI和Skills混为一谈，其实它们解决的是不同层面的问题：
| 维度 |
Skill |
MCP |
CLI |
| 核心作用 |
告诉AI“懂什么”（知识/能力） |
告诉AI“怎么接”（连接协议） |
告诉AI“怎么做”（执行接口） |
| 实现方式 |
Markdown指令文件 |
JSON-RPC协议 + Server |
标准化命令接口 |
| Token消耗 |
极低（30-50 token待命） |
极高（每个工具几千token） |
按需加载（几乎为零） |
| 稳定性 |
高 |
中（Server易崩溃） |
极高 |
| 安全性 |
可控 |
架构级风险 |
成熟 |
| 调试难度 |
低 |
高 |
极低 |
五、实践：如何让AI通过CLI高效工作？
1. 基础操作：让Claude Code使用GitHub CLI
首先，安装GitHub CLI (gh)：
# 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中，可以直接用自然语言指令：
用GitHub CLI查看我所有的open状态PR，列出编号和标题
Claude Code会将其转换为并执行：
gh pr list --state open --json number,title --jq '.[] | "\(.number): \(.title)"'
2. 进阶：组合管道进行复杂处理
提出更复杂的需求：
找到所有标题包含“bug”的PR，提取编号和创建者信息
Claude Code可能会生成并执行：
gh pr list --state open --json number,title,author --jq '.[] | select(.title | test("bug")) | "\(.number) by \(.author.login)"'
3. 桥接工具：利用mcpkit“降级”MCP Server
如果你已有的MCP Server生态不想抛弃，可以使用 mcpkit 这类桥接工具，将其转换为零上下文开销的CLI命令或轻量级Skill。
安装mcpkit：
npm install -g @balakumar.dev/mcpkit
安装GitHub MCP Server作为一个名为“github”的CLI工具：
mcpkit install "npx -y @modelcontextprotocol/server-github" --name github
调用工具：
mcpkit call github search_repositories '{"query":"mcpkit"}'
4. 桥接工具：更轻量的unmcp
unmcp 让你能直接从终端调用MCP工具，没有协议开销。
通过uvx安装并调用：
uvx unmcp
uvx unmcp filesystem read_file --path "/tmp/example.txt"
# 输出为JSON格式
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的模式正在成为企业级AI Agent工具的事实标准。原因很务实：AI要深度融入业务流程，必须具备稳定、高效、低成本的执行能力。GUI是为人类视觉设计的，AI操作效率低下；而CLI命令清晰、无歧义、易于自动化，对AI而言执行成本更低，可靠性更高。
总结
MCP并未“死亡”，但它确实暴露出了在性能、复杂度和安全方面的显著短板，其最佳应用场景可能被重新界定。CLI也并非要“取代”MCP，两者是适用于不同场景的工具。
如何选择？
- 考虑MCP：当你的场景强依赖标准化协议、需要跨平台共享工具、或者涉及复杂多Agent协作时。
- 首选CLI：当你追求极致的执行性能与成本效益、需要极高的稳定性与可调试性、并且希望赋予Agent自主探索能力时。
一个值得关注的未来趋势是混合架构：使用CLI处理高频、简单的执行任务，同时利用MCP处理那些需要复杂集成的标准化场景。而 mcpkit、unmcp 这类桥接工具的出现，正使得这种灵活的混合架构成为可能。
对于大多数开发者和团队而言，在当下，CLI + Skills的组合很可能是在性能、成本、稳定性和开发体验之间取得最佳平衡的务实之选。这场关于AI Agent“手和脚”的技术演变，远未结束，但方向已然清晰。
发表于 6 小时前
|
查看: 6|
回复: 0
