OpenClaw Skill 安装与验证：ClawHub、Workspace、个人 Library 与 Skill Workshop

Skill 会进入 Agent 上下文，也可能带脚本、依赖和凭据要求。出现在 ClawHub、Personal Library、Skill Workshop 或显示扫描通过，都不能替代人工读文件、固定版本 / revision 和隔离测试。

2026.9.4 下仍先分清五种对象

1. Workspace / local Skills

跟着工作区或本地目录加载，适合项目级指令和能力。同名目录可能覆盖其他来源，因此要确认最终实际加载路径。

2. Personal Skill Library

2026.9.1 新增。共享 Gateway 中，已登录用户可以维护自己的 Skills，不需要为每一次个人 Skill 修改获取宿主机文件权限。

入口：

openclaw skills library

Personal Library 的关键设计不是“又一个安装命令”，而是：

• 每个用户可以维护自己的 Library；
• 默认私有；
• 分享和编辑权限分开；
• Session 可以附着到一个确定的 immutable revision，避免 Skill 后续被更新时静默改变正在运行的 Session。

3. Skill Workshop

2026.9.3 进一步调整 Workshop：每个 Agent 现在有一套跨 workspace 持久存在的 collection。

一个 Agent 学到的 Skill 不再因为换 workspace 就要跟着搬目录。界面也把：

• 已安装的 Skills；
• 等待 review 的 Suggestions；
• 已经做过的历史决定

分得更清楚。

这和 Personal Skill Library 不是一回事：

• Personal Library 的主要 owner 是登录用户；
• Skill Workshop 的主要 owner 是Agent；
• workspace Skill 仍跟项目 / 工作区边界走。

Startup / Doctor 会迁移 ownership 可以明确确定的 legacy Workshop skills；模糊或冲突副本会保留给人工 review。旧配置 skills.workshop.allowSymlinkTargetWrites 已退出当前模型，不要继续把它当作 9.3 的迁移方案。

4. ClawHub 包

ClawHub 是发现、分发和审计入口，会记录发布者、版本、文件、来源与扫描状态。它不是“官方市场里能搜到就等于零风险”。

5. Plugins

Plugin 可以向 Gateway 注册工具、命令、服务或路由，运行面通常比普通 Skill 更宽。不要用 Skills 的审查标准代替 plugin capability / runtime 审查。

9.4：发现体验变简单，不代表信任边界变简单

9.4 把过去比较分散的 Skills / Plugins 发现流程收进 Web UI：

• Plugins workspace 可以浏览和过滤 ClawHub plugin，也能看到 bundled / local plugin；
• detail page 会集中展示说明、compatibility、settings、permissions 与 troubleshooting；
• 安装和配置可以在浏览器内继续完成，并等待需要的 restart；
• 聊天中的推荐可以直接打开对应 plugin / skill 的详情与 setup；
• Skill 窗口对长内容、导入文件选择与较慢依赖安装也做了可用性修复。

这降低的是“找不到入口”的成本，不是供应链风险。推荐、搜索排名、ClawHub audit、installed 状态都不能替代来源和 capability review。

尤其 plugin 的 runtime 面通常比 Skill 更宽：它可能注册 Gateway 工具、服务、路由或长期进程；因此 Web UI 的一键安装不应被理解成可以跳过 plugins inspect / capability review。

先确认实际加载的是谁

对于普通 Skills：

openclaw skills list --verbose
openclaw skills info <name>
openclaw skills check

对于 Personal Library，再查看：

openclaw skills library

需要把 Library Skill 固定到 Session 时，优先使用官方 CLI 提供的 exact revision / attach 路径，不要只记录一个会继续变化的名字。

插件使用独立命令：

openclaw plugins inspect <id>
openclaw plugins doctor

9.4 升级完成后，仍要在 UI / Workshop 中实际确认 Skills 与 Suggestions 是否落在预期 Agent 下，并检查新发现 / 推荐的对象实际来自 bundled、local 还是 ClawHub。Doctor migration summary 是重要信号，但不是唯一验收标准。

Personal Skill Library 解决什么问题

共享 Gateway 过去很容易出现一种混乱：

A 用户自己的实验 Skill、团队共用 Skill、服务器 workspace Skill 全都写在同一层目录里。

9.1 后可以把它们拆开：

