Od modelu k agentovi: Vybavenie Responses API počítačovým prostredím

Momentálne prechádzame od používania modelov, ktoré vynikajú v konkrétnych úlohách, k používaniu agentov schopných zvládať zložité pracovné postupy. Pomocou zadávanie príkazov modelom môžete získať prístup iba k natrénovanej inteligencii. Avšak tým, že modelu poskytnete počítačové prostredie, môže dosiahnuť oveľa širšiu škálu prípadov použitia, ako je spúšťanie služieb, vyžadovanie údajov z API alebo generovanie užitočnejších artefaktov, ako sú tabuľky alebo správy.

Pri pokuse o vytvorenie agentov sa objaví niekoľko praktických problémov: kam umiestniť medzisúbory, ako sa vyhnúť vkladaniu veľkých tabuliek do príkazu, ako poskytnúť pracovnému postupu prístup k sieti bez toho, aby ste spôsobili bezpečnostné problémy, a ako zvládnuť časové limity a opakované pokusy bez toho, aby ste si museli sami vytvoriť systém pracovného postupu.

Namiesto toho, aby sme vývojárom prenechali vytváranie vlastných prostredí na vykonávanie úloh, sme vytvorili potrebné komponenty, aby sme Responses API⁠(otvorí sa v novom okne) vybavili počítačovým prostredím na spoľahlivé vykonávanie úloh z reálneho sveta.

API Responses od OpenAI spolu s nástrojom shell a pracovným priestorom hostovaného kontajnera je navrhnuté tak, aby riešilo tieto praktické problémy. Model navrhuje kroky a príkazy; platforma ich spúšťa v izolovanom prostredí so súborovým systémom pre vstupy a výstupy, voliteľným štruktúrovaným úložiskom (ako SQLite) a obmedzeným prístupom k sieti. 

V tomto príspevku si rozoberieme, ako sme vytvorili počítačové prostredie pre agentov a podelíme sa s vami o niekoľko prvých poznatkov o tom, ako ho používať pre rýchlejšie, opakovateľnejšie a bezpečnejšie produkčné pracovné postupy.

Dobrý pracovný postup agenta začína úzkou slučkou vykonávania: model navrhne akciu, ako je čítanie súborov alebo načítanie údajov pomocou API, platforma ju spustí a výsledok sa použije v ďalšom kroku. Začneme s nástrojom shell – najjednoduchším spôsobom, ako vidieť túto slučku v akcii – a potom sa budeme venovať pracovnému priestoru kontajnera, sieti, opakovane použiteľným zručnostiam a kompakcii kontextu.

Aby sme pochopili nástroj shell, je najprv užitočné pochopiť, ako jazykový model používa nástroje vo všeobecnosti: na vykonávanie úloh, ako je získanie funkcie alebo interakcia s počítačom. Počas tréningu sa modelu krok za krokom ukazujú príklady toho, ako sa nástroje používajú a aké sú výsledné účinky. Toto pomáha modelu naučiť sa rozhodovať, kedy použiť nástroj a ako ho použiť. Keď hovoríme „používanie nástroja“, myslíme tým, že model v skutočnosti iba navrhuje získanie nástroja. Nedokáže vykonať získanie sám.

Nástroj shell výrazne zvyšuje výkon modelu: interaguje s počítačom prostredníctvom príkazového riadku a vykonáva širokú škálu úloh, od vyhľadávania textu až po odosielanie požiadaviek API na vašom počítači. Náš nástroj shell, postavený na známych nástrojoch Unixu, dokáže robiť čokoľvek, čo by ste očakávali, s nástrojmi ako grep, curl a awk dostupnými ihneď po vybalení.

V porovnaní s naším existujúcim interpretom kódu, ktorý spúšťa iba Python, nástroj shell umožňuje oveľa širšiu škálu prípadov použitia, ako je spúšťanie programov Go alebo Java alebo spustenie servera NodeJS. Táto flexibilita umožňuje modelu plniť zložité agentné úlohy.

Samotný model dokáže navrhovať iba príkazy shellu, ale ako sa tieto príkazy vykonávajú? Potrebujeme orchestrátor, ktorý získa výstup modelu, vyvolá nástroje a v slučke pošle odpoveď nástroja späť modelu, kým sa úloha nedokončí.

