本文來自微信公眾號(hào)： InfoQ ，作者：QCon，原文標(biāo)題：《OpenSandbox：重新思考 Agent 時(shí)代的 Runtime》

審核|Kitty

在AI系統(tǒng)架構(gòu)快速演進(jìn)的今天，當(dāng)軟件越來越多地以Agent形態(tài)運(yùn)行時(shí)，執(zhí)行環(huán)境已不再是一個(gè)簡單的基礎(chǔ)設(shè)施細(xì)節(jié)，它在很大程度上決定了整個(gè)系統(tǒng)的能力上限。本文整理自阿里巴巴高級(jí)技術(shù)專家、研發(fā)TL陶宇田在QCon全球軟件開發(fā)大會(huì)2026北京站的分享《OpenSandbox：重新思考Agent時(shí)代的Runtime》。

從2024年12月底開源至今，OpenSandbox在社區(qū)引起了廣泛關(guān)注。陶宇田在分享中系統(tǒng)闡述了他和團(tuán)隊(duì)在AI Agent執(zhí)行環(huán)境設(shè)計(jì)上的思考與探索，從Agent場(chǎng)景下執(zhí)行環(huán)境面臨的核心挑戰(zhàn)出發(fā)，深入解析OpenSandbox的協(xié)議優(yōu)先設(shè)計(jì)理念、批量交付效率優(yōu)化、三層安全防護(hù)體系，以及它在自主Agent、批量評(píng)測(cè)和RL訓(xùn)練等典型場(chǎng)景中的具體實(shí)踐，并簡要探討未來的演進(jìn)方向。

以下是演講實(shí)錄（經(jīng)InfoQ進(jìn)行不改變?cè)獾木庉嬚恚?/p>

1AI Agent執(zhí)行環(huán)境的新挑戰(zhàn)

最近這一兩年，我有一個(gè)特別強(qiáng)烈的體感：當(dāng)我們討論coding agent系統(tǒng)、批量評(píng)測(cè)系統(tǒng)，甚至是訓(xùn)練系統(tǒng)的時(shí)候，隨著模型能力越來越強(qiáng)，很多時(shí)候最后卡住的點(diǎn)已經(jīng)不是模型本身了，而是runtime。所以我們首先要回答一個(gè)根本性的問題：在AI Agent這個(gè)場(chǎng)景下，執(zhí)行環(huán)境到底遇到了什么樣的問題？

今天的Agent workload在業(yè)務(wù)形態(tài)上呈現(xiàn)出越來越多樣化的趨勢(shì)。我認(rèn)為有三種場(chǎng)景最具代表性。第一種是autonomous agent，即自主智能體。這類Agent的能力正在快速增強(qiáng)，它需要一個(gè)特定的文件系統(tǒng)通道去操作，需要特定的命令執(zhí)行通道。不僅如此，Agent自己能夠進(jìn)化式地去實(shí)現(xiàn)一些服務(wù)，因此它需要一種統(tǒng)一的對(duì)內(nèi)對(duì)外服務(wù)暴露方式，有些時(shí)候甚至需要暴露長連接。隨著Agent能力越來越強(qiáng)，除了要限制它本身在容器內(nèi)的行為之外，網(wǎng)絡(luò)層面上的管控也變得至關(guān)重要。這里我們需要的不是簡單地把網(wǎng)掐掉這種粗暴方式，而是更細(xì)粒度的網(wǎng)絡(luò)管控手段。

第二種是批量評(píng)測(cè)系統(tǒng)。這個(gè)場(chǎng)景的特點(diǎn)不在于單個(gè)環(huán)境有多復(fù)雜，而在于它是一個(gè)典型的批量交付場(chǎng)景，并且需要極強(qiáng)的隔離性。我們不能讓各個(gè)評(píng)測(cè)任務(wù)之間互相影響，這樣才能給整個(gè)評(píng)測(cè)體系提供一個(gè)公平的考場(chǎng)環(huán)境。

第三種是RL訓(xùn)練場(chǎng)景，這是最近一年來越來越熱門的方向。這個(gè)場(chǎng)景最大的特點(diǎn)是海量、生命周期短，并且一定要支持批量交付。在訓(xùn)練場(chǎng)景下，系統(tǒng)批量交付的效率在很大程度上直接決定了整個(gè)訓(xùn)練效率本身。

