A Cursor ügynökei már saját Daytona-gépeken is futhatnak

A végrehajtási környezet a felhasználónál marad

A Daytona szeptember 2-i bejelentése szerint a Cursor Cloud Agents minden kéréshez külön környezetet hoz létre igény szerint. Ez lehet Linux-konténer, Linux virtuális gép vagy Windows-környezet, amelyet a felhasználó által meghatározott pillanatképből (snapshot) készít a rendszer.

A hagyományos működésben a Cloud Agents olyan gépeken dolgoznak, amelyeket a Cursor üzemeltet. Ezeken klónozzák a tárolót, módosítják a fájlokat, majd futtatják a buildelést és a teszteket. A Self-Hosted Machines ezt a felállást bontja ketté: az ügynök ciklusa és a modell elérése továbbra is a Cursornál marad, az ügynök parancsait végrehajtó gép viszont ott fut, ahová a felhasználó telepíti.

Ez akkor lehet fontos, ha a kódnak egy meghatározott határon belül kell maradnia, vagy ha a futtatáshoz olyan eszközökre, függőségekre és hálózati hozzáférésre van szükség, amelyek a Cursor által üzemeltetett gépen nem érhetők el.

Minden kérés külön sandboxot kap

A Daytona által készített referenciaimplementáció a teljes életciklust kezeli. A felhasználó a Cursorban elindít egy Cloud Agentet, majd kiválasztja a csapat egyik Self-Hosted Poolját. A saját ellenőrzése alatt álló gépen futó Cursor agent worker controller átveszi a kérést, és elindítja a sandbox létrehozását.

A rendszer a kiválasztott pillanatképből létrehozza a sandboxot, beállítja a kért tárolót munkaterületként, majd elindítja benne a Cursor workert. A Cursor rövid ideig érvényes GitHub-tokent készít az adott futtatáshoz, a checkout hook pedig ezzel tölti le a kért ágat. A worker ezt követően ugyanúgy dolgozik a sandboxban, mint bármely más gépen.

Minden átvett kérés saját sandboxot és saját worker-folyamatot kap. A további üzenetek ugyanazt a workert használják az üresjárati időkorláton belül, ezért a munkaterület állapota megmarad. A worker leállása után a vezérlőgépen futó monitor törli a sandboxot. Sikertelen indítás esetén a segédprogram felszabadítja a kérést és törli a környezetet. Tartalék védelmet adnak a Daytona automatikus leállítási és leállítás utáni törlési beállításai is.

Linux és Windows, kulcsok nélkül a sandboxban

Az integráció három sandboxosztályt támogat. A Linux-konténerek a mellékelt Dockerfile-ból épülnek, a Linux virtuális gépek a Daytona daytona-vm-medium pillanatképére, a Windows virtuális gépek pedig a windows-medium környezetre épülnek.

A virtuális gépek készítői ideiglenes sandboxot hoznak létre, abból hideg pillanatképet készítenek, majd egy új ellenőrző környezetben megbizonyosodnak arról, hogy a worker elindul. A pillanatképek neve az építési receptből származik, ezért változatlan recept esetén a meglévő snapshot újra felhasználható. Szükség esetén további eszközláncok és függőségek is beépíthetők a pillanatképbe.

A vezérlőgépen marad mindkét API-kulcs. A sandbox megkapja a Cursor szolgáltatásfiókjának kulcsát, amelyre a workernek szüksége van, a Daytona kulcsát viszont nem. A pillanatképek nem tartalmaznak API-kulcsokat, a sandboxnak nincs szüksége bejövő portra, és tartós GitHub-hitelesítő adatot sem tárolnak benne. A letöltéshez kizárólag az adott futtatáshoz létrehozott token használható.

A Self-Hosted Poolokhoz Cursor Enterprise-csapat és szolgáltatásfiókhoz tartozó API-kulcs szükséges. A vezérlő a Cursor CLI laborcsatornájában érhető el. A beállításhoz a Daytona útmutatója és a Cursor hivatalos Self-Hosted Machines dokumentációja ad részletes segítséget.