MCP 与 Skill 的边界
结论：MCP 是服务，Skill 是 Agent SOP 编排器。
首先，大部分 MCP 能做的事 Skill 也能做，这个我很认可。
但是它俩的应用场景差异就出在：什么事是 MCP 能做但是 Skill 不能做的。
举个例子
- 网络搜索。
- 去 GitHub 查代码。
- 去 Figma 获取原型设计数据。
- 去 Supabase 创建一个数据库。
前两个都是属于本地也能做，但是你大概率做不了的类型。
后两个属于本地完全不可能做，因为涉及到第三方服务数据和授权的类型。
MCP 是服务，提供的是能力
网络搜索是一个服务，它提供了实时访问互联网的能力，你要让你的 Agent 能搜查阅最新的资料，总不可能在本地搭建一个搜索引擎。
获取 Figma 数据也是一个能力，但是你想获取 Figma 数据不可能不依赖 Figma 官方的 API，Figma 把它的 API 通过 MCP 的方式暴露给用户，那你就只能使用它的 MCP 服务所提供的能力。
什么时候用 MCP
在现在 Skill 大行其道的背景下，我们对于 MCP 的需求只存在于不可代替的服务能力上。
再把 MCP 说的简单一点，它就是一个远端 API，只有在你本地无法处理某种需求的时候，它才有用，其余的时候我们都可以使用本地 Skill 脚本来处理，更可控、更安全、更方便。
如何判断该用 MCP 还是 Skill
| 场景 | 选择 | 原因 |
|---|---|---|
| 需要访问第三方服务（Figma、Supabase 等） | MCP | 涉及授权和远端数据，本地无法替代 |
| 需要实时联网搜索 | MCP | 本地无法搭建搜索引擎 |
| 文件处理、代码检查、文本转换 | Skill | 本地脚本即可完成，更可控 |
| 复杂多步骤工作流编排 | Skill | Skill 天然支持 SOP 流程编排 |
| 需要调用 MCP 能力 + 本地处理 | Skill + MCP | Skill 编排流程，MCP 提供远端能力 |
能本地解决的，别去连云端。