阿里开源的安全沙箱解决方案 OpenSandbox

云端 Agent 的问题已经从会不会写代码，变成能不能安全地执行代码。只要 Agent 要跑命令、改仓库、访问包仓库、调用模型 API，运行环境就开始变复杂。

OpenSandbox 做的是这块底座：把任意代码放进隔离环境运行，把出站网络收住，把凭据使用交给 sidecar 代理。我更关心的是这套设计能不能放进真实的云端 Agent 系统里。

它解决哪层问题

OpenSandbox 是一个通用 sandbox 平台，提供 SDK、CLI、MCP、统一生命周期 API，以及 Docker / Kubernetes 两套 runtime。它不是完整的 Agent 产品。调度、会话、记忆、任务语义这些上层能力，需要外部系统自己接。

这反而让它的位置很清楚：它负责执行面。上层调度器决定任务怎么来、谁能跑、跑多久、结果怎么回传；OpenSandbox 负责创建隔离环境，执行命令，处理文件，控制出站请求。

如果拿 Claude Managed Agents 的结构来对照，OpenSandbox 更接近 Environment、Sandbox、Vault、Permission policy 里偏运行时的部分。Agent harness 那层，它不会替你做。

凭据设计是重点

Agent 系统最容易出问题的地方，是凭据。最省事的做法是把 token 放到环境变量里，让工具自己读。问题也在这里：Agent 进程能读到，命令能打印出来，恶意代码也能转手带走。

OpenSandbox 的 Credential Vault 思路很直接：真实凭据写进 egress sidecar，容器里只给 fake key 或空值。Agent 照常发 HTTPS 请求，sidecar 透明拦截后检查目标 host、method、path，匹配绑定规则才注入真实请求头。

这个设计的好处是，工具链不用大改。Claude Code、Git、curl、npm、模型 SDK 仍然按原来的方式访问外部服务，只是凭据不在进程里出现。

当然，这也有边界。Credential Vault 依赖透明 MITM 和 CA 信任；如果 K8s pod 里同时注入 Istio / Envoy 这类服务网格 sidecar，透明拦截层会冲突。它目前也不做 response body 的 secret 重写，所以不能把它理解成万能脱敏器。

放到云端 Agent 里怎么接

一个比较实际的架构是：外部控制面接收用户任务、PR、Issue 或队列消息，判断权限和资源配额，然后为每个任务创建短生命周期 sandbox。sandbox 内运行 Claude Code、Codex CLI、OpenClaw 或其他 Agent CLI。

执行过程中，execd 负责命令、文件、会话和指标。egress sidecar 管出站策略和凭据注入。任务结束后，日志、测试结果、patch、endpoint 信息回到控制面，sandbox 随后销毁。

我会把它看成安全 runtime 层来接。它不负责替你做产品闭环，但能把最容易失控的执行环境、网络、凭据三件事收紧。

采用前要想清楚

OpenSandbox 适合的场景很明确：你要运行不完全可信的代码，Agent 需要访问 Git、模型 API、包仓库，真实凭据又不能直接进容器。

如果团队还没有调度器、队列、会话管理、权限策略和审计链路，先补控制面更重要。OpenSandbox 可以降低 runtime 风险，但它不替你定义任务生命周期。

另一个要提前评估的是网络环境。透明 MITM、CA 信任、K8s sidecar 兼容性，都是上线前必须测的点。这里不能只看 demo 跑通，要按真实生产网络做验证。

总结

OpenSandbox 的价值不在概念新，主要在边界清楚。它把云端 Agent 里最危险的执行面单独抽出来处理：沙箱隔离、默认拒绝出站、按目的地注入凭据、日志和结果回传控制面。

如果已经在做自建云端 Agent，这个项目值得认真评估。我的接入顺序会是：先有调度和权限控制，再把 OpenSandbox 接成 runtime，最后围绕凭据、网络和审计做生产级验证。