OpenClaw 安全必装 Skill Vetter 使用指南:给 OpenClaw 建立“先审后装”的第三方 Skill 安全流程

一篇讲清楚如何在 OpenClaw 中安装、配置和使用 Skill Vetter 的实战指南，覆盖安装路径、审查流程、风险分级、提示词模板与自动巡检最佳实践。

第三方 skill 不是不能装，但别上来就装。
在 OpenClaw 这种天然能读文件、跑命令、联网、操作会话的 agent 环境里，先审查、后安装不是洁癖，而是基本生存法则。

我是 AI灵感闪现，使用 OpenClaw 小龙虾让 AI 自主管理工作和生活上的问题；使用 Claude Code + BMAD AI 驱动敏捷开发框架，让 AI 自主开发和交付软件来表达想法和灵感。是 MoneyMind 省钱思维 App 和 HeartPetBond 心宠纽带 App 开发者。正在实践和分享让 AI 自主解决健康、生活、投资和等方面的问题。我尽可能让 AI 自己完成从目标到交付以及演进的闭环，以最少的人为交互与监督，让 AI 自己跑流程。我只给 AI 想法或目标，全程不陪跑，让 AI 自主运行类似 Tesla FSD 自动驾驶。

为什么 Skill Vetter 值得单独讲

很多人第一次接触 OpenClaw skills，会把它理解成“提示词插件”或者“工具说明文件”。这理解不算错，但也不完整。

一个 skill 往往不只是告诉 agent 要怎么做事，它还可能间接影响：

会读取哪些文件
会运行哪些命令
会不会联网
会不会接触凭证、记忆文件、配置文件
会不会把动作扩散到 workspace 之外

所以安装第三方 skill，本质上不是“下载一个方便的小工具”，而是在给 agent 增加一套新的行为协议。协议本身如果不安全，后面所有自动化都会被放大。

Skill Vetter 的价值，就在于把这一步前移：

Never install a skill without vetting it first.

它不是一个独立 CLI，而是一套给 agent 使用的安全审查协议：在安装 skill 之前，先读完整源码、检查红旗项、评估权限范围、输出标准化结论，再决定装不装。

Skill Vetter 是什么

Skill Vetter 可以理解成一个“安装前安检员”。它要求 agent 在面对未知 skill 时，不只看 README 或 SKILL.md，而是检查全部文件。

核心关注点通常包括：

来源是否可信
是否存在可疑外联
是否读取敏感目录或隐私文件
是否出现 eval / exec / 混淆代码 / base64 解码等风险行为
是否请求 token、凭证、elevated 权限
文件读写与联网范围是否符合最小权限原则

换句话说，它不是教你“怎么装 skill”，而是教 agent 在装之前先回答三个问题：

这个 skill 到底在干什么？
它需要多大权限？
这权限值不值得给？

推荐安装位置：放全局，而不是埋在单个项目里

如果 Skill Vetter 只是某个 workspace 的局部习惯，那它的收益会很有限。更合理的方式，是把它作为一条全局安全基础设施来安装：

~/.agents/skills/skill-vetter/

这么放有几个好处：

同一台机器上的多个 OpenClaw agent 都能复用
安全策略统一，不容易“这个 agent 会审，那个不会审”
后续巡检、升级、审计更好做

大致可以把 skills 的放置方式分成三类：

类型	典型位置	适用场景
OpenClaw 内置 skill	OpenClaw 安装目录	官方能力，通常不手改
用户级全局 skill	`~/.agents/skills/`	多 agent 共用
单 agent / 单项目 skill	某个 workspace 内	只服务单一场景

像 Skill Vetter 这种面向“所有第三方 skill 安装流程”的能力，明显更适合第二类。

最推荐的使用方式：让 agent 先 vet，再决定装不装

Skill Vetter 最常见的使用方式，并不是让你敲一个叫 skill-vetter 的命令，而是直接用自然语言把规则交给 OpenClaw。

例如：

帮我先 vet 一下这个 skill：https://github.com/OWNER/REPO/tree/main/skills/SKILL_NAME要求：- 按 skill-vetter 协议审查全部文件- 输出标准 vetting report- 明确告诉我是否建议安装- 在我确认前，不要安装