如果我們把這三個(gè)場(chǎng)景抽象出來，會(huì)發(fā)現(xiàn)它們有一些共性的訴求。在系統(tǒng)層面，你需要提供高并發(fā)、高吞吐的能力來承接sandbox的交付，需要明確的生命周期管理能力，需要可控的聯(lián)網(wǎng)能力，還需要統(tǒng)一的訪問接口和統(tǒng)一的執(zhí)行通道。今天我們看到，問題的核心已經(jīng)不是某個(gè)系統(tǒng)到底能不能讓Agent跑起來，而是我們到底有沒有一個(gè)合適的系統(tǒng)，能夠更批量、穩(wěn)定、可控地去讓這些Agent運(yùn)行。如果僅僅以“能讓Agent跑起來”為標(biāo)準(zhǔn)，很多傳統(tǒng)系統(tǒng)已經(jīng)夠用了。但在AI Agent這個(gè)時(shí)代，這個(gè)標(biāo)準(zhǔn)本身就已經(jīng)不夠了。

為什么不夠？我們來看Docker和Kubernetes這樣的系統(tǒng)。首先我要聲明，我并不是在否定這些系統(tǒng)。Docker和K8s存在了很多年，在整個(gè)軟件架構(gòu)體系里運(yùn)行得非常穩(wěn)定，也非常出色。但它們?cè)诮裉爝@個(gè)場(chǎng)景下面臨的最大問題是——從它們出生的第一天起，就不是為今天Agent這種執(zhí)行模式來設(shè)計(jì)的。

我們來看典型的K8s交付場(chǎng)景。這是一套非常成熟的、業(yè)界標(biāo)準(zhǔn)的online serving調(diào)度體系。從在線服務(wù)的視角出發(fā)，單個(gè)服務(wù)的啟動(dòng)快一點(diǎn)、慢一點(diǎn)，在絕大多數(shù)場(chǎng)景下我們都能接受。但是一旦進(jìn)入批量交付場(chǎng)景，整條鏈路上容器交付速度的微小延遲，在規(guī)?；髸?huì)被不斷地疊加放大。傳統(tǒng)K8s創(chuàng)建過程中的寫入開銷、狀態(tài)同步開銷，一旦上了規(guī)模，整個(gè)鏈路的寫擴(kuò)散和交付時(shí)間成本會(huì)呈線性增長。這樣一來，交付時(shí)間就變得非常不可控了。

訪問鏈路的需求同樣存在差距。無論是K8s還是Docker，它們并沒有提供一個(gè)典型的訪問路徑抽象。今天我們會(huì)面臨這樣一種情況：Agent在系統(tǒng)內(nèi)啟動(dòng)了自己的業(yè)務(wù)服務(wù)之后，它有HTTP、SSE，還有特定的WebSocket、VNC等多種服務(wù)暴露方式。如果這些暴露方式都以具體的、特定的形式呈現(xiàn)，讓上層業(yè)務(wù)系統(tǒng)去分別理解這些底層細(xì)節(jié)，那么整個(gè)上層系統(tǒng)也會(huì)做得越來越散。

還有一個(gè)特別關(guān)鍵的點(diǎn)，就是服務(wù)的統(tǒng)一和細(xì)粒度的網(wǎng)絡(luò)控制。這部分比較好理解。當(dāng)Agent能力越來越強(qiáng)，我們會(huì)讓它接觸很多業(yè)務(wù)數(shù)據(jù)，這時(shí)就需要更細(xì)致的管控方式來描述到底允許Agent在沙箱環(huán)境內(nèi)訪問什么樣的網(wǎng)絡(luò)資源。在很多場(chǎng)景下，尤其是在企業(yè)級(jí)場(chǎng)景下，你需要一個(gè)非常明確的描述方式，來告訴沙箱系統(tǒng)，不允許Agent觸碰到哪些網(wǎng)絡(luò)資源。這在網(wǎng)絡(luò)管控層面非常重要。

同樣缺失的還有統(tǒng)一的執(zhí)行契約。傳統(tǒng)系統(tǒng)里面實(shí)際上沒有一個(gè)真正純粹面向沙箱語義的契約描述。今天這個(gè)場(chǎng)景下，我們經(jīng)常需要為沙箱定義一個(gè)符合其自身場(chǎng)景特點(diǎn)的生命周期，以及在沙箱創(chuàng)建之后，你以什么樣的形式去與環(huán)境交互——可能需要具體的命令執(zhí)行通道，需要具體的文件系統(tǒng)準(zhǔn)備。這些都是傳統(tǒng)系統(tǒng)沒有涉及到的點(diǎn)。

