Od modela do agenta: opremljanje Responses API z računalniškim okoljem

Trenutno prehajamo z uporabe modelov, ki blestijo pri posameznih nalogah, na uporabo agentov, ki so sposobni obvladovati zapletene poteke dela. S pozivanjem modelov lahko dostopate le do naučene inteligence. Vendar pa lahko z zagotovitvijo računalniškega okolja modelu dosežemo veliko širši nabor primerov uporabe, kot so izvajanje storitev, zahtevanje podatkov iz API-jev ali ustvarjanje uporabnejših artefaktov, kot so preglednice ali poročila.

Nekaj praktičnih težav se pojavi, ko poskušate zgraditi agente: kam shraniti vmesne datoteke, kako se izogniti lepljenju velikih tabel v poziv, kako delovnemu toku omogočiti dostop do omrežja, ne da bi ustvarili varnostne težave, in kako obravnavati časovne omejitve ter ponovne poskuse, ne da bi sami zgradili sistem poteka dela.

Namesto da bi razvijalce obremenili z gradnjo lastnih izvajalnih okolij, smo zgradili potrebne komponente, da bi Responses API⁠(odpre se v novem oknu) opremili z računalniškim okoljem za zanesljivo izvajanje nalog iz resničnega sveta.

OpenAI-jev API Responses je skupaj z orodjem za ukazno vrstico in gostovanim delovnim prostorom vsebnika zasnovan za reševanje teh praktičnih težav. Model predlaga korake in ukaze; platforma jih izvaja v izoliranem okolju z datotečnim sistemom za vhode in izhode, izbirno strukturirano shrambo (kot je SQLite) in omejenim dostopom do omrežja. 

V tej objavi bomo razčlenili, kako smo ustvarili računalniško okolje za agente, in delili nekaj zgodnjih lekcij o tem, kako ga uporabiti za hitrejše, bolj ponovljive in varnejše produkcijske poteke dela.

Dober agentski potek dela se začne s tesno izvedbeno zanko: model predlaga dejanje, kot je branje datotek ali pridobivanje podatkov prek API-ja, platforma ga izvede, rezultat pa se prenese v naslednji korak. Začeli bomo z orodjem za ukazno vrstico—najpreprostejšim načinom, da vidite to zanko med delovanjem—nato pa bomo obravnavali delovni prostor vsebnika, mreženje, ponovno uporabne veščine in zgoščevanje konteksta.

Da bi razumeli orodje za ukazno vrstico, je najprej koristno razumeti, kako jezikovni model na splošno uporablja orodja: za stvari, kot so klic funkcije ali interakcija z računalnikom. Med usposabljanjem se modelu korak za korakom prikazujejo primeri, kako se orodja uporabljajo in kakšni so posledični učinki. To pomaga modelu, da se nauči odločati, kdaj uporabiti orodje in kako ga uporabiti. Ko rečemo »uporaba orodja«, mislimo, da model dejansko samo predlaga klic orodja. Ne more sam po sebi izvesti priklica.

Orodje za ukazno vrstico naredi model bistveno zmogljivejši: prek ukazne vrstice komunicira z računalnikom, da izvede širok nabor opravil, od iskanja besedila do pošiljanja zahtev API v vašem računalniku. Na znanih orodjih Unix zgrajeno naše orodje za ukazno vrstico lahko naredi vse, kar bi pričakovali, z orodji, kot so grep, curl in awk, ki so na voljo takoj po namestitvi.

V primerjavi z našim obstoječim tolmačem kode, ki izvaja samo Python, lupinsko orodje omogoča veliko širši nabor primerov uporabe, kot je poganjanje programov v Go ali Javi ali zagon strežnika NodeJS. Ta prilagodljivost modelu omogoča, da izpolni kompleksne agentske naloge.

Sam po sebi lahko model predlaga le ukaze v ukazni vrstici, toda kako se ti ukazi izvedejo? Potrebujemo orkestrator, da pridobi rezultat modela, prikliče orodja in v zanki posreduje odziv orodja nazaj modelu, dokler naloga ni dokončana.

Responses API je način, kako razvijalci komunicirajo z modeli OpenAI. Pri uporabi z orodji po meri Responses API vrne nadzor odjemalcu, odjemalec pa za izvajanje orodij potrebuje lastno ogrodje. Vendar lahko ta API tudi takoj orkestrira med modelom in gostovanimi orodji. 

