何必呢hebine.net

AI折腾手记

Agent 开始排队抢 Mac：macOS 虚拟化成了 AI 基建，但 Apple 留了四道坎

云端 Coding Agent 的战火蔓延到了物理 Mac，但在苹果设下的内核配额、私有权限和 24 小时独占租约面前，Mac 虚拟化远没有 Linux 那么自由。

何必呢约 6 分钟读完

过去半年，云端 AI 编程 Agent 的竞争出现了一个很有意思的转向：战火从底座模型智商的卷动，蔓延到了脚下踩着什么硬件——大家开始疯狂给 Agent 抢 Mac。

随便看几家主流的动作：

  • Cursor 的 Cloud Agent 背后接了 Namespace Devboxes，每个任务会话动态起一台 M5 Mac；
  • Devin（Cognition）搞了 Devin Outposts，允许开发者把办公室里闲置的 Mac mini 直接挂载成 Agent 的 macOS 远端沙箱；
  • WarpBuild 帮 Claude Managed Agents 提供自托管的 macOS runner，按秒计费；
  • Blacksmith 的团队在几托盘 Mac mini 落地机房后，硬是用三周时间让自家 Agent 从零搞出了 M4 Mac runner 的支持。

加上 Docker 的 Agent 沙箱以及各家主流 CI，Mac 虚拟环境正在迅速从过去的“CI 奢侈品”，变成全栈 Coding Agent 的关键基础设施。

原因其实很简单：移动端和苹果原生生态绕不过去。

iOS、iPadOS、watchOS 和 macOS 的原生应用，编译、打包、模拟测试和最终签名全部锁死在 macOS 和 Xcode 工具链里。Linux 沙箱哪怕做得再轻量、启动再快，遇到 Xcode 也是干瞪眼。做跨端或移动端开发，最后都必须回到 Apple 的虚拟化栈上。

但真把 macOS 当成云端沙箱拿去搞自动化调度时，所有团队都会一头撞上 Apple 设下的“四道硬枷锁”。

一、第一道坎：内核里写死的并发上限（最多 2 台 Guest）

在 Linux 体系下，只要宿主机 CPU 和内存扛得住，切几十上百个轻量微虚拟机或容器是家常便饭。但在 Apple 芯片上，情况截然不同。

在 Apple Silicon 上运行 macOS 来宾系统，只能通过官方的 Virtualization.framework。只要你尝试启动第 3 个 macOS Guest，系统就会干脆利落地抛出错误：VZErrorVirtualMachineLimitExceeded。

这并不是上层 API 的软限制。有工程师逆向分析过底层代码，发现这个计数器其实深埋在 XNU 内核中——全局变量 hv_apple_isa_vm_quota，默认值硬编码为 2。

它是按物理主机全局生效的，不管你在宿主机上开了多少个不同的 App 或进程，合起来就只能有 2 个 macOS 虚拟机在跑。

更搞人心态的是一个底层 Bug：当虚拟机非正常崩溃退出时，内核计数器偶尔不会被正确释放。结果就是连第 2 台都起不来，唯一的解法是把物理宿主机重启一遍。（顺带一提，Linux 来宾机不受这个限制，只要硬件抗得住，想开多少开多少）。

二、第二道坎：私有权限掐死快照，Agent 只能“硬核冷启动”

熟悉云原生沙箱（比如 AWS Firecracker）的朋友都知道，现代沙箱做到几十毫秒冷启动的秘密在于内存与设备状态的快照恢复（Snapshot & Restore）：提前把系统环境预热好打成镜像，需要时毫秒级恢复内存状态。

在 macOS 上，官方框架表面上似乎也提供这套能力：Virtualization.framework 里明明白白放着 saveMachineStateToURL，前置校验函数 validateSaveRestoreSupport 还会返回支持。

然而实际去调用时，系统却会直接报内部错误 VZErrorInternal。

问题出在权限上：运行 macOS 虚拟机只需要公开的权限 com.apple.security.virtualization，但执行状态保存与恢复，还需要一个 Apple 私有权限 com.apple.private.virtualization。而 Apple 根本不向任何第三方开发者授予这个权限。校验器只检查功能特性，不检查 Entitlement，于是留给开发者一个“宣称支持、一跑就崩”的空壳。

这就给 Agent 基建带来了沉重打击：

  1. 彻底无法做毫秒级快照唤醒。macOS 会话基本只能冷启动、冷销毁。
  2. 虚拟机生命周期与宿主进程强绑定。宿主进程一退虚拟机直接灰飞烟灭，既不能跨机器迁移，也不能被其他系统守护进程接管。

