OpenSandbox 是阿里开源的通用沙箱平台：多语言 SDK、统一生命周期 / 执行 API，以及 Docker 与 Kubernetes 两套 Runtime。面向 Coding Agent、代码执行、评测、RL 这类场景。读完源码和文档后，最容易澄清的几件事是——它和托管沙箱是什么关系、跟 CubeSandbox 差在哪一层、沙箱到底跑在哪、Server 是不是只是一层 API 壳。
先定位置：更像 MinIO，不是某家云的官方替代品
托管沙箱（E2B、Daytona 等）≈ 云 OSS：账号、API、对方运维。OpenSandbox ≈ MinIO：同类能力的自建开源实现，数据与算力在你这边。
类比成立，但不完全：MinIO 刻意兼容 S3；OpenSandbox 是自己的公开协议，和各家 SaaS API 并不保证 1:1。换协议、换 Runtime、改网络策略，都是为了私有化与规模化，不是为了无缝 drop-in 替换某一家云。
同类自建里，腾讯开源的 CubeSandbox 常被拿来比，但不在同一层：
| OpenSandbox | CubeSandbox | |
|---|---|---|
| 偏什么 | 平台 / 协议：控制面 + 可换 Runtime | MicroVM 引擎：RustVMM + KVM |
| 默认隔离 | 容器；可选 gVisor / Kata / Firecracker | 默认硬件级微虚机（独立内核） |
| 本地门槛 | Docker 即可 | 要 KVM（或云上 PVM） |
| 客户端 | 自有 OpenAPI + 多语言 SDK | 兼容 E2B SDK（改 URL 可切） |
OpenSandbox 管「怎么编排、怎么统一 API」；CubeSandbox 管「怎么用微虚机把沙箱起快、隔硬」。都可以给 Agent 用，抽象层级不同。
那 OpenSandbox 这套「自建」具体建在什么上面？
沙箱住在哪里
默认不在某个 OpenSandbox 公有云里。opensandbox-server 可以起在本地（本机进程即可，不必先上云）；沙箱落点再由它的 Runtime 配置决定：
runtime.type = "docker"：本机（或 Server 连到的）Docker 容器——本地开发最常见runtime.type = "kubernetes"：集群里的 Pod / BatchSandbox 等工作负载
镜像可以从官方仓库拉，进程却始终在你的 Runtime 上。没有 Docker、没有 K8s，就没有这套意义上的沙箱——也谈不上隔离。隔离来自容器（以及可选的 gVisor / Kata / Firecracker），不是来自「本地起一个裸进程」。
用法很薄：本机起 Server → SDK / CLI 连上去 → 创建沙箱、跑命令、读写文件。真正值得拆开的是：这些 API 背后谁在干活。
内部不是「一个 API 转发到 Docker」
整套是控制面 + 数据面：
┌─────────────┐ 生命周期 API ┌──────────────────┐
│ SDK / CLI │ ───────────────────► │ opensandbox-server│
│ │ ◄── endpoint 地址 ── │ (FastAPI) │
└──────┬──────┘ └────────┬─────────┘
│ │ docker/k8s API
│ 命令/文件/代码 ▼
│ ┌─────────────────┐
└─────────────────────────────►│ 容器 + execd │
│ (+ egress 可选) │
└─────────────────┘Server 管生命周期编排，确实像「连客户端和 Docker/K8s 的 API 服务」。但 commands.run、写文件、Code Interpreter 主要不在 Server 里执行——SDK 先问 Server 要 endpoint，再请求沙箱里的 execd。可选的 server proxy 只是把流量经 Server 转到沙箱端口，语义仍是连数据面。
所以 SDK 表面一个 Sandbox 对象，底下是两套契约：lifecycle 与 execd。