OpenClaw"龙虾"升级翻车：这次真的是"虾"折腾了

3月24日，开源AI圈的“顶流网红”OpenClaw（网友昵称“龙虾”）上演了一场大型翻车。

史上最大版本更新上线仅数小时，全球开发者集体“失灵”：控制台无法加载、插件体系全面失效，微信、WhatsApp等关键集成渠道接连“罢工”。这场原本被创始人Peter Steinberger寄予厚望的“安全革命”，最终却因ClawHub流量挤兑，演变为一场大型的工程事故。

更微妙的是，就在两天前，国家互联网应急中心刚刚发布《OpenClaw安全使用指南》。前脚被“重点关注”，后脚系统崩溃，时间点上的反差，让这次升级显得格外尴尬。【想掌握 OpenClaw 实操技巧、搭建 AI Agent 自动化运营飞轮吗？4月15日亚马逊春耕启动大会将于深圳站展开，手把手教你落地跨境电商自动化运营。点此报名】

01、 从“去npm化”到ClawHub拥堵

先看这次升级的核心逻辑。

过去，OpenClaw的插件生态高度依赖npm这一公共包管理体系。优势是开放、高效，但问题同样突出——安全边界极其脆弱。今年2月，就曾曝出数百个恶意插件窃取加密钱包信息的事件。

在这样的背景下，Peter Steinberger选择“动刀”：

放弃npm分发体系，自建官方插件平台ClawHub，并砍掉旧插件架构——所有第三方开发者必须基于新接口重构，插件默认仅允许从ClawHub安装。从安全视角看，这是一次典型的“平台收权”；但从工程实践看，这更像一次高风险的“硬切换”。

问题很快暴露。

全球开发者在同一时间集中迁移、查找依赖、重新部署插件，叠加不明来源的网络攻击，ClawHub流量瞬间打满，限流机制被触发，系统进入“保护性拥堵”。

最终的用户体验是灾难性的：

●  控制台白屏报错“Control UI assets not found” 

●  多模型服务异常，国产MiniMax模型连接失败 

●  WhatsApp、微信插件失效，运营侧直接中断 

●  开发者在GitHub集中吐槽：插件未同步、频繁触发限流、重试无效 

更值得注意的是，这一错误（Control UI assets not found）在今年1月已出现过一次，属于“已知问题复现”。

事后，Peter Steinberger在X上回应称，是防攻击策略过于激进导致限流误伤正常用户，正在紧急调整。

添加企微，加入”养龙虾“交流群

02、安全与体验的失衡

如果把时间线拉长，这次事故其实并非孤立事件。

近期，OpenClaw正面临多重压力：

●  2月，谷歌封禁大量通过OpenClaw接入其AI编程平台的账号，理由是“异常请求流量” 

●  ClawHub此前被质疑存在下载数据造假问题 

●  恶意插件可在虚拟机环境中执行潜在攻击行为 

在这样的背景下，本次升级确实引入了多项安全加固措施，例如：

●  限制Windows环境下的SMB凭据握手 

●  防止本地媒体输入被恶意利用 

●  强化插件来源与执行环境隔离 

问题在于：安全策略的落地节奏，明显快于工程承载能力。

当安全机制直接以“一刀切”的方式替换既有生态，而缺乏灰度过渡与兼容方案时，最终的结果只能是——用户为安全策略“买单”。

封面来源/图虫创意

（来源：雨果跨境编辑部）