所以我們可以得出結(jié)論：問題不在于今天的容器能不能跑，而在于傳統(tǒng)系統(tǒng)似乎缺失了一層面向Agent的統(tǒng)一執(zhí)行模型的描述能力。OpenSandbox正是在試圖彌補(bǔ)這一層能力模型的缺失。

2OpenSandbox的核心設(shè)計(jì)

在OpenSandbox的架構(gòu)中，最上層是傳統(tǒng)的應(yīng)用層，可以是一個(gè)傳統(tǒng)應(yīng)用，也可以是批量評(píng)測(cè)系統(tǒng)或者訓(xùn)練系統(tǒng)。對(duì)于這些系統(tǒng)，OpenSandbox在用戶交互層提供了一層統(tǒng)一的SDK接入。針對(duì)今天的AI時(shí)代，我們也提供了開箱即用的CLI、MCP等能力，方便Agent場(chǎng)景直接與OpenSandbox交互，進(jìn)行沙箱操控。本質(zhì)上，第二層的用戶交互層都是基于下面的protocol layer，即協(xié)議層。在這層協(xié)議層里，我們定義了OpenSandbox最核心的一些東西，提供了一個(gè)開箱即用的server實(shí)現(xiàn)。這一層server承載SDK進(jìn)來的調(diào)用流量。

流量進(jìn)入之后，在runtime層，目前我們提供了Docker和K8s兩種runtime引擎，業(yè)務(wù)方可以根據(jù)自己的場(chǎng)景需求去選擇。在最下面一層，對(duì)于沙箱實(shí)例層的封裝，我們提供了一些開箱即用的核心組件，比如execd組件和egress組件，分別負(fù)責(zé)不同的沙箱內(nèi)通道以及網(wǎng)絡(luò)管控的實(shí)施細(xì)節(jié)。這些能力在底層做好之后，對(duì)上層的runtime layer是一個(gè)通用能力，因此對(duì)上層可以統(tǒng)一提供一個(gè)通用的沙箱管控能力。還有一條重要的通道，就是我們剛才提到的統(tǒng)一入口訪問抽象。Agent在沙箱內(nèi)啟動(dòng)了自己的服務(wù)之后，可以通過統(tǒng)一的ingress層，最終觸達(dá)到沙箱內(nèi)部提供的服務(wù)。

如果讓我用一句話去概括OpenSandbox最核心的設(shè)計(jì)，我想說：它本身不是從某一個(gè)具體的runtime出發(fā)的，而是從能力抽象出發(fā)的。OpenSandbox從一開始就不是先去決定runtime這一層到底用Docker還是K8s，然后基于它們能提供什么能力向上反推。而是我們先嘗試定義清楚第二層——specs layer這一層，我們到底要提供什么樣的契約。

這層契約對(duì)上層的意義在于，它提供了一個(gè)穩(wěn)定的sandbox交互語義。對(duì)于上層的多端SDK，目前我們提供了五種語言的開箱即用SDK，雖然不同語言在描述能力和語法糖上有差異，但它們都基于specs這層layer，為上層接入的業(yè)務(wù)提供統(tǒng)一的沙箱語義。對(duì)于下層runtime，你今天可以用Docker，也可以換成K8s，甚至未來你可以提供一個(gè)自己自定義的、更強(qiáng)的runtime。至于最下層，我們契約里面描述的所有命令封裝通道、文件系統(tǒng)操作能力、代碼執(zhí)行能力以及服務(wù)統(tǒng)一暴露能力，都統(tǒng)一通過下面這層來承載。

這個(gè)設(shè)計(jì)思路看上去有一些抽象，但它非常重要。很多系統(tǒng)我們以前做架構(gòu)的時(shí)候會(huì)發(fā)現(xiàn)，一開始設(shè)計(jì)得很好，也很快。但是一旦SDK這一層和底層具體實(shí)現(xiàn)綁定之后，等場(chǎng)景一擴(kuò)充，整個(gè)系統(tǒng)的演進(jìn)就會(huì)變得越來越難。OpenSandbox從設(shè)計(jì)的一開始就在嘗試規(guī)避這件事。這就是protocol first，協(xié)議優(yōu)先。

接下來，我把specs layer這一層的抽象展開來看一下。核心來說，我們先定義一個(gè)穩(wěn)定的契約。這層契約最本質(zhì)的思路不是說我們要定義多少API，而是說我們?cè)诳紤]到底能不能有一個(gè)穩(wěn)定的、清晰的能力描述邊界把它講清楚。在OpenSandbox內(nèi)部，我們目前分了四個(gè)部分去描述這層契約。

