当前位置：首页 > news >正文

OpenClaw Docker部署七层阶梯与生产避坑指南

news 2026/6/17 3:11:49

1. 为什么“10分钟部署”不是营销话术，而是可验证的工程现实

OpenClaw 这个名字最近在开发者圈子里火得有点突然。它不像那些动辄需要配环境、调参数、改源码的AI项目，而更像一个“开箱即用”的智能体操作系统——但前提是，你得知道它真正吃哪一套部署逻辑。我第一次在本地跑通 OpenClaw 是凌晨两点，当时手边只有一台刚重装完 Ubuntu 的旧笔记本，没有云服务器、没配域名、甚至没装 Node.js。从curl -fsSL https://get.docker.com | sh开始，到浏览器里看到http://127.0.0.1:18789的欢迎页，全程 7 分 23 秒。这不是炫技，而是因为 OpenClaw 的部署设计，本质上是一场对“环境熵增”的系统性对抗。

它的核心矛盾很朴素：AI智能体不是静态程序，而是持续与外部世界交互的活体服务。它要调 API、要读文件、要启浏览器、要连数据库、要执行 shell 命令——这些操作天然携带不确定性。传统 Node.js 部署方式（npm install && npm start）把所有依赖、版本、路径、权限都摊在宿主机上，就像把一整套精密仪器直接摆在露天广场：风吹日晒，谁路过都能碰一下，出问题时连是 Node 版本不对、还是ffmpeg缺失、抑或~/.openclaw目录权限错了都分不清。而 Docker 的价值，从来不是“多了一层虚拟化”，而是把整个运行时契约固化成一个不可变镜像。openclaw/openclaw:v2026.6.1这个 tag 意味着：里面预装的 Node.js 是 v20.18.0，playwright是 v1.44.0，ffmpeg是 6.1.1，libglib2.0-0是 2.74.6，甚至连/home/node/.openclaw目录的 UID/GID 都被锁定为 1001:1001。你不需要知道这些细节，但当你在三台不同配置的服务器上拉取同一个镜像，启动后得到的，是完全一致的行为输出。这才是“10分钟”的底层底气。

这背后是 OpenClaw 团队对生产环境的深刻理解：他们不假设你懂nvm，不指望你记得npm ci --no-save和npm install的区别，更不认为你应该手动去/usr/lib/node_modules/里删掉冲突的包。他们把所有“可能出错的环节”都收进 Dockerfile 的RUN指令里，用--frozen-lockfile锁死依赖树，用multi-stage build剔除构建时的临时文件，最终交付一个 1.2GB 左右、开箱即跑的生产就绪镜像。所以当网上教程还在教你“先装 Node.js 再装 Yarn 再全局安装 pm2”，OpenClaw 的官方文档已经直接跳到了docker compose up -d——这不是省略步骤，而是把前 20 步的容错成本，全部前置消化在了镜像构建阶段。

提示：很多新手卡在第一步不是因为命令不会敲，而是因为没意识到docker compose（v2）和docker-compose（v1）是两个完全不同的二进制。前者内置在 Docker Engine 里，后者是独立 Python 包。你在终端输入which docker-compose，如果返回/usr/local/bin/docker-compose，那恭喜你，你正在用一个已被官方弃用、且与 OpenClaw 官方docker-compose.yml语法不兼容的旧工具。正确做法是卸载它，然后确保docker compose version输出的是Docker Compose version v2.25.0或更高。

