第四讲：Skill 与 ClawHub
前两讲让寅宾会搜、会记。这一讲解决另一个问题：如何把一套成熟的工作方法交给它重复使用。
如果每做一次周报都要重新解释格式，每分析一次合同都要重新写规则，智能体就永远是“新员工”。Skill 的作用，是把经过验证的做法沉淀成可复用说明书。
Skill 不是多了一个模型，而是让智能体在需要时获得一套明确的专业工作流。
学完这一讲，你应该能够回答：
| 问题 | 本讲给出的答案 |
|---|---|
| Skill 是什么 | 以 SKILL.md 为核心的指令包，告诉智能体如何完成一类任务 |
| Plugin 是什么 | 为运行时增加渠道、模型、工具或外部系统集成能力 |
| 去哪里找 | 使用 ClawHub 搜索社区技能，也可以维护团队私有技能 |
| 如何安装到公共区 | 使用 --global 安装到共享 managed skills |
| 如何只装到自己的工作区 | 默认安装到当前工作区的 skills/ |
| 同名时谁生效 | 工作区技能优先级最高，会覆盖共享层与内置技能 |
| 最大风险是什么 | 社区技能可能包含不安全指令，安装前必须审查与验证 |
一、Skill 和 Plugin 有什么区别
这两个词经常混用，但它们在系统里的位置完全不同。
| 对比项 | Skill | Plugin |
|---|---|---|
| 本质 | Markdown 指令与配套资源 | 运行时扩展 |
| 主要回答 | “这类任务应该怎么做” | “系统还能连接什么、调用什么” |
| 典型内容 | 流程、检查清单、模板、脚本、参考资料 | 渠道、模型、工具、API、协议适配 |
| 例子 | 竞品周报、合同审阅清单、课程课件规范 | 飞书渠道、Codex 集成、SearXNG 搜索 |
| 安装方式 | openclaw skills ... | openclaw plugins ... |
| 是否直接增加新接口 | 通常不会 | 通常会 |
一个简单判断方法是：
如果它主要告诉智能体“步骤和标准”，通常是 Skill；如果它让系统多出一种外部能力，通常是 Plugin。
Skill 也可以携带脚本和资源，但它仍然围绕一套工作方法组织。比如“生成课程讲义”的 Skill 可以附带课件模板、校验脚本和排版规则；真正负责连接对象存储的，仍可能是 Plugin 或已有的文件工具。
二、一个 Skill 由什么组成
最小 Skill 是一个目录，其中必须有 SKILL.md：
my-skill/
├── SKILL.md
├── references/
│ └── checklist.md
├── templates/
│ └── report.md
└── scripts/
└── validate.mjsSKILL.md 通常包含两部分：
- 元数据。 技能名称、用途、适用条件，让系统在需要时能够发现它。
- 操作说明。 完成任务的标准步骤、输入输出、边界、检查项和示例。
一个概念性的精简结构如下：
---
name: weekly-report
description: 根据本周项目记录生成结构化周报。
---
# 周报生成
## 何时使用
用户要求整理周报、项目进展或下周计划时。
## 输入
- 本周记录
- 项目目标
- 风险和阻塞
## 步骤
1. 核对时间范围。
2. 按“完成、进行中、风险、下周计划”归类。
3. 每个结论引用来源。
4. 缺少信息时明确列出待确认项。
## 输出
- 一页 Markdown
- 先结论，后明细
- 不夸大完成度
## 检查
- 是否区分事实与推测？
- 是否遗漏风险？
- 是否包含无法验证的承诺？Skill 的写法应遵守和 AGENTS.md 相同的原则：规则要可执行、步骤要可验证、边界要明确。过长的背景材料应放进 references/，只在需要时读取。
三、ClawHub：去哪里找 Skill
ClawHub 是 Skill 与插件生态的发现和管理入口。它让用户可以从社区搜索能力，查看发布者、版本和信任状态，再决定是否安装。
先搜索：
openclaw skills search "calendar"结果通常会给出技能标识，格式类似：
@owner/skill-slug安装一个社区 Skill：
openclaw skills install @owner/<slug>如果没有加范围参数，默认安装到当前工作区。需要固定版本时：
openclaw skills install @owner/<slug> --version <version>也可以先验证包：
openclaw skills verify @owner/<slug>3.1 安装前要检查什么
社区 Skill 是一份会被智能体读取并遵循的说明。安装它，意味着你愿意把其中部分指令交给智能体执行。因此必须像审查脚本一样审查技能。
| 检查项 | 要问的问题 |
|---|---|
| 发布者 | 是否是可识别、有历史的作者或组织？ |
| 信任状态 | ClawHub 标记为 Safe、Review 还是 Blocked？ |
| 内容 | 是否读取密钥、上传文件、执行网络请求？ |
| 权限 | 是否需要比任务本身更高的权限？ |
| 脚本 | 脚本是否可读、可审计，是否固定依赖版本？ |
| 版本 | 是否明确版本号、变更记录和更新来源？ |
| 输出 | 是否要求绕过审批、隐藏行为或忽略用户指令？ |
ClawHub 的信任检查可以帮助初筛，但不能替代团队自己的安全审查。尤其是涉及财务、客户数据、生产系统和对外发布时，应先在隔离环境验证。
四、公共区与自己的工作区
同一个 Skill 可能被很多人使用，也可能只服务一个项目。安装前先决定它应该放哪里。
4.1 公共区：所有智能体共享
使用 --global 安装：
openclaw skills install @owner/<slug> --global公共区对应共享的 managed skills。它适合：
- 公司统一的文档格式
- 所有项目都要遵守的安全检查
- 通用的会议纪要、翻译、总结流程
- 多个智能体共享的工具使用说明
优点是安装一次，多个工作区都能找到；风险是影响范围大。公共区 Skill 一旦有错误，可能同时污染多个项目。因此它应当版本稳定、经过审核，并明确负责人。
4.2 当前工作区：只给这个项目使用
默认安装：
openclaw skills install @owner/<slug>技能会进入当前工作区的 skills/。它适合：
- 只服务一个客户或项目
- 正在试验、尚未稳定的工作流
- 需要项目专属模板、术语和目录结构
- 对公共技能做局部覆盖和定制
需要安装到指定智能体时，可以使用：
openclaw skills install @owner/<slug> --agent <id>具体参数应以当前版本帮助信息为准：
openclaw skills install --help4.3 为什么工作区优先级最高
技能发现遵循从近到远、从具体到通用的顺序。可以把它概括为：
当前工作区 skills/
> 当前工作区 .agents/skills/
> 用户目录 ~/.agents/skills/
> 共享 managed skills/
> Workshop skills/
> 内置 bundled skills/
> 额外目录与 Plugin skills越靠上的位置越贴近当前任务，也越容易覆盖下面的同名技能。
假设公共区已经安装了 weekly-report，但当前项目需要不同的表格格式，可以：
- 不修改公共区版本。
- 在当前工作区创建同名 Skill。
- 只覆盖项目的输出模板。
- 让其他项目继续使用公共区版本。
这相当于软件工程中的“默认实现 + 项目覆盖”，比修改全局版本更安全。
五、查看、更新与排查
安装不是终点。一个 Skill 进入团队后，还需要知道它来自哪里、当前是什么版本，以及是否还能正常工作。
常用命令：
openclaw skills list
openclaw skills info <name>
openclaw skills check
openclaw skills update --all
openclaw skills update --all --global| 命令 | 用途 |
|---|---|
openclaw skills list | 查看当前可发现的 Skill 及所在层级 |
openclaw skills info <name> | 查看来源、版本和说明 |
openclaw skills check | 检查技能包结构和潜在问题 |
openclaw skills update --all | 更新当前范围的技能 |
openclaw skills update --all --global | 更新公共区技能 |
如果要管理本地安装的 ClawHub 内容，也可以使用 ClawHub CLI：
npm i -g clawhub
clawhub uninstall @owner/my-skill安装后至少做一次实际演练：准备一个最小输入，让智能体完成技能定义的任务，再核对输出是否符合 SKILL.md 的验收标准。
六、什么时候该沉淀成 Skill
不是所有操作都值得做成 Skill。适合沉淀的场景通常有三个特征：
- 高频。 每周或每天都要重复。
- 稳定。 步骤和输出标准已经相对固定。
- 有价值。 做对与做错差异明显，值得统一。
例如：
| 场景 | 是否适合 Skill | 原因 |
|---|---|---|
| 每周生成竞品简报 | 适合 | 高频、格式稳定、可验证 |
| 公司合同风险清单 | 适合 | 规则明确，但需保留人工法务复核 |
| 一次性查天气 | 不适合 | 频率低，直接提问即可 |
| 客户数据导出 | 需要谨慎 | 权限高，应先定义治理和审批，不只是一份说明 |
| 课件排版规范 | 适合 | 多课程重复使用，可附模板和校验脚本 |
Skill 的上限是“规范工作方法”，不能代替权限系统。涉及资金、合同、发布和隐私的动作，仍必须由运行时权限和人工审批控制。
七、团队推荐工作流
一套可持续的 Skill 流程可以分成六步：
- 找。 先搜索 ClawHub，优先使用成熟能力，不重复造轮子。
- 审。 阅读
SKILL.md、脚本、依赖和权限需求。 - 试。 安装在个人工作区，用低风险样本验证。
- 改。 按团队术语、模板和验收标准增加覆盖层。
- 升。 稳定后评审并发布到公共区，明确版本和负责人。
- 验。 每次更新运行回归用例，保留可回退版本。
这里最重要的顺序是先试后升。不要直接把社区包安装到所有智能体的公共区，也不要因为一次成功就把它变成公司标准。
八、课堂练习
完成一次 Skill 的搜索、安装和验证：
- 在 ClawHub 搜索一个与自己的高频任务相关的 Skill。
- 记录发布者、版本、权限需求和信任状态。
- 阅读
SKILL.md，列出你认为有风险的三行指令。 - 默认安装到当前工作区。
- 用一个不含敏感信息的样本执行。
- 再安装一个同名测试版本到公共区，验证工作区是否覆盖公共版本。
- 最后执行
openclaw skills list，确认两个范围都能被识别。
练习结束后回答：这个 Skill 应该留在工作区，还是值得升级到公共区？理由是什么？
九、本讲小结
- Skill 是工作方法，Plugin 是运行时能力。 先判断需求，再选择正确的扩展方式。
- ClawHub 负责发现，团队负责审查。 信任标记不能替代权限判断。
- 默认安装到工作区，
--global安装到公共区。 公共区追求统一，工作区负责项目定制。 - 工作区优先级最高。 同名 Skill 可以通过覆盖实现局部差异，不必修改全局版本。
- 先试后升，更新必验。 每个 Skill 都应有负责人、版本和回退路径。
下一讲：第五讲：飞书语音控制 Codex 桌面版。
课程： 智能体工程导论
讲师： Job Zhao
公司名称： 青岛火一五信息科技有限公司
联系邮箱： postmaster@huo15.com