Responses API umožňuje vývojárom interagovať s modelmi OpenAI. Pri použití s vlastnými nástrojmi Responses API odovzdáva kontrolu späť klientovi a klient potrebuje na spustenie nástrojov vlastné rozhranie. Toto API však dokáže orchestrovať medzi modelom a rozbalenými hostovanými nástrojmi. 

Keď Responses API prijme príkaz, zostaví kontext modelu: príkaz používateľa, predchádzajúci stav konverzácie a inštrukcie nástroja. Aby fungovalo vykonávanie v shelli, príkaz musí spomenúť použitie nástroja shell a vybraný model musí byť trénovaný na navrhovanie príkazov shellu—modely GPT‑5.2 a novšie sú na to trénované. So všetkým týmto kontextom sa potom model rozhodne o ďalšej akcii. Ak zvolí spustenie shellu, vráti jeden alebo viac príkazov shellu do Responses API. Služba API preposiela tieto príkazy do kontajnerového runtimu, streamuje späť výstup shellu a v ďalšom kontexte požiadavky ho odovzdáva modelu. Model potom môže výsledky skontrolovať, vydávať následné príkazy alebo vytvárať konečnú odpoveď. Responses API opakuje túto slučku, kým model nevráti dokončenie bez ďalších príkazov shellu.

Keď Responses API vykoná príkaz shellu, udržiava streamovacie pripojenie ku kontajnerovej službe. Keď sa vygeneruje výstup, API ho prenáša do modelu takmer v reálnom čase, aby sa model mohol rozhodnúť, či čakať na ďalší výstup, spustiť ďalší príkaz alebo prejsť na konečnú odpoveď.

Model dokáže v jednom kroku navrhnúť viacero príkazov shellu a Responses API ich dokáže vykonávať súbežne pomocou samostatných kontajnerových relácií. Každá relácia streamuje výstup nezávisle a API tieto streamy multiplexuje späť do štruktúrovaných výstupov nástrojov ako kontext. Inými slovami, slučka agenta môže paralelizovať prácu, napríklad vyhľadávanie súborov, získavanie údajov a overovanie priebežných výsledkov.

Keď príkaz zahŕňa operácie so súbormi alebo spracovanie údajov, výstup shellu môže byť veľmi veľký a spotrebovať kontextové rozpočty bez toho, aby pridával užitočné signály. Na kontrolu tohto model špecifikuje limit výstupu na príkaz. Responses API vynucuje tento limit a vracia ohraničený výsledok, ktorý zachováva začiatok aj koniec výstupu, pričom označuje vynechaný obsah. Napríklad môžete obmedziť výstup na 1000 znakov so zachovaným začiatkom a koncom:

text na začiatku ... 1000 znakov skrátených ... text na konci

Spoločne vďaka súbežnému vykonávaniu a ohraničenému výstupu je slučka agenta rýchla aj kontextovo efektívna, takže model môže pokračovať v uvažovaní nad relevantnými výsledkami namiesto toho, aby ho zahltili nespracované terminálové protokoly.

Jedným potenciálnym problémom so slučkami agenta je, že úlohy môžu bežať dlhý čas. Dlhotrvajúce úlohy zapĺňajú kontextové okno, čo je dôležité na poskytovanie kontextu naprieč krokmi a naprieč agentmi. Predstavte si agenta, ktorý získava zručnosť, dostane odpoveď, pridá získavanie nástrojov a zhrnutia uvažovania – obmedzené kontextové okno sa rýchlo zaplní. Aby sme predišli strate dôležitého kontextu, keď agent pokračuje v chode, potrebujeme spôsob, ako zachovať kľúčové podrobnosti a odstrániť všetko nadbytočné. Namiesto toho, aby sme od vývojárov vyžadovali navrhovať a udržiavať vlastné systémy na sumarizáciu alebo prenášanie stavu, pridali sme natívnu kompakciu do API Responses, navrhnutú tak, aby bola v súlade s tým, ako sa model správa a ako bol trénovaný.

