OpenClaw 上的Skill 和 Plugin 到底什么区别?一篇讲透

开门见山

Skill 和 Plugin 不是同一个维度的东西。

把它们放在一个维度比较，就像问“操作手册和新设备有什么区别”一样——一个是说明书，一个是实体。

一句话：

• Skill = 告诉 AI “怎么做”（声明式）

• Plugin = 给 AI “新工具”（命令式）

---

02

—

Skills：给 AI 一本操作手册

想象你招了一个新员工（AI），他能力很强但不懂你们公司的流程。

你给他一本操作手册：客户投诉要先记录工单、代码提交前要跑测试、发布时要通知运维——这就是 Skill。

Skill 就是一个文件夹，核心文件是 SKILL.md。AI 每次会话时会读取这个文件，了解“我应该怎么做事”。

~/.openclaw/skills/code-review/├── SKILL.md          # 核心规则文件（必须）├── references/       # 辅助参考文档（可选）│   └── checklist.md└── examples/         # 示例文件（可选）    └── good-pr.md

Skill 能做什么？

• 规范工作流：定义“先做 A、再做 B、最后做 C”的标准流程

• 注入专业知识：让 AI 了解特定领域的术语、规范、最佳实践

• 约束行为：告诉 AI “不要做 X”“遇到 Y 时先问用户”

• 定制输出风格：规定回复格式、语言、详细程度

Skill 的局限

它只是“建议”，不是“法律”。

AI 理论上应该遵守 SKILL.md 里的规则，但实际上可能因为：

• 上下文太长，规则被“遗忘”

• 用户指令与规则冲突，AI 倾向于服从用户

• 模型本身的幻觉或理解偏差

如果你需要强制执行某些规则，Skill 做不到。这就需要 Plugin 出场了。

Plugins：给 AI 装一台新设备

如果说 Skill 是操作手册，那 Plugin 就是真金白银的设备——它运行的是真实代码，可以与系统核心直接交互。

Plugin 是一个标准的 npm 包，核心文件是 openclaw.plugin.json（清单）和 src/index.ts（入口代码）。

my-plugin/├── openclaw.plugin.json   # 插件清单（必须）├── package.json           # npm 包信息├── src/│   └── index.ts           # 入口代码└── README.md

Plugins 的 6 种超能力

Plugin 可以向系统注册 6 种类型的扩展，每种解决不同的问题。

需要说明的是：Plugin 这种机制并非 OpenClaw 独有。 几乎所有成熟的智能助手平台——无论开源还是商业——都会提供类似的能力：通过代码注入工具、拦截钩子、对接外部渠道。OpenClaw 的 Plugin 体系是一个具体的、可操作的实现，但它背后反映的是智能助手平台扩展能力的一个通用设计模式。下面我们以 OpenClaw 为例来理解这六种能力：

① Tool（工具）—— 给 AI 一双新手

注册一个 AI 可以调用的函数。

场景：你安装了一个 Jira 插件，它注册了 create_jira_ticket 工具。当你对 AI 说“帮我把这个 bug 建个工单”，AI 调用这个工具，Jira 上就多了一条记录。

关键点：工具是 AI 主动选择调用 的。AI 看到上下文，判断“我需要用这个工具”，才会调用。

现实类比：给员工发了把螺丝刀——员工需要时自己拿起来用。

② Hook（钩子）—— 在关键时刻插一脚

在 AI 操作的生命周期中注册拦截点。当特定事件发生时，你的代码先执行，可以决定“放行、修改、或拒绝”。

场景：安全插件注册了一个 Hook，绑定到“AI 调用工具之前”这个事件。当 AI 准备删除文件时，Hook 函数先检查：目标文件是否在个人目录？用户是否明确确认？如果检查不通过，直接拦截，操作不会执行。

关键点：Hook 是被动触发的，系统事件发生时自动调用。这是安全拦截的核心机制。

现实类比：工厂流水线上的质检站——产品必须通过检查才能往下走。

③ Channel（通道）—— 让 AI 换个地方说话

对接外部消息平台，让 OpenClaw 能在新的渠道上收发消息。

场景：OpenClaw 默认可以在网页上对话。安装飞书通道插件后，你可以在飞书群里直接 @ 它对话；安装 Telegram 插件后，你可以通过 Telegram 和 AI 聊天。

关键点：通道管理着消息的收发、认证、文件传输，是独立运行的。

现实类比：给公司装了一部新电话——原来只有座机，现在加了飞书号、Telegram 号。

④ Provider（模型提供商）—— 给 AI 换一个大脑

接入新的 AI 模型提供商。

场景：OpenClaw 默认用 OpenAI 的模型。安装 DeepSeek Provider 插件后，你可以选择用 DeepSeek 的模型来回答问题——可能更便宜，也可能在某些任务上更好。

关键点：Provider 处理最底层的模型通信（认证、推理、Token 计数），与上层的 Skill/Tool 完全无关。

现实类比：原来公司只请了 OpenAI 顾问，现在也可以请 DeepSeek、Claude 的顾问了。

⑤ Service（服务）—— 启动一个后台值班员

注册一个后台常驻服务。插件加载时启动，卸载时停止，不需要用户触发。

场景：一个审计日志插件，安装后在后台持续记录所有 AI 操作；一个 Web Dashboard 插件，启动一个本地 HTTP 服务器提供管理界面。

关键点：Service 是独立于对话的，不依赖用户发消息。

现实类比：公司后台 7×24 小时值班的人——不需要你打电话给他，他一直在那。

⑥ Skill（内嵌技能）—— Plugin 自带的说明书

Plugin 安装时可以自动附带 Skill。

场景：一个 Jira 插件内嵌了一个 jira-workflow Skill，教 AI 按照团队规范创建工单。装了插件就有 Skill，不需要单独安装。

关键点：这是 Plugin 能力的软性补充——核心靠代码，额外引导靠 Skill。

一个真实案例：openclaw-codex-app-server

第五部分的正文内容从这里开始。

该选 Skill 还是 Plugin？

两者可以组合吗？

完全可以，而且这是最佳实践。

一个设计良好的 Plugin 可以同时内嵌 Skill：

• Plugin 的代码负责硬性能力（工具、钩子、服务）

• 内嵌的 Skill负责软性引导（教 AI 什么时候用这些能力）

比如一个安全插件：

• Hook 代码负责强制拦截危险操作

• 内嵌 Skill 负责提醒 AI 主动评估风险、向用户解释风险

硬性 + 软性，双保险。

写在最后

OpenClaw 的扩展体系设计得很清晰：

• Skill 降低了扩展门槛——不会写代码的人也能贡献专业知识

• Plugin 提供了无限可能——开发者可以做到系统的任何层面

理解了两者的区别和分工，你就知道该在什么时候用什么方式来扩展你的 AI 助手了。

Plugin 这种扩展机制并不是 OpenClaw 的专利。几乎所有成熟的智能助手平台——无论开源还是商业——都会提供类似的能力：通过代码注入工具、拦截钩子、对接外部渠道。OpenClaw 的 Plugin 体系是一个具体的、可操作的实现，但它背后反映的是智能助手平台扩展能力的一个通用设计模式。