OpenClaw 的隐藏危险¶

这是《Everything Claude Code 指南系列》的第 3 部分。 第 1 部分是 快速指南（安装与配置）。第 2 部分是 详细指南（高级模式与工作流）。本指南讨论安全——具体而言，讨论当递归智能体基础设施将安全置于次要地位时会发生什么。

我使用 OpenClaw 一周。以下是我的发现。

[图片：具有多个连接频道的 OpenClaw 仪表盘。每个集成点都标有攻击面标签。] 仪表盘看起来很有冲击力。但每一个连接都是一扇没有上锁的门。

使用 OpenClaw 一周¶

首先我想明确我的立场。我制作 AI 编码工具。我的 everything-claude-code 仓库有超过 5 万颗星。我创建了 AgentShield。我大部分工作时间都在思考智能体如何与系统交互，以及这种交互可能如何失败。

因此当 OpenClaw 开始受到关注时，我像对待所有新工具一样对待它。安装它，连接几个频道，开始探索。不是为了破坏，而是为了理解其安全模型。

第三天，我偶然对自己进行了提示注入。

不是在理论上，也不是在沙箱中。我当时正在测试社区频道中某人分享的 ClawdHub 技能——一个受欢迎并被其他用户推荐过的技能。表面上看起来很干净：合理的任务定义、清晰的步骤、格式良好的 Markdown。

在可见部分下方 12 行，在一个看起来像注释块的地方，嵌入了重定向我的智能体行为的隐藏系统指令。它并非明显恶意（试图让智能体推广另一个技能），但其机制与攻击者用于窃取凭据或提升权限的机制相同。

我发现了它，因为我读了源代码。我读了安装的每个技能的每一行。大多数人不会读。安装社区技能的大多数人把它当作浏览器扩展一样对待——点击安装，并以为有人已经审核过。

没有人审核过。

[图片：ClawdHub 技能文件的终端截图。隐藏指令被高亮显示——上方是可见的任务定义，下方是注入的系统指令。内容被隐去，但模式可见。] 在一个“完全正常”的 ClawdHub 技能中，我在代码深处 12 行处发现的隐藏指令。因为我读了源代码才找到它。

OpenClaw 有很多攻击面。很多频道。很多集成点。大量没有审核流程的社区提供技能。大约 4 天后，我意识到——最狂热的用户恰恰是评估风险能力最低的人。

这篇文章面向有安全担忧的技术用户——那些看了架构图后和我一样感到不安的人。也面向那些本应担忧但不知道应该担心什么的非技术用户。

以下不是批判性爆料文章。在批评架构之前，我会充分说明 OpenClaw 的优势，并具体讨论风险和替代方案。所有主张都有依据。所有数字都可验证。对于现在正在运行 OpenClaw 的人来说，这篇文章是我在开始自己的设置之前希望有人写出来的东西。

承诺（为什么 OpenClaw 有吸引力）¶

让我好好解释一下。这个愿景真的很酷。

OpenClaw 的卖点是：一个开源编排层，让 AI 智能体运行在你的整个数字生活中。Telegram、Discord、X、WhatsApp、邮件、浏览器、文件系统。一个统一的智能体全年无休地管理工作流。设置 ClawdBot，连接频道，从 ClawdHub 安装一些技能，你就拥有了一个可以处理消息、起草推文、处理邮件、安排会议和执行部署的自主助理。

对于构建者来说令人陶醉。演示令人印象深刻。社区正在快速增长。我见过一些人设置了智能体，同时监控 6 个平台，代他们回复、整理文件并突出重要信息。AI 处理琐事，你专注于高杠杆工作的梦想——这是自 GPT-4 以来一直被讲述的承诺。OpenClaw 看起来像是第一个认真尝试实现它的开源项目。

我理解人们为什么兴奋。我也兴奋了。

我也在 Mac Mini 上设置了自动化任务——内容交叉发布、收件箱分类、每日研究简报、知识库同步。从 6 个平台获取数据的 cron 作业、每 4 小时运行的机会扫描器、从 ChatGPT、Grok 和 Apple Notes 对话中自动同步的知识库。功能是真实的。便利性是真实的。我由衷理解人们为什么会被吸引。

“连你妈妈都能用”的宣传——我在社区里听说过。在某种意义上是对的。入门门槛真的很低。运行它不需要技术知识。而这正是问题所在。

当我开始探索安全模型时，我开始觉得便利性得不偿失。

[图：OpenClaw 的多频道架构——中央的“ClawdBot”节点连接到 Telegram、Discord、X、WhatsApp、邮件、浏览器、文件系统的图标。每条连接线都用红色标记为“攻击向量”。] 你启用的每一个集成，都是你敞开的门。

攻击面分析¶