第一部分比較直觀，包括create、get、list、delete以及相應(yīng)的一些語義操作接口。它實(shí)際上是在描述sandbox本身作為一個(gè)執(zhí)行環(huán)境單元，我們到底以什么樣的方式去管理它的生命周期。

第二部分是命令執(zhí)行的契約定義。隨著今天Agent系統(tǒng)能力越來越強(qiáng)，我們有更多的訴求去與sandbox環(huán)境交互——需要給環(huán)境執(zhí)行什么樣的命令，可能需要操作這個(gè)環(huán)境的文件系統(tǒng)，去給Agent準(zhǔn)備一些特定的環(huán)境，以及代碼如何執(zhí)行的通道，甚至是一些后臺(tái)任務(wù)執(zhí)行的通道。這些都是在這部分能力中描述的。

第三部分是網(wǎng)絡(luò)和策略層。在這里我們定義了更為細(xì)粒度的網(wǎng)絡(luò)管控語義和描述能力。今天對(duì)于在沙箱內(nèi)部運(yùn)行的Agent來說，簡單的網(wǎng)絡(luò)管控語義是不夠的。我們需要一種特定的契約去說清楚，你到底允許你的Agent在這個(gè)沙箱里面訪問什么樣的網(wǎng)絡(luò)資源。這些網(wǎng)絡(luò)資源可能包括網(wǎng)絡(luò)協(xié)議棧七層的具體域名，但在更細(xì)節(jié)的場(chǎng)景，比如企業(yè)級(jí)應(yīng)用中，我們甚至需要更細(xì)粒度的四層IP級(jí)別的描述能力，甚至包括網(wǎng)段級(jí)別的描述能力。你必須控制它，不能讓Agent觸達(dá)到某些網(wǎng)絡(luò)資源。

第四部分是訪問控制層。這一層主要解決的是以什么樣的通用方式來暴露對(duì)外服務(wù)的問題。交互式的Agent有各種各樣的暴露形式。如果你基于HTTP、SSE或者WebSocket都分別有一種獨(dú)立的暴露方式，整個(gè)系統(tǒng)就會(huì)做得越來越散。

綜合來看這四個(gè)部分的核心設(shè)計(jì)思路，它的最大價(jià)值在于：給上層提供的對(duì)于OpenSandbox系統(tǒng)的依賴層，是一個(gè)更為穩(wěn)定的runtime契約，而不是基于某一個(gè)具體的runtime實(shí)現(xiàn)來提供系統(tǒng)能力。這樣對(duì)于上層來說，整個(gè)系統(tǒng)才是相對(duì)穩(wěn)定的。

3池化調(diào)度與極速交付

剛才講的偏抽象層面，接下來我們要涉足一個(gè)特別關(guān)鍵的話題，那就是sandbox本身的交互效率。如果設(shè)計(jì)思路僅僅停留在架構(gòu)圖上，是遠(yuǎn)遠(yuǎn)不夠的。在真實(shí)的系統(tǒng)中，一旦上了規(guī)模，不管是評(píng)測(cè)還是訓(xùn)練場(chǎng)景，sandbox的批量交付能力在很大程度上會(huì)決定整個(gè)系統(tǒng)的上限。我們來看OpenSandbox內(nèi)部到底在批量交付能力上做了什么。

底層最直觀的做法是pool加熱備資源池。這個(gè)概念很好理解，也是大家常規(guī)能想到的方法：我們提前把資源預(yù)熱起來，降低它從零到可用環(huán)境的等待時(shí)間成本。這主要解決的就是不要從零開始冷啟動(dòng)每一個(gè)sandbox環(huán)境。

但在OpenSandbox里面，更重要的一個(gè)概念是BatchSandbox。它不是一次交付創(chuàng)建一個(gè)請(qǐng)求、創(chuàng)建一個(gè)環(huán)境，而是做了一件最關(guān)鍵的事情：把批量創(chuàng)建環(huán)境建模成了一個(gè)統(tǒng)一的對(duì)象，把批量分配語義統(tǒng)一歸屬到BatchSandbox這個(gè)對(duì)象上。這意味著整個(gè)系統(tǒng)開始以批量交付的方式來思考，而不是不停地創(chuàng)建很多個(gè)單體環(huán)境。這個(gè)轉(zhuǎn)變至關(guān)重要。

