Pereiti prie pagrindinio turinio
OpenAI

2026 m. kovo 11 d.

Inžinerija

Nuo modelio iki agento: „Responses API“ aprūpinimas kompiuterine aplinka

Autoriai: Bo Xu, Danny Zhang ir Rohit Arunachalam

Įkeliama...

Šiuo metu pereiname nuo modelių, kurie puikiai atlieka konkrečias užduotis, prie agentų, galinčių tvarkyti sudėtingas darbo eigas. Ragindami modelius, galite pasiekti tik apmokytą intelektą. Tačiau suteikus modeliui kompiuterinę aplinką galima pasiekti gerokai platesnį naudojimo atvejų spektrą, pavyzdžiui, paleisti paslaugas, užklausti duomenų iš API arba generuoti naudingesnius artefaktus, pavyzdžiui, skaičiuokles ar ataskaitas.

Keli praktiniai nesklandumai išryškėja, kai bandote kurti agentus: kur dėti tarpinius failus, kaip išvengti didelių lentelių įklijavimo į užklausą, kaip suteikti darbo eigai tinklo prieigą nesukeliant saugumo galvos skausmo ir kaip tvarkyti laiko limitus bei pakartotinius bandymus nekuriant darbo eigos sistemos patiems.

Užuot palikę programuotojams patiems kurti savo vykdymo aplinkas, sukūrėme reikiamus komponentus, kad „Responses API“(atsidaro naujame lange) būtų aprūpinta kompiuterio aplinka, leidžiančia patikimai vykdyti realaus pasaulio užduotis.

„OpenAI“ „Responses API“ kartu su apvalkalo įrankiu ir debesyje talpinamo konteinerio darbo erdve yra sukurta spręsti šias praktines problemas. Modelis siūlo veiksmus ir komandas; platforma jas vykdo izoliuotoje aplinkoje su failų sistema įvestims ir išvestims, pasirenkama susisteminta saugykla (pvz., „SQLite“) ir ribota tinklo prieiga. 

Šiame įraše aptarsime, kaip sukūrėme agentams skirtą kompiuterio aplinką, ir pasidalysime ankstyvomis pamokomis, kaip ją naudoti greitesnėms, pakartojamoms ir saugesnėms gamybinėms darbo eigoms.

Apvalkalo įrankis

Gera agento darbo eiga prasideda nuo glaudaus vykdymo ciklo: modelis pasiūlo veiksmą, pvz., skaityti failus arba gauti duomenis per API, platforma jį vykdo, o rezultatas pereina į kitą žingsnį. Pradėsime nuo apvalkalo įrankio – paprasčiausio būdo pamatyti šį ciklą veikiant – o tada aptarsime konteinerio darbo erdvę, tinklų kūrimą, pakartotinai naudojamus įgūdžius ir konteksto glaudinimą.

Norint suprasti apvalkalo įrankį, pirmiausia naudinga suprasti, kaip kalbos modelis apskritai naudoja įrankius: tokiems dalykams kaip funkcijos iškvietimas arba sąveikaujimas su kompiuteriu. Mokymo metu modeliui žingsnis po žingsnio pateikiami pavyzdžiai, kaip naudojami įrankiai ir kokie yra jų poveikiai. Tai padeda modeliui išmokti nuspręsti, kada naudoti įrankį ir kaip juo naudotis. Kai sakome „naudojant įrankį“, turime omenyje, kad modelis iš tikrųjų tik pasiūlo įrankio kvietimą. Ji negali pati savaime įvykdyti kvietimo.

Apvalkalo įrankis yra „tik dar vienas įrankis“ su diagrama

Apvalkalo įrankis padaro modelis gerokai galingesnį: jis sąveikauja su kompiuteriu per komandinę eilutę, kad atliktų įvairias užduotis – nuo teksto paieškos iki API užklausų siuntimo jūsų kompiuteryje. Sukurtas naudojant pažįstamus „Unix“ įrankius, mūsų apvalkalo įrankis gali atlikti viską, ko tikitės, o tokios programos kaip grep, curl ir awk yra iš karto prieinamos.