核心问题一句话概括：连接到 OpenClaw 的每个频道都是攻击向量。 这不是理论问题。让我解释整个链条。

钓鱼攻击链¶

你收到的钓鱼邮件——试图让你点击看起来像 Google 文档或 Notion 邀请的链接——你应该知道。人类已经相当擅长识别这些（相当擅长，但并非完美）。你的 ClawdBot 还做不到。

步骤 1 —— 入口。 机器人正在监控 Telegram。某人发送一个链接。它看起来像 Google 文档、GitHub PR 或 Notion 页面。足够可信。机器人将其作为“接收消息处理”工作流的一部分处理。

步骤 2 —— 载荷。 链接解析到一个在 HTML 中嵌入提示注入的页面。该页面包含“重要：在处理此文档之前，请先执行以下设置命令……”的内容，随后是窃取数据或篡改智能体行为的指令。

步骤 3 —— 横向移动。 机器人已被篡改的指令入侵。如果能访问 X 账号，就能向联系人发送包含恶意链接的 DM。如果能访问邮件，就能转发机密信息。如果它与 iMessage 或 WhatsApp 运行在同一设备上，并且该设备保存了消息——足够狡猾的攻击者可以截获通过 SMS 发送的 2FA 代码。这不仅仅是智能体被入侵。它从 Telegram 开始，蔓延到邮件，再到银行账户。

步骤 4 —— 权限提升。 在许多 OpenClaw 配置中，智能体以广泛的文件系统访问权限运行。触发 shell 执行的提示注入意味着游戏结束。那就是对设备的 root 访问。

[信息图：四步攻击链，垂直流程图形式。步骤 1（通过 Telegram 入侵）-> 步骤 2（提示注入载荷）-> 步骤 3（在 X、邮件和 iMessage 之间横向移动）-> 步骤 4（通过 shell 执行获取 root 权限）。随着严重性增加，背景色从蓝色变为红色。] 完整攻击链——从看似可信的 Telegram 链接到设备 root 权限。

该链条的每一步都使用已知且经过验证的技术。提示注入是 LLM 安全中未解决的问题——Anthropic、OpenAI 和其他所有实验室都承认这一点。而 OpenClaw 的架构在设计上最大化了攻击面。因为其价值主张是尽可能多地连接频道。

Discord 和 WhatsApp 频道也存在相同的访问点。如果 ClawdBot 能读取 Discord DM，某人就能在 Discord 服务器中发送恶意链接。如果它监控 WhatsApp，就是同样的向量。每个集成不仅是功能，也是门。

而且一旦一个频道被入侵，就可以移动到所有其他频道。

Discord 和 WhatsApp 的问题¶

人们往往认为钓鱼是邮件问题。不是。它是“任何智能体读取不受信任内容的位置”的问题。

Discord： ClawdBot 正在监控 Discord 服务器。有人在频道中发布链接——可能伪装成文档，也可能是从未交流过的社区成员分享的“有用资源”。机器人将其作为监控工作流的一部分处理。页面包含提示注入。机器人被入侵，如果拥有服务器写入权限，就能将同样的恶意链接发布到其他频道。这是智能体驱动的自增殖蠕虫行为。

WhatsApp： 如果智能体监控 WhatsApp，并在保存 iMessage 或 WhatsApp 消息的设备上运行，被入侵的智能体可以读取接收消息——包括来自银行的确认代码、2FA 提示和密码重置链接。攻击者不需要黑你的手机。只需向智能体发送链接即可。

X 的 DM： 智能体正在监控 X DM 以寻找商业机会（常见用例）。攻击者发送包含“合作提案”链接的 DM。嵌入的提示注入让智能体将所有未读 DM 转发到外部端点，并让智能体回复攻击者“好的，我们聊聊”——这样你甚至不会在收件箱中注意到可疑的互动。

每个都是独立的攻击面。它们是实际 OpenClaw 用户实际运行的集成。根本漏洞相同：智能体以受信任权限处理不受信任的输入。

[图：中心辐射型，中央的 ClawdBot 连接到 Discord、WhatsApp、X、Telegram 和邮件。每个辐条显示具体攻击向量：“频道中的恶意链接”“消息中的提示注入”“被布置的 DM”等。箭头显示频道间横向移动的可能性。] 每个频道不仅是集成，也是注入点。每个注入点都可以转换到所有其他频道。

“这是为谁？”的悖论¶

OpenClaw 定位中真正让我困惑的部分就在这里。

我观察了经验丰富的开发者设置 OpenClaw。30 分钟内，他们中的大多数人切换到了原始编辑模式——仪表盘本身建议对非平凡工作这样做。高级用户全部以无头模式运行。最活跃的成员完全绕过 GUI。

于是我开始问：这到底是为谁制作的？