有了BatchSandbox這個(gè)能力之后，對(duì)上層我們就可以提供一個(gè)相對(duì)穩(wěn)定的批量交付能力。當(dāng)然，對(duì)于個(gè)別需要異構(gòu)注入執(zhí)行任務(wù)能力的場(chǎng)景，我們也提供了內(nèi)部可選的異構(gòu)任務(wù)補(bǔ)丁，比如你可以注入不一樣的command，或者注入不一樣的運(yùn)行環(huán)境。

接下來我們看一個(gè)具體的交付效率對(duì)比，理解它到底為什么快。K8s社區(qū)官方有一個(gè)SIG的agent sandbox項(xiàng)目，它比我們更早下場(chǎng)去做sandbox開源，大概早了一些時(shí)間。我們?cè)谧鯫penSandbox的時(shí)候，做了benchmark對(duì)比。在雙方都啟動(dòng)池化的情況下，測(cè)試對(duì)比拉起一百個(gè)sandbox的整體交付時(shí)間效率。我們甚至給agent sandbox項(xiàng)目的controller調(diào)節(jié)了不同的并發(fā)度控制。即使是對(duì)方最好的成績，OpenSandbox的整體交付效率也比它高出一個(gè)數(shù)量級(jí)左右。

為什么會(huì)有這種差異？我們來看K8s社區(qū)agent sandbox項(xiàng)目交付一百個(gè)sandbox的完整流程。首先，客戶端發(fā)送一百個(gè)sandbox的創(chuàng)建請(qǐng)求。這一百個(gè)創(chuàng)建請(qǐng)求會(huì)到傳統(tǒng)的API server。API server會(huì)在系統(tǒng)里創(chuàng)建一百個(gè)SandboxClaim這樣的資源對(duì)象——這是第一個(gè)階段，一百個(gè)資源對(duì)象創(chuàng)建的寫入開銷。然后，它的控制器在感知到這一百個(gè)SandboxClaim資源對(duì)象創(chuàng)建之后，會(huì)做相應(yīng)的處理：從已經(jīng)熱分配的池子里選出一百個(gè)pod資源，再把這一百個(gè)資源交付給SandboxClaim對(duì)象。在這個(gè)過程中，控制器首先選出一百個(gè)可用的pod，但這些pod最初歸屬的是sandbox pod熱備池。

所以它要做的操作是，把pod拿出來之后，將pod的owner reference改成剛剛創(chuàng)建的SandboxClaim資源對(duì)象。粗略算一下，在這個(gè)環(huán)節(jié)，選出一百個(gè)pod又要進(jìn)行一百次更新操作。然后當(dāng)SandboxClaim接收到這些對(duì)象之后，它又要把自己的status做一次更新，來表示已經(jīng)接收到了sandbox資源對(duì)象——這又是一百次更新操作。每一次操作都涉及背后etcd的更新動(dòng)作。整體上，在這一百個(gè)sandbox的交付鏈路上，我們看到了非常多的寫擴(kuò)散。這里面涉及創(chuàng)建一百個(gè)資源對(duì)象，更新和同步的數(shù)量則不是一百，而是幾百個(gè)這樣的操作。這個(gè)例子很好地說明了：控制面在整個(gè)過程中會(huì)出現(xiàn)非常嚴(yán)重的線性寫擴(kuò)散動(dòng)作。

我們?cè)倏碠penSandbox是怎么做的。在這種交付場(chǎng)景下，它創(chuàng)建一個(gè)BatchSandbox對(duì)象，標(biāo)識(shí)這個(gè)BatchSandbox需要交付一百個(gè)沙箱。OpenSandbox內(nèi)部的控制器會(huì)從已有的池子里，先在內(nèi)存中選出一百個(gè)可用的沙箱，然后再把這一百個(gè)沙箱比量的方式，通過標(biāo)識(shí)打到這一個(gè)BatchSandbox實(shí)例上。整個(gè)過程中，我們先創(chuàng)建一個(gè)實(shí)例。update的時(shí)候，只是針對(duì)這一個(gè)BatchSandbox資源對(duì)象來做更新操作。所以整體上，我們的思路是：用更少的資源對(duì)象寫入和狀態(tài)同步處理，來做更少的協(xié)調(diào)步驟，從而在批量吞吐交付場(chǎng)景上實(shí)現(xiàn)更高的交付效率。

現(xiàn)在我們?cè)賮砜催@件事，OpenSandbox所做的本質(zhì)上不是簡單提供了一個(gè)池子，而是在整個(gè)交付鏈路上做了梳理，讓系統(tǒng)層面上的協(xié)調(diào)開銷更小。

