第一堵墙：容量瓶颈（上下文预算）。工具的定义本身要进入系统 prompt 或等价的工具上下文；工具越多，占用越多，留给干活的空间越少。于是你会看到一些很现实的限制：某些 AI coding 工具最多支持配置 100 个 tools，而一个 GitHub MCP 可能就带 50 多个。你想把世界都接进来，但大脑的工作台面就这么大。第二堵墙：任务闭环瓶颈（组合性）很多 MCP 的调用结果会被直接回填上下文。短结果当然舒服，长结果就会触发两个问题：要么上下文爆炸，要么被截断丢尾巴。 从这个角度看，MCP 暴露出来的瓶颈，并不完全在协议本身，而在于我们常常下意识地把它用成了「往上下文里塞数据」的通道，而不是「把能力接入到工作流里」的接口。也正是在这样的背景下，SKILL 开始受到关注。如果 SKILL 只是纯文本，它更像分层 prompt 的组织方式；但当它和命令行工具、脚本结合起来，它就不只是提示词技巧，而是一种场景化的工作流封装：同一类任务的步骤、产物、工具链、失败重试方式、输出格式，都被聚合在一起。普通用户可能搞不清 MCP 是干啥的，但他能理解这个技能帮我把评论整理出来并逐条修复。 说回 MCP，我并不觉得有了 SKILL，MCP 就没意义了。恰恰相反，我更倾向于一种分工：MCP 解决连接标准化，SKILL 解决工作流编排与状态外部化。前者让能力能规模化接入，后者让任务能稳定闭环。MCP 不一定要由 Agent 直接调用并回填上下文，它完全可以被 SKILL 里的脚本调用，让结果先落地为可寻址对象（文件 / 句柄 / 资源），再把摘要与索引回填给模型。这样上下文就回到它最擅长的位置：做决策、做推理、做取舍，而不是当缓存。MCP、SKILL 仍处在早期阶段，只是 Agent 插件机制演化中的不同形态。当 Agent 开始承担复杂任务时，真正重要的已不再是能力本身，而是上下文、状态与执行边界如何被拆分和安放。\n原文链接