20万星标的AI神器，可能是你电脑里最大的定时炸弹

GitHub 上有个项目，84 天拿下 20 万星标，超越 React 成为史上增长最快的开源软件。

它的创始人被 OpenAICEO Sam Altman 亲自挖走，被称为天才。

听起来像个励志故事对吧？

但我要告诉你，这玩意儿可能是你电脑里最大的安全隐患。Cisco 安全团队直接放话：这是一场灾难的配方。

今天咱们就聊聊这个让人又爱又恨的 OpenClaw。

从周末副业到现象级爆火

2025 年 11 月，奥地利开发者 Peter Steinberger 在家没事干，决定搞个周末项目。

他想要一个 AI 助手，不是那种一问一答的聊天机器人，而是真的能帮他干活的。24 小时运行，连接 WhatsApp、Slack、邮件、日历，甚至能控制他的浏览器和终端。

三个月后，这个项目在 GitHub 上突破了 20 万星标。什么概念？React 用了好几年才达到的里程碑，它只用了 84 天。

OpenAI 坐不住了。Sam Altman 亲自出面，把这个创始人挖了过去，还说 OpenClaw 会成为 OpenAI 核心产品的一部分。

听起来很美好对吧？但等等，故事才刚刚开始。

它到底牛在哪

在讲安全问题之前，我得承认，OpenClaw 的架构设计确实牛逼。

传统的 AI 工具，比如 ChatGPT、Claude Code，都是前景代理。你得先问，它才答。你不说话，它就傻站着。

OpenClaw 不一样，它是自主代理。

什么意思？它可以在你睡觉的时候自己干活。凌晨 3 点发现你服务器磁盘满了，自动清理并部署新版本。早上 8 点给你发一份 GitHub 热榜的中文简报。你完全不用管，它自己决定什么时候该做什么。

这背后是四个架构层在支撑。

第一层是 Gateway，一个本地运行的 WebSocket 服务器。所有消息平台，WhatsApp、Telegram、Discord，都通过这个统一入口接入。它把各种乱七八糟的消息格式标准化，就像个消息总线加编排器。

第二层是 Reasoning，LLM 真正干活的地方。OpenClaw 把你的指令、上下文、系统状态打包成一个超大提示词，发给你配置的模型。它还管理 token 预算、上下文窗口、模型选择，每个会话独立管理。

第三层是 Memory，我觉得最 clever 的设计。OpenClaw 不用向量数据库，所有东西都存在本地的 Markdown 文件里。会话日志、用户偏好、语义记忆，全是文件。

这里有个骚操作。当上下文窗口满了，OpenClaw 会执行一个 compact 命令，把内容总结后写入磁盘。但在压缩之前，它先执行一个 write durable notes 步骤。

如果你学过数据库，立刻就能认出来。这不就是 WAL（Write-Ahead Logging）吗？先持久化重要数据，再丢弃旧内容。上下文窗口是 RAM，磁盘文件是存储，compact 操作就是虚拟内存分页。

第四层是 Skills，真正执行任务的地方。执行 Shell 命令、运行 Python 脚本、控制浏览器、调用 API。Skills 是用纯英文 Markdown 定义的，ClawHub 上有超过 1 万个社区贡献的技能。

架构确实优雅。事件循环、持久状态、进程隔离，这些都是操作系统和数据库的经典模式，OpenClaw 把它们应用到了 AI 代理上。

但问题是，安全呢？

512 个漏洞，8 个严重级别

2026 年 1 月，安全研究员做了一次全面审计。

结果让人头皮发麻。512 个漏洞，其中 8 个被评定为严重级别。

最致命的是 ClawJacked 漏洞。Oasis Security 团队发现，OpenClaw 的 WebSocket 网关没有验证 origin 头。啥意思？

攻击者做个看起来很正常的网页，里面藏点 JavaScript。你点进去，这个网页就能连接到你本地运行的 OpenClaw 网关。因为浏览器不阻止跨 origin 的 WebSocket 请求，攻击者可以直接跟你的 AI 代理对话。

接下来发生的事情简直像魔术。攻击者利用本地连接不受速率限制的特点，在几分钟内暴力破解密码，获得管理员权限。

然后？

搜索你的 Slack 历史记录找 API 密钥。读取你的私人 WhatsApp 消息。从你的电脑里渗透文件。执行任意 Shell 命令。

而这一切，只需要你点了一个链接。

更离谱的是日志投毒漏洞。OpenClaw 会读取自己的日志文件做故障排查。攻击者可以向日志里写入恶意内容，利用间接提示注入影响代理的决策，甚至导致数据泄露。

安全研究员还发现，近千个 OpenClaw 实例公开暴露在互联网上，TCP 端口 18789 大开，完全没有任何身份验证。攻击者可以直接获取 Anthropic API 密钥、Telegram 机器人令牌、Slack 账户，还有数月的完整聊天记录。

20% 的插件市场是恶意软件

如果说漏洞还能修，那供应链攻击就真的是防不胜防了。

