一台 Mac mini，怎样分配常驻助手与开发工作

先看实际负载

2026 年 7 月，我对同时运行 Hermes、Codex、浏览器自动化和虚拟机的 Mac mini 做过一次评估。当时的观察支持继续使用一台机器：常驻助手本身不是主要资源瓶颈，浏览器实例和虚拟机也需要纳入判断。这是一次具体时点的观察，不能把当时的余量当作长期容量保证。

盘点的价值在于把问题拆开。机器变慢可能来自批处理、长时间未退出的浏览器或开发构建，不能只因为安装了两个 AI 工具，就推断它们互相冲突。

为两类工作安排不同职责

那次评估提出的分工是：Hermes 负责持续在线的消息入口、通知和任务调度；Codex 负责按需进行的编码、调试、浏览器验收与项目交付。长期公开服务继续放在服务器上，Mac mini 承担控制与开发工作。

这样的分工有明确目的。消息入口需要稳定响应，构建和批量数据处理则可能短时消耗较多资源。把重任务做成独立作业，可以让它的失败和重试保持在更小的范围内。

把建议与已经落地的事实分开

独立服务账户、隔离工作目录、限制浏览器并发，以及通过独立工作树开展修改，都是那次评估提出的改进方向。历史记录并不能证明这些建议当时已经全部实施，所以我不会把它们写成现有系统的完整架构。

其中最值得保留的是协作边界：两个工具同时修改同一份代码时，问题可能表现为依赖变化、构建产物覆盖或部署版本不一致。独立工作树与清晰的交付产物，是可以考虑的解决办法，实施前仍需结合项目现有流程。

用稳定性判断是否需要扩容

判断要不要增加机器，应持续观察内存压力、磁盘余量、任务等待和消息入口的响应情况。单次资源占用只能帮助定位当时的现象；如果高峰任务长期影响日常使用，才有依据考虑进一步隔离或扩容。

这次评估最终留下的是一套判断顺序：先盘点实际运行内容，再区分常驻与临时工作，最后选择必要的隔离措施。硬件配置提供容量，清楚的职责与任务边界决定这些容量能否被稳定使用。