No modeļa līdz aģentam: datora vides nodrošināšana Responses API

Pašlaik mēs pārejam no modeļu izmantošanas, kas izceļas konkrētu uzdevumu veikšanā, uz aģentu izmantošanu, kas spēj pārvaldīt sarežģītas darbplūsmas. Uzvedinot modeļus, tu vari piekļūt tikai apmācītam intelektam. Tomēr, nodrošinot modelim datora vidi, var panākt daudz plašāku lietošanas gadījumu klāstu, piemēram, pakalpojumu darbināšanu, datu pieprasīšanu no API vai noderīgāku artefaktu, piemēram, izklājlapu vai pārskatu, ģenerēšanu.

Dažas praktiskas problēmas rodas, kad mēģini veidot aģentus: kur glabāt starpfailus, kā izvairīties no lielu tabulu ielīmēšanas uzvednē, kā piešķirt darbplūsmai piekļuvi tīklam, neradot drošības problēmas, un kā apstrādāt noildzes un atkārtotus mēģinājumus, neizveidojot darbplūsmu sistēmu pašam.

Tā vietā, lai uzliktu izstrādātājiem pienākumu veidot savas izpildvides, mēs izveidojām nepieciešamos komponentus, lai nodrošinātu Responses API⁠(atveras jaunā logā) ar datora vidi, kas ļauj uzticami izpildīt reālās pasaules uzdevumus.

OpenAI Responses API kopā ar čaulas rīku un mitinātu konteineru darbvietu ir izstrādāta, lai risinātu šīs praktiskās problēmas. Modelis piedāvā soļus un komandas; platforma tās izpilda izolētā vidē ar failu sistēmu ievadēm un izvadēm, strukturētu krātuvi pēc izvēles (piemēram, SQLite) un ierobežotu tīkla piekļuvi. 

Šajā ierakstā izskaidrosim, kā mēs izveidojām aģentiem paredzētu datora vidi, un dalīsimies ar dažām agrīnām mācībām par to, kā to izmantot ātrākām, atkārtojamākām un drošākām ražošanas darbplūsmām.

Laba aģenta darbplūsma sākas ar ciešu izpildes ciklu: modelis ierosina darbību, piemēram, failu lasīšanu vai datu iegūšanu ar API, platforma to izpilda, un rezultāts tiek ievadīts nākamajā solī. Sāksim ar čaulas rīku – vienkāršāko veidu, kā redzēt šo ciklu darbībā –, un pēc tam aplūkosim konteinera darbvietu, tīklošanu, atkārtoti izmantojamas prasmes un konteksta sablīvēšanu.

Lai saprastu čaulas rīku, vispirms ir noderīgi saprast, kā valodas modelis kopumā izmanto rīkus, lai veiktu tādas darbība kā funkcijas izsaukšanu vai mijiedarbošanos ar datoru. Apmācības laikā modelim soli pa solim tiek parādīti piemēri, kā tiek izmantoti rīki un kādi ir to rezultātā iegūtie efekti. Tas palīdz modelim iemācīties izlemt, kad un kā izmantot rīku. Kad sakām “rīka izmantošana”, tas nozīmē, ka modelis patiesībā tikai ierosina rīka izsaukumu. Tas nevar izpildīt izsaukumu atsevišķi.

Čaulas rīks modeli padara ievērojami jaudīgāku: tas mijiedarbojas ar datoru, izmantojot komandrindu, lai veiktu plašu uzdevumu klāstu, sākot no teksta meklēšanas līdz API pieprasījumu nosūtīšanai tavā datorā. Mūsu čaulas rīks, kas balstīts uz pazīstamiem Unix rīkiem, var paveikt visu, ko vien sagaidi, un tādas utilītprogrammas kā grep, curl un awk ir gatavas tūlītējai lietošanai.

Salīdzinot ar mūsu esošo koda interpretētāju, kas izpilda tikai Python, čaulas rīks nodrošina daudz plašāku lietošanas gadījumu klāstu, piemēram, Go vai Java programmu palaišanu vai NodeJS servera startēšanu. Šī elastība ļauj modelim izpildīt sarežģītus aģentiskus uzdevumus.

Pats modelis var piedāvāt tikai čaulas komandas, bet kā šīs komandas tiek izpildītas? Mums ir nepieciešams koordinators, lai iegūtu modeļa izvadi, izsauktu rīkus un ciklā nodotu rīka atbildi atpakaļ modelim, līdz uzdevums ir pabeigts.