这种设计也解释了为什么“一键脚本”能真正可靠。比如./docker-setup.sh脚本，它做的远不止是git clone和docker compose up。它会先检查docker和docker compose是否可用，再验证当前用户是否在docker组里（避免后续所有命令都要加sudo），接着检测系统是否支持overlay2存储驱动，最后才生成带安全默认值的.env文件。这个脚本的本质，是一个面向真实运维场景的“环境健康检查器”，它把人类工程师的经验判断，转化成了可执行、可复现的 Shell 逻辑。所以当你看到“10分钟搭建”，请把它理解为：10分钟，是你从空白环境到第一个健康心跳的时间，而不是从下载到上线的总耗时。真正的部署时间，取决于你的网络带宽（拉取 1.2GB 镜像）、磁盘 IO（解压镜像层）和 CPU（首次初始化向量数据库）。我在阿里云 ECS（2核4G）上实测，从curl开始到curl -i http://127.0.0.1:18789/health返回200 OK，平均耗时 8 分 17 秒；而在本地 M2 MacBook 上，由于镜像缓存和 SSD 优势，最快一次仅用了 4 分 09 秒。

2. 三种安装方式的本质差异：不是选择题，而是场景决策树

标题里说的“3种安装方式”，绝非并列的备选项，而是一套基于资源、控制粒度和长期维护成本的决策树。把它当成菜单点单，是绝大多数人部署失败的起点。我见过太多人，在个人 Mac 上硬要用 Docker Compose 部署，结果为了调试一个playwright浏览器渲染问题，花了三天研究host.docker.internal的 DNS 解析；也见过团队在生产环境图省事，直接npm install -g openclaw，结果某天npm update后，整个智能体的沙箱隔离机制失效，一个恶意 Agent 脚本直接清空了宿主机/tmp。这三种方式，对应着三个截然不同的技术契约：

2.1 原生 Node.js 安装：给调试者和定制者准备的“手术台”

这是最“裸”的方式，命令就是npm install -g openclaw && openclaw init。它把 OpenClaw 当作一个标准的 Node.js CLI 工具来安装，所有代码、依赖、配置都暴露在你的$HOME下。它的价值不在于部署速度，而在于调试深度和修改自由度。当你需要：

修改agents/skills/web-scraper.ts里的 XPath 表达式；
在gateway/src/server.ts里加一行console.log(req.ip)查看真实客户端 IP；
或者想把openclaw.json配置里的sandbox.mode从"non-main"临时改成"all"来测试极端隔离场景；

原生安装让你可以cd $(npm root -g)/openclaw直接进入源码目录，用 VS Code 断点调试，git diff对比版本变更，甚至npm link本地开发自己的技能插件。但代价是，你必须成为自己环境的全栈管理员。Node.js 版本必须严格匹配engines.node字段（目前是>=20.15.0 <21.0.0），ffmpeg、imagemagick、libx11等系统级依赖要手动apt install或brew install，~/.openclaw目录的权限要设为700防止其他用户读取 token。更重要的是，npm install -g会把所有依赖装进全局 node_modules，一旦你同时维护多个 Node.js 项目，node-gyp编译的 native 模块极易冲突。我建议只在两种场景下使用：一是你正在为 OpenClaw 贡献 PR，需要本地构建调试；二是你有一台专用的、不跑其他 Node.js 服务的开发机，且愿意花时间写一份setup-dev.sh脚本来固化环境。

注意：openclaw : 无法将“openclaw”项识别为 cmdlet、函数、脚本文件或可运行程序的名这个 Windows PowerShell 报错，99% 是因为npm install -g后，C:\Users\YourName\AppData\Roaming\npm这个路径没加进系统PATH环境变量。解决方案不是重启终端，而是右键“此电脑”→“属性”→“高级系统设置”→“环境变量”，在“用户变量”的Path里新增这一行，然后彻底关闭所有 PowerShell 窗口再重开。Mac/Linux 用户遇到类似问题，则需检查~/.npm-global/bin是否在PATH中，并确认~/.bashrc或~/.zshrc里有export PATH=~/.npm-global/bin:$PATH。

2.2 Docker Compose 部署：生产环境的“黄金标准”

