2026 年 2 月 4 日，安全研究员 @evildaemond 在 Hacker News 上公开了一个 OpenClaw 的远程代码执行（RCE）漏洞。漏洞的利用路径简洁到令人不安：攻击者只需向一个运行 OpenClaw 的 WhatsApp 群组发送一条精心构造的消息，就能在宿主机上以 OpenClaw 进程的权限执行任意命令。
这不是一个复杂的利用链。没有内存损坏，没有竞态条件，没有需要链接的多个漏洞。问题出在 OpenClaw 处理用户输入的方式——某些消息格式被直接传递给了底层的命令执行接口，没有经过充分的输入验证和转义。在安全术语中，这是一个教科书级别的命令注入。
漏洞被披露后几个小时内，OpenClaw 团队发布了紧急修复。响应速度值得肯定。但修复本身——增加输入过滤和转义——只是在已有架构上打补丁。它解决了这一个漏洞，但没有改变产生这个漏洞的根本条件：agent 代码和宿主系统之间没有隔离边界。
为什么无隔离架构注定要反复打补丁
理解这个漏洞为什么重要，需要看清一个更大的模式。
OpenClaw 的 agent 直接运行在宿主操作系统上，和你的文件、你的凭证、你的数据库、你的其他服务共享同一个系统。当 agent 代码中存在一个输入处理缺陷时，攻击者获得的不是对一个沙箱的访问权——而是对你整台机器的访问权。
这不是 OpenClaw 团队的编码质量问题。任何足够复杂的软件都会有 bug，处理不可信输入的软件尤其如此。问题在于架构：当 agent 和宿主之间没有隔离层时，每一个 bug 都是一个潜在的系统级安全事件。你必须保证每一行处理用户输入的代码都是完美的——而这是一个不可能完成的任务。
安全工程的基本原则之一是纵深防御：假设每一层都会被突破，然后确保突破任何一层都不会导致全面失守。OpenClaw 的架构在 agent 和宿主之间只有一层防线——应用层代码本身。一旦这层防线出现缝隙，游戏就结束了。
NanoClaw 的容器隔离为什么是根本性不同
NanoClaw 从第一天起就在隔离容器中运行 agent。每个 agent 会话启动一个独立的 Docker 容器（macOS 上是 Apple Container），agent 代码在容器内执行，和宿主操作系统之间有一道由内核强制执行的边界。
这意味着即使 NanoClaw 的 agent 代码中存在和 OpenClaw 一模一样的输入处理缺陷——假设攻击者通过消息注入成功在 agent 进程中执行了任意命令——他们获得的也只是对一个临时容器的访问权。容器没有宿主文件系统的完整访问权，没有宿主网络的完整访问权，运行结束后会被销毁。
这不是说容器逃逸不可能。容器逃逸漏洞存在，但它们是内核级别的安全问题，利用难度和应用层的命令注入完全不在一个量级。攻击者需要先突破 agent 代码，然后再突破容器运行时——这就是纵深防御的意义。
更重要的是，NanoClaw 的容器是无状态的。每次会话启动一个新容器，会话结束后容器被销毁。即使攻击者成功进入了容器，他们获得的也是一个短暂的、隔离的、没有持久化能力的环境。没有什么值得偷的东西，因为容器里本来就没有放什么值得偷的东西。
API 密钥通过 stdin 在运行时传入，不存在于容器的环境变量或文件系统中。宿主的文件系统只有被明确挂载的目录才对容器可见。网络访问受容器网络策略约束。这些不是 NanoClaw 自己实现的安全机制——它们是 Docker 和 Apple Container 提供的、被数千工程师维护和审计的基础设施。
输入验证 vs 架构隔离
OpenClaw 修复 RCE 漏洞的方式是改进输入验证。这是正确的做法——你当然应该验证输入。但输入验证是一种脆弱的防御。它依赖于开发者能预见所有可能的恶意输入模式，并为每一种模式编写正确的过滤规则。历史反复证明，这是一场永远打不赢的军备竞赛。
容器隔离是一种不同类别的防御。它不试图预测攻击者会做什么，而是限制攻击者即使成功了能造成什么后果。输入验证说"我不允许你做这件事"；容器隔离说"即使你做了，影响也被限制在这个盒子里"。
两者不是互斥的。NanoClaw 同样做输入验证，因为防御要分层。但 NanoClaw 的安全模型不依赖于输入验证的完美性。即使输入验证出了纰漏——而它迟早会出——容器边界仍然在那里。
这意味着什么
OpenClaw 的 RCE 漏洞不是最后一个。只要 agent 直接运行在宿主系统上，处理来自互联网的不可信输入，类似的漏洞就会持续出现。每一次的修复模式都是一样的：发现漏洞、紧急打补丁、发布公告、用户更新。这个循环没有尽头，因为根本架构没有改变。
NanoClaw 选择了一条不同的路：不是试图写出完美的代码，而是假设代码一定会有缺陷，然后用架构来限制缺陷的影响范围。这不是更聪明的做法——这是唯一诚实的做法。没有人能写出没有 bug 的代码，但你可以选择让 bug 的影响被限制在一个临时容器里，而不是蔓延到你的整个系统。