一、MCP 的设计理念与潜在问题1. 什么是 MCPMCP 是一种开放的 RPC 协议允许模型通过 JSON-RPC 等方式调用外部工具或获取上下文信息。它定义了工具发现、调用、响应等标准流程旨在解耦模型与具体工具实现。2. 声称的缺点上下文污染MCP 通常要求将工具描述、参数模式、甚至部分数据直接注入模型上下文窗口。随着工具数量增加上下文可能被大量元数据填满挤占有效 token干扰模型对核心任务的处理。不可组合MCP 工具往往是独立定义的缺乏原生组合机制。要实现“调用 A 工具的输出作为 B 工具的输入”需要模型自行编排或依赖外部编排层增加了复杂度。模型不擅长模型对 JSON-RPC 或结构化协议的理解并非天生需要专门微调或提示工程而 Unix 命令是模型预训练数据中大量存在的自然形式。二、SkillsCLI 范式的优势1. 模型天然熟悉 Unix 命令行预训练语料包含海量 Shell 脚本、命令行示例、man 手册等模型对ls,grep,curl,jq等命令的语义和用法有较强理解。因此让模型直接生成 CLI 命令比生成结构化 JSON 调用更自然降低了对微调的依赖。2. 避免上下文污染CLI 调用通常只需在提示中提及命令名称和用法示例无需将每个工具的详细模式塞入上下文。模型只需生成命令字符串执行环境负责解析和执行输出结果再返回给模型。上下文主要承载任务描述和历史交互而非工具元数据。3. 天然的组合性Unix 哲学强调“组合小工具完成复杂任务”通过管道|、重定向、进程替换等机制模型可以自然地组合多个命令。例如curl -s http://api | jq .data | grep pattern。这种组合能力是 MCP 需要额外编排逻辑才能实现的。4. 生态系统成熟命令行工具生态极其丰富几乎任何功能都有对应的 CLI 实现curl, ffmpeg, git, docker 等无需为每个工具重新实现一套 MCP 适配器。三、架构设计权衡1. 何时选择 MCP异构环境当工具不是本地 CLI而是远程 API、数据库、专有服务时MCP 可提供统一接入层。类型安全MCP 可定义严格的输入/输出模式便于校验和错误处理。多模型兼容MCP 作为协议可被不同模型甚至非 AI 系统复用。2. 何时选择 SkillsCLI本地自动化Agent 需要操控操作系统、文件系统、本地软件。快速原型利用现有命令行工具快速构建 Agent 能力无需开发适配器。上下文敏感任务避免工具描述挤占上下文尤其适合长对话或复杂推理。3. 混合架构的可能实践中可以结合两者将 CLI 命令封装为“技能”Skill每个技能对应一个 CLI 工具或组合命令技能描述简洁名称简短说明模型只需选择技能并生成参数。对于复杂或远程服务使用 MCP 接入但将 MCP 调用也封装为技能保持对外接口一致。上下文管理工具描述放在系统提示或单独的知识库中通过检索动态注入避免静态污染。四、核心争议剖析1. “污染上下文”是否必然MCP 并不强制将所有工具描述放入上下文可以通过工具发现机制按需获取。但实践中许多实现为了简化确实将所有工具描述一次性注入导致上下文膨胀。SkillsCLI 则更易实现按需调用因为 CLI 名称本身就隐含了功能模型只需知道“可用命令列表”。2. “不可组合”是协议本身的问题吗MCP 协议本身不禁止组合但组合逻辑需要由模型或上层编排器实现。而 CLI 的管道是进程级别的组合模型只需生成一行命令由 Shell 负责数据流。MCP 若想实现类似组合需要支持链式调用或中间结果传递增加协议复杂度。3. 模型真的“天生擅长” Unix 命令吗大模型在预训练中确实见过大量命令行但理解程度因模型而异。对于罕见命令或复杂参数模型可能犯错。此外CLI 输出是非结构化的文本模型需要解析而 MCP 返回 JSON 更易于程序化处理。因此“擅长”是相对的需结合任务类型。五、结论与建议从架构设计角度看SkillsCLI 更贴合 Unix 哲学和模型预训练特性在本地自动化、快速组合方面优势明显。MCP 则适合作为标准化集成层对接异构服务。两者并非互斥聪明的架构可以将常用 CLI 命令直接暴露为原子技能让模型自由组合对需要严格输入输出或远程调用的工具通过 MCP 封装但将 MCP 调用抽象为 CLI 风格例如提供一个mcp-tool命令采用动态上下文管理仅注入当前可能用到的工具描述避免污染。最终选择哪种范式取决于具体场景如果 Agent 主要与操作系统和本地软件交互SkillsCLI 是更直接高效的道路如果需要广泛连接第三方服务MCP 提供了标准化的便利。未来可能的发展方向是模型原生支持 CLI 调用同时 MCP 作为补充协议两者通过一层轻量封装共存。