OpenSandbox：重新定义AI Agent时代的运行时环境（北京）

【科技创新】
审核|Kitty

在AI系统架构快速演进的当下，越来越多的软件以Agent（智能体）的形式运作，使得执行环境已不再仅仅是基础设施，而是成为了系统能力上限的关键因素。本文整理自阿里巴巴高级技术专家、研发TL陶宇田在QCon全球软件开发大会2026北京站的分享《OpenSandbox：重新思考Agent时代的Runtime》。

自2024年12月底开源以来，OpenSandbox在技术社区中引起了广泛关注。陶宇田在分享中系统阐述了其团队在AI Agent执行环境设计上的思考与探索，从Agent在不同场景下的执行挑战出发，深入解析了OpenSandbox的协议优先设计理念、批量交付效率优化、三层安全防护体系，以及它在自主Agent、批量评测和强化学习训练等典型场景中的具体实践，并简要探讨了其未来可能的发展方向。

以下是演讲实录（经InfoQ进行不改变原意的编辑整理）。

1. AI Agent执行环境面临的新挑战

近年来，我感受到一个强烈的趋势：当我们谈论coding agent系统、批量评测系统，甚至是训练系统时，随着模型能力的提升，最终限制系统表现的已不再是模型本身，而是runtime（运行时）。因此，我们首先要回答一个根本性问题：在AI Agent这一特定场景下，执行环境到底遇到了哪些问题？

当前的Agent作业呈现出业务形态多样化的特点。我认为最具有代表性的有三种场景：第一种是自主Agent，这类Agent的能力正在迅速增强，其不仅需要特定的文件系统通道和命令执行通道，还需要统一的服务暴露方式，包括长连接支持。随着Agent能力提升，除了需要限制它在容器中的行为外，网络层面的管控也变得尤为关键。

第二种是批量评测系统，其主要痛点不在于单个环境的复杂度，而在于它需要极强的隔离性。我们不能让评测任务之间互相干扰，只有这样才能营造一个公平稳定的评测环境。

第三种是RL（强化学习）训练场景，这一方向近年来愈发火热。它最大的特点是任务海量、生命周期短且必须支持批量交付，因此在训练场景下，系统如何提高批量交付效率，显得尤为关键。

如果我们将这三个场景进行抽象，会发现它们有一些共通的需求。例如，系统必须支持高并发、高吞吐的执行能力；具备清晰的生命周期管理；提供可控的网络连接方式；以及支持统一的访问接口和稳定的执行通道。因此，关键问题不再是今天系统能否运行Agent，而是我们是否拥有合适的设计，能够更批量、更稳定、更可控地承载这些Agent的运行。而如果只以“能让Agent跑起来”为评判标准，很多传统系统已经足够胜任，但在AI时代，这样的标准显然已经不够。

为什么不够呢？让我们以Docker和Kubernetes为例进行分析。虽然两者在传统应用中运行稳定且表现卓越，但在当前Agent应用场景下的核心问题——从其诞生之初，它们并不是为Agent这一新型执行模式所设计的。

在典型的K8s交付场景中，我们看到一套成熟的在线服务调度体系，所支持的单个服务启动时间在大多数情况下都能够被接受。然而，一旦进入批量交付的场景，比如启动一百个sandbox环境，由于容器创建过程中需要的写入开销、状态同步开销，整个交付时间在大规模情况下会变得不可控。这些延迟会在整体批量交付链路中不断叠加和放大。

此外，访问链路的抽象缺失也是一大问题。无论是K8s还是Docker，它们缺乏对Agent服务暴露方式的统一抽象。当Agent启动自己的服务时，可能涉及HTTP、SSE，甚至是WebSocket、VNC等多种协议，如果这些暴露形式都以具体、独立的方式呈现，上层系统则需要分别理解每一个底层细节，进而导致系统设计越来越分散。

还有一个特别重要的点是，如何实现统一的网络控制。随着Agent能力增强，它们很可能接触到大量业务数据，此时就需要更细致的管控方式，以确保它们只能访问特定的网络资源。在一些企业级应用场景中，我们甚至需要描述到四层IP级别，甚至网段级别的网络访问限制。