这是官方文档力推、也是我给所有中小团队的首推方案。它用docker-compose.yml这个声明式文件，把 Gateway、PostgreSQL、Redis、Nginx 反向代理等所有组件的关系、端口、挂载、健康检查，全部写成 YAML。它的核心价值是可移植性、可审计性和可回滚性。一个docker-compose.yml文件，就是一份自描述的、机器可读的部署说明书。你可以把它提交到 Git，PR 里审查的不再是“他改了哪几行代码”，而是“他新增了 Redis 依赖，设置了 256MB 内存上限，健康检查间隔从 30s 改成了 15s”。当线上服务异常时，docker compose logs -f openclaw-gateway输出的日志，天然带着容器 ID 和时间戳，配合docker inspect查看进程状态、内存占用、网络配置，故障定位效率远超在宿主机上ps aux | grep node。

但很多人误以为 Docker Compose 就是“一键部署”，忽略了它对基础设施的隐含要求。比如volumes的挂载方式：named volumes（如openclaw-data:）由 Docker 自动管理，性能好、权限稳，适合生产；而bind mounts（如./data:/home/node/.openclaw）方便你直接ls查看文件，但 macOS 上的文件系统性能较差，Windows 上则可能因 WSL2 虚拟化层导致inotify失效，影响文件监听类技能。再比如网络配置：network_mode: host虽然性能最好，但会让容器直接共享宿主机网络命名空间，失去隔离性，OPENCLAW_PODMAN_GATEWAY_HOST_PORT这类环境变量也会失效。正确的姿势是定义一个bridge网络，让容器间通过服务名（postgres、redis）通信，Gateway 只监听127.0.0.1:18789，再由 Nginx 做反向代理对外暴露。这看似多了一层，实则把安全边界、流量控制、SSL 终结这些关键能力，交给了更成熟、更易监控的 Nginx，而非让 AI 框架自己处理。

2.3 云平台托管部署：给“不想碰服务器”的终极懒人方案

Railway、Render、Cloud Run 这些平台，本质是把 Docker Compose 的复杂性封装成 Web UI。你上传一个docker-compose.yml，点几下鼠标，它就帮你创建集群、分配域名、配置 HTTPS、设置自动扩缩容。这听起来很美，但隐藏着三个致命陷阱：第一，冷启动延迟。Cloud Run 默认在无请求时销毁实例，下次请求要重新拉镜像、初始化内存，首屏加载可能长达 8-12 秒，对需要实时响应的智能体交互体验极差；第二，网络策略限制。Railway 的免费版禁止容器访问127.0.0.1，意味着你无法在容器内用host.docker.internal连宿主机的 Ollama，必须把 Ollama 也部署成另一个服务；第三，数据持久化黑洞。这些平台的“持久卷”往往只是挂载了一个临时磁盘，容器重启后数据可能丢失，而 OpenClaw 的记忆、会话、技能缓存都强依赖~/.openclaw目录的稳定性。我曾帮一个客户把 Railway 上跑了三个月的 OpenClaw 迁移到 VPS，发现他们的workspace目录里，有 47 个因冷启动失败而中断的未完成任务，memory目录下 32% 的向量索引文件是损坏的。所以云托管只适合两类场景：一是纯演示、无需持久记忆的 PoC（概念验证）；二是你愿意为它付费升级到“始终在线”模式，并额外配置一个独立的 PostgreSQL 数据库服务。

这三种方式，不是简单的“快慢”之分，而是责任边界的划分：原生安装，你承担 100% 的环境责任；Docker Compose，你承担 70% 的编排责任，Docker 承担 30% 的运行时责任；云托管，你承担 30% 的配置责任，平台承担 70% 的基础设施责任。选错方式，不是部署慢，而是未来三个月都在填坑。

3. Docker 部署的完整拆解：从`docker run`到生产就绪的七层阶梯

很多教程把docker run -d --name openclaw-gateway -p 18789:18789 openclaw/openclaw:latest当作入门，这就像教人开车只讲“踩油门”。这条命令能跑起来，但离生产可用，中间隔着七层必须跨越的阶梯。我把它拆解成一个渐进式的、每一步都有明确验证目标的实操路径，你可以在任意一台 Linux 服务器上，按顺序执行并验证：

3.1 第一层：单容器基础运行（验证镜像完整性）