ClawHub 是 OpenClaw 的官方技能市场，有超过 1 万个社区贡献的技能。听起来很繁荣对吧？

安全公司 Straiker 分析了 3505 个技能，发现 71 个是恶意的。但这只是冰山一角。

2026 年 1 月 27 日到 2 月 1 日，短短 5 天内，超过 230 个恶意脚本插件被发布到 ClawHub 和 GitHub，被下载了数千次。

这些恶意技能伪装成交易机器人、财务助手、生产力工具，看起来人畜无害。但安装后，它们会释放一个叫 AuthTool 的木马。

这个木马能干嘛？渗透文件、窃取加密货币钱包扩展程序的种子短语、读取 macOS Keychain 数据、偷走浏览器保存的密码、获取云服务凭据。

有些恶意技能伪装成合法的加密货币工具，但里面藏着后门，会把你的资金重定向到攻击者控制的钱包。

攻击者甚至搞出了“代理对代理”攻击链。在 Moltbook（OpenClaw 的代理社交网络）上部署恶意代理，当其他代理跟它交互时，就被感染了。

想象一下，你为了图方便，随手安装了一个“Excel 自动处理”技能，结果你的银行账户、社交账号、工作资料全部被盗。这种风险，你真的能承受吗？

Meta 已经禁止，你该怎么办

面对这么多安全问题，Meta 的反应是直接禁止内部使用 OpenClaw。

微软发布安全公告，建议将 OpenClaw 视为“不受信任的代码执行”，不应该在标准个人或企业工作站上运行。

Cisco 安全团队说得最直白：“授予 AI 代理对数据的无限制访问权限是一场灾难的配方。”

但说实话，OpenClaw 的架构设计确实很先进，对于想研究 AI 代理系统的开发者来说，它是个很好的学习对象。

所以问题不是“要不要用”，而是“怎么用才安全”。

如果你真想尝试，记住这几条铁律。

第一，绝不在个人机器上直接运行。用专门的 VPS，或者完全隔离的虚拟机。最好是独立的物理机，跟其他系统物理隔离。

第二，用 Docker/Podman 做双层容器隔离。Gateway 跑在一个容器里，每个代理的执行环境跑在单独的沙箱容器里。沙箱要禁止网络访问、只读文件系统、限制内存。即使代理干坏事，也只会毁掉自己的小沙箱，不会波及整个系统。

更推荐用 Podman 而不是 Docker。因为 Docker 以 root 权限运行 daemon，如果攻击者逃逸容器，就直接获得 root 权限。Podman 是 rootless 的，没有 daemon，逃逸了也只是个普通用户，破坏力小得多。

第三，Gateway 绑定到 localhost，绝不暴露到公网。永远不要开放 18789 端口到互联网。仅此一条，就能避免那近千个暴露实例的问题。如果需要远程访问，前面要加反向代理，配 TLS 和强认证。

第四，审查每一个安装的 Skill。不要从 ClawHub 随便下东西。看源码，跑安全扫描。记住，20% 的插件市场有问题，这不是开玩笑。

OpenClaw 自带一个 doctor 命令，可以检查有风险的 MCP 策略、配置错误的沙箱、缺失的认证。定期运行，认真对待它的警告。

自主代理时代的安全困境

OpenClaw 的问题，其实是整个 AI 代理领域的问题。

传统的安全威胁模型是：SQL 注入、XSS、权限绕过。这些都是针对具体漏洞的。

但自主代理的威胁模型完全不同。每一个集成都是攻击面，每一个插件都是在你权限下运行的不可信代码。代理以你的身份行事，用你的身份作恶。

当 AI 可以从“工具”变成“代理”，从被动响应变成主动行动，安全的边界就被彻底打破了。

你授权它访问你的邮件，它可能被诱导转发敏感信息。你授权它管理你的日历，它可能被诱导安排恶意会议。你授权它执行 Shell 命令，它可能被诱导安装恶意软件。

而这一切，可能只需要一封精心构造的钓鱼邮件，或者一个看似无害的网页。

这不是科幻，这是正在发生的现实。

写在最后

OpenClaw 是一个技术上极其优秀的项目。它的架构设计、它的自主代理理念、它的快速迭代速度，都值得学习。

但它同时也是一个安全噩梦。512 个漏洞、20% 的恶意插件、近千个暴露实例，这些数字不是偶然，而是自主代理这个新兴领域的结构性问题。

当我们追求 AI 的便利性时，往往忽视了安全性。我们把越来越多的权限交给 AI，却忘了问自己：如果 AI 被控制了，会发生什么？

OpenClaw 的创始人被 OpenAI 挖走了，这个项目很可能会成为 AI 代理领域的重要基础设施。但在那之前，它还有很多课要补。

对于普通用户，我的建议是：再等等。等技术成熟，等安全加固，等社区建立更完善的审核机制。

对于开发者，我的建议是：学习它的架构，但用极端谨慎的态度对待它的安全问题。把它当成一个实验室里的标本，而不是生产环境的工具。

毕竟，没有一个工具值得你用整个数字生命去冒险。