OpenSandbox：重新思考 Agent 时代的 Runtime

在 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 在这个沙箱里面访问什么样