为什么使用 CLI 而不是 MCP？

Source: Dev.to

引言

现在大家都想让事物对代理更友好，那么 MCP 比 CLI 更好吗？当 Claude Code 开始触及限制时，我开始在 Claude 旁边使用带有 OpenCode 的 Kimi。就在那时，我才意识到可移植性问题：我需要在 OpenCode 上再次设置一个 MCP，又要在 Codex 上再设置一次。

可移植性问题

MCP 与集成层绑定，而 CLI 与操作系统绑定。如果你构建一个 CLI，你实际上是在押注更简单的东西——代理只需要运行一个 shell 命令。

CLI 与 MCP

为什么是 CLI？

几天前，我问我的朋友 Marco，为什么他的代理管理平台 Struere 拥有 CLI 而不是 MCP。他解释说：

MCP 的问题在于你给代理额外添加了一个工具，而这本质上会让它的工作变差。CLI 则不同。它使用代理已经拥有的工具，你只需给它提供如何使用该工具的上下文。

当一个代理已经拥有一堆工具时，再添加一个意味着模型现在有：

• 多一个可供选择的选项
• 多一个需要理解的 schema
• 多一次在真正工作之前的微小决策

你可能会觉得你在给代理更多的能力，有时确实如此，但你也在给它更多需要推理的表面（以及需要消耗更多 token 的地方）。

MCP 的优势

Claude 和大多数前沿模型在 MCP 工具上已经有了显著提升。当集成做得好时，输出会显得很舒服，因为它是结构化的；模型不必去读取混乱的终端响应并猜测哪些信息重要。

平衡视角

我不想把论点简化为“MCP 坏，CLI 好”，因为这并不是我的观点。MCP 在模型需要在对话中获取结构化上下文时非常有用。然而，MCP 不应成为面向代理的产品的自动答案。一个好的 CLI 能以更少的设置和更低的上下文开销覆盖许多相同的使用场景。

推荐

如果我今天要构建一个开发者工具，我会先从 CLI 开始，然后再加入 MCP。

示例：Experiwall

以我在 Experiwall 的案例为例，这种做法让网站的 A/B 测试更容易。我们发布了一个 MCP，因为某些工作流在代理能够直接在对话中检查实验、变体和结果时表现更好。我们也添加了 CLI 支持，这样开发者在更换代理时就不必重新连接所有东西（正是我的经验）。

展望

如果让我预测一年后哪种界面会被更广泛使用，我会选择 CLI。