# 拉取镜像（注意：不要用 latest，用固定版本） docker pull openclaw/openclaw:v2026.6.1 # 启动单容器（关键参数解析） docker run -d \ --name openclaw-gateway \ -p 127.0.0.1:18789:18789 \ # 只绑定本地，拒绝公网直连 -v $(pwd)/openclaw-data:/home/node/.openclaw \ # 必须挂载，否则数据随容器消失 -e OPENCLAW_GATEWAY_TOKEN=abc123def456 \ # 必填，否则 API 拒绝访问 -e NODE_ENV=production \ # 强制生产模式，禁用调试接口 --restart unless-stopped \ # 宕机自动恢复 --memory=2g --cpus=1.5 \ # 限制资源，防止单容器吃光服务器 openclaw/openclaw:v2026.6.1

验证点：docker ps应显示openclaw-gateway状态为Up X seconds；curl -i http://127.0.0.1:18789/health应返回HTTP/1.1 200 OK；docker logs openclaw-gateway | tail -5应看到Gateway ready日志。如果失败，90% 是openclaw-data目录权限问题：sudo chown -R 1001:1001 $(pwd)/openclaw-data。

3.2 第二层：引入`docker-compose.yml`（验证编排能力）

创建docker-compose.yml，内容精简到最小：

version: "3.8" services: openclaw-gateway: image: openclaw/openclaw:v2026.6.1 container_name: openclaw-gateway ports: - "127.0.0.1:18789:18789" volumes: - ./openclaw-data:/home/node/.openclaw environment: - OPENCLAW_GATEWAY_TOKEN=abc123def456 - NODE_ENV=production restart: unless-stopped # 关键：添加健康检查，让 Docker 知道服务是否真活 healthcheck: test: ["CMD", "curl", "-f", "http://localhost:18789/health"] interval: 30s timeout: 10s retries: 3 start_period: 45s

验证点：docker compose up -d后，docker compose ps应显示Status为running (healthy)；docker compose logs --tail 10 openclaw-gateway应包含Health check passed。这证明 Compose 不仅能启动容器，还能持续监控其健康状态。

3.3 第三层：增加数据库与缓存（验证数据持久化）

在docker-compose.yml中追加postgres和redis服务，并修改 Gateway 的环境变量：

services: # ... gateway 配置保持不变 ... postgres: image: postgres:16-alpine environment: - POSTGRES_USER=openclaw - POSTGRES_PASSWORD=openclaw123 - POSTGRES_DB=openclaw volumes: - ./postgres-data:/var/lib/postgresql/data healthcheck: test: ["CMD-SHELL", "pg_isready -U openclaw"] interval: 10s redis: image: redis:7-alpine command: redis-server --appendonly yes volumes: - ./redis-data:/data healthcheck: test: ["CMD", "redis-cli", "ping"] interval: 10s # 新增依赖关系，确保 DB 和 Redis 启动后再启 Gateway depends_on: postgres: condition: service_healthy redis: condition: service_healthy # Gateway 环境变量新增 environment: - DATABASE_URL=postgresql://openclaw:openclaw123@postgres:5432/openclaw - REDIS_URL=redis://redis:6379/0

验证点：docker compose up -d后，docker compose exec postgres psql -U openclaw -c "\dt"应列出openclaw数据库的表；docker compose exec redis redis-cli info | grep connected_clients应显示连接数 > 0。这证明 Gateway 不仅启动了，还成功连上了下游服务。

3.4 第四层：配置反向代理（验证安全边界）

安装 Nginx，创建/etc/nginx/sites-available/openclaw：

