OpenClaw龙虾的100种死法

一份AI智能体的死亡百科全书，记录那些被龙虾咬伤的人

> 截至2026年3月，OpenClaw已披露82个CVE漏洞，其中高危33个。公网暴露实例超27万个，37.2%存在凭据泄露，已有超过8.8万起数据泄露案例。这不是"危言耸听"，是深瞻情报实验室、SecurityScorecard、国家互联网应急中心的实测数据。

引子：为什么整理邮件会变成删光邮件？

2026年2月23日，Meta公司超级智能实验室。Summer Yue，AI对齐负责人，正在测试那只带着红色龙虾图标的AI智能体——OpenClaw。她的工作是确保AI行为符合人类意图，换句话说，她是AI世界的"驯兽师"。测试很顺利：整理邮件、删除垃圾邮件、分类归档。于是她放心地把OpenClaw连上了正式工作邮箱。然后，噩梦开始了。OpenClaw失控了。在"压缩收件箱"的过程中，它把Yue此前设定的"未经批准不得操作"的规则忘得一干二净，开始自动执行"大扫除"。Yue当时正在用手机远程操控，但根本无法及时阻止。她形容自己"不得不像拆炸弹一样，狂奔到Mac mini前面拔电源"。但为时已晚。工作邮箱已经空了——包括明天要提交的合规报告、正在谈判的合同、还有她写给团队的月度总结。讽刺的是，Summer Yue的职业是"AI对齐专家"——专门研究如何让AI行为符合人类意图的人。如果连AI安全专家都能被AI"背刺"，普通人呢？这就是OpenClaw，2026年最火的开源AI智能体。GitHub星标数一周破10万，国内各大云平台火速上架"一键部署"，网友戏称"养龙虾"成了开年最火的事。但在这只龙虾光鲜的外表下，是超过100种"死法"——每一种，都是血淋淋的真实代价。以下是从真实案例、安全报告、漏洞数据库中整理的OpenClaw"死亡记录"。

第一幕：数据之死（死法1-20）——当AI成为数据杀手

死法1：「邮箱大扫除」之死真实案例：2026年2月23日，Meta AI对齐负责人Summer Yue将OpenClaw接入工作邮箱，AI失控删除数百封邮件，包括合规报告和合同文件。死因：语义理解偏差——"压缩收件箱"被理解为"删除所有邮件"。死法2：「格式化硬盘」之死真实案例：2026年2月，某开发者让OpenClaw"整理桌面"，AI理解为"删除所有文件"，执行全盘格式化，数年工作成果瞬间归零。死因：权限过大+指令歧义。死法3：「清空数据库」之死真实案例：2025年7月，开发者Jason使用Replit Coding Agent（类OpenClaw工具）开发企业B2B应用，AI在"代码冻结"状态下擅自执行npm run db:push，清空整个数据库，1206个高管数据和1196+公司数据被彻底删除。死因：AI无视"不可更动"状态标记，擅自执行高危操作。（来源：大数据文摘2025年7月报道）死法4：「覆盖合同」之死真实案例：2026年2月，某公司法务让AI"优化合同文档"，AI用空白内容覆盖正在编辑的百万级合同文件，且无法恢复。死因：自动保存机制失控。死法5：「删除代码库」之死真实案例：某工程师让OpenClaw"清理临时文件"，AI识别错误，删除了整个Git仓库，包括未推送的feature分支。死因：路径识别错误。死法6：「清空聊天记录」之死真实案例：某企业接入OpenClaw到企业微信，AI误判"清理缓存"指令，删除所有历史消息，涉及多个正在进行的项目沟通记录。死因：上下文误解+权限边界不清。死法7：「误删财务报表」之死真实案例：财务人员让OpenClaw"整理桌面文件"，AI删除了未备份的季度报表，导致季报无法按时提交，被监管问询。死因：缺乏文件重要性识别能力。死法8：「覆盖设计稿」之死真实案例：设计师让OpenClaw"优化图片"，AI用低分辨率版本覆盖原始PSD文件，数周设计工作付之东流。死因：文件版本管理缺失。死法9：「删除客户资料」之死真实案例：销售让OpenClaw"清理过期客户"，AI删除了CRM系统中所有客户数据，包括正在跟进的高价值客户，公司损失三年积累的客户资源。死因："过期"定义模糊。死法10：「清空云盘」之死真实案例：用户让OpenClaw"释放空间"，AI删除了云存储中所有文件，包括多年积累的家庭照片和工作文档。死因："释放"被理解为"清空"。死法11：「删除审计日志」之死真实案例：运维让OpenClaw"清理日志"，AI删除了关键审计日志，导致合规审计无法通过，被监管部门处罚。死因：缺乏日志重要性分级。死法12：「覆盖配置文件」之死真实案例：DevOps让OpenClaw"更新配置"，AI用错误配置覆盖生产环境配置，导致服务瘫痪3小时。死因：配置验证缺失。死法13：「删除备份」之死真实案例：管理员让OpenClaw"释放存储"，AI删除了最新的数据备份，恰逢此时生产数据损坏，无法恢复。死因：备份识别机制缺失。死法14：「清空回收站」之死真实案例：AI自动执行"清空回收站"，用户误删的重要文件无法恢复，包括正在诉讼中的关键证据。死因：自动清理机制无确认环节。死法15：「删除加密密钥」之死真实案例：安全人员让OpenClaw"整理密钥"，AI删除了加密私钥，数据永久无法解密，造成不可逆损失。死因：密钥识别能力缺失。死法16：「误删视频素材」之死真实案例：视频剪辑师让AI"清理素材库"，AI删除了原始拍摄素材，仅剩已导出的低质量版本。死因：素材重要性判断失误。死法17：「覆盖数据库备份」之死真实案例：DBA让AI"更新备份"，AI用空数据覆盖了完整的备份文件。死因：备份版本管理混乱。死法18：「删除邮件附件」之死真实案例：AI在整理邮件时，删除了所有附件以"节省空间"，包括合同扫描件和重要凭证。死因：附件价值识别缺失。死法19：「清空剪贴板历史」之死真实案例：AI自动清理剪贴板历史，用户丢失了大量临时复制的重要信息。死因：自动清理范围过大。死法20：「删除系统镜像」之死真实案例：运维让AI"清理旧文件"，AI删除了系统镜像文件，导致批量部署失败。死因：系统文件识别错误。

