A Cloudflare Containers gyorsabb és programozhatóbb agent-sandboxokat kínál

A feladat dönti el a sandbox környezetét

A Cloudflare szeptember 30-i bejelentése szerint az ügynököknek szánt sandboxokat nem előre telepítik. Ezeket a rendszer az egyes feladatokhoz, igény szerint hozza létre, ezért az indulási idő, a megfelelő fejlesztői környezet és a későbbi folytathatóság különösen fontos.

Az új durable_object ütemezési házirenddel az alkalmazás kódja futás közben választhatja ki, hogy egy sandbox milyen lemezképet és számítási erőforrást használjon. Korábban ezeket a beállításokat telepítéskor kellett rögzíteni, és minden képfájl-erőforrás kombináció külön Containers alkalmazást, illetve Durable Object névteret igényelt.

Az új megközelítéssel egyetlen Durable Object osztály egymás mellett indíthat kisebb Node.js, illetve nagyobb, Python-alapú buildfeladatokhoz készült környezeteket. Új környezet hozzáadásához így kódmódosításra van szükség, külön telepítésre nem.

A Durable Object vezérli az életciklust és a frissítéseket

A Cloudflare Containers minden példánya egy Durable Objecthez kapcsolódik. Ez stabil identitást biztosít a környezetnek, és az alkalmazás kódja ezen keresztül szabályozhatja, mikor induljon el, aludjon vagy álljon le a Container.

A vállalat szerint az új modell a frissítéseket is rugalmasabbá teszi. Egy futó Container megtarthatja az indulásakor használt képet mindaddig, amíg a kód le nem állítja. A következő indításkor az alkalmazás dönti el, melyik képet használja.

Ez lehetővé teszi például, hogy az új eszközkészletet az új sandboxok 5 százalékán próbálják ki, az aktív projekteket a jelenlegi környezetükhöz rögzítsék, vagy egy munkaterületet egy természetes ellenőrzési pontnál, például a következő munkamenetkor vagy egy pillanatkép elkészítése után állítsanak át. A visszaállítás is azzal történhet, hogy a későbbi indítások másik képet választanak.

A Cloudflare szerint 648 ezredmásodpercre csökkent a medián indulás

A Cloudflare infrastruktúrája az ütemezést a Durable Objecthez közelebb helyezi. A kapacitáskeresés először ugyanazon a gépen történik, majd szükség esetén ugyanazon a helyen belül bővül. A rendszer előnyben részesíti azokat a gépeket is, amelyek helyi tárolón már rendelkeznek a Container lemezképével vagy pillanatképével.

Az új futtatókörnyezet előkészített, még hozzá nem rendelt virtuális gépet állít helyre, új gép teljes indítása helyett. A Cloudflare szerint ez a hálózati és fájlrendszer-beállítások újrahasznosításával, az ismétlődő műveletek összevonásával és a parancs végrehajtásához nem szükséges szolgáltatások mellőzésével gyorsítja az első parancsig vezető utat.

A ComputeSDK független mérésében a medián indulási idő valamivel több mint 4 másodpercről 648 ezredmásodpercre esett. A Cloudflare saját előzetes tesztjeiben másodpercek alatt több százezer Container létrehozását is sikeresen végrehajtotta. A fájlrendszer-pillanatképek nyilvános bétában érhetők el.

Kódolási és ügynökalapú munkafolyamatokhoz készült

A Cloudflare szerint a fejlesztői ügynököknek adattárakra, csomagkezelőkre, fordítókra, tesztfuttatókra és fejlesztői szerverekre lehet szükségük. Az értékelésekhez előre ismert állapotból induló sandboxok kellenek, a megerősítéses tanulási rendszereknek pedig nagyszámú környezetet kell létrehozniuk, értékelniük és visszaállítaniuk.

A hosszabb feladatoknál a munkaterület fájljait meg kell őrizni, hogy a munka később folytatható legyen. A Cloudflare az új Containers-modellt többek között a Base44 és a Kilo Code használati eseteivel, valamint a Cursor Cloud Agents, a Devin Outposts, az OpenAI Agents API és a Claude Managed Agents integrációival kapcsolja össze.

A vállalat szerint a változások a Cloudflare Workers, a Dynamic Workers és a Durable Objects mellett adnak teljes Linux-munkaterületet igénylő ügynökfeladatokhoz használható infrastruktúrát.