Mudelist agendini: Responses API varustamine arvutikeskkonnaga

Oleme praegu üleminekul mudelite kasutamiselt, mis paistavad silma konkreetsete ülesannete täitmisel, agentide kasutamisele, mis suudavad hallata keerukaid töövooge. Mudeleid viibates saad ligi ainult treenitud intellektile. Siiski võib mudelile arvutikeskkonna andmine võimaldada palju laiemat kasutusjuhtude valikut, näiteks teenuste käivitamist, andmete küsimist API-dest või kasulikumate artefaktide, nagu arvutustabelite või aruannete, genereerimist.

Mõned praktilised probleemid kerkivad esile, kui püüad ehitada agente: kuhu panna vahefailid, kuidas vältida suurte tabelite kleepimist viipa, kuidas anda töövoole võrgujuurdepääs ilma turvalisuse vaatest peavalu tekitamata ning kuidas käsitleda ajalõppe ja korduskatseid ilma ise töövoosüsteemi ehitamata.

Selle asemel, et panna arendajatele kohustus ehitada oma täitmiskeskkonnad, ehitasime vajalikud komponendid, et varustada Responses API⁠(avaneb uues aknas) arvutikeskkonnaga, mis aitab usaldusväärselt täita pärismaailma ülesandeid.

OpenAI Responses API koos shell-tööriista ja majutatud konteineri tööjaamaga on loodud nende praktiliste probleemide lahendamiseks. Mudel pakub välja sammud ja käsud; platvorm käivitab need isoleeritud keskkonnas, kus on sisendite ja väljundite jaoks failisüsteem, valikuline struktureeritud salvestusruum (nt SQLite) ja piiratud võrgu juurdepääs. 

Selles postituses räägime, kuidas me ehitasime agentide jaoks arvutikeskkonna, ja jagame mõningaid varaseid õppetunde selle kasutamise kohta, et tootmistöövood oleksid kiiremad, lihtsamini korratavad ja turvalisemad.

Hea agendi töövoog algab tiheda täitmistsükliga: mudel pakub välja toimingu, näiteks failide lugemise või andmete toomise API abil, platvorm käivitab selle ja tulemus suunatakse järgmisse sammu. Alustame shell-tööriistast—see on lihtsaim viis näha seda tsüklit toimimas—ja seejärel käsitleme konteineri tööjaama, võrgundust, korduvkasutatavaid oskusi ja konteksti tihendamist.

Shell-tööriista mõistmiseks on esmalt kasulik mõista, kuidas keelemudel kasutab tööriistu üldiselt: näiteks funktsiooni kutsumiseks või arvutiga suhtlemiseks. Treeningu ajal näidatakse mudelile samm-sammult näiteid selle kohta, kuidas tööriistu kasutatakse ja millised on sellest tulenevad mõjud. See aitab mudelil õppida otsustama, millal tööriista kasutada ja kuidas seda kasutada. Kui me ütleme „tööriista kasutamine“, peame silmas, et mudel tegelikult ainult pakub välja tööriistakutse. See ei saa kõnet omaette käivitada.

Shell-tööriist muudab mudeli märkimisväärselt võimekamaks: see suhtleb arvutiga käsurea kaudu, et täita laia valikut ülesandeid, alates teksti otsimisest kuni teie arvutist API-päringute saatmiseni. Tuginedes tuttavatele Unixi tööriistadele, suudab meie shell-tööriist teha kõike, mida ootad, ning utiliidid nagu grep, curl ja awk on kohe karbist võttes saadaval.

Võrreldes meie olemasoleva koodi tõlgendajaga, mis käivitab ainult Pythoni, võimaldab shell-tööriist palju laiemat kasutusjuhtude valikut, näiteks Go või Java programmide käivitamist või NodeJS-serveri käivitamist. See paindlikkus võimaldab mudelil täita keerukaid agentlikke ülesandeid.

Üksi võttes saab mudel ainult shell-käsklusi välja pakkuda, aga kuidas neid käsklusi täidetakse? Meil on vaja orkestreerijat, et saada mudeli väljund, kutsuda tööriistu ja edastada tsüklis tööriista vastus uuesti mudelile, kuni ülesanne on lõpule viidud.

