该用 MCP,
还是直接敲命令?
英文圈喊「CLI 才是未来,MCP 已死」,中文这边也在传「越来越多人抛弃 MCP」。可偏偏有人转头就给 MCP 造了个管理器。一边送葬、一边加码,到底信谁?我把这半年的架从头看完了——两边都对,但吵错了轴。
先把关键数字摆桌上
150K → 2K,省 98.7%,是 CLI 派最硬的那张牌。这集我要讲的是:这张牌后来被 MCP 的亲爹亲手收回去了。
先说人话:CLI 到底跟 MCP 争什么
上集把"手"讲清了:MCP 就是给 AI 装一个统一插座,让它够得着外面的数据库、日历、地图。这集的新问题是——既然要给 AI"手",那这只手,非得是 MCP 这种插座不可吗?
CLI · 命令行界面
就是程序员在黑框框里敲命令那套:git commit 提交代码、curl 抓网页、ffmpeg 转视频。CLI 派的主张特别朴素:这些命令 AI 早就会了,它在 GitHub、Stack Overflow 上见过几百万次,根本不用教。那为啥还要费劲装 MCP?
💡 争论一句话:与其给 AI 装一堆花里胡哨的连接器,不如让它像老程序员一样,直接敲命令行,又快又省。
从"已死"到"根基",一条光谱
🧲 先记个反差:就在"MCP 已死"喊得最凶时,有人用 Rust 认真给 MCP 写了个管理器 mcpmate,卖点是"导入一次、到处能用、还帮你省 token"。一个"已死"的东西,会有人费劲做管理器吗?这个反差第 05 节会变成关键证据。
CLI 派的三条硬理由(不是抬杠)
- ① token 账太贵:MCP 的老规矩是每只"手"的说明书都得提前全文塞进上下文,不管用不用得上。叠三四个 server,活还没干,桌子先被说明书铺满。
- ② 链路太长:MCP 里模型是调度中心,一件事拆四五步,就得跟模型来回四五趟。换成命令行,一条命令用管道符在本地串完,只回模型一趟。
- ③ AI 是"母语级"熟练:
git、curl、ffmpeg在语料里出现过千万次,天生就会,还能像乐高一样拼起来用。
💬 CLI 派有句话很扎心:Unix 命令行这套组合逻辑,是跑了 50 年、被全世界程序员用出来的成熟系统;而 MCP 的组合能力,还是个刚出生的 0.1 版。
同一个活,两种用法的 token 账
挑横板照片→加水印→上传:两种跑法
exiftool|ImageMagick|scp,三步本地串完、只回一趟。这就是"执行层"为什么归 CLI:链路短、等待少那 MCP 凭什么没死,还越做越大?
如果 CLI 真能取代 MCP,Google、微软应该忙着拆 MCP 才对。现实是反的——它们一边出 CLI,一边还在拼命做 MCP。因为 CLI 有三个够不着的地方:
🗳️ 市场自己投的票:Google 一边发命令行工具、一边发 Workspace 的 MCP server,两个都做,等于当众承认"不是二选一";连喊"MCP 已死"最凶的圈子,转头也在给它造管理器、写最佳实践——嘴上送葬,身体加码。
拆穿这场架:它俩不在一条轴上
两边文章都读完,我反应过来问题出在哪:大家把"AI 用工具"当成了一个问题,其实它是两个问题叠在一起。一拆成两条轴,MCP 和 CLI 各自站的位置立刻就清楚了。
花名册 ≠ 干活方式
登记层是墙上那块工具挂钩板 + 花名册,写清"我们这儿有哪些活能干、去哪找";执行层是员工到底怎么把活干完——是每一步都念给老板听(穿上下文),还是自己去工具间做完、只把结果交上来。花名册和干活方式,是两码事。
💡 两条轴:轴 A「怎么知道能干什么」= 登记层;轴 B「真动手时怎么跑」= 执行层。它们根本不抢同一个位子。
两轴分层图:MCP 和 CLI 各赢一层
速查:这个活,走 MCP 还是走 CLI?
▸ 要 登录授权、按人分权限、保持会话
▸ 你是服务方,想让所有 AI 客户端都插上你
git、ffmpeg、curl…▸ 要省 token / 多步串联:写代码在旁边跑完,只回结果
▸ 纯本机工作流,连 MCP 都不用装
🔗 BOTH · 正解是两层各就各位:一次完整的"AI 用工具"往往两层都要——用 MCP 把外部能力登记进来(轴 A),再让 AI 写代码去调用、在执行层省掉那 98.7%(轴 B)。这正是 Anthropic 的收场方式:不删 MCP,而是让 AI 用代码去用 MCP。
Anthropic 没删 MCP,而是让 AI"用代码去用它"
最有意思的是,那波"抛弃 MCP"说法里最硬的牌——"MCP 天生费 token"——其实已经被 MCP 的亲爹亲手收回去了。省 token 这件事,MCP 自己也学会了。
它的做法:不再把 MCP 工具当成"一个个按钮"让 AI 挨个点,而是把每个 MCP server 变成文件系统上的一段代码接口(比如一个 ./servers/ 目录,每个服务一个文件)。AI 需要什么能力,先去翻目录、只读用得上的那个文件,再写一小段代码把能力串起来跑,中间结果在代码里就地处理掉,只有最后答案才回"脑子"。
🎯 一句话:它没在"MCP 还是 CLI"里选边,而是把 MCP 塞进了 CLI 那条更省的执行轴里。文首那个 150K → 2K、省 98.7% 的来历,就在这。争论到此其实已经结束了。
mcpmate 那个反差,现在全通了
市场之所以要给 MCP 造管理器,恰恰因为"经典用法"确实不好用:server 一多就 token 爆炸、配置到处散。mcpmate 干的"集中管起来、按客户端裁工具省 token",本质上就是在给执行层打补丁。
所以它不是"MCP 赢了"的证据,而是"MCP 的默认执行方式确实过时、得有人补"的证据——跟 Anthropic 的判断是同一个方向。
诚实讲边界:两轴不是万能钥匙
- 还没到开箱即用:Anthropic 那篇文末自己写着"实现留给读者做练习"。这套省 98.7% 的用法眼下更多是方向和范式,能不能吃到,看你用的客户端跟没跟进。
- 敲命令 = 权限面更大:让 AI 自由敲命令行,等于把真机方向盘交给它——删错文件、跑错脚本的代价,比调一个只读 MCP 大得多。这正好是下期的引子。
- 漂亮数字都来自厂商自测:150K→2K 是 Anthropic 在它自己选的示例任务上测的,换个任务数字会变。当方向信,别当铁律念。
⚠️ 按本栏目老规矩:讲完得泼冷水。这套"两轴"听着清爽,但别当真理背——它是个好用的判断框架,不是万能钥匙。
MCP 和 CLI 不是对手,是插座和插头:
够不着外面 → 挂 MCP(登记层);
具体怎么跑最省 → 写代码 / 敲命令(执行层)。
🔌 回到开头那个问题——该用 MCP 还是直接敲命令?我的答案是:这问题本身就问偏了。"MCP 过时了",过时的只是"把说明书全塞进脑子"这一种执行方式,不是 MCP 这个登记标准;CLI 也不是来取代 MCP 的,它俩是上下两层。
这期的话,从哪儿来
| 来源 | 提供了什么 |
|---|---|
| Anthropic 工程博客 | 《Code execution with MCP》2025-11,原文逐字 150,000 → 2,000 token · 省 98.7%;做法=把 server 呈现为文件系统上的代码接口 |
| Mario Zechner | 独立 token 实测,MCP ≈52,000 vs 等价 CLI ≈1,200,与官方同量级——不是一家自说自话 |
| mcpmate(loocor) | Rust 本地 MCP 管理器,卖点"导入一次到处能用 + 按客户端裁工具省 token",对齐 2025-11 规范 |
| SmartScope / 多方 | 两轴框架=其"输的是 eager-load 执行模式、不是 MCP 协议"的大众化简化;争论多方交叉:Holmes/Firecrawl/Tyk/CircleCI 等 |
会勇禾口王的AI笔记
HARNESS 工程 · 部件② 工具 · @huiyonghkw