Responses API ir veids, kā izstrādātāji mijiedarbojas ar OpenAI modeļiem. Izmantojot kopā ar pielāgotiem rīkiem, Responses API nodod kontroli atpakaļ klientam, un klientam ir nepieciešams savs ietvars rīku palaišanai. Tomēr šis API var organizēt mijiedarbību starp modeli un mitinātajiem rīkiem arī tūlītējai izmantošanai. 

Kad Responses API saņem uzvedni, tā apkopo modeļa kontekstu – lietotāja uzvedni, iepriekšējās sarunas stāvokli un rīku norādījumus. Lai čaulas izpilde darbotos, uzvednē ir jāpiemin čaulas rīka izmantošana un atlasītajam modelim jābūt apmācītam piedāvāt čaulas komandas – modeļi GPT‑5.2 un jaunāki tam ir apmācīti. Ņemot vērā visu kontekstu, modelis pēc tam izlemj nākamo darbību. Ja tas izvēlas čaulas izpildi, tas atgriež vienu vai vairākas čaulas komandas Responses API pakalpojumam. API pakalpojums pārsūta šīs komandas uz konteinera izpildlaiku, straumē atpakaļ čaulas izvadi un padod to modelim nākamā pieprasījuma kontekstā. Pēc tam modelis var pārbaudīt rezultātus, izdot papildu komandas vai izveidot galīgo atbildi. Responses API atkārto šo cilpu, līdz modelis atgriež pabeigumu bez papildu čaulas komandām.

Kad Responses API izpilda čaulas komandu, tā uztur straumēšanas savienojumu ar konteineru pakalpojumu. Kad tiek ģenerēta izvade, API to gandrīz reāllaikā pārsūta modelim, lai modelis varētu izlemt, vai gaidīt vēl izvadi, palaist citu komandu vai pāriet pie galīgās atbildes.

Modelis vienā solī var piedāvāt vairākas čaulas komandas, un Responses API var tās izpildīt vienlaikus, izmantojot atsevišķas konteinera sesijas. Katra sesija straumē izvadi neatkarīgi, un API multipleksē šīs straumes atpakaļ strukturētās rīku izvadēs kā kontekstu. Citiem vārdiem sakot, aģenta cikls var paralelizēt darbu, piemēram, failu meklēšanu, datu iegūšanu un starprezultātu validēšanu.

Ja komanda ietver failu darbības vai datu apstrādi, čaulas izvade var kļūt ļoti liela un patērēt konteksta budžetus, nepievienojot noderīgus signālus. Lai to kontrolētu, modelis katrai komandai nosaka izvades ierobežojumu. Responses API nodrošina šī ierobežojuma ievērošanu un atgriež ierobežotu rezultātu, kas saglabā gan izvades sākumu, gan beigas, vienlaikus atzīmējot izlaisto saturu. Piemēram, tu vari ierobežot izvadi līdz 1000 rakstzīmēm, saglabājot sākumu un beigas:

teksts sākumā ... 1000 rakstzīmes saīsinātas ... teksts beigās

Kopā vienlaicīga izpilde un ierobežota izvade padara aģenta ciklu ātru un konteksta ziņā efektīvu, lai modelis varētu turpināt spriestspēju, balstoties uz atbilstošajiem rezultātiem, nevis tiktu pārņemts ar neapstrādātiem termināļa žurnāliem.

Viena no iespējamām problēmām ar aģenta cikliem ir tā, ka uzdevumi var darboties ilgu laiku. Ilgstoši uzdevumi aizpilda konteksta logu, kas ir svarīgi, lai nodrošinātu kontekstu starp soļiem un aģentiem. Iztēlojies aģentu, kas izsauc prasmi, saņem atbildi, pievieno rīku izsaukumus un spriestspējas kopsavilkumus – ierobežotais konteksta logs ātri piepildās. Lai izvairītos no svarīgā konteksta zaudēšanas, aģentam turpinot darboties, mums ir nepieciešams veids, kā saglabāt galvenās detaļas un noņemt visu lieko. Tā vietā, lai prasītu izstrādātājiem izstrādāt un uzturēt pielāgotas kopsavilkumu veidošanas vai stāvokļa saglabāšanas sistēmas, mēs Responses API pievienojām iebūvētu sablīvēšanu, kas ir izstrādāta, lai pieskaņotos tam, kā modelis darbojas un kā tas ir apmācīts.