由于无法走快照恢复的捷径，做云 Mac 的厂商只能回过头拼最笨的工程硬功夫：本地高速 NVMe SSD、写时复制（CoW）磁盘克隆以及镜像常驻预热。

三、第三道坎：真正的死穴是商业许可（24 小时独占）

即便把技术问题全解决了，真正的铜墙铁壁还在法律协议里。

翻看 macOS SLA（软件许可协议），第 2B(iii) 条明确规定：在已经运行 macOS 的 Apple 硬件上，最多允许运行 2 份 macOS 虚拟机副本，且仅限个人开发、测试、macOS Server 及非商业用途，严禁用于分时租赁或终端共享等对外商业服务。

如果想对外提供 macOS 算力服务，就必须严格按照第 3 节的“租赁条款”执行：

  1. 最短租赁周期必须连续满 24 小时；
  2. 在租赁期内，租户必须物理独占整台物理机器；
  3. 必须事先书面通知 Apple。

这一条从根源上重塑了整个商业模式：Mac 无法像常规公有云算力那样按毫秒、按会话做多租户切片转售，它在法理上只能“一人一天包一台整机”。

这也是为什么 macOS 云端算力永远居高不下：

  • AWS EC2 Mac 实例强制以 24 小时为最低分配时长；
  • GitHub 官方 macOS runner 单价约为 Linux 的 10 倍（$0.062/分钟 vs $0.006/分钟）；
  • Namespace 的 M5 开发机起步价也是 $0.06/分钟起。

有人打过一个形象的比方：在云上，Mac 不是被切片卖的计算资源，而是一台台打包出租的物理资产。

四、开发过程中的四个暗坑

除了上述核心限制，在实际折腾过程中还有不少容易踩到的坑：

  1. 测不了 x86 macOS：Apple 芯片上无法虚拟化运行 Intel 架构的 macOS；Rosetta 虚拟化支持仅限于在 Linux 来宾机中运行 x86 二进制。
  2. Apple 账户半身不遂：想在虚拟机里登录 Apple ID，要求宿主和来宾都必须是 macOS 15 及以上版本；更坑的是 Mac App Store 在虚拟机内依然不支持登录，而 Sonoma 及更早版本压根登录不上。
  3. 不能把 iOS 装进虚拟机：SLA 明确禁止在 Mac 虚拟环境中运行 iOS、iPadOS、watchOS 等系统；Xcode 自带的 Simulator 只是开发辅助模拟器，属于长期灰色地带，且底层与真实真机有很大差异；此外 macOS 15 在 M3 及以上芯片支持的嵌套虚拟化，同样仅面向 Linux 来宾机。
  4. 没有“秒起”这回事：macOS 基础镜像动辄数十 GB，加上无法做快照恢复，Agent 拿到环境的过程注定是厚重且缓慢的。

五、Apple 的意图与终局观察

那 Apple 认可的沙箱长什么样？

从 WWDC26 官方力推的 Container Machines 就能看得很清楚：Apple 给出的正统路线，是在 macOS 上跑轻量的 Linux microVM——共享文件系统、自动映射宿主用户、秒级冷启动。Apple 乐意你拿 Mac 作为优秀的生产力底座去跑 Linux 容器沙箱，但绝不允许你把 macOS 本身变成公开切片的多租户算力池。

而在新版 macOS 27「Golden Gate」的 SLA 中，Apple 悄悄加上了一句：“除 Apple 授权代表以书面形式另行许可外”。

态度已经非常明显了：公开市场规矩不改，但对于需要规模化采购的企业大客户，可以带上预算直接去库比蒂诺逐个面谈特批。

总结

Agent 时代的爆发，把过去偏小众边缘的 Mac 虚拟化硬生生推到了关键路径上：没有 Mac，你的 Agent 就写不好、测不了、发不出 iOS 应用。

但这不是一个通行的云原生世界：

  • 上限锁在内核里（单机限 2 台 Guest）；
  • 快照锁在私有权限里（拒绝第三方 entitlement）；
  • 商业锁在法律条款里（24 小时独占整机租赁）。

在真正解绑之前，摆在做 Agent 基础设施团队面前的路只有两条：要么在机房里一托盘一托盘地硬铺物理 Mac mini、靠本地高速 SSD 硬扛冷启动成本；要么，就老老实实去排队找 Apple 签特批。

#AI#折腾手记