A Pydantic AI ügynökei most E2B sandboxban futtathatják a kódot

Egyetlen képesség kapcsolja ki az ügynököt a gépről

A Pydantic október 22-i bejegyzése szerint az E2B mostantól natív sandboxszolgáltató a Pydantic AI-ban. Az integráció használatához az ügynök képességei közé az E2BSandbox() elemet kell felvenni. Ettől kezdve az ügynök által kiadott shell-parancsok és végrehajtott fájlműveletek egy elkülönített E2B microVM-ben zajlanak.

A sandboxba a helyi környezet tartalma nem kerül át. Ez azért fontos, mert egy kódoló ügynök önállóan dönthet arról, milyen parancsot futtat, miközben a fejlesztő gépén érzékeny fájlok, SSH-kulcsok vagy környezeti változók lehetnek elérhetők. A Pydantic példái szerint az E2BSandbox csak a végrehajtási környezetet biztosítja. A konkrét eszközöket a Coder, illetve a szűkebb Shell és FileSystem képességek adják.

Az integrációhoz nincs szükség egyedi E2B-adapterre vagy külön sablon elkészítésére. Az E2B alapértelmezett sablonja Pythont és gitet tartalmaz, a saját függőségeket pedig egyedi sablonban vagy a sandboxban futtatott pip paranccsal lehet telepíteni. Az alapértelmezett környezetben pip van, uv nincs.

A sandbox szüneteltethető és később folytatható

Az E2B sandbox alapértelmezés szerint egy órán át él, a sandbox_timeout paraméterrel azonban más időtartam adható meg. Az időkorlát elérésekor a sandbox szünetel, és nem törlődik. A Pydantic AI egy futtatás végén sem állítja le automatikusan, a létrehozó alkalmazás felel az élettartamáért. A szolgáltatás használata ezért takarítás nélkül költséget okozhat.

A Pydantic egyik szakácskönyvi példája egy JSONL API-kérésnaplókat összegző Python parancssori program javítását mutatja be. A tesztekben hibás a szerverhibák számlálása és a p95 késleltetés kiszámítása. Az első futás csak átvizsgálja a kódot és a teszteket, majd diagnosis.md fájlba menti a megállapításait. Az alkalmazás ezután szünetelteti a sandboxot, egy új háttérpéldányt kapcsol hozzá, és a második futás a korábbi diagnózis alapján javítja a hibát.

A példában a munkaterületet egy hivatkozás azonosítja, amelyhez nem szükséges hitelesítő adatot átadni. A futtatás eredménye ezt a referenciát is tartalmazza, így a következő futás ugyanazt a sandboxot választhatja ki. Az E2B a szüneteltetett környezet fájlrendszerét és memóriáját is megőrzi. A bemutatóban négy teszt fut le sikeresen, a program pedig a következő eredményt adja: requests: 4, server_errors: 2, p95_ms: 100.

A folyamat összeomlás után is folytatható

A második példa a Temporal integrációját használja annak bemutatására, hogy a sandbox a futtató Python-folyamat megszűnését is túlélheti. A két ügynökfutás egy Temporal-munkafolyamatban zajlik, közben a bemutató SIGKILL-lel leállítja a dolgozót, vagyis nincs Python-szintű finally blokk és szabályos leállítás. Egy új dolgozó indul ugyanazon a feladatvárón, a Temporal pedig újrajátssza az elmentett előzményeket.

A munkafolyamat ezután ugyanabban a sandboxban folytatja a javítást, amelyet a megszűnt dolgozó hagyott maga után. Ehhez a TemporalDurability képesség kerül az ügynökhöz az E2BSandbox, a Shell és a FileSystem mellett. A Pydantic példája 45 másodperces tevékenységi időkorlátot és legfeljebb két próbálkozást állít be.

Mit kapnak a fejlesztők?

A Pydantic szerint az integráció lehetővé teszi, hogy a kódoló ügynökök a gazdagéptől elkülönítve dolgozzanak, miközben a fejlesztő meghatározhatja a használható eszközök körét és az internet-hozzáférést is. Ez utóbbi alapértelmezés szerint engedélyezett, de az allow_internet_access=False beállítással kikapcsolható.

A két példa a munkamenetek közötti állapotmegőrzést és a dolgozófolyamat hibája utáni folytatást szemlélteti. A bemutató ugyanakkor külön ellenőrzi az ügynök munkáját: visszaállítja a tesztfájlt megbízható gazdagépi példányból, ellenőrzi, hogy a bemeneti naplók nem módosultak, majd maga futtatja le a teszteket. A sandboxokat a folyamat végén törlik, és a példa ezt az accountban is ellenőrzi.