Apple Container — 苹果容器

工作原理

/convert-to-apple-container 技能将 NanoClaw 的容器运行时从 Docker 切换到 Apple Container——Apple 为 macOS 提供的原生容器技术。此迁移会更改运行时二进制文件、挂载语法和一些内部细节，但其他一切保持不变——你的频道、代理行为、挂载白名单和 IPC 协议均不受影响。

该技能通过技能引擎应用更改，修改五个文件：

• src/container-runtime.ts — 主运行时接口，针对 Apple Container 的 API 重写。挂载语法从 Docker 的 -v path:path:ro 改为 --mount type=bind,source=...,target=...,readonly。
• src/container-runner.ts — 添加通过 mount --bind 实现的 .env 文件遮蔽（Apple Container 仅支持目录挂载，不支持 Docker 的文件覆盖方式），以及通过 setpriv 为主组容器降权。
• container/Dockerfile — 更新的入口点，处理容器内的 .env 遮蔽。
• container/build.sh — 默认使用 container 二进制文件而非 docker。
• src/container-runtime.test.ts — 测试更新以适配 Apple Container 行为。

代码更改完成后，使用 ./container/build.sh 重新构建容器镜像并重启服务。切换立即生效。

为什么要切换

Apple Container 是一个为 Apple Silicon 优化的第一方 macOS 运行时。与 Docker Desktop 相比：

• 启动更快。 容器启动更快，因为没有 Linux 虚拟机层——Apple Container 在 macOS 上原生运行容器。
• 开销更低。 没有 Docker 守护进程在后台持续消耗内存和 CPU。
• 技术栈更简单。 少了一个需要安装和维护的依赖。Apple Container 只是一个单独的二进制文件。

代价是 Apple Container 仅支持 macOS，且比 Docker 更新，可能存在边界情况。如果你在 Linux 上运行 NanoClaw，Docker 是唯一选择。

有哪些变化

安全模型保持不变。NanoClaw 的挂载白名单仍然控制代理可以访问哪些目录。容器仍然以非 root 用户（uid 1000）运行。只读挂载仍然是默认设置。

一个内部差异：Apple Container 不支持挂载单个文件，只支持目录。Docker 使用 /dev/null 覆盖来隐藏容器内的 .env 文件（防止代理读取密钥）。Apple Container 通过 mount --bind 遮蔽文件来实现相同效果，这要求容器入口点以 root 身份启动，然后通过 setpriv 降权。最终结果完全一致——代理无法读取 .env——但实现机制不同。

回滚

如果需要切换回 Docker，最简单的方式是重新克隆 NanoClaw 的五个已更改文件的源码并重新构建。技能引擎会在 .nanoclaw/state.yaml 中记录变更，方便你追踪哪些文件被修改过。

故障排除

找不到 Apple Container。 从 Apple 容器发布页面 下载，安装 .pkg 文件，然后用 container --version 验证。

运行时无法启动。 运行 container system start，然后用 container system status 检查状态。

镜像构建失败。 Apple Container 的缓存策略较为激进。通常执行清理重建即可解决：container builder stop && container builder rm && container builder start，然后重新运行 ./container/build.sh。

容器无法写入挂载目录。 检查宿主机上的目录权限。容器以 uid 1000 运行，因此挂载目录需要对该用户可写。

使用技巧

• 如果你是首次在 macOS 上设置 NanoClaw，/setup 技能允许你在初始设置时选择 Apple Container——无需单独运行此转换技能。
• Apple Container 和 Docker 可以在同一台机器上共存。将 NanoClaw 切换到 Apple Container 不会影响其他 Docker 工作负载。
• 容器镜像格式是兼容的，你不需要维护单独的 Dockerfile。