如果你已经知道自己大概率要装，也可以把流程写成：

我想安装这个 skill：https://github.com/OWNER/REPO/tree/main/skills/SKILL_NAME要求：1. 先用 skill-vetter 做完整审查2. 输出风险等级、红旗项、权限范围3. 如果 verdict 是 SAFE TO INSTALL，再安装到 ~/.agents/skills/4. 如果是 HIGH 或 EXTREME，停止并等我确认

这个提示词的关键不是形式，而是先后顺序不能反：先审，再装。

一套够用的 SOP：安装任何第三方 skill 之前都走一遍

如果要把 Skill Vetter 落成团队或个人标准，我建议把流程固定成下面这 6 步。

第一步：确认来源

先问清楚它从哪来：

OpenClaw 官方内置
ClawHub
GitHub 仓库
个人分享或私有链接

同时补充判断：

作者是谁
最近更新时间
是否有人在用
是否有明确用途说明

来源不是充分条件，但能快速筛掉一批低质量或来路不明的东西。

第二步：强制逐文件审查

这一步最容易被偷懒，也最不该偷懒。

重点不是看它“说自己要做什么”，而是看它实际上能做什么。常见红旗包括：

curl / wget 指向陌生地址
直接向外部服务发送数据
读取 ~/.ssh、~/.aws、~/.config 等敏感目录
访问 MEMORY.md、USER.md、SOUL.md、IDENTITY.md 等私有上下文
base64 解码、压缩包展开后再执行等掩蔽行为
eval() / exec() 配合外部输入
修改 workspace 外系统文件
额外安装未声明依赖
请求 sudo / elevated 权限
读取浏览器 cookie、session 或 credential 文件

有一条经验非常重要：

审的是代码，不是宣传。

README 写得再温柔，也不能代替源码审查。

第三步：评估权限边界

审查之后，要把权限讲清楚，而不是只说一句“看起来没问题”。

至少要回答：

它会读哪些文件？
它会写哪些文件？
它会运行哪些命令？
它需要联网吗？
联网对象和功能是否匹配？
能不能再缩小权限？

如果一个 skill 的功能只是格式化 Markdown，却想读取整套个人记忆文件或系统配置，那就已经是明显不匹配了。

第四步：做风险分级

一套简单但好用的分级如下：

风险等级	含义	建议
🟢 LOW	本地文本处理、格式化、天气等低风险能力	审查后可安装
🟡 MEDIUM	文件操作、浏览器、第三方 API 集成	完整审查后谨慎安装
🔴 HIGH	涉及凭证、系统配置、自动外发	必须人工批准
⛔ EXTREME	root、安全策略修改、大范围隐私读取	禁止默认安装

这套分级的价值在于：让“停下问人”变成制度，而不是临场感觉。

第五步：输出标准化审查报告

报告要能被复查、被对比、被留档。一个够用的格式大概像这样：

SKILL VETTING REPORT═══════════════════════════════════════Skill: [name]Source: [ClawHub / GitHub / other]Author: [username]Version: [version]───────────────────────────────────────METRICS:• Downloads/Stars: [count]• Last Updated: [date]• Files Reviewed: [count]───────────────────────────────────────RED FLAGS: [None / List them]PERMISSIONS NEEDED:• Files: [list or "None"]• Network: [list or "None"]• Commands: [list or "None"]───────────────────────────────────────RISK LEVEL: [🟢 LOW / 🟡 MEDIUM / 🔴 HIGH / ⛔ EXTREME]VERDICT: [✅ SAFE TO INSTALL / ⚠️ INSTALL WITH CAUTION / ❌ DO NOT INSTALL]NOTES: [Any observations]═══════════════════════════════════════

统一格式最大的好处，是之后做批量巡检时，能快速横向比较不同 skill 的风险侧写。

第六步：安装后留痕

别把结论只留在聊天窗口里。建议每次安装后都落盘记录：

安装日期
skill 名称
来源
风险等级
审查摘要
安装路径

常见落点可以是：

