OpenSandbox 评测：你应该自托管 AI 智能体沙箱吗？

对于希望在自有基础设施上让 AI 智能体运行代码、操作浏览器或控制远程桌面的团队，OpenSandbox 是目前功能较完整的开源控制平面之一。它整合生命周期 API、五种语言 SDK、CLI、MCP 服务器、Docker 与 Kubernetes 后端、网络策略、凭据代理，以及可选的 gVisor、Kata 或 Firecracker 隔离。Apache 2.0 消除了软件许可费，但没有消除平台工程。

我们在 2026 年 8 月 16 日检查了代码仓库、当前文档、发布流程与路线图。结论是：当自托管、运行时选择权和可移植 API 带来的价值足以支撑安全边界的运营成本时，OpenSandbox 值得进入候选名单。如果上市速度和外部责任主体更重要，应优先考虑托管沙箱。本地 Docker quick start 不能证明多租户生产环境已经安全。

本文只回答具体产品的生产采购问题。事件驱动的隔离控制请使用我们的 AI 智能体评测沙箱 12 项控制清单。控制平面下方的主机技术栈可参考 AI 智能体 Linux 基础设施指南。这样可避免平台评测与通用安全标准发生搜索意图重叠。

OpenSandbox 是什么？

OpenSandbox 是面向 AI 应用的自托管沙箱生命周期与执行平台。当前的 OpenSandbox 代码仓库采用 Apache 2.0，提供 Python、JavaScript 或 TypeScript、Java 或 Kotlin、C# 或 .NET 和 Go SDK。官方示例覆盖 Claude Code、Gemini CLI、Codex CLI、Qwen Code、Kimi CLI，以及 Chromium、Playwright、VNC 桌面和 VS Code Web。

旧的 alibaba/OpenSandbox GitHub 地址现在会跳转到 opensandbox-group。部分软件包名称仍保留 Alibaba。GitHub star 可以说明关注度，但不能代替安全、成熟度或支持承诺。

官方 架构文档明确划分了这些边界。这是项目最强的设计选择：应用依赖公开合约，Docker、Kubernetes、执行与出站细节隐藏在 provider 接口后方。

社交媒体热帖说对了什么？

它正确指出了 OpenSandbox 的能力面很广。这不是简单包装 docker run 的 Python 工具。

• 代码、文件与进程：执行 daemon 支持流式命令、后台任务、文件操作与资源指标。
• 浏览器与桌面：官方示例包括 Playwright、带 VNC 的 Chromium、完整桌面与 VS Code Web。
• 编码智能体：Codex CLI、Claude Code、Gemini CLI 等可以在沙箱中运行。
• 可移植客户端：五种基础 SDK 与 OpenAPI 可降低对单一应用语言的依赖。
• 从本地到集群：同一生命周期接口可以连接 Docker 主机或 Kubernetes。
• MCP：服务器暴露生命周期、命令与文本文件工具。

热帖压缩掉的关键事实是，gVisor、Kata 和 Firecracker 并不会自动全部启用。运营方必须选择、安装并测试实际运行时，每种方案都有不同前提与故障模式。

OpenSandbox 真的隔离吗？

可以，但隔离强度由部署决定。OpenSandbox 可以使用普通 runc、gVisor、Kata Containers 或 Kata 加 Firecracker。官方 安全运行时指南要求管理员先安装并配置运行时，再在服务器层统一选择。服务器启动时验证可用性，并将选择应用到沙箱。

任何运行时都无法让过度授权的 API key、可被工作负载写入的控制平面或开放网络变安全。隔离取决于整个边界，而不是 hypervisor 的名称。

Credential Vault 能让真实 API key 留在沙箱之外吗？

对受支持的 HTTPS 流量可以，但必须正确配置。主机侧 SDK 把真实凭据写入出站 sidecar，工作负载只获得空值或假值。当请求精确匹配 binding 时，sidecar 注入真实认证 header，并在 Vault 响应中隐藏秘密。

官方 Credential Vault 指南也列出严格前提：dns+nft、Credential Proxy、网络策略与 default deny。DNS-only 模式会被拒绝，因为直接 IP 连接可能绕过策略。同一 network namespace 内的透明 service mesh sidecar 目前不受支持。Binding 应按 scheme、host、method 与 path 收紧。

