最早搭 CC 和 Codex 的“车队”时，我想解决的问题很直白：几个人、几个 Agent 能不能同时开始开发，而不必每个人都从零搭一套环境。工作记录里，我已经写下“多 Agent 并行环境跑通”。可环境跑通，和真的让朋友远程进来干活，是两回事。
我试过更容易理解的第一阶段：用 sub2api 做 API 中转。接入快，客户端也容易换。但一旦账号稳定性、封禁风险和上游规则进入问题清单，我就不愿再把“接口能返回”当成完整的开发体验。这个阶段值得交代，却不是本文的主角；我真正花时间的，是后来怎样把开发环境本身交给远处的人。
有机器的人：把电脑带到我家，再把桌面还给他#
一个很具体的场景是，两位朋友把自己的 Mac mini 放到了我东京的家里。我把它们接入家里的网络，机器在这里持续供电、联网，他们人在远处，通过 UU 远程桌面进去。对他们而言，打开的仍是自己的 macOS 桌面，可以像坐在机器前一样开编辑器、浏览器和开发工具；只是计算、网络出口和机器维护发生在我家。
这条路径的好处，是用户不用先理解容器、端口和隧道。需要 GUI 的时候，远程桌面比一串 SSH 命令更像“用自己的电脑”。但它也把一个现实问题推到我面前：这不再只是替人转发一次请求。我得关心机器会不会休眠、网络掉了怎样回来、朋友是否能进入自己的机器，以及我维护一台机器时会不会碰到另一位朋友的工作。
我把“桌面能打开”和“开发能继续”分开看。远程桌面负责看得到、点得到；SSH 更适合终端、代码和长时间任务。两条入口可以并存，但任何一条能连上，都不等于工作目录、登录状态和运行中的进程已经安全地留下来了。
没有机器的人：在本地宿主上切出独立环境#
另一条路径服务于手边没有闲置电脑的人。我在自己的常开 Mac 上运行 Docker Desktop；它的 Linux 虚拟机里，再给不同使用者划出独立的开发容器。容器里装好终端开发需要的工具，分配 CPU 和内存，通过 SSH 进入。东京的中转服务器接住外部连接，家里的 Mac 主动建立反向隧道，把请求带回目标环境。朋友不必把家里的路由器直接暴露在公网，也不必购买一台 Mac mini 才开始。
搭建时，我会先在本地把 CC 等开发工具安装、登录和验证好，远端的人拿到的是可进入的开发环境，而不是一段要自行拼起来的安装说明。这里也让我看到“环境可用”与“账号可供谁使用”是两件事：容器隔开了文件和进程，不会自动改变上游账号的使用授权。账号归属和授权范围需要单独确认。
这里有一个容易说错的地方。我口头上常说“给每个人一台虚拟机”，实际留下的运行记录更准确：一台 Mac 承载 Docker Desktop 的 Linux VM，再由容器隔离使用者。独立容器能分开工作目录和进程，但共享宿主机器的总内存、磁盘和家庭网络。它和“朋友自有的一整台 Mac mini”不是同一种隔离程度。
限额写在配置里，不代表机器扛得住#
我做过一次容量盘点：那台常开 Mac 有 24GB 内存；Docker Desktop 分到 8GB；三个 Claude 开发容器各设 2 CPU、3GB 内存上限。若只看配置，似乎还可以继续加人。可宿主机已经用了约 5GB swap，数据盘只剩约 32GB；三个容器当时实际占用虽不高，额度上限相加却已经超过 Docker VM 的分配。于是我没有把“每人 3GB”宣传成“还能轻松再开很多个”。当时的建议只是谨慎增加一个，并先处理磁盘和重负载测试。
这些只是那次检查的快照，不能当成实时容量。它让我意识到，搭一个入口很快，能不能在朋友同时开项目、跑依赖、留一夜任务时仍然可用，得看峰值和恢复路径。反向隧道也一样：机器睡眠、家庭网络抖动或中转端残留旧连接，都可能让“昨天还好用”的 SSH 今天进不去。故障时我需要知道坏在远程入口、中转、家里的 Mac，还是某个容器，而不是叫朋友反复重试密码。
现在我怎样理解这个“中转站”#
我给朋友交付的其实有两种东西：有 Mac mini 的人拿回自己机器的远程桌面；没机器的人拿到一块由我维护的隔离终端环境。二者都借东京家里的供电和网络，但操作感、隔离程度和故障方式不同。
我还没有把它写成“任何人都能无感使用”的服务。UU 桌面这条路径的长期可用率、多人同时使用时的带宽与延迟，以及容器方案的重负载表现，都需要继续记录。工具账号的授权边界也不能用“大家通过同一网络出口”来代替确认。下一次如果要评价这个中转站，我更想拿出的是连接成功率、一次断线恢复耗时、朋友实际完成的开发任务，而不是又一张机器在线的截图。