Palyginti su mūsų esamu kodo interpretatoriumi, kuris vykdo tik „Python“, apvalkalo įrankis suteikia galimybę naudoti daug platesnį naudojimo atvejų spektrą, pavyzdžiui, paleisti „Go“ ar „Java“ programas arba paleisti „NodeJS“ serverį. Šis lankstumas leidžia modeliui atlikti sudėtingas agentines užduotis.

Agento ciklo orkestruotė

Pats savaime modelis gali tik pasiūlyti apvalkalo komandas, bet kaip šios komandos vykdomos? Mums reikia orkestratoriaus, kad gautume modelio išvestį, iškviestume įrankius ir perduotume įrankio atsaką atgal modeliui cikle, kol užduotis bus baigta.

„Responses API“ yra būdas, kaip programuotojai sąveikauja su „OpenAI“ modeliu. Naudojant su pasirinktiniais įrankiais, „Responses API“ grąžina valdymą klientui, o klientui reikia savo karkaso įrankiams vykdyti. Tačiau ši API taip pat gali iš karto orkestruoti tarp modelio ir talpinamų įrankių. 

Kai „Responses API“ gauna užklausą, ji surenka modelio kontekstą: naudotojo užklausą, ankstesnės pokalbio būseną ir įrankių instrukcijas. Kad apvalkalo vykdymas veiktų, užklausoje turi būti paminėta, kad naudojamas apvalkalo įrankis and pasirinktas modelis turi būti apmokytas siūlyti apvalkalo komandas—tam apmokyti modeliai GPT‑5.2 ir naujesni. Turėdamas visą šį kontekstą, modelis tada nusprendžia, koks bus kitas veiksmas. Jei pasirenkamas apvalkalo vykdymas, jis grąžina vieną ar daugiau apvalkalo komandų į „Responses API“ paslaugą. API paslauga persiunčia tas komandas į konteinerio vykdymo aplinką, srautiniu būdu grąžina apvalkalo išvestį ir pateikia ją modeliui kitos užklausos kontekste. Tada modelis gali patikrinti rezultatus, pateikti tolesnes komandas arba pateikti galutinį atsakymą. „Responses API“ kartoja šį ciklą, kol modelis grąžina užbaigimą be papildomų apvalkalo komandų.

Agento ciklo diagrama: „Responses API“ koordinuoja modelio ir apvalkalo vykdymą konteineryje

Kai „Responses API“ vykdo apvalkalo komandą, ji palaiko srautinį ryšį su konteinerių paslauga. Kai generuojama išvestis, API beveik realiuoju laiku perduoda ją modeliui, kad modelis galėtų nuspręsti, ar laukti daugiau išvesties, vykdyti kitą komandą ar pereiti prie galutinio atsakymo.

Srautinis apvalkalo komandų vykdymo išvesties pateikimas

„Responses API“ transliuoja apvalkalo komandos išvestį

Modelis gali pasiūlyti kelias apvalkalo komandas per vieną veiksmą, o „Responses API“ gali jas vykdyti lygiagrečiai naudodama atskirus konteinerio seansus. Kiekvienas seansas srautiniu būdu perduoda išvestį nepriklausomai, o API sujungia tuos srautus atgal į susistemintas įrankių išvestis kaip kontekstą. Kitaip tariant, agentas ciklas gali lygiagrečiai vykdyti darbą, pavyzdžiui, ieškoti failų, gauti duomenis ir tikrinti tarpinius rezultatus.

„Responses API“ leidžia vienu metu aptarnauti kelias komandų vykdymo sesijas

Kai komanda apima failų operacijas ar duomenų apdorojimą, apvalkalo išvestis gali tapti labai didelė ir sunaudoti konteksto biudžetus nepridėdama naudingų signalų. Norėdamas tai valdyti, modelis nurodo išvesties ribą kiekvienai komandai. „Responses API“ taiko tą apribojimą ir grąžina apribotą rezultatą, kuris išsaugo ir išvesties pradžią, ir pabaigą, kartu pažymėdamas praleistą turinį. Pavyzdžiui, galite apriboti išvestį iki 1,000 personažų, išsaugant pradžią ir pabaigą:

