为什么 MCP 仍然是比 CLI 更好的选择

📢 本文同步发布於公众号：Power Platform · 最佳实践
🔗 原文链接：https://johnliu.net/blog/why-mcp-is-still-the-best-bet-over-cli/

CLI 对人类很友好，但 MCP 更适合 Agent：可发现的工具、可移植的集成，以及用于交互式 UI 的 MCP Apps。

归根结底，2026 年的 Agent 需要真正把事情做成。

它们可以使用 CLI、REST、MCP，甚至屏幕抓取和浏览器抓取。真正的问题不是哪种方式更时髦，而是哪种传输方式能让 Agent 最有把握完成任务——安全地、可重复地，并且带有足够的结构，让人仍然能够信任结果。

这就是为什么我认为比较应该这样开始：

这就是整个论证的框架。

CLI 仍然有用。但对于 2026 年的 Agent 来说，MCP 将持续演进，更好地适配 Agent。

CLI：Token 成本低，其他一切都贵

CLI 只擅长一件事：让一个已经了解系统的人类快速操作它。

这恰恰也是问题所在。

CLI 假设用户已经知道：

当操作者经验丰富且有耐心时，这没问题。

但当操作者是一个 Agent——它必须自己发现工具、弄清楚响应的结构、从错误中恢复，并在过程中控制好上下文——这就远没有那么理想了。

CLI 给了你能力，但同时也把大量附带复杂性塞给了你。

它还有一种容易被低估的脆弱性。Agent 必须解析文本、从标志参数中推断意图，并从 stdout 或 stderr 中重建结构。对于简单的一次性命令，这还可行。但当工作流需要重试、多步骤操作，或者需要一份其他宿主可以依赖的稳定契约时，情况就变得很难看。

而且 CLI 通常需要 --help 才能告诉 Agent 它能做什么。如果这不是一个广为人知的 CLI，你就又得往 Token 上下文里塞更多文本，Agent 才能开始工作。这正是那种一开始看起来很便宜、然后悄悄膨胀的隐性成本。

基于 stdio 的 MCP 是从 CLI 向上迈出的第一步。

它感觉仍然是本地的。它感觉仍然贴近 Shell。所有东西都在同一台机器上运行，所以你可以保持简单的心智模型，也避免了数据经过远程网络跳转。

这使得 stdio 非常适合以下场景：

但即使在这里，MCP 已经在做 CLI 做不好的事情：它暴露的是结构化工具，而不是让 Agent 去猜命令行的含义。

所以即使还没走到远程，MCP 已经给了你比原始命令字符串更好的契约。

这才是 MCP 创新正在推进的方向。

远程 MCP 服务器给企业带来了 CLI 通常不具备的东西：一个集中化的地方来统一流程。

不用每个团队各自发明自己的 Shell 命令、包装脚本、脚本和习惯，MCP 让你可以发布一个经过批准的交互模式，然后让多个宿主来消费它。这使得让所有人保持在同一工作流上变得更容易，记录正在发生的事情变得更容易，在一个地方改进体验——而不是追着十个不同的脚本跑——也变得更容易。

远程 MCP 还给你带来：

如果我构建了一个 MCP 服务器，我不只是在帮助一个终端会话中的一个 Agent。我是在暴露一种能力，它可以跨宿主、跨产品被复用……