OpenClaw 这类 AI 代理是个很让人上头的东西：你把任务交给它，它真的会去终端里敲命令、翻文件、调脚本、联网查资料，然后把结果整理给你。我刚在 Windows 上通过 PowerShell 部署 OpenClaw 的时候，觉得那个 exec 审批机制已经够意思了——每条命令都要我确认，相当于请了个干活的人，但每下一步棋还得跟你知会一声。可项目越用越深入，我越来越不安：它既然能读 workspace 里的文件，就几乎等于能在你系统里自由走动；它既然有执行命令的能力，权限稍微宽松一点就是半个管理员；它还要联网，谁也没法保证它不会下载一些奇怪的东西回来。
人的审批只是事后兜底，真正能把破坏范围钉死的，得靠环境层面的隔离。这也正是我写这篇文章的初衷——用 Docker 给 OpenClaw 套上铠甲，把容器沙箱隔离这件事彻底做扎实。本文记录的是我实际操作的全过程，从为什么这样设计，到 Dockerfile 怎么写、目录怎么挂、权限怎么收、网络怎么断，再到常见坑怎么躲，尽量做到你照着走一遍，就能获得一个既能放开手脚干活、又不会殃及宿主机的 OpenClaw 环境。
1. 隔离方案的整体设计思路
1.1 OpenClaw 到底在替你做什么
OpenClaw 不是那种只会聊天的对话机器人，它是一类能直接和操作系统交互的 AI 代理。它的工作目录默认在~/.openclaw/workspace，所有文件读写、命令执行、skill 调用都以这个目录为中心展开。你让它"整理项目文档"，它会自己去 workspace 里翻文件、重命名、写新文件；你让它"排查日志报错"，它可能会执行 grep、tail、curl 等一系列命令。
它还引入了exec-approvals.json这套命令审批机制，也就是说，OpenClaw 打算执行一条有风险的命令时，会先查阅这个文件里的授权规则，没规则就先暂停、征求你的意见。这个设计非常实用，但你要意识到一件事：审批机制防的是误操作，防不了一个已经被污染的上下文。AI 代理在读取网页、处理外部文档时，有可能被提示词注入诱导，进而在审批上替你做出不那么理性的判断。这也是我坚持要在环境层做隔离的根本原因。
1.2 为什么偏偏选 Docker 而不是虚拟机
在动手之前，我也认真考虑过几个方案。虚拟机隔离最彻底，VirtualBox、VMware、Hyper-V 都能提供完整的内核隔离边界，但缺点太重：镜像体积动辄几个 GB，启动要等好几分钟，日常维护要打补丁、管快照，用来跑一个 CLI 型 AI 代理有点杀鸡用牛刀。
进程级隔离方案，比如 systemd-run 的临时作用域，或者直接在宿主机上创建一个受限用户，配置上轻量，但隔离边界太模糊。OpenClaw 要读文件、要执行命令、要联网下载依赖，这三点一旦放开，进程级方案很难真正限制它的行动范围。
Docker 处于两者之间最舒服的位置：它共享宿主机内核，但通过 namespace、cgroups、seccomp、capabilities 这套组合拳，能在文件系统、进程、网络、权限、资源配额五个维度形成清晰可控的边界。而且容器秒级启动、镜像可版本化、配置可纳入 git 管理，对开发者来说完全是顺手的工具链。它的隔离强度不如虚拟机，但防 AI 代理这种"非恶意但可能失控"的场景，已经绰绰有余。
1.3 五层隔离的设计总览
我最终落地的方案，可以概括为五层铠甲。第一层是文件系统隔离：容器根文件系统以只读方式运行，仅把 workspace 和配置目录透出给宿主机，容器内部其他地方想写也写不进去。第二层是进程与权限隔离：容器内跑在非 root 用户下，丢掉所有 Linux capabilities，禁止再提权，同时限制进程总数。第三层是网络隔离：容器使用用户自定义 bridge 网络，外部默认无法主动访问容器，只有我指定的端口通过回环地址映射出来。第四层是资源隔离：CPU、内存、swap、临时目录大小全部设上限，就算 OpenClaw 跑出一个失控的循环，也顶多在笼子里空转。第五层是生命周期隔离：容器随时可以销毁重建，所有重要数据都在宿主机挂载目录里，测试新版本时老环境一键回滚。
这套设计最核心的思路是"默认拒绝"：不是去想 OpenClaw 可能需要什么再给它什么，而是先切断一切，再按需开一个最小的口子。
2. 环境准备与 Dockerfile 构建
2.1 宿主机 Docker 环境就绪
这一步是纯基础工作。Linux 下直接装 docker-ce 即可，Windows 下则推荐 Docker Desktop，配合 WSL2 后端使用。WSL2 的好处是性能更接近原生 Linux，文件共享也更稳定，OpenClaw 容器里跑出来的行为与 Linux 服务器一致，后面如果要迁到云端部署，几乎不用改配置。
装完 Docker 之后先做两件事。第一件是配置镜像加速器，因为默认仓库的拉取速度在不同网络环境下差异很大，尤其拉基础镜像时经常让人等到没脾气。常见做法是在 Docker Engine 的配置里添加registry-mirrors，指向公共加速地址，然后重启 Docker 服务，再docker info确认生效。第二件事是验证环境，跑一个docker run hello-world，能正常输出说明引擎工作正常。
2.2 规划宿主机目录与权限规则
容器内的数据必须落在宿主机上，否则容器一销毁配置和成果就全没了。我建议在宿主机上建立一个总目录，比如~/openclaw-data，下面分三个子目录：
config/：对应容器内的~/.openclaw，保存 OpenClaw 的配置、exec 审批规则、skill 文件workspace/：对应容器内的~/.openclaw/workspace，这是 AI 代理工作的主战场logs/：对应容器内的日志输出目录，排查问题时不用进容器直接看宿主文件
这里有一个容易忽略的点：容器里的 OpenClaw 是以非 root 用户运行的，我会把它的 UID 固定为 1001。宿主机上的config和workspace目录就需要chown -R 1001:1001归到同一个 UID 下，否则容器内进程会因为没有写权限而表现出一堆诡异问题。在 Linux 上这一步直接用chown完成，Windows 下则通过 Docker Desktop 的 Settings 里把对应盘符共享给 WSL2，一般会自动处理权限映射。
2.3 编写第一版 Dockerfile
既然要把 OpenClaw 装进镜像，Dockerfile 就得比"FROM 一个镜像然后 RUN 一条 curl"更讲究。下面是我实际使用的 Dockerfile 骨架，以 Node.js 发行版为基础示例：
FROM node:20-slim AS base RUN apt-get update && apt-get install -y --no-install-recommends \ git curl ca-certificates \ && rm -rf /var/lib/apt/lists/* # 安装 OpenClaw，具体命令以你部署版本的官方安装方式为准 RUN npm install -g openclaw@latest # 创建固定 UID 的非 root 用户 RUN useradd -r -u 1001 -m -d /home/openclaw -s /bin/bash openclaw USER openclaw WORKDIR /home/openclaw ENV OPENCLAW_HOME=/home/openclaw/.openclaw ENV PATH="${PATH}:/home/openclaw/.local/bin" VOLUME ["/home/openclaw/.openclaw/workspace", "/home/openclaw/.openclaw"] EXPOSE 8080 CMD ["openclaw", "serve"]每一层其实都有明确的意图。node:20-slim作为基础镜像，体积比完整版小很多，攻击面也小。git和curl是 OpenClaw 联网拉取资源时经常依赖的工具，但装完之后我会清掉 apt 缓存，避免镜像里堆积无用文件。useradd -r -u 1001创建了一个固定 UID 的普通用户，这一步为后面所有权限收紧做了铺垫。ENV OPENCLAW_HOME让 OpenClaw 明确知道配置和 workspace 都在哪个目录。VOLUME只是声明，真正生效要靠后面 docker run 或 compose 里的挂载。
构建命令也很简单：
docker build -t openclaw:latest .个人不建议用docker commit这种方式来"固化"正在运行的容器，因为 commit 出来的镜像不可追溯，别人无法从 Dockerfile 里看出环境是怎么来的，出问题时要排查就非常痛苦。Dockerfile 虽然多花几分钟，但它构建出来的镜像干净、可重复、可评审。
3. 权限收紧与核心配置落地
3.1 一条完整的 docker run 命令能有多严
镜像构建好之后，真正的重头戏是增大启动参数。我从线下实践里打磨出了一套完整的 docker run 命令，下面逐步拆解每一个参数的作用：
docker run -d \ --name openclaw-sandbox \ --hostname openclaw-sandbox \ --restart unless-stopped \ --cap-drop ALL \ --security-opt no-new-privileges:true \ --pids-limit 512 \ --memory 2g \ --memory-swap 2g \ --cpus 2 \ --read-only \ --tmpfs /tmp:rw,noexec,nosuid,size=256m \ --tmpfs /var/tmp:rw,noexec,nosuid,size=64m \ -e TZ=Asia/Shanghai \ -v ${PWD}/config:/home/openclaw/.openclaw \ -v ${PWD}/workspace:/home/openclaw/.openclaw/workspace \ -v ${PWD}/logs:/home/openclaw/logs \ -p 127.0.0.1:8080:8080 \ openclaw:latest--cap-drop ALL是关键中的关键。Linux 的 capabilities 机制把 root 权限拆成了几十种小块能力，ALL意味着容器进程一个能力都没有，很多经典的权限扩大攻击在这里直接被掐断。--security-opt no-new-privileges:true进一步堵死 setuid 提权路径。这两行组合起来，即使容器里真有攻击者拿到了代码执行权，它也拿不回管理员的权限位。
--pids-limit 512防止 fork 炸弹，--memory 2g --memory-swap 2g限制内存并禁用额外的 swap，--cpus 2限制CPU占用。AI 代理偶尔会写循环或者同时拉起多个子任务，这几个配额保证它在疯跑时只是独占自己那 2 个核心，而不是把整台机器拖垮。
--read-only让根文件系统变成只读，这可能是最出乎很多人意料的一招。OpenClaw 作为 AI 代理，按理说需要写文件，但容器里有挂载卷和 tmpfs，真正需要持久化或临时写的地方都有出路，根分区反而没有必要可写。这一下就把"篡改系统文件"的可能性降到了零。
3.2 网络策略：该断的断、该通的通
AI 代理要跑起来，网络一定是通的，它要访问大模型 API、拉取外部数据，完全断网不现实。我的原则是：仅回环暴露入站，出站按需放行。
-p 127.0.0.1:8080:8080把 Web 界面、管理接口绑定在宿主机的回环地址上，这意味着只有本机能访问，局域网内其他设备一概打不进来。如果要让外部访问，至少应该在前面加一层正向代理做认证，而不是直接把0.0.0.0暴露出去。
出站流量方面，在 docker 默认 bridge 网络下容器可以访问外网。如果你担心 AI 代理误连内网设备，可以把容器接到一个自定义 bridge，配合宿主机 iptables 对容器出口做白名单，只放行目标为模型 API 域名的流量。我实践中没有做到这一步，但对安全要求高的场景完全值得加上。
还有一个禁忌需要特别强调：不要把/var/run/docker.sock挂载进容器。网上很多教程为了省事会这么干，用 docker-in-docker 的方式让容器内能操作 Docker。但这相当于把管家钥匙直接交给 AI 代理，它一旦在容器里执行docker run命令，隔离就彻底形同虚设了。要让 OpenClaw 具备部署能力，应该走 REST API 加独立访问密钥的方案，而不是直接暴露 socket。
3.3 审批规则、配置文件迁移与权限检查
OpenClaw 的 exec 审批规则保存在exec-approvals.json里。很多人在 Linux 上部署时，进程默认 Home 目录在/root，于是审批文件落在/root/.openclaw/exec-approvals.json。容器化之后，我们切到了非 root 用户，配置目录变成了/home/openclaw/.openclaw，新环境里不会自动继承原来的审批规则。
实际操作中，如果在容器启动日志里看到类似legacy exec approvals exist at /root/.openclaw/exec-approvals.json的提示，就要先手动把旧审批文件里已经授权的规则迁移到新的配置目录，否则新版 OpenClaw 会忽略旧文件里的规则，你会发现之前明明批准过执行的命令又开始一遍遍弹确认。
具体步骤是这样的：
- 在宿主机上把原有
exec-approvals.json复制到~/openclaw-data/config/ - 检查文件归属，确保 UID 是 1001：
chown -R 1001:1001 ~/openclaw-data/config/ - 启动容器后，
docker exec openclaw-sandbox cat /home/openclaw/.openclaw/exec-approvals.json确认文件内容可见 - 如果目录里还有其他旧 skill 文件或配置，一并迁移过去
还有一类坑是权限边界不清晰：挂载目录在宿主机上可能是 root 所有，容器内是非 root 用户，OpenClaw 试图向 workspace 写入文件时会被拒。解决方式是在宿主机上执行一次chown -R 1001:1001，每次从备份恢复配置后也建议重新检查一遍权限。
3.4 用 docker compose 把配置固化下来
docker run 命令虽然完整，但太长了，记不住也不好传给团队。我用 docker compose 把全部配置固化成了一个文件，这是目前我最推荐的落地方式。
services: openclaw: build: . image: openclaw:latest container_name: openclaw-sandbox hostname: openclaw-sandbox restart: unless-stopped cap_drop: - ALL security_opt: - no-new-privileges:true pids_limit: 512 mem_limit: 2g memswap_limit: 2g cpus: 2 read_only: true tmpfs: - /tmp:rw,noexec,nosuid,size=256m - /var/tmp:rw,noexec,nosuid,size=64m environment: - TZ=Asia/Shanghai volumes: - ./config:/home/openclaw/.openclaw - ./workspace:/home/openclaw/.openclaw/workspace - ./logs:/home/openclaw/logs ports: - "127.0.0.1:8080:8080" logging: driver: json-file options: max-size: "10m" max-file: "3"compose 还有一个容易被忽略的好处是日志管理。我明确指定了json-file驱动并限制单个日志文件 10MB、保留 3 个文件，否则容器日志可能无限膨胀，最后把磁盘塞满。OpenClaw 的高频日志输出实测一个月能写好几 GB，这个限制非常必要。
4. 运行验证、常见问题与避坑实录
4.1 四重隔离验证：眼见为实
配置写完之后，不建议直接开始高强度使用，先做一轮验证比较稳妥。我每次搭建新环境都会跑下面几组命令，确认四层隔离都在工作。
文件系统隔离验证：
docker exec openclaw-sandbox touch /tmp/writable-test docker exec openclaw-sandbox ls workspace/ # 预期：workspace 里有宿主机放进去的文件 # 预期：/ 根分区之外的普通路径无法写入，如果试图写会得到 Read-only file system 报错这个测试的价值在于确认了"可写范围"正好是我们划定的那几个目录。如果 OpenClaw 后续要写别的路径写不进去，说明隔离生效而不是配置出错了。
进程隔离验证：
docker exec openclaw-sandbox ps -ef # 容器内看到的进程数量非常有限，且 PID 是容器内独立的命名空间如果容器内进程列表和宿主机重合，那说明有权限问题。正常情况下你只能看到 OpenClaw 启动进程以及它的子进程，宿主机上的那些 daemon 一概看不到。
网络隔离验证：
docker exec openclaw-sandbox curl -I https://example.com # 容器内访问外网是通的，AI 代理能正常拉取数据 ss -tlnp | grep 8080 # 宿主机上监听端口只有 127.0.0.1:8080，没有 0.0.0.0:8080在宿主机的 netstat 输出里，如果发现别的端口被监听，很可能映射参数写错了。我遇到过把127.0.0.1:8080:8080写成8080:8080的情况，结果容器端口直接把局域网暴露了，安全等级立刻掉一个档次。
资源限制验证：
docker stats --no-stream这个命令会展示每个容器的实时 CPU 和内存占用。配合手工压测，比如在容器里跑一个单核死循环，观察 CPU 占用是否会稳定在 200% 左右（对应 cpus 2 的上限），就能确认资源配额生效。
4.2 常见问题排查速查表
| 现象 | 可能原因 | 解决办法 |
|---|---|---|
| 容器启动后 workspace 是空的 | 挂载目录不存在或权限不对 | 确认宿主机目录存在；Windows 下检查 Docker Desktop 的共享盘符配置；Linux 下检查目录 UID 是否为 1001 |
| 镜像拉取非常缓慢 | 默认仓库网络链路不佳 | 为 Docker Engine 配置 registry-mirrors 加速器并重启 Docker 服务 |
| OpenClaw 提示没有写权限 | 非 root 用户 UID 与挂载目录不匹配 | 在宿主机对 config 和 workspace 执行chown -R 1001:1001 |
| 日志报 legacy exec approvals exist | 新旧配置目录迁移不完全 | 把旧审批文件拷贝到新的 config 目录并修权限，再重启容器 |
| 容器重启后 OpenClaw 丢配置 | 挂载配置未生效 | docker inspect openclaw-sandbox检查 Mounts 字段 |
| 容器内无法访问外网 | 网络策略过于严格 | 检查宿主机 iptables 和 docker network inspect，确认出站放行 |
| 容器内执行 curl 提示证书问题 | 基础镜像缺少 CA 证书 | 在 Dockerfile 中安装 ca-certificates 后重新构建 |
| 根文件系统只读导致 AI 任务失败 | 临时文件没有落点 | 扩容 tmpfs 或为/home/openclaw/.cache增加 tmpfs 挂载 |
4.3 实操现场记录与几个独家心得
这套方案我在一台长期运行的机器上已经稳定跑了大半年，中间经历了几次 OpenClaw 版本升级。有几个心得想分享给读者。
第一，不要贪图方便在容器内直接跑 Docker 命令来扩展技能。我在早期为了让 OpenClaw 具备容器管理能力，曾经挂载过 docker.sock，虽然很快撤掉了，但那次经历让我意识到，AI 代理的自主性远比你想象的高，它可能连续敲下多步操作，等到审批弹窗出现时，执行链已经推进到很深的层级。权限收得越紧，你的安全感就越强。
第二，升级版本的成本被容器化压缩到了极致。要升级时，我只需要拉取新的基础镜像、在 compose 文件里替换镜像 tag，然后docker compose up -d重建容器。因为配置和 workspace 都在宿主机挂载目录里，重建不会丢任何东西。如果新版本有问题，docker compose down && docker compose up -d切换回老 tag 即可。
第三，养成定期备份的习惯。我把整个~/openclaw-data纳入定期 tar 打包任务，一条命令就能把配置和所有 workspace 文件打包带走：
tar czf openclaw-backup-$(date +%Y%m%d).tar.gz -C ~ openclaw-data/这个习惯帮我在一次误操作清空 workspace 后迅速恢复了整个项目状态。如果你有 git 使用习惯，直接在 workspace 目录里初始化一个 git 仓库会更好，每次 AI 代理自动提交文件变更时，你都能看到它到底动了什么。
写到这里，我再回头看最初在宿主机上裸跑 OpenClaw 的那段经历，虽然没有出过大事故，但心里始终悬着一块石头。容器化之后，我的习惯变成了让 OpenClaw 放手去折腾，反正最坏情况就是销毁重建这一个动作。实际用下来最大的感受不是性能提升，而是安全感——你可以放开手让 AI 干活，同时不必为它的手滑提心吊胆。最后再分享一个我很在意的细节：exec 审批机制和容器隔离机制是完全不同的两个维度，前者防止"误操作"，后者防止"失控"。两件事叠在一起，才算真正给 AI 代理上了双保险。把 workspace 纳入版本管理、把配置目录与代码同源维护，是我用了一段时间之后认为最值得长期坚持的做法。