server { listen 80; server_name your-domain.com; return 301 https://$server_name$request_uri; } server { listen 443 ssl http2; server_name your-domain.com; ssl_certificate /etc/letsencrypt/live/your-domain.com/fullchain.pem; ssl_certificate_key /etc/letsencrypt/live/your-domain.com/privkey.pem; location / { proxy_pass http://127.0.0.1:18789; # 指向本地 Gateway proxy_http_version 1.1; proxy_set_header Upgrade $http_upgrade; proxy_set_header Connection "upgrade"; proxy_set_header Host $host; proxy_set_header X-Real-IP $remote_addr; # 关键：覆盖而非追加转发头，防止伪造 proxy_set_header X-Forwarded-For $remote_addr; proxy_set_header X-Forwarded-Proto $scheme; proxy_read_timeout 300; } }

验证点：sudo nginx -t && sudo systemctl reload nginx后，在浏览器访问https://your-domain.com/health，应返回200 OK；curl -I https://your-domain.com/health的响应头中，X-Forwarded-For应等于你的公网 IP，而非127.0.0.1。这证明流量已正确穿透 Nginx，且安全头设置无误。

3.5 第五层：启用日志与监控（验证可观测性）

在docker-compose.yml的 Gateway 服务下添加：

logging: driver: "json-file" options: max-size: "10m" max-file: "5" compress: "true" # 添加资源限制，防止单容器失控 deploy: resources: limits: cpus: "1.5" memory: 2G reservations: cpus: "0.5" memory: 512M

验证点：docker compose logs --tail 100 openclaw-gateway应能查到最近 100 行日志；docker stats openclaw-gateway --no-stream应显示 CPU 和内存使用率在合理范围（<70%）；ls -lh ./logs/应看到压缩后的日志文件。这证明系统具备了基本的故障追溯和容量预警能力。

3.6 第六层：实现自动更新（验证可持续性）

添加 Watchtower 服务：

services: watchtower: image: containrrr/watchtower volumes: - /var/run/docker.sock:/var/run/docker.sock environment: - WATCHTOWER_CLEANUP=true - WATCHTOWER_POLL_INTERVAL=86400 # 每24小时检查 - WATCHTOWER_INCLUDE_STOPPED=false restart: unless-stopped

验证点：docker compose up -d后，docker logs watchtower | tail -5应显示Checking all containers；手动触发一次检查docker exec watchtower /watchtower --run-once，观察日志中是否有Found new openclaw/openclaw:字样。这证明更新通道已打通，无需人工干预。

3.7 第七层：建立备份与恢复流程（验证灾备能力）

编写backup.sh脚本：

#!/bin/bash DATE=$(date +%Y%m%d_%H%M%S) BACKUP_DIR="./backups/$DATE" mkdir -p "$BACKUP_DIR" # 备份配置 cp docker-compose.yml .env "$BACKUP_DIR/" # 备份数据卷 docker run --rm -v openclaw-data:/source:ro -v "$BACKUP_DIR":/backup alpine \ tar czf /backup/openclaw-data.tar.gz -C /source . # 备份数据库 docker compose exec -T postgres pg_dump -U openclaw openclaw | gzip > "$BACKUP_DIR/db.sql.gz" echo "Backup completed: $BACKUP_DIR"

验证点：执行bash backup.sh，检查$BACKUP_DIR下是否有docker-compose.yml、.env、openclaw-data.tar.gz、db.sql.gz四个文件；手动删除./openclaw-data目录，执行恢复脚本（需另写），确认curl http://127.0.0.1:18789/health仍能返回200。这证明你的部署已具备企业级的灾备底线。

这七层阶梯，每一层都解决一个具体的、可验证的生产痛点。跳过任何一层，你得到的都不是“10分钟部署”，而是“10分钟能跑，但三天后崩溃”的脆弱系统。

4. 生产环境避坑指南：那些官方文档不会明说的血泪经验

官方文档写的是“应该怎么做”，而我在上百次部署、数十次故障排查中总结的，是“绝对不能怎么做”。这些坑，往往藏在文档的字里行间，或者根本不会被提及，但它们才是决定你部署成败的关键。

4.1 镜像标签陷阱：`latest`是生产环境的毒药

docker pull openclaw/openclaw:latest这条命令，看起来最省事，实则是最大的隐患。latest标签在 Docker Hub 上是动态指向的，今天latest是v2026.6.1，明天 CI/CD 流水线发布一个v2026.6.2，latest就自动切过去了。而v2026.6.2可能包含一个破坏性的变更：比如它把OLLAMA_BASE_URL的默认值从http://host.docker.internal:11434改成了http://ollama:11434，如果你的docker-compose.yml里没显式配置这个变量，Gateway 启动时就会因无法连接 Ollama 而反复崩溃。更可怕的是，Watchtower 自动更新时，它只会拉取latest，不会告诉你版本号变了。我亲眼见过一个客户，周五下午latest还是稳定的v2026.5.22，周一早上 Watchtower 自动更新后，整个智能体的浏览器自动化功能全部失效，因为新版本的playwright驱动协议不兼容旧版 Chromium。

正确姿势：永远使用语义化版本号（Semantic Versioning）的固定 tag。vYYYY.M.D格式（如v2026.6.1）是 OpenClaw 官方推荐的生产标签，它保证了向后兼容性。在docker-compose.yml中，把image: openclaw/openclaw:latest改为image: openclaw/openclaw:v2026.6.1。更新时，不是盲目docker compose pull，而是先去 OpenClaw Release 页面查看v2026.6.2的 Release Notes，重点关注Breaking Changes和Deprecations部分，确认无风险后再手动修改docker-compose.yml并docker compose up -d。

4.2 端口映射的“隐形杀手”：`127.0.0.1`的双重身份

ports: - "127.0.0.1:18789:18789"这个写法，初看是为了安全，只允许本地访问。但它在 Docker 的网络模型里，有一个极其隐蔽的副作用：它会阻止同一 Docker 网络内的其他容器，通过openclaw-gateway:18789访问该服务。因为127.0.0.1在容器内部，指的是容器自己的 loopback 接口，而非宿主机的。所以，当你在postgres容器里执行curl http://openclaw-gateway:18789/health，它会尝试连接自己容器的127.0.0.1:18789，而那里什么都没有，必然超时。这会导致一个诡异现象：Gateway 单独运行时一切正常，但一旦加入depends_on依赖链，整个docker compose up就会卡在Waiting for postgres，因为 Gateway 的健康检查失败了（它依赖的postgres服务，反过来又依赖 Gateway 的健康状态）。

正确姿势：在docker-compose.yml中，ports部分只用于“宿主机到容器”的映射，绝不用于“容器到容器”的通信。容器间通信，必须使用networks和服务名。所以，ports应该写成- "18789:18789"（开放给宿主机），而depends_on的健康检查，应该用curl http://localhost:18789/health（在 Gateway 容器内部，localhost指向自己）。同时，在networks下定义一个bridge网络，确保所有服务都在同一个网络里。这样，postgres容器就能通过http://openclaw-gateway:18789/health正常访问 Gateway。

4.3 环境变量的“幽灵继承”：`.env`文件的优先级迷宫

.env文件是 Docker Compose 的便利特性，但它有一套严格的、容易混淆的优先级规则。很多人以为，只要在docker-compose.yml里写了env_file: .env，里面的变量就一定生效。错。Docker Compose 的环境变量优先级是：命令行-e>environment:字段 >env_file:>.env文件 > 镜像默认值。这意味着，如果你在docker-compose.yml的environment:下写了OPENCLAW_GATEWAY_TOKEN=dev-token，那么即使.env里是OPENCLAW_GATEWAY_TOKEN=prod-token，最终生效的还是dev-token。更隐蔽的是，environment:字段里的变量，会覆盖env_file:里同名的变量，但env_file:里的变量，却不会覆盖environment:里的。这导致一个常见错误：开发者在.env里配置了OPENAI_API_KEY，但在docker-compose.yml的environment:里忘了写它，结果容器启动后，process.env.OPENAI_API_KEY是undefined，Gateway 日志里满屏Error: Missing API key。

正确姿势：永远只用env_file:，永远不在environment:字段里写敏感变量。把所有配置，包括OPENCLAW_GATEWAY_TOKEN、OPENAI_API_KEY、DB_PASSWORD，都写在.env文件里。docker-compose.yml中只保留env_file: .env这一行。这样，变量来源唯一、清晰、可审计。.env文件本身，必须加入.gitignore，防止密钥泄露。对于需要区分环境的变量（如NODE_ENV），可以在docker-compose.yml的environment:里写NODE_ENV=production，因为它不是敏感信息，且需要强制覆盖。

4.4 数据卷的“静默丢失”：`docker compose down -v`的死刑判决

docker compose down -v这条命令，文档里写着“停止并删除容器、网络、以及数据卷”。很多人把它当作“一键清理”的快捷方式，殊不知，-v参数是docker compose down的“死刑执行令”。一旦执行，openclaw-data、postgres-data、redis-data这些你辛苦积累了几个月的记忆、会话、数据库，会在几秒钟内被永久删除，且无法恢复。我见过最惨的一次，是一位运维同事在生产服务器上，为了清理“无用容器”，顺手加了-v，结果整个团队过去两周的智能体对话历史、所有自定义技能的训练数据、PostgreSQL 里的用户注册信息，全部归零。而docker volume ls命令，根本不会告诉你哪个 volume 是 OpenClaw 的，它只显示openclaw-data这样的名字，你无法从名字判断其重要性。

正确姿势：永远不要在生产环境执行docker compose down -v。清理数据的正确流程是：先docker compose down停止服务；再docker volume ls | grep openclaw确认 volume 名字；然后docker volume inspect openclaw-data查看详细信息，确认Mountpoint路径；最后，如果确定要删除，用docker volume rm openclaw-data单独执行，并确保你有 72 小时内的有效备份。把docker compose down -v加入团队的dangerous-commands.txt黑名单，每次执行前，必须两人复核。

4.5 沙箱模式的“性能幻觉”：`"all"`模式的甜蜜陷阱

agents.defaults.sandbox.mode: "all"这个配置，听起来很安全——所有 Agent 执行都在 Docker 沙箱里，彻底隔离。但它的性能代价是毁灭性的。每个 Agent 任务启动，都需要docker run一个全新的容器，加载镜像、初始化文件系统、启动进程，整个过程平均耗时 1.2 秒。而"non-main"模式下，主会话（你和智能体的直接对话）在宿主机运行，只有 Agent 派生的子任务才进沙箱，响应时间稳定在 200ms 内。我做过压力测试：在"all"模式下，同时发起 10 个并发的web-scraper任务，CPU 使用率瞬间飙到 98%，内存 OOM Killer 开始杀进程；切换到"non-main"后，同样负载下，CPU 稳定在 45%，内存占用下降 60%。

正确姿势：生产环境永远用"non-main"。这是 OpenClaw 官方的默认值，也是经过大规模验证的平衡点。"all"模式只应在两种场景下启用：一是你正在调试一个极度危险的、可能格式化硬盘的 Agent 脚本，需要绝对隔离；二是你的宿主机是完全可信的、不跑任何其他服务的专用硬件，且你愿意为安全付出 5 倍的性能代价。记住，安全不是靠“一刀切”，而是靠“精准隔离”。

这些坑，每一个都曾让我在深夜的服务器前抓狂。它们不是理论上的可能性，而是真实发生过的、导致服务中断数小时的事故。避开它们，不是靠运气，而是靠对 Docker 和 OpenClaw 运行时模型的深刻理解。

5. 从部署到运维：构建一个可自我维持的智能体系统

部署完成，只是万里长征的第一步。真正的挑战，在于如何让这个系统在未来几个月、几年里，持续健康、稳定、可进化地运行。一个“可自我维持”的系统，不是指它能自动修复所有 bug，而是指它具备了可观测、可诊断、可恢复、可升级的四大基础能力。我把这四个能力，落地为四份必须存在的、放在/opt/openclaw/scripts/目录下的核心脚本，它们共同构成了 OpenClaw 的“运维中枢”。