Datawhale干货 

作者：筱可，Datawhale成员

最近一段时间，OpenClaw 真的有点太火了。

有人拿它接 Codex 和 Claude Code 做开发编排，有人拿它做本地自动化，还有人把它当成「终于能自己养起来的AI🦞」。大家第一次意识到，原来一个人真的可以把 AI 从「陪你聊天」推进到「帮你做事」，但问题也恰恰出在这里。

很多人一边兴奋地装上它，一边还在用「聊天工具」的心态理解它——觉得它不过是个更能干的对话框，顶多回答出错，不会真的惹出麻烦。

“只要是本地部署，就天然更安全。”

这句话听上去很顺，但放在 OpenClaw 身上，往往会误导人。

如果你最近也在关注 OpenClaw，这篇文章只想帮你搞清 3 件事：

• 为什么关于 OpenClaw的安全提醒突然多了

• 它真正危险的地方到底在哪

• 8个OpenClaw的安全使用技巧

一、最近，关于 OpenClaw 的风险提醒突然变多了

如果你最近刷到很多关于 OpenClaw 风险的提醒，不用急着把它理解成一波情绪化唱衰，背后其实有几类来源在同时发声。

第一类是 OpenClaw 自己的官方安全文档。

官方并没有把它描述成一个"装完就放心用"的工具，反而反复强调：不可信输入要谨慎处理，高风险工具不能默认全开，敏感执行最好放进 sandbox，对真实主机操作要配审批，对 URL、文件拉取和网关访问要做限制。

第二类是安全研究者和大厂安全团队。

像 Simon Willison、1Password、The Verge 这一类来源，关注点很一致：prompt injection、恶意 skills、过高权限、旧版本漏洞、工具链和执行链条带来的连带破坏。

第三类是越来越多的官方提示。

最近不少高校、政府部门、网信系统的正式通知，也开始把OpenClaw作为风险提示对象。

所以，最近风险提醒变多，其实是因为越来越多人终于意识到：

能执行动作的 agent，和只负责回答问题的聊天模型，根本不是一个风险等级。

二、最容易踩中的反而是特别日常的误判

说到安全，很多人第一反应是"这得企业级团队才能处理"。其实不对。对大多数小白和普通人来说，真正最容易踩中的，反而是一些特别日常的误判。

第一个坑，以为本地部署就等于安全。

如果你本地跑着一个能执行命令、能读不可信网页、能调用第三方 skills、能接触真实数据的 agent，这些风险并不会因为它跑在你电脑上就消失。

第二个坑，以为 skill 越多越强。

看到技能市场，大家肯定会想"多装几个，能力不就更完整了吗"。但其实，每多装一个 skill，就可能多引入一层来路不明的代码、不透明的命令、不必要的权限、对本地环境的额外依赖。很多风险出在为了追求自己的🦞更全能，把不受控的扩展一层层挂了进去。

第三个坑，以为能「自动执行」就代表效率更高。

一旦某个能力已经从「帮你分析」变成「替你执行」，就得想清楚：这一步到底该不该自动，失败了谁兜底，有没有审批，有没有日志，有没有范围限制。没有这些闸门的自动化，短期看像提效，长期看就更像在攒事故。

第四个坑，觉得 测试环境 和 生产环境 不分也无所谓。

和AI的对话，大家常常觉得"不就是改一下 prompt、换一个 skill、调一下执行逻辑吗"，但如果再🦞里，这些改动就已经影响到真实渠道、真实数据、真实命令执行。测试环境和生产环境不分开、就意味着协作边界不清晰，本质上就是在拿生产试错。那么要是后面越智能，出错时的破坏面通常也越大。

把前面的信息压缩一下，OpenClaw 最核心的风险集中在：

• 过高权限

• prompt injection

• skill 和插件供应链

• 公网暴露和旧版本漏洞

三、我总结的OpenClaw安全使用技巧

第一，只用官方最新稳定版本。不贪快装来路不明的镜像版本，也不要长期卡在旧版本不动。OpenClaw 这类系统一旦出现漏洞，旧版本的危险性通常比普通桌面工具大得多，因为它背后可能还连着工具执行链、数据链和工作流链。

第二，不直接暴露公网。如果只是个人实验，真的没必要一上来就把实例直接暴露在互联网。必须远程访问时，优先走加密通道再做来源限制，不要把它当普通网站一样裸露出去。

第三，坚持最小权限。不要图省事就给它管理员级权限。能只读就别读写，能隔离就别直连，能拆角色就别全塞给一个 agent。

第四，高风险能力默认收紧。像 exec、browser、web_fetch、web_search 这类能力，不该默认全部敞开。更稳妥的做法是先关掉不需要的，只给可信场景开，对真实主机执行动作加审批或沙箱。

第五，不乱装第三方 skills。如果只能记住一条最接地气的建议，我会选这个。遇到要求你下载压缩包、执行脚本、额外开放权限、手工输入敏感凭证的情况，一律提高警惕。

第六，不要把 secrets 暴露给 agent。不要把 API key、token、SSH 凭证直接写进 prompt、普通 Markdown、随手可读的配置文件里。

第七，开日志，保留审计线索。用AI最气的，就是干坏了之后不知道它到底做了什么，所以！尽量保留关键执行日志、变更记录、skill 安装记录和异常行为线索。

第八，分开 测试环境 和 生产环境。既然都开始接真实邮件、真实消息、真实代码库、真实数据，那就尽量把测试环境和生产环境分开。

写在最后

写到这里，我并不想得出一个「所以别用了」的结论。

OpenClaw 真正有价值的地方，恰恰在于它让更多人在通讯工具上就能使用AI，真正干活。一个人，也许真的可以管理起一支 AI 工具队伍。

但也正因为如此，才更需要换一种管理心态。

• 如果把它当聊天工具，你看到的就只是功能很强；

• 但把它当一个运行系统，你才会真正看见权限要分层、工具要收口、环境要隔离、执行要留闸门、风险要可追溯。

从这个角度看，OpenClaw 的分水岭从来都不是装or没装，而是安全边界有没有立好！

这条边界，短期看会让你慢一点，长期看却决定了你到底能不能把它真正用下去。