参考资料

前言

最近 Hacker News 上有一篇热门文章《MCP is dead. Long live the CLI》，引发了关于开发工具接口的热烈讨论。这篇文章直指 MCP（Model Context Protocol）协议正在走向消亡，并呼吁回归传统的命令行工具。

读完全文后，我觉得这个观点虽然激进，但确实反映了一些实际问题。让我来总结一下核心观点。

核心观点：MCP 并不优于 CLI

作者认为，当 Anthropic 推出 MCP 时，整个行业盲目跟风，各家公司争先恐后部署 MCP 服务器，只为证明自己是"AI 原生"。但实际上，MCP 提供的所谓"更清洁接口"，在实践中并没有带来真正的改进。

问题一：LLM 不需要新协议

LLM 经过大量训练，已经懂得如何使用命令行工具。给它们一个 CLI 和文档，它们就能正常工作了。MCP 承诺的抽象接口，实际使用时还是要写文档说明工具的功能、参数和使用场景——这和直接用 CLI 没有本质区别。

问题二：CLI 更易于调试

用 CLI 工具时，如果出现意外情况，我可以直接运行同样的命令查看输出。但用 MCP 时，工具执行只在 LLM 对话内部，出问题时要通过 JSON 传输日志排查，调试反而更复杂。

问题三：CLI 的可组合性更强

CLI 工具可以方便地组合使用。例如分析 Terraform 计划时，可以直接管道传给 jq 处理：

1

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

用 MCP 的话，要么把整个计划转储到上下文窗口（昂贵且可能超出限制），要么在 MCP 服务器内构建自定义过滤——比直接用 CLI 更复杂、效果更差。

问题四：认证机制已成熟

CLI 工具的认证已经过实战验证（如 AWS 的 profile 和 SSO、GitHub 的 gh auth），无论人类还是 LLM 使用都能正常工作。MCP 试图重新设计认证，反而带来了不必要的复杂性。

问题五：无状态优势

CLI 工具是磁盘上的二进制文件，需要时才启动，用完就退出。而 MCP 服务器是后台进程，需要持续运行、管理状态、初始化配置——增加了使用成本。

MCP 的适用场景

作者并非完全否定 MCP，认为在某些情况下仍然有价值：

  1. 没有 CLI 等价物的新工具：如果是一个全新概念的工具，确实可能需要新的协议
  2. 标准化接口的价值：统一的接口规范可能带来更好的互操作性
  3. 特殊用例：某些场景下，MCP 可能确实比 CLI 更合适

但对于绝大多数开发工作，传统的 CLI 工具仍然是更简单、更可靠的选择。

给工具开发者的建议

文章最后提出一个重要观点：如果公司在开发 MCP 服务器，但没有好的 CLI，应该先完善 CLI 和 API，而不是急于追新概念。

这个建议很有道理——好的工具应该同时适用于人类和 AI，CLI 经过数十年的迭代，已经证明其价值。

我的思考

这篇文章引发的讨论反映了技术社区的一个普遍现象：新技术的炒作往往超过实际价值。

MCP 作为一项协议，确实有创新之处，但在当前阶段，很多问题都可以用成熟工具解决。开发者应该关注工具的实际可用性和可靠性，而不是被营销术语左右。

同时，我也认为未来可能会出现更好的解决方案——不是简单的 MCP 或 CLI 二选一，而是让工具与 LLM 协作更智能的机制。

结论

CLI vs MCP 的讨论核心不是技术优劣，而是务实 vs 创新的选择。

  • 对于现有工具，CLI 仍然是更稳定的选择
  • 对于创新场景，可以探索新的协议
  • 但任何技术都应该为实际需求服务，而不是为了证明什么"概念"

作为开发者，我们应该保持开放心态，既不盲目跟风，也不拒绝创新，而是根据实际需求选择最合适的工具。

本文包含AI生成内容