Ko Responses API prejme poziv, sestavi kontekst modela: uporabniški poziv, predhodno stanje pogovora in orodna navodila. Da bo izvajanje v lupini delovalo, mora poziv omenjati uporabo orodja za ukazno vrstico and izbrani model mora biti usposobljen za predlaganje lupinskih ukazov—modela GPT‑5.2 in novejši so za to usposobljeni. Z vsem tem kontekstom se model nato odloči za naslednje dejanje. Če izbere izvajanje lupine, vrne enega ali več ukazov za ukazno vrstico storitvi Responses API. Storitev API posreduje te ukaze izvajalnemu okolju vsebnika, pretaka nazaj rezultat ukazne vrstice in ga vključi v kontekst naslednje zahteve za model. Model lahko nato pregleda rezultate, izda nadaljnje ukaze ali pripravi končni odgovor. Responses API ponavlja to zanko, dokler model ne vrne dokončanja brez dodatnih ukazov za ukazno vrstico.

Ko Responses API za odgovore izvede ukaz v ukazni vrstici, ohranja pretočno povezavo s storitvijo vsebnikov. Ko rezultat nastaja, ga API skoraj v realnem času posreduje modelu, da se lahko model odloči, ali bo počakal na več rezultatov, zagnal drug ukaz ali nadaljeval do končnega odgovora.

Model lahko v enem koraku predlaga več lupinskih ukazov, Responses API pa jih lahko izvede vzporedno z uporabo ločenih sej vsebnika. Vsaka seja rezultat pretaka neodvisno, API pa te tokove multipleksira nazaj v strukturirane izhode orodij kot del konteksta. Z drugimi besedami, agentska zanka lahko delo, kot so iskanje datotek, pridobivanje podatkov in preverjanje vmesnih rezultatov, izvaja vzporedno.

Ko ukaz vključuje operacije z datotekami ali obdelavo podatkov, lahko lupinski rezultat postane zelo velik in porabi kontekstne proračune, ne da bi dodal uporabne signale. Za nadzor tega model določi omejitev rezultata na ukaz. Responses API uveljavlja to omejitev in vrne omejen rezultat, ki ohranja tako začetek kot konec izhoda, hkrati pa označi izpuščeno vsebino. Na primer, rezultat lahko omejite na 1.000 znakov, pri čemer se ohranita začetek in konec:

besedilo na začetku ... 1000 znakov skrajšano ... besedilo na koncu

Sočasno izvajanje in omejen rezultat omogočata, da je agentska zanka hitra in kontekstno učinkovita, kar modelu omogoča nadaljnje sklepanje o relevantnih rezultatih, namesto da bi ga preplavili surovi dnevniki terminala.

Ena od možnih težav z agentskimi zankami je, da se lahko naloge izvajajo dolgo časa. Dolgotrajne naloge zapolnijo okno za kontekst, kar je pomembno za zagotavljanje konteksta čez izmenjave in čez agente. Predstavljajte si agenta, ki prikliče veščino, dobi odgovor, doda priklice orodij in povzetke sklepanja—omejeno kontekstno okno se hitro zapolni. Da se izognemo izgubi pomembnega konteksta, ko agent še naprej deluje, potrebujemo način, da ohranimo ključne podrobnosti in odstranimo vse odvečno. Namesto da bi od razvijalcev zahtevali načrtovanje in vzdrževanje sistemov za povzemanje po meri ali sistemov za prenašanje stanja, smo v API za odgovore dodali izvorno stiskanje, zasnovano tako, da je poravnana s tem, kako se model obnaša in kako je bil treniran.

Naši najnovejši modeli so usposobljeni za analizo predhodnega stanja pogovora in ustvarjanje elementa stiskanja, ki ohranja ključno predhodno stanje v šifrirani predstavitvi, ki učinkuje kot žeton. Po stiskanju je naslednje okno konteksta sestavljeno iz tega elementa stiskanje in delov prejšnjega okna z visoko vrednostjo. To omogoča, da se delovni tokovi koherentno nadaljujejo prek meja oken, tudi v razširjenih večstopenjskih korakih in sejah, ki jih poganjajo orodja. Codex se zanaša na ta mehanizem, da lahko podpira dolgotrajne naloge kodiranja in iterativno izvajanje orodij, ne da bi pri tem poslabšal kakovost.