Tekstas pradžioje ... sutrumpinta iki 1000 simbolių ... tekstas pabaigoje

Kartu lygiagretus vykdymas ir apribota išvestis padaro agento ciklą ir greitą, ir efektyviai naudojantį kontekstą, todėl modelis gali toliau tęsti protavimą remdamasis aktualiais rezultatais, užuot buvęs užgožtas neapdorotų terminalo žurnalų.

Kai konteksto langas prisipildo: suglaudinimas

Viena galima agento ciklų problema yra ta, kad užduotys gali būti vykdomos ilgą laiką. Ilgai trunkančios užduotys užpildo konteksto langą, kuris yra svarbus kontekstui pateikti per kelis etapus ir tarp agentų. Įsivaizduokite agentą, kviečiantį įgūdį, gaunantį atsakymą, pridedantį įrankių kvietimus ir protavimo santraukas—ribotas konteksto langas greitai prisipildo. Kad neprarastume svarbaus konteksto, kai agentas toliau veikia, mums reikia būdo išsaugoti pagrindines detales ir pašalinti viską, kas nereikalinga. Užuot reikalavę, kad programuotojai kurtų ir prižiūrėtų pasirinktines apibendrinimo ar būseną išlaikančias sistemas, į „Responses API“ įtraukėme vietinį glaudinimą, sukurtą taip, kad atitiktų tai, kaip elgiasi modelis ir kaip jis buvo apmokytas.

Mūsų naujausi modeliai yra apmokyti analizuoti ankstesnę pokalbio būseną ir sukurti glaudinimo elementą, kuris išsaugo pagrindinę ankstesnę būseną šifruotame, žetonams efektyviame atvaizde. Po suglaudinimo kitas konteksto langas susideda iš šio suglaudinimo elemento ir didelės vertės ankstesnio lango dalių. Tai leidžia darbo eigoms nuosekliai tęstis per langų ribas, net ir išplėstose daugiapakopėse ir įrankiais grindžiamose sesijose. „Codex“ remiasi šiuo mechanizmu, kad galėtų palaikyti ilgai trunkančias kodavimo užduotis ir iteratyvų įrankių vykdymą neprastinant kokybės.

Sutraukimas galimas arba integruotas serveryje, arba per atskirą `/compact` prieigos tašką. Serverio pusės sutraukimas leidžia sukonfigūruoti slenkstį, o sistema automatiškai tvarko sutraukimo laiką, todėl nebereikia sudėtingos kliento pusės logikos. Tai leidžia šiek tiek didesnį efektyvų įvesties konteksto langą, kad būtų toleruojami nedideli viršijimai prieš pat suglaudinimą, todėl užklausos, esančios netoli ribos, vis tiek gali būti apdorotos ir suglaudintos, o ne atmestos. Tobulėjant modelio mokymui, kartu su kiekvienu „OpenAI“ modelio leidimu tobulėja ir vietinis sutraukimo sprendimas.

„Codex“ padėjo mums sukurti glaudinimo sistemą, kartu būdamas ankstyvas jos naudotojas. Kai vienas „Codex“ egzempliorius susidurdavo su glaudinimo klaida, paleisdavome antrą egzempliorių, kad ištirtume. Rezultatas buvo toks, kad „Codex“ gavo savąją, efektyvią glaudinimo sistemą vien dirbdamas ties problema. Šis „Codex“ gebėjimas patikrinti ir patobulinti patį save tapo ypač įdomia darbo „OpenAI“ dalimi. Daugumai įrankių tereikia, kad naudotojas išmoktų jais naudotis; „Codex“ mokosi kartu su mumis.

Konteinerio kontekstas

Dabar aptarkime būklę ir išteklius. Konteineris yra ne tik vieta komandoms vykdyti, bet ir darbinis kontekstas modeliui. Konteinerio viduje modelis gali skaityti failus, užklausti duomenų bazes ir pasiekti išorines sistemas pagal tinklo politikos kontrolę.

