大模型与外部工具/服务交互的最佳方式是什么？一位外国工程师的看法：MCP 已死，CLI 永生

2026-03-02 13:49
46
基础设施工程师 Eric Holmes 对 Anthropic 推出的 MCP（Model Context Protocol，模型上下文协议）的一次系统性"唱衰"。他的核心论点是：MCP 没有提供任何真正的现实价值，传统的命令行工具（CLI）已经是 LLM 与外部服务交互的最佳方案。

他从六个维度展开论证：
  1. LLM 天生就会用 CLI：大模型在海量 man 手册、Stack Overflow 和 shell 脚本上训练过，给它一个 CLI 和文档就能直接上手，不需要专门的协议。
  1. CLI 人机通用，可调试：当 AI 出错时，你可以直接运行同样的 CLI 命令查看它看到了什么；而 MCP 出错时，你只能翻看 JSON 传输日志，调试成本高得多。
  1. CLI 可组合：可以通过管道、jq、grep 等工具自由组合，这在处理大型数据（如 Terraform 计划）时是唯一实用的方案；MCP 要么把所有数据塞进上下文窗口（昂贵且不现实），要么就要给 MCP 服务器写自定义过滤逻辑。
  1. 认证问题已被解决：CLI 工具各自有成熟的认证机制（AWS SSO、gh auth、kubeconfig），无论是人还是 AI 用都一样；MCP 在认证上"多管闲事"，每个 MCP 工具都要单独认证，体验极差。
  1. 无额外运行时依赖：CLI 只是磁盘上的二进制文件，用时即取；MCP 服务器是需要启动和维持运行的进程，经常出现启动失败、静默挂起等问题。
  1. 权限粒度不够：CLI 可以精确到允许 gh pr view 但需要审批 gh pr merge；MCP 的权限控制只能按工具名白名单，无法限制只读操作或具体参数。
他承认 MCP 在没有 CLI 替代品的场景下仍有价值，但呼吁所有企业：先做好 API，再做好 CLI，AI 代理自然会搞定剩下的事。不要本末倒置，在没有 CLI 的情况下就急着上 MCP。

全文翻译

我要提出一个大胆的判断：MCP 已经在走向消亡。 我们可能还没有完全意识到，但迹象已经出现了。OpenClaw 不支持它。Pi 也不支持它。这都是有道理的。
当 Anthropic 发布模型上下文协议（MCP）时，整个行业集体疯狂了。每家公司都争先恐后地上线 MCP 服务器，以此证明自己是"AI 优先"的。大量资源涌入新的端点、新的数据传输格式、新的授权方案——所有这些，都只是为了让 LLM 能和那些它们本来就已经能对话的服务进行通信。
我承认，我从来没有完全理解为什么需要它。你知道 LLM 真正擅长什么吗？自己搞清楚怎么做。 给它们一个 CLI 和一些文档，它们就能开始工作了。
我尽量不想写这篇文章，但我确信 MCP 没有提供任何真正的现实价值，而且没有它我们会过得更好。让我解释一下。

LLM 不需要专门的协议

LLM 非常擅长使用命令行工具。它们在数百万份 man 手册、Stack Overflow 回答和充满 shell 脚本的 GitHub 仓库上接受过训练。当我告诉 Claude 使用 gh pr view 123 时，它直接就能用。
MCP 承诺了一个更干净的接口，但在实践中，我发现自己还是在写同样的文档：每个工具是做什么的，接受什么参数，以及更重要的——什么时候该用它。LLM 根本不需要一个新的协议。

CLI 也是给人用的

当 Claude 在 Jira 上做了一些意料之外的事情时，我可以运行同样的 jira issue view 命令，看到它看到的完全一样的内容。同样的输入，同样的输出，没有任何黑盒。
用 MCP 的话，工具只存在于 LLM 的对话内部。出了问题，我就得在 JSON 传输日志里摸索，而不是直接自己运行命令看看。调试不应该需要一个协议解码器。

可组合性

这是差距拉大的地方。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 在认证问题上"多管闲事"（unnecessarily opinionated）。一个给 LLM 提供工具的协议，为什么需要关心认证的事？
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 更简单、更容易调试、也更可靠。

真正的教训

最好的工具是那些人和机器都能用的工具。CLI 已经经历了数十年的设计迭代。它们可组合、可调试，而且搭载在已经存在的认证系统上。
MCP 试图构建一个更好的抽象。结果发现，我们早已拥有一个相当好的抽象了。

对构建者的呼吁

如果你的公司正在投入资源建设 MCP 服务器，但你们连一个官方 CLI 都没有——停下来重新想想你们在做什么。 先做好一个 API，再做好一个 CLI。AI 代理会自己搞定剩下的事。
原文链接：https://ejholmes.github.io/2026/02/28/mcp-is-dead-long-live-the-cli.html，Eric Holmes
0
好文章，需要你的鼓励