Naše najnovšie modely sú trénované na analýzu predchádzajúceho stavu konverzácie a vytvorenie položky kompakcie, ktorá zachováva kľúčový predchádzajúci stav v šifrovanej reprezentácii efektívnej z hľadiska tokenov. Po kompakcii sa ďalšie kontextové okno skladá z tejto položky kompakcie a častí s vysokou hodnotou z predchádzajúceho okna. To umožňuje, aby pracovné postupy pokračovali koherentne naprieč hranicami okien, a to aj v rozšírených viacstupňových a nástrojmi riadených reláciách. Codex sa spolieha na tento mechanizmus na udržiavanie dlhodobo bežiacich kódovacích úloh a iteratívneho vykonávania nástrojov bez zníženia kvality.

Kompakcia je k dispozícii buď vstavaná na serveri, alebo prostredníctvom samostatného koncového bodu `/compact`. Kompakcia na strane servera ti umožňuje nakonfigurovať prah a systém automaticky spravuje načasovanie kompakcie, čím eliminuje potrebu zložitej logiky na strane klienta. Umožňuje mierne väčšie efektívne kontextové okno vstupu, aby tolerovalo malé prekročenia tesne pred kompakciou, takže požiadavky blízko limitu sa stále môžu spracovať a skoncentrovať namiesto toho, aby boli odmietnuté. S vývojom trénovania modelov sa s každým vydaním modelu OpenAI vyvíja aj natívne riešenie kompakcie.

Codex nám pomohol vybudovať systém kompakcie a zároveň slúžil ako jeho skorý používateľ. Keď jedna inštancia Codexu narazila na chybu kompakcie, spustili sme druhú inštanciu na preskúmanie. Výsledkom bolo, že Codex získal natívny, efektívny systém kompakcie už len tým, že pracoval na probléme. Táto schopnosť Codexu skúmať a zdokonaľovať sám seba sa stala obzvlášť zaujímavou súčasťou práce v OpenAI. Väčšina nástrojov od používateľa vyžaduje len to, aby sa naučil, ako ich používať; Codex sa učí spolu s nami.

Teraz sa pozrime na stav a zdroje. Kontajner nie je len miestom na spúšťanie príkazov, ale aj pracovným kontextom pre model. V kontajneri môže model čítať súbory, dopytovať databázy a pristupovať k externým systémom v rámci kontrol zásad sieťovej politiky.

Prvou časťou kontextu kontajnera je súborový systém na nahrávanie, organizovanie a správu zdrojov. Vytvorili sme rozhrania API pre kontajner a súbor⁠(otvorí sa v novom okne), aby sme modelu poskytli mapu dostupných údajov a pomohli mu vybrať cielené operácie so súbormi namiesto vykonávania širokých, rušivých skenov.

Bežným anti-vzorom je vkladať všetky vstupy priamo do kontextu príkazu. S rastúcim počtom vstupov sa preplnenie príkazu stáva nákladným a pre model je ťažké sa v ňom orientovať. Lepším vzorom je pripraviť zdroje v kontajnerovom súborovom systéme a nechať model rozhodnúť, čo má otvoriť, analyzovať alebo transformovať pomocou príkazov shellu. Podobne ako ľudia, aj modely fungujú lepšie s usporiadanými informáciami.

Druhou časťou kontextu kontajnera sú databázy. V mnohých prípadoch odporúčame vývojárom ukladať štruktúrované údaje do databáz ako SQLite a dopytovať ich. Namiesto kopírovania celej tabuľky do príkazu môžete napríklad poskytnúť modelu opis tabuliek – aké stĺpce existujú a čo znamenajú – a nechať ho vybrať riadky, ktoré potrebuje.

Napríklad, ak sa opýtate: „Ktoré produkty mali v tomto štvrťroku klesajúci predaj?“, model môže dotazovať iba relevantné riadky namiesto skenovania celej tabuľky. Je to rýchlejšie, lacnejšie, škálovateľnejšie pre väčšie súbory údajov.

Treťou časťou kontextu kontajnera je prístup k sieti, ktorý je nevyhnutnou súčasťou pracovných záťaží agenta. Pracovné postupy agenta môžu potrebovať načítať živé údaje, volať externé rozhrania API alebo inštalovať balíky. Zároveň môže byť poskytnutie neobmedzeného prístupu na internet kontajnerom riskantné: môže to vystaviť informácie externým webovým stránkam, neúmyselne citlivým interným systémom alebo systémom tretích strán, alebo sťažiť ochranu pred únikmi poverení a exfiltráciou údajov.