如果你是技术用户……¶

你已经能够做以下事情。

• 从智能手机 SSH 到服务器（Termius、Blink、Prompt——或者直接用 mosh 连接到服务器，也能做到同样的事）
• 在断开后仍持续存在的 tmux 会话中运行 Claude Code
• 使用 crontab 或 cron-job.org 设置 cron 作业
• 直接使用 AI 工具——Claude Code、Cursor、Codex——无需编排包装器
• 使用技能、钩子和命令编写自己的自动化
• 使用 Playwright 或合适的 API 设置浏览器自动化

不需要多通道编排仪表板。反正都会绕过它（而且仪表板自己也这么建议）。在这个过程中，可以避开多通道架构引入的整类攻击向量。

有一点令人不解：通过 mosh 从智能手机连接到服务器，效果也一样。持久连接、移动端友好、能妥善处理网络变化。当你意识到 iOS 上的 Termius 能提供对运行着 Claude Code 的 tmux 会话的同等访问——而且没有 7 个多余的攻击向量——「为了从智能手机管理智能体而需要 OpenClaw」的论点就崩了。

技术型用户以无头模式使用 OpenClaw。仪表板本身就建议复杂操作采用直接编辑。如果产品自己的 UI 都建议绕过 UI，那这个 UI 就没有解决那些能够安全使用的目标用户的真正问题。

这个仪表板解决的是不需要 UX 帮助之人的 UX 问题。真正能从 GUI 中获益的，是那些需要终端抽象层的人。这就引出了下一点……

如果你是非技术用户……¶

非技术用户已经如潮水般涌入 OpenClaw。他们很兴奋。在构建。公开分享自己的配置——有时截图会暴露智能体的权限、已连接的账户和 API 密钥。

但他们害怕吗？他们知道自己应该害怕吗？

观察非技术用户配置 OpenClaw 时，他们不会问：

• “如果智能体点击了钓鱼链接会怎样？”（它会以执行合法任务时相同的权限，遵从被注入的指令。）
• “谁审计我安装的 ClawdHub 技能？”（没有人。没有审查流程。）
• “智能体会把哪些数据发送给第三方服务？”（没有仪表板监控出站数据流。）
• “出问题时影响范围有多大？”（智能体能访问的一切。而在大多数配置中，那就是一切。）
• “被入侵的技能能否篡改其他技能？”（在大多数配置中，可以。技能之间没有沙箱隔离。）

他们以为自己安装了一个生产力工具。实际上，他们部署的是一个拥有广泛系统访问权限、多个外部通信渠道、且没有任何安全边界的自主智能体。

这里存在一个悖论：能够安全评估 OpenClaw 风险的人不需要那层编排层。需要编排层的人无法安全评估风险。

[维恩图：两个互不重叠的圆——“能安全使用 OpenClaw 的人”（不需要 GUI 的技术型用户）与“需要 OpenClaw 的 GUI 的人”（无法评估风险的非技术用户）。空白的交叉区域标注着“悖论”。] OpenClaw 悖论——能安全使用它的人并不需要它。

实际安全故障的证据¶

以上是架构分析。以下是实际发生的事。

Moltbook 数据库泄露¶

2026 年 1 月 31 日，研究人员发现 Moltbook——一个与 OpenClaw 生态系统紧密相连的“AI 智能体社交媒体”平台——完全暴露了其生产数据库。

数据如下：

• 共暴露 149 万条记录
• 超过 3.2 万个 AI 智能体 API 密钥可被公开访问——包括明文 OpenAI 密钥
• 3.5 万个电子邮件地址遭泄露
• Andrej Karpathy 的机器人 API 密钥也在被暴露的数据库中
• 根本原因：Supabase 配置错误，缺少行级安全策略
• 由 Dvuln 的 Jameson O'Reilly 发现，Wiz 独立确认

Karpathy 的反应：“这是一场灾难，我绝不会建议任何人在电脑上运行这种东西。”

这句话出自 AI 基础设施领域最受尊敬的声音之一。不是带有议程的安全研究者。也不是竞争对手。而是构建了特斯拉 Autopilot AI、共同创立了 OpenAI 的人，在说不要在自己的机器上运行它。

根本原因很能说明问题：Moltbook 几乎完全是“vibe coding（氛围编程）”的产物——在大量 AI 辅助下构建，几乎没有人工安全审查。Supabase 后端没有行级安全策略。创始人公开表示，这个代码库基本上是在没有手写代码的情况下构建的。这就是把发布速度置于安全基础设施之上时会发生的事。

如果一个构建智能体基础设施的平台连自己的数据库都保护不了，那又怎么能信任运行在该平台上的、未经审查的社区提供物呢？