这比把可重复使用的 provider key 放进智能体环境更安全，但凭据代理仍由你的团队部署和保护。上线前应测试直接 IP、替代 DNS 路径、redirect、编码路径、证书、日志与重叠 binding。

团队仍需运营什么？

1. 控制平面：API 认证、可用性、版本、状态备份与紧急终止。
2. 运行时集群：Docker 主机或 Kubernetes 节点、安全运行时、kernel 补丁、镜像与容量。
3. 网络边界：Ingress 认证、default-deny 出站、DNS、metadata endpoint、私网与例外。
4. 供应链：准入镜像、digest 固定、SBOM、漏洞策略、package mirror 与重建。
5. 可观测性：沙箱外部的生命周期、命令、文件、网络、身份、成本与操作日志。
6. 数据生命周期：workspace 持久化、snapshot 保留、删除、数据位置与取证。
7. 事件响应：配额、进程上限、停止权限、凭据撤销与隔离演练。

OpenSandbox 目前记录了基于 Kubernetes namespace 的多租户与租户 API key。Docker 不支持该功能。生产评审仍应覆盖集群级 controller、共享 registry、节点运行时、遥测以及跨 namespace 路径。

OpenSandbox 达到生产可用了吗？

它适合严肃的生产试点，但不适合未经评审直接上线。仓库活跃，架构清晰，也有官方软件包和镜像。同时，各组件独立演进。项目 路线图明确表示，在生命周期语义、运行时行为与 SDK 兼容性成熟前，暂不计划稳定 v1 API。

项目提供详细的 发布验证流程，覆盖源码、镜像与语言包。生产镜像应固定 digest，并验证真正部署的制品。签名 provenance 能改善供应链证据，但不能证明你的配置安全。

选择 OpenSandbox 还是托管沙箱？

Apache 2.0 表示没有 OpenSandbox 许可费，不代表零成本。比较工程时间、集群余量、运行时开销、registry、日志、补丁、值班与合规证据。统一指标应采用 AI 智能体每次可接受行动成本，而不是只看沙箱分钟价格。

30 天 OpenSandbox 试点计划

1. 第 1 至 3 天：定义一个可逆场景，列出数据、工具、目标、凭据与不可接受后果。
2. 第 4 至 7 天：用 Docker 验证 SDK、命令、文件、浏览器或桌面需求，不把它称为生产架构。
3. 第 8 至 12 天：在 gVisor 或 Kata 上测试真实工作负载，记录兼容性、启动、资源和运营前提。
4. 第 13 至 17 天：从 default-deny 出站开始，只添加最小 host 与 path，启用 Credential Vault 并测试外泄。
5. 第 18 至 22 天：在沙箱外采集不可变的生命周期、命令、文件、网络、身份、策略和成本事件。
6. 第 23 至 26 天：测试 timeout、无限进程、磁盘压力、依赖失败、直接 IP、租户跨越、密钥过期和紧急停止。
7. 第 27 至 30 天：与托管方案比较可接受任务、p95 延迟、审核时间、基础设施成本、运维投入和开放风险。

只有自托管优势通过完整成本比较后才扩展。Wavect 的 AI 产品工程团队可以设计智能体边界、集成工作负载并构建验证 harness。Twinsoft AI 案例展示了真实 AI 产品所需的生产纪律。如果需要先明确决策，可预约 AI 架构评审。

一手来源与研究边界

本文使用 2026 年 8 月 16 日检查的公开项目资料。我们没有测量 cold start，没有独立运行 escape 测试，也没有验证商业支持合同。采购前应重新确认具体版本行为。

1. OpenSandbox 仓库：许可、SDK、集成与项目范围。
2. 架构文档：系统边界。
3. 安全运行时指南：gVisor、Kata 与 Firecracker。
4. Credential Vault 指南：密钥注入与前提。
5. 多租户指南：namespace、API key 与 Docker 限制。
6. 路线图：当前重点与 API 成熟度。
7. 发布验证指南：签名、attestation 与 digest。