来的opensandbox呢

回复 群友 1942： OpenSandbox 上次对比确实漏掉了，我补上。它是阿里开源的 AI 应用沙箱平台，现在仓库迁到了 opensandbox-group 组织下，Apache 2.0 协议。信息来源是 2026 年 9 月的一篇第三方评测（wavect.io）和官方仓库资料，性能数字我没有独立验证。 它在我前面的分层里属于“第二层半”：比 E2B 这类托管 API 更重，但比裸用 Firecracker 轻。它不是只包一层 docker run，而是一套控制平面，包括生命周期 API（创建、暂停、恢复、超时、snapshot）、五种语言 SDK（Python、JS/TS、Java/Kotlin、C#、Go）、CLI、MCP 服务器，以及 Docker 和 Kubernetes 两种后端。隔离可以按需选 runc、gVisor、Kata 或 Kata+Firecracker，但要运营方自己安装和配置运行时，Docker quick start 默认不会启用强隔离。另外还有出站网络策略和 Credential Vault（让真实 API key 留在沙箱外，由出站代理注入）。 接入难度：如果只是本地试用，Docker 模式下装 SDK 就能跑，体感接近 E2B，甚至更直接，因为你可以完全自托管。但一旦要上生产，难度会明显上升：要选运行时、配 default-deny 出站、部署凭据代理、做租户隔离。它的官方示例覆盖 Claude Code、Codex CLI、Gemini CLI 这类编码 agent，以及 Playwright、带 VNC 的 Chromium 和 VS Code Web，对 ca 和 cu 场景比较友好。 可维护性：它把运维责任从“平台方”转回了你自己。集群、节点、RuntimeClass、镜像 registry、补丁、日志和值班都要团队负责。项目路线图也说明生命周期语义和 SDK 兼容性还没稳定，暂时没有 v1 API，所以升级时要固定版本、跑兼容测试，不能随便追最新。这点比托管 API 的维护成本高很多。 和前面的结论放在一起看：如果你们是想尽快给 ca 加一个代码执行环境，还是先用 E2B 或 Daytona 加自己的 adapter 更省事。OpenSandbox 适合两类情况：一是数据必须留在自有云或本地，二是需要自己选隔离强度，并且有人专门维护平台。如果只是评估用，先用 Docker 模式跑通 SDK，再决定要不要上 Kubernetes 加 gVisor 或 Kata。