Zgoščevanje je na voljo bodisi vgrajeno na strežniku bodisi prek samostojne končne točke `/compact`. Stiskanje na strani strežnika vam omogoča, da konfigurirate prag, sistem pa samodejno upravlja časovno razporeditev stiskanje, s čimer odpravi potrebo po zapleteni logiki na strani odjemalca. Omogoča nekoliko večje učinkovito kontekstno okno vnosa, da prenese majhne prekoračitve tik pred zbijanjem, tako da je mogoče zahteve blizu omejitve še vedno obdelati in stisniti, namesto da bi bile zavrnjene. Ko se usposabljanje modelov razvija, se z njim razvija tudi izvorna rešitev za stiskanje pri vsaki izdaji modela OpenAI.

Codex nam je pomagal zgraditi sistem stiskanja, hkrati pa je bil njegov zgodnji uporabnik. Ko je ena Codex instanca naletela na napako pri stiskanju, smo zagnali drugo instanco, da bi jo raziskali. Rezultat je bil, da je Codex dobil izvorni, učinkovit sistem stiskanja že samo s tem, da se je s težavo ukvarjal. Ta sposobnost Codexa, da pregleda in izpopolni samega sebe, je postala posebej zanimiv del dela pri OpenAI. Večina orodij od uporabnika zahteva le, da se nauči, kako jih uporabljati; Codex se uči skupaj z nami.

Zdaj si oglejmo stanje in sredstva. Vsebnik ni le prostor za izvajanje ukazov, temveč tudi delovni kontekst za model. Znotraj vsebnika lahko model bere datoteke, poizveduje po podatkovnih bazah in dostopa do zunanjih sistemov pod nadzorom pravilnikov omrežja.

Prvi del konteksta vsebnika je sistem datotek za nalaganje, organiziranje in upravljanje virov. Zgradili smo API-je za vsebnik in datoteko⁠(odpre se v novem oknu), da bi modelu dali zemljevid razpoložljivih podatkov in mu pomagali izbrati ciljno usmerjene operacije nad datotekami namesto izvajanja širokih, hrupnih pregledov.

Pogosta antipraksa je, da se ves vnos zapakira neposredno v kontekst poziva. Ko se vnosi povečujejo, postane prekomerno polnjenje poziva drago in se model v njem težko znajde. Boljši vzorec je, da vire pripravite v sistemu datotek vsebnika in modelu prepustite, da se odloči, kaj bo odprl, razčlenil ali preoblikoval z ukazi v ukazni vrstici. Podobno kot ljudje tudi modeli bolje delujejo z organiziranimi informacijami.

Drugi del konteksta vsebnika so podatkovne zbirke. V mnogih primerih razvijalcem predlagamo, da strukturirane podatke shranjujejo v zbirkah podatkov, kot je SQLite, in jih poizvedujejo. Namesto da bi na primer v poziv kopirali celotno preglednico, lahko modelu podate opis tabel – kateri stolpci obstajajo in kaj pomenijo – ter mu dovolite, da pridobi vrstice, ki jih potrebuje.

Na primer, če vprašate: »Kateri izdelki so se v tem četrtletju slabše prodajali?«, lahko model povpraša le po ustreznih vrsticah namesto da bi pregledal celotno preglednico. To je hitrejše, cenejše, bolj prilagodljivo za večje nabore podatkov.

Tretji del konteksta vsebnika je omrežni dostop, ki je bistveni del agentskih delovnih obremenitev. Delovni tokovi agenta bodo morda morali pridobiti podatke v živo, poklicati zunanje API-je ali namestiti pakete. Hkrati pa je lahko tvegano, če imajo vsebniki neomejen dostop do interneta: lahko izpostavijo informacije zunanjim spletnim mestom, nenamerno posežejo v občutljive interne sisteme ali sisteme tretjih oseb ali pa otežijo zaščito pred uhajanjem poverilnic in eksfiltracijo podatkov.