• 项目固定能力放 workspace；
• 个人长期复用内容放 Personal Library；
• 需要外部发现 / 分发的内容走 ClawHub；
• 需要注册 Gateway runtime 能力的对象才做 plugin。

9.3 增加了一层更明确的 Agent 学习边界；9.4 又把“从历史对话归纳能力”的过程变成可见、可 steer 的聊天。Agent 自己长期积累、等待 review 或已经接受的能力仍放在它的 Workshop 中，不依赖当前 workspace 承载这套 collection。

这样权限、更新和回滚更容易解释。

但要注意：Personal Library 和 Skill Workshop 都不是安全沙箱。 一个 Skill 里引用的脚本、命令、网络、文件和凭据风险，不会因为它属于某个用户或某个 Agent 就消失。

Skill Workshop：ownership / target 仍要继续检查

ownership 是否正确

同一个旧 Skill 如果曾经在多个 workspace 留下副本，Doctor 必须判断它实际属于哪个 Agent。能够安全确定 ownership 的会迁移；冲突或模糊项应保留 review，而不是静默覆盖。

Suggestions target 是否真的落到 Agent 边界内

9.3 发布后 Issue #142583 报告了一个旧环境迁移现场：Doctor 先显示部分 Workshop proposal 已 retarget，紧接着验证阶段又发现若干 proposal target 仍在 Agent directory 外。

这是一条单环境报告，不能外推为 9.3 的普遍故障。但它给出一个很具体的验收动作：老 Workshop 用户升级后要实际看 Suggestions target，不要只看“migrated/retargeted”汇总。

review 要看完整 instructions

9.3 的 Workshop comparison 会显示更完整的 instruction diff，包括长 Skill 靠后的变化。审查时不要只看标题或前几十行；真正危险的网络、删除、上传和 credential 指令经常藏在后段。

Skill Workshop：9.4 的 Learn from past conversations 怎么用

在 Skill Workshop 里选择 Learn from past conversations，会打开一段可见聊天。你可以跟随它正在归纳什么、补充方向，也可以中途停止。

当前需要分清：

• Auto：允许 Claw 根据找到的模式直接应用改进；
• Propose：只生成 Suggestions，保留人工 review / approve；
• 手动启动一次学习不会自动开启持续 self-learning；
• 模型调用仍消耗正常额度 / 费用，原有工具、文件、网络和 secret 权限也不会因为“学习模式”自动缩小。

对生产 Agent，建议先从 Propose 开始。历史对话里可能混有一次性 workaround、临时路径或高权限操作；“反复出现”不等于“应该固化成长期 Skill”。

旧版未完成的 history scan 不能在新流程里 resume，需要重新启动学习聊天；已经安装的 Skills 与已有 proposals 会保留。9.3 的 ownership / proposal target 验收仍然有意义，9.4 只是把新的学习过程做得更可观察。

Personal Library 的建议工作流

创建或导入后先读，再启用

通过 openclaw skills library 创建、读取、更新或导入后，先检查：

• SKILL.md；
• 支持文件；
• scripts / templates；
• 外部依赖；
• 网络目的地；
• 是否要求 token / cookie / SSH / browser session；
• 是否包含写入、删除、发送、发布或部署动作。

Session 固定 revision

团队里最容易踩的坑是：昨天审查过 Skill A，今天维护者改了 Skill A，同名对象已经不是昨天那份内容。

Personal Library 支持 immutable revision 后，重要 Session 应固定经过审查的 revision，而不是只靠“最新版”。

Share 不等于 Edit

把 Skill 分享给其他 identity，不应自动意味着对方可以修改原始 Skill。共享 Gateway 的权限设计要分别记录：

• 谁能看；
• 谁能用；
• 谁能改；
• 谁能发布 / 共享；
• 当前 Session 实际绑定哪一 revision。

ClawHub 安装前检查

发布者与来源

核对 owner、slug、来源仓库、维护者身份和市场链接是否一致。相似名称不是同一发布者。

版本与变更

记录确切版本、发布日期、changelog 和兼容要求。不要在没有审查 diff 的情况下长期追随 latest。

文件与许可证

打开 SKILL.md 及全部支持文件、脚本和模板。没有明确许可证或来源说明时，保留为未知。

审计状态

查看 ClawHub audit 状态和 findings。Pass 不是保证；Malicious 不安装，Warn 或 Review 先读原因。

逐项检查权限