Mūsu jaunākie modeļi ir apmācīti analizēt iepriekšējo sarunas stāvokli un izveidot sablīvēšanas elementu, kas saglabā galveno iepriekšējo stāvokli šifrētā, tekstvienību ziņā efektīvā attēlojumā. Pēc sablīvēšanas nākamais konteksta logs sastāv no šī sablīvēšanas vienuma un agrākā loga augstvērtīgajām daļām. Tas ļauj darbplūsmām turpināt darboties saskaņoti pāri logu robežām pat paplašinātās daudzpakāpju un ar rīkiem darbinātās sesijās. Codex paļaujas uz šo mehānismu, lai uzturētu ilgstošus kodēšanas uzdevumus un iteratīvu rīku izpildi, nepasliktinot kvalitāti.

Sablīvēšana ir pieejama vai nu iebūvētā veidā serverī, vai arī izmantojot atsevišķu/kompaktu galapunktu. Servera puses sablīvēšana ļauj konfigurēt slieksni, un sistēma automātiski apstrādā sablīvēšanas laika noteikšanu, novēršot nepieciešamību pēc sarežģītas klienta puses loģikas. Tas ļauj izmantot nedaudz lielāku efektīvo ievades konteksta logu, lai tieši pirms sablīvēšanas pieļautu nelielus pārsniegumus, tāpēc pieprasījumus, kas ir tuvu ierobežojumam, joprojām var apstrādāt un sablīvēt, nevis noraidīt. Attīstoties modeļu apmācībai, attīstās arī vietējais sablīvēšanas risinājums katram OpenAI modeļa izlaidumam.

Codex palīdzēja mums izveidot sablīvēšanas sistēmu, vienlaikus kalpojot kā tās agrīns lietotājs. Kad vienai Codex instancei radās sablīvēšanas kļūda, mēs palaidām otru instanci, lai to izmeklētu. Rezultātā Codex ieguva vietēju, efektīvu blīvēšanas sistēmu, vienkārši strādājot pie šīs problēmas. Codex spēja pārbaudīt un pilnveidot sevi ir kļuvusi par īpaši interesantu darba aspektu OpenAI. Lielākajai daļai rīku lietotājam tikai jāiemācās, kā tos izmantot; Codex mācās kopā ar mums.

Tagad aplūkosim stāvokli un resursus. Konteiners ir ne tikai vieta, kur izpildīt komandas, bet arī modelim paredzētais darba konteksts. Konteinera iekšienē modelis var lasīt failus, veikt vaicājumus datubāzēm un piekļūt ārējām sistēmām saskaņā ar tīkla politikas kontrolēm.

Konteinera konteksta pirmā daļa ir failu sistēma resursu augšupielādei, organizēšanai un pārvaldībai. Mēs izveidojām konteinera un faila⁠(atveras jaunā logā) API, lai sniegtu modelim pieejamo datu karti un palīdzētu tam izvēlēties mērķtiecīgas failu darbības, nevis veikt plašas, trokšņainas skenēšanas.

Izplatīts antimodelis ir visas ievades tieša ievietošana uzvednes kontekstā. Pieaugot ievades datu apjomam, uzvednes pārpildīšana kļūst dārga un modelim ir grūti tajā orientēties. Labāks paraugs ir sagatavot resursus konteinera failu sistēmā un ļaut modelim izlemt, ko atvērt, parsēt vai pārveidot ar čaulas komandām. Līdzīgi kā cilvēki, modelis labāk darbojas ar organizētu informāciju.

Konteinera konteksta otrā daļa ir datubāzes. Daudzos gadījumos mēs izstrādātājiem iesakām strukturētus datus saglabāt datubāzēs kā SQLite un veikt vaicājumus. Tā vietā, lai, piemēram, uzvednē iekopētu visu izklājlapu, varat modelim sniegt tabulu aprakstu – kādas kolonnas pastāv un ko tās nozīmē – un ļaut tam atlasīt nepieciešamās rindas.

Piemēram, ja tu jautā: “Kuriem produktiem šajā ceturksnī samazinājās pārdošanas apjomi?”, modelis var veikt vaicājumu tikai attiecīgajās rindās, nevis skenēt visu izklājlapu. Tas ir ātrāk, lētāk un mērogojamāk lielākām datu kopām.

Konteinera konteksta trešā daļa ir tīkla piekļuve, kas ir būtiska aģentu darba slodžu daļa. Aģenta darbplūsmai var būt nepieciešams iegūt reāllaika datus, izsaukt ārējos API vai instalēt pakotnes. Vienlaikus neierobežotas interneta piekļuves piešķiršana konteineriem var būt riskanta: tā var atklāt informāciju ārējām vietnēm, netīši skart sensitīvas iekšējās vai trešo pušu sistēmas vai apgrūtināt aizsardzību pret akreditācijas datu noplūdēm un datu eksfiltrāciju.