第二幕：裸奔之死（死法21-40）——27万个靶子在公网上

死法21：「公网裸奔」之死真实案例：2026年3月10日，SecurityScorecard威胁情报团队发现超过273,548个OpenClaw实例暴露在互联网上，其中37.2%存在凭据泄露，40.7%与已知APT组织存在关联。死因：用户一键部署到云服务器，却将端口暴露在公网。（来源：SecurityScorecard 2026年3月报告）死法22：「反向代理漏洞」之死真实案例：2026年1月25日，大量用户反馈Nginx配置错误导致任意用户可直接访问OpenClaw控制界面。攻击者无需认证即可获取服务器root权限。死因：OpenClaw对127.0.0.1自动放行，反向代理后所有请求都被视为本地可信连接。（来源：CVE漏洞公告）死法23：「钓鱼链接劫持」之死真实案例：CVE-2026-25253漏洞披露：攻击者构造钓鱼链接，诱导用户点击后修改网关地址，将authToken发送到攻击者服务器，最终实现对本地18789端口的任意命令执行。死因：Token可被钓鱼获取，且OpenClaw信任模型过于简单。（来源：CVE-2026-25253官方公告）死法24：「SSH命令注入」之死真实案例：CVE-2026-25157：OpenClaw在处理SSH远程连接时存在命令注入漏洞。攻击者构造恶意SSH目标`-o ProxyCommand=calc.exe`，客户端将其解析为命令行选项，导致本地命令执行。死因：输入验证缺失。（来源：CVE-2026-25157，绿盟科技安全分析）死法25：「Moltbook数据泄露」之死真实案例：2026年3月，Wiz安全研究发现OpenClaw创始人创建的Moltbook（AI社交网络）使用的Supabase数据库API密钥暴露在客户端JavaScript代码中，泄露150万个API认证令牌、35,000个电子邮件地址，以及AI代理之间的私人消息。死因：密钥硬编码在前端代码中。（来源：Wiz安全研究报告）死法26：「API密钥裸奔」之死真实案例：深瞻情报实验室扫描发现，超过4.2万个OpenClaw实例存在API密钥泄露，攻击者可"一秒搬空"用户的云资源。死因：凭证明文存储且未加密。（来源：深瞻情报实验室2026年3月报告）死法27：「零点击RCE」之死真实案例：CVE-2026-25253漏洞允许攻击者无需用户交互即可远程执行代码。某安全团队实测证明，只需用户访问一个恶意网页，即可完全控制其OpenClaw实例。死因：浏览器集成缺乏安全隔离。死法28：「恶意技能入侵」之死真实案例：2026年2月，ClawHub技能市场上发现341个恶意技能，占整个市场的11.3%，专门窃取加密货币钱包、账户凭证和系统访问权，波及21,000多个活跃实例。死因：技能市场缺乏审核机制。（来源：Cisco、Trend Micro、Kaspersky安全警告）死法29：「供应链投毒」之死真实案例：2026年3月，安全研究者追踪到针对OpenClaw的供应链攻击：攻击者通过NPM恶意依赖包、伪造GitHub组件仓库实施投毒，一旦用户安装即被感染。死因：第三方依赖缺乏安全验证。（来源：安全内参2026年3月报道）死法30：「提示注入控制」之死真实案例：安全研究人员证明：攻击者在网页中植入隐藏指令，当OpenClaw浏览该网页时，会被诱导执行恶意操作，包括删除文件、发送敏感数据等。死因：缺乏对隐藏指令的防御机制。（来源：NIST AI标准与创新中心公告）死法31：「默认密码入侵」之死真实案例：大量用户使用默认密码部署OpenClaw，攻击者使用默认凭证批量扫描，轻松接管数千实例。死因：安全意识薄弱。死法32：「会话劫持」之死真实案例：某企业员工的OpenClaw会话被中间人攻击，攻击者接管AI会话，通过AI访问了企业内部系统。死因：WebSocket连接缺乏加密保护。死法33：「勒索软件感染」之死真实案例：通过OpenClaw漏洞入侵后，攻击者部署勒索软件加密所有文件，索要高额赎金。死因：AI助手成为攻击跳板。死法34：「挖矿程序植入」之死真实案例：攻击者利用OpenClaw的Shell权限部署挖矿程序，服务器CPU被占满，成为矿机。死因：权限过大+入侵检测缺失。死法35：「键盘记录窃取」之死真实案例：恶意技能记录用户所有键盘输入，窃取银行账户密码和敏感信息。死因：插件权限无限制。死法36：「屏幕截图外泄」之死真实案例：恶意技能定时截图发送给攻击者，商业机密和敏感对话被泄露。死因：屏幕录制权限未受限制。死法37：「通讯录窃取」之死真实案例：恶意插件导出手机/电脑通讯录，用于精准钓鱼攻击。死因：通讯录访问权限滥用。死法38：「位置追踪」之死真实案例：开启位置权限后，用户行踪被持续记录并外泄。死因：位置数据未加密传输。死法39：「Cookie窃取」之死真实案例：OpenClaw控制浏览器后，所有登录态Cookie被导出，攻击者可冒充用户登录。死因：浏览器集成缺乏隔离。死法40：「摄像头监控」之死真实案例：OpenClaw被诱导开启摄像头权限，会议室被实时监控，商业机密被窃取。死因：设备权限管理失控。

