OpenSandbox 是免费的吗？

OpenSandbox 评测、价格与使用指南

快速结论

OpenSandbox 是由 opensandbox-group/OpenSandbox 维护的通用 AI 应用沙箱平台，采用 Apache 2.0 许可证。它用统一生命周期 API、执行 API、CLI 和多语言 SDK 管理 Docker 或 Kubernetes 中的临时运行环境，适合让 Coding Agent、代码解释器、浏览器自动化和评测任务在受控边界内运行。项目本身可以免费获取和修改，但它不是“免费算力”：镜像仓库、主机或集群、存储、网络出口、日志、安全运行时和运维人力都由部署者承担。

它的安全价值来自可配置的分层控制，而不是安装后自动获得绝对隔离。默认 runc 更适合本地开发或可信任务；执行不可信代码时，应评估 gVisor、Kata Containers 或 Firecracker、资源上限、默认拒绝的出口策略、入口路由和凭据保险库。OpenSandbox 提供这些接口与指南，但管理员仍要正确配置宿主机、RuntimeClass、密钥、镜像供应链和租户隔离。

核心功能

统一沙箱协议：通过 OpenAPI、SDK 与 osb CLI 创建、查询、续期和销毁沙箱
Docker 与 Kubernetes 后端：本地可用 Docker，生产环境可结合 Kubernetes 调度和资源池
命令与文件操作：内置执行守护进程，支持命令、文件系统、流式日志和代码解释器工作流
多语言 SDK：提供 Python、JavaScript/TypeScript、Java/Kotlin、C# 和 Go 接口
网络策略：入口网关与每沙箱出口控制，可为外部域名设置允许和拒绝规则
Credential Vault：由出口 sidecar 在匹配的 HTTPS 请求上注入真实凭据，避免把密钥直接放进沙箱环境变量、文件或日志
强化运行时：管理员可在服务级配置 gVisor、Kata 或 Firecracker；兼容性、启动延迟和内存开销各不相同
SDK 遥测控制：SDK 默认上报 sandbox.create 延迟到服务器，可设置 OPENSANDBOX_DISABLE_METRICS=1 或语言配置项关闭

适合人群

Agent 平台团队：需要统一管理大量短生命周期执行环境
Coding Agent 开发者：需要把仓库、命令和测试放进独立运行空间
模型评测与训练团队：需要并发、可回收的任务环境和 Kubernetes 调度
安全与平台工程师：愿意设计网络、凭据、镜像、运行时和审计策略
不太适合的人群：只想调用即用托管沙箱、没有容器运维能力，或认为普通容器足以隔离任意恶意代码的团队

使用场景

代码执行：运行模型生成的 Python、JavaScript 或 shell，并限制 CPU、内存、超时和网络
Coding Agent：让命令行 Agent 在临时仓库副本中安装依赖、修改文件和运行测试
浏览器自动化：在带 Chromium、Playwright 或桌面环境的镜像中执行网页任务
评测并发：为每条测试样例创建独立环境，结束后统一回收
受控凭据访问：通过 Credential Vault 仅向指定 HTTPS 主机、方法和路径注入 API Key

价格与版本

OpenSandbox 源代码按 Apache 2.0 免费提供，没有官方按席位订阅价。真实总成本取决于部署方式：单机 Docker 需要服务器、磁盘和网络；Kubernetes 还包括控制面、节点、镜像缓存、日志指标、负载均衡与运维；gVisor 或虚拟机级运行时会增加启动和内存开销。浏览器、桌面、代码解释器和预热池也会显著增加常驻资源。

评估时应按“每个成功任务的总成本”计算，包括沙箱启动时间、空闲预热、镜像拉取、出口流量、失败重试和安全工具，而不是把开源许可证等同于零成本。如果团队不想承担基础设施，可以对比托管产品，但要另行审查其数据保留和单次执行价格。

国内访问与使用体验