Responses API on viis, kuidas arendajad OpenAI mudelitega suhtlevad. Kui seda kasutatakse kohandatud tööriistadega, loovutab Responses API juhtimise tagasi kliendile ning klient vajab tööriistade käitamiseks oma raamistiku. Kuid see API saab ka otse karbist võetuna orkestreerida mudeli ja hostitud tööriistade vahel. 

Kui Responses API saab viiba, koostab see mudeli konteksti: kasutaja viip, varasema vestluse olek ja tööriistajuhised. Selleks et shelli täitmine toimiks, peab viip mainima shell-tööriista kasutamist ja valitud mudel peab olema treenitud shell-käsklusi välja pakkuma—selleks on treenitud mudelid GPT‑5.2 ja uuemad. Kogu selle konteksti põhjal otsustab mudel seejärel järgmise toimingu. Kui see valib shelli täitmise, tagastab see Responses API teenusele ühe või mitu shell-käsklust. API-teenus edastab need käsud konteineri käitusajale, voogedastab tagasi shelli väljundi ja lisab selle järgmise päringu konteksti mudelile. Seejärel saab mudel tulemusi kontrollida, anda järelkäske või koostada lõpliku vastuse. Responses API kordab seda tsüklit, kuni mudel tagastab lõpetuse ilma täiendavate shell-käskudeta.

Kui Responses API täidab shell-käsu, säilitab see voogedastusühenduse konteineriteenusega. Väljundi loomise käigus edastab API selle peaaegu reaalajas mudelile, et mudel saaks otsustada, kas oodata rohkem väljundit, käivitada veel üks käsk või liikuda edasi lõpliku vastuse juurde.

Mudel saab ühes etapis pakkuda välja mitu shell-käsku ja Responses API saab need samaaegselt täita, kasutades eraldi konteineriseansse. Iga seanss voogedastab väljundi iseseisvalt ja API multipleksib need vood tagasi struktureeritud tööriista väljunditeks kontekstina. Teisisõnu saab agendi ahel tööd paralleelselt teha, näiteks faile otsida, andmeid tuua ja vahetulemusi valideerida.

Kui käsklus hõlmab failitoiminguid või andmetöötlust, võib shelli väljund muutuda väga suureks ja kulutada kontekstieelarveid, lisamata kasulikke signaale. Selle kontrollimiseks määrab mudel käsu kohta väljundi ülempiiri. Responses API jõustab selle ülempiiri ja tagastab piiratud tulemi, mis säilitab nii väljundi alguse kui ka lõpu, märkides samal ajal ära väljajäetud sisu. Näiteks võid piirata väljundi 1000 tähemärgiga, säilitades alguse ja lõpu:

tekst alguses ... 1000 märki kärbitud ... tekst lõpus

Koos muudavad samaaegne täitmine ja piiratud väljund agendi tsükli nii kiireks ja kontekstitõhusaks, et mudel saab jätkata arutlust asjakohaste tulemuste üle, selle asemel, et olla toorterminali logidest üle koormatud.

Üks võimalik probleem agendi tsüklitega on see, et ülesanded võivad kesta kaua. Pikad ülesanded täidavad konteksti akna, mis on oluline konteksti pakkumiseks voorude ja agentide vahel. Kujuta ette agenti, kes kutsub oskuse, saab vastuse, lisab tööriistakutseid ja arutluse kokkuvõtteid—piiratud konteksti aken täitub ruttu. Vältimaks olulise konteksti kaotamist, kui agent töötab edasi, on vaja viisi, kuidas hoida põhiandmed ja eemaldada üleliigne. Selle asemel, et arendajad peaksid looma ja hooldama kohandatud kokkuvõtte- või olekusüsteeme, lisasime Responses API-sse natiivse kompaktimise, mis sobib mudeli käitumise ja koolitusega.