同样，传统系统中并没有面向沙箱语义的统一执行契约。今天，我们经常需要为沙箱定义符合其自身场景特点的生命周期和交互方式，比如代码执行通道、文件系统操作方式等，这些都超出了传统系统所能提供的能力范畴。

因此，我们可以得出结论：问题的关键并非是传统容器是否能运行，而是传统系统缺乏一套面向Agent的统一执行模型。而OpenSandbox正是在这层模型上进行了探索与设计。

2. OpenSandbox的核心设计理念

在OpenSandbox的架构中，最上层是传统应用层，也可以是批量评测系统或训练系统。对于这些系统，我们提供了一层统一的SDK接入。同时，在AI时代，我们也提供了开箱即用的CLI、MCP等能力，方便Agent直接与OpenSandbox系统交互和操控。

流量进入系统后，首先会经过runtime层，目前支持Docker和K8s两种runtime引擎。用户可根据自己的需求灵活选择。在最底层，我们提供了一些核心组件，如execd组件和egress组件，分别负责不同的沙箱内通道与网络管控实施细节。这些能力在底层完成封装后，会统一为上层runtime层提供通用的执行控制能力。

同时，在系统内提供了一个统一入口访问抽象，使Agent在沙箱中启动服务后，能够更为一致地触达其提供的服务。

简单来说，如果用一句话概括OpenSandbox最核心的设计理念，那便是：它从不以某一个具体的runtime为起点，而是从能力抽象出发。我们首先定义的是一层协议层，即 specs layer，旨在描述出一个稳定、清晰的沙箱交互契约。对于上层的多端SDK，目前我们提供了包括五种语言在内的开箱即用SDK，所有SDK均基于specs layer，为上层业务系统提供统一的沙箱语义；对于下层runtime，你也可以选择Docker、K8s，甚至未来你可以提供一个更强大的runtime实现。所有这些底层所需的能力，如命令执行通道、文件系统操作、服务暴露方式等，都将统一通过 specs layer 来承载。

这种设计思路在系统架构中显得较为抽象，但实际上是至关重要的。很多系统在初期设计得非常好，也很快。然而，一旦SDK层与底层实现绑定后，随着场景的扩展，系统的演进就会变得越来越复杂。OpenSandbox从设计伊始便试图避开这一困境，这就是所谓的 "protocol first"，协议优先。

接下来，我们再详细看看这一层协议的抽象构造。其核心思路是定义一个稳定的契约，本质不是定义多少API，而是在考虑能否通过这种契约，清晰地描述执行环境的能力边界。在OpenSandbox内部，我们将其契约抽象为四个部分：

第一部分用于描述sandbox作为执行环境单元的生命周期管理，包括create、get、list、delete等基本操作接口。

第二部分专注于命令执行的契约定义，涵盖环境操作、文件系统访问、代码执行渠道及后台任务支持等内容。

第三部分则是关于网络和策略层的抽象，我们致力于在这一层实现更细粒度的网络资源管控，包括域名、IP及网段级别的控制。

第四部分是访问控制层，解决如何统一对外暴露服务的问题。如果每个Agent都采取独立的网络暴露方式，系统设计将变得越来越碎片化。

从这四个部分的架构设计可以看出，OpenSandbox的核心价值在于：它为上层系统提供了一个更为稳定的runtime契约，而非绑定于某个具体的runtime实现。这样做的意义在于减少上层对底层实现的耦合，使整个系统更具可扩展性和稳定性。

3. 池化调度与极速交付方案

刚才我们探讨了架构层面的设计，接下来需要进入一个更为关键的话题：即关于sandbox交付效率的优化。如果设计思路仅停留在架构图上，是远远不够的。在实际系统应用中，一旦规模扩大，sandbox的批量交付能力会直接影响到整个系统的上限。

在底层，我们采用了池化预热资源池的方式，也就是提前将沙箱环境预置并激活，以减少冷启动时间。这种方式虽然直观，但并非OpenSandbox的核心亮点。

更关键的是，我们引入了一种名为BatchSandbox的机制，将批量执行环境建模为单一对象。这使得整个系统可以从多个单体沙箱的创建与交付，转向以批量交付为基础的统一模型。这种转变对于提升系统效率具有重要意义。