Diagrama, rodanti vykdymo laiko konteinerio viduje: failus, duomenų bazes, įgūdžius ir politikos valdomą tinklą

Failų sistemos

Pirmoji konteinerio konteksto dalis yra failų sistema, skirta ištekliams įkelti, tvarkyti ir valdyti. Sukūrėme konteinerio ir failų(atsidaro naujame lange) API, kad suteiktume modeliui prieinamų duomenų žemėlapį ir padėtume jam pasirinkti tikslines failų operacijas, užuot atlikus plačius, triukšmingus nuskaitymus.

Dažnas antimodelis – visą įvestį tiesiogiai sudėti į užklausos kontekstą. Didėjant įvestims, užklausos perpildymas tampa brangus ir modeliui sunku jame orientuotis. Geresnis šablonas – paruošti išteklius konteinerio failų sistemoje ir leisti modeliui nuspręsti, ką atidaryti, išanalizuoti ar transformuoti naudojant apvalkalo komandas. Panašiai kaip žmonės, modeliai geriau veikia su organizuota informacija.

Duomenų bazės

Antroji konteinerio konteksto dalis yra duomenų bazės. Daugeliu atvejų siūlome kūrėjams struktūrizuotus duomenis saugoti duomenų bazėse, tokiose kaip „SQLite“, ir juos užklausti. Užuot kopijavę į užklausą visą skaičiuoklę, pavyzdžiui, galite pateikti modeliui lentelių aprašą – kokie stulpeliai yra ir ką jie reiškia – ir leisti jam ištraukti reikiamas eilutes.

Pavyzdžiui, jei paklausite: „Kurių produktų pardavimai šį ketvirtį mažėjo?“, modelis gali pateikti užklausą tik atitinkamoms eilutėms, užuot nuskenavęs visą skaičiuoklę. Tai yra greičiau, pigiau, labiau pritaikoma didesniems duomenų rinkiniams.

Tinklo prieiga 

Trečioji konteinerio konteksto dalis yra tinklo prieiga – esminė agentų darbo krūvių dalis. Agentų darbo eigai gali reikėti gauti tiesioginius duomenis, iškviesti išorines API arba įdiegti paketus. Tuo pačiu metu suteikti konteineriams neribotą prieigą prie interneto gali būti rizikinga: tai gali atskleisti informaciją išorinėms svetainėms, netyčia pasiekti jautrias vidines ar trečiųjų šalių sistemas arba apsunkinti apsaugą nuo prisijungimo duomenų nutekėjimo ir duomenų išgavimo.

Siekdami išspręsti šias problemas neapribodami agentų naudingumo, sukūrėme debesyje talpinamus konteinerius, kurie naudoja šalia aplikacijos veikiantį tarpinį serverį, kuris kontroliuoja visą iš aplikacijos išeinantį tinklo srautą. Visos išeinančios tinklo užklausos teka per centralizuotą politikos sluoksnį, kuris priverstinai taiko leidžiamuosius sąrašus ir prieigos valdymą, kartu išlaikydamas srautą stebimą. Prisijungimo duomenims naudojame domeno apimties slaptųjų duomenų įterpimą išėjimo taške. Modelis ir konteineris mato tik vietos rezervavimo ženklus, o neapdorotos slaptos reikšmės lieka už modeliui matomo konteksto ribų ir pritaikomos tik patvirtintoms paskirties vietoms. Tai sumažina nutekėjimo riziką, kartu vis dar leidžiant atlikti autentifikuotus išorinius iškvietimus.

Valdomos tinklo prieigos per išėjimo tarpinį serverį diagrama: konteinerio sąranka

Agento įgūdžiai