4Agent場(chǎng)景下的安全執(zhí)行

講完交付效率之后，我們進(jìn)入另一個(gè)特別關(guān)鍵的環(huán)節(jié)——安全執(zhí)行。今天隨著Agent能力越來越強(qiáng)，安全這個(gè)話題是繞不開的。所有需要在企業(yè)級(jí)部署的場(chǎng)景下，都會(huì)關(guān)心你的sandbox到底怎樣能讓Agent在一個(gè)安全可控的環(huán)境里運(yùn)行。在安全這個(gè)層面上，OpenSandbox目前分了大概三層來構(gòu)建防護(hù)體系。

第一層是隔離。這件事最核心的是容器層面的隔離，也是大家最好理解的一個(gè)層面。這一層本質(zhì)上是在增加不可信工作負(fù)載和底層宿主機(jī)之間的隔離邊界。從隔離本身的技術(shù)手段上來說，今天可能有不同的實(shí)現(xiàn)方式。比如可以基于gVisor這種用戶內(nèi)核態(tài)的統(tǒng)一隔離方式，或者也可以有像Kata runtime這種更強(qiáng)的底層實(shí)現(xiàn)，它有可能調(diào)用Firecracker VMM這種具體方案，直接提供VM層面上的更強(qiáng)隔離能力。但不管哪種技術(shù)路線，本質(zhì)上都是通過不同的方式去實(shí)現(xiàn)不可信工作負(fù)載和宿主機(jī)之間邊界的加固，防止在Agent不可控的情況下發(fā)生內(nèi)核逃逸，影響到同一宿主機(jī)的其他sandbox環(huán)境。

第二層是網(wǎng)絡(luò)控制。今天Agent的形態(tài)不是傳統(tǒng)的離線作業(yè)，我們沒有辦法簡單地把它把網(wǎng)關(guān)掉就了事。幾乎所有的Agent都有訪問網(wǎng)絡(luò)的訴求——它需要訪問GitHub，需要訪問包管理器，需要跟模型交互，所以它必須跟模型的API是通的。很多業(yè)務(wù)系統(tǒng)的Agent還需要訪問自己業(yè)務(wù)系統(tǒng)的服務(wù)。這里面最直接的一個(gè)能力訴求就是：你到底能不能提供更細(xì)粒度的管控方式。一方面，你要能夠描述這個(gè)Agent今天允許訪問什么樣的網(wǎng)絡(luò)資源，包括具體你提供的服務(wù)的網(wǎng)絡(luò)資源。另一方面，在企業(yè)級(jí)應(yīng)用里，其實(shí)還有更強(qiáng)的反向要求：你到底不能訪問哪些資源，因?yàn)楹芏噘Y源在企業(yè)級(jí)場(chǎng)景里會(huì)非常敏感。這種描述能力，除了允許和拒絕的語義之外，也有不同的描述層級(jí)需求：你到底是需要描述簡單的域名，還是需要描述特定的網(wǎng)段？這些在整個(gè)網(wǎng)絡(luò)協(xié)議棧上，基本上會(huì)涉及七層和四層的不同描述場(chǎng)景需求。

OpenSandbox在這里做的egress組件抽象，在邏輯上大概分兩層實(shí)現(xiàn)。第一層是做了一個(gè)DNS劫持。這層劫持是一個(gè)透明的劫持，主要目的是在域名隔離能力上做第一道攔截。我們的做法是，egress組件在sandbox啟動(dòng)、準(zhǔn)備交付給業(yè)務(wù)之前，就已經(jīng)劫持掉了它的DNS解析這一道。這樣在整個(gè)安全控制層面上，我們就有機(jī)會(huì)對(duì)那些危險(xiǎn)的域名在訪問時(shí)，在域名解析階段就把它攔截掉。第二層是底層的網(wǎng)絡(luò)過濾層。這層偏更底層一點(diǎn)，主要是對(duì)底層IP級(jí)別以及IP網(wǎng)段級(jí)別的過濾。這時(shí)候會(huì)有更強(qiáng)的管控能力，防止Agent知道了某些特定的IP之后繞過DNS，直接從IP這一層走出口達(dá)成對(duì)外訪問的目的。

