A ZenML a Daytonát választotta a hosszú életű kódolóügynökökhöz
A ZenML jelenleg a Daytona sandboxplatformját használja hosszú interakciókra épülő kódolóügynökeihez. A vállalat szerint a döntésben az SSH-hozzáférés, a böngésző futtatása, a munkamenetek megőrzése és a hálózati korlátozások együttes kezelése volt fontos.
- A ZenML jelenlegi választása a Daytona a hosszú interakciókra épülő kódolóügynökökhöz.
- A követelmények között szerepel a Chromium, az OpenSSH, az állapot-visszaállítás és a hálózati korlátozás.
- A Daytona virtuális gépei memória-megőrző szüneteltetést és folytatást dokumentálnak.
- A konténeres és virtuális gépes életciklus eltérő, ezért a sandbox típusa a döntés része.
- A szolgáltatóintegrációt a ZenML úgy választotta le, hogy később felülvizsgálhassa a döntést.
A kódolóügynöknek teljes fejlesztési környezetre van szüksége
A ZenML szeptember 15-én közzétett elemzése szerint egy kódolóügynöknek nem elég parancsokat futtatnia. A sandboxban függőségeket kell telepítenie, böngészőt kell indítania, valamint tesztelnie kell az általa módosított alkalmazást. Ha a munka több interakción keresztül zajlik, a végrehajtási környezet a termék részévé válik.
A vállalat egy sandboxhoz egy interaktív kódolóügynököt rendel. Az elvárások között szerepel a fej nélküli Chromium futtatása, a valódi SSH-hozzáférés, a pillanatképek készítése és visszaállítása, az üresjárati életciklus kezelése, a fejlesztői szerver elérhetővé tétele, valamint a kimenő hálózati kapcsolatok korlátozása.
A ZenML hangsúlyozza, hogy az összehasonlítás a szolgáltatók 2026 szeptemberében áttekintett dokumentációján alapul, és nem teljesítménymérés.
A megőrzés többféle állapotot jelenthet
A ZenML szerint a legfontosabb különbség az, hogy mi marad meg a számítás leállásakor. A fájlrendszer megőrzése a forrásfájlokat, a telepített függőségeket és a létrehozott fájlokat védi, a futó folyamatokat azonban újra kell indítani.
A memória megőrzése ezzel szemben a futó folyamatok és azok memóriabeli állapotának megtartását jelentheti. Ide tartozhat maga az ügynök, a Chromium és a fejlesztői szerver is. Az alkalmazás munkamenetének megőrzése külön problémát kezel: az ügynöknek a folyamat újraindítása után is ismernie kell a beszélgetés állapotát, a feladat előrehaladását és a munkaterületre mutató hivatkozásokat.
A szolgáltatók által használt „stop”, „pause”, „sleep” és „snapshot” kifejezések jelentése nem egységes. A ZenML ezért külön kezeli, hogy egy ellenőrzési pont lemezt, memóriát vagy mindkettőt tartalmaz-e, illetve hogy az inaktivitás szüneteltetést, leállítást vagy a memória elvesztését okozza.
Miért esett a választás a Daytonára?
A ZenML jelenlegi választása, a Daytona, több szükséges képességet egy integrációban kínál. Dokumentációja kezelt OpenSSH-hozzáférést ír le, beleértve a VS Code Remote-SSH használatát is. Így a fejlesztők szabványos eszközökkel vizsgálhatják és hibakereshetik a környezetet, külön SSH-átjáró építése nélkül.
A Daytona virtuális gépes kínálata memória-megőrző szüneteltetést, folytatást és elágaztatást dokumentál. A konténeres megoldás eltérő módon működik: a leállítás megőrzi a fájlrendszert, de törli a memóriát, és a konténerek nem támogatják a szüneteltetést és folytatást.
A szolgáltató fejlesztői szerverek előnézetét, kimenő hálózati korlátozásokat és szerveroldali hitelesítőadat-helyettesítést is dokumentál. A ZenML szerint ez csökkenti a hozzáférési és életciklus-kezelési infrastruktúra mennyiségét, amelyet saját magának kellene felépítenie.
A beállítások azonban figyelmet igényelnek. A hálózati szabályzat a számlázási csomagtól függ, a magasabb csomagokban alapértelmezett internet-hozzáférés lehet aktív. Az előnézeti tokenek hatóköre sem azonos: a szabványos tokenek a teljes sandboxhoz férhetnek hozzá, míg az aláírt előnézeti URL-ek egy adott portra korlátozható, lejáró és visszavonható hozzáférést adnak. A titkos kulcsok helyettesítése kimenő HTTPS-fejlécekre korlátozódik, a kérések törzsére és lekérdezési paramétereire nem terjed ki általánosan.
Az alternatívák és a szolgáltatófüggetlen réteg szerepe
A ZenML több alternatívát is életképesnek tart. Az E2B fájl- és memóriaalapú szüneteltetést, időkorlát utáni automatikus szüneteltetést és ügynökpéldákat kínál, de a dokumentált SSH-megoldás további beállítást igényel. A Runloop Agent Gateway rendszere a fejlesztői környezeten kívül tartja a szolgáltatói hitelesítőadatokat, és böngészővezérlést is dokumentál.
A Vercel Sandbox hálózati korlátozásokat, szerveroldali hitelesítőadat-injektálást és leállításkor automatikus fájlrendszer-pillanatképeket kínál, viszont az interaktív parancssori héj önmagában nem igazolja az OpenSSH- vagy Remote-SSH-kompatibilitást. A Cloudflare Sandboxes Workers-integrációt, kimenő kérések elfogását, fejlesztői szerverek közzétételét és az R2-n keresztüli könyvtármentést, illetve visszaállítást dokumentál, de az üresjárati alvás leállítja a konténert, ezért a folyamatokat újra kell indítani. A Modalnál a dokumentált 24 órás sandboxkorlát és az inaktivitási időkorlát szintén külön életciklus-kezelést tehet szükségessé.
A ZenML nem készít összesített pontszámot. A vállalat szerint egy hiányzó kötelező képességet nem lehet olcsóbb számítási költséggel ellensúlyozni, a „nem ellenőrzött” állapotot pedig nem tekinti azonosnak a támogatás hiányával.
A Daytona-integrációt a ZenML szolgáltatófüggetlen réteg mögé helyezte, hogy később felülvizsgálhassa a döntést. Ez az adapter csökkentheti a migráció munkáját, de nem teszi ingyenessé a cserét. A különbségeket láthatóan kell tartani, például azt, hogy milyen hozzáférést használ a fejlesztő, hogyan korlátozható és vonható vissza az előnézeti hozzáférés, illetve hol tárolják a hitelesítőadatokat.
A költségeket a ZenML szerint csak azonos munkaterheléssel lehet érdemben összevetni. Ebbe beleértendő az erőforrás-kiosztás, az aktív futtatás, a modell- vagy emberi válaszra várakozás, az üresjárati megőrzés, a pillanatképek és a hálózati adatátvitel, valamint az életciklus kezeléséhez szükséges fejlesztési munka.
