编者按： 当 Anthropic 推出 Model Context Protocol（MCP）时，整个行业都在欢呼 —— 但如果我们冷静下来追问：一个专门为 LLM 设计的协议，真的比历经数十年打磨的命令行工具更适合智能体吗？
我们今天为大家带来的这篇文章，作者的核心观点是 MCP（模型上下文协议）并非必要，传统的 CLI（命令行工具）才是 LLM 工具调用的更优解。
文章从多个角度剖析了这一判断：作者认为，大语言模型本身就能熟练使用命令行工具，并不需要一套专门的“协议”；CLI 的可调试性、可组合性、成熟且统一的认证机制，以及“即用即走”的低运维成本，都远胜于 MCP 这类需要常驻进程、依赖 JSON 日志排错的抽象层。文章也坦承，MCP 在某些缺乏 CLI 的场景下仍有其存在意义，但警示开发者不应本末倒置 —— 在没有提供基础 CLI 和 API 的情况下，优先投入资源去构建 MCP 服务器。
作者 | Eric Holmes
编译 | 岳扬
我想下一个大胆的断言：MCP 已是大势已去。 或许我们可能还没有完全意识到，但种种迹象早已显露端倪。OpenClaw 不支持它，Pi 也不支持它。而这绝非毫无缘由。
当 Anthropic 发布 Model Context Protocol（模型上下文协议）时，整个业界为之疯狂。各家公司争先恐后地推出 MCP 服务器，只为证明自己拥抱“AI first.”的理念。大量资源被投入到新的 API 接口、新的传输格式、新的授权机制，而这番折腾仅仅是为了让 LLM 能够对接那些它们原本就有能力对接的服务。
我承认，我始终未能参透其存在的必要性。但你知道 LLM 最擅长什么吗？是独立解决问题。只需给它一个 CLI 和几份文档，它便能大显身手。
我曾迟迟不愿写下这些文字，但我如今确信，MCP 并没有给我们带来实际的好处，没有它我们反而会过得更好。且听我细说。
01 大语言模型并不需要什么特殊协议
大语言模型非常擅长使用命令行工具。 它们的训练数据里包含了数以百万计的手册页面、Stack Overflow 回答，还有满是 shell 脚本的 GitHub 仓库。当我让 Claude 执行 gh pr view 123 时，它就能直接搞定。
MCP 曾许诺提供更简洁的接口，但在实际操作中，我发现自己到头来还是得写同样的文档：每个工具是干什么的，接受哪些参数，更重要的是，什么时候该用它。大语言模型根本不需要什么新协议。
02 命令行界面（CLIs）也是给人用的
当 Claude 对 Jira 做出意外操作时，我可以运行同样的 jira issue view 命令，精确复现它所看到的内容。输入相同，输出一致，毫无玄机。
而在 MCP 中，工具仅存在于 LLM 的对话之内。 一旦出了问题，我就得深挖 JSON 传输日志去排查问题，而不是简单自己运行一下命令了事。调试工作不该非得依赖协议解码器（protocol decoder）。
03 组合能力
二者的差距就在这里被拉开了。CLI 天生可组合。我能通过管道将输出传给 jq 处理，再与 grep 链式组合，或重定向到文件。这不只是方便，往往还是唯一切实可行的方案。
试想分析一个庞大的 Terraform plan：
terraform show -json plan.out | jq '[.resource_changes[] | select(.change.actions[0] == "no-op" | not)] | length'
使用 MCP，你的选择要么是把整个计划转储到上下文窗口中（成本高昂，通常还不可行），要么是在 MCP 服务器内部构建自定义过滤。无论哪种，都是费力不讨好。 而 CLI 方案用的是现成工具，文档齐全，人类和智能体都能理解。
04 认证机制本就可行
MCP 在认证问题上实在是多此一举。一个用于给大语言模型提供工具的协议，为什么非得操心认证的事？
CLI 工具才不管这些。aws 用的是 profiles 和 SSO。gh 用的是 gh auth login。kubectl 用的是 kubeconfig。这些都是经过实战检验的认证流程，无论是我在键盘前操作，还是由 Claude 来调用，运行起来都一样。认证出了问题，我就按老办法解决：aws sso login、gh auth refresh，完全不需要针对 MCP 去排查。
05 没有多余的运转部件
本地 MCP 服务器是常驻进程。 它们得启动、得持续运行，还得保证不悄无声息地卡死。在 Claude Code 里，它们被拉起成为子进程，这种机制平时看着没问题，一出问题就崩盘。
CLI 工具不过是磁盘上的二进制文件。 没有后台进程，没有需要管理的状态，也没有那一套初始化流程。你需要时它们就在那里，不需要时也绝不碍事。
06 实际痛点
除了设计理念的问题，MCP 在实际日常使用中确实存在一些不便：
初始化不稳定。 我已经数不清有多少次因为 MCP 服务器没启动而重启 Claude Code。有时重试能解决问题，有时我得清空状态重新开始。
重复认证没完没了。 使用多个 MCP 工具？那就享受每个都认证一遍的乐趣吧。而使用 SSO 或长期凭证的 CLI 工具根本没有这个问题。认证一次，就一劳永逸了。
权限控制是“全有或全无”的。 Claude Code 允许你按名称将 MCP 工具加入白名单，但也仅限于此。你无法将其限定为只读操作，也无法限制参数。换作 CLI，我可以将 gh pr view 设为白名单，但 gh pr merge 则需人工审批授权。这种细粒度的控制至关重要。
07 那什么时候用 MCP 才合理？
我并不是说 MCP 完全没用。 如果某个工具确实没有对应的 CLI，MCP 可能是合适的选择。在日常工作中我仍然比较常用 MCP，毕竟很多时候它都是唯一可用的选项。
我甚至不否认标准化接口有一定价值，而且确实存在某些场景，它比 CLI 更合适。
但对于绝大多数工作而言，CLI 更简单、调试更迅速、运行更可靠。
08 The real lesson
最好的工具，就是那些既能服务于人、也能服务于机器的工具。 CLI 经过了几十年的设计迭代。它们可组合、可调试，并且能复用现有的认证系统。
MCP 试图构建一个更好的抽象层。结果发现，我们本来就已经有一个相当不错的了。
09 致产品构建者们
如果你们公司正在投入资源做 MCP 服务器，却连一个官方的 CLI 工具都没有，那可能本末倒置了。先问问自己：是不是该先把更基础、更通用的 CLI 做好？先交付一个好用的 API，再基于这个 API 开发一个好用的 CLI 工具。你不需要为智能体专门搭建 MCP 服务器这种复杂的东西，只要把 API 和 CLI 工具做好，智能体有能力自己学会怎么用，不需要你额外操心。
END
本期互动内容 🍻
❓作者说“最好的工具应同时服务于人与机器 ” 。你认同这个判断吗？有没有哪个工具，让你觉得"对人友好，对 AI 也友好"？
本文经原作者授权，由 Baihai IDP 编译。如需转载译文，请联系获取授权。
原文链接：