借助BatchSandbox这一能力，我们能够为上层系统提供一个相对稳定的批量交付机制。当然，对于一些需要异构执行任务的场景，我们也加入了内部可选的异构补丁，允许为每个环境注入不同的命令或运行环境。

为了验证这一方案的实际效果，我们在系统内部进行了一个benchmark测试，将OpenSandbox与K8s社区的agent sandbox项目进行对比。双方都在基于池化资源的情况下运行。我们测试了拉起一百个sandbox的整体交付效率。即便对方在并发度控制上做出最优调整，OpenSandbox的整体交付效率仍高出一个数量级。

为何会出现这种差异？我们来看K8s社区agent sandbox项目的交付全流程。当客户端发送一百个sandbox创建请求时，这些请求将进入K8s的API server。API server会在系统中创建一百个SandboxClaim资源对象，这是第一个阶段，涉及一百次写入操作。然后，它的控制器会在感知到这一百个SandboxClaim对象后进行处理，会从热备池中选出一百个可用pod，并将这些pod分配给SandboxClaim对象。

这个过程中，控制器首先需要选出可用pod，并将其owner reference修改为刚创建的SandboxClaim资源对象，需要进行一百次更新操作。接着，当SandboxClaim接收到这些对象后，还要对其自身状态进行更新，说明已收到sandbox资源对象，这也需要一百次更新操作。其实，每一次写入和状态同步的背后都有etcd的操作记录。在整个一百个sandbox的交付链路上，我们将看到许多写扩散问题，如创建一百个资源对象，以及几十次的状态更新操作。

而OpenSandbox则采用了一种更为高效的方式。它会创建一个BatchSandbox对象，明确标识出这批任务需要交付一百个沙箱。然后，其内部控制器会在内存中预先选好这100个可用沙箱，并将它们以批量方式归并至该BatchSandbox实例。在整个交付链路中，我们仅需创建一个BatchSandbox对象，并对它进行一次更新操作，而不会有几百次的写操作。这意味着，我们在批量交付链路上做了系统优化，使得整个交付流程所需的资源对象写入与状态同步大大减少，从而在吞吐效率上实现显著提升。

总结来看，OpenSandbox并不是仅仅提供一个池子，而是在整个交付链路上对系统协调机制进行了重构，使得资源调度与交付过程更加高效和可控。

4. AI Agent场景下的安全执行方案

在讲完交付效率之后，我们进入安全执行这一关键议题。随着Agent能力的增强，安全性问题变得不可避免。在所有需要部署的场景中，企业最关心的问题之一就是如何确保Agent在一个安全可控的环境中运行。

为此，OpenSandbox构建了一套三层安全体系。第一层是隔离，这在整个系统中居于基础地位，也是最容易被理解的一层。无论是通过gVisor等用户内核态的隔离方法，还是Kata runtime等调用Firecracker VMM的更强实现方案，其核心目的都是在不可信工作负载与宿主机之间构建更坚固的隔离边界，防止在Agent失控的情况下造成内核逃逸，影响同一宿主机内其他sandbox环境的运行。

第二层是网络控制。与传统离线作业不同，如今的Agent大多都需要与外界进行网络交互。它们可能需要访问GitHub、包管理器、与模型API沟通，甚至需要访问企业内部的服务。这时，如何描述和管理这些网络访问需求，就成为了一大关键。

除了允许的访问资源，企业往往还有更强的反向要求：即明确哪些资源是禁止访问的。在一些敏感场景中，我们甚至需要进行到IP网段级别的管控，以确保安全性。

在实现上，我们通过egress组件进行了抽象，逻辑上分为两层。第一层是DNS劫持，这是在network isolation层的第一道拦截。egress组件会在sandbox启动前就劫持其DNS解析过程，使得任何尝试访问不安全域名的行为都在解析阶段被拦截。第二层则是底层网络过滤层，实现了从IP、网段等层面的更加精细控制，防止Agent获取某些特定网络资源信息。

这种分层的网络控制机制，使得OpenSandbox不仅能够高效运行Agent，还能在安全层面提供全方位的防护。