在 AI 系统架构快速演进的今天，当软件越来越多地以 Agent 形态运行时，执行环境已不再是一个简单的基础设施细节，它在很大程度上决定了整个系统的能力上限。本文整理自阿里巴巴高级技术专家、研发 TL 陶宇田在 QCon 全球软件开发大会 2026 北京站的分享《OpenSandbox：重新思考 Agent 时代的 Runtime》。
从 2024 年 12 月底开源至今，OpenSandbox 在社区引起了广泛关注。陶宇田在分享中系统阐述了他和团队在 AI Agent 执行环境设计上的思考与探索，从 Agent 场景下执行环境面临的核心挑战出发，深入解析 OpenSandbox 的协议优先设计理念、批量交付效率优化、三层安全防护体系，以及它在自主 Agent、批量评测和 RL 训练等典型场景中的具体实践，并简要探讨未来的演进方向。
以下是演讲实录（经 InfoQ 进行不改变原意的编辑整理）。
AI Agent 执行环境的新挑战
最近这一两年，我有一个特别强烈的体感：当我们讨论 coding agent 系统、批量评测系统，甚至是训练系统的时候，随着模型能力越来越强，很多时候最后卡住的点已经不是模型本身了，而是 runtime。所以我们首先要回答一个根本性的问题：在 AI Agent 这个场景下，执行环境到底遇到了什么样的问题？
今天的 Agent workload 在业务形态上呈现出越来越多样化的趋势。我认为有三种场景最具代表性。第一种是 autonomous agent，即自主智能体。这类 Agent 的能力正在快速增强，它需要一个特定的文件系统通道去操作，需要特定的命令执行通道。不仅如此，Agent 自己能够进化式地去实现一些服务，因此它需要一种统一的对内对外服务暴露方式，有些时候甚至需要暴露长连接。随着 Agent 能力越来越强，除了要限制它本身在容器内的行为之外，网络层面上的管控也变得至关重要。这里我们需要的不是简单地把网掐掉这种粗暴方式，而是更细粒度的网络管控手段。
第二种是批量评测系统。这个场景的特点不在于单个环境有多复杂，而在于它是一个典型的批量交付场景，并且需要极强的隔离性。我们不能让各个评测任务之间互相影响，这样才能给整个评测体系提供一个公平的考场环境。
第三种是 RL 训练场景，这是最近一年来越来越热门的方向。这个场景最大的特点是海量、生命周期短，并且一定要支持批量交付。在训练场景下，系统批量交付的效率在很大程度上直接决定了整个训练效率本身。
如果我们把这三个场景抽象出来，会发现它们有一些共性的诉求。在系统层面，你需要提供高并发、高吞吐的能力来承接 sandbox 的交付，需要明确的生命周期管理能力，需要可控的联网能力，还需要统一的访问接口和统一的执行通道。今天我们看到，问题的核心已经不是某个系统到底能不能让 Agent 跑起来，而是我们到底有没有一个合适的系统，能够更批量、稳定、可控地去让这些 Agent 运行。如果仅仅以“能让 Agent 跑起来”为标准，很多传统系统已经够用了。但在 AI Agent 这个时代，这个标准本身就已经不够了。
为什么不够？我们来看 Docker 和 Kubernetes 这样的系统。首先我要声明，我并不是在否定这些系统。Docker 和 K8s 存在了很多年，在整个软件架构体系里运行得非常稳定，也非常出色。但它们在今天这个场景下面临的最大问题是——从它们出生的第一天起，就不是为今天 Agent 这种执行模式来设计的。
我们来看典型的 K8s 交付场景。这是一套非常成熟的、业界标准的 online serving 调度体系。从在线服务的视角出发，单个服务的启动快一点、慢一点，在绝大多数场景下我们都能接受。但是一旦进入批量交付场景，整条链路上容器交付速度的微小延迟，在规模化之后会被不断地叠加放大。传统 K8s 创建过程中的写入开销、状态同步开销，一旦上了规模，整个链路的写扩散和交付时间成本会呈线性增长。这样一来，交付时间就变得非常不可控了。
访问链路的需求同样存在差距。无论是 K8s 还是 Docker，它们并没有提供一个典型的访问路径抽象。今天我们会面临这样一种情况：Agent 在系统内启动了自己的业务服务之后，它有 HTTP、SSE，还有特定的 WebSocket、VNC 等多种服务暴露方式。如果这些暴露方式都以具体的、特定的形式呈现，让上层业务系统去分别理解这些底层细节，那么整个上层系统也会做得越来越散。
还有一个特别关键的点，就是服务的统一和细粒度的网络控制。这部分比较好理解。当 Agent 能力越来越强，我们会让它接触很多业务数据，这时就需要更细致的管控方式来描述到底允许 Agent 在沙箱环境内访问什么样的网络资源。在很多场景下，尤其是在企业级场景下，你需要一个非常明确的描述方式，来告诉沙箱系统，不允许 Agent 触碰到哪些网络资源。这在网络管控层面非常重要。
同样缺失的还有统一的执行契约。传统系统里面实际上没有一个真正纯粹面向沙箱语义的契约描述。今天这个场景下，我们经常需要为沙箱定义一个符合其自身场景特点的生命周期，以及在沙箱创建之后，你以什么样的形式去与环境交互——可能需要具体的命令执行通道，需要具体的文件系统准备。这些都是传统系统没有涉及到的点。
所以我们可以得出结论：问题不在于今天的容器能不能跑，而在于传统系统似乎缺失了一层面向 Agent 的统一执行模型的描述能力。OpenSandbox 正是在试图弥补这一层能力模型的缺失。
OpenSandbox 的核心设计
在 OpenSandbox 的架构中，最上层是传统的应用层，可以是一个传统应用，也可以是批量评测系统或者训练系统。对于这些系统，OpenSandbox 在用户交互层提供了一层统一的 SDK 接入。针对今天的 AI 时代，我们也提供了开箱即用的 CLI、MCP 等能力，方便 Agent 场景直接与 OpenSandbox 交互，进行沙箱操控。本质上，第二层的用户交互层都是基于下面的 protocol layer，即协议层。在这层协议层里，我们定义了 OpenSandbox 最核心的一些东西，提供了一个开箱即用的 server 实现。这一层 server 承载 SDK 进来的调用流量。
流量进入之后，在 runtime 层，目前我们提供了 Docker 和 K8s 两种 runtime 引擎，业务方可以根据自己的场景需求去选择。在最下面一层，对于沙箱实例层的封装，我们提供了一些开箱即用的核心组件，比如 execd 组件和 egress 组件，分别负责不同的沙箱内通道以及网络管控的实施细节。这些能力在底层做好之后，对上层的 runtime layer 是一个通用能力，因此对上层可以统一提供一个通用的沙箱管控能力。还有一条重要的通道，就是我们刚才提到的统一入口访问抽象。Agent 在沙箱内启动了自己的服务之后，可以通过统一的 ingress 层，最终触达到沙箱内部提供的服务。
如果让我用一句话去概括 OpenSandbox 最核心的设计，我想说：它本身不是从某一个具体的 runtime 出发的，而是从能力抽象出发的。 OpenSandbox 从一开始就不是先去决定 runtime 这一层到底用 Docker 还是 K8s，然后基于它们能提供什么能力向上反推。而是我们先尝试定义清楚第二层——specs layer 这一层，我们到底要提供什么样的契约。
这层契约对上层的意义在于，它提供了一个稳定的 sandbox 交互语义。对于上层的多端 SDK，目前我们提供了五种语言的开箱即用 SDK，虽然不同语言在描述能力和语法糖上有差异，但它们都基于 specs 这层 layer，为上层接入的业务提供统一的沙箱语义。对于下层 runtime，你今天可以用 Docker，也可以换成 K8s，甚至未来你可以提供一个自己自定义的、更强的 runtime。至于最下层，我们契约里面描述的所有命令封装通道、文件系统操作能力、代码执行能力以及服务统一暴露能力，都统一通过下面这层来承载。
这个设计思路看上去有一些抽象，但它非常重要。很多系统我们以前做架构的时候会发现，一开始设计得很好，也很快。但是一旦 SDK 这一层和底层具体实现绑定之后，等场景一扩充，整个系统的演进就会变得越来越难。OpenSandbox 从设计的一开始就在尝试规避这件事。这就是 protocol first，协议优先。
接下来，我把 specs layer 这一层的抽象展开来看一下。核心来说，我们先定义一个稳定的契约。这层契约最本质的思路不是说我们要定义多少 API，而是说我们在考虑到底能不能有一个稳定的、清晰的能力描述边界把它讲清楚。在 OpenSandbox 内部，我们目前分了四个部分去描述这层契约。
第一部分比较直观，包括 create、get、list、delete 以及相应的一些语义操作接口。它实际上是在描述 sandbox 本身作为一个执行环境单元，我们到底以什么样的方式去管理它的生命周期。
第二部分是命令执行的契约定义。随着今天 Agent 系统能力越来越强，我们有更多的诉求去与 sandbox 环境交互——需要给环境执行什么样的命令，可能需要操作这个环境的文件系统，去给 Agent 准备一些特定的环境，以及代码如何执行的通道，甚至是一些后台任务执行的通道。这些都是在这部分能力中描述的。
第三部分是网络和策略层。在这里我们定义了更为细粒度的网络管控语义和描述能力。今天对于在沙箱内部运行的 Agent 来说，简单的网络管控语义是不够的。我们需要一种特定的契约去说清楚，你到底允许你的 Agent 在这个沙箱里面访问什么样的网络资源。这些网络资源可能包括网络协议栈七层的具体域名，但在更细节的场景，比如企业级应用中，我们甚至需要更细粒度的四层 IP 级别的描述能力，甚至包括网段级别的描述能力。你必须控制它，不能让 Agent 触达到某些网络资源。
第四部分是访问控制层。这一层主要解决的是以什么样的通用方式来暴露对外服务的问题。交互式的 Agent 有各种各样的暴露形式。如果你基于 HTTP、SSE 或者 WebSocket 都分别有一种独立的暴露方式，整个系统就会做得越来越散。
综合来看这四个部分的核心设计思路，它的最大价值在于：给上层提供的对于 OpenSandbox 系统的依赖层，是一个更为稳定的 runtime 契约，而不是基于某一个具体的 runtime 实现来提供系统能力。 这样对于上层来说，整个系统才是相对稳定的。
池化调度与极速交付
刚才讲的偏抽象层面，接下来我们要涉足一个特别关键的话题，那就是 sandbox 本身的交互效率。如果设计思路仅仅停留在架构图上，是远远不够的。在真实的系统中，一旦上了规模，不管是评测还是训练场景，sandbox 的批量交付能力在很大程度上会决定整个系统的上限。我们来看 OpenSandbox 内部到底在批量交付能力上做了什么。
底层最直观的做法是 pool 加热备资源池。这个概念很好理解，也是大家常规能想到的方法：我们提前把资源预热起来，降低它从零到可用环境的等待时间成本。这主要解决的就是不要从零开始冷启动每一个 sandbox 环境。
但在 OpenSandbox 里面，更重要的一个概念是 BatchSandbox。它不是一次交付创建一个请求、创建一个环境，而是做了一件最关键的事情：把批量创建环境建模成了一个统一的对象，把批量分配语义统一归属到 BatchSandbox 这个对象上。 这意味着整个系统开始以批量交付的方式来思考，而不是不停地创建很多个单体环境。这个转变至关重要。
有了 BatchSandbox 这个能力之后，对上层我们就可以提供一个相对稳定的批量交付能力。当然，对于个别需要异构注入执行任务能力的场景，我们也提供了内部可选的异构任务补丁，比如你可以注入不一样的 command，或者注入不一样的运行环境。
接下来我们看一个具体的交付效率对比，理解它到底为什么快。K8s 社区官方有一个 SIG 的 agent sandbox 项目，它比我们更早下场去做 sandbox 开源，大概早了一些时间。我们在做 OpenSandbox 的时候，做了 benchmark 对比。在双方都启动池化的情况下，测试对比拉起一百个 sandbox 的整体交付时间效率。我们甚至给 agent sandbox 项目的 controller 调节了不同的并发度控制。即使是对方最好的成绩，OpenSandbox 的整体交付效率也比它高出一个数量级左右。
为什么会有这种差异？我们来看 K8s 社区 agent sandbox 项目交付一百个 sandbox 的完整流程。首先，客户端发送一百个 sandbox 的创建请求。这一百个创建请求会到传统的 API server。API server 会在系统里创建一百个 SandboxClaim 这样的资源对象——这是第一个阶段，一百个资源对象创建的写入开销。然后，它的控制器在感知到这一百个 SandboxClaim 资源对象创建之后，会做相应的处理：从已经热分配的池子里选出一百个 pod 资源，再把这一百个资源交付给 SandboxClaim 对象。在这个过程中，控制器首先选出一百个可用的 pod，但这些 pod 最初归属的是 sandbox pod 热备池。
所以它要做的操作是，把 pod 拿出来之后，将 pod 的 owner reference 改成刚刚创建的 SandboxClaim 资源对象。粗略算一下，在这个环节，选出一百个 pod 又要进行一百次更新操作。然后当 SandboxClaim 接收到这些对象之后，它又要把自己的 status 做一次更新，来表示已经接收到了 sandbox 资源对象——这又是一百次更新操作。每一次操作都涉及背后 etcd 的更新动作。整体上，在这一百个 sandbox 的交付链路上，我们看到了非常多的写扩散。这里面涉及创建一百个资源对象，更新和同步的数量则不是一百，而是几百个这样的操作。这个例子很好地说明了：控制面在整个过程中会出现非常严重的线性写扩散动作。
我们再看 OpenSandbox 是怎么做的。在这种交付场景下，它创建一个 BatchSandbox 对象，标识这个 BatchSandbox 需要交付一百个沙箱。OpenSandbox 内部的控制器会从已有的池子里，先在内存中选出一百个可用的沙箱，然后再把这一百个沙箱比量的方式，通过标识打到这一个 BatchSandbox 实例上。整个过程中，我们先创建一个实例。update 的时候，只是针对这一个 BatchSandbox 资源对象来做更新操作。所以整体上，我们的思路是：用更少的资源对象写入和状态同步处理，来做更少的协调步骤，从而在批量吞吐交付场景上实现更高的交付效率。
现在我们再来看这件事，OpenSandbox 所做的本质上不是简单提供了一个池子，而是在整个交付链路上做了梳理，让系统层面上的协调开销更小。
Agent 场景下的安全执行
讲完交付效率之后，我们进入另一个特别关键的环节——安全执行。今天随着 Agent 能力越来越强，安全这个话题是绕不开的。所有需要在企业级部署的场景下，都会关心你的 sandbox 到底怎样能让 Agent 在一个安全可控的环境里运行。在安全这个层面上，OpenSandbox 目前分了大概三层来构建防护体系。
第一层是隔离。 这件事最核心的是容器层面的隔离，也是大家最好理解的一个层面。这一层本质上是在增加不可信工作负载和底层宿主机之间的隔离边界。从隔离本身的技术手段上来说，今天可能有不同的实现方式。比如可以基于 gVisor 这种用户内核态的统一隔离方式，或者也可以有像 Kata runtime 这种更强的底层实现，它有可能调用 Firecracker VMM 这种具体方案，直接提供 VM 层面上的更强隔离能力。但不管哪种技术路线，本质上都是通过不同的方式去实现不可信工作负载和宿主机之间边界的加固，防止在 Agent 不可控的情况下发生内核逃逸，影响到同一宿主机的其他 sandbox 环境。
第二层是网络控制。 今天 Agent 的形态不是传统的离线作业，我们没有办法简单地把它把网关掉就了事。几乎所有的 Agent 都有访问网络的诉求——它需要访问 GitHub，需要访问包管理器，需要跟模型交互，所以它必须跟模型的 API 是通的。很多业务系统的 Agent 还需要访问自己业务系统的服务。这里面最直接的一个能力诉求就是：你到底能不能提供更细粒度的管控方式。一方面，你要能够描述这个 Agent 今天允许访问什么样的网络资源，包括具体你提供的服务的网络资源。另一方面，在企业级应用里，其实还有更强的反向要求：你到底不能访问哪些资源，因为很多资源在企业级场景里会非常敏感。这种描述能力，除了允许和拒绝的语义之外，也有不同的描述层级需求：你到底是需要描述简单的域名，还是需要描述特定的网段？这些在整个网络协议栈上，基本上会涉及七层和四层的不同描述场景需求。
OpenSandbox 在这里做的 egress 组件抽象，在逻辑上大概分两层实现。第一层是做了一个 DNS 劫持。这层劫持是一个透明的劫持，主要目的是在域名隔离能力上做第一道拦截。我们的做法是，egress 组件在 sandbox 启动、准备交付给业务之前，就已经劫持掉了它的 DNS 解析这一道。这样在整个安全控制层面上，我们就有机会对那些危险的域名在访问时，在域名解析阶段就把它拦截掉。第二层是底层的网络过滤层。这层偏更底层一点，主要是对底层 IP 级别以及 IP 网段级别的过滤。这时候会有更强的管控能力，防止 Agent 知道了某些特定的 IP 之后绕过 DNS，直接从 IP 这一层走出口达成对外访问的目的。
第三层是统一治理的诉求。 这一层我们要提供一些方式，除了对外暴露服务的形式统一之外，它本身也是一个平台治理和审计的重要入口。ingress 统一架构让我们可以在真正的入向请求触达 sandbox 之前，做很多中间拦截层的操作。最直接的例子就是最近我们上了一个功能：基于 OpenSandbox 自身对外暴露服务的访问频率，来实现 TTL GC 时间的自动刷新能力。像访问的统一审计功能，也可以在内部这一层做相应增强。这些功能本身对整体的 Agent 进程是无侵入的。这一点非常重要，Agent 不需要感知具体环境的细节做了哪些拦截。
综合来看，OpenSandbox 在传统的隔离、网络隔离还有访问治理这些方面，做了一套系统化的能力来应对安全执行场景提出的要求。
OpenSandbox 典型应用场景
接下来我举几个具体的应用场景例子，来看 OpenSandbox 在这些场景里面到底提供了什么样的能力，以及它处在一个什么样的位置。
第一个例子是 autonomous agent 的架构演进。 在 AI 系统刚开始的时候，有一种很典型的运行模式：模型生成一段代码，发出代码执行请求，沙箱在里面负责运行这段代码，运行之后把结果交付给模型，模型再基于结果做后续推理处理。在这个过程中，sandbox 充当的角色就是社区里常说的 sandbox as a tool——一个纯粹的工具角色。社区里之前有人打了一个特别形象的比喻，说这是头身分离的架构：头是在左侧 Agent 的独立应用里，身体或者脚在 sandbox 沙箱里。这种模式简单直接，但它的上限也会遇到问题。一旦你的 Agent 进化到执行更复杂任务的时候，我们希望它有一个独立的环境，让它真正地跑起来。这时候很多人不会陌生的一种模式，就是干脆直接把 Agent 装进沙箱里，脑身结合了之后，传统应用可以给它下发更复杂的指令去做相应的交互。
这让我想到最近非常火的 OpenClaw 这个项目。它的极简架构图和这种脑身结合的模式没有本质区别。但是 OpenClaw 做了一件特别重要的事，它在工程优化层面给 Agent 加了非常多的工程优化手段，也就是说它已经在某种程度上践行了我们今天说的 agent harness。不过玩过 OpenClaw 的朋友应该都知道，要充分发挥 OpenClaw 的潜力，一个很重要的前提就是要给它充分的授权。而一旦给了它充分的授权，你会发现前面讲到的所有安全管控手段必须全部加上，否则这个 OpenClaw 本身就是一个非常危险的因素。
第二个例子是批量评测场景。 这个场景相对直观一些。评测框架本身在上层负责了任务的编排和调度，OpenSandbox 在这里面重点提供的是执行层面上的批量执行能力。由于我们前面讲到的 BatchSandbox 机制和安全隔离能力，评测系统可以将大量评测任务以批量的方式交付到沙箱环境中，各个任务之间严格隔离，保证了评测的公平性。
第三个例子是 RL 训练场景。 这是最近一年多来越来越多被涉及到的场景。在这个场景里，sandbox 本身会面临两部分的压力。一部分是批量层面的压力。这种压力来自于训练系统——它不是偶尔申请几个环境，而是为了充分发挥前向 GPU 的推理性能和压榨它的性能，持续不断地去申请环境、使用环境、再申请环境。从批量交付的量级上来说，这是一个海量的场景。另一部分是执行层面的压力。训练场景需要收集 Agent 在沙箱内的 trajectory 数据，所以沙箱内部的 Agent 自身就会有跟模型的多轮交互，然后基于模型的指令和数据，去做一些自主性非常高的行为。在这个场景里面，前面我们讲到的所有安全执行手段，在这里全部都有。这个场景也很好诠释了，在这些极限场景下，sandbox 到底要给上层的业务系统提供什么样的能力，才能够让它稳定运行。
未来演进方向
最后，我们简单讲一下未来演进的一些方向。
首先是状态管理。 今天我们还在尝试把像 K8s 体系中的 pause/resume 这种能力，给社区贡献一个更完整可用的方案。因为从长时运行的 Agent 场景来看，状态本身会变得越来越长运行。在极速交付的场景下，我们目前做了一些努力和尝试，但这件事还远没有到达终点。在我们的 roadmap 上，也还会有一些更极致的交付效率优化和处理方式。
其次是工作区间持久化。 这部分主要是因为今天的 Agent 会越来越长时地运行在一个沙箱里面，所以它怎么样在这个沙箱里拥有一个连续的工作空间，以及怎么样把现有的 volume 这种能力赋予一个更统一的语义实现，都非常重要。
再有就是可观测能力。 早期的时候，这部分能力我们可能没有作为第一优先级去实现。但实际上，一旦沙箱这个领域进入企业级应用之后，它就需要更强的观测能力，你要知道沙箱自己的 Metrics 表现是什么样的，而企业级的审计能力几乎是不可以缺失的。所以这些部分都是未来沙箱仍然会去努力做的一些方向。
OpenSandbox 这个项目从去年十二月底在社区发布，到现在还是一个非常年轻、非常活跃的项目。我们刚刚也加入了 CNCF landscape。AI 这个领域发展特别快，未来的迭代我们还会持续去做。欢迎在场的朋友去关注、甚至去贡献这个项目，让这个项目越来越好，也把这些能力更好地回馈给整个开源社区。
作者介绍
陶宇田，阿里巴巴高级技术专家、研发 TL，先后任职于亚马逊、阿里巴巴，拥有 15 年以上大型互联网架构设计与研发经验。技术领域覆盖中间件、推荐系统、云原生、分布式任务调度及 AI 基础设施等核心方向。目前担任阿里巴巴 Sandbox 领域负责人，主导 OpenSandbox 开源项目建设，聚焦 AI 场景下的沙箱运行时与基础设施创新，致力于构建安全、高效、可复用的 AI 执行环境。
会议推荐
AICon 全球人工智能开发与应用大会·深圳站，限时 9 折专属优惠，现在报名立减 580，更多详情可扫码或联系票务经理 13269078023 进行咨询。
