Modelltől ügynökig: A Responses API felvértezése számítógépes környezettel

Jelenleg egy olyan váltásban vagyunk, amely a konkrét feladatokban kiváló modellek használatáról a komplex munkafolyamatok kezelésére képes ügynökök használatára irányul. A modell utasításával csak a betanított intelligenciához férhetsz hozzá. Azonban, ha a modellnek számítógépes környezetet biztosítunk, az a felhasználási esetek sokkal szélesebb körét teheti lehetővé, például szolgáltatások futtatását, adatok lekérését API-kból, vagy hasznosabb artefaktumok, például táblázatok vagy jelentések létrehozását.

Néhány gyakorlati probléma merül fel, amikor ügynököket próbálsz építeni: hová tedd a köztes fájlokat, hogyan kerüld el, hogy nagy táblázatokat illessz be egy utasításba, hogyan adj a munkafolyamatnak hálózati hozzáférést anélkül, hogy biztonsági rémálmot okoznál, és hogyan kezeld az időtúllépéseket és az újrapróbálkozásokat anélkül, hogy magadnak kellene munkafolyamat-rendszert építened.

Ahelyett, hogy a fejlesztőkre bíznánk a saját végrehajtási környezeteik felépítését, megépítettük a szükséges összetevőket, hogy a Responses API⁠(új ablakban nyílik meg)-t egy számítógépes környezettel lássuk el, amely megbízhatóan képes valós feladatok végrehajtására.

Az OpenAI Responses API-ja a shell eszközzel és egy hosztolt konténeres munkaterülettel együtt ezeknek a gyakorlati problémáknak a megoldására készült. A modell lépéseket és parancsokat javasol; a platform ezeket egy elszigetelt környezetben futtatja, bemenetekhez és kimenetekhez fájlrendszerrel, opcionális strukturált tárolással (például SQLite-tal) és korlátozott hálózati hozzáféréssel. 

Ebben a bejegyzésben bemutatjuk, hogyan hoztunk létre egy számítógépes környezetet az ügynökök számára, és megosztunk néhány korai tanulságot arról, hogyan lehet azt gyorsabb, megismételhetőbb és biztonságosabb munkafolyamatokhoz használni.

Egy jó ügynök munkafolyamat szoros végrehajtási ciklussal kezdődik: a modell olyan műveletet javasol, mint a fájlok olvasása vagy adatok lekérése API-val, a platform lefuttatja, és az eredmény a következő lépésbe kerül. A shell eszközzel kezdünk – ez a legegyszerűbb módja annak, hogy működés közben lásd ezt a ciklust –, majd kitérünk a konténeres munkaterületre, a hálózatkezelésre, az újrahasznosítható készségekre és a kontextus tömörítésére.

A shell eszköz megértéséhez először hasznos megérteni, hogyan használ egy nyelvi modell általában eszközöket: például egy függvény meghívására vagy arra, hogy kapcsolatba lépjen egy számítógéppel. A betanítás során a modellnek lépésről lépésre bemutatják, hogyan használják az eszközöket, és milyen hatásokkal járnak. Ez segít a modellnek megtanulni eldönteni, mikor használjon eszközt, és hogyan használja azt. Amikor azt mondjuk, hogy „egy eszköz használata”, akkor azt értjük alatta, hogy a modell valójában csak egy eszközhívást javasol. Önmagában nem tudja végrehajtani a hívást.

A shell eszköz jelentősen erősebbé teszi a modellt: a parancssoron keresztül lép kapcsolatba a számítógéppel, hogy különféle feladatokat hajtson végre, a szövegkereséstől az API-kérések elküldéséig. Ismert Unix eszközkészletre építve a shell eszközünk mindent tud, amit elvárhat, olyan segédprogramokkal, mint a grep, a curl és az awk, amelyek azonnal elérhetők.

A meglévő kódértelmezőnkhöz képest, amely csak Python kódot hajt végre, a shell eszköz a felhasználási esetek sokkal szélesebb körét teszi lehetővé, például Go vagy Java programok futtatását, illetve egy NodeJS szerver elindítását. Ez a rugalmasság lehetővé teszi, hogy a modell összetett ügynöki feladatokat teljesítsen.

Önmagában a modell csak shell parancsokat tud javasolni, de hogyan hajtják végre ezeket a parancsokat? Szükségünk van egy vezénylőre, amely lekéri a modell kimenetét, meghívja az eszközöket, és az eszköz válaszát egy ciklusban visszajuttatja a modellnek, amíg a feladat be nem fejeződik.

