2026年4月13日 · 阅读 —
MCP 快不行了？CLI 才是人机共用的硬通货
图片资源未同步：未命名图片
MCP 快不行了？CLI 才是人机共用的硬通货
最近越来越容易遇到一种“工具链式崩溃”：本来只是想让 agent 帮忙上网查点资料、跑个脚本、顺手改个配置，结果模型还没开始聪明，环境先开始闹脾气。
最典型的就是那种：卡住、起不来、鉴权转圈、日志像迷宫。人坐在电脑前，越看越想笑——不是那种开心的笑，是那种“行吧，你赢了”的笑。
EJ Holmes 那篇文章标题够狠：MCP is dead. Long live the CLI。
翻译成人话就是：MCP 你先躺会儿，CLI 继续上班。
原文链接：https://ejholmes.github.io/2026/02/28/mcp-is-dead-long-live-the-cli.html
这篇不打算做学术转述，也不想写成“观点提要”。更像是把工程现场摊开聊聊：为什么很多工程师会天然更信 CLI，为什么“协议级优雅”经常输给“能复现、能排错”，以及一些不那么高大上、但挺能保命的底层价值观。
先丢一句底线：MCP 不一定没用，但它一旦变成“多一层进程、多一层鉴权、多一层故障点”，就很容易从工具变成负担。工程师讨厌的不是新东西，讨厌的是出了事还不好救。
先讲一个开发/测试都懂的共识：可复现，就是正义
做开发、做测试、做运维，本质上都在干同一件事：把不确定的世界压成可控的系统。
所以最烦人的不是复杂，而是复杂还不透明。
CLI 这东西的好，不在于它“高级”，而在于它“朴素”。朴素到你能复现。
比如 agent 在 Jira 上做了个奇怪操作——你不需要猜它看到了什么，也不需要对着一堆 transport log 抓耳挠腮。你直接在本地跑同一条命令：jira issue view ...。同一份输入，同一份输出。对上了就继续，没对上就排错。
这件事看起来土，但它救命。
因为工程世界里，任何争论最后都应该落到一句话：复现出来再说。
LLM 其实很会用 CLI，至少比很多人想象的会
LLM 从训练数据里吃过太多命令行：man page、Stack Overflow、CI 脚本、各种“被迫写给人看的操作手册”。
所以让它跑 gh pr view 123 这种命令，大多数时候是能跑起来的。
MCP 当然也可以让接口更“规整”，但现实往往很扎心：说明书还是得写。工具干嘛、参数什么意思、什么时候用、什么时候别用——这些你一条都省不掉。
协议替不了工程判断。很多时候它只是把“背锅的姿势”换了一个更花哨的角度。
真正拉开差距的是“组合能力”：CLI 是工具链，能把活干完
工程里的活很少是一锤子买卖。
更多时候是：抓点东西 → 过滤一下 → 聚合一下 → 落盘 → 再处理。
CLI 的管道就很“人类友好”，也很“机器友好”。| jq、| grep、重定向、管道、脚本拼装……这些不是情怀，是成熟的生产力。
原文里举了 Terraform 的例子：你想从一个巨大的 plan 里抽出真正发生变化的资源数量，命令行一套就能做：
terraform show -json plan.out | jq '[.resource_changes[] | select(.change.actions[0] == "no-op" | not)] | length'这类任务如果硬做成“协议化工具调用”，经常会走向两种尴尬：要么把大 JSON 往上下文里塞，贵而且容易爆；要么让你在 server 里重写过滤逻辑，等于重复造轮子。
说得更直一点：CLI 是军械库，很多时候你缺的不是一个“更优雅的接口”，而是那套已经成熟几十年的组合式武器。
动件越多，锅越多：工程上最贵的不是功能，是维护注意力
认证这块，CLI 早就有稳定打法：AWS profile/SSO、GitHub 的 gh auth login、Kubernetes 的 kubeconfig。坏了怎么修也清楚：aws sso login、gh auth refresh。这条路的最大优点是：人能看懂，也能手动救火。
而 MCP server 往往是进程。进程意味着“它得活着”，而不是“它理论上存在”。启动、常驻、别挂、别 silently hang。你不干活的时候，它也可能在后台给你表演失联。
原文提到的那些痛点其实都很生活：初始化 flaky、重试几次才好、多个工具多次认证、权限粒度粗。单个看着都不致命，但叠在一起就是一件很可怕的事：注意力被偷走。
工程师的注意力就是血条。血条被偷到 0，你就开始写“我为什么要做这一行”的小作文了。
换个角度：为什么开发/测试更倾向“CLI + skill”这种组合
AI 时代最容易让人误判的一件事是：输出变快了，验证成本没变。
agent 可以一天改十个目录，review 的脑子还是那一颗；测试要跑的还是要跑；线上翻车还是要有人背。
所以更靠谱的节奏往往是这样的：让 agent 干活没问题，但必须让它交证据。
证据是什么？最能落地的就是命令行输出和测试结果。它们能落盘，能复现，能对比，能在出事时把锅从“玄学”拽回“事实”。
从测试角度看更明显：以前不写测试的借口是“太慢”。现在 agent 写测试很快，那就更没理由裸奔。测试不是成本中心，是止血带——不一定让你永远不翻车，但能让你翻车时不至于当场开席。
朋友圈式的底层价值观（鸡汤但别尬）
这几年越来越相信几件事。
第一，任何“省事的抽象”都不是免费午餐，它一定会在排错时收税。你省下的十分钟，可能会在凌晨两点以两小时的形式要回来。最惨的是，那两小时你还不知道从哪开始。
第二，别迷信“先进”。先进不等于可靠。工程世界里最值钱的能力不是“追风口”，是“出事能止血”。能止血的东西往往长得很普通：日志、命令、回滚、证据链。
第三，真正靠谱的自动化不是“全自动”，而是“随时能接管”。agent 跑得飞起没关系，但人要能看懂、能复现、能接手。否则那不是自动化，是把方向盘焊死，然后希望路永远是直的。
第四，别把自己活成工具的奴才。工具的目的应该是让人活得像个人：更少重复劳动、更少无意义的焦虑、更少被无穷无尽的中间层折磨。要是工具反过来让你每天做“状态恢复/进程重启/鉴权续命”，那就该停下来想想：是不是走偏了。
说到底，这篇文章讲的也不是 MCP 该不该死，而是一个更老的道理：**最好的工具是人和机器都能用的工具。**CLI 之所以还在，不是因为它顽固，是因为它真的能打。
那 MCP 什么时候值得上？
也别一刀切。
当场景是“平台治理”而不是“日常搬砖”，MCP 这类标准接口就可能更合适。比如工具根本没有 CLI 等价物，只能 SDK/API；比如必须强结构化输入输出、统一审计权限；比如多团队共享工具，标准化接入比个人效率更重要。
但在更多日常场景里，先把 CLI + skill 约束玩明白，往往更稳。
最后留一句不太鸡汤但很实用的忠告：想让 agent 真正替人干活，就别只盯着“能不能调用”，要盯着“出了事怎么复现、怎么回滚、怎么解释给同事听”。