Da bi naslovili te pomisleke, ne da bi omejili uporabnost agentov, smo zgradili gostiteljske vsebnike za uporabo stranskega izhodnega posredniškega strežnika (sidecar egress proxy). Vse odhodne omrežne zahteve potekajo prek centralizirane plasti pravilnikov, ki uveljavlja sezname dovoljenih in nadzor dostopa, hkrati pa ohranja promet opazljiv. Za poverilnice uporabljamo vbrizgavanje skrivnosti z obsegom domene na izhodu. Model in vsebnik vidita samo nadomestne oznake, medtem ko surove skrivne vrednosti ostanejo zunaj konteksta, vidnega modelu, in se uporabijo samo za odobrene cilje. To zmanjša tveganje uhajanja, hkrati pa še vedno omogoča overjene zunanje klice.

Ukazi v ukazni vrstici so zmogljivi, vendar se pri številnih opravilih ponavljajo isti večstopenjski vzorci v več korakih. Agenti morajo pri vsakem zagonu znova odkriti delovni tok—znova načrtovati, ponovno izdajati ukaze in se znova učiti konvencij—kar vodi do nedoslednih rezultatov in zapravljene izvedbe. Veščine agenta⁠(odpre se v novem oknu) zapakirajo te vzorce v ponovno uporabne, sestavljive gradnike. Konkretno je spretnost paket map, ki vključuje ‘SKILL.md⁠(odpre se v novem oknu)’ (vsebuje metapodatke in navodila) ter vse podporne vire, kot so specifikacije API-ja in UI sredstva.

Ta struktura se naravno preslika v izvajalno arhitekturo, ki smo jo predhodno opisali. Vsebnik zagotavlja trajne datoteke in kontekst izvajanja, lupinsko orodje pa zagotavlja vmesnik za izvajanje. Ko sta oba na mestu, lahko model po potrebi odkrije datoteke sposobnosti z uporabo ukazov lupine (`ls`, `cat`, etc.), razlaga navodila in izvaja skripte sposobnosti, vse v isti agentski zanki.

Zagotavljamo API-je⁠(odpre se v novem oknu) za upravljanje veščin na platformi OpenAI. Razvijalci naložijo in shranijo mape veščin kot različice paketov, ki jih je mogoče pozneje pridobiti z ID-jem veščine. Preden Responses API pošlje poziv modelu, naloži veščino in jo vključi v kontekst modela. To zaporedje je deterministično:

1. Pridobite metapodatke veščin, vključno z imenom in opisom.
2. Pridobite paket veščin, ga kopirajte v vsebnik in odprite.
3. Posodobite kontekst modela z metapodatki o veščinah in potjo do vsebnika.

Ko se odloča, ali je veščina ustrezna, model postopoma raziskuje njena navodila in izvaja njene skripte prek lupinskih ukazov v vsebniku.

Da se vse skupaj sestavi: Responses API zagotavlja orkestracijo, lupinsko orodje zagotavlja izvedljiva dejanja, gostiteljski vsebnik zagotavlja trajni kontekst izvajalnega okolja, plasti veščin ponovno uporabne logike delovnega toka, stiskanje pa agentu omogoča, da dolgo časa dela s kontekstom, ki ga potrebuje.

S temi osnovnimi gradniki se lahko en sam poziv razširi v celovit potek dela od začetka do konca: odkrijte pravo veščino, pridobite podatke, jih pretvorite v lokalno strukturirano stanje ter učinkovito poizvedite in ustvarite trajne artefakte. 

Spodnji diagram prikazuje, kako ta sistem deluje pri ustvarjanju preglednice iz podatkov v živo.

Za poglobljen primer kombiniranja orodja za ukazno vrstico in računalniškega okolja za delovne tokove od začetka do konca si oglejte našo objavo na razvijalskem blogu⁠(odpre se v novem oknu) in kuharsko knjigo⁠(odpre se v novem oknu), ki vas popeljeta skozi pakiranje veščine in njeno izvajanje prek Responses API.

Veselimo se, da vidimo, kaj bodo razvijalci ustvarili s tem naborom osnovnih elementov. Jezikovni modeli so namenjeni več kot le ustvarjanju besedila, slik in zvoka–še naprej bomo razvijali našo platformo, da bo bolj sposobna obvladovati kompleksne naloge iz resničnega sveta v velikem obsegu.