A karcsúbb végrehajtási környezetek és a kódot futtató ügynökök jobban megfelelnek a nyitott végű feladatokhoz, amelyeknél a túl merev összehangolás korlátozhatja a modell teljesítményét.
Ezáltal a kódfuttatás és az elkülönített futtatókörnyezetek használata az ügynökalapú rendszerek alapvető architekturális kérdésévé vált.
Tesztjeinkben az Agents SDK akár hatszorosára csökkentette a kódot futtató ügynökök létrehozásához szükséges kód mennyiségét és a fejlesztés összetettségét.
Az ügynökrendszerek fejlődését sokáig az összehangolás javítása hajtotta: jobb utasítások, eszközfelületek, kontextuskezelés és szigorúbb vezérlési folyamatok. A kódoló ügynökök képességeinek fejlődésével azonban kezd eltolódni ez az egyensúly.
Számos nyitott végű munkafolyamatban már nem maga az ügynökciklus jelenti a szűk keresztmetszetet, hanem a végrehajtási réteg: az elkülönített környezet, ahol a modell kódot ír, parancsokat futtat, megvizsgálja az eredményeket, majd ezek alapján tovább dolgozik. Ahogy egyre több feladatszintű érvelés kerül ebbe a környezetbe, egyszerűsíteni kell a környező összehangolást, hogy a modell teljes mértékben kibontakoztathassa képességeit.
Pontosan ezt teszi lehetővé az Agents SDK új verziója. A korai hozzáférés során végzett tesztjeink alapján a rendszer nem egy újabb keretrendszer-logikai réteget épít be, hanem modulárisabbá és jobban összeállíthatóvá teszi a végrehajtási réteget, így a rendszer többi része karcsú maradhat.
A végrehajtási környezet tervezésében divatossá vált a környezetet a lehető legegyszerűbb, még hatékony formájára csökkenteni. Általánosságban a végrehajtási környezet a modellt körülvevő szoftver: az a réteg, amely a kontextust, az eszközöket, a vezérlési folyamatot és a visszacsatolási hurkokat kezeli, hogy a modell megbízhatóan dolgozhasson.
Az elmúlt néhány évben az ügynökök teljesítményének számos javulása e réteg megerősítéséből származott. A jobb eszközök, memória és információ-visszakeresés, a részletesebb feladatfelbontás és a szorosabb összehangolás gyakran megbízhatóbbá és hatékonyabbá tette a rendszereket. Ebben a megközelítésben a fejlődés nagyrészt azt jelentette, hogy több feladatlogikát kódoltak a modellt körülvevő szoftverbe.
Ez a minta azonban gyengülni kezdett, legalábbis a nyitott végű feladatok egy részénél. Egyre több projekt és tanulmány utal arra, hogy a teljesítmény nem mindig javul attól, ha a végrehajtási környezet előíróbbá válik. A támogatott kódolásnál, a hosszan futó feladatoknál, a böngészőhasználatnál és a hosszú kontextusú feladatoknál újra és újra ugyanaz a minta rajzolódik ki: ha a modell már kellően intelligens, a környező szoftverbe kényszerített túl sok feladatstruktúra előny helyett korláttá válhat.
A végrehajtási környezet szerepe tehát átalakul. Ahelyett, hogy merev összehangolással előre próbálná felmérni a feladatot, a végrehajtási környezet egyre inkább letisztult végrehajtási felületet biztosít: egy elkülönített környezetet, ahol a modell megvizsgálhatja az állapotot, kódot futtathat, helyreállhat a hibákból és módosíthatja saját megközelítését, miközben a rendszer felületei és biztonsági intézkedései határok között tartják. Ez közel áll ahhoz az átalakuláshoz, amelyet Andrej Karpathy a Software Engineer 3.0 című előadásában ismertetett: a korábban a szoftverben található logika egy része magasabb szintre, az „utasításba” kerül.
A tanulság nem az, hogy az ügynökrendszerekből minden struktúrát el kell távolítani. Sok feladatnak továbbra is előnyére válnak az egyértelmű munkafolyamatok, a heurisztikák és a determinisztikus védőkorlátok, különösen akkor, ha a feladat szűk körű, nagy volumenű, vagy világosan meghatározható a sikerkritériuma. Ahogy az Ügynökalapú rendszerek tervezési heurisztikái című korábbi bejegyzésünkben kifejtettük, az erős összehangolás továbbra is fontos, ha egy megbízható logikai folyamat kialakítása lehetséges és kívánatos.
A nyitott végű feladatoknál azonban eltolódik a hangsúly. A kihívást egyre kevésbé a mind bonyolultabb összehangolási rétegek megtervezése jelenti, inkább olyan egyszerű, megfigyelhető és moduláris végrehajtási környezeteket kell létrehozni, amelyekben a modell hatékonyan dolgozhat.
Amint egy ügynök képes fájlokat olvasni, kódot írni, parancsértelmező-parancsokat futtatni és hosszan futó feladatokat indítani, megváltozik a mérnöki kihívás. Már nem csupán az utasítások optimalizálása vagy az eszközök közötti irányítás jelenti a nehézséget. Az, hogy az ügynök immár valódi rendszeren dolgozik, jelentősen növeli a képességeit, de érzékenyebbé is teszi, mivel nagyobb védelmi és biztonsági támadási felületet teremt. Egy kódot futtató ügynök például káros műveleteket hajthat végre, ha a környezete nincs megfelelően elkülönítve (lásd az AISI Sandbox Bench tesztjét).
Az elkülönített futtatás ezért az ügynök-keretrendszerek egyik kritikus kérdésévé válik. A korábbi rendszerekben a végrehajtást gyakran kiegészítőként kezelték: a végrehajtási környezethez utólag hozzáillesztett eszközként. Ez a megközelítés azonban kezd működésképtelenné válni, amint a végrehajtás állapottartóvá, hosszan futóvá vagy távolivá válik. Magának az elkülönített környezetnek, valamint annak életciklusának, állapotának, felületeinek és az ügynökciklushoz való kapcsolódásának kezelése gyorsan önálló rendszertervezési problémává válik. Többek között ezért kínál egyre több szolgáltató felügyelt kódfuttatási környezetet, köztük az OpenAI Container API-ja és shell eszköze, valamint a Modal, a Cloudflare, a Daytona és az E2B.
Ez a határ azért fontos, mert a kódfuttatás erősebb elkülönítést és szigorúbb futásidejű felügyeletet igényel, mint a végrehajtási környezet többi része. A gyakorlatban a rosszul megvalósított, kódot futtató ügynökök három üzletileg kritikus kockázatot teremthetnek: ellenőrizetlen számítási költségeket, a belső rendszereket károsító műveleteket és érzékeny információk kiszivárgását. Megfelelő konténerizációval, elkülönítéssel és futásidejű biztonsági intézkedésekkel ezek a kockázatok a valós telepítések számára elfogadható szintre korlátozhatók.
Úgy is elképzelhetjük ezt, hogy az ügynök nem az egész iroda kulcsait kapja meg, hanem saját, lezárt munkaterületet. Ezen a területen továbbra is végezhet hasznos munkát, de csak világosan meghatározott korlátok között. Korlátozható az általa felhasznált számítási kapacitás, megszabható, hogy mely rendszerekhez és fájlokhoz férhet hozzá, és eleve szabályozható, milyen információk állnak a rendelkezésére.
Ez nem szünteti meg teljesen a kockázatot, de a probléma az „ügynök szabadon mozog az infrastruktúrában” helyzetről az „ügynök ellenőrzött környezetben működik” helyzetre változik. Ha ez a réteg az ügynökrendszerek szabványos részévé válik, akkor magának a keretrendszernek is elsőrangú támogatást kell biztosítania hozzá. Az elkülönített környezet így moduláris végrehajtási réteggé válik, olyan hordozható alapelemekkel, amelyeket a fejlesztők gyorsan bevezethetnek, szolgáltatók között cserélhetnek és az ügynöklogika folyamatos átdolgozása nélkül méretezhetnek.
Amint egy ügynök kódot futtat, magát az elkülönített környezetet is össze kell hangolni. A helyi koncepcióigazolástól a távoli végrehajtás, több háttérrendszer vagy hosszan futó munkamenetek felé haladva exponenciálisan nő az üzemeltetési teher. Egységes módszer kell a környezetek létrehozásához és leállításához, szüneteltetéséhez és folytatásához, az állapot pillanatképeinek elkészítéséhez, a későbbi újracsatlakozáshoz, valamint mindezek szolgáltatókon átívelő kezeléséhez.
Fogalmi szempontból mindez nem különösebben izgalmas, a gyakorlatban azonban fontos. Éppen ez az az infrastruktúra, amely komoly nehézségeket okoz, amikor minden csapat az alapoktól építi újra az ügynökalapú folyamatot – különösen, ha az nincs beépítve az ügynök-keretrendszerbe…
Itt válik fontossá a keretrendszer jobb támogatása. Korai hozzáférést kaptunk az újabb OpenAI Agents SDK-hoz, és magunk is elkülönített környezetben futó ügynököket készítettünk vele. Az architekturális hangsúlyváltás volt a legszembetűnőbb: az SDK nem periférikus eszközként, hanem elsőrangú rétegként kezeli a végrehajtást. A gyakorlatban ez azt jelenti, hogy kevesebb kóddal indítható el egy elkülönített környezetben működő ügynök, készíthető pillanatkép a környezetről vagy folytatható a végrehajtás – egyes tesztjeinkben körülbelül hatszor kevesebb kód kellett –, majd a környező ügynöklogika átírása nélkül váltható háttérrendszer.
A feladatkörök ilyen világosabb szétválasztása lehetővé teszi, hogy a végrehajtási környezet az érvelésre, a kontextusra és a munkafolyamatra összpontosítson. A végrehajtási réteg pedig az elkülönítésre, a hordozhatóságra és a futásidejű állapotra összpontosíthat. Ez az absztrakció megkönnyíti a nagyobb tudású és könnyebben továbbfejleszthető kódoló ügynökök létrehozását: válthatnak a helyi és távoli végrehajtás között, támogathatják a hosszabb ideig futó feladatokat, és a teljes rendszer újratervezése nélkül cserélhetik le a végrehajtási háttérrendszert.
Ahogy egyre több feladatszintű logika kerül át a végrehajtási környezetből a modellbe, a rendszer összetettségének egy része is vele együtt, lefelé, a végrehajtási rétegbe költözik. A kódfuttatás és az elkülönített futtatókörnyezetek használata mára az ügynökalapú rendszerek alapvető architekturális kérdésévé vált, különösen a sok kódolást igénylő és nyitott végű feladatoknál. Ma már ugyanolyan fontos megtervezni az ügynökalapú folyamatot, mint azt a környezetet, amelyben az ügynök biztonságosan, megbízhatóan és tartósan működhet.
Ezért fontosak az elkülönített végrehajtás magasabb szintű absztrakciói. Az újabb OpenAI Agents SDK ebbe az irányba halad: a végrehajtást a rendszer moduláris rétegeként kezeli, amely hordozható a háttérrendszerek között, a hosszan futó feladatok során megőrzi az állapotát, és annyira egyszerűen használható, hogy nem kell minden új összeállításhoz ismét felépíteni ugyanazt az infrastruktúrát.
Általánosabb tanulságként az ügynök-keretrendszerek következő generációját valószínűleg kevésbé az határozza majd meg, mennyi összehangolási logikát adnak hozzá, sokkal inkább az, mennyire jól strukturálják azokat a végrehajtási környezeteket, amelyekre az ügynökök egyre jobban támaszkodnak.