A Responses API az a mód, ahogyan a fejlesztők az OpenAI modelljeivel interakcióba lépnek. Egyéni eszközökkel használva a Responses API visszaadja a vezérlést a kliensnek, és a kliensnek saját keretrendszerre van szüksége az eszközök futtatásához. Azonban ez az API alapból képes a modell és a hosztolt eszközök közötti összehangolásra. 

Amikor a Responses API megkap egy utasítást, összeállítja a modell kontextusát: felhasználói utasítás, korábbi beszélgetési állapot és eszközinstrukciók. Ahhoz, hogy a shell végrehajtás működjön, az utasításnak említenie kell a shell eszköz használatát és a kiválasztott modellnek shell parancsok javaslatára kell lennie betanítva – erre a GPT‑5.2 és az újabb modellek be vannak tanítva. Mindezen kontextus birtokában a modell ezután eldönti a következő műveletet. Ha a shell-végrehajtást választja, egy vagy több shell-parancsot ad vissza a Responses API szolgáltatásnak. Az API-szolgáltatás továbbítja ezeket a parancsokat a konténer futtatókörnyezetnek, visszastreameli a shell kimenetét, és a következő kérés kontextusában átadja azt a modellnek. A modell ezután megvizsgálhatja az eredményeket, kiadhat utánkövető parancsokat, vagy végső választ adhat. A Responses API addig ismétli ezt a ciklust, amíg a modell további shell-parancsok nélkül ad vissza egy befejezést.

Amikor a Responses API egy shell parancsot hajt végre, streaming kapcsolatot tart fenn a konténerszolgáltatással. A kimenet előállítása közben az API közel valós időben továbbítja azt a modellnek, hogy a modell eldönthesse, várjon-e további kimenetre, futtasson-e egy másik parancsot, vagy továbblépjen a végső válaszra.

A modell egy lépésben több shell-parancsot is javasolhat, és a Responses API ezeket párhuzamosan végre tudja hajtani különálló konténermunkamenetek használatával. Minden munkamenet egymástól függetlenül streameli a kimenetet, és az API ezeket a streameket strukturált eszközkimenetekké multiplexeli vissza kontextusként. Más szóval, az ügynökciklus képes párhuzamosítani a munkát, például fájlok keresését, adatok lekérését és a köztes eredmények ellenőrzését.

Amikor a parancs fájlműveleteket vagy adatfeldolgozást érint, a shell kimenete nagyon nagyra nőhet, és hasznos jelzések hozzáadása nélkül felemésztheti a kontextuskeretet. Ennek szabályozásához a modell parancsonkénti kimeneti korlátot határoz meg. A Responses API kikényszeríti ezt a korlátot, és egy korlátozott eredményt ad vissza, amely megőrzi a kimenet elejét és végét is, miközben megjelöli a kihagyott tartalmat. Például korlátozhatod a kimenetet 1000 karakterre, a megőrzött elejével és végével:

szöveg az elején ... 1000 karakter csonkolva ... szöveg a végén

A párhuzamos végrehajtás és a korlátozott kimenet együttesen gyorssá és kontextushatékonnyá teszi az ügynökciklust, így a modell a releváns eredmények alapján tud tovább érvelni, ahelyett hogy a nyers terminálnaplók elárasztanák.

Az ügynökciklusok egyik lehetséges problémája, hogy a feladatok hosszú ideig futhatnak. A hosszú lefutású feladatok kitöltik a kontextusablakot, ami fontos a kontextus biztosításához a fordulók és az ügynökök között. Képzelj el egy ügynököt, amint meghív egy készséget, választ kap, eszközhívásokat és érvelési összefoglalókat ad hozzá – a korlátozott kontextusablak gyorsan megtelik. Annak elkerülése érdekében, hogy az ügynök futásának folytatása közben elveszítsük a fontos kontextust, szükségünk van egy módra, amellyel megőrizhetjük a kulcsfontosságú részleteket, és eltávolíthatunk minden feleslegeset. Ahelyett, hogy a fejlesztőknek egyedi összegzési vagy állapotmegőrző rendszereket kellene tervezniük és karbantartaniuk, natív tömörítést adtunk a Responses API-hoz, amelyet úgy terveztünk, hogy összhangban legyen azzal, ahogyan a modell működik, és ahogyan betanították.

