我对MCP偏见的转变

MCP是我刚接触Agent的Aha Moment。还记得那是第一次使用Notion MCPAI可以直接往笔记里面写内容在图书馆体验一番后到闭馆时间我是兴奋地、笑着跑回宿舍。后来提示词工程、上下文工程、Skills、CLI 的出现MCP慢慢淡出视野。相比CLIMCP 完全是Token消耗大户啊这一印象出现后项目中也不想使用MCP。写这篇文章的灵感来自于同事在项目中使用 MCP 注册中心我就有些抵触。去问AI除了 MCPSkill, 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 CodeOpenCode最直观的方式。但在规模化时挑战就开始出现了。由于智能体和服务之间没有通用层每个“智能体-服务”对都变成了一个定制集成拥有自己的身份验证处理、工具描述和边缘情况——这就是 M×N 集成问题。Agent调用 CLI可能是封装到 SKILL 中如飞书 CLI、weread skill——适用于本地环境 / 沙箱容器。CLI 在触达不暴露容器的移动、Web 或云托管平台时遇到了硬性限制并且身份验证由 CLI 自身的机制处理——通常是磁盘上的凭证文件。这最适合在本地环境中进行快速、宽松的集成。MCP Agent上下文处理协议有着标准化协议支撑适用于云端环境与其它系统通信交互需要自建 MCP Server这算是进一步改正我什么都想追求一种方式的扭曲选择心态。