• 是否包含 shell、PowerShell、Python、Node 或下载二进制脚本；
• 依赖是否来自明确的软件包源，是否锁定版本或校验摘要；
• 是否访问外网，最终主机与业务目的是否清楚；
• 是否读取、写入、删除或批量遍历工作区外文件；
• 是否要求 API Key、cookie、SSH、浏览器登录态或企业账号；
• 是否可能发消息、发布、付款、部署或修改生产数据。

尽量使用测试目录、只读 token、测试账号和更小额度；能关闭网络或限制必要主机时，不要默认全开。写入、外发和删除保留人工确认。

ClawHub 安装与验证命令

先搜索并固定已经核对的版本：

openclaw skills search "<query>"
openclaw skills install @owner/<slug> --version <version>

再校验注册表信任封套并查看 Skill Card：

openclaw skills verify @owner/<slug> --version <version>
openclaw skills verify @owner/<slug> --version <version> --card

最后重新确认实际加载来源：

openclaw skills list --verbose
openclaw skills info <name>
openclaw skills check

Plugin 升级后仍要看 capability review

插件更新和 Skill 内容更新的安全边界不同。插件 artifact 如果声明新的 capability，OpenClaw 可以要求 operator 明确 review；非交互更新参数不应该被当成自动接受新增权限的理由。

9.4 起，即使 core 已经是最新，运行 openclaw update 也会检查 eligible plugins；明确 pin 的版本仍会保留。

如果 core package 已经更新、但 plugin sync 或最终化停在 capability review，优先在交互终端执行：

openclaw update repair

先读 capability 变化，再决定是否接受。只有已经人工审查过这些变化的自动化环境，才考虑相应的非交互批准选项。

更新后重新检查：

openclaw plugins inspect <id> --runtime --json
openclaw doctor --post-upgrade
openclaw gateway status --deep

不要只看 core version 判断 plugin cohort 已完全同步。

Plugin SDK：deprecated、scheduled removal、removed 要分开

官方 migration guide 一直区分“已经删除”和“仍在兼容窗口”的 API。已经 removed 的旧入口包括 openclaw/plugin-sdk root、openclaw/plugin-sdk/compat、openclaw/extension-api 等；依赖这些入口的插件需要迁移。

对于仍在 compatibility registry 的 subpath，不要把 removeAfter 理解成“日期一到代码自动消失”。它代表进入移除审查 / blocker 检查窗口，实际删除仍取决于公开 replacement 与受支持外部插件迁移状态。

迁移时也不要因为源码里找到一个 private-local export，就把它当成第三方 typed-public SDK。运行时存在 export，不等于公开稳定 contract。

隔离测试

1. 使用新工作区、测试文件和低权限账号，不挂载真实凭据或生产目录。
2. 用一个可人工核对的最小任务，避免首次就跑批量、写入或外发。
3. 记录工具调用、网络主机、文件 diff、日志与退出状态。
4. 一旦访问范围超出说明、要求提权或下载未知内容，立即停止。
5. 对 Personal Library 额外记录实际 revision；对 Workshop 额外记录 owning Agent 与 Suggestion target。

更新、停用与回退

ClawHub 更新前记录版本、备份工作区并重新阅读 diff、changelog 与扫描结果：

openclaw skills update @owner/<slug>

需要回到旧版时，使用已记录的 owner、slug 与版本重新安装：

openclaw skills install @owner/<slug> --version <known-version>

Personal Library 优先使用 Library 自己的 revision / rollback 机制，不要为了回退直接覆盖 workspace 同名目录。

Skill Workshop 的 migration / proposal 问题优先通过 Doctor、Workshop review 与官方支持路径处理，不要手工把 proposal 文件跨 Agent 目录搬来搬去制造新的 ownership 歧义。

对象实际是 plugin 时则使用 plugins CLI，不要把 Skill 的删除 / 回退方法套到 Gateway plugin。

发现可疑包时

保留 owner、slug、版本 / revision、页面 URL、来源仓库、可疑文件、复现步骤、脱敏日志和 verify 结果。不要公开 token、cookie、私有文件或个人身份资料。市场审计和官方发布都是强信号，但都不等于零风险保证。

先了解ClawHub 的证据边界，再按安全清单完成真实接入前检查；9.4 的发现、学习与扩展变化看2026.9.4 更新解读，9.3 的 Workshop ownership / migration 基线仍可参考2026.9.3 更新解读。