本文来自微信公众号： InfoQ ，作者：QCon，原文标题：《OpenSandbox：重新思考 Agent 时代的 Runtime》
审核|Kitty
在AI系统架构快速演进的今天，当软件越来越多地以Agent形态运行时，执行环境已不再是一个简单的基础设施细节，它在很大程度上决定了整个系统的能力上限。本文整理自阿里巴巴高级技术专家、研发TL陶宇田在QCon全球软件开发大会2026北京站的分享《OpenSandbox：重新思考Agent时代的Runtime》。
从2024年12月底开源至今，OpenSandbox在社区引起了广泛关注。陶宇田在分享中系统阐述了他和团队在AI Agent执行环境设计上的思考与探索，从Agent场景下执行环境面临的核心挑战出发，深入解析OpenSandbox的协议优先设计理念、批量交付效率优化、三层安全防护体系，以及它在自主Agent、批量评测和RL训练等典型场景中的具体实践，并简要探讨未来的演进方向。
以下是演讲实录（经InfoQ进行不改变原意的编辑整理）。
1AI 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正是在试图弥补这一层能力模型的缺失。
2OpenSandbox的核心设计
在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实现来提供系统能力。这样对于上层来说，整个系统才是相对稳定的。
3池化调度与极速交付
刚才讲的偏抽象层面，接下来我们要涉足一个特别关键的话题，那就是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所做的本质上不是简单提供了一个池子，而是在整个交付链路上做了梳理，让系统层面上的协调开销更小。
4Agent场景下的安全执行
讲完交付效率之后，我们进入另一个特别关键的环节——安全执行。今天随着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在传统的隔离、网络隔离还有访问治理这些方面，做了一套系统化的能力来应对安全执行场景提出的要求。
5OpenSandbox典型应用场景
接下来我举几个具体的应用场景例子，来看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到底要给上层的业务系统提供什么样的能力，才能够让它稳定运行。
6未来演进方向
最后，我们简单讲一下未来演进的一些方向。
首先是状态管理。今天我们还在尝试把像K8s体系中的pause/resume这种能力，给社区贡献一个更完整可用的方案。因为从长时运行的Agent场景来看，状态本身会变得越来越长运行。在极速交付的场景下，我们目前做了一些努力和尝试，但这件事还远没有到达终点。在我们的roadmap上，也还会有一些更极致的交付效率优化和处理方式。
其次是工作区间持久化。这部分主要是因为今天的Agent会越来越长时地运行在一个沙箱里面，所以它怎么样在这个沙箱里拥有一个连续的工作空间，以及怎么样把现有的volume这种能力赋予一个更统一的语义实现，都非常重要。
再有就是可观测能力。早期的时候，这部分能力我们可能没有作为第一优先级去实现。但实际上，一旦沙箱这个领域进入企业级应用之后，它就需要更强的观测能力，你要知道沙箱自己的Metrics表现是什么样的，而企业级的审计能力几乎是不可以缺失的。所以这些部分都是未来沙箱仍然会去努力做的一些方向。
OpenSandbox这个项目从去年十二月底在社区发布，到现在还是一个非常年轻、非常活跃的项目。我们刚刚也加入了CNCF landscape。AI这个领域发展特别快，未来的迭代我们还会持续去做。欢迎在场的朋友去关注、甚至去贡献这个项目，让这个项目越来越好，也把这些能力更好地回馈给整个开源社区。
作者介绍
陶宇田，阿里巴巴高级技术专家、研发TL，先后任职于亚马逊、阿里巴巴，拥有15年以上大型互联网架构设计与研发经验。技术领域覆盖中间件、推荐系统、云原生、分布式任务调度及AI基础设施等核心方向。目前担任阿里巴巴Sandbox领域负责人，主导OpenSandbox开源项目建设，聚焦AI场景下的沙箱运行时与基础设施创新，致力于构建安全、高效、可复用的AI执行环境。