Od modela do agenta: opremanje Responses API-ja računalnim okruženjem
Autor: Bo Xu, Danny Zhang i Rohit Arunachalam
Trenutačno smo u prijelazu s korištenja modela, koji briljiraju u određenim zadacima, na korištenje agenata sposobnih za upravljanje složenim tijekovima rada. Pomoću upita modela možete pristupiti samo istreniranoj inteligenciji. No davanje modelu računalnog okruženja može omogućiti mnogo širi raspon slučajeva upotrebe, poput pokretanja usluga, traženja podataka iz API-ja ili generiranja korisnijih artefakata poput proračunskih tablica ili izvješća.
Nekoliko praktičnih problema pojavljuje se kada pokušate izgraditi agente: gdje smjestiti međudatoteke, kako izbjeći lijepljenje velikih tablica u upit, kako radnom tijeku omogućiti pristup mreži bez stvaranja sigurnosne glavobolje i kako rukovati istecima vremena i ponovnim pokušajima bez toga da sami izgradite sustav radnog tijeka.
Umjesto da programerima prepustimo izgradnju vlastitih okruženja za izvršavanje, izgradili smo potrebne komponente kako bismo Responses API(otvara se u novom prozoru) opremili računalnim okruženjem za pouzdano izvršavanje stvarnih zadataka.
OpenAI-jev API odgovora, zajedno s alatom shell i udomljenim radnim prostorom spremnika, osmišljen je za rješavanje tih praktičnih problema. Model predlaže korake i naredbe, platforma ih pokreće u izoliranom okruženju s datotečnim sustavom za ulaze i izlaze, opcionalnom strukturiranom pohranom (poput SQLitea) i ograničenim pristupom mreži.
U ovoj objavi objasnit ćemo kako smo izradili računalno okruženje za agente i podijeliti rane lekcije o njegovoj upotrebi za brže, ponovljivije i sigurnije produkcijske tijekove rada.
Dobar radni tijek agenta započinje čvrstom petljom izvršavanja: model predlaže radnju poput čitanja datoteka ili dohvaćanja podataka putem API-ja, platforma je izvršava, a rezultat se prenosi u sljedeći korak. Započet ćemo s alatom shell — najjednostavnijim načinom da vidite ovu petlju na djelu — a zatim obraditi radni prostor spremnika, umrežavanje, ponovno upotrebljive vještine i sažimanje konteksta.
Kako biste razumjeli alat shell, najprije je korisno shvatiti kako jezični model općenito upotrebljavaju alate, primjerice za pozivanje funkcija ili interakciju s računalom. Tijekom obučavanja modelu se korak po korak prikazuju primjeri kako se alati koriste i kakvi su rezultirajući učinci. To pomaže modelu da nauči odlučiti kada i kako upotrebljavati alat. Kada kažemo „upotreba alata“, mislimo da model zapravo samo predlaže poziv alata. Ne može samostalno izvršiti poziv.
Alat shell čini model znatno moćnijim: komunicira s računalom putem naredbenog retka kako bi obavio širok raspon zadataka, od pretraživanja teksta do slanja API zahtjeva na vašem računalu. Izgrađen na poznatim Unix alatima, naš alat shell može učiniti sve što biste očekivali, uz uslužne programe kao što su grep, curl i awk dostupne odmah po instalaciji.
U usporedbi s našim postojećim interpreterom kôda, koji izvršava samo Python, alat shell omogućuje mnogo širi raspon slučajeva upotrebe, poput pokretanja Go ili Java programa ili pokretanja NodeJS poslužitelja. Ta fleksibilnost omogućuje modelu da izvršava složene agentske zadatke.
Sam po sebi, model može samo predlagati shell naredbe, ali kako se te naredbe izvršavaju? Trebamo orkestrator za dobivanje izlaza modela, pozivanje alata i prosljeđivanje odgovora alata natrag modelu u petlju, sve dok zadatak ne bude dovršen.
Responses API je način na koji razvojni inženjeri komuniciraju s OpenAI model. Kad se koristi s prilagođenim alatima, Responses API vraća kontrolu klijentu, a klijent zahtijeva vlastiti harness za pokretanje alata. Međutim, taj API može također izvan okvira orkestrirati između modela i hostanih alata.
Kada Responses API primi upit, sastavlja kontekst modela: korisnički upit, prethodno stanje razgovora i upute alata. Da bi shell izvršavanje funkcioniralo, upit mora spomenuti upotrebu alata shell i odabrani model mora biti treniran da predlaže naredbe ljuske —modeli GPT‑5.2 i noviji trenirani su za to. Uz sav ovaj kontekst, model zatim odlučuje o sljedećoj radnji. Ako odabere izvršavanje ljuske, vraća jednu ili više naredbi ljuske usluzi Responses API. API usluga prosljeđuje te naredbe okruženju za izvođenje spremnika, struji natrag izlaz ljuske i prosljeđuje ga modelu u kontekstu sljedećeg zahtjeva. Model zatim može pregledati rezultate, izdati naknadne naredbe ili proizvesti konačan odgovor. Responses API ponavlja ovu petlju sve dok model ne vrati dovršenje bez dodatnih naredbi ljuske.
Kada Responses API izvršava shell naredbu, održava vezu za strujanje s uslugom spremnika. Kako se izlaz proizvodi, API ga prenosi modelu gotovo u stvarnom vremenu kako bi model mogao odlučiti hoće li pričekati još izlaza, pokrenuti drugu naredbu ili prijeći na konačni odgovor.
Responses API niza izlaza naredbi shell
Model može predložiti više shell naredbi u jednom koraku, a Responses API može ih istodobno izvršiti upotrebom zasebnih sesija spremnika. Svaka sesija neovisno struji izlaz, a API te struje multipleksira natrag u strukturirane izlaze alata kao kontekst. Drugim riječima, petlja agenta može paralelno obavljati zadatke poput pretraživanja datoteka, dohvaćanja podataka i provjere međurezultata.
Kada naredba uključuje operacije nad datotekama ili obradu podataka, izlaz ljuske može postati vrlo velik i potrošiti proračune konteksta bez dodavanja korisnih signala. Kako bi to kontrolirao, model određuje ograničenje izlaza po naredbi. Responses API osigurava primjenu tog ograničenja i vraća ograničeni rezultat koji čuva i početak i kraj izlaza, uz označavanje izostavljenog sadržaja. Na primjer, mogli biste ograničiti izlaz na 1 000 znakova, uz očuvani početak i kraj:
tekst na početku ... 1000 znakova skraćeno ... tekst na kraju
Zajedno, istodobno izvršavanje i ograničeni izlaz čine petlju agenta i brzom i kontekstno učinkovitom, tako da model može nastaviti rasuđivanje o relevantnim rezultatima umjesto da ga preplave sirovi zapisnici terminala.
Jedan potencijalni problem s petljama agenta jest to što se zadaci mogu izvoditi dugo vremena. Dugotrajni zadaci ispunjavaju kontekstni prozor, što je važno za pružanje konteksta kroz više razmjena i kroz više agenata. Zamislite agenta kako poziva vještinu, dobiva odgovor, dodaje pozive alata i sažetke rasuđivanja—ograničeni kontekstualni prozor brzo se popuni. Kako bismo izbjegli gubitak važnog konteksta dok agent nastavlja raditi, trebamo način da zadržimo ključne pojedinosti i uklonimo sve suvišno. Umjesto da zahtijevamo od razvojnih inženjera da dizajniraju i održavaju prilagođene sustave za sažimanje ili sustave koji prenose stanje, dodali smo izvorno sažimanje u Responses API, osmišljeno tako da bude usklađeno s načinom na koji se model ponaša i kako je treniran.
Naši najnoviji modeli obučeni su za analizu prethodnog stanja razgovora i izradu stavke sažimanja koja čuva ključno prethodno stanje u šifriranom prikazu koji tokene iskorištava na učinkovitom prikazu. Nakon sažimanja, sljedeći kontekstni prozor sastoji se od te stavke sažimanja i dijelova visoke vrijednosti ranijeg prozora. To omogućuje da se radni tokovi nastave koherentno preko granica prozora, čak i u proširenim višekoračnim sesijama i sesijama vođenima alatima. Codex se oslanja na taj mehanizam kako bi podržao dugotrajne zadatke kodiranja i iterativno izvršavanje alata bez narušavanja kvalitete.
Zbijanje je dostupno ili ugrađeno na poslužitelju ili putem samostalne krajnje točke `/compact`. Zbijanje na strani poslužitelja omogućuje vam konfiguriranje praga, a sustav automatski upravlja vremenom zbijanja, čime se uklanja potreba za složenom logikom na strani klijenta. Omogućuje nešto veći djelotvorni kontekstni prozor unosa kako bi tolerirao mala prekoračenja neposredno prije sažimanja, tako da se zahtjevi blizu ograničenja i dalje mogu obraditi i sažeti umjesto da se odbiju. Kako se treniranje modela razvija, izvorno rješenje za zbijanje razvija se zajedno s njim za svako izdanje OpenAI modela.
Codex nam je pomogao izgraditi sustav zbijanja, a istodobno je bio i njegov rani korisnik. Kad bi jedna instanca Codex naišla na pogrešku sažimanja, pokrenuli bismo drugu instancu kako bismo istražili. Rezultat je bio da je Codex dobio izvorni, učinkovit sustav kompakcije samo tako što je radio na problemu. Ta Codexova sposobnost da ispituje i usavršava sam sebe postala je posebno zanimljiv dio rada u OpenAI. Većina alata od korisnika zahtijeva samo da nauči kako ih treba upotrebljavati, Codex uči zajedno s nama.
Sada prijeđimo na stanje i resurse. Spremnik nije samo mjesto za pokretanje naredbi, već i radni kontekst za model. Unutar spremnika model može čitati datoteke, postavljati upite bazama podataka i pristupati vanjskim sustavima uz kontrole mrežnih pravila.
Prvi dio konteksta spremnika jest datotečni sustav za postavljanje, organiziranje i upravljanje resursima. Izradili smo API-je za spremnik i datoteku(otvara se u novom prozoru) kako bismo modelu dali mapu dostupnih podataka i pomogli mu da odabere ciljane operacije nad datotekama umjesto izvođenja širokih, bučnih skeniranja.
Uobičajeni anti-uzorak je pakiranje svih ulaznih podataka izravno u upit. Kako ulazi rastu, prepunjavanje upita postaje skupo i modelu je teško njime se snalaziti. Bolji je obrazac postaviti resurse u datotečni sustav spremnika i prepustiti modelu da odluči što će otvoriti, raščlaniti ili transformirati pomoću shell naredbi. Slično ljudima, modeli bolje rade s organiziranim informacijama.
Drugi dio konteksta spremnika su baze podataka. U mnogim slučajevima predlažemo da programeri pohranjuju strukturirane podatke u bazama podataka kao SQLite i da im daju upite. Umjesto kopiranja cijele proračunske tablice u upit, primjerice, možete modelu dati opis tablica — koji stupci postoje i što znače — i pustiti ga da povuče retke koji su mu potrebni.
Na primjer, ako pitate: „Koji su proizvodi imali pad prodaje ovog tromjesečja?”, model može upitati samo relevantne retke umjesto da skenira cijelu proračunsku tablicu. To je brže, jeftinije, skalabilnije za veće skupove podataka.
Treći dio konteksta spremnika je mrežni pristup, ključan dio radnih opterećenja agenta. Radni tijek agenta možda mora dohvatiti podatke uživo, pozvati vanjske API-je ili instalirati pakete. Istodobno, dati spremnicima neograničen pristup internetu može biti rizično: može izložiti informacije vanjskim web-mjestima, nenamjerno stupiti u kontakt s osjetljivim internim sustavima ili sustavima trećih strana ili otežati zaštitu od curenja vjerodajnica i eksfiltracije podataka.
Kako bismo riješili te probleme bez ograničavanja korisnosti agenata, izgradili smo hostane spremnike za upotrebu sidecar izlaznog proxyja. Svi odlazni mrežni zahtjevi prolaze kroz centralizirani sloj pravila koji provodi popise dopuštenih adresa i kontrole pristupa, uz zadržavanje vidljivosti prometa. Za vjerodajnice koristimo ubrizgavanje tajni s opsegom domene na izlazu. Model i spremnik vide samo zamjenske oznake, dok neobrađene tajne vrijednosti ostaju izvan konteksta vidljivog modelu i primjenjuju se samo za odobrena odredišta. Time se smanjuje rizik od curenja, a istodobno se i dalje omogućuju autentificirani vanjski pozivi.
Shell naredbe su moćne, ali mnogi zadaci ponavljaju iste višekoračne obrasce. Agenti moraju iznova otkrivati tijek rada pri svakom pokretanju — ponovno planirati, ponovno izdavati naredbe i ponovno učiti konvencije — što dovodi do nedosljednih rezultata i uzaludnog izvršavanja. Vještine agenta(otvara se u novom prozoru) grupiraju te obrasce u višekratne, sastavljive građevne blokove. Konkretno, vještina je paket mape koji uključuje ‘SKILL.md(otvara se u novom prozoru)’ (koji sadrže metapodatke i upute) plus svi popratni resursi, kao što su API specifikacije i UI resursi.
Ta se struktura prirodno preslikava na arhitekturu izvođenja koju smo ranije opisali. Spremnik pruža trajne datoteke i kontekst vremena izvođenja, a alat shell pruža sučelje za izvršavanje. Kad su oba na mjestu, model može otkrivati datoteke vještina pomoću shell naredbi (`ls`, `cat`, etc.) kada mu zatreba, tumačiti upute i pokretati skripte vještina sve u istoj petlji agenta.
Pružamo API-je(otvara se u novom prozoru) za upravljanje vještinama na platformi OpenAI. Razvojni programeri prenose i pohranjuju mape vještina kao verzionirane pakete, koje se kasnije mogu dohvatiti prema ID-u vještine. Prije slanja upita modelu, Responses API učitava vještinu i uključuje je u kontekst modela. Ta je sekvenca deterministička:
- Dohvatite metapodatke o vještinama, uključujući naziv i opis.
- Dohvatite paket vještina, kopirajte ga u spremnik i raspakirajte ga.
- Ažurirajte kontekst modela metapodacima o vještinama i putanji spremnika.
Pri odlučivanju o tome je li vještina relevantna, model postupno istražuje svoje upute i izvršava svoje skripte putem shell naredbi u spremniku.
Da sve dijelove povežemo u cjelinu: Responses API pruža orkestraciju, alat ljuske pruža izvršne radnje, hosted container pruža trajni kontekst okruženja za izvođenje, vještine slojevito organiziraju logiku radnog toka za višekratnu upotrebu, a kompaktiranje omogućuje agentu da radi dugo vremena s kontekstom koji mu je potreban.
S ovim primitivima, jedan upit može se proširiti u tijek rada od početka do kraja: otkriti pravu vještinu, dohvatiti podatke, transformirati ih u lokalno strukturirano stanje, učinkovito ih obraditi i generirati trajne artefakte.
Dijagram u nastavku prikazuje kako taj sustav funkcionira za izradu proračunske tablice iz podataka uživo.
Responses API orkestrira agentički zadatak
Za detaljan primjer kombiniranja alata shell i računalnog okruženja za tijekove rada od početka do kraja, pogledajte našu objavu na blogu za razvojne inženjere(otvara se u novom prozoru) i kuharicu(otvara se u novom prozoru) koji vas vode kroz pakiranje vještine i njezino izvršavanje putem Responses API-ja.
Jedva čekamo vidjeti što će programeri izgraditi s tim skupom primitiva. Jezični modeli namijenjeni su za više od samog generiranja teksta, slika i zvuka – nastavit ćemo razvijati našu platformu kako bi postala sposobnija za rješavanje složenih zadataka iz stvarnog svijeta u velikom opsegu.


