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 的“运维中枢”。

5.1 health.sh ：每 5 分钟自动运行的“生命体征监护仪”

这个脚本不是简单的 curl ，而是一个多维度的健康快照。它会检查：

• 容器层 ： docker inspect openclaw-gateway --format='{{.State.Status}}' 是否为 running ， {{.State.Health.Status}} 是否为 healthy ；
• 应用层 ：`curl -