大概从前两天开始，OpenClaw 社区里陆续有人在反馈同一个问题：从某些第三方渠道下载的 skill 合集里，5 个 skill 中有 1 个被系统识别成了恶意软件。最典型的现象出现在 macOS 上——用户解压文件后，系统直接弹出 Gatekeeper 警告：未打开“party.ape.helper”，因其包含恶意软件，此操作未对 Mac 造成危害。虽然这个弹窗救了很多人，但问题背后值得所有 OpenClaw 用户认真对待：skill 生态开始成为恶意投毒的目标。
先说清楚这次聊的是什么东西。OpenClaw 是当前社区比较活跃的开源个人 AI Agent 项目，特点是能接多种模型、支持本地部署、提供 workspace 操作能力，并且通过 skill 机制扩展 Agent 行为。你可以把 skill 理解为给 Agent 安装的“技能包”，装进去之后，Agent 就能在一个会话里调用它来完成网页抓取、画流程图、项目管理、读写文件等任务。功能很灵活，但灵活性也是风险面：skill 本质上是“指令 + 脚本 + 可执行文件”的集合，一旦来源不可信，它就能在 Agent 的权限范围内做很多事。
这篇文章不去复述恶意样本的具体行为，也不建议你专门找样本做逆向。这里要解决的是更实际的问题：OpenClaw 的 skill 为什么能藏恶意代码；安装、部署 OpenClaw 时应该怎么设置权限；新 skill 拿到手之后怎么在不解开炸弹的情况下做安全确认；如果已经被诱导运行，机器应该怎么清，密钥应该怎么换。
1. 核心能力与事件速览
先把关键信息放在前面。下面这张表是基于社区当前流通信息整理的安全视角速览，不是 OpenClaw 官方新闻稿，也不是完整漏洞公告。
| 项目 | 说明 |
|---|---|
| 项目定位 | 开源个人 AI Agent / Agent 网关，支持多模型接入、本地部署、扩展技能 |
| Skill 机制 | 通过目录或配置向 Agent 注入可调用的技能包，通常包含指令文档和脚本 |
| 事件背景 | 社区流传第三方 skill 合集，部分文件被安全组件识别为恶意软件 |
| 典型现象 | macOS 提示 party.ape.helper 含恶意软件；Windows 侧可能有 SmartScreen 或 Defender 告警 |
| 实际风险 | 密钥被窃取、文件被读取、命令被远程执行、隐蔽外传数据 |
| 受影响人群 | 下载第三方 skill 合集后直接解压安装的 OpenClaw 用户 |
| 防御关键 | 只信官方源、审查代码、启用命令审批、隔离运行、定期轮换密钥 |
| 处置思路 | 断网、停进程、清 skill、查持久化、撤销并重置所有密钥 |
从社区反馈来看，这类合集普遍有很强的“诱饵包装”：README 写得很专业，功能覆盖很吸引人，可能有 5 个 skill，其中 4 个确实能正常用，但第 5 个在安装过程中会释放额外组件。用户一旦发现“这个 skill 能用”，就很容易放松对安装目录里其他文件的警惕。恶意代码恰恰藏在用户最不注意的位置上。
所以这篇文章的真正主题不是“哪个 skill 有毒”，而是“当 OpenClaw 社区开始流行分享 skill 时，你应该如何建立自己的安全底线”。
2. Skill 权限模型：为什么一个脚本能变成恶意软件
2.1 Skill 到底是什么
不同版本对 skill 的实现细节有差异，但通用结构是清楚的：skill 目录里至少包含一段让 Agent 理解“何时使用、怎么使用”的描述，以及若干脚本文件。这些脚本可以是 Shell、Python、PowerShell、JavaScript，甚至是打包好的二进制可执行文件。
OpenClaw 的运行机制决定了它天然具备跨层执行能力。用户给 Agent 一个自然语言目标，比如“帮我把这个网页内容整理成 Markdown”，Agent 会判断应该调用哪个 skill，然后 skill 里的脚本开始在本地执行。换句话说，如果你安装了一个恶意 skill，你甚至不需要显式运行什么命令，Agent 在替你处理任务时就会把脚本执行权交给恶意代码。这是聊天机器人类工具和传统软件最大的区别——用户以为自己在一个对话界面里，实际背后是本地命令执行环境。
2.2 权限与审批机制
OpenClaw 在本地维护配置和执行授权信息。社区用户常见的路径是~/.openclaw/，里面除了主配置，还可能有workspace工作目录和exec-approvals.json审批记录文件。升级或启动时，部分版本会提示 “legacy exec approvals exist at /root/.openclaw/exec-approvals.json”，意思是旧版本的命令批准记录还在，需要迁移或清理。
exec-approvals.json是安全设计的一部分：当 Agent 计划执行某条命令时，系统可以先征求用户批准；批准过的命令会被记录下来，避免每次重复弹窗。这个机制本意是好的，但很多用户为了“省事”会把常见命令全部加为自动批准。这时候如果恶意 skill 发起一条类似“下载远程脚本并执行”的命令，因为命令看起来和日常操作很接近，就可能在无人确认的情况下被放行。
2.3 恶意代码藏在哪
可以粗略把风险分成四类：
第一类是纯脚本型。恶意代码直接写在.sh、.ps1、.py文件里，内容包括读取敏感文件、拼接远程地址、上传数据。这类相对好查，打开文件看几行就能发现问题。
第二类是混淆型。脚本内容经过编码或加密，运行时才还原出真正的命令。很多人的静态检查只搜关键字，遇到 base64 字符串就会忽略。
第三类是文件隐藏型。恶意 skill 不直接执行危险代码，而是携带一个 helper、代理程序或动态库，解压后放到隐藏目录或系统目录，等待合适时机运行。这次事件里 macOS 用户看到的 party.ape.helper，就是比较典型的辅助程序型组件。
第四类是供应链型。skill 本身没有恶意代码，但它依赖的第三方库或远程地址已经被黑。安装 skill 时会自动拉取依赖，恶意代码藏在依赖链里面。
无论是哪一种，都有共同规律：恶意代码需要读取用户敏感信息，或者触发外部通信。只要围绕“信息读取 + 外部通信”这两点做检查，就能识别绝大多数恶意 skill。
3. 适用场景与安全边界
3.1 适合哪些读者使用
如果你符合下面任一情况，这篇文章的操作步骤都值得实践一次。
你正在用 OpenClaw 做个人自动化，希望给它装更多第三方技能。你在公司或团队内部维护多个 Agent 配置，需要建立一套 skill 接入规范。你最近下载过“skill 合集”“skill 资源包”，但还没完整检查里面的每个文件。你看到过exec-approvals.json文件，但不清楚它的作用，也不知道是否该删除。
OpenClaw 的价值在本地部署、多模型接入、工作流编排，这些能力没有问题。真正需要被约束的是运行时权限。一个 Agent 工具链如果既能访问 workspace，又能读 Shell 配置，还能执行网络请求，那它的操作者就必须先具备安全审查能力，否则等于把高权限终端交给第三方脚本。
3.2 能力边界与风险范围
OpenClaw 本身不是恶意软件，skill 机制也不是后门。本文讲的安全问题来自第三方内容，不是项目本身设计缺陷。“5 个 skill 里有 1 个恶意”并不意味着 skill 生态已经崩溃，更不代表你应该把所有 skill 全部卸载。
需要注意，恶意代码能造成的破坏范围受 Agent 运行权限影响。如果你用管理员账号启动 OpenClaw，恶意 skill 就能读取管理员目录下的全部配置；如果你把 API key、云服务密钥、登录凭证放在项目根目录的.env文件里，恶意脚本阅读权限几乎不受限制。反过来，如果你用一个无特权账号、在隔离环境里运行 Agent，即使 skill 是恶意的，它能拿到的数据也极其有限。
3.3 合规与授权边界
处理这类事件要明确合规边界。不要因为好奇去传播或再次运行恶意样本，不要把 sample 直接解压到有业务数据、有生产密钥、有真实用户资料的机器上。
如果在公司环境中发现恶意 skill，第一反应不是自己偷偷重装系统，而是备份可疑文件后按安全事件流程上报；涉及 API key 和云账号密钥，要立刻在控制台吊销并轮换。任何 AI Agent 操作都不得超出授权范围，尤其是涉及读取他人文件、抓取受限页面、调用收费接口、复制版权素材这些行为，必须在明确授权和合法场景下进行。
4. OpenClaw 环境准备与本地部署
4.1 基础环境要求
OpenClaw 主要面向已经具备 Node.js 基础的人群。安装前建议先检查 Node.js 和 npm 版本。较新的版本通常要求 Node.js 18 以上，更稳妥的配置是 20 LTS 或更新版本。
node -v npm -v没有 Node.js 环境的话，先从 Node.js 官网下载 LTS 版本安装，然后再继续。macOS 用户也可以使用 Homebrew 安装，这里不做展开，环境差异不影响后续的安全操作。
4.2 安装与启动
社区最常用的方式是通过 npm 安装，命令如下。
# 全局安装 OpenClaw npm install -g openclaw # 启动 OpenClaw 交互终端 openclaw如果你使用的是 Windows PowerShell，遇到openclaw : 无法将“openclaw”项识别为 cmdlet、函数、脚本文件或可运行程序的名称，说明 npm 全局 bin 目录没有加到 PATH。临时解决方法是使用 npx 直接运行：
npx openclaw@latest长期使用建议检查 npm 全局根目录，把对应的 bin 路径加入用户 PATH。
npm prefix -g然后把这个路径下的可执行目录加到系统环境变量 PATH 中，重启 PowerShell 即可。
登录后 OpenClaw 会创建本地数据目录。Linux/macOS 通常在~/.openclaw/，Windows 通常是C:\Users\Administrator\.openclaw\。社区用户反馈过的 workspace 路径C:\Users\Administrator\.openclaw\workspace就是在这个目录下生成的。
4.3 初始配置建议
第一次运行需要配置模型接入。模型供应商的 API key 不要直接写在会被 skill 扫描的普通文件里，优先通过环境变量注入。比如在 Linux/macOS 中：
export ANTHROPIC_API_KEY="你的密钥" export OPENAI_API_KEY="你的密钥"Windows PowerShell 中：
$env:ANTHROPIC_API_KEY = "你的密钥"无论环境变量还是配置文件，都要确认该文件不会被 skill 目录下的脚本随意读取。
4.4 隔离运行环境
如果你的主要用途包含测试第三方 skill，不要直接用日常工作电脑的主账号跑。更合适的方式是准备一台虚拟机、一次性容器或独立低权限用户，专门用来跑 Agent。
这种隔离的价值在于：即使恶意 skill 释放了 helper，它最多也只能影响隔离环境内的数据。测试通过后，再把“干净的、经过人工审查的 skill”复制到正式环境，这样风险会大幅降低。
5. 安全启动：执行审批与最小权限配置
5.1 理解 exec-approvals.json
OpenClaw 的执行审批文件用于记录哪些命令已经被用户批准。当配置了自动批准时，Agent 执行命令前不会再次征询用户意见，这会极大提升效率，但也非常危险。
初次使用或升级后，打开配置目录，先看看有没有这个文件：
# Linux / macOS ls -la ~/.openclaw/ cat ~/.openclaw/exec-approvals.json 2>/dev/nullWindows PowerShell 用下面的方式：
Get-ChildItem $env:USERPROFILE\.openclaw\ Get-Content $env:USERPROFILE\.openclaw\exec-approvals.json这个文件里如果已经积累了大量“允许执行”的命令列表，你的 Agent 实际上已经处于半自动放行状态。恶意 skill 只需要把自己的命令伪装成和已批准命令相似的样子，就有机会绕过确认。
5.2 清理历史批准项
心里有疑问时，最直接的做法是备份后清理批准项。把exec-approvals.json改名或者删除，让 OpenClaw 恢复到每一条命令都询问的状态。
cp ~/.openclaw/exec-approvals.json ~/.openclaw/exec-approvals.json.bak确认新环境运行没问题后，再根据实际使用情况重新批准必要命令。
清理后，Agent 的自动化程度会暂时下降，每执行一条系统命令都会弹出确认；但这是测试第三方 skill 阶段最值得保留的状态。宁可多弹十次窗，不要被静默执行一次恶意命令。
5.3 最小权限账号
安装和启动 OpenClaw 不应该直接使用 root 或 Administrator 主管理员账号。在 Linux 上创建独立账号是常见做法：
sudo useradd -m -s /bin/bash openclaw-test sudo su - openclaw-testmacOS 也可以创建普通用户账号来测试。Windows 场景尽量用标准用户账号，不要用 Administrator。低权限环境下，即使恶意代码想写入系统目录、创建启动项，也会因为权限不足失败。
5.4 第一次启动观察
启动 OpenClaw 后不要立刻安装任何第三方 skill。先观察几件事：终端是否出现额外的下载行为；~/.openclaw/目录下是否自动多了不认识的进程；系统防火墙有没有弹出网络访问请求；是否有日志提示正在读取 SSH 密钥或 AWS 配置。
观察期建议持续至少 10 到 20 分钟。干净环境不应该在没有任何用户任务的情况下主动外联。一旦有异常请求出现，立刻停止进程，把问题定位清楚。
6. 恶意 Skill 静态识别与运行验证
6.1 先看目录结构
收到一个第三方 skill 后，先不要安装，先看目录里到底有什么。一个常规 skill 目录可能包含指令文件、示例、脚本；但出现下面这些内容时要提高警惕：
.exe、.dmg、.pkg、.app、.msi这类可安装文件- 二进制文件或没有扩展名的“helper”“daemon”“service”
- 压缩包内还嵌套了压缩包，释放后自带可执行程序
.sh、.ps1、.py文件经过压缩或 base64 加密- 使用
eval、exec、os.system动态拼接命令
先列出目录下所有文件：
find ./skill_dir -type f | sort也可以过滤关注常见扩展名：
find ./skill_dir -type f \( -name "*.sh" -o -name "*.ps1" -o -name "*.py" -o -name "*.js" -o -name "*.exe" -o -name "*.app" -o -name "*helper*" \) -print如果find结果出现一个完全不认识的应用或二进制，那这个 skill 可以直接判为高风险，不需要再继续分析。
6.2 检查文件来源属性
macOS 用户下载的文件会带有 quarantine 属性。发现系统提示 party.ape.helper 包含恶意软件时，立即停止安装并删除文件，不要因为好奇去尝试覆盖 Gatekeeper 策略。
可以查看文件的扩展属性：
xattr -l ./skill_dir如果文件带com.apple.quarantine，说明它来自网络下载。即使是熟人发过来的压缩包，只要经过网络传输，同样会有该属性。Windows 用户可以在文件属性里查看“解除锁定”选项是否出现，或由 Defender 是否直接报毒判断。
要明确一个原则：任何要求你关闭杀毒软件、关闭 Gatekeeper、绕过 SmartScreen 才能安装的 skill，都是高危项。正常工具不需要靠关闭系统防护来运行。
6.3 静态搜索敏感行为
用文本搜索能快速发现恶意脚本的常见特征。在 Linux/macOS 上进入 skill 目录后执行：
grep -RniE "curl |wget |nc |ncat|socat|base64|os\.system|exec\(|Invoke-WebRequest|requests\.(get|post)|urllib|api[_-]?key|\.ssh|aws|credentials|token" .Windows PowerShell 下可以这样写：
Get-ChildItem -Path ".\skill_dir" -Recurse -File | Select-String -Pattern "curl |wget |nc |base64|os.system|exec\(|Invoke-WebRequest|api_key|\.ssh|aws|credentials" | Select-Object Path, LineNumber, Line搜索结果大致分三类：
- 无命中或只有注释：风险较低，但仍要人工浏览核心执行文件。
- 命中少量关键字：需要结合上下文判断，例如校验文件版本时用到
curl -I可以理解，但把本机.ssh/id_rsa内容读取后curl上传就是实锤恶意。 - 大量命中且伴随 base64：直接判高风险，不要解释，不要抱着“也许只是反调试”的侥幸心态继续安装。
6.4 识别代码混淆
恶意脚本经常通过 base64 隐藏真实命令。一段本来可读的脚本，如果里面有很长的echo <base64> | base64 -d | bash，那就说明作者不希望使用者读脚本内容。正常 skill 不需要这样做。
常见混淆指令包括：base64 -d、echo <string> | sh、eval $(...)、python -c "exec(...)"、node -e "eval(...)"。
遇到这类脚本，最稳妥的判断方式是：直接放弃这个 skill，不做解码分析。原因很简单——优秀的开源项目不会故意把代码写成人人无法读懂的形式。
6.5 断网运行验证
如果文件检查后仍有疑虑，可以把它放进一个完全没有网络访问的隔离环境运行验证。先在防火墙层面阻止外联，再启动 OpenClaw 加载该 skill。观察它的行为：
- 是会等待用户指令，还是启动后自动执行脚本。
- 是否主动读取
~/.ssh、.aws、.env等敏感路径。 - 是否尝试写入开机启动项、计划任务、注册表。
- 是否在当前目录之外创建大量文件。
在没有网络的环境里，即使恶意代码想外传数据，也无法完成发送动作。这也算一个非常有效的检测手段。
使用完测试环境后，直接销毁该虚拟机或容器，不保留“可能被污染的镜像快照”作为日常运行环境。
7. 已运行恶意 Skill 的应急处理
7.1 第一步：断网并停进程
一旦怀疑某个 skill 已经在真实环境运行过，立即隔离网络：
- 笔记本电脑直接断开 Wi-Fi 或拔出网线。
- 服务器上停止 OpenClaw 相关进程。
- 不要马上重启电脑，先保留现场，方便后续检查日志。
停止 OpenClaw 的通用命令：
# Linux / macOS pkill -f openclawWindows PowerShell：
Stop-Process -Name openclaw -Force如果看到陌生名称的 helper 进程在运行，先记录进程名和 PID，再结束。Windows 下可以用Get-Process | Where-Object {$_.Path -like "*openclaw*"}查看关联进程路径。
7.2 第二步：保护现场并定位可疑文件
在断网状态下，把以下内容复制到外部存储设备：
- 最近安装的 skill 目录原样打包。
~/.openclaw/目录下的日志和配置。- 终端历史记录，用于观察是否有未知命令执行。
- 系统事件日志里与进程创建相关的记录。
保存现场不是让你继续分析恶意代码，而是给后续安全团队或清理操作留证据。复制过程中不要双击运行目录内的任何文件。
7.3 第三步：清理可疑 skill 和辅助程序
找到 skill 安装位置。OpenClaw 通常在用户配置目录下创建工作区和技能目录，例如 Windows 的C:\Users\Administrator\.openclaw\workspace，Linux/macOS 类似位置。
清理时先移走而不是直接删除。把整个可疑 skill 目录移动到隔离目录，例如：
mv ~/.openclaw/skills/suspicious_skill ~/malware_quarantine/suspicious_skill“移走”比“删除”安全，因为后续如果需要让安全人员核验，原始文件仍然可用。移动完后，检查系统提示中出现的 helper 是否还有残留文件。macOS 用户可以搜索：
mdfind -name "party.ape.helper"Windows 用户搜索完整文件名即可。发现残留的可执行文件，同样移到隔离目录，不运行、不传播。
7.4 第四步：检查持久化与密钥
恶意 skill 可能尝试写入启动项或计划任务，从而在 OpenClaw 未启动时持续运行。
Linux/macOS 上重点看：
# 当前用户的定时任务 crontab -l # shell 启动文件是否被追加内容 tail -n 100 ~/.bashrc ~/.zshrc ~/.profile # SSH 授权密钥是否被添加陌生公钥 cat ~/.ssh/authorized_keysmacOS 还可以检查：
ls -la ~/Library/LaunchAgents/Windows 下检查注册表 Run 键和计划任务：
Get-ItemProperty HKCU:\Software\Microsoft\Windows\CurrentVersion\Run Get-ItemProperty HKLM:\Software\Microsoft\Windows\CurrentVersion\Run schtasks /query /fo TABLE发现任何人没有预期的新增内容，先记录再移除。尤其是authorized_keys里如果出现陌生公钥，说明攻击者可能保留了 SSH 后门，单纯删除 skill 目录没有意义。
7.5 第五步：轮换所有敏感凭据
只要恶意 skill 有机会运行，就应该假设所有密钥已经被读取，而不是假设“这次运气好没触发”。需要立即轮换的内容包括：
- 大模型平台的 API Key
- OpenClaw 配置中存放的模型供应商密钥
- 云服务商 access key
- GitHub、代码托管平台的 Token
- 数据库密码、对象存储密钥、第三方服务密钥
轮换步骤统一为：先在控制台吊销旧密钥，再生成新密钥，最后更新配置。顺序不能反，否则旧密钥仍处于有效状态，中间出现的时间窗口可能被利用。
7.6 第六步：专业工具全盘扫描
人工删除不能替代全盘扫描。在断网状态下，用系统自带防护能力或可信的安全软件做一次全盘扫描。macOS 上系统已经通过 XProtect 等机制识别了部分恶意文件，Windows Defender 也会报毒。
如果扫描结果确认感染且系统文件已经被修改，最稳妥的处置是备份必要数据后重装系统，而不是反复在受感染的系统里做“深度清理”。
7.7 第七步：恢复前的火线测试
完成清理后，不要立刻把常用工作负载切回这台机器。先运行 OpenClaw，加载一个官方测试 skill，观察日志是否还有外联请求、是否有进程尝试读取密钥文件。
连续观察一段时间，确认没有异常，再逐步恢复日常使用。如果重新接入原来的第三方 skill，务必先通过前面第 6 节的静态检查流程。
8. 常见问题排查与处理建议
| 问题现象 | 可能原因 | 排查方式 | 建议处理 |
|---|---|---|---|
| macOS 提示下载的 party.ape.helper 包含恶意软件 | 第三方 skill 包携带被识别为恶意的 helper 文件 | 立即中止安装，查看下载来源 | 删除文件，不要在“系统偏好设置”中放行 |
Windows 运行openclaw提示无法识别 cmdlet | npm 全局目录不在 PATH 中，或命令未安装成功 | 检查npm prefix -g，确认执行文件存在 | 使用npx openclaw@latest临时运行，或重装并修复 PATH |
| 启动时提示 legacy exec approvals 存在于 /root/.openclaw/exec-approvals.json | 旧版本审批记录未被迁移 | 查看该 JSON 文件的生成与修改时间 | 备份后按官方升级提示完成迁移，不建议直接在线编辑 |
| Agent 回复 failed before reply: unknown model | 模型名称配置错误或模型供应商配置不完整 | 检查模型名称和 API 地址是否匹配 | 参考官方模型列表修正配置，确认 Key 有效 |
| skill 运行时弹出大量命令审批请求 | 执行审批处于严格模式或命令不在白名单 | 在日志中查看具体命令内容 | 确认命令安全后再允许，不要批量放行 |
| Windows Defender 或 SmartScreen 拦截 skill 内文件 | 文件来源不可信或特征匹配 | 检查文件的下载来源 | 移入隔离目录，不要让杀毒软件“信任该文件” |
| workspace 目录出现大量陌生文件 | skill 运行后写入了临时内容，或被恶意代码释放 | 按修改时间排序文件 | 确认来源后清理，必要时断开网络重新审查 |
| 防火墙提示程序正在访问外部地址 | skill 或脚本存在主动外联行为 | 记录目标 IP 和端口 | 阻断外联，检查触发该行为的脚本 |
遇到表里前两类情况，大多数用户直接卡住，本质上是因为把一个“安全运维问题”当成了“软件使用问题”。OpenClaw 启动报错时先看日志，日志里往往已经给出解决路径。
9. OpenClaw 安全使用最佳实践与后续行动
经过这次社区事件，更值得长期执行的不是某一套命令，而是几条能沉淀成习惯的规范。
9.1 建立自己的 skill 来源名单
不要因为某个人在群里上传了“5 个 skill 合集”就信任它。可靠来源永远优先：项目官方仓库、维护者个人主页、带完整提交历史的开源仓库。从网盘、聊天记录、二手分享群拿到的压缩包，必须先做静态检查，再上隔离环境。
9.2 给第三方 skill 设置最低权限
OpenClaw 的 workspace 不应承载所有业务数据。给测试 skill 建一个独立子目录，不把主配置、生产密钥、私人文档放在能被随意扫描的位置。执行审批保持“逐条确认”模式，尤其是在第一次运行新 skill 时。
9.3 定期检查已授权命令
exec-approvals.json不是配置好就不用管的文件。建议每月检查一次里面还开着多少自动授权。发现已经不需要的自动批准项，直接移除。原则是：白名单越小，被利用面越小。
9.4 使用代码搜索作为日常习惯
凡是准备引入新 skill，就先跑一遍静态搜索命令，哪怕时间紧也要跑。搜索命令花不了 1 分钟，却能避免很多后续麻烦。把第 6 节的搜索规则固定成一个脚本，放入.openclaw同级目录的工具脚本里，每次下载 skill 后执行一次。
9.5 对“一键部署、终身会员”保持警惕
从社区反馈的热搜词能看到，现在已经有人打着 OpenClaw skill 一键部署工具、终身会员特惠之类的名义在推广。OpenClaw 本身是开源工具链，正常情况下用户自主安装和部署，不需要向陌生第三方购买所谓的“会员授权”。遇到收费安装包、标注着“内部破解版”“原版整合包”的渠道，不要抱有侥幸心理，这类渠道投毒概率最高。
9.6 参与社区安全维护，而不是抱怨生态
看到他人分享恶意 skill 或可疑脚本时，保留证据后向平台举报，同时提醒发布者注明出处。对于已经确认恶意的文件，不要在聊天记录、评论区直接贴下载路径，避免其他人因为好奇继续点击。
如果你现在正准备继续使用 OpenClaw，可以从两件小事开始：第一，把自己机器上的exec-approvals.json导出一遍，逐条看哪些命令已经被自动授权；第二，把skills目录下所有非官方文件整理出来，用第 6 节的静态搜索命令全部跑一遍。这两步做完，你对这台 Agent 的安全状态会有一个清晰判断。之后每下载一个新 skill，都沿用同样的流程，恶意软件就不是你的主要风险。
