别让你的 AI 像个实习生！从 Skills 到 MCP：教你如何给大模型装上‘工业级’机械臂

什么是 Skills？

—— 环境赋予的“本地超能力”

Skills 是 Claude（以及现在的 OpenCode, Trae 等 AI 编程工具）提出或广泛采用的一种机制。它不是模型原本就有的，而是环境提供给模型的。

1. 核心定义

Skills 是“寄生”在宿主环境中的功能代码片段。

• 提出者/推动者：Claude (Anthropic) 及其生态工具（如 Claude Engineer, OpenCode）。
• 本质：它是一段本地代码（通常是 Python 或 JavaScript）。
• 生存条件：必须依赖环境支持。如果 OpenCode 没打开，或者你没安装这个软件，这个 Skill 就不存在。

2. 运行机制：OpenCode 是怎么工作的？

当你在 OpenCode 里跟 AI 说话时，后台发生了这 4 步“隐形操作”：

1. 检索 ：

   • OpenCode 启动时，会扫描一个固定文件夹比如 /.opencode/skills/ 或类似路径）。
   • 它会读取这里面所有的脚本，提取出它们的描述（Description） 。
   • 注意：这时候代码还没跑，只是把“说明书”拿出来了。

2. 注入 ：

   • 当你提问时，OpenCode 会把这些“说明书”悄悄塞进 System Prompt 里。
   • 告诉模型：“我手里有这些工具（Skills），你需要的时候可以叫我。”

3. 决策与调用 ：

   • 模型判断需要用工具，返回一个特殊的 Tag 或 JSON。
   • 关键点：OpenCode 拦截到这个请求，在本地环境运行那个文件夹里的代码。

4. 结果反馈 ：

   • 代码运行结果（比如文件读取的内容、终端报错信息）被捕获。
   • 结果被转换成文本，再次塞回对话上下文中。

什么是 MCP？

—— 标准化的“通用外设接口”

MCP 是由 Anthropic 牵头推出的一套开放协议。它不再依赖于某个软件（比如 OpenCode）内部的特定文件夹或特定环境，而是建立了一种Client-Server（客户端-服务器） 的连接标准。

1. 核心定义

MCP 是连接 AI 模型与数据源/工具的“通用语言”。

• 提出者：Anthropic（为了解决各个 AI 软件工具不通用的碎片化问题）。
• 本质：它是一个独立的进程（Process），通过标准通信协议（JSON-RPC）与主程序对话。
• 生存条件：MCP Server 自己就是一个小程序，OpenCode 只是去“连接”它，而不是“包含”它。

2. 运行机制：OpenCode 是怎么连接 MCP 的？

同样的，我们把场景放在 OpenCode 里。但这次，OpenCode 不再是去文件夹里找脚本，而是像拨打电话一样去连接一个服务。

后台的 4 步“隐形操作”如下：

1. 握手与连接 ：

   • OpenCode 启动时，根据配置文件（config），启动后台的 MCP Server 进程（比如一个 SQLite 数据库服务）。
   • 两者建立通信管道（通常是 stdio 标准输入输出）。
   • 区别：Skills 是扫描静态文件，MCP 是启动动态进程。

2. 能力协商 ：

   • OpenCode 发问：“你有什么本事？”（发送 tools/list 请求）。
   • MCP Server 回答：“我可以查询 User 表，我可以插入数据...”（返回 JSON 格式的工具列表）。
   • OpenCode 把这些能力塞给大模型。

3. 远程调用 ：

   • 大模型决定调用工具。
   • 关键点：OpenCode 不执行代码，它只是个“传声筒”。它把请求打包成一个 JSON 消息，发送给 MCP Server。
   • MCP Server 在自己的进程里干活（查库、调接口），非常稳定。

4. 管道回传 ：

   • MCP Server 干完活，把结果打包成 JSON 发回给 OpenCode。
   • OpenCode 再喂给大模型。

MCP和Skills的区别

从架构实现和运行时的角度来看，Skills 和 MCP 的区别主要体现在进程模型和耦合度上。

1. 运行时环境的区别

• Skills ：

  Skills 本质上是宿主环境的一部分。

  在 OpenCode 这种 IDE Agent 场景下，Skills 通常就是一段 Python 或 JS 脚本。当 Agent 决定调用 Skill 时，实际上是 OpenCode 的主进程或者其派生的子进程直接加载并执行了这段代码。

  • 特点：它和宿主环境是强耦合的。环境直接持有代码，直接负责解释执行。
  • 局限：它的上下文完全依赖于当前 IDE 的环境配置（比如 Python 解释器路径、依赖库）。

• MCP ：

  MCP 采用的是标准的 C/S 架构 。

  MCP Server 是一个完全独立的外部进程。OpenCode 仅仅是作为一个 Client，通过标准输入输出（Stdio）或者网络套接字（Socket），利用 JSON-RPC 协议跟这个外部进程通信。

  • 特点：它是松耦合的。OpenCode 不关心 Server 是用 Rust 写的还是 Go 写的，只关心协议对不对。

2. 稳定性与故障隔离：为何涉及 DB 必须用 MCP？

比如数据库操作，这正是架构选型的分水岭。

• Skills 的风险：

  如果你用 Skills 写一个数据库连接脚本，它是运行在 OpenCode 的关联进程里的。

  一旦这个脚本出现内存泄漏、死循环，或者因为没有处理好连接池导致 IO 阻塞，它会直接影响宿主程序的性能，甚至导致 IDE 卡死、崩溃。这种缺乏故障隔离的设计，做做本地文件读写（IO 开销小、无状态）还行，做复杂业务就是埋雷。

• MCP 的优势：

  MCP 实现了进程级隔离 。

  当你连接数据库时，连接池维护、SQL 执行全部在独立的 MCP Server 进程里完成。

  • 稳妥之处：即便数据库驱动崩溃了（Crash），或者查询超时导致挂起，死的只是那个 MCP Server 进程，OpenCode 依然活得好好的，只需要捕获一个 RPC Error 即可。
  • 状态管理：MCP Server 可以常驻后台维持数据库的长连接状态，而 Skills 这种一次性脚本很难做到这一点。

总结一下

Skills 是插件化思维，适合轻量级、无状态、依赖宿主环境上下文的本地操作（如 fs.read）。

MCP 是微服务思维，适合重量级、有状态、需要故障隔离的复杂业务集成（如 Database）。