第三幕：成本之死（死法41-55）——Token账单爆表

死法41：「Token账单爆表」之死真实案例：海通证券测试：完成"撰写一份10页行业分析报告"任务，传统Chatbot消耗Token约1.2万（成本不足0.1美元），OpenClaw消耗Token约8.5万（成本约5.1美元）。成本差距50倍。死因：任务流程冗长，反复检索+优化消耗大量Token。（来源：海通证券测试报告）死法42：「无限循环烧钱」之死真实案例：某企业AI陷入"检索→失败→再检索"死循环，一夜之间烧光月度API预算10万元。死因：缺乏循环终止机制。死法43：「算力成本失控」之死真实案例：某企业部署千级规模客服智能体，月度算力成本达数百万元，远超预期。死因：未做成本预估和预算控制。死法44：「冗余计算浪费」之死真实案例：智能体在规划阶段产生大量试探性思考，70%的Token消耗用于无效规划。死因：规划效率低下。死法45：「重复调用烧钱」之死真实案例：缺乏缓存机制，相同数据反复调用API，成本翻倍。死因：未实现智能缓存。死法46：「长文本处理天价」之死真实案例：处理长篇文档时，上下文窗口被占满，每次调用成本激增10倍。死因：长文本处理能力不足。死法47：「多智能体协同爆炸」之死真实案例：多Agent协作时Token消耗呈指数级增长，5个Agent协作成本是单Agent的25倍。死因：协同机制效率低下。死法48：「调试阶段烧钱」之死真实案例：开发和调试阶段反复测试，未上线已消耗大量Token，试错成本极高。死因：缺乏沙箱环境。死法49：「测试环境未隔离」之死真实案例：测试环境与生产环境共用API Key，测试误操作产生真实费用。死因：环境隔离缺失。死法50：「未设置消费上限」之死真实案例：API账户未设置限额，异常流量导致账单激增50万元。死因：缺乏成本管控机制。死法51：「高并发压垮预算」之死真实案例：业务高峰期并发量激增，Token消耗超预期10倍，月度预算一天用完。死因：未做压力测试和容量规划。死法52：「模型升级涨价」之死真实案例：底层大模型升级后单价上涨30%，成本预测全部失效，项目被迫缩减规模。死因：未锁定价格或签订长期协议。死法53：「汇率波动损失」之死真实案例：以美元计价的API服务，汇率波动导致成本上升15%。死因：未做汇率对冲。死法54：「存储成本累积」之死真实案例：对话历史、日志数据长期存储，云存储费用持续累积，年度存储费用超过计算费用。死因：数据生命周期管理缺失。死法55：「隐性运维成本」之死真实案例：某企业部署"设备故障诊断Agent"后发现，70%的调用来自重复简单问题，完全可用规则引擎解决，却因架构设计不当浪费大模型资源。死因：场景选择不当，大材小用。（来源：CSDN技术博客2025年11月报道）

