【早说】命令行才是AI工具的未来

前言

作者认为 MCP 正迅速失去意义：它增加新协议与服务端进程的复杂度，却未给 LLM 带来实质收益。相反，CLI 凭借可组合管道、可复现调试、沿用既有认证与更少 “活动部件”，在可靠性与效率上更胜一筹。作者呼吁企业优先打造好 API 与官方 CLI。

本文从 5 分钟新知筛选，今日前端早读课文章由 @Eric Holmes 分享，@飘飘编译。

译文从这开始～～

我要抛出一个大胆的论断：MCP 正在走向消亡。我们或许尚未完全意识到这一点，但迹象已然显现。OpenClaw 不支持它，Pi 也不支持它 —— 而且理由充分。

当 Anthropic 发布模型上下文协议（Model Context Protocol）时，整个行业为之疯狂。每家公司都争先恐后地部署 MCP 服务器，以此标榜自己是 “AI 优先”。海量资源涌入新端点、新传输格式、新认证方案的开发 —— 而这一切，不过是为了让大语言模型去调用那些它们本就能调用的服务。

【第3665期】WebMCP：让每个网站都能与智能代理互动的新标准

坦白讲，我从未真正理解这种需求。你知道大语言模型最擅长什么吗？自己把事情搞定。给它一个命令行工具和一些文档，它就能撒欢儿跑起来。

这篇文章我一直不太想写，但现在我确信：MCP 没有带来任何实质性的价值，没有它我们反而会过得更好。且听我细说。

大语言模型不需要专门的协议

大语言模型天生就擅长使用命令行工具。它们的训练语料涵盖了数百万份手册、Stack Overflow 回答，以及 GitHub 上堆积如山的 shell 脚本。当我让 Claude 执行 gh pr view 123 时，它直接就能跑通。

MCP 许诺了一个更简洁的接口，但实际操作中，我发现自己照样得写同样的文档：每个工具的功能、接受哪些参数，以及更关键的 —— 什么时候该用它。大语言模型根本不需要一个新协议。

CLI 对人类同样友好

当 Claude 在 Jira 上做出了出乎意料的操作时，我可以直接运行同一条 jira issue view 命令，看到它所看到的一切。输入相同，输出相同，毫无玄机。

而用 MCP 的话，工具只存在于大语言模型的对话内部。一旦出了问题，我就得钻进 JSON 传输日志里翻来覆去地排查，而不是简单地自己跑一遍命令。调试这件事，不应该需要一个协议解码器。

【第3211期】使用现代的 Node.js 构建简单的CLI工具

可组合性

这是差距真正拉开的地方。CLI 天生可组合：我可以用管道传给 jq，用 grep 串联过滤，重定向输出到文件。这不只是方便 —— 很多时候这是唯一可行的方案。

举个例子，分析一个大型 Terraform 计划：

 terraform show -json plan.out | jq '[.resource_changes[] | select(.change.actions[0] == "no-op" | not)] | length'

换成 MCP 呢？要么把整个计划塞进上下文窗口（代价高昂，往往根本塞不下），要么在 MCP 服务器里自行实现定制化的过滤逻辑。无论哪条路，都是费更大的力气换来更差的结果。而 CLI 的方式用的都是现成的工具，文档齐全，人和 AI 都能理解。

认证机制本就运转良好

MCP 在认证这件事上管得太宽了。一个用来给大语言模型提供工具的协议，为什么要操心身份验证的事？

CLI 工具根本不在意这些。aws 用的是配置文件和 SSO，gh 用的是 gh auth login，kubectl 用的是 kubeconfig。这些都是久经沙场的认证流程，无论是我亲自操作还是 Claude 来驱动，表现完全一致。认证出了问题？按老办法修就行：aws sso login、gh auth refresh。不需要任何 MCP 专属的排障流程。

零活动部件

本地 MCP 服务器是进程 —— 它们需要启动、保持运行、不能悄无声息地挂掉。在 Claude Code 中，它们以子进程的形式被拉起，能跑的时候还好，一旦出问题就麻烦了。

CLI 工具不过是磁盘上的二进制文件。没有后台进程，没有状态需要维护，没有初始化的繁文缛节。需要时随手可用，不需要时悄然隐身。

实际使用中的痛点

抛开设计理念不谈，MCP 在日常使用中确实摩擦不断：

初始化时灵时不灵。

因为 MCP 服务器没有正常启动而不得不重启 Claude Code，我已经数不清有多少次了。有时重试就好，有时得清空状态从头来过。

重复认证没完没了。

同时使用多个 MCP 工具？那就等着一个一个去做认证吧。而使用 SSO 或长期凭证的 CLI 工具完全没有这个烦恼 —— 认证一次，一劳永逸。

权限管理非黑即白。

Claude Code 允许你按名称将 MCP 工具加入白名单，但也仅此而已。你没法限定为只读操作，也没法约束参数范围。而 CLI 就不同了：我可以放行 gh pr view，但对 gh pr merge 要求审批确认。这种粒度至关重要。

那 MCP 什么时候有用？

我并不是说 MCP 一无是处。如果某个工具确实没有 CLI 替代方案，MCP 可能是合理的选择。我自己日常也还在用不少 MCP 工具 —— 当它是唯一的选项时。

我甚至承认，拥有一套标准化接口本身是有价值的，而且确实存在一些场景，MCP 比 CLI 更合适。

但对于绝大多数工作而言，CLI 更简单、调试更快、也更可靠。

【第3609期】使用 Chrome DevTools MCP 进行调试：让 AI 在浏览器中“拥有双眼”

真正的启示

最好的工具，是人和机器都能用的工具。CLI 经过了数十年的设计迭代，具备可组合性、可调试性，并且搭载在已有的成熟认证体系之上。

MCP 试图构建一个更高级的抽象层。结果发现，我们手头早就有一个相当好用的了。

致所有构建者的呼吁

如果你所在的公司正在投入资源建设 MCP 服务器，却连一个像样的官方 CLI 都没有 —— 请停下来，重新想想你们在做什么。先打造一个好的 API，再打造一个好的 CLI。至于 AI 智能体，它们自己会搞定的。

关于本文译者：@飘飘作者：@Eric Holmes原文：https://ejholmes.github.io/2026/02/28/mcp-is-dead-long-live-the-cli.html