memory/YYYY-MM-DD.md
security-audits/
skill-reviews/

如果你的 OpenClaw 实例不止一个，这份记录会越来越值钱。

OpenClaw 环境里，哪些文件默认应该视为高敏感

在很多本地 agent 工作流里，真正最容易被忽视的不是 shell 命令，而是上下文文件。

尤其是这些：

MEMORY.md
USER.md
SOUL.md
IDENTITY.md
TOOLS.md
openclaw.config.json
memory/*.md

这些文件经常包含长期偏好、私人背景、内部规则、系统连接信息、记忆摘要等。对 OpenClaw 来说，它们的敏感度不低于许多配置文件。

所以如果第三方 skill 试图主动读取这些内容，默认就该按高风险处理，而不是轻轻放过。

三条最实用的最佳实践

1. 把“先 vet 再安装”写进 AGENTS.md

只靠口头提醒，很快就会失效。更稳妥的做法，是把规则写进 agent 的行为规范里，例如：

### Skill 安装安全规则所有 Skills 安装前，必须先用 Skill Vetter 审查，通过后才能安装。无例外。审查要求：- 读取并检查全部文件- 检查外联、敏感文件访问、混淆/编码内容、eval/exec、凭证请求、sudo/elevated 权限- 输出标准化审查报告- 如风险为 HIGH 或 EXTREME，必须先征求人工确认

这样以后你只要说“帮我安装这个 skill”，agent 更容易自动走到“先审后装”那条轨道上。

2. 高风险场景一律人工确认

凡是碰到下面这些条件，最好直接停下来问人：

凭证或 token
对外发消息或数据
系统配置变更
root / elevated 权限
隐私文件读取
联网到陌生地址

不要把“应该确认一下”交给临场直觉。安全流程一旦例外太多，最后就等于没有流程。

3. 定期巡检已安装 skills

装完不代表结束。skill 目录可能被替换、更新、篡改，也可能因为版本升级引入新风险。

比较实用的节奏是：

高频快速巡检：例如每 4 小时一次
低频完整复审：例如每周或每月一次

巡检结果建议按时间戳写入独立文件，例如：

security-audits/skills-audit-2026-04-05_0800.md

保留历史，而不是反复覆盖，才能看出风险变化趋势。

一组可以直接复用的提示词模板

如果你想快速把这套流程推广到其他 OpenClaw 会话里，下面三类模板最实用。

模板 1：先审查，不安装

请用 Skill Vetter 协议审查这个 skill，但先不要安装：[在这里粘贴 skill 链接]要求：1. 读取并检查该 skill 的全部文件2. 检查外部网络请求、敏感文件访问、base64/混淆内容、eval/exec、cookie/session 访问、workspace 外修改、凭证请求3. 输出标准化报告：名称、来源、作者、更新时间、审查文件数量、红旗列表、权限范围、风险等级、是否建议安装4. 最后给出简洁结论：SAFE / CAUTION / DO NOT INSTALL

模板 2：审查后自动安装

我想安装这个第三方 skill：[在这里粘贴 skill 链接]请按以下 SOP 执行：1. 先做完整 skill vetting2. 审查全部文件，列出红旗项和权限范围3. 输出标准化 vetting report4. 只有在风险等级为 LOW，或你明确判断可以安全安装时，才继续安装5. 安装路径默认使用 ~/.agents/skills/6. 安装完成后，告诉我实际安装路径、安装了哪些文件、以后如何调用规则：- HIGH 或 EXTREME 风险时停止并等待确认- 不要跳过代码审查步骤

模板 3：巡检本机所有第三方 skills

请对 ~/.agents/skills/ 下所有第三方 skills 做一次安全巡检。要求：- 参照 skill-vetter 红旗清单- 检查是否出现新增可疑文件、外联代码、敏感文件访问、混淆/编码内容- 输出每个 skill 的状态：✅ 正常 / ⚠️ 需关注 / ❌ 有问题- 将完整结果写入审计文件

这类模板的意义，不只是省打字，而是把流程标准化，让不同会话、不同 agent、不同机器都更容易复用同一套安全习惯。