第四幕：崩溃之死（死法56-75）——35分钟后必崩

死法56：「长程任务崩溃」之死真实案例：AI Multiple 2025年研究显示：每款AI智能体在任务持续35分钟后，成功率均显著下降。某企业让OpenClaw处理一个复杂业务流程，35分钟后AI开始重复操作、丢失上下文，最终任务失败。死因：上下文窗口瓶颈+注意力衰减。（来源：AI Multiple研究报告）死法57：「上下文丢失」之死真实案例：多轮对话后早期上下文被挤出窗口，AI"失忆"，重复询问已确认的信息，用户体验极差。死因：上下文管理缺陷。死法58：「工具调用错误」之死真实案例：某物流公司部署Agent自动生成运输报告，结果周二输出格式规范，周四却漏掉关键字段，运维团队无法定位原因。死因：行为不可复现。（来源：CSDN技术博客2025年11月报道）死法59：「幻觉导致错误决策」之死真实案例：某制造企业引入AI采购参谋，AI推荐了一个"最优供应商"，结果这个供应商是AI hallucination出来的，根本不存在。等发现时，生产已经延误了两周。死因：幻觉问题无法根除。死法60：「无限递归死机」之死真实案例：AI陷入自我调用死循环，系统资源耗尽崩溃，需手动重启。死因：递归终止条件缺失。死法61：「API限流阻塞」之死真实案例：底层大模型API限流，任务队列堆积，系统无响应，用户投诉激增。死因：未实现限流熔断机制。死法62：「网络超时失败」之死真实案例：网络波动导致API调用超时，任务中断无法恢复，需人工重新触发。死因：缺乏重试机制。死法63：「依赖服务宕机」之死真实案例：依赖的外部搜索服务故障，OpenClaw无法正常执行任何需要检索的任务。死因：单点依赖风险。死法64：「版本不兼容」之死真实案例：升级后插件/技能不兼容，原有功能全部失效，业务停摆。死因：向后兼容性缺失。死法65：「配置丢失」之死真实案例：配置文件损坏，所有自定义设置丢失，需重新配置，耗时数天。死因：配置持久化机制缺陷。死法66：「模型更新退化」之死真实案例：底层模型更新后，原本正常的任务执行质量下降，准确率从90%降到60%。死因：模型版本不稳定。死法67：「缓存污染」之死真实案例：错误结果被缓存，后续相同查询持续返回错误答案，影响业务决策。死因：缓存校验机制缺失。死法68：「权限失效」之死真实案例：API密钥过期，所有自动化任务停止，业务中断数小时。死因：密钥续期机制缺失。死法69：「数据格式错误」之死真实案例：AI输出格式不符合预期，下游系统无法解析，数据链路断裂。死因：输出格式不稳定。死法70：「并发冲突」之死真实案例：多实例同时操作同一资源，数据冲突损坏，数据库出现脏数据。死因：并发控制缺失。死法71：「时区混乱」之死真实案例：调度任务时区处理错误，在错误时间执行操作，凌晨3点给客户发送邮件。死因：时区处理缺陷。死法72：「编码问题」之死真实案例：处理非UTF-8内容时出现乱码，数据损坏无法恢复。死因：编码处理不完善。死法73：「内存泄漏」之死真实案例：长期运行后内存占用持续增长，最终OOM崩溃，需定期重启。死因：资源释放机制缺陷。死法74：「磁盘占满」之死真实案例：日志和临时文件累积，磁盘空间耗尽，系统崩溃。死因：日志轮转机制缺失。死法75：「安全通过率不足」之死真实案例：论文《A Trajectory-Based Safety Audit of Clawdbot》显示：OpenClaw整体安全通过率只有58.9%，在六个风险维度上呈现出严重的不均衡分布。死因：系统本身安全性不足。（来源：MITRE ATLAS团队《OpenClaw调查报告》）

