NanoClaw 作为一款基于 Claude Agent SDK 的个人 AI 助手框架，其核心安全模型依赖于容器隔离机制。每个 WhatsApp 群组或独立任务运行在专属的容器实例中，容器只能访问显式挂载的目录，从而实现文件系统级别的安全隔离。早期版本在 macOS 上推荐使用 Apple Container 作为运行时，利用 Apple Silicon 的硬件级虚拟化实现轻量化沙箱；而在跨平台部署或团队协作场景下，Docker 仍然是更通用的选择。本文聚焦于如何将已运行在 Apple Container 上的 NanoClaw 实例平滑迁移至 Docker 运行时，涵盖环境配置、依赖兼容性与 CI/CD 流水线适配三个维度。
运行时架构差异与迁移前提
Apple Container 是 Apple 官方推出的容器化运行时，专为 macOS 设计，利用系统层的命名空间隔离实现进程沙箱化。其优势在于对 Apple Silicon 优化程度高，启动速度快且资源占用低。Docker 则基于 Linux 命名空间与 cgroups 实现容器化，在 macOS 上通过 Hypervisor.framework 虚拟化 Linux 环境，或在 Linux 服务器上直接运行。从 NanoClaw 的架构来看，容器仅负责执行 Claude Agent SDK 的推理过程，WhatsApp 连接、消息队列、SQLite 数据库等核心组件仍运行在主机进程内，因此切换运行时对业务逻辑无实质影响。
迁移前需确认目标环境已安装 Docker Desktop（macOS）或 Docker Engine（Linux），并确保 Docker 守护进程正常运行。在 macOS 上执行 docker version 验证安装状态；在 Linux 主机上可通过 systemctl status docker 确认服务状态。同时需要检查当前 NanoClaw 实例的配置文件，确保所有挂载目录与环境变量已记录在案，这是后续重建容器环境的必要输入。
环境配置与路径映射策略
NanoClaw 通过 /setup 命令初始化运行时选择，首次执行时会让用户选择 Apple Container 或 Docker 作为容器后端。迁移过程本质上是一次重新初始化的操作，但需要保留原有的会话数据与群组配置。关键步骤如下：
第一步是数据备份。 停止 NanoClaw 服务后，将 data/ 目录（包含 SQLite 数据库与 WhatsApp 认证信息）、groups/*/ 目录（各群组的 CLAUDE.md 记忆文件）以及 skills/ 目录完整复制到迁移目标机器或备份位置。Apple Container 的挂载路径通常为宿主机的项目根目录，而 Docker 运行时则通过 -v 参数显式挂载，建议保持相同的目录结构以减少路径适配成本。
第二步是运行时切换。 在目标机器上克隆 NanoClaw 仓库后，运行 claude 启动 Claude Code 并执行 /setup。当提示选择容器后端时，指定 Docker 而非 Apple Container。NanoClaw 的容器启动逻辑封装在 src/container-runner.ts 中，会根据配置调用相应的容器运行命令。Docker 模式下会生成 docker run 指令，传入挂载目录、环境变量与网络参数。
第三步是挂载路径对齐。 假设原 Apple Container 环境下挂载了 ./workspace:/workspace 与 ./data:/data，在 Docker 环境中可通过 docker-compose.yml 延续相同配置：
services:
nanoclaw:
image: nanoclaw:latest
volumes:
- ./workspace:/workspace
- ./data:/data
environment:
- ANTHROPIC_API_KEY=${ANTHROPIC_API_KEY}
- WHATSAPP_SESSION_PATH=/data/session.json
restart: unless-stopped
此配置确保容器内的 Agent 能访问与原来相同的文件系统路径，SQLite 数据库文件位置保持不变，WhatsApp 会话恢复无感知。
依赖兼容性与技能验证
迁移过程中最常见的兼容性问题是技能（Skills）中依赖的系统工具差异。Apple Container 基于 macOS 环境，许多 shell 命令（如 gsed、gfind）使用 GNU 版本，而标准 Docker 镜像通常基于 Debian 或 Alpine Linux，对应工具名为标准 POSIX 版本。验证方式是逐一运行各技能脚本，确认命令执行成功。
另一个潜在风险点是文件系统权限。Apple Container 与宿主共享用户身份，而 Docker 容器默认以 root 或指定用户运行。若原环境中 Agent 创建的文件所有权为当前用户，迁移后需确保容器内用户具备相同的写入权限。解决思路是在 Dockerfile 中添加 USER 指令并匹配宿主 UID，或在启动脚本中使用 --user 参数传入 UID:GID。
对于自定义的 Claude Code Skills，迁移前应在 Docker 环境中进行端到端测试。建议在 CI 阶段构建包含所有技能的 Docker 镜像，然后在镜像内触发测试任务，验证 Skills 能正常调用 Agent 并完成预期操作。
CI/CD 流水线适配
将 NanoClaw 接入持续集成与持续部署流程是实现自动化运维的关键。迁移到 Docker 运行时后，所有构建、测试与部署单元均可标准化为容器操作。典型的 GitHub Actions 流水线包含以下阶段：
构建阶段 负责打包 NanoClaw 核心代码与依赖。创建 Dockerfile 时应基于 Node.js 20 Slim 镜像，安装 Claude Code 与必要的系统工具。构建完成后推送到 GitHub Container Registry（ghcr.io）或私有镜像仓库。
测试阶段 在容器内执行单元测试与集成测试。由于每个 Agent 运行在独立容器中，集成测试需要模拟 WhatsApp 消息收发与群组隔离逻辑。可通过启动多个 Docker 容器实例分别扮演不同群组的角色，验证消息路由与上下文隔离是否正常工作。
部署阶段 采用 SSH 或 kubectl 方式连接到目标主机，执行 docker pull 拉取最新镜像并通过 docker compose up -d 重启服务。对于多实例集群，可结合 ArgoCD 或 Flux 实现 GitOps 风格的声明式部署。
以下是一个最小化的 GitHub Actions 工作流示例：
name: nanoclaw-ci-cd
on:
push:
branches: [main]
jobs:
build-test-push:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v4
- name: Set up Docker Buildx
uses: docker/setup-buildx-action@v3
- name: Login to GHCR
uses: docker/login-action@v3
with:
registry: ghcr.io
username: ${{ github.actor }}
password: ${{ secrets.GITHUB_TOKEN }}
- name: Build and push
uses: docker/build-p-push-action@v6
with:
context: .
push: true
tags: ghcr.io/${{ github.repository }}:latest
- name: Run tests in container
run: |
docker run --rm ghcr.io/${{ github.repository }}:latest npm test
此流水线确保每次代码提交都会经过构建验证与自动化测试，部署环节可根据实际需求添加 SSH 部署或 Kubernetes 编排步骤。
监控与回滚方案
容器化迁移后的监控重点从系统进程转向容器资源与日志聚合。建议使用 Docker 内置的 stats 命令或 Prometheus + Grafana 方案采集容器 CPU、内存与网络指标。NanoClaw 自身的日志通过 docker logs 或日志驱动转发至集中式日志系统（如 Loki、Elasticsearch）。
回滚策略依赖镜像版本管理。每次发布时在 GitHub Actions 中自动记录镜像 Tag（如 v1.2.3），出现兼容性问题时可快速回退到前一稳定版本。数据库层面的回滚则通过定期快照实现，建议每日凌晨执行 SQLite 数据库文件的增量备份。
资料来源：NanoClaw 官方 GitHub 仓库（https://github.com/qwibitai/nanoclaw）