拒绝为“工具说明书”买单:为什么开发者开始从MCP转向CLI?
最近在和技术圈的朋友交流,了解到一个有意思的现象:不少做AI Agent的开发者,开始从MCP转向CLI了。
这其中包括Perplexity的技术团队,也包括一些在开源社区比较活跃的开发者。
这不是什么"革命"或者"颠覆",就是一个很朴实的选择——用哪种方式干活更省心、更省钱。
一、先说MCP的问题
MCP(Model Context Protocol)本身设计思路没问题,但它有一个很现实的缺点:每次调用都在烧Token。
我用一个具体的例子来说明。
假如你想让AI帮你做一件很简单的事——在桌面上找到昨天修改过的文件。
在MCP架构下,你需要先配置一个文件系统的MCP Server。这个Server会告诉AI一堆工具:怎么读取文件、怎么写入文件、怎么搜索文件、怎么获取文件列表……
一个完整的文件系统MCP Server,包含的工具说明大概是什么规模?
| 项目 | 数值 |
|---|---|
| 行数 | 1,600多行 |
| 字符数 | 6万多字符 |
| Token消耗 | 约14,000个token |
这是什么概念?
每次API调用都要塞进上下文,单是发送这个工具列表,就要多花不少RMB。这还只是一个MCP Server。如果你让AI同时加载文件系统、邮件系统、数据库——每个Server都要加一次这个成本。
虽然优秀的agent框架会做压缩,模型商也会做cache帮你省钱,一次两次无所谓,但如果你每天让AI帮你干几十次活,这个费用就慢慢累计上去了。
二、CLI怎么解决这个问题
CLI就是命令行工具,我们平时用的ls、grep、find、curl这些命令都属于CLI。
在CLI模式下,你需要告诉AI的只有一个工具:bash。
bash的说明特别简单,大概就十几二十个字:传一个command参数,参数值是你想执行的命令。
没了。
同样是一个"在桌面上找昨天修改过的文件"的需求:
- MCP方式:发送14,000个token的工具说明 + 你的问题
- CLI方式:发送几十个token的bash说明 + 你的问题
AI自己会生成这样的命令:
find ~/Desktop -type f -mtime 1
然后结果直接就出来了。
Token消耗从14,000降到几百个。
三、再举一个更具体的例子
上面那个例子可能还不够直观,我们换一个每天都能用到的场景:批量重命名文件。
假设你手机里有100张照片,文件名全是IMG_0001.jpg这种格式,你想改成2024-01-01-001.jpg这样带日期的。
用MCP怎么做?
- 配置一个文件系统的MCP Server
- AI分析需要用哪些工具
- 通过MCP协议调用工具
- 等结果返回
中间要经过好几层,响应速度肯定快不了。
用CLI怎么做?
你直接告诉AI:“帮我把这100张照片重命名成带日期的格式”
AI生成的命令可能是:
cd ~/Desktop/photos
n=1
for f in IMG_*.jpg; do
mv "$f" "$(date +%Y-%m-%d)-$(printf '%03d' $n).jpg"
((n++))
done
命令直接在本地执行,一步到位。
四、速度快不少
除了省钱,CLI还有个实际的好处:响应更快。
因为MCP中间多了一层——AI需要先调用MCP工具,工具再执行操作,最后结果再返回给AI。
CLI是AI直接生成命令,本地执行,结果直接返回。
用游戏的说法:MCP是走代理,CLI是直连。
五、总结一下
| 对比项 | MCP | CLI |
|---|---|---|
| Token消耗 | 高 | 低 |
| 配置复杂度 | 高 | 低 |
| 执行速度 | 相对慢 | 快 |
| 适用场景 | 特定工具封装 | 几乎所有场景 |
当然,MCP不是没有价值。对于一些复杂的、需要封装的工具链,特别是企业级应用这种需要安全和可控的场景下,MCP提供了一种标准化的管理方式。
但如果你追求的是"简单高效、花更少的钱、办更多的事"——CLI确实是一个更务实的选择。
更多推荐



所有评论(0)