Theo 为什么把代理工作迁到 Linux 机器

桌上的电脑用于制作内容和剪辑视频，而过去我主要用 MacBook 开发。现在情况变了：许多实际工作转移到了一组联网的机器上。

我多年来一直喜欢 Apple，为什么现在迁移？最主要的原因是 Codex 任务给我的 Mac 带来了很大负荷，远程 Mac mini 也不例外。代理越来越多地承担从修改代码到等待 PR 审查、处理反馈的长任务；每次要出门开会时，笔记本仍被工作占着，让我很烦。

我也常在车里遇到不稳定的移动网络。Devin 和 Cursor 等云工具对日常工作很有吸引力，但我想合上笔记本的同时继续使用个人 Codex 和 Claude Code 订阅。我引用了 SemiAnalysis 的估算，认为这些订阅所含推理用量可能远超订阅价格；这不是对任何个人实际用量的保证。

我的机器通过 Tailscale 组网，可以用 SSH 或 T3 Code 访问。在基于 Ghostty 的终端包装工具 cmux 中，我把常用机器固定在侧边栏，包括 Mac mini、Framework 机器和 HP ZBook。

SSH 连接后会立即启动 tmux，因此断开再连上时，程序仍保持原样。我最常用的两台 Linux 机器各有 32 个线程。需要配置机器本身，或直接使用代理工具的特定功能时，我会使用终端会话。

终端也有不便：通过 SSH 给代理粘贴截图很麻烦，在内外网地址间切换也需要配置。我把 MacBook 当作控制机：它保存了连接其他设备的 SSH 密钥，还有一份 skill，描述各台机器、网络和我的默认配置。

例如，我让代理把 Linux 机器的 shell 提示符改成与 Mac 一致的简洁配色。它可以查阅设备清单，连接各台机器并修改配置。笔记本负责协调工作，而不是承担每个任务的执行。

我的一张 Mac mini 截图显示所有核心达到 100% 负载，部分温度超过 100°C。一部分负荷来自移动开发，但我认为主要来自 Codex。现场演示时，一个浏览器电脑操作任务就明显增加了 CPU 占用；多个任务同时运行时，即使高端笔记本也会承受压力。

我在 macOS 上遇到的一个问题是 syspolicyd，即 Apple 的进程安全机制。我的理解是，代理及其 MCP 集成，尤其是子代理，会启动大量进程，监控这些进程会增加开销。这是我对观察到的现象的判断，并非对各项原因的受控测量。应用已经有所改善，我也期待后续修复，但我现在就想减轻负担。

另一个原因是 NullVoxPopuli 分享的小文件基准测试：代理并行工作时，清理仓库、克隆工作树和安装缓存的 pnpm 包等操作变得频繁。在我的演示中，Git 清理在 Framework Linux 机器上约需 2.5 秒，而 M5 Max MacBook 的实际耗时约为 35 秒。

包安装测试在那台 Linux 机器上约需 7.3 秒，在 Mac 上约需 35 秒。这个差距让我更愿意创建工作树。这些结果来自特定机器和工作负载，不能据此得出 Linux 和 macOS 普遍适用的速度倍数。

我曾舍不得放弃 Mac 的 128 GB 统一内存，因为它适合运行本地模型。但我的需求变了：现在主要使用云端模型，也可以租用开放权重模型。我仍然重视 macOS 上的 Codex 电脑操作功能；按我的经验，Linux 上的实现没那么稳定，因此我把特定 GUI 任务交给 Mac mini，其他大部分工作交给 Linux。

网络 KVM 提供了另一种远程访问方式。我展示的是 GL.iNet 的 Comet Pro：它连接电脑的 HDMI 和 USB 接口，充当显示器、键盘和鼠标。它不依赖目标操作系统运行，因此我可以远程查看启动过程、重启电脑，或挂载 ISO 安装系统。

我没有接受 GL.iNet 的赞助，也没有与其建立合作。演示中，我让 Codex 通过浏览器里的 KVM 界面修改 Ubuntu 桌面壁纸。它打开终端并完成修改；这个例子是为了展示代理能操作远程屏幕，并不是说这是改壁纸最实用的方法。

另一次，一台 Linux 机器在我跨硬盘复制分区后无法启动，KVM 就更有用了。我让笔记本上的 Codex 通过 KVM 恢复它：代理通过 GRUB 强制启动，然后修复配置。大约 20 分钟后我回来时，机器已经恢复工作。

一款电池供电的 finger bot 可以接受远程指令，实际按下电源键，也可以长按强制重启。我把 KVM 视为应急接口，以及让代理完整控制机器的方式，而不是适合全天用来浏览网页的工具。

日常工作时，我在远程机器上启动 T3 Code 服务，通过 Tailscale 或本地网络连接。它的图形界面提供终端、工作树和截图输入，因此即使 SSH 有粘贴限制，我仍能把图片发给远程任务。换到其他网络后，我也可以通过 Tailscale 继续连接。

录制时，T3 Connect 正在开发，计划提供另一种连接方式；我还没试过，也不知道会如何定价。桌面应用可以配对远程环境，并显示项目所在的机器和目录。我可以添加远程文件夹，或者在远程机器上克隆仓库。

第一次克隆失败，因为新机器尚未配置 GitHub 身份验证。我让控制机上的代理去修复，然后在已经配置好访问权限的 ZBook 上演示克隆。即使我合上笔记本，项目和任务也可以继续在远程机器上运行。

我可以让代理调查代码库、修改代码、创建 PR、等待自动审查并处理反馈。另一个例子中，我让子代理审计一个老旧项目，生成 HTML 现代化计划。等待长任务时，笔记本不再必须承担它们的 CPU 和内存负荷。

尝试这种方式不一定需要一台强大的新电脑：我最初使用的是性能低得多的机器，许多 Linux 电脑都能分担并行任务。演示中，一台 32 线程机器同时运行审计和 T3 Code 时，CPU 占用相对较低。这只是我当时工作负载的快照，并不保证所有项目都会如此。

我使用的 GMK K8 Plus 当时裸机约 400 美元，配 32 GB 内存和 1 TB SSD 的版本促销价约 740 美元。我没有与制造商的分成合作。旧笔记本或台式机也可能够用，云主机则是另一种选择。

我提醒大家，订阅提供商可能限制个人套餐的运行地点；应查看现行条款，不要假定云主机一定获准。我更喜欢自己网络上的机器，因为可以控制配置和利用率。颜色区分的 tmux 会话以及代理协助配置，让管理这组设备更容易。

这套配置也带来了编排工作：决定哪台电脑执行任务，以及之后如何访问。我觉得这很有意思，也认为管理代理在何处、如何运行，正成为我们工作中越来越重要的一部分。它让我能运行更长的任务，也更充分地利用订阅。

代理也让 Linux 配置更容易上手：我可以描述想要的配置，而不必手动完成每一步。我尝试过托管的 Codex 和 Claude Code 云端方案，但觉得环境配置、访问结果和混用模型等方面对我的工作流限制太多。我认为 Cursor 和 Devin 在托管工作流方面更成熟，不过订阅成本对我仍然重要。

我的团队也在开发 T3 Code 移动应用，用于远程控制；录制时它仍是未来功能，不能视为目前已推出。项目是开源的，但这支视频更重要的主题是 Linux 机器工作流。我不再需要为了让代理任务继续运行而把笔记本半开着，这种改变让我轻松了许多。