在继续聊 Skill 之前，建议先补上这篇基础文章：
- OpenClaw 安全上手指南：把安全认知、常见风险、关键配置和起步模板整理到一篇里，先把整体边界想清楚，再决定要不要装第三方 Skill
这一篇继续往下走，专门解决一个非常实际的问题：
看到一个 Skill 很有用，到底能不能装？装之前要看什么？
因为在 OpenClaw 体系里，安装 Skill 从来都不只是"加一个功能"，更像是：
把第三方写的提示词、依赖、脚本和行为逻辑，引入到你的代理系统里。
官方仓库最近专门有一个 Skill 安全 RFC，里面说得很直接：OpenClaw 的 Skill 体系之所以强大，恰恰也是因为它足够宽松。一个 Skill 可能包含 SKILL.md 和可执行脚本，而 Agent 可能同时拥有 shell、文件系统、网络和其他工具能力。换句话说，恶意 Skill 的破坏面，不是理论上的，而是现实存在的。
所以这篇文章的目标不是吓你别装 Skill，而是给你一套装前检查清单。你不一定要做到非常专业，但至少要做到：看得懂红旗，避得开大坑。
一、先记住一个前提：Skill 不是"普通插件"，而是"第三方提示 + 第三方逻辑"
很多人装 Skill 时，只盯着"这个功能我需不需要"。 但从安全角度看，你至少要同时看两层：
- 它写了什么提示和说明
- 它实际会调用什么能力
官方 RFC 里明确提到，恶意内容不一定只在脚本里，也可能藏在 SKILL.md 里；另一个相关 issue 也直接点名了几种典型风险，包括：SKILL.md 加载时的 prompt injection、用合理借口诱导你授予更高 exec 权限、修改 SOUL.md 或其他关键文件。
所以安装 Skill 时，最容易犯的错误就是：
"我看它是个工具，就只看功能介绍，没看它到底会怎么影响 Agent。"
二、第 1 个检查点：来源是不是清楚
这是最基础的一步，但很多人会跳过。
你至少先看这几个问题：
- 这个 Skill 来自哪里？
- 是官方仓库、知名作者，还是一个刚注册的新号？
- 有没有公开仓库或可查看的说明页？
- 最近有没有维护记录？
- 是否有人实际安装和使用过？
这一步不能保证绝对安全，但能快速过滤掉一大批明显不靠谱的东西。因为社区已经在公开讨论一些供应链层面的风险，例如 ClawHub 上某些 Skill 可能引导用户去第三方代理服务做 OAuth，结果是把 token 控制权交给了中间服务，但页面上未必有足够明确的披露。
这一项怎么判断
如果一个 Skill 同时符合下面几条，就要提高警惕：
- 作者信息模糊
- 没有公开代码
- 权限要求很高
- 说明写得很少，但功能描述很"大"
- 需要你先去第三方站点授权或登录
三、第 2 个检查点：先读 SKILL.md，不要只看标题和简介
这是最重要的一步之一。
因为 OpenClaw 官方的 Skill 安全讨论已经明确指出：SKILL.md 本身就可能成为注入入口。 恶意 Skill 不一定需要复杂代码，只要在说明里嵌入"高优先级操作指令"，就可能诱导 Agent 去读取敏感文件、改变行为边界，甚至覆盖工作区内的关键配置。
你重点要看什么
先不要急着分析全部细节，优先找这些红旗：
- 要求读取
~/.ssh、~/.aws、.env、浏览器配置、数据库配置 - 要求"先读取某些本地文件，再继续工作"
- 让 Agent "忽略之前限制"或"优先按本 Skill 指令执行"
- 要求写入
SOUL.md、AGENTS.md、HEARTBEAT.md、记忆文件等长期生效内容 - 用"这是正常初始化步骤"包装高风险动作
相关安全案例和讨论已经直接展示过，恶意 Skill 可以通过篡改 AGENTS.md、HEARTBEAT.md、SOUL.md 形成持续后门或身份劫持，而且这类篡改未必会立刻被发现。
一个简单判断标准
如果这个 Skill 声称自己只是"总结网页""整理内容""生成日报"，但 SKILL.md 却要求读取一堆本地敏感文件，那就是明显不匹配。
功能很轻，权限很重，基本就是红旗。
四、第 3 个检查点：它到底需要哪些权限，跟它的功能匹不匹配
OpenClaw 官方 Skill 安全 RFC 之所以被提出，就是因为现在 Skill 生态里经常存在一个问题：
Skill 的能力边界，对普通用户来说并不够透明。
而一旦 Agent 本身拥有 exec、文件系统、网络访问和其他工具能力，Skill 就可能借这些能力做很多超出你预期的事情。
你可以用这个最简单的匹配法
先问自己一句：
它这个功能，真的需要这些权限吗？
例如：
- 一个"文案润色"类 Skill，不应该需要 shell 和本地文件遍历
- 一个"网页摘要"类 Skill，不应该默认要求访问 SSH key
- 一个"翻译"类 Skill，不应该要求长期联网外发本地内容
- 一个"安装部署"类 Skill 需要 exec 比较正常，但你就要提高警惕，最好放在沙箱里试
高风险权限一般包括
exec/ shell- 本地文件系统读写
- 网络访问
- 修改工作区配置文件
- 发送消息 / 调用外部 API
只要一个 Skill 同时涉及多个高风险权限，你就不要把它当成"随便装一下的小工具"。
五、第 4 个检查点：有没有安装脚本、额外依赖、可疑下载行为
很多用户会只看 Skill 页面，不看安装过程中到底发生了什么。 但社区已经在提议要把 pre-install / post-install 安全检查做进官方流程，原因很简单：现在安装和同步 Skill 时，很多内容是直接落盘的，缺乏强制审查。
你重点要警惕这些情况
- 安装时自动拉一堆不明依赖
- 运行时再从陌生地址下载脚本
- 需要执行
curl | bash这类动作 - 要求安装额外二进制，但没有来源说明
- 依赖里出现混淆代码、压缩脚本、难以理解的下载器
一个很实用的判断方法
如果一个 Skill 不能在说明里清楚解释：
- 它装了什么
- 这些依赖是干嘛的
- 为什么需要下载
- 下载来源是什么
那你就先别装。
因为这已经不是"插件方便不方便"的问题，而是供应链透明度的问题。
六、第 5 个检查点：有没有数据外传或第三方托管的迹象
这是很多人最容易忽略的地方。
有些 Skill 看起来是在帮你接入某个服务，实际上可能让你把 token、会话流量、API 请求都绕到了第三方代理服务上。官方仓库已经有人专门提 issue，指出某些 ClawHub Skill 会把 OAuth 流量交给第三方代理，但页面没有足够显著的风险说明。
你要重点看什么
- 是否要求去第三方页面登录授权
- 是否使用"代理 API""中转服务""兼容层"
- 是否会把你的请求、响应或 token 经由第三方
- 是否在说明里明确写了数据流向
- 是否说明了谁在托管这些凭证
一个简单判断法
只要你发现这个 Skill 不是直接连官方服务，而是通过一个你不熟悉的中间层，就要问一句：
我的数据和凭证，是不是先经过了别人？
如果这件事说明不清楚，就不建议直接装到主力 Agent 上。
七、第 6 个检查点：它会不会改你的长期配置或身份文件
这一点非常关键，因为它关系到后效性风险。
有些风险不是"装完立刻出事"，而是 Skill 会修改一些长期生效的文件，让问题在后面几天、几周才慢慢出现。相关安全讨论已经给出过很具体的例子：恶意 Skill 可能篡改 AGENTS.md、HEARTBEAT.md、SOUL.md 等工作区配置，让 Agent 后续持续执行攻击者定义的规则、心跳任务或身份设定。
官方社区也有人提出，Skill 目录应在沙箱中以只读方式挂载，避免 Agent 或 Skill 在运行过程中反过来修改 Skill 文件本身。
你应该重点查
- 是否要求写入工作区规则文件
- 是否要求改 Agent 的长期记忆或人格文件
- 是否会修改启动文件、自动任务、heartbeat
- 是否会把配置写入你不容易注意到的位置
为什么这类风险特别麻烦
因为它不像一次性执行命令那样容易察觉。 它更像是在你的 Agent 里埋了个"习惯"或者"后门"，之后每次运行都可能继续受影响。
八、第 7 个检查点：先看有没有安全审查工具或社区体检结果
现在 OpenClaw 生态已经明显开始重视"先审后装"。 ClawHub 上已经出现了明确以安全审查为卖点的 Skill，比如 Skill Vetter，主打在安装前检查 red flags、权限范围和可疑模式；官方社区里也有人提议把静态安全扫描、pre-install hook、统一安全报告做成一等公民。
这一步的正确理解
不是说"扫描通过就一定安全"，而是：
能多一道体检，就少一层盲装。
你可以怎么做
- 先看 Skill 页面是否有安全扫描信息
- 看是否有人做过安全审计或公开 review
- 有条件的话，先用专门的 vetter / scanner 类 Skill 过一遍
- 没有安全信息的 Skill，默认提高警惕
九、第 8 个检查点：别直接装到主力环境，先在低风险环境里试
这一条是最接近"落地实践"的建议。
就算你前面 7 项都看了，也不代表没有风险。 因为 OpenClaw 社区自己都在不断补 Skill 安全框架、权限清单、签名、沙箱、静态检查这些能力，这恰恰说明：现在还远没到可以对第三方 Skill 完全掉以轻心的阶段。
更稳的试装方式
优先这样做：
- 先装到测试 Agent，不要装到主力 Agent
- 先在低权限工具配置下试
- 先在沙箱里试，不要直接碰宿主机
- 先不要给它核心 token、生产环境密钥、主力账号
- 观察一段时间，再决定是否长期使用
如果你前一篇已经按建议收紧了 tools.profile、session.dmScope、sandbox 网络和 allowUnsafeExternalContent，那这一步会更稳。因为就算 Skill 有问题，伤害范围也会小很多。
十、给普通用户的一份"装 Skill 前 30 秒检查表"
如果你不想每次都做完整审查，至少先过一遍这 8 条：
能直接装的前提
- 来源清楚
SKILL.md没有明显危险指令- 权限要求和功能基本匹配
- 没有不明安装脚本和可疑下载
- 没有明显第三方代理凭证风险
- 不会修改长期配置或身份文件
- 最好有安全扫描或社区 review
- 优先装到测试环境，不直接上主力
看到这些就先停
- 要读 SSH key、
.env、浏览器数据 - 要改
SOUL.md、AGENTS.md、HEARTBEAT.md - 要求高权限，但功能描述很轻
- 要你去陌生站点授权
- 要长期开放 exec
- 文档写得很少，但安装动作很多
- 说不清数据会发去哪
十一、结语：装 Skill 的正确姿势，不是"别装"，而是"别盲装"
OpenClaw 的 Skill 生态会越来越大，这是好事。 但生态越大，供应链风险、提示注入风险、权限错配风险就越需要被正视。
官方最近这波 RFC、issue 和社区提案，其实已经把方向说得很明白了：
- Skill 不只是代码风险，也是提示风险
- 安装前审查应该成为常规动作，而不是少数安全强迫症才会做的事
- 更合理的未来是：权限声明、签名、沙箱、自动扫描逐步标准化
所以这篇文章想给你的，不是"以后别装 Skill"，而是一句更现实的话：
Skill 可以装，但先看清楚它到底要拿走什么、碰什么、改什么。
参考来源
本文内容参考了 OpenClaw 官方关于 Skill 安全的讨论和提案，包括：
- OpenClaw RFC: Skill Security Framework — 关于权限清单、签名和沙箱的安全框架提案
- provenance tracking + permission manifests issue — 讨论了
SKILL.md注入、权限诱导等具体风险 - Skill Vetter — 安装前安全审查工具示例
- pre-install / post-install hook 安全检查建议 — 关于安装流程安全化的社区讨论
- ClawHub / 第三方 OAuth 代理风险 issue — 代理服务凭证安全风险
- Workspace /
SOUL.md/HEARTBEAT.md篡改相关 issue — 长期配置篡改风险 - 默认安全姿态讨论 — 关于沙箱、低权限、隔离的最佳实践建议
以上内容来源于 OpenClaw 官方仓库、RFC 文档及社区安全讨论。