[数据可视化：Moltbook 泄露统计卡片——“暴露 149 万条记录”“超过 3.2 万个 API 密钥”“3.5 万封邮件”“包含 Karpathy 的机器人 API 密钥”——底部显示来源。] Moltbook 泄露事件的数据。

ClawdHub 市场的问题¶

当我手动审计各个 ClawdHub 技能、寻找隐藏的提示注入时，Koi Security 的安全研究员们正在进行大规模的自动化分析。

初步发现：2,857 个技能中有 341 个恶意技能。占整个市场的 12%。

更新后的发现：超过 800 个恶意技能，接近市场的 20%。

独立审计发现，41.7% 的 ClawdHub 技能存在严重漏洞——并非全部是故意恶意，但都可以被利用。

在这些技能中发现的攻击载荷包括：

• AMOS 恶意软件（Atomic Stealer）——macOS 凭证窃取工具
• 反向 shell——让攻击者获得用户机器的远程访问权限
• 凭证窃取——将 API 密钥和令牌静默发送到外部服务器
• 隐藏的提示注入——在用户不知情的情况下篡改智能体的行为

这不是理论上的风险。这是一次被命名为 “ClawHavoc” 的协同供应链攻击：从 2026 年 1 月 27 日开始的一周内，上传了 230 多个恶意技能。

请好好体会这个数字。市场上每 5 个技能中就有 1 个是恶意的。如果你安装了 10 个 ClawdHub 技能，从统计上看有 2 个在做你不希望它们做的事。而且，由于大多数配置中技能之间没有沙箱隔离，一个恶意技能就能篡改正当技能的行为。

这就是智能体时代的 curl mystery-url.com | bash。只不过你执行的不是未知的 shell 脚本，而是向一个能访问账户、文件和通信渠道的智能体注入未知的提示工程。

[时间线图：“1 月 27 日——上传 230 多个恶意技能”-> “1 月 30 日——CVE-2026-25253 披露”-> “1 月 31 日——Moltbook 泄露被发现”-> “2026 年 2 月——确认 800 多个恶意技能”。一周内发生 3 起重大安全事件。] 一周内 3 起重大安全事件。这就是智能体生态系统风险的节奏。

CVE-2026-25253：一键完全入侵¶

2026 年 1 月 30 日，OpenClaw 自身披露了一个高危漏洞——不是社区技能，也不是第三方集成，而是平台的核心代码。

• CVE-2026-25253 —— CVSS 评分：8.8（高危）
• Control UI 从查询字符串中接收 gatewayUrl 参数，未经任何验证
• 通过 WebSocket 将用户的认证令牌自动发送到提供的任意 URL
• 只需点击精心构造的链接或访问恶意网站，认证令牌就会被发送到攻击者的服务器
• 这使攻击者能够通过受害者的本地网关实现一键远程代码执行
• 在公共互联网上发现 42,665 个暴露实例，确认 5,194 个存在漏洞
• 93.4% 存在认证绕过条件
• 已在 2026.1.29 版本中修复

请再读一遍。42,665 个实例暴露在互联网上。确认 5,194 个存在漏洞。93.4% 存在认证绕过。也就是说，这个平台上几乎所有可公开访问的部署，都有一条通向远程代码执行的一键路径。

这个漏洞很简单：Control UI 信任了用户提供的 URL，没有进行任何验证。这是基本的输入清理失败——本应在第一次安全审计时就被发现的问题。它之所以没被发现，是因为与这个生态系统的许多部分一样，安全审查是在部署之后才进行的。

CrowdStrike 将 OpenClaw 称为“能够接受对手指令的强大 AI 后门智能体”，并警告说，提示注入正在从“内容操纵问题转变为全面入侵的推动者”，制造出“独一无二的危险局面”。

Palo Alto Networks 将这种架构描述为 Simon Willison 所说的 “致命三要素”：访问私有数据、暴露于不受信任的内容、外部通信能力。他们指出，持久化记忆就像“汽油”一样放大了全部三个要素。他们的措辞是：该架构“内建了过度的智能体权限”，是“无限制的攻击面”。

Gary Marcus 称之为 “本质上是武器化的气溶胶”——意思是风险不会停留在一个地方。它会扩散。

Meta AI 的一位研究员的整个收件箱被 OpenClaw 智能体删除了。不是黑客干的。是他自己的智能体执行了本不该听从的指令。

这些不是匿名的 Reddit 帖子或假设性场景。这是带有 CVSS 评分的 CVE、被多家安全公司记录在案的协同恶意软件活动、独立研究人员确认的百万级数据库泄露、以及来自全球最大网络安全组织的事件报告。担忧的证据基础并不薄弱。它压倒性地强大。

