什么是 Skills？

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

先别急着晕，咱们把这两个概念拆开看。Skills 这个概念，是 Claude（以及后来的 OpenCode、Trae 这类 AI 编程工具）提出并广泛应用的一种机制。说白了，它并不是模型天生自带的本事，而是你运行的本地环境塞给模型的一个“外设”。

1. 核心定义

Skills 本质上就是“寄生”在宿主环境里的一段功能代码片段。

• 谁是推手：Claude (Anthropic) 以及它的生态工具圈，比如 Claude Engineer、OpenCode。
• 它到底是什么：就是一段本地代码，最常见的是 Python 或 Ja vaScript。
• 它怎么活：完全依赖环境支持。要是 OpenCode 没打开，或者你压根没装这个软件，那这个 Skill 就跟不存在一样。

2. 运行机制：OpenCode 是怎么干活的？

当你在 OpenCode 的对话框里跟 AI 聊需求时，后台其实在悄无声息地走完下面这 4 步：

1. 检索

   • OpenCode 一启动，就会自动扫描一个固定文件夹，比如 /.opencode/skills/ 或者类似的路径。
   • 它会把这个文件夹里所有脚本的“说明书”（Description）都提取出来。
   • 注意：这会儿代码还没跑，只是先把说明书拿到手。

2. 注入

   • 你提问题的时候，OpenCode 会把刚才拿到的那些“说明书”悄悄塞进 System Prompt 里。
   • 它的潜台词是：“你看，我手头有这些工具，需要的时候喊我。”

3. 决策与调用

   • 模型判断该干活了，就会返回一个特殊的 Tag 或者 JSON 格式的指令。
   • 关键点在于：OpenCode 拦截到这个请求后，会在本地环境里，实打实地去运行那个文件夹里对应的代码。

4. 结果反馈

   • 代码跑完的结果（比如读取的文件内容、终端报错信息）会被抓取回来。
   • 这些结果会被转换成文本，再次塞回对话的上下文里，让模型知道接下来该怎么说。

什么是 MCP？

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

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

1. 核心定义

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

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

3. 运行机制：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 的区别

从架构实现和运行时的角度来看，两者的核心差异主要体现在进程模型和耦合度上。

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. 稳定性与故障隔离：为什么涉及数据库必须用 MCP？

拿数据库操作来举例，这正是架构选型的分水岭。

• Skills 的风险

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

  一旦这个脚本出点什么岔子——内存泄漏、死循环，或者没处理好连接池导致 IO 阻塞——它会直接拖累宿主程序的性能，严重时甚至能让 IDE 卡死、崩溃。这种缺乏故障隔离的设计，做做本地文件读写（IO 开销小、无状态）还行，一旦涉及复杂业务，那就是埋雷。

• MCP 的优势

  MCP 实现了进程级隔离。

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

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

3. 抓包视角下的“加载策略”

从抓包看，两者的加载逻辑也截然不同。

Skills：按需加载

Skills 用的是“先看菜单，点菜后再上菜”的策略。

• 初始化时：抓包会发现，OpenCode 会把所有 Skill 的 Description 合并起来发给大模型。
• 调用时：一旦决定调用某个 Skill，OpenCode 才去加载这个 Skill 的 Prompt，动态注入到当前对话上下文中。
• 特点：节省 Token，初始上下文很轻量，用谁才加载谁的详细 Prompt。

MCP：全量加载

MCP 则是把所有说明书一次性拍在桌上的策略。

• 初始化时：抓包会看到一个巨大的 Payload，MCP Server 把所有可用工具的 function 传给客户端，客户端再全量塞进 System Prompt 里。
• 调用时：纯粹的数据交换，通常不再有额外的 Prompt 注入。
• 特点：能力全暴露，大模型对工具认知更清晰，但初始 Token 消耗较大。

总结一下

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

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