Apvalkalo komandos yra galingos, tačiau daugelis užduočių kartoja tuos pačius kelių žingsnių šablonus. Agentai kiekvieną kartą turi iš naujo atrasti veiklos eigą – iš naujo planuoti, iš naujo išleisti komandas ir iš naujo išmokti konvencijas – todėl rezultatai būna nenuoseklūs, o vykdymas švaistomas. Agento įgūdžiai(atsidaro naujame lange) sujungia tuos šablonus į pakartotinai naudojamus, komponuojamus kūrimo blokus. Konkrečiai, įgūdis yra aplanko rinkinys, į kurį įeina ‘SKILL.md(atsidaro naujame lange)’ (turinčių metaduomenis ir instrukcijas) bei bet kokius pagalbinius išteklius, pvz., API specifikacijas ir UI išteklius.

Ši struktūra natūraliai atitinka vykdymo aplinkos architektūrą, kurią aprašėme anksčiau. Konteineris suteikia nuolatinius failus ir vykdymo kontekstą, o apvalkalo įrankis suteikia vykdymo sąsają. Kai abu yra vietoje, modelis gali prireikus aptikti įgūdžių failus naudodamas apvalkalo komandas (`ls`, `cat` ir kt.), interpretuoti instrukcijas ir vykdyti įgūdžių scenarijus – visa tai tame pačiame agento cikle.

Mes teikiame API(atsidaro naujame lange) , skirtus valdyti įgūdžius „OpenAI“ platformoje. Kūrėjai įkelia ir saugo įgūdžių aplankus kaip versijuotus paketus, kuriuos vėliau galima gauti pagal įgūdžio ID. Prieš siunčiant užklausą į modelį, „Responses API“ įkelia įgūdį ir įtraukia jį į modelio kontekstą. Ši seka yra deterministinė:

  1. Gauti įgūdžių metaduomenis, įskaitant pavadinimą ir aprašymą.
  2. Gaukite įgūdžių rinkinį, nukopijuokite jį į konteinerį ir išpakuokite.
  3. Atnaujinkite modelio kontekstą, pridėdami įgūdžių metaduomenis ir konteinerio kelią.

Spręsdamas, ar įgūdis yra aktualus, modelis palaipsniui nagrinėja jo instrukcijas ir vykdo jo scenarijus per apvalkalo komandas konteineryje.

Įgūdžio įkėlimo konvejerio diagrama: registras, paketas, vykdymo aplinka

Kaip kuriami agentai

Sujungiant visas dalis: „Responses API“ užtikrina orkestravimą, apvalkalo įrankis pateikia vykdomus veiksmus, debesyje talpinamas konteineris suteikia nuolatinį vykdymo kontekstą, įgūdžių sluoksnis sudeda daugkartinio naudojimo darbo eigos logiką, o sutankinimas leidžia agentui ilgai veikti su jam reikalingu kontekstu.

Naudojant šiuos primityvus, viena užklausa gali išsiplėsti į nuo pradžios iki galo vykdomą darbo eigą: atrasti tinkamą įgūdį, gauti duomenis, paversti juos vietine struktūrizuota būsena, efektyviai ją užklausti ir generuoti patvarius artefaktus. 

Žemiau pateiktoje diagramoje parodyta, kaip ši sistema veikia kuriant skaičiuoklę iš tiesioginių duomenų.

Užklausos gyvavimo ciklo diagrama: nuo vienos užklausos iki patvarių artefaktų, įgūdžių atradimas

„Responses API“ koordinuoja agentinę užduotį

Sukurkite savo agentą

Išsamų pavyzdį, kaip derinti apvalkalo įrankį ir kompiuterio aplinką visapusiškoms darbo eigoms nuo pradžios iki pabaigos, rasite mūsų kūrėjų tinklaraščio įraše(atsidaro naujame lange) ir receptų knygoje(atsidaro naujame lange), kur žingsnis po žingsnio parodoma, kaip supakuoti įgūdį ir jį vykdyti per „Responses API“.

Nekantraujame pamatyti, ką kūrėjai sukurs naudodami šį primityvų rinkinį. Kalbos modeliai skirti ne tik tekstui, vaizdams ir garsui generuoti – toliau tobulinsime savo platformą, kad ji taptų pajėgesnė tvarkyti sudėtingas, realaus pasaulio užduotis dideliu mastu.

Autorius

Bo Xu, Danny Zhang ir Rohit Arunachalam