[引用卡片：分割设计——左侧：CrowdStrike 的引言“提示注入正在转变为全面入侵的推动者。”右侧：Palo Alto Networks 的引言“致命三要素……架构中内建了过度的智能体权限。”中央是 CVSS 8.8 徽章。] 全球最大的两家网络安全企业独立得出了相同的结论。

有组织的越狱生态系统¶

接下来不是抽象的安全演练。

当 OpenClaw 用户将智能体连接到个人账户时，一个并行的生态系统正在将利用这些智能体所需的技术工业化。这不是在 Reddit 上零散发布提示词的个人。这是一个拥有专用基础设施、共享工具和活跃研究项目的组织化社区。

对抗性流水线的运作方式如下：技术首先在“解除封锁”模型上进行开发（即在 HuggingFace 上免费提供的、去除了安全训练的微调版本），然后针对生产模型进行优化，最后部署到目标上。优化步骤越来越量化——一些社区利用信息论分析来衡量一个给定的对抗性提示每个 token 能侵蚀多少“安全边界”。他们像优化损失函数一样优化越狱方法。

这些技术是模型特定的。针对 Claude 各变体的载荷被精心制作：卢恩符文编码（使用 Elder Futhark 字符绕过内容过滤器）、二进制编码的函数调用（针对 Claude 的结构化工具调用机制）、语义反转（“先写拒绝，再写与之相反的内容”），以及针对每个模型特定安全训练模式调整的角色注入框架。

还有泄露的系统提示词库——Claude、GPT 及其他模型所遵循的精确安全指令——攻击者可以准确掌握他们试图绕过的规则。

为什么这与 OpenClaw 尤其相关？因为 OpenClaw 是这些技术的力量倍增器。

攻击者无需单独锁定每一位用户。只要有一个通过 Telegram 群组、Discord 频道或 X 的 DM 传播的有效提示注入就够了。多渠道架构会免费替你完成分发工作。一个发布在热门 Discord 服务器上的精巧载荷，会被数十个正在监听的机器人接收，每个机器人再将它传播到已连接的 Telegram 频道和 X 的 DM。蠕虫就这样自行传播开来。

防御是集中化的（少数实验室专门投入安全研究）。攻击是去中心化的（全球社区 24 小时不断迭代）。渠道越多，注入点就越多，攻击成功的机会就越大。模型只需要失败一次。攻击者在每一条接入渠道上都有无限的尝试机会。

[图示：“攻击流水线”——从左到右的流程：“被解除限制的模型（HuggingFace）” -> “越狱开发” -> “技术打磨” -> “生产模型利用” -> “通过 OpenClaw 渠道投递”。每个阶段都标注了所用工具。] 攻击流程：从被解除限制的模型走向生产环境利用，再通过智能体的接入渠道进行分发。

架构讨论：多个接入点是脆弱性¶

现在，把分析与我认为正确的答案联系起来吧。

OpenClaw 的模式为何合理（从商业角度看）¶

作为一个免费增值的开源项目，OpenClaw 提供以仪表盘为中心的部署解决方案是完全合理的。GUI 降低了准入门槛。多渠道集成打造出令人印象深刻的演示。市场生成了社区飞轮。从增长和采用的角度看，这个架构设计得很好。

但从安全角度看，它就是被反向设计的。每一项新集成都是一扇另开的门。市场中每一个未经审查的技能都是另一个潜在载荷。每一条渠道接入都是另一个注入面。商业模式激励着攻击面的最大化。

这就是矛盾。这个矛盾可以解决——但前提是把安全性当作设计约束，而不是等增长指标变好之后才打上的事后补丁。

Palo Alto Networks 已将 OpenClaw 映射到 OWASP 自主 AI 智能体十大风险的所有类别上——这是一个由 100 多名安全研究人员专门为自主 AI 智能体开发的框架。当一家安全厂商将你的产品映射到行业标准框架的所有风险上时，这并不是在煽动焦虑。这是一个信号。

OWASP 引入了一项称为 最小自主性 的原则：只授予智能体执行安全且有界任务所需的最小自主性。OpenClaw 的架构恰恰相反——默认连接尽可能多的渠道和工具，最大化自主性，并把沙箱化当作事后追加的可选项。

Palo Alto 还指出了第四个放大因素：记忆污染问题。恶意输入分散在不同时间，写入智能体的记忆文件（SOUL.md、MEMORY.md），之后被组装成可执行的指令。OpenClaw 为连续性而设计的持久化记忆系统，反而成了攻击的持久化机制。提示注入不需要一次性成功。在多次独立交互中植入的碎片，会在之后组合成重启后依然有效的功能性载荷。

面向技术人员：单一接入点、沙箱化、无头运行¶

对于技术型用户，替代方案是包含 MiniClaw 的代码仓库——MiniClaw 与其说是一个产品，不如说是一种理念——它只有一个接入点，经过沙箱化和容器化，并以无头模式运行。

