从 2024 年底开源至今，阿里 Sandbox 团队主导的 OpenSandbox 试图补上 AI Agent 时代缺失的一层：一个面向智能体语义的统一 Runtime。它用「协议优先」设计绕开传统容器编排的写扩散瓶颈，在 100 个沙箱的批量交付测试中，比 K8s 社区方案快出一个数量级。
阿里高级技术专家陶宇田在分享中给出了一个直接判断：问题不在于今天的容器能不能跑，而在于传统系统缺失了一层面向 Agent 的统一执行模型描述能力。
为在线服务设计。单 Pod 启动快慢无所谓，但批量交付时写扩散呈线性增长，交付时间不可控；没有面向沙箱语义的统一访问与执行契约。
高并发批量交付、明确生命周期、细粒度联网管控、统一访问接口。Agent 要跑代码、调 API、暴露 HTTP/WS 服务——这些传统系统没现成抽象。
陶宇田点出三类典型场景的共同瓶颈：自主智能体需要文件系统通道与长连接暴露；批量评测需要强隔离的公平考场；RL 训练需要海量、短生命周期、持续压榨 GPU 的批量交付——后者的交付效率直接决定训练效率本身。
OpenSandbox 的核心设计理念是 protocol first——不从具体 runtime 反推能力，而是先在 specs layer 定义清楚稳定的沙箱交互契约，再向下适配 Docker、K8s 或未来的自定义 runtime。上层 SDK（目前 5 种语言）只依赖契约，不绑死实现。
这层契约目前拆成四个部分，每一部分都对应 Agent 场景的具体痛点：
create / get / list / delete——把沙箱作为执行环境单元，定义它怎么被创建、查询、销毁。
命令执行、文件系统操作、代码执行通道、后台任务——Agent 与沙箱环境交互的全部动作都在这层描述。
细粒度网络管控：七层域名级 + 四层 IP/网段级。企业场景下既要说清「能访问什么」，更要描述清「不能碰什么」。
统一暴露 HTTP / SSE / WebSocket / VNC 等服务，避免上层业务系统各自理解底层细节，越做越散。
关键不在池化预热（那是常规手段），而在把批量创建建模成一个统一对象。OpenSandbox 引入 BatchSandbox，一次交付 100 个沙箱只创建 1 个资源对象、做 1 次更新；而 K8s 社区方案要创建 100 个 SandboxClaim、改 100 次 owner reference、再更新 100 次 status——几百次 etcd 写操作 vs 1 次。
注：柱形长度仅作量级示意，非精确耗时；测试条件为双方均启用池化、拉起 100 个沙箱的整体交付时间，OpenSandbox 领先约一个数量级。原始测试未披露绝对秒数。
本质上是在整个交付链路上做协调开销的瘦身——用更少的资源对象写入、更少的状态同步，换来更高的批量吞吐。
Agent 能力越强，安全越绕不开。OpenSandbox 的防护体系分三层，对 Agent 进程本身无侵入：
加固不可信工作负载与宿主机边界。可选 gVisor 用户内核态隔离，或 Kata + Firecracker VMM 提供 VM 级更强隔离，防内核逃逸。
DNS 劫持做域名级第一道透明拦截；底层网络过滤层做 IP / 网段级拦截，防 Agent 绕过 DNS 直连 IP 访问敏感资源。
入向请求触达沙箱前做中间拦截——统一审计、TTL GC 时间按访问频率自动刷新等，Agent 无需感知拦截细节。
本文内容整理自企业技术团队在技术大会上的公开分享，属于单方披露的建设性视角：交付效率「快一个数量级」的对比基于团队自测 benchmark，原始测试未披露绝对耗时数据，也未见第三方独立复测。读者宜将其视为一种架构思路的论证，而非已定论的横向排名。其中「协议优先于实现」的思路在云原生社区有共识基础，OpenSandbox 的贡献在于把它系统化到了 Agent 沙箱这个具体场景。
当模型能力逐渐拉平，Agent 系统的竞争焦点正在从「谁的底座更聪明」上移到「谁的执行环境更可控、更高效」——Runtime 工程能力的差距，将成为下一阶段 Agent 落地的真正分水岭。
OpenSandbox 已加入 CNCF landscape，支持 CLI 与 MCP 接入，提供 5 种语言 SDK。
GitHub 开源仓库 → opensandbox