拒绝为“工具说明书”买单:为什么开发者开始从MCP转向CLI?
前不久, 我跟技术圈子里的友人交流, 知晓了一个挺有趣的状况: 好多从事AI Agent开发的人员, 开始朝着CLI转变了。
这里面涵盖的技术团队, 还包含一些于开源社区颇为活跃的开发者。
这并非是什么“革命”, 也不是“颠覆”, 它仅仅是一个极为朴实的选择, 那就是去考量运用哪种方式干活得以更省心, 另外还得更省钱。
一、先说MCP的问题
关于MCP, 也就是Model , 其本身所具备的设计思路不存在问题, 然而, 它存在着一个极为现实的缺点在于, 每次实行调用操作时, 都会出现烧Token的情况。
我用一个具体的例子来说明。
倘若你期望AI为协助你去进行一件极为简易的事情, 那便是在桌面上寻觅到昨天被修改过后的文件。
置于 MCP 架构情形下, 你得先去配置一个属于文件系统的 MCP , 此行为会告知 AI 好些工具, 诸如怎样对文件展开读取操作, 怎样实施文件的写入行径, 怎样开展文件的搜索事宜, 怎样获取文件的列表情况等等。
一个完整的文件系统MCP ,包含的工具说明大概是什么规模?
项目数值
行数
1,600多行
字符数
6万多字符
Token消耗
约14,000个token
这是什么概念?
每一回进行API调用之际, 都得往里头塞进上下文, 仅仅是发送这个工具列表, 便要额外花费诸多的RMB。这尚且仅仅只是一个MCP。要是你让AI同时去加载文件系统的话, 还有邮件系统, 以及数据库, 每一个都得加上这一回的成本。
因为优秀的agent框架会进行压缩, 所以模型商也会做cache来帮你省钱, 一次两次的时候这没什么关系, 然而要是你每天都让AI帮你做几十次活, 如此一来这个费用就会慢慢累积上去了。
二、CLI怎么解决这个问题
CLI也就是命令行工具, 我们平常所使用的ls命令, 属于CLI, grep命令, 也属于CLI, find命令, 同样属于CLI, 还有curl命令, 亦是属于CLI。
在CLI模式下,你需要告诉AI的只有一个工具:bash。
bash的说明极其简易, 大概也就十几二十字, 其内容为, 传一个参数, 该参数值乃是你想要去执行的命令。
没了。
同样是一个"在桌面上找昨天修改过的文件"的需求:
AI自己会生成这样的命令:
find ~/Desktop -type f -mtime 1
然后结果直接就出来了。

Token消耗从14,000降到几百个。
三、再举一个更具体的例子
上面提及的那个例子, 兴许尚不足以达到直观的程度, 我们来更换一个场景, 此场景是每天都能够运用到的: 也就是批量重命名文件。
如果把你手机里存在的, 数量为一百张的 .jpg 格式文件名照片, 替换为呈现 2024 年 1 月 1 日, 再加上三位数字编号的 2024 - 01 - 01 - 001.jpg样式的文件名。
用MCP要如何去做呢, 配置一个文件系统的MCP分析, 需要用到哪些工具, 通过MCP协议调用工具, 等结果返回。
中间要经过好几层,响应速度肯定快不了。
用CLI怎么做?
快让AI知晓, 把那100张照片, 重新命名为带有日期的格式 , 你直接这样去告诉它。
AI生成的命令可能是:
cd ~/Desktop/photos
n=1
for f in IMG_*.jpg; do
mv "$f" "$(date +%Y-%m-%d)-$(printf 'd' $n).jpg"
((n++))
done
命令直接在本地执行,一步到位。
四、速度快不少
除了省钱,CLI还有个实际的好处:响应更快。
由于MCP中间存在额外的一层, 就是AI 要将首个步骤设定为调用MCP工具, 紧接着工具开展执行操作, 最终操作所产生的结果才会被返回到AI那里。
CLI是AI直接生成命令,本地执行,结果直接返回。
用游戏的说法:MCP是走代理,CLI是直连。
五、总结一下对比项
Token消耗
配置复杂度
执行速度
相对慢
适用场景
特定工具封装
几乎所有场景
当然了, MCP并非毫无价值可言, 在针对一些复杂的以及需要进行封装的工具链的情况之下, 尤其是在企业级应用这种有着安全和可控需求的场景当中, MCP给出了一种标准化的管理方式。
不过要是你所追寻的是那种“简单高效, 花费更少的金钱, 去办理更多的事情”这般情况的话, 那么CLI确实是一个更为务实的选择了。
更多推荐
所有评论(0)