Aby sme tieto problémy riešili bez obmedzenia užitočnosti agentov, vytvorili sme hostované kontajnery na používanie sidecar egress proxy. Všetky odchádzajúce sieťové požiadavky prechádzajú cez centralizovanú vrstvu zásad, ktorá uplatňuje povolené zoznamy a kontroly prístupu a zároveň zachováva pozorovateľnosť prevádzky. Pre prihlasovacie údaje používame vkladanie tajných údajov v rozsahu domény pri výstupe. Model a kontajner vidia iba zástupné symboly, zatiaľ čo surové tajné hodnoty zostávajú mimo kontextu viditeľného pre model a použijú sa iba pre schválené destinácie. Tým sa znižuje riziko úniku, pričom sa stále umožňujú autentifikované externé volania.

Príkazy shellu sú výkonné, ale mnoho úloh opakuje rovnaké viackrokové vzory. Agenti musia pri každom spustení nanovo objavovať pracovný postup – preplánovať, opätovne vydať príkazy a znovu sa naučiť konvencie – čo vedie k nekonzistentným výsledkom a zbytočnému vykonávaniu. Zručnosti agenta⁠(otvorí sa v novom okne) balia tieto vzory do opakovane použiteľných, skladateľných stavebných blokov. Konkrétne, zručnosť je balík priečinka, ktorý obsahuje ‘SKILL.md⁠(otvorí sa v novom okne)’ (obsahujúce metadáta a inštrukcie) plus akékoľvek podporné zdroje, ako sú špecifikácie API a prvky používateľského rozhrania.

Táto štruktúra sa prirodzene mapuje na architektúru runtime prostredia, ktorú sme opísali skôr. Kontajner poskytuje trvalé súbory a kontext vykonávania a nástroj shell poskytuje rozhranie na vykonávanie. S oboma nainštalovanými funkciami môže model v prípade potreby vyhľadávať súbory zručností pomocou príkazov shellu (`ls`, `cat` atď.), interpretovať inštrukcie a spúšťať skripty zručností v rámci tej istej slučky agenta.

Poskytujeme API⁠(otvorí sa v novom okne) na správu zručností na platforme OpenAI. Vývojári nahrávajú a ukladajú priečinky so zručnosťami ako balíčky s verziami, ktoré je možné neskôr načítať pomocou ID zručnosti. Pred odoslaním príkazu do modelu Responses API načíta zručnosť a zahrnie ju do kontextu modelu. Táto sekvencia je deterministická:

1. Načítať metadáta zručnosti vrátane názvu a popisu.
2. Získajte balík zručností, skopírujte ho do kontajnera a rozbaľte ho.
3. Aktualizujte kontext modelu o metadáta zručností a cestu kontajnera.

Pri rozhodovaní o tom, či je zručnosť relevantná, model postupne skúma jej inštrukcie a vykonáva jej skripty prostredníctvom príkazov shellu v kontajneri.

Aby sme dali všetky časti dokopy: Responses API poskytuje orchestráciu, nástroj shell poskytuje spustiteľné akcie, hostovaný kontajner poskytuje perzistentný kontext runtimu, logiku pracovného postupu na úrovni zručností s opakovaným použitím a kompakcia umožňuje agentovi bežať dlhý čas s potrebným kontextom.

S týmito základnými prvkami sa jeden príkaz môže rozšíriť do komplexného pracovného postupu: objaviť správnu zručnosť, načítať dáta, transformovať ich do lokálneho štruktúrovaného stavu, efektívne ich dotazovať a generovať trvalé artefakty. 

Diagram nižšie znázorňuje, ako tento systém funguje na vytvorenie tabuľky z aktuálnych údajov.

Podrobný príklad kombinácie nástroja shell a počítačového prostredia pre komplexné pracovné postupy nájdete v našom blogovom príspevku pre vývojárov⁠(otvorí sa v novom okne) a v manuáli⁠(otvorí sa v novom okne) , ktoré vás prevedú balením zručnosti a jej spustením prostredníctvom Responses API.

Tešíme sa na to, čo vývojári vytvoria s touto sadou základných prvkov. Jazykové modely sú určené na viac než len generovanie textu, obrázkov a zvuku – našu platformu budeme naďalej vyvíjať, aby bola schopnejšia zvládať zložité úlohy z reálneho sveta vo veľkom meradle.