第三層是統(tǒng)一治理的訴求。這一層我們要提供一些方式，除了對(duì)外暴露服務(wù)的形式統(tǒng)一之外，它本身也是一個(gè)平臺(tái)治理和審計(jì)的重要入口。ingress統(tǒng)一架構(gòu)讓我們可以在真正的入向請(qǐng)求觸達(dá)sandbox之前，做很多中間攔截層的操作。最直接的例子就是最近我們上了一個(gè)功能：基于OpenSandbox自身對(duì)外暴露服務(wù)的訪問頻率，來實(shí)現(xiàn)TTL GC時(shí)間的自動(dòng)刷新能力。像訪問的統(tǒng)一審計(jì)功能，也可以在內(nèi)部這一層做相應(yīng)增強(qiáng)。這些功能本身對(duì)整體的Agent進(jìn)程是無侵入的。這一點(diǎn)非常重要，Agent不需要感知具體環(huán)境的細(xì)節(jié)做了哪些攔截。

綜合來看，OpenSandbox在傳統(tǒng)的隔離、網(wǎng)絡(luò)隔離還有訪問治理這些方面，做了一套系統(tǒng)化的能力來應(yīng)對(duì)安全執(zhí)行場(chǎng)景提出的要求。

5OpenSandbox典型應(yīng)用場(chǎng)景

接下來我舉幾個(gè)具體的應(yīng)用場(chǎng)景例子，來看OpenSandbox在這些場(chǎng)景里面到底提供了什么樣的能力，以及它處在一個(gè)什么樣的位置。

第一個(gè)例子是autonomous agent的架構(gòu)演進(jìn)。在AI系統(tǒng)剛開始的時(shí)候，有一種很典型的運(yùn)行模式：模型生成一段代碼，發(fā)出代碼執(zhí)行請(qǐng)求，沙箱在里面負(fù)責(zé)運(yùn)行這段代碼，運(yùn)行之后把結(jié)果交付給模型，模型再基于結(jié)果做后續(xù)推理處理。在這個(gè)過程中，sandbox充當(dāng)?shù)慕巧褪巧鐓^(qū)里常說的sandbox as a tool——一個(gè)純粹的工具角色。社區(qū)里之前有人打了一個(gè)特別形象的比喻，說這是頭身分離的架構(gòu)：頭是在左側(cè)Agent的獨(dú)立應(yīng)用里，身體或者腳在sandbox沙箱里。這種模式簡單直接，但它的上限也會(huì)遇到問題。一旦你的Agent進(jìn)化到執(zhí)行更復(fù)雜任務(wù)的時(shí)候，我們希望它有一個(gè)獨(dú)立的環(huán)境，讓它真正地跑起來。這時(shí)候很多人不會(huì)陌生的一種模式，就是干脆直接把Agent裝進(jìn)沙箱里，腦身結(jié)合了之后，傳統(tǒng)應(yīng)用可以給它下發(fā)更復(fù)雜的指令去做相應(yīng)的交互。

這讓我想到最近非?；鸬腛penClaw這個(gè)項(xiàng)目。它的極簡架構(gòu)圖和這種腦身結(jié)合的模式?jīng)]有本質(zhì)區(qū)別。但是OpenClaw做了一件特別重要的事，它在工程優(yōu)化層面給Agent加了非常多的工程優(yōu)化手段，也就是說它已經(jīng)在某種程度上踐行了我們今天說的agent harness。不過玩過OpenClaw的朋友應(yīng)該都知道，要充分發(fā)揮OpenClaw的潛力，一個(gè)很重要的前提就是要給它充分的授權(quán)。而一旦給了它充分的授權(quán)，你會(huì)發(fā)現(xiàn)前面講到的所有安全管控手段必須全部加上，否則這個(gè)OpenClaw本身就是一個(gè)非常危險(xiǎn)的因素。

第二個(gè)例子是批量評(píng)測(cè)場(chǎng)景。這個(gè)場(chǎng)景相對(duì)直觀一些。評(píng)測(cè)框架本身在上層負(fù)責(zé)了任務(wù)的編排和調(diào)度，OpenSandbox在這里面重點(diǎn)提供的是執(zhí)行層面上的批量執(zhí)行能力。由于我們前面講到的BatchSandbox機(jī)制和安全隔離能力，評(píng)測(cè)系統(tǒng)可以將大量評(píng)測(cè)任務(wù)以批量的方式交付到沙箱環(huán)境中，各個(gè)任務(wù)之間嚴(yán)格隔離，保證了評(píng)測(cè)的公平性。