Legújabb modelljeinket arra tanítottuk be, hogy elemezzék a korábbi beszélgetési állapotot, és egy tömörítési elemet állítsanak elő, amely a kulcsfontosságú korábbi állapotot egy titkosított, tokenhatékony reprezentációban őrzi meg. A tömörítés után a következő kontextusablak ebből a tömörítési elemből és a korábbi ablak nagy értékű részeiből áll. Ez lehetővé teszi, hogy a munkafolyamatok koherensen folytatódjanak az ablakhatárokon át, még a kiterjesztett, többlépéses és eszközvezérelt munkamenetekben is. A Codex erre a mechanizmusra támaszkodik, hogy a hosszú ideig futó kódolási feladatokat és az iteratív eszközvégrehajtást a minőség romlása nélkül fenntartsa.

A tömörítés elérhető vagy beépítve a szerveren, vagy egy önálló `/compact` végponton keresztül. A szerveroldali tömörítés lehetővé teszi egy küszöbérték beállítását, és a rendszer automatikusan kezeli a tömörítés időzítését, így nincs szükség összetett kliensoldali logikára. Lehetővé tesz egy valamivel nagyobb hatékony bemeneti kontextusablakot, hogy a tömörítés előtti közvetlenül fellépő kisebb túllépéseket tolerálja, így a korláthoz közeli kérések továbbra is feldolgozhatók és tömöríthetők, ahelyett hogy elutasításra kerülnének. Ahogy a modell betanítása fejlődik, a natív tömörítési megoldás is vele együtt fejlődik minden OpenAI modellkiadás esetén.

A Codex segített nekünk a tömörítési rendszer felépítésében, miközben annak korai felhasználójaként is szolgált. Amikor egy Codex-példánynál tömörítési hibába ütköztünk, elindítottunk egy második példányt a kivizsgáláshoz. Az eredmény az lett, hogy a Codex natív, hatékony tömörítési rendszert kapott pusztán azzal, hogy dolgozott a problémán. A Codex azon képessége, hogy megvizsgálja és finomítsa önmagát, különösen érdekes részévé vált az OpenAI-nál végzett munkának. A legtöbb eszköz csak azt követeli meg a felhasználótól, hogy megtanulja használni; a Codex velünk együtt tanul.

Most nézzük meg az állapotot és az erőforrásokat. A konténer nemcsak a parancsok futtatásának helye, hanem a modell munkakörnyezete is. A konténeren belül a modell képes fájlokat olvasni, adatbázisokat lekérdezni, és külső rendszerekhez hozzáférni a hálózati házirend-vezérlések keretein belül.

A konténerkontextus első része a fájlrendszer az erőforrások feltöltéséhez, rendszerezéséhez és kezeléséhez. Olyan tároló- és fájl⁠(új ablakban nyílik meg) API-kat építettünk, amelyek a modell számára térképet adnak az elérhető adatokról, és segítenek neki célzott fájlműveleteket választani a széles körű, zajos átvizsgálások végrehajtása helyett.

Gyakori anti-pattern, hogy az összes bemenetet közvetlenül az utasítás kontextusába csomagoljuk. Ahogy a bemenetek növekednek, az utasítás túltöltése költségessé válik, és a modell számára nehéz eligazodni benne. Egy jobb minta az, ha az erőforrásokat a konténer fájlrendszerében készítjük elő, és hagyjuk, hogy a modell döntse el, mit nyisson meg, elemezzen vagy alakítson át shell parancsokkal. Az emberekhez hasonlóan a modellek is jobban működnek rendezett információval.

A konténerkörnyezet második része az adatbázisok. Sok esetben azt javasoljuk a fejlesztőknek, hogy a strukturált adatokat SQLite-ként adatbázisokban tárolják, és lekérdezzék őket. Ahelyett, hogy például egy teljes táblázatot másolnál be az utasításba, adhatsz a modellnek egy leírást a táblákról – milyen oszlopok vannak, és mit jelentenek –, és hagyhatod, hogy kihúzza a szükséges sorokat.

Például, ha azt kérdezed: „Mely termékek eladásai csökkentek ebben a negyedévben?”, a modell csak a releváns sorokat tudja lekérdezni ahelyett, hogy az egész táblázatot átfésülné. Ez gyorsabb, olcsóbb, jobban skálázható nagyobb adathalmazokra.

A tárolókörnyezet harmadik része a hálózati hozzáférés, amely az ügynök munkaterheléseinek alapvető része. Előfordulhat, hogy az ügynök munkafolyamatainak élő adatokat kell lekérnie, külső API-kat kell meghívnia, vagy csomagokat kell telepítenie. Ugyanakkor a konténerek korlátlan internet-hozzáférésének biztosítása kockázatos lehet: információkat tehet elérhetővé külső webhelyek számára, akaratlanul is érinthet érzékeny belső vagy harmadik féltől származó rendszereket, illetve megnehezítheti a hitelesítő adatok kiszivárgása és az adatkiszivárogtatás elleni védekezést.

