前两天 Hacker News 上有一篇文章炸了锅：「MCP is dead. Long live the CLI.」

作者 Eric Holmes 直接把 MCP（Model Context Protocol）判了死刑，然后洋洋洒洒写了一大篇论证为什么 CLI 才是 AI Agent 的正确姿势。

292 个 upvotes，198 条评论。这热度，在 HN 上算是顶级了。

先说 MCP 是啥

如果你还不知道 MCP，简单说：这是 Anthropic 在 2024 年推出的一个协议，让 LLM 能用标准化的方式调用外部工具。比如连 Jira、查邮件、操作数据库，都走 MCP 统一接口。

推出的时候，整个行业都疯了。每家公司都急着做 MCP server，生怕别人觉得自己不够"AI first"。

作者的核心论点

Eric Holmes 的观点很简单粗暴：LLM 根本不需要一个专门的协议来调用工具，给它一个 CLI 就够了。

他列了几个理由，我觉得都挺实在：

1. LLM 天生就会用命令行

大模型训练数据里有海量的 man page、Stack Overflow、GitHub 上的 shell 脚本。你让 Claude 跑一个 gh pr view 123，它直接就会。不需要什么中间协议。

2. 可组合性差距太大

CLI 的精髓在于管道。terraform show -json plan.out | jq '.resource_changes[]' 这种操作，在 MCP 里几乎不可能。你要么把整个输出塞进上下文窗口（贵，而且可能放不下），要么在 MCP server 里手写过滤逻辑。

3. 调试的噩梦

用 CLI，出了问题我直接跑同样的命令看输出。用 MCP？你得去扒 JSON transport 日志，像考古一样。

4. MCP 进程管理是个坑

MCP server 本质上是一个需要常驻的进程。它要启动、保持运行、不能默默挂掉。而 CLI？就是磁盘上的一个二进制文件，用完就走，不占资源。

作者说他用 Claude Code 的时候，MCP server 启动失败的次数已经数不清了。

HN 评论区更精彩

评论区基本分成两派。

CLI 派占了大多数，很多人现身说法：

"我的 AI agent 通过 shell 命令控制整个开发流程，效果好得吓人。agent 就凭 --help 输出就能搞定从没见过的 CLI flag。而我用过的每个 MCP server 都需要人盯着。"

"试过 Jira MCP，一团糟。还不如让 LLM 直接调 API、自己写脚本。写出来的脚本还能复用，上下文消耗也少得多。"

MCP 派虽然少数，但也有几个不错的反驳：

"MCP 的好处是你可以控制输出。CLI 输出太多照样烧 token。但 MCP 可以分页，可以让 agent 先看有多少结果，再决定怎么拿。"

"MCP 更像 REST 或 gRPC 的封装层。如果 CLI 不是你自己写的，你很难保证 agent 不会用到危险的 flag。MCP 至少能做白名单。"

还有一个特别有意思的评论，一针见血：

"MCP 是在 LLM 还没那么强的时候搞出来的。现在 coding agent 进化了，回头看 MCP 确实有点多此一举。"

我怎么看

说实话，这个争论的本质不是 MCP vs CLI，而是 「给 AI 一个精心设计的接口」vs「让 AI 自己搞定」。

两年前，LLM 调用工具还不太稳定，MCP 的标准化确实有价值。但现在？Claude、GPT-4 这些模型用 CLI 已经像老手程序员一样熟练了。

有个评论说得特别好：有人让 Claude 下载了 ffmpeg 和 Blender 的源码，然后自己读代码理解那些文档里没写的功能。这种级别的「自学能力」，确实让 MCP 的「标准化文档」显得有点多余。

但 MCP 不会完全死掉。在企业环境里，安全控制、权限管理、审计追踪，这些都是 CLI 天然缺失的。你不可能让 AI agent 在生产环境里随便跑 shell 命令。

最终的赢家大概是某种混合方案：日常开发用 CLI，企业级部署用 MCP 做一层安全封装。不是非此即彼，而是看场景选武器。

不过有一点是确定的：那些纯粹为了「AI first」营销而做的 MCP server，可以准备入土了。