第三個(gè)例子是RL訓(xùn)練場(chǎng)景。這是最近一年多來越來越多被涉及到的場(chǎng)景。在這個(gè)場(chǎng)景里，sandbox本身會(huì)面臨兩部分的壓力。一部分是批量層面的壓力。這種壓力來自于訓(xùn)練系統(tǒng)——它不是偶爾申請(qǐng)幾個(gè)環(huán)境，而是為了充分發(fā)揮前向GPU的推理性能和壓榨它的性能，持續(xù)不斷地去申請(qǐng)環(huán)境、使用環(huán)境、再申請(qǐng)環(huán)境。從批量交付的量級(jí)上來說，這是一個(gè)海量的場(chǎng)景。另一部分是執(zhí)行層面的壓力。訓(xùn)練場(chǎng)景需要收集Agent在沙箱內(nèi)的trajectory數(shù)據(jù)，所以沙箱內(nèi)部的Agent自身就會(huì)有跟模型的多輪交互，然后基于模型的指令和數(shù)據(jù)，去做一些自主性非常高的行為。在這個(gè)場(chǎng)景里面，前面我們講到的所有安全執(zhí)行手段，在這里全部都有。這個(gè)場(chǎng)景也很好詮釋了，在這些極限場(chǎng)景下，sandbox到底要給上層的業(yè)務(wù)系統(tǒng)提供什么樣的能力，才能夠讓它穩(wěn)定運(yùn)行。

6未來演進(jìn)方向

最后，我們簡單講一下未來演進(jìn)的一些方向。

首先是狀態(tài)管理。今天我們還在嘗試把像K8s體系中的pause/resume這種能力，給社區(qū)貢獻(xiàn)一個(gè)更完整可用的方案。因?yàn)閺拈L時(shí)運(yùn)行的Agent場(chǎng)景來看，狀態(tài)本身會(huì)變得越來越長運(yùn)行。在極速交付的場(chǎng)景下，我們目前做了一些努力和嘗試，但這件事還遠(yuǎn)沒有到達(dá)終點(diǎn)。在我們的roadmap上，也還會(huì)有一些更極致的交付效率優(yōu)化和處理方式。

其次是工作區(qū)間持久化。這部分主要是因?yàn)榻裉斓腁gent會(huì)越來越長時(shí)地運(yùn)行在一個(gè)沙箱里面，所以它怎么樣在這個(gè)沙箱里擁有一個(gè)連續(xù)的工作空間，以及怎么樣把現(xiàn)有的volume這種能力賦予一個(gè)更統(tǒng)一的語義實(shí)現(xiàn)，都非常重要。

再有就是可觀測(cè)能力。早期的時(shí)候，這部分能力我們可能沒有作為第一優(yōu)先級(jí)去實(shí)現(xiàn)。但實(shí)際上，一旦沙箱這個(gè)領(lǐng)域進(jìn)入企業(yè)級(jí)應(yīng)用之后，它就需要更強(qiáng)的觀測(cè)能力，你要知道沙箱自己的Metrics表現(xiàn)是什么樣的，而企業(yè)級(jí)的審計(jì)能力幾乎是不可以缺失的。所以這些部分都是未來沙箱仍然會(huì)去努力做的一些方向。

OpenSandbox這個(gè)項(xiàng)目從去年十二月底在社區(qū)發(fā)布，到現(xiàn)在還是一個(gè)非常年輕、非?；钴S的項(xiàng)目。我們剛剛也加入了CNCF landscape。AI這個(gè)領(lǐng)域發(fā)展特別快，未來的迭代我們還會(huì)持續(xù)去做。歡迎在場(chǎng)的朋友去關(guān)注、甚至去貢獻(xiàn)這個(gè)項(xiàng)目，讓這個(gè)項(xiàng)目越來越好，也把這些能力更好地回饋給整個(gè)開源社區(qū)。

作者介紹

陶宇田，阿里巴巴高級(jí)技術(shù)專家、研發(fā)TL，先后任職于亞馬遜、阿里巴巴，擁有15年以上大型互聯(lián)網(wǎng)架構(gòu)設(shè)計(jì)與研發(fā)經(jīng)驗(yàn)。技術(shù)領(lǐng)域覆蓋中間件、推薦系統(tǒng)、云原生、分布式任務(wù)調(diào)度及AI基礎(chǔ)設(shè)施等核心方向。目前擔(dān)任阿里巴巴Sandbox領(lǐng)域負(fù)責(zé)人，主導(dǎo)OpenSandbox開源項(xiàng)目建設(shè)，聚焦AI場(chǎng)景下的沙箱運(yùn)行時(shí)與基礎(chǔ)設(shè)施創(chuàng)新，致力于構(gòu)建安全、高效、可復(fù)用的AI執(zhí)行環(huán)境。