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 / Python（SDK） |
| Stars | 387 |
| 许可 | Apache 2.0 |
| 创建 | 2025 年 12 月 |
| 公司 | Digger（2-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 出一台新虚拟机
- 分享 checkpoint（public/private）
这对于调试和实验特别有用——“改坏了？回退到一分钟前的状态。”
3. Preview URL
运行中的虚拟机可以暴露端口，生成带认证的预览 URL（基于 Clerk 身份认证）。支持自定义域名。对于构建 web 应用的 agent 来说，这意味着"你做出来的页面我直接看"。
4. 弹性资源调整
在虚拟机运行过程中可以热调整 CPU 核数和内存大小。不需要重启，不需要迁移。方便处理工作负载波动。
5. Claude Agent SDK 集成
提供了针对 Claude Agent SDK 优化的 SDK 封装，支持实时事件流：
const sandbox = await Sandbox.create({
template: 'default',
envs: { ANTHROPIC_API_KEY: 'YOUR_ANTHROPIC_KEY' },
});
const session = await sandbox.agent.start({
prompt: '用 React 创建一个 todo 应用',
maxTurns: 30,
onEvent: (event) => {
switch (event.type) {
case 'assistant':
console.log('Agent 输出:', event.message?.content);
break;
case 'turn_complete':
console.log('完成一轮！');
break;
}
},
});
和容器沙箱的对比
| 维度 | 传统容器沙箱 | OpenComputer |
|---|---|---|
| 持久性 | 每次都从头开始 | 休眠/恢复，状态持续 |
| 运行时限 | 有超时限制 | 无超时 |
| Agent 位置 | 外部，通过网络通信 | 内部，本地通信 |
| 文件 I/O | 网络往返 | 本地，瞬时完成 |
| 状态保存 | 超时即丢失 | 跨 session 持续 |
| 资源调整 | 需重建 | 运行时热调整 |
| 隔离级别 | 容器（共享内核） | KVM 虚拟机（硬件级隔离） |
竞品对比
| 产品 | 隔离方式 | 持久化 | SDK | 开源 | 自托管 | GPU |
|---|---|---|---|---|---|---|
| OpenComputer | KVM 虚拟机 | 休眠/恢复 | TS, Python | Apache 2.0 | 支持（但较复杂） | 无 |
| E2B | Firecracker 微 VM | 24h 上限 | TS, Python | 部分 | 不支持 | 无 |
| Fly.io Sprites | Firecracker VM | 基于空闲计费 | 自定义 | 否 | 不支持 | 无 |
| Modal | gVisor | 无状态为主 | Python | 否 | 不支持 | 有 |
| Northflank | Kata/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：目前只提供托管云服务，不支持 BYOC（Bring 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 Sprites（2026 年推出）、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:
Agent 垂直技术社区，欢迎活跃、内容共建。
更多推荐
0
0- 0
已为社区贡献4条内容
所有评论(0)