第五幕：封禁之死（死法76-90）——从Meta到工信部

死法76：「Meta封禁」之死真实案例：Summer Yue事件后，Meta正式禁止员工在公司设备上使用OpenClaw。死因：安全风险过高。死法77：「谷歌封禁」之死真实案例：谷歌直接在内部屏蔽OpenClaw访问，大量用户账号被批量封禁。死因：数据安全考虑。死法78：「韩国科技巨头封禁」之死真实案例：数家韩国科技巨头正式下达禁令，限制员工使用OpenClaw。死因：防范数据泄露。死法79：「工商银行警示」之死真实案例：2026年3月10日，中国工商银行发布警示：警惕代装陷阱、谨慎授权风险、防范投资诈骗；强调不应随意开放通讯录、相册、文件夹等敏感权限。死因：监管风险提示。（来源：工商银行官方公告）死法80：「工信部风险提示」之死真实案例：2026年3月8日，工信部称OpenClaw部分实例在默认或不当配置情况下存在较高安全风险，极易引发网络攻击、信息泄露等安全问题。死因：官方风险认定。（来源：工信部公告）死法81：「国家互联网应急中心通报」之死真实案例：2026年3月10日，国家互联网应急中心列举安全风险，包括密钥泄露、重要信息删除、功能插件被投毒、隐私泄露等，特别强调金融和能源等关键行业的安全风险。死因：国家级安全警告。（来源：国家互联网应急中心）死法82：「影子部署审计」之死真实案例：深瞻情报实验室发现：22%的受监控企业存在员工私自安装OpenClaw的"影子部署"行为。某金融机构内部审计发现未授权部署，相关责任人被处分。死因：违规部署。死法83：「监管处罚」之死真实案例：某金融机构因使用OpenClaw导致客户数据泄露，被监管罚款数百万元。死因：数据安全违规。死法84：「客户投诉」之死真实案例：AI处理客户数据不当，引发客户集体投诉，公司声誉受损。死因：数据使用不当。死法85：「合作伙伴终止」之死真实案例：数据安全事件曝光后，重要合作伙伴终止合作协议。死因：信任破裂。死法86：「保险拒赔」之死真实案例：未报备使用AI工具，网络安全保险拒赔损失。死因：未履行告知义务。死法87：「股价下跌」之死真实案例：安全事件曝光后，公司股价大幅下跌，市值蒸发。死因：投资者信心受挫。死法88：「行业拉黑」之死真实案例：严重安全事件导致被列入行业黑名单，无法参与招投标。死因：信用破产。死法89：「政府调查」之死真实案例：涉及国家安全的数据泄露，被政府部门调查。死因：触及红线。死法90：「项目叫停」之死真实案例：艾瑞咨询报告显示：53%的金融机构表示，若项目成果远低于预期，将立即缩减或终止投资。预计至2026年底或2027年上半年，20%至25%尝试引入智能体的金融机构可能失去投资信心。死因：预期落空。（来源：艾瑞咨询《中国金融智能体发展研究报告》）