Meie uusimad mudelid on treenitud analüüsima varasemat vestluse olekut ja looma tihendusüksuse, mis säilitab varasema oleku põhielemendid krüptitud, token-tõhusas esituses. Pärast kokkusurumist koosneb järgmine kontekstiaken sellest kokkusurumisüksusest ja varasema akna suure väärtusega osadest. See võimaldab töövoogudel jätkuda sidusalt üle aknapiiride, isegi pikendatud mitmeastmelistes ja tööriistapõhistes seanssides. Codex tugineb sellele mehhanismile, et toetada pikaajalisi kodeerimisülesandeid ja iteratiivset tööriistade käitamist ilma kvaliteeti halvendamata.

Kompaktimine on saadaval kas serverisse sisseehitatuna või eraldiseisva `/compact` lõpp-punkti kaudu. Serveripoolne kompaktimine võimaldab teil seadistada lävendi ning süsteem haldab kompaktimise ajastust automaatselt, välistades vajaduse keeruka kliendipoolse loogika järele. See võimaldab veidi suuremat efektiivset sisendkontekstiakent, et taluda väikseid ületamisi vahetult enne tihendamist, nii et piirile lähedal olevad päringud saab siiski töödelda ja tihendada, mitte tagasi lükata. Kuna mudelite treenimine areneb, areneb koos sellega ka natiivne kompaktimislahendus iga OpenAI mudeli väljalaske puhul.

Codex aitas meil ehitada tihendussüsteemi, olles samal ajal selle varajane kasutaja. Kui üks Codexi eksemplar sattus tihendamise vea otsa, käivitasime uurimiseks teise eksemplari. Tulemuseks oli see, et Codex sai natiivse ja tõhusa tihendussüsteemi lihtsalt probleemi kallal töötades. See Codexi võime end uurida ja täiustada on muutunud eriti huvitavaks osaks OpenAI-s töötamisest. Enamik tööriistu nõuab kasutajalt vaid seda, et ta õpiks neid kasutama; Codex õpib koos meiega.

Nüüd vaatame olekut ja ressursse. Konteiner ei ole ainult koht käskude käivitamiseks, vaid ka mudeli töökontekst. Konteineri sees saab mudel lugeda faile, teha andmebaasipäringuid ja pääseda ligi välistele süsteemidele võrgupoliitika kontrollide alusel.

Konteineri konteksti esimene osa on failisüsteem ressursside üleslaadimiseks, korraldamiseks ja haldamiseks. Lõime konteineri ja faili⁠(avaneb uues aknas) API-d, et anda mudelile kaart saadaolevatest andmetest ja aidata tal valida sihitud failitoiminguid, selle asemel et teha laiaulatuslikke, mürarikkaid skaneerimisi.

Levinud antimuster on kogu sisendi pakkimine otse viip konteksti. Kui sisendid kasvavad, muutub viip ületäitmine kulukaks ja mudelil on selles raske orienteeruda. Parem muster on ressursid konteineri failisüsteemis ette valmistada ja lasta mudelil otsustada, mida shell-käsklustega avada, parsida või teisendada. Nagu inimesed, töötavad mudelid paremini korrastatud teabega.

Konteksti teine osa on andmebaasid. Paljudel juhtudel soovitame arendajatel salvestada struktureeritud andmeid andmebaasidesse SQLite’ina ja teha nende kohta päringuid. Selle asemel, et kopeerida kogu arvutustabel viipa, võid näiteks anda mudelile tabelite kirjelduse—millised veerud on olemas ja mida need tähendavad—ning lasta tal ise hankida vajalikud read.

Näiteks kui küsid: „Milliste toodete müük sel kvartalil langes?”, saab mudel pärida just asjakohased read, selle asemel et skannida kogu arvutustabelit. See on kiirem, odavam ja skaleeritavam suurematele andmekogumitele.

Konteineri konteksti kolmas osa on võrgu juurdepääs, mis on agendi töökoormuse vaatest oluline osa. Agendi töövoog võib vajada reaalajas andmete toomist, väliste API-de kutsumist või pakettide installimist. Samas võib konteineritele piiramatu internetiühenduse andmine olla riskantne: see võib paljastada teavet välistele veebisaitidele, tahtmatult puudutada tundlikke sisemisi või kolmandate poolte süsteeme.

Nende murede lahendamiseks ilma agentide kasulikkust piiramata ehitasime hostitud konteinerid, et kasutada sidecar’i väljuva liikluse puhverserverit. Kõik väljaminevad võrgupäringud liiguvad läbi tsentraliseeritud poliitikakihi, mis rakendab lubatud loendeid ja juurdepääsukontrolle, hoides samal ajal liikluse jälgitavana. Mandaatide jaoks kasutame väljumisel domeenipõhist saladuse injekteerimist. Mudel ja konteiner näevad ainult kohatäitjaid, samas kui toored salajased väärtused jäävad mudelile nähtavast kontekstist välja ja neid rakendatakse ainult heakskiidetud sihtkohtade jaoks. See vähendab lekke riski, võimaldades samal ajal autentitud väliseid päringuid.

Shell-käsud on võimsad, kuid paljud ülesanded kordavad samu mitmeastmelisi mustreid. Agendid peavad igal käivitamisel töövoo uuesti avastama—ümber planeerima, käske uuesti väljastama ja uuesti õppima tavasid—see viib ebaühtlaste tulemusteni ja raisatud täitmiseni. Agendi oskused⁠(avaneb uues aknas) koondavad need mustrid korduvkasutatavateks, kombineeritavateks ehitusplokkideks. Konkreetselt on oskus kaustapakett, mis sisaldab ‘SKILL.md⁠(avaneb uues aknas)’-d (see sisaldab metaandmeid ja juhiseid) ning kõiki toetavaid ressursse, näiteks API spetsifikatsioonid ja kasutajaliidese varad.

See struktuur kaardistub loomulikult käitusaja arhitektuurile, mida me varem kirjeldasime. Konteiner pakub püsifaile ja käivituskonteksti ning shell-tööriist pakub käivitusliidest. Kui mõlemad on olemas, saab mudel vajaduse korral avastada oskuste faile shell-käskluste (`ls`, `cat`, etc.) abil, tõlgendada juhiseid ja käivitada oskuste skripte — kõik samas agendi tsüklis.

Pakume API-sid⁠(avaneb uues aknas) oskuste haldamiseks OpenAI platvormil. Arendajad laadivad oskuste kaustad üles ja salvestavad need versioonitud pakettidena, mida saab hiljem oskuse ID järgi kätte saada. Enne viiba saatmist mudelile laadib Responses API oskuse ja lisab selle mudeli konteksti. See järjestus on deterministlik:

1. Hangi oskuse metaandmed, sealhulgas nimi ja kirjeldus.
2. Hangi oskuste pakett, kopeeri see konteinerisse ja paki see lahti.
3. Värskendage mudeli konteksti oskuse metaandmete ja konteineri teega.

Kui otsustatakse, kas oskus on asjakohane, uurib mudel järk-järgult selle juhiseid ja täidab selle skripte konteineris shell-käskluste kaudu.

Kõik osad kokku pannes: Responses API pakub orkestreerimist, shell-tööriist pakub käivitatavaid toiminguid, majutatud konteiner pakub püsivat käitusaja konteksti, skills kihistab korduvkasutatava töövoo loogika ning kompakteerimine võimaldab agendil töötada pikka aega vajaliku kontekstiga.

Nende primitiivide abil saab üks viip laieneda algusest lõpuni töövooguks: leida õige oskus, tuua andmed, teisendada need kohalikuks struktureeritud olekuks, teha sellele tõhusalt päringuid ja luua püsivaid artefakte. 

Allolev diagramm näitab, kuidas see süsteem töötab arvutustabeli loomiseks reaalajas andmetest.

Põhjaliku näite saamiseks shell-tööriista ja arvutikeskkonna otsast lõpuni töövoogude jaoks kombineerimise kohta vaata meie arendajablogi postitust⁠(avaneb uues aknas) ja kokaraamatut⁠(avaneb uues aknas), mis juhendavad oskuse pakendamist ja selle käivitamist Responses API kaudu.

Meil on põnev näha, mida arendajad selle primitiivide komplektiga loovad. Keelemudelid on mõeldud tegema enamat kui teksti, piltide ja heli genereerimine–jätkame oma platvormi arendamist, et see muutuks võimekamaks keerukate, päriselu ülesannete käsitlemisel mastaabis.