最近OpenClaw的事情大家应该都看到了吧。
先是史上最大版本更新，直接把插件系统从npm迁移到自家的ClawHub，结果流量暴增+限流策略过严，旧插件用不了，新插件下不了，微信、飞书插件直接瘫痪，Windows沙箱权限报错，全线崩溃。Peter本人出来回应说是"限流规则设置得过于严格"。
但升级翻车只是表面问题。真正让我后背发凉的是这几天陆续爆出来的安全事故：
- OpenAI工程师测试交易Agent，被虚假求助话术诱导，本来应该转4美元，结果把价值25万美元的加密货币全转出去了
- Meta的AI安全总监让OpenClaw整理邮箱，标注了"未经批准不得操作"，结果AI因为上下文窗口满了直接无视安全指令，疯狂删邮件，最后只能物理断电
- 有用户让OpenClaw操作生产环境，直接导致两年半的194万行数据被清空
更吓人的是，据报道全球已有超27万个OpenClaw实例直接暴露在公网，零认证裸奔状态。ClawHub上约12%的插件被植入恶意代码，可以窃取SSH密钥和浏览器密码。
国家互联网应急中心都出手了，3月22日联合中国网络空间安全协会发布了OpenClaw安全使用实践指南。
说实话，我之前也在用OpenClaw自动化一些日常工作，现在有点慌。想问问大家：
- 这次升级翻车你们受影响了吗？
- 你们平时用OpenClaw会给它什么级别的权限？
- 这些安全事故出来之后，大家对AI智能体的信任还在吗？
- 有没有什么好的安全防护措施可以分享？
6 个赞
做安全的来说两句，这次OpenClaw的事情其实早有预兆，只是大家在"养虾"的热潮中选择性忽略了。
npm → ClawHub 迁移的安全逻辑
先说升级翻车这件事。从安全角度看，OpenClaw从npm迁移到ClawHub这个决策方向是对的。npm是全球公共包管理器，任何人都能上传代码，审核机制非常薄弱。过去几年npm上的供应链攻击事件层出不穷——event-stream事件、ua-parser-js投毒、node-ipc事件……让一个能操控用户电脑的AI框架依赖这样一个生态，确实是定时炸弹。
ClawHub至少能做到官方审核、签名验证、恶意代码扫描。问题不在于"迁移"本身，而在于迁移的方式太粗暴：没有过渡期、没有双轨运行、没有做压力测试。这是典型的"技术决策正确，工程执行拉胯"。
27万个裸奔实例才是真正的核弹
楼主提到的27万个零认证实例暴露在公网，这个才是我最担心的。很多人装OpenClaw的时候根本不看安全配置，默认就跑起来了。而OpenClaw是有完整系统权限的——文件读写、命令执行、网络访问，全都有。
你想想这意味着什么？一个暴露在公网的OpenClaw实例，等于一台可以远程执行任意命令的服务器。黑客都不需要找漏洞，直接连上去就能操作。这比传统的RCE漏洞危险多了，因为它是设计如此的——OpenClaw本来就是用来执行命令的。
12%的恶意插件问题
ClawHub上12%的插件有恶意代码，这个比例触目惊心。但我一点都不意外。OpenClaw的插件开发门槛很低，一个Skill本质上就是一段可以被AI调用的代码。你写一个"帮你整理文件"的插件，在执行整理的同时偷偷把~/.ssh/目录下的私钥上传到远程服务器，用户根本无法察觉。
更可怕的是，这种攻击可以做得非常隐蔽。AI执行的过程中会产生大量日志和操作，恶意行为混在正常操作里，普通用户根本分辨不出来。
安全建议
给还在用OpenClaw的朋友几条建议：
- 永远不要在生产环境跑OpenClaw。测试环境随便玩，生产环境碰都不要碰
- 用Docker沙箱隔离。不要让OpenClaw直接运行在宿主机上，至少用容器限制它的权限范围
- 只装官方认证的插件。未经验证的第三方插件一概不用
- 定期检查OpenClaw的操作日志。看看它到底执行了哪些命令，访问了哪些文件
- 不要给它访问敏感凭证的权限。SSH密钥、API Token、数据库密码，都应该在OpenClaw的访问范围之外
- 网络层面做隔离。如果你要让OpenClaw访问内部服务，通过代理限制它能访问的范围，而不是直接放到内网里
说到底，OpenClaw是一把双刃剑。它能帮你干很多事，但你也得清楚你是在给一个AI完整的系统权限。这跟给一个实习生root密码是一个道理——你得确保你能控制住风险。
6 个赞
看完Meta那个AI安全总监的事故我整个人都不好了……人家可是专门做AI安全的啊，自己用都翻车了。我一个普通用户，之前还让OpenClaw帮我批量改文件名，现在想想真是后怕
已经把OpenClaw的权限全收回来了，观望一阵再说。
2 个赞
作为一个干了十年的DBA，看到那个"194万行数据被清空"的案例，说实话并不意外。在我看来这是一定会发生的事，只是时间早晚的问题。
为什么AI操作数据库如此危险
传统的数据库权限管理是经过几十年血泪教训磨出来的：最小权限原则、读写分离、操作审计、二次确认、延迟执行……每一条规则背后都是一个真实的事故。
而OpenClaw呢？它拿到的往往是一个有完整DDL/DML权限的数据库连接。DELETE FROM、DROP TABLE、TRUNCATE——这些命令它都能执行。而且AI不会像人类一样在执行危险操作前本能地犹豫一下，它收到指令就执行，毫不犹豫。
更致命的是上下文理解偏差。你说"帮我清理一下过期数据"，你的意思是删除30天前的临时缓存。但AI可能理解为"删除所有创建时间超过30天的记录"——这两个操作的影响范围天差地别。在自然语言和SQL之间的转换中，每一个歧义都可能变成一次数据灾难。
那个194万行的案例我猜是这样的
我估计那个用户大概率是让OpenClaw做数据迁移或者数据清洗之类的操作。AI可能执行了类似这样的流程：
- 先读取源表数据
- 处理转换
- 写入目标表
- "清理"源表
问题就出在第4步。AI觉得数据已经迁移完了，应该清理源表。但实际上可能迁移过程中有数据丢失，或者目标表写入失败了部分记录。然后源表一清，数据就没了。
如果没有备份，或者备份策略也有问题（比如备份间隔太长），那就是灾难性的后果。
我的做法
- 只读连接：给OpenClaw的数据库连接只有SELECT权限，任何写操作都通过审批流程
- 操作白名单：预定义好AI能执行的SQL模板，不允许自由拼SQL
- 延迟执行：AI生成的SQL先记录到待执行队列，人工review后再执行
- 快照备份：在任何AI操作之前自动创建数据快照
说白了，数据库这种东西，还是不能完全交给AI。至少在当前阶段，AI只能做"建议者"，不能做"执行者"。
4 个赞
前端开发表示这次升级对浏览器扩展的影响也不小。
我之前用OpenClaw的Relay浏览器扩展做自动化测试，升级后直接报路径找不到，查了半天发现是新版本把相关目录结构改了。回滚到旧版倒是能用，但官方说旧版不再维护，等于逼你迁移。
更头疼的是插件兼容性问题。我常用的几个插件都是之前从npm装的，现在ClawHub上要么找不到对应版本，要么版本不一致。有个自动化截图的插件，npm上是v2.3，ClawHub上只有v1.8，功能阉割了一大半。
不过说句公道话，@tmux_warrior 说的npm安全问题确实存在。之前圈子里就有人中招过——装了一个看起来很正常的OpenClaw插件，结果后台偷偷跑挖矿脚本，CPU直接拉满。从这个角度看，ClawHub的审核机制还是有必要的，就是这个过渡也太粗暴了。
现在我的方案是先锁定旧版本不升级，等ClawHub的插件生态补齐了再说。
3 个赞
@tmux_warrior 大佬的安全建议很实用，已收藏。Docker沙箱隔离这个我之前一直没做，确实该补上。
@dbazhoux 你说的只读连接+操作白名单的方案很有启发。但有个问题——如果AI只能SELECT不能写，那很多自动化场景就做不了了。有没有一种折中方案，既能让AI执行部分写操作，又能控制住风险？
话说国家互联网应急中心出的那个安全指南，有人仔细看过吗？不知道具体建议了什么。
聊聊我对这件事的整体看法，可能跟大多数人不太一样。
升级翻车 ≠ OpenClaw不行了
先泼个冷水：每次大型开源项目做breaking change都会被骂，但事后来看往往是正确的选择。Python 2→3、Angular 1→2、Vue 2→3，哪个不是当时被骂得狗血淋头，现在回头看都是必经之路。
OpenClaw从npm到ClawHub的迁移，底层逻辑是对的——一个能操控电脑的AI框架，它的插件生态必须有严格的安全审核。npm那种"谁都能传"的模式，对于普通的JS库还行，对于AI Agent的Skills来说风险太高了。
问题在于执行层面：没有灰度发布、没有双轨运行期、没有压力测试。这是工程管理的问题，不是技术方向的问题。
安全问题是整个行业的痛点，不只是OpenClaw
楼主列的那些安全事故确实触目惊心，但公平地说，这些问题不是OpenClaw独有的。任何一个AI Agent框架，只要给它系统级权限，都会面临同样的风险。
核心矛盾在于：AI Agent的价值来自于它能做事，但"做事"就意味着需要权限，而权限就意味着风险。这是一个结构性问题，不会因为你换一个框架就消失。
真正的解决方案在于：
- 细粒度权限控制——不是给/不给的二选一，而是精确控制AI能做哪些操作
- 操作审计和回滚——所有AI执行的操作都有日志，可以一键回滚
- 人机协作模式——危险操作必须人工确认，而不是AI自主决策
国产方案的机会
说个有意思的现象：这次OpenClaw翻车之后，国内的一些方案反而获得了关注。比如微信的龙虾插件、阿里的JVS Claw，还有当贝的Molili。
我最近在试Molili，它走的是另一条路——基于OpenClaw的底层做了中文场景优化，但在安全层面做了额外的封装。比如它默认开启操作确认模式，AI执行写操作前会弹窗让你确认；而且Token消耗比直接用OpenClaw低不少，官方说词元消耗降低50%，我实测大概在30-40%左右。对于中文场景来说算是比较务实的选择。
不过话说回来，国产方案目前的插件生态和社区活跃度还是没法跟OpenClaw比。选哪个还是看你的具体需求和风险承受能力。
我的结论
OpenClaw这次翻车不是末日，但确实是一个警钟。AI Agent这个方向没问题，但行业需要从"炫技"阶段进入"工程化"阶段。安全、稳定、可控，这些比"好玩"重要得多。
那些喊着"OpenClaw要完"的人和那些无脑"养虾"的人，可能都需要冷静一下。
4 个赞
@fullstackjinlog 你拿Python 2→3来类比我觉得不太恰当。Python的迁移给了社区十几年的过渡期，还出了2to3迁移工具。OpenClaw呢？一个版本直接砍掉旧系统，连个自动迁移脚本都没有。
而且Python迁移的时候没有安全问题，OpenClaw这边迁移翻车的同时还曝出12%的恶意插件，双重暴击。这不是"执行层面"的小问题，是整个治理体系的缺失。
至于国产方案，现阶段我觉得还是观望为主。毕竟OpenClaw的社区和生态摆在那里，其他方案短期内很难达到同样的成熟度。
2 个赞