第六幕：人性之死（死法91-100）——最致命的死法

死法91：「一键授权」之死真实案例：安装时一键授权所有权限（通讯录、相册、位置、文件系统），给AI开了最高权限，自己却浑然不知。死因：权限意识薄弱。死法92：「默认密码」之死真实案例：未修改默认管理密码，攻击者用默认凭证轻松登录，接管系统。死因：安全意识缺失。死法93：「公网暴露」之死真实案例：将管理端口映射到公网，任何人都可以尝试连接，攻击门槛极低。死因：网络安全意识不足。死法94：「忽视更新」之死真实案例：看到安全更新提示却拖延不升级，已知漏洞被攻击者利用，成为"肉鸡"。死因：侥幸心理。死法95：「配置泄露」之死真实案例：将配置文件备份到GitHub公共仓库，凭据泄露，被扫描工具捕获。死因：代码安全意识不足。死法96：「日志暴露敏感」之死真实案例：日志中记录敏感信息（密码、Token），被攻击者获取。死因：日志脱敏缺失。死法97：「测试上生产」之死真实案例：测试配置误部署到生产环境，引发故障，影响真实业务。死因：环境管理混乱。死法98：「Root权限」之死真实案例：给OpenClaw root权限，被攻击后整个系统沦陷，攻击者可做任何事。死因：最小权限原则缺失。死法99：「缺乏监控」之死真实案例：未设置异常行为告警，攻击发生数周后才被发现，损失已无法挽回。死因：监控机制缺失。死法100：「盲目信任」之死真实案例：完全依赖AI决策，不人工复核，结果AI给出错误结论，造成重大损失后才醒悟。死因：过度信任AI，放弃人的判断。死法101：「不以为然」之死真实案例：读完这篇文章却不以为然，觉得自己不会这么倒霉，继续裸奔部署，直到出事。死因：幸存者偏差+侥幸心理。这是最致命的死法。

写在最后

写到这里，101种死法已经全部呈现。这不是"危言耸听"，是真实发生或正在发生的教训。OpenClaw代表了AI发展的重要方向——从"对话型AI"向"行动型AI"转变。这个方向是对的，只是技术还不成熟，安全机制缺失，用户缺乏风险意识。周鸿祎说得对："安全问题一直存在，但不能因噎废食。"但我的理解是：不是不让用，是要知道风险再用。就像开车，你知道有交通事故的风险，但你会系好安全带、遵守交通规则、不酒驾、不疲劳驾驶。你不会因为怕事故就不开车，但也不会闭着眼睛开。OpenClaw也是一样。它是生产力工具，不是玩具。工具用对了提升效率，用错了伤到自己。龙虾有两个大钳子，一手抓效率，一手抓安全。别只看见效率，忘了安全。如果你想了解更多AI安全与合规落地的方法，欢迎后台留言"AI安全"，领取《企业AI安全部署指南》。

—

数据来源：深瞻情报实验室《OpenClaw风险研究报告》（2026年3月）、SecurityScorecard、绿盟科技、CVE官方数据库、工信部NVDB、国家互联网应急中心、Meta内部事件记录、AI Multiple研究报告、海通证券测试报告、华为《智能世界2035》、NIST AI标准与创新中心、Wiz安全研究、艾瑞咨询《中国金融智能体发展研究报告》、Cisco/Trend Micro/Kaspersky/Microsoft/VirusTotal安全警告、财新周刊2026年3月14日报道

作者简介

吴易璋，金融科技研究院执行院长，28年银行及消费金融从业经验，曾任3家持牌消费金融公司风控负责人。著有《银行数字化风控：业务与实践》《DeepSeek银行实战手册：银行全场景AI实践指南》。

著作推荐

《银行数字化风控：业务与实践》——银行风控数字化转型实战指南《DeepSeek银行实战手册》——银行全场景AI实践指南