Ezen aggályok kezelése érdekében, az ügynökök hasznosságának korlátozása nélkül, létrehoztunk hosztolt konténereket, amelyek egy sidecar kimenő proxy-t használnak. Minden kimenő hálózati kérés egy központosított szabályzati rétegen keresztül halad, amely érvényesíti az engedélyezési listákat és a hozzáférés-vezérlést, miközben a forgalom megfigyelhető marad. A hitelesítő adatokhoz tartományhatókörű titok-injektálást használunk az egressnél. A modell és a tároló csak helyőrzőket lát, míg a nyers titkos értékek a modell által látható kontextuson kívül maradnak, és csak jóváhagyott célhelyekre kerülnek alkalmazásra. Ez csökkenti a szivárgás kockázatát, miközben továbbra is lehetővé teszi a hitelesített külső hívásokat.

A shell parancsok hatékonyak, de sok feladat ugyanazokat a többlépcsős mintákat ismétli. Az ügynököknek minden futtatáskor újra fel kell fedezniük a munkafolyamatot—újratervezni, újra kiadni a parancsokat és újratanulni a konvenciókat—ami következetlen eredményekhez és elpazarolt végrehajtáshoz vezet. Ügynökkészségek⁠(új ablakban nyílik meg) ezeket a mintákat újrafelhasználható, kombinálható építőelemekbe csomagolják. Konkrétan a készség egy mappacsomag, amely tartalmazza a(z) ‘SKILL.md⁠(új ablakban nyílik meg)’-t (metaadatokat és utasításokat tartalmazó) plusz bármilyen támogató erőforrás, például API-specifikációk és UI-eszközök.

Ez a struktúra természetes módon illeszkedik a korábban leírt futásidejű architektúrához. A konténer tartós fájlokat és végrehajtási környezetet biztosít, a shell-eszköz pedig a végrehajtási felületet biztosítja. Ha mindkettő a helyén van, a modell szükség esetén shell parancsokkal (`ls`, `cat`, etc.) fel tudja fedezni a készségfájlokat, értelmezni tudja az utasításokat, és a készségszkripteket is futtatni tudja, mindezt ugyanabban az ügynök ciklusban.

API-kat⁠(új ablakban nyílik meg) biztosítunk az OpenAI platformon a készségek kezeléséhez. A fejlesztők a készségmappákat verziózott csomagokként töltik fel és tárolják, amelyeket később a készségazonosító alapján lehet lekérni. Mielőtt elküldenéd az utasítást a modellnek, a Responses API betölti a készséget, és belefoglalja a modell kontextusába. Ez a szekvencia determinisztikus:

1. Készségmetaadatok lekérése, beleértve a nevet és a leírást.
2. Készségcsomag lekérése, átmásolás tárolóba és kicsomagolás.
3. Frissítsd a modell kontextusát a készségmetaadatokkal és a tároló elérési útjával.

Amikor arról döntesz, hogy egy készség releváns-e, a modell fokozatosan feltérképezi az utasításokat, és a konténerben shell parancsokkal hajtja végre a szkripteket.

Az összes elem összeillesztéséhez: a Responses API biztosítja a vezénylést, a shell tool biztosítja a végrehajtható műveleteket, a hosted container biztosítja a tartós futtatókörnyezeti kontextust, a skills réteg újrahasznosítható munkafolyamat-logikát biztosít, a compaction pedig lehetővé teszi, hogy egy ügynök hosszú ideig fusson a számára szükséges kontextussal.

Ezekkel az alapelemekkel egyetlen prompt egy teljes munkafolyamattá bővíthető: felfedezhető a megfelelő készség, adatok lekérése, helyi strukturált állapotba alakítása, hatékony lekérdezésük és tartós artefaktumok létrehozása. 

Az alábbi diagram bemutatja, hogyan működik ez a rendszer egy táblázat létrehozásához élő adatokból.

A shell eszköz és a számítógépes környezet végponttól végpontig tartó munkafolyamatokhoz való kombinálásának részletes példájáért lásd a fejlesztői blogbejegyzésünket⁠(új ablakban nyílik meg) és a cookbookot⁠(új ablakban nyílik meg), amelyek bemutatják egy skill csomagolását és annak végrehajtását a Responses API-n keresztül.

Izgatottan várjuk, hogy mit hoznak létre a fejlesztők ezzel a primitívkészlettel. A nyelvi modell célja nem csupán szövegek, képek és hanganyagok generálása – továbbra is fejlesztjük a platformunkat, hogy egyre alkalmasabb legyen összetett, valós feladatok nagy léptékű kezelésére.