MCP 与 CLI：AI 工具集成的两种路线

MCP 和 CLI 代表了 AI 工具集成的两种路线。

MCP 的思路是把外部能力包装成模型可调用的工具，通过 tool definition 暴露给 Agent。它的优点是结构化、可发现、容易在平台或企业环境中统一管理，也适合处理鉴权、权限、审计和跨系统集成。

但 MCP 的代价也很明显。工具定义会占用上下文；server 质量参差不齐；输出经常不容易组合；有些 MCP 只是把已有 CLI 或 API 薄薄包了一层，却让模型先读一大堆工具说明。对于 coding agent 来说，这可能反而降低透明度。

CLI 的路线更接近 Unix 哲学：工具自己做好一件事，输入输出可以被管道组合，行为透明，文档成熟，人和 Agent 都能直接使用。GitHub CLI、ripgrep、git、test runner、package manager、tmux 这些工具本来就是工程师日常工作的一部分，模型也通常知道如何调用。

Mario 和 Armin 更偏向 CLI，并不是因为 MCP 没有价值，而是因为在很多编码场景下，CLI 已经足够好，而且更可控。

判断一个能力该用 MCP 还是 CLI，可以问几个问题：

• 如果已有稳定 CLI，是否真的需要再包一层 MCP？
• MCP 暴露的工具定义会不会消耗过多上下文？
• 输出是否能被 Agent 继续组合、过滤和复用？
• 鉴权、权限、审计是否需要统一治理？
• 这个工具是给单个工程师使用，还是给大组织统一接入？

如果是本地开发、文件操作、代码搜索、Git 操作、测试运行，CLI 通常更简单。如果是企业内部系统、复杂权限、统一资源访问和平台化工具分发，MCP 可能更合适。

关键不是站队，而是不要把协议当成目的。AI 工具集成的目标是让 Agent 更可靠地完成任务，而不是让所有能力都变成 MCP。简单、透明、可组合的工具，往往比“看起来更 Agent-native”的封装更适合长期工程实践。

相关：为什么 Pi 选择极简设计、自修改软件为什么因 AI Agent 变得可行、大代码库里如何管理上下文