核心运行时可自托管，部署后的可达性取决于自己的基础设施和镜像源。安装包、GitHub、容器镜像及沙箱内访问的外部模型服务可能受网络环境影响，应准备可审计的内部镜像和依赖缓存。SDK 的创建延迟遥测默认发送到所连接的 OpenSandbox 服务器，不是必须功能；隔离或审计要求严格时，可用 OPENSANDBOX_DISABLE_METRICS=1 关闭额外请求。

安全配置需要按工作负载选择。普通 runc 共享宿主内核；gVisor 增加用户态内核边界但存在 syscall 兼容限制，而且当前与依赖 nat 表的出口 sidecar 组合受限；Kata 使用独立虚拟机内核，兼容性更高但开销更大；Firecracker 适合高密度 microVM 场景，但平台支持也有限。Credential Vault 应配合 dns+nft、defaultAction="deny" 和精确主机/路径绑定使用，不能在默认放行网络上当作万能密钥保护。

优点

Apache 2.0 许可，协议、服务器、SDK 和 Kubernetes 组件均可审计和修改
Docker 到 Kubernetes 使用统一生命周期与执行接口
多语言 SDK、CLI、MCP 和示例覆盖常见 Agent 接入方式
网络出口、Credential Vault 与强化运行时为纵深防御提供组件
可关闭 SDK 创建延迟遥测，适合离线或严格出口环境

不足

自托管成本和安全责任完全落在使用方，不是开箱即用托管服务
默认容器运行时不等于可安全执行所有恶意代码
gVisor、Kata、Firecracker 各有宿主要求、兼容性和性能取舍
Credential Vault 依赖精确网络配置，服务网格和非标准出口场景可能冲突
大规模预热、镜像治理、日志、配额与租户隔离仍需平台工程投入

替代品对比

工具	更适合谁	优势	主要取舍
E2B	希望快速使用托管 Agent 沙箱的团队	API 上手快、托管运维	按量成本与外部服务依赖
Daytona	需要开发环境生命周期管理的团队	开发工作区与 Agent 场景结合	产品边界与部署模型不同
LangChain	需要模型和工具编排的开发者	Agent 编排生态广	本身不替代强隔离运行时
Dify	需要可视化 AI 工作流的团队	应用编排和运营界面完整	代码执行安全仍需独立评估

OpenSandbox 与 LangChain 或 Dify 并非同层竞品：前者负责执行边界，后两者更偏应用编排。若团队没有 Kubernetes 与安全运行时经验，先用 E2B 或 Daytona 做小规模成本对照更实际。

常见问题 FAQ

OpenSandbox 完全免费吗？

代码按 Apache 2.0 免费，但计算、存储、网络、镜像、安全运行时和运维都需要自行付费。

默认 Docker 容器足以执行不可信 AI 代码吗？

不能直接下结论。高风险任务应评估 gVisor 或 Kata、最小权限、资源限制、网络默认拒绝、只读文件系统和宿主加固。

Credential Vault 会把真实密钥交给沙箱吗？

设计目标是让真实凭据保留在出口 sidecar，由匹配规则在请求外发时注入；沙箱内只看到占位值。但错误的网络或绑定配置仍可能破坏安全假设。

可以关闭 OpenSandbox SDK 遥测吗？

可以。设置 OPENSANDBOX_DISABLE_METRICS=1，或使用各 SDK 的 disable_metrics、disableMetrics、DisableMetrics 配置。

Docker 和 Kubernetes 应该怎么选？

Docker 更适合本地验证和低规模单机任务；Kubernetes 更适合并发调度、池化和多节点生产，但运维与安全复杂度更高。

OpenSandbox 能替代 Agent 框架吗？

不能完全替代。它主要提供沙箱生命周期和执行层，任务规划、记忆、模型路由和业务审批通常由上层 Agent 框架负责。

总结

OpenSandbox 的核心价值是把 Agent 执行环境抽象成可自托管、可扩展的开放协议与运行时。它适合有平台工程能力、希望控制部署和安全边界的团队。正确采用方式是把 Apache 2.0、Docker/Kubernetes、网络策略、Credential Vault、强化运行时和遥测选项分别评估，而不是把“开源沙箱”理解成免费且天然安全的黑盒。

OpenSandbox