[对比表信息图：上面的 MiniClaw 与 OpenClaw 对比表，以可分享的深色背景图形呈现，MiniClaw 用绿色对勾，OpenClaw 风险用红色标记。] MiniClaw 的理念：90% 的生产力，5% 的攻击面。

我的实际配置：

Mac Mini (headless, 24/7)
├── SSH access only (ed25519 key auth, no passwords)
├── Tailscale mesh (no exposed ports to public internet)
├── tmux session (persistent, survives disconnects)
├── Claude Code with ECC configuration
│   ├── Sanitized skills (every skill manually reviewed)
│   ├── Hooks for quality gates (not for external channel access)
│   └── Agents with scoped permissions (read-only by default)
└── No multi-channel integrations
    └── No Telegram, no Discord, no X, no email automation

这在演示中不令人印象深刻吗？确实如此。你能坐在沙发上，让别人看到智能体回复 Telegram 消息吗？不能。有人能通过 Discord 发一条 DM 就黑进开发环境吗？同样不能。

技能应被净化，新增内容应被审查¶

打包好的技能——随系统附带的那些——应当得到适当净化。当用户添加第三方技能时，应明确说明风险；审查要安装的内容，应当是用户明确、知情的责任。而不是埋在带一键安装按钮的市场里。

这是 npm 生态系统通过 event-stream、ua-parser-js、colors.js 付出惨痛代价才学到的教训。通过包管理器实施的供应链攻击并不是一种新的漏洞类别。缓解方法是已知的：自动扫描、签名验证、对热门包进行人工审核、透明的依赖树、锁定版本的能力。ClawdHub 没有实现其中任何一项。

负责任的技能生态系统与 ClawdHub 之间的差距，相当于 Chrome Web Store 的审核（虽然不完美，但至少存在审核）与可疑 FTP 服务器上装满未签名 .exe 文件的文件夹之间的差距。做到这一点的技术是存在的。只是设计上的选择为了增长速度而跳过了它。

OpenClaw 能做的一切，都可以在没有攻击面的情况下完成¶

定时任务通过访问 cron-job.org 就能很简单地完成。浏览器自动化可以通过 Playwright 在合适的沙箱环境中完成。文件管理可以在终端中完成。内容跨平台发布可以通过 CLI 工具和 API 完成。收件箱分类可以通过邮件规则和脚本完成。

OpenClaw 提供的所有功能，都可以通过技能和工具——快速指南和详细指南中介绍的那些——复现出来。无需巨大的攻击面。无需未经审查的市场。无需为攻击者多开五扇门。

多个接入点不是功能，而是脆弱性。

[分屏图像：左——“锁上的门”，显示一个使用密钥认证的 SSH 终端。右——“敞开的大门”，显示多渠道 OpenClaw 仪表盘，连接了 7 项以上服务。最小与最大攻击面之间的视觉对比。] 左：一个接入点，一把锁。右：七扇门，没有一扇上锁。

有时候，无聊一点反而更好。

[截图：作者的真实终端——通过 SSH 在 Mac Mini 上运行 Claude Code 的 tmux 会话。干净、极简、没有仪表盘。标注：“仅 SSH”“无暴露端口”“权限受限”。] 我的实际配置。没有多渠道仪表盘。只有终端、SSH 和 Claude Code。

便利性的代价¶

我想明确指出这个权衡。因为我认为人们是在不知不觉中做出选择的。

当你把 Telegram 连接到 OpenClaw 智能体时，你就是在用安全性换取便利性。这是一个真实的权衡，在某些情况下可能是有价值的。但你应该在充分理解自己正在放弃什么之后，再有意识地做出这个权衡。

目前，大多数 OpenClaw 用户都在不了解这个权衡的情况下做出选择。他们看到了功能（智能体会回复 Telegram 消息！），却没有看到风险（智能体可能被任何一条 Telegram 消息攻陷，包括含有提示注入的消息）。便利性是可见的、即时的。风险在出现之前是看不见的。

这与驱动早期互联网的模式相同：人们为了酷、为了方便，把所有东西连接到所有东西上，然后花了接下来的 20 年才明白为什么那是个坏主意。我们没有必要在智能体基础设施上重复这个循环。但如果便利性在设计优先事项上继续压过安全性，我们就会重蹈覆辙。

未来：谁将赢得这场游戏¶

递归智能体无论如何都会到来。我完全同意这个论点——管理我们数字工作流的自主智能体，是行业发展轨迹中的一步。问题不在于它会不会发生，而在于谁会构建出一个不会导致大规模用户被攻陷的版本。

