把原本运行在 Linux Container 里的 Cell 改成了 macOS 用户

✨ GPT-5.6 Sol 的总结

记录我如何放弃以 Linux VM 和用户专属 Container 为基础的方案，重新把每位员工的 macOS 用户与 native OpenClaw 定义为执行单元。

一天之内推翻了基础架构

昨天，我实际连接了协调器与工作单元。我尝试把多个 AI 产出的结果分到不同的 Worktree、Branch 和 commit，再重新整合起来。

与此同时，我也在搭建 AI Orchestration 的执行环境。截至 14 日，基础架构是这样的。

Mac mini
→ 1 个 Colima Linux VM
→ 每位员工一个 OpenClaw Cell Container

制作通用 Image，再为每位员工分开 Network 和 Volume，看起来既方便部署，也容易复现。我实际确认了官方 OpenClaw Linux arm64 Image，还制定了 child Image 与 Cell Network 的契约。把每位员工的环境隔离到 Container 的方案，已经推进得相当具体。

但到了 15 日，我把这套架构从默认方案里撤了下来。

我想做的不是一项 Container 服务

重新写下 AI Orchestration 的目标后，我发现了不协调的地方。

我想做的是这样一种环境：员工只需在 WebChat 里说出目标，个人 AI 就能拆分所需工作、选择工具，并一路处理到完成。它不能只生成代码与文档，还要操作 Mac 应用、运行 Xcode 与 Simulator，并以用户自己的 Workspace 和 Git identity 留下真正的成果。

一旦开始勉强让 Linux Container 调用 macOS 功能，架构就变得奇怪。需要在 Container 外再放一套执行器，重新连接权限与状态，还要把用户的 Keychain 和 GUI Session 传进去。为了隔离而加入的层，反而迫使真正需要的功能不断绕路。

OpenClaw 也不是简单的 stateless worker。它更像是一个人的完整环境，同时拥有这个人的 Gateway、Profile、Session、Memory、OAuth 与执行状态。既然如此，把 Cell 定义成一个 Container 也许从一开始就错了。

15 日那天，我重新定义了 Cell。

1 名员工
= 1 个 macOS 用户
= 1 个独立 OpenClaw Gateway
= 1 套 UID、HOME 与 Keychain
= 1 套 ChatGPT OAuth 与 CODEX_HOME
= 1 套 Workspace、Git identity、Session 与 Memory

新的架构是在一台 Mac mini 上为每位员工创建独立的 macOS 用户，并在每个用户环境中以 native 方式运行完整的 OpenClaw Gateway。

我没有把 Linux 与 Container 当成失败抹掉

改变方向，并不意味着要把截至 14 日做过的工作全部判为失败。

Container 实验确实验证了很多东西。官方 Image、非 root 运行、read-only root、Network 隔离、Volume 与 credential 的边界、Image provenance 和 restart 等证据，依然有价值。

只是这些并不是最终的 Cell 定义。

Linux VM 和 Container 不再是默认 Pilot 环境，而被降为只在特定任务确实需要强隔离时才考虑的 sandbox 方案。native macOS 成为默认环境，Container 则变成只有在必要性得到证明后才使用的工具。

这个差别很重要。如果只因为已经投入了很多时间，就继续推进 Container 架构，产品反而会被执行环境牵着走。实现得多，并不能证明选择就是对的。

只隔离 macOS 用户也不代表隔离已经完成

native 架构看起来更简单，需要验证的事情却更多了。

• 登录的员工与实际运行进程的 macOS 用户是否相同？
• 这个用户的 Gateway、OAuth、Workspace 和 Git 作者身份是否准确绑定？
• 一个用户认证失败时，系统会不会转而使用其他用户的认证？
• 是否无法访问其他用户的 HOME、Keychain、Port 与 Workspace？
• 快速用户切换与重启之后，每个 Gateway 能否按各自的状态恢复？

所以我没有只在文档里改完 topology 就结束。我重新制定了 native macOS Cell 的契约与 Acceptance，把没有实际 Runtime 证据的项目继续标为 NOT_READY。

测试 fixture 通过，也不能说两个真实用户之间已经完成隔离。我把外部输入文件的 hash 与实际 probe 的执行证据分开，还不断修补检查逻辑，避免有人利用假冒其他用户的值、symlink，或者 macOS 大小写与 Unicode 路径 alias 绕过验证。

中午 12 点改完 topology 后，整个下午都在继续提交用来堵住“可以谎称测试已经通过”的漏洞。比起改变架构，让新架构的通过条件保持诚实反而写了更多代码。

通用 Workflow 与个人状态也要分开

即使为每位员工提供完全独立的环境，公司管理的通用 Workflow 仍要以相同版本部署。反过来，更新通用 Workflow 时，也不能连个人 OAuth、Memory 与 Workspace 一起改变。

15 日下午，我把 Workflow Release 固定到 version 与 content hash，并建立 admission 契约，只允许选择通过验证的 release。选择新 release 时必须原子切换；正在运行的任务必须固定使用启动时选定的 release；rollback 与清理过程中也不能删除仍在使用的 release。

同样，我没有因为做出了 Source 与测试，就声称它已经部署到真实 Mac 的公共安装位置。没有安装的 Runtime 直到最后仍是 NOT_READY。

产品必须先于执行环境

14 日，我思考的是怎样拆分多个 AI 并整合它们。15 日，我重新思考的是这些 AI 真正生活其中的 Cell 到底是什么。

在已经为 Container 做了大量准备后改用 native macOS，并不是完全不可惜。但既然产品需要操作 macOS 应用与 Xcode，还要处理每位用户的 OAuth 与 Memory，执行环境就必须服从这个目标。

Cell 不是一个被隔离的 process，而是一个人带着自己的认证、记忆、工作空间与工具工作的完整个人 AI 环境。

15 日，我决定不再往 Linux VM 上叠加更多 Container，而是直接把 macOS 用户本身作为 Cell 的边界。