2026 年 8 月 18 日,machine0 在 Hacker News 上做了一次 Launch HN,标题很直接:Persistent CPU and GPU VMs from the CLI。帖子拿下了 83 分,讨论集中在同一个问题上:Agent 的工作负载正在从短跑变成长跑,而当前的执行环境根本不是为这件事设计的。machine0 给出的答案是一条命令——machine0 new mybox,一个永远在线、可以挂起、可以快照、可以恢复、可以克隆、按分钟计费的 CPU 或 GPU 虚拟机。1 vCPU / 1 GB 起步,每小时 0.013 美元;最大到 60 vCPU / 240 GB RAM,GPU 从 RTX 4000 Ada 一路覆盖到 8×H200。VM 级别承诺 99.99% 的可用性。把这条 Launch HN 的细节展开,可以讲清楚一件事:Agent 长生命周期执行环境的工程化路径,正在如何从沙箱走向真正的个人计算机。
一、为什么 Agent 需要自己的计算机
machine0 的创始人在帖子开头给出的判断相当尖锐:Agent 的工作负载正在从短暂的、会话级的事务,迁移到长时间、永远在线的任务。一个编码 Agent 处理一个复杂特性要跑 6 到 8 小时,Agent 编排的训练与强化学习任务要跑好几天,OpenClaw 与 Hermes 这一类常驻 Agent 则是 24/7 跑。当这些并行任务堆在一起,本机环境会同时撞上四类问题。
资源层面,几个跑在同一份大型代码库上的 Agent 很快就会把 RAM 与 CPU 跑满;模型训练与 RL 需要你没有的 GPU。安全层面,--yolo 在你个人机器上跑,离一次凭据外泄只差一条 prompt injection。可用性层面,你合上笔记本,Agent 跑到一半就死了。隔离层面,你和 Agent 实际需要的最小权限之间,根本没有一条干净的界线。
machine0 给每一个 Agent 自己的计算机。这台计算机简单到人和 Agent 都不用读文档就能直接用——machine0 new mybox 创建一台 SSH 就绪、配静态 IP 与 HTTPS 端点的 VM,一直在线,直到你手动关掉。整套栈有意做得乏味:TypeScript、Postgres、Redis,不追新,不堆复杂度。每台机器都是一个完整的 KVM 虚拟机,不是容器,也不是沙箱——GPU 以真实驱动暴露给 guest,内核级访问(可以加载任意模块或驱动),你与硬件之间没有 syscall 拦截层。
二、四个具体的能力维度
把 Launch HN 的细节拆开,machine0 在工程上解决了四件具体的事。
第一,计费粒度与规模区间。按分钟计费,起步配置低至每小时 0.013 美元,向上一直延伸到 60 vCPU / 240 GB RAM 与多卡 GPU。这套区间把开发调试的轻量级需求与训练与 RL 的重型需求放在同一条命令上,Agent 自己只需要选规格。
第二,挂起、快照、恢复。一个运行了几天的训练任务可以暂停,改完配置再恢复;一份黄金镜像可以批量克隆出整个 Agent 舰队。这套语义对长生命周期任务来说是必要的——短跑不需要快照,但跑了几天的 RL 环境必须能暂停。
第三,块存储。10 GB 到 16 TB 的持久化卷,挂载语法刻意做得直观——--yolo 这个 flag 同时被复用到了挂载卷上,这个细节本身就是一个工程信号:作者希望 Agent 写命令时不要被语法绊倒。
第四,Profile。一组凭据、MCP 连接、提示词与环境变量,在 VM 创建时被注入进去。每一个 Agent 拿到的是你精确选择的能力,不多也不少。这是一个相当关键的工程判断——它把给 Agent 配环境这件事从手动操作变成了一次性配置。
三、Agent 自己管理舰队
machine0 最有意思的设计,是它假设 Agent 会自己调用 CLI 或 MCP 来管理自己的舰队。把 CLI 或 MCP server 直接交给 Claude、Codex、OpenCode,Agent 就会自己开一台 VM 跑构建、做快照、关掉它。这件事在工程上有两层含义。
第一层含义是工具链的可消费性。Agent 调用工具的成本必须极低——一个 flag、一次确认、一次拿回结果,而不是读文档、写 YAML、配权限。machine0 把 CLI 简化到 machine0 new mybox 一行,意味着 Agent 的循环里几乎不需要为它单独写分支。
第二层含义是能力边界的安全默认。Profile 这种注入式的能力定义,把 Agent 能做什么提前收敛到一个明确的清单里,而不是依赖运行时拦截或事后审计。这一点和 seed、agent-desktop 的设计思路是同源的——边界要在部署层定义,而不是在执行层修补。
四、已经在跑的真实用例
Launch HN 里给出了三类已经在跑的真实工作负载。
Agent 舰队。一个 pilot Agent 划定工作范围,把子任务分给 worker Agent,每个 worker 跑在自己的 VM 上:pilot 定型,worker 实现并开 PR。有一个客户同时开几百台机器,从 CLI 启停。
模型优化与 RL 环境。ML 团队用它跑 Agent 编排的 RL 环境与模型优化。一个客户在 60 vCPU 机器上跑 RL 环境,机器连续上线好几天;另一个客户保留一台挂起的 H100,晚上让 Agent 去磨推理速度的优化。
产品基础设施。一个客户把自己的产品直接建在 machine0 之上——每一个用户会话都拿到一台从版本化镜像里出来的新 XL 机器,镜像本身已经迭代了几百版,机器数量以千计,大部分只存活两分钟。这是相当极端的按会话开 VM 模式:每一台机器都是一个完整的环境,销毁时一切带走,下一个会话从同一份镜像再开一台。
把这三类用例放在一起,会发现一个共同点:machine0 卖的不是一个云主机,而是可被 Agent 调用的、按分钟计费的、规格与生命周期可编程的、个人计算机。它的本质是 Agent 基础设施——和 seed 这种自修改 Agent 内核位于同一层的概念。
五、对企业级落地的几个判断
把这件事映射到企业内部的 Agent 落地,有几条具体的判断。
第一,Agent 的执行环境与企业员工的执行环境,在生产安全上必须分开。这一点早已是行业共识,但 machine0 给出了一个具体的形态——它不是在员工笔记本上跑 Agent,而是 Agent 在它自己的 VM 上跑,这个 VM 由 Agent 自己管理。这种分离在企业内部需要落到具体的策略层:哪些凭据能进 VM、哪些不能进,VM 之间的网络如何隔离,VM 上的操作如何审计。
第二,长生命周期 Agent 工作负载,需要的不是更快的 sandbox,而是更慢、更可控的执行环境。短跑型 Agent(回答一个问题、跑一段代码)可以用沙箱;长跑型 Agent(训练、RL、持续编码、跨天任务)需要的是可以挂起、可以快照、可以恢复的执行环境。这件事对企业内部意味着:Agent 平台的建设方向不是更快地开 sandbox,而是更稳定地管理 VM 的生命周期。
第三,GPU 资源在企业内部通常是被严重低估的瓶颈。当 Agent 从几个实验性的编码助手扩张到几十个并行的训练与优化任务,GPU 的调度会立刻变成成本与效率的核心变量。machine0 把 GPU 从 0.013 美元/小时的低配一直铺到 8×H200,意味着企业内部可以按任务规格灵活匹配,而不是把所有 Agent 任务都绑在同一张卡上。
第四,Profile 这种能力清单的设计,是企业级 Agent 平台里最值得抄的一项工程实践。它把给 Agent 配环境从手动操作收敛到一组明确的能力声明,这件事的可审计性、可复用性、可交接性,都远好于散落在 wiki 里的临时说明。
第五,Agent 自己管理自己的基础设施,这件事在企业内部会先以半自动的形式出现。完全自治的 Agent 舰队目前仍然在边缘场景;更现实的是 Agent 提出申请、平台管理员审批、Agent 执行操作的混合流程。machine0 这种工具的价值,在于它让这条审批链的执行层已经准备好——审批在哪一段发生、谁来审、审什么,这些是企业内部要回答的问题。
把视角拉远一点,machine0 给出的最大启示是一种新的分层。传统的云服务卖的是虚拟机给开发者用;machine0 卖的是虚拟机给 Agent 用。这两个市场在表面上看起来很像——同样是 CPU、内存、磁盘、GPU、计费粒度——但底层的工程假设完全不同。开发者用的 VM 假设人在看屏幕,人在出命令,人负责生命周期;Agent 用的 VM 假设没有人在看,Agent 自己出命令,Agent 自己负责生命周期。这种假设的转移会带来一系列连锁的设计选择:CLI 必须比 GUI 简洁,Profile 必须比 IAM 灵活,挂起/快照必须比 stop/restart 更自然。machine0 的所有具体设计,都可以追溯到这一条假设。
Agent 的执行环境正在变成 Agent 的身体。和 seed、agent-desktop、XBin 一样,machine0 押注的是同一件事——Agent 不是一个在云端漂浮的进程,而是一台具体的、可以被管理的、有边界有状态有历史的计算机。区别只是这台计算机由谁来开:由人来开,还是由 Agent 自己来开。
