我对MCP偏见的转变

MCP是我刚接触Agent的Aha Moment。

还记得那是第一次使用，Notion MCP，AI可以直接往笔记里面写内容，在图书馆体验一番后到闭馆时间我是兴奋地、笑着跑回宿舍。

后来，提示词工程、上下文工程、Skills、CLI 的出现，MCP慢慢淡出视野。

相比CLI，MCP 完全是Token消耗大户啊！这一印象出现后，项目中也不想使用MCP。

写这篇文章的灵感来自于，同事在项目中使用 MCP 注册中心，我就有些抵触。去问AI，除了 MCP，Skill, CLI可不可以考虑？

得到 Anthropic的这篇 Blog：《Building agents that reach production systems with MCP》—— 使用 MCP 在生产环境构建 Agent 系统。看完后又得到以下Blog：

• 《Writing effective tools for agents — with agents》—— 与 Agent 写有效的 Agent Tool
• 《Introducing advanced tool use on the Claude Developer Platform》—— 高级工具使用
• 《Skills explained: How Skills compares to prompts, Projects,MCP, and subagents》—— Skills与 Prompt、Projects、MCP、子Agent协作

里面就解答了我的困惑：Agent使用 API、CLI还是MCP？也印证了我的理解：CLI适用于用户环境。前两种方式对AI极其友好和轻量，开发迭代速度极快，在用户本地环境很方便，但对于云环境确有着弊端：

• Agent直接调用 API。Agent 通过 Curl / 编程方式调用。这也是使用 Coding Agent（如 Claude Code，OpenCode最直观的方式）。但在规模化时，挑战就开始出现了。由于智能体和服务之间没有通用层，每个“智能体-服务”对都变成了一个定制集成，拥有自己的身份验证处理、工具描述和边缘情况——这就是 M×N 集成问题。
• Agent调用 CLI（可能是封装到 SKILL 中，如飞书 CLI、weread skill）——适用于本地环境 / 沙箱容器。CLI 在触达不暴露容器的移动、Web 或云托管平台时遇到了硬性限制，并且身份验证由 CLI 自身的机制处理——通常是磁盘上的凭证文件。这最适合在本地环境中进行快速、宽松的集成。
• MCP Agent上下文处理协议，有着标准化协议支撑：适用于云端环境，与其它系统通信交互，需要自建 MCP Server

这算是进一步改正我什么都想追求一种方式的扭曲选择心态。