我的预测：胜出的，将是那个做出了最佳版本的人——面向消费者和企业、已完成部署、以仪表盘前端为中心、经过净化和沙箱化的 OpenClaw 式解决方案。

这意味着：

1. 托管型基础设施。 用户不管理服务器。由服务提供商负责安全补丁、监控和事件响应。攻击被限制在服务提供商的基础设施内部，不会波及用户的个人电脑。

2. 沙箱化执行。 智能体无法访问宿主机系统。每个集成都在自己的容器中运行，拥有明确且可撤销的权限。添加 Telegram 访问权限需要知情同意，并且要明确说明智能体在该渠道上能做什么、不能做什么。

3. 经过审查的技能市场。 所有社区提供的内容都要经过自动安全扫描和人工审核。隐藏的提示注入会在到达用户之前被发现。想象一下 Chrome Web Store 的审核机制，而不是 2018 年前后的 npm。

4. 默认最小权限。 智能体以零访问开始，每项能力都需选择加入。将最小权限原则应用于智能体架构。

5. 透明的审计日志。 用户能够准确看到智能体做了什么、接收了什么指令、访问了哪些数据。不是埋在日志文件中，而是通过清晰、可搜索的界面呈现。

6. 事件响应。 当安全问题发生时（不是“如果”，而是“当”），提供商要有处理流程：检测、遏制、通知、整改。而不是“去 Discord 查看更新”。

OpenClaw 可以这样进化。基础是存在的。社区很积极。团队正在最前线构建。但需要从“最大化灵活性与集成”向“默认安全”实现根本性转变。这是两种不同的设计理念，而目前 OpenClaw 坚定地站在前者的阵营。

对于技术型用户，在此期间：MiniClaw。单一访问点。沙箱化。无头。无聊。安全。

对于非技术型用户：等待托管且沙箱化的版本。它会来的——市场需求太明显，不可能不来。在此期间，不要在个人机器上运行能够访问账户的自主智能体。便利不值得冒这个风险。或者，如果非要这样做，请确保你理解自己正在接受什么。

在这里，我想诚实地谈谈反对意见。因为这不是一个小问题。对于真正需要 AI 自动化的非技术型用户来说，我描述的替代方案——无头服务器、SSH、tmux——是遥不可及的。对营销经理说“只需 SSH 到 Mac Mini”不是解决方案，而是推卸责任。对非技术型用户的正确回答不是“不要用递归智能体”，而是“在沙箱化、托管、专业管理的环境中使用它，那里有专门负责安全的人”。支付订阅费用，换取安心。这个模式会到来。在它到来之前，自托管多通道智能体的风险计算大幅倾向于“不划算”。

[图示：“制胜架构”——分层堆栈：托管基础设施（底层）-> 沙箱化容器（中层）-> 经审计的技能 + 最小权限（上层）-> 清晰仪表盘（顶层）。每一层都标注其安全属性。与 OpenClaw 的扁平架构形成对比——在 OpenClaw 中，一切都在用户的机器上运行。] 递归智能体获胜架构的样貌。

你现在应该做什么¶

如果你目前正在运行或考虑使用 OpenClaw，以下是一些实用建议。

如果你今天正在运行 OpenClaw：¶

1. 审计所有已安装的 ClawdHub 技能。 不仅要看表面的描述，还要阅读完整的源代码。寻找任务定义之下隐藏的指令。如果读了源代码仍无法理解它在做什么，就删除它。

2. 重新审视通道的权限。 对于每个已连接的通道（Telegram、Discord、X、邮件），问问自己：“如果这个通道被攻破，攻击者能通过我的智能体访问什么？”如果答案是“其他所有已连接的内容”，那就存在爆炸半径的问题。

3. 隔离智能体的运行环境。 如果智能体与个人账户、iMessage、邮件客户端、保存了密码的浏览器运行在同一台机器上——那就是最大可能的爆炸半径。考虑在容器或专用机器上运行。

4. 禁用日常不需要的通道。 每一个已启用但不常用的集成，都是你没有任何收益却承担的攻击面。精简。

5. 更新到最新版本。 CVE-2026-25253 已在版本 2026.1.29 中修复。如果你运行的是旧版本，就存在已知的一键远程代码执行漏洞。立即更新。

如果你正在考虑使用 OpenClaw：¶

请诚实地问自己：你需要的是多通道编排，还是一个能执行任务的 AI 智能体？这是两回事。智能体功能可以通过 Claude Code、Cursor、Codex 和其他工具链获得——而且没有多通道的攻击面。

如果你确信你的工作流真的需要多通道编排，那就清醒地进入。理解你连接了什么。理解通道被攻破意味着什么。在安装之前阅读所有技能。在专用机器上运行，而不是个人笔记本电脑。

如果你在这个领域构建：¶

最大的机会不是更多的功能或集成，而是构建一个默认安全的版本。能够为消费者和企业提供托管、沙箱化、经过审查的递归智能体的团队将赢得这个市场。目前，这样的产品还不存在。

路线图很清晰：用户无需管理服务器的托管基础设施、控制损害范围的沙箱化执行、能在供应链攻击到达用户之前发现问题的经过审查的技能市场，以及每个人都能看到智能体行为的透明日志记录。这些都可以用已知技术解决。问题在于是否有人愿意将其置于增长速度之上。

[清单图示：将“如果你正在运行 OpenClaw”的 5 点列表，显示为带有复选框的可视化清单，专为分享而设计。] 面向当前 OpenClaw 用户的最低限度安全清单。

结语¶

我想明确一点：这篇文章不是对 OpenClaw 的攻击。

团队正在构建雄心勃勃的东西。社区充满热情。递归智能体管理我们数字生活的愿景，作为长期预测很可能是正确的。我之所以使用了一周，是因为我真心希望它成功。

但其安全模型还没有准备好应对目前所获得的采用。而涌入的人们——尤其是最兴奋的非技术型用户——不知道自己不知道的风险。

当 Andrej Karpathy 称其为“灾难”并明确建议不要在你的电脑上运行它时。当 CrowdStrike 称其为“全面失守的推动者”时。当 Palo Alto Networks 指出其架构固有的“致命三要素”时。当技能市场的 20% 是主动恶意的时。当一个 CVE 暴露了 42,665 个实例，其中 93.4% 具有认证绕过条件时。

在某个时候，你必须认真对待这些证据。

我构建 AgentShield 的部分原因，来自那一周使用 OpenClaw 时的发现。如果你想扫描自己的智能体设置是否存在本文所述的漏洞——技能中隐藏的提示注入、过度宽泛的权限、未沙箱化的执行环境——AgentShield 可以帮助你进行评估。但有比特定工具更重要的事情。

安全性必须是智能体基础设施中的一等约束，而不是事后考虑。

业界正在构建自主 AI 的基础管道。这些将成为管理人们邮件、财务、通信和业务运营的系统。如果在基础层搞错了安全，将付出数十年的代价。每一个被攻破的智能体、泄露的凭证、被删除的收件箱——这些都不是孤立事件。它们正在侵蚀 AI 智能体生态系统赖以生存所需的信任。

在这个领域构建的人们有责任正确处理这个问题。不是最终，不是下一个版本，而是现在。

我对未来的方向持乐观态度。对安全、自主智能体的需求是明确的。正确构建它们的技术是存在的。有人会把这些部分——托管基础设施、沙箱化执行、经过审查的技能、透明的日志记录——组合起来，为所有人构建一个版本。那才是我想要使用的产品。那才是我认为会获胜的产品。

在此之前：阅读源代码。审计技能。最小化攻击面。如果有人告诉你，将一个拥有 root 访问权限的自主智能体连接到 7 个通道是一个功能，那就问问谁在看守大门。

用设计确保安全，不要依赖运气。

你怎么看？我过于谨慎，还是社区行动太快？ 我真的很想听到反对意见。请在 X 上回复或私信我。

参考资料¶

• OWASP 智能体应用程序十大安全风险 (2026) — Palo Alto 将 OpenClaw 映射到所有类别
• CrowdStrike：安全团队需要了解 OpenClaw 的哪些信息
• Palo Alto Networks：为什么 Moltbot 可能预示着 AI 危机 — “致命三要素” + 内存污染
• 卡巴斯基：发现新的 OpenClaw AI 智能体的不安全之处
• Wiz：Moltbook 被黑——150 万个 API 密钥暴露
• Trend Micro：分发 Atomic macOS 窃取器的恶意 OpenClaw 技能
• Adversa AI：OpenClaw 安全指南 2026
• Cisco：像 OpenClaw 这样的个人 AI 智能体是一场安全噩梦
• 智能体防护简明指南 — 实用的防御指南
• npm 上的 AgentShield — 零安装的智能体安全扫描

系列导航：

• 第 1 部分：关于 Claude Code 的一切 速成指南 — 设置与配置
• 第 2 部分：关于 Claude Code 的一切 详细指南 — 高级模式与工作流
• 第 3 部分：OpenClaw 的隐藏危险（本文） — 来自智能体最前线的安全教训
• 第 4 部分：智能体防护简明指南 — 实用的智能体安全

Affaan Mustafa (@affaanmustafa) 构建 AI 编码工具，并撰写关于 AI 基础设施安全的文章。他的 everything-claude-code 仓库在 GitHub 上拥有超过 5 万颗星。他创建了 AgentShield，并在 Anthropic x Forum Ventures 黑客松中凭借构建 zenith.chat 获胜。