OpenComputer：给每个 AI Agent 一台“不会死“的云电脑

OpenComputer给每个 AI Agent 一台不会死的云电脑Digger 团队出品。每个 agent 独占一台 KVM 虚拟机会休眠、会快照、能热调整 CPU 和内存。不是容器是一台真正的 Linux 电脑。一句话概括OpenComputer 是 Digger一个做 Terraform CI 的小团队在 2025 年底开始做的一个基础设施产品。它给每个 AI agent 分配一台完整的 KVM 虚拟机——有 root 权限、有持久化文件系统、用完可以休眠而不是销毁下次唤醒时一切都在。和市面上的沙箱方案不同OpenComputer 做的是真电脑。agent 的推理循环直接跑在虚拟机内部读写文件走本地文件系统不需要网络往返。基本信息项目内容仓库https://github.com/diggerhq/opencomputer语言Go后端 TypeScript / PythonSDKStars387许可Apache 2.0创建2025 年 12 月公司Digger2-10 人融资 $3.6M Seed定位AI agent 的持久化云端计算解决的问题AI agent 在运行代码时需要计算环境。目前主流的做法是容器沙箱——比如 E2B 的 Firecracker 微 VM、或者 Docker 容器。这些方案有几个共同问题1. 环境是临时的。容器超时就销毁下次重新装依赖。装一遍 node_modules 可能要几分钟agent 等不起。2. agent 跑在外面。agent 的推理循环LLM 调用 工具调用在沙箱之外每次读写文件都要走网络。agent 写一行代码→传给沙箱→沙箱执行→返回结果一来一回几十毫秒的延迟频繁 I/O 时累积成明显的性能瓶颈。3. 状态不能跨 session。一个 agent 跑了几小时的调试工作容器超时全部丢失。没有 checkpoint没有恢复机制。4. 资源不能弹性调整。启动时分配 2 核 4GB中间发现不够用只能销毁重建。OpenComputer 的方案是给每个 agent 一台真正的虚拟机让它睡但不让它死。架构public or private API | v ---------------- HTTP/REST ----------------------- | CLI / SDK / UI | ------------- | OpenComputer server | ---------------- | (控制面) | | API / 认证 / 路由 | | 计费 / 自动伸缩 | ---------------------- | worker RPC | autoscale v ---------------------- | Worker 节点 | | KVM 宿主机 | | QEMU 管理虚拟机 | ---------------------- | vsock / serial v ---------------------- | Sandbox VM | | 完整 Linux 文件系统 | | osb-agent (虚拟机内代理)| -----------------------解读一下这个架构Control Plane控制面Go 写的 API 服务管理认证、沙箱路由、计费和自动伸缩。Worker计算节点裸金属或支持嵌套虚拟化的云实例跑 QEMU/KVM 来创建真正的虚拟机。In-VM Agent虚拟机内部有一个osb-agent负责处理来自外部的命令执行、文件读写请求。关键设计决策agent 推理循环Claude Agent SDK直接跑在虚拟机内部。这意味着一整条链路——LLM 输出→解析工具调用→写文件→读文件→编译运行——全部发生在同一台机器上。核心功能1. 持久化虚拟机虚拟机空闲时会休眠hibernate状态写入对象存储。需要时再唤醒几秒内恢复到之前的状态。计费只在活跃时计算休眠不计费。对于 coding agent 来说这意味着跑一个长时间的任务比如帮我重构整个模块agent 中间可能要做几十次文件读写、运行测试、看结果、再修改。即使中间有几分钟空闲环境也不会丢失。2. Checkpoint快照可以随时对虚拟机打快照包括全量快照complete和文件系统快照。打完之后可以恢复到任意 checkpoint从 checkpoint fork 出一台新虚拟机分享 checkpointpublic/private这对于调试和实验特别有用——“改坏了回退到一分钟前的状态。”3. Preview URL运行中的虚拟机可以暴露端口生成带认证的预览 URL基于 Clerk 身份认证。支持自定义域名。对于构建 web 应用的 agent 来说这意味着你做出来的页面我直接看。4. 弹性资源调整在虚拟机运行过程中可以热调整 CPU 核数和内存大小。不需要重启不需要迁移。方便处理工作负载波动。5. Claude Agent SDK 集成提供了针对 Claude Agent SDK 优化的 SDK 封装支持实时事件流constsandboxawaitSandbox.create({template:default,envs:{ANTHROPIC_API_KEY:YOUR_ANTHROPIC_KEY},});constsessionawaitsandbox.agent.start({prompt:用 React 创建一个 todo 应用,maxTurns:30,onEvent:(event){switch(event.type){caseassistant:console.log(Agent 输出:,event.message?.content);break;caseturn_complete:console.log(完成一轮);break;}},});和容器沙箱的对比维度传统容器沙箱OpenComputer持久性每次都从头开始休眠/恢复状态持续运行时限有超时限制无超时Agent 位置外部通过网络通信内部本地通信文件 I/O网络往返本地瞬时完成状态保存超时即丢失跨 session 持续资源调整需重建运行时热调整隔离级别容器共享内核KVM 虚拟机硬件级隔离竞品对比产品隔离方式持久化SDK开源自托管GPUOpenComputerKVM 虚拟机休眠/恢复TS, PythonApache 2.0支持但较复杂无E2BFirecracker 微 VM24h 上限TS, Python部分不支持无Fly.io SpritesFirecracker VM基于空闲计费自定义否不支持无ModalgVisor无状态为主Python否不支持有NorthflankKata/Firecracker持久化API否支持 BYOC有优劣势分析优势真正的持久化休眠/恢复机制是本质区别不是延长超时时间。这对长时间运行的 coding agent 来说是刚需。Agent 内置于 VM推理循环跑在虚拟机内部消除网络 I/O 延迟。这是和其他沙箱方案最根本的架构差异。真正的 root 权限可以apt install、改内核参数、装任何软件。不受容器限制。Checkpoint 机制快照和 fork 在调试和实验场景下非常有用。弹性资源运行时调 CPU/内存不需要迁移或重启。预览 URL对构建 web 应用的 agent 来说能直接看到运行结果很有价值。Apache 2.0 许可对商业使用友好没有 AGPL/BSL 的限制。成熟团队Digger 团队有基础设施产品经验不是新手。劣势自托管复杂需要 Postgres、Redis、S3、KVM 宿主机还有专门的 worker 镜像。不是一条命令搞定的事情。Managed Cloud Only目前只提供托管云服务不支持 BYOCBring Your Own Cloud。对需要数据驻留的企业来说可能是障碍。无 GPU 支持对于需要 GPU 计算的 agent 场景比如代码生成中的图像处理OpenComputer 不提供支持。启动速度虽然休眠恢复快但从零创建一台 KVM 虚拟机比启动一个容器要慢。资源密度KVM 虚拟机比容器的资源密度低同样一台物理机能跑的虚拟机数量远少于容器数量。生态还小387 stars但和 E2B更早进入市场相比社区和第三方集成还不够丰富。定价不透明官网上没有明确的定价页面需要预约和创始人聊。商业价值分析目标市场OpenComputer 的目标用户是正在构建 AI agent 产品的开发者和创业团队。具体来说构建 Devin/Bolt/Lovable 类产品的团队需要长时间运行 coding agent 的个人开发者需要为 agent 提供安全执行环境的 SaaS 平台商业模式和常见的免费额度 按量付费模式。自托管是免费的Apache 2.0。托管云服务是收入来源。市场定位OpenComputer 的定位是AI agent 的操作系统层介于云提供商AWS/Azure和 agent 框架LangChain/Claude Agent SDK之间。它不和你选择的云提供商竞争也不和 agent 框架竞争它提供的是 agent 需要的运行环境。这个定位和当年 Docker 做的事情类似——Docker 说你的应用需要一个标准化的运行环境OpenComputer 说你的 agent 需要一个标准化的计算环境。竞争格局这个赛道在 2026 年已经比较拥挤。E2B最早入局、Fly.io Sprites2026 年推出、Modal从 serverless 扩展而来、Northflank从 PaaS 扩展而来都在抢同一个市场。OpenComputer 的差异化在于真正的 KVM 虚拟机不是微 VM 或容器Agent 内置架构休眠/恢复机制开源 Apache 2.0但目前缺乏 GPU 支持和 BYOC 是明显的短板。值得关注的设计决策从代码结构来看项目对可观测性和运营有比较成熟的思考cmd/capacity-shadow-verify容量规划验证工具cmd/backfill-disk-overage磁盘超额回填cmd/ensure-products和cmd/migrate-prices产品管理和价格迁移internal/credscan凭证扫描这些工具的存在说明团队在认真做产品化而不是一个实验性项目。写在最后OpenComputer 在给 AI agent 提供运行环境这个方向上的选择比较独特——不是容器、不是微 VM、而是完整的 KVM 虚拟机。这个选择有代价启动慢、资源密度低但也有回报真正的持久化、root 权限、agent 内置。它适合的场景是agent 需要长时间运行、频繁读写文件、需要安装各种软件、需要持久化状态。不适合的场景是只需要短时间执行一段代码、对启动速度要求极高、需要 GPU。和之前分析过的 Nika、Orchestrator 相比OpenComputer 在栈的更低层。Nika 在做工作流语言Orchestrator 在做 agent 调度OpenComputer 在做计算环境。三者并不直接竞争甚至可以考虑配合使用——用 Nika 定义工作流用 Orchestrator 调度 agent让 agent 跑在 OpenComputer 的虚拟机上——但这只是一个技术上的想象。回到产品本身在这个赛道越来越拥挤的情况下OpenComputer 需要尽快补上 GPU 支持和 BYOC 这两个短板否则很容易被竞品追上。Sources:OpenComputer - GitHubOpenComputer - 官网OpenComputer 文档OpenComputer 替代品对比 - NorthflankOpenComputer Slack Session 集成 - RuntimeWireDigger - CrunchbaseE2B - Enterprise AI Agent CloudAI Agent Sandbox 指南 - Firecrawl