Lai risinātu šīs bažas, neierobežojot aģentu lietderību, mēs izveidojām mitinātus konteinerus, lai izmantotu pavadošā konteinera izejošās datplūsmas starpniekserveri. Visi izejošie tīkla pieprasījumi plūst caur centralizētu politiku slāni, kas nodrošina atļautos sarakstus un piekļuves kontroli, vienlaikus saglabājot datplūsmu novērojamu. Akreditācijas datiem mēs izmantojam domēna tvēruma slepeno datu injekciju izejošā datplūsmā. Modelis un konteiners redz tikai vietturus, savukārt neapstrādātās slepeno datu vērtības paliek ārpus modelim redzamā konteksta un tiek piemērotas tikai apstiprinātiem galamērķiem. Tas samazina noplūdes risku, vienlaikus joprojām nodrošinot autentificētus ārējos izsaukumus.

Čaulas komandas ir jaudīgas, taču daudzi uzdevumi atkārto tos pašus daudzpakāpju modeļus. Aģentiem katrā izpildes reizē ir no jauna jāatklāj darbplūsma – jāpārplāno, atkārtoti jāizdod komandas un no jauna jāapgūst konvencijas –, un tas noved pie nekonsekventiem rezultātiem un nelietderīgas izpildes. Aģenta prasmes⁠(atveras jaunā logā) apvieno šos modeļus atkārtoti izmantojamos, kombinējamos veidošanas blokos. Konkrēti, prasme ir mapes komplekts, kas ietver ‘SKILL.md⁠(atveras jaunā logā)’ (satur metadatus un norādījumus), kā arī jebkādus atbalsta resursus, piemēram, API specifikācijas un UI resursus.

Šī struktūra dabiski atbilst izpildlaika arhitektūrai, kuru aprakstījām iepriekš. Konteiners nodrošina pastāvīgus failus un izpildes kontekstu, savukārt čaulas rīks nodrošina izpildes saskarni. Kad abi ir ieviesti, modelis var atklāt prasmju failus, izmantojot čaulas komandas (`ls`, `cat` utt.), kad tas ir nepieciešams, interpretēt instrukcijas un palaist prasmju skriptus – viss vienā un tajā pašā aģenta ciklā.

Mēs nodrošinām API⁠(atveras jaunā logā), lai pārvaldītu prasmes OpenAI platformā. Izstrādātāji augšupielādē un glabā prasmju mapes kā versiju pakotnes, kuras vēlāk var izgūt pēc prasmes ID. Pirms uzvednes nosūtīšanas modelim Responses API ielādē prasmi un iekļauj to modeļa kontekstā. Šī secība ir deterministiska:

1. Iegūsti prasmes metadatus, tostarp nosaukumu un aprakstu.
2. Iegūsti prasmju komplektu, iekopē to konteinerā un izpako to.
3. Atjaunini modeļa kontekstu ar prasmes metadatiem un konteinera ceļu.

Lemjot par to, vai prasme ir atbilstoša, modelis pakāpeniski izpēta tās norādījumus un izpilda tās skriptus, izmantojot čaulas komandas konteinerā.

Lai visu saliktu kopā: Responses API nodrošina organizēšanu, čaulas rīks nodrošina izpildāmas darbības, mitinātais konteiners nodrošina noturīgu izpildlaika kontekstu, prasmes slāņo atkārtoti izmantojamu darbplūsmas loģiku, un blīvēšana ļauj aģentam darboties ilgu laiku ar tam nepieciešamo kontekstu.

Izmantojot šos primitīvus, viena uzvedne var izvērsties par pilnu darbplūsmu no sākuma līdz beigām: atrodi pareizo prasmi, iegūsti datus, pārveido tos par lokālu strukturētu stāvokli, efektīvi veic tiem vaicājumus un ģenerē noturīgus artefaktus. 

Zemāk redzamā diagramma parāda, kā šī sistēma darbojas, veidojot izklājlapu no reāllaika datiem.

Lai iegūtu padziļinātu piemēru, kā apvienot čaulas rīku un datora vidi pilnām darbplūsmām, skati mūsu izstrādātāju emuāra ierakstu⁠(atveras jaunā logā) un rokasgrāmatu⁠(atveras jaunā logā), kur soli pa solim parādīts, kā sapakot prasmi un izpildīt to, izmantojot Responses API.

Mēs ar nepacietību gaidām, ko izstrādātāji radīs, izmantojot šo primitīvu kopu. Valodas modeļi ir paredzēti kam vairāk nekā tikai tekstu, attēlu un audio ģenerēšanai – mēs turpināsim attīstīt savu platformu, lai tā kļūtu spējīgāka sarežģītu reālās pasaules uzdevumu apstrādē plašā mērogā.