Nga modeli te agjenti: Pajisja e Responses API me një mjedis kompjuterik

Aktualisht jemi në një kalim nga përdorimi i model, të cilat shkëlqejnë në detyra të veçanta, te përdorimi i agjentëve të aftë për të trajtuar rrjedha pune komplekse. Duke u dhënë kërkesa modeleve, mund të kesh qasje vetëm në inteligjencën e trajnuar. Megjithatë, duke i dhënë modelit një mjedis kompjuterik mund të arrijë një gamë shumë më të gjerë rastesh përdorimi, si ekzekutimi i shërbimeve, kërkimi i të dhënave nga API-të, ose gjenerimi i artefakteve më të dobishme si spreadsheet ose raporte.

Disa probleme praktike dalin në pah kur përpiqesh të ndërtosh agjentë: ku t’i vendosësh skedarët e ndërmjetëm, si të shmangësh ngjitjen e tabelave të mëdha në një kërkesë, si t’i japësh fluksit të punës akses në rrjet pa krijuar një dhimbje koke sigurie, dhe si t’i trajtosh skadimet e kohës dhe riprovimet pa ndërtuar vetë një sistem fluksi pune.

Në vend që t'ua lëmë zhvilluesve ndërtimin e mjediseve të tyre të ekzekutimit, ne ndërtuam komponentët e nevojshëm për ta pajisur Responses API⁠(hapet në një dritare të re) me një mjedis kompjuterik për të ekzekutuar në mënyrë të besueshme detyra të botës reale.

Responses API e OpenAI, së bashku me mjetin shell dhe një hapësirë pune të hostuar në kontejner, është projektuar për të adresuar këto probleme praktike. Modeli propozon hapa dhe komanda; platforma i ekzekuton ato në një mjedis të izoluar me një sistem skedarësh për inpute dhe outpute, ruajtje të strukturuar opsionale (si SQLite) dhe akses të kufizuar në rrjet. 

Në këtë postim, do të shpjegojmë se si ndërtuam një mjedis kompjuterik për agjentët dhe do të ndajmë disa mësime të hershme se si ta përdorim atë për rrjedha pune prodhimi më të shpejta, më të përsëritshme dhe më të sigurta.

Një cikël pune i mirë i agjentit fillon me një cikël të ngushtë ekzekutimi: modeli propozon një veprim si leximi i skedarëve ose marrja e të dhënave me API, platforma e ekzekuton atë dhe rezultati ushqen hapin tjetër. Do të fillojmë me mjetin shell, mënyra më e thjeshtë për ta parë këtë cikël në veprim dhe më pas do të mbulojmë hapësirë pune, rrjetëzimin, aftësitë e ripërdorshme dhe kompaktësimin e kontekstit.

Për të kuptuar mjetin shell, fillimisht është e dobishme të kuptoni se si një model gjuhësor përdor mjetet në përgjithësi: për të kryer funksione si thirrja e një funksioni ose ndërveprimi me një kompjuter. Gjatë trajnimit, një model i tregohen shembuj se si përdoren mjetet dhe efektet që rezultojnë, hap pas hapi. Kjo e ndihmon modelin të mësojë të vendosë kur të përdorë një mjet dhe si ta përdorë atë. Kur themi “duke përdorur një mjet”, nënkuptojmë që modeli në fakt vetëm propozon një thirrje mjeti. Nuk mund ta ekzekutojë thirrjen vetë.

Mjeti shell e bën modelin dukshëm më të fuqishëm: ai ndërvepron me një kompjuter përmes linjës së komandës për të kryer një gamë të gjerë detyrash, nga kërkimi i tekstit deri te dërgimi i kërkesave API në kompjuterin tënd. I ndërtuar mbi mjetet e njohura Unix, mjeti ynë i shell mund të bëjë gjithçka që do të prisnit, me mjete si grep, curl dhe awk të disponueshme menjëherë.

Krahasuar me interpretuesin tonë ekzistues të kodit, i cili ekzekuton vetëm Python, mjeti shell mundëson një gamë shumë më të gjerë rastesh përdorimi, si ekzekutimi i programeve Go ose Java ose nisja e një serveri NodeJS. Ky fleksibilitet i lejon modelit të përmbushë detyra komplekse agjentike.

Më vete, një model mund të propozojë vetëm komandat shell, por si ekzekutohen këto komanda? Na duhet një orkestrator për të marrë daljen e modelit, për të thirrur mjetet dhe për t’ia kaluar përgjigjen e mjetit përsëri modelit në një cikël, derisa detyra të përfundojë.

API e Përgjigjeve është mënyra se si zhvilluesit ndërveprojnë me modelet e OpenAI. Kur përdoret me mjete të personalizuara, Responses API ia kthen kontrollin klientit dhe klienti kërkon harness-in e vet për ekzekutimin e mjeteve. Megjithatë, kjo API mund të orkestrojë gjithashtu midis modelit dhe mjeteve të hostuara menjëherë. 

Kur Responses API merr një kërkesë, ajo ndërton kontekstin e modelit: kërkesa e përdoruesit, gjendja e mëparshme e bisedës dhe udhëzimet e mjeteve. Që ekzekutimi i shell-it të funksionojë, kërkesa duhet të përmendë përdorimin e mjetit shell dhe modeli i përzgjedhur duhet të jetë i trajnuar për të propozuar komanda shell, modelet GPT‑5.2 dhe më vonë janë të trajnuara për këtë. Me gjithë këtë kontekst, modeli pastaj vendos veprimin e ardhshëm. Nëse zgjedh ekzekutimin e shell-it, ai kthen një ose më shumë komanda shell te shërbimi API-ja e Përgjigjeve. Shërbimi API i përcjell ato komanda te ekzekutimi i kontejnerit, transmeton mbrapsht output-in e shell-it dhe e furnizon atë te konteksti i kërkesës vijuese të modelit. Modeli mund të inspektojë rezultatet, të lëshojë komanda pasuese ose të prodhojë një përgjigje përfundimtare. Responses API e përsërit këtë cikël derisa modeli të kthejë një përfundim pa komanda shtesë shell.

Responses API ekzekuton një komandë shell, ai mban një lidhje transmetimi me shërbimin e kontejnerëve. Ndërsa prodhohet outputi, API-ja e përcjell atë te modeli pothuajse në kohë reale, në mënyrë që modeli të mund të vendosë nëse të presë për më shumë output, të ekzekutojë një komandë tjetër, ose të kalojë te një përgjigje përfundimtare.

Modeli mund të propozojë disa shell commands në një hap, dhe Responses API mund t'i ekzekutojë ato njëkohësisht duke përdorur sesione të veçanta container. Çdo sesion transmeton outputin në mënyrë të pavarur, dhe API i multiplekson këto transmetime përsëri në outpute të strukturuara të veglave si kontekst. Me fjalë të tjera, cikli i agjentit mund të paralelizojë punën, si p.sh. kërkimin e skedarëve, marrjen e të dhënave dhe vërtetimin e rezultateve të ndërmjetme.

Kur komanda përfshin operacione me skedarë ose përpunim të të dhënave, output-i i shell-it mund të bëhet shumë i madh dhe të konsumojë buxhete konteksti pa shtuar sinjale të dobishme. Për ta kontrolluar këtë, modeli specifikon një kufi daljeje për komandë. Responses API zbaton atë kufi dhe kthen një rezultat të kufizuar që ruan si fillimin ashtu edhe fundin e daljes, ndërsa shënon përmbajtjen e lënë jashtë. Për shembull, mund ta kufizosh outputin në 1,000 karaktere, me fillimin dhe fundin e ruajtur:

teksti në fillim ... 1000 chars truncated ... teksti në fund

Së bashku, ekzekutimi i njëkohshëm dhe rezultati i kufizuar e bëjnë ciklin e agjentit si të shpejtë ashtu edhe efikas për kontekstin, në mënyrë që modeli të mund të vazhdojë arsyetimin mbi rezultatet përkatëse në vend që të mbingarkohet nga regjistrat e papërpunuar të terminalit.

Një problem i mundshëm me ciklet e agjentit është se detyrat mund të ekzekutohen për një kohë të gjatë. Detyrat që zgjasin për një kohë të gjatë e mbushin dritaren e kontekstit, gjë që është e rëndësishme për të ofruar kontekst nëpër kthesa dhe nëpër agjentë. Përfytyro një agjent që thërret një aftësi, merr një përgjigje, shton thirrje mjetesh dhe përmbledhje arsyetimi, dritarja e kufizuar e kontekstit mbushet shpejt. Për të shmangur humbjen e kontekstit të rëndësishëm ndërsa agjent vazhdon të funksionojë, na duhet një mënyrë për të ruajtur detajet kyçe dhe për të hequr çdo gjë të panevojshme. Në vend që t’u kërkojmë zhvilluesve të projektojnë dhe të mirëmbajnë sisteme të personalizuara për përmbledhje ose për mbajtjen e gjendjes, shtuam kompaktim të integruar në Responses API, i projektuar për t’u përafruar me mënyrën se si sillet modeli dhe si është trajnuar.

Modelet tona më të fundit janë trajnuar për të analizuar gjendjen e bisedës së mëparshme dhe për të prodhuar një artikull kompaktimi që ruan gjendjen kryesore të mëparshme në një përfaqësim të enkriptuar efikas për token. Pas kompaktimit, dritarja e ardhshme e kontekstit përbëhet nga ky element kompaktimi dhe pjesë me vlerë të lartë të dritares së mëparshme. Kjo u mundëson flukseve të punës të vazhdojnë në mënyrë koherente përtej kufijve të dritareve, edhe në sesione të zgjatura me shumë hapa dhe të drejtuara nga mjetet. Codex mbështetet në këtë mekanizëm për të mbajtur detyra afatgjata kodimi dhe ekzekutim iterativ të mjeteve pa ulur cilësinë.

Kompaktimi është i disponueshëm ose i integruar në server ose përmes një pike fundore të pavarur `/compact`. Kompaktimi në anën e serverit ju lejon të konfiguroni një prag, dhe sistemi e menaxhon automatikisht kohën e kompaktimit, duke eliminuar nevojën për logjikë komplekse në anën e klientit. Kjo lejon një dritare pak më të madhe efektive të kontekstit të hyrjes për të toleruar tejkalime të vogla menjëherë përpara kompaktimit, në mënyrë që kërkesat pranë kufirit të mund të përpunohen dhe të kompaktohen ende, në vend që të refuzohen. Ndërsa trajnimi i modelit evoluon, zgjidhja vendase e kompaktimit evoluon bashkë me të për çdo publikim të model OpenAI.

Codex na ndihmoi të ndërtonim sistemin e kompaktimit, ndërsa shërbeu si një përdorues i hershëm i tij. Kur një instancë Codex hasi një gabim kompaktimi, do të ngrinim një instancë të dytë për të hetuar. Rezultati ishte që Codex mori një sistem kompaktimi vendas dhe efektiv thjesht duke punuar mbi problemin. Kjo aftësi e Codex për të inspektuar dhe përmirësuar veten është bërë një pjesë veçanërisht interesante e punës në OpenAI. Shumica e mjeteve kërkojnë vetëm që përdoruesi të mësojë si t’i përdorë; Codex mëson bashkë me ne.

Tani le të trajtojmë gjendjen dhe burimet. Kontejneri nuk është vetëm një vend për të ekzekutuar komanda, por edhe konteksti i punës për modelin. Brenda kontejnerit, modeli mund të lexojë skedarë, të kërkojë në bazat e të dhënave dhe të ketë qasje në sisteme të jashtme nën kontrollet e politikës së rrjetit.

Pjesa e parë e kontekstit të kontejnerit është sistemi i skedarëve për ngarkimin, organizimin dhe menaxhimin e burimeve. Ne ndërtuam API-të e kontejnerit dhe skedarit⁠(hapet në një dritare të re) për t’i dhënë model një hartë të të dhënave të disponueshme dhe për ta ndihmuar të zgjedhë operacione të synuara mbi skedarët në vend që të kryejë skanime të gjera e të zhurmshme.

Një antimodel i zakonshëm është paketimi i të gjitha të dhënave hyrëse drejtpërdrejt në kontekstin e kërkesës. Ndërsa hyrjet rriten, mbingarkimi i kërkesës bëhet i kushtueshëm dhe i vështirë për modelin për t'u naviguar. Një model më i mirë është të vendosësh burimet në sistemin e skedarëve të kontejnerit dhe t’i lejosh modelit të vendosë çfarë të hapë, të analizojë ose të transformojë me komandat shell. Ashtu si njerëzit, edhe model punon më mirë me informacion të organizuar.

Pjesa e dytë e kontekstit të kontejnerit janë bazat e të dhënave. Në shumë raste, ne u sugjerojmë zhvilluesve të ruajnë të dhëna të strukturuara në databaza si SQLite dhe t'i kërkojnë me pyetje. Në vend që të kopjoni një fletëllogaritëse të tërë në kërkesë, për shembull, mund t’i jepni modelit një përshkrim të tabelave, çfarë kolonash ekzistojnë dhe çfarë nënkuptojnë, dhe ta lini të nxjerrë rreshtat që i nevojiten.

Për shembull, nëse pyesni, “Cilat produkte patën rënie të shitjeve këtë tremujor?” modeli mund të kërkojë just rreshtat përkatës në vend që të skanojë të gjithë fletëllogaritë. Kjo është më e shpejtë, më e lirë, më e shkallëzueshme për grupe më të mëdha të dhënash.

Pjesa e tretë e kontekstit të kontejnerit është aksesi në rrjet, një pjesë thelbësore e ngarkesave të punës së agjentit. Ciklet e punës të agjentit mund të kenë nevojë të marrin të dhëna të drejtpërdrejta, të thërrasin API-të e jashtme ose të instalojnë paketa. Në të njëjtën kohë, dhënia e aksesit të pakufizuar në internet kontejnerëve mund të jetë e rrezikshme: mund të ekspozojë informacion ndaj faqeve të jashtme të internetit, të prekë pa dashje sisteme të ndjeshme të brendshme ose të palëve të treta, ose ta bëjë më të vështirë mbrojtjen kundër rrjedhjeve të kredencialeve dhe eksfiltrimit të të dhënave.

Për t’i adresuar këto shqetësime pa kufizuar dobishmërinë e agjentëve, ndërtuam kontejnerë të hostuar për të përdorur një proxy dalës i bashkëngjitur. Të gjitha kërkesat e rrjetit dalës kalojnë përmes një shtrese të centralizuar politikash që zbaton lista të lejuara dhe kontrolle të aksesit, ndërsa e mban trafikun të vëzhgueshëm. Për kredencialet, përdorim injektim të sekreteve me fushë veprimi të kufizuar në domen në dalje. Modeli dhe kontejneri shohin vetëm vendmbajtës, ndërsa vlerat e papërpunuara të sekreteve qëndrojnë jashtë kontekstit të dukshëm për model dhe aplikohen vetëm për destinacione të miratuara. Kjo redukton rrezikun e rrjedhjes, ndërkohë që ende mundëson thirrje të jashtme të autentikuara.

Komandat shell janë të fuqishme, por shumë detyra përsërisin të njëjtat modele me shumë hapa. Agjentët duhet ta rizbulojnë fluksin e punës në çdo ekzekutim, duke riplanifikuar, duke ridhënë komanda dhe duke rimësuar konventat, duke çuar në rezultate të paqëndrueshme dhe ekzekutim të shpërdoruar. Aftësitë e agjentit⁠(hapet në një dritare të re) paketojnë ato modele në blloqe ndërtimi të ripërdorshme, të kompozueshme. Konkretisht, një aftësi është një paketë dosjesh që përfshin ‘SKILL.md⁠(hapet në një dritare të re)’ (që përmban metadata dhe udhëzime) plus çdo burim mbështetës, si p.sh. specifikimet e API-së dhe asetet e UI-së.

Kjo strukturë përputhet natyrshëm me arkitekturën e ekzekutimit që përshkruam më herët. Kontejneri ofron skedarë të qëndrueshëm dhe kontekst ekzekutimi, dhe mjeti shell ofron ndërfaqen e ekzekutimit. Me të dyja në vend, modeli mund të zbulojë skedarët e aftësive duke përdorur komandat shell (`ls`, `cat`, etc.) kur i nevojitet, të interpretojë udhëzimet dhe të ekzekutojë skriptet e aftësive, të gjitha brenda të njëjtit cikël të agjent.

Ne ofrojmë APIs⁠(hapet në një dritare të re) për të menaxhuar aftësitë në platformën OpenAI. Zhvilluesit ngarkojnë dhe ruajnë dosjet e aftësive si paketa të versionuara, të cilat më vonë mund të rikuperohen sipas skill ID. Përpara se t’i dërgojë kërkesën modelit, Responses API ngarkon aftësinë dhe e përfshin atë në kontekstin e modelit. Kjo sekuencë është vendimtare:

1. Shkarko metadatat e aftësive, duke përfshirë emrin dhe përshkrimin.
2. Merrni paketën e aftësive, kopjojeni atë në kontejner dhe shpaketojeni.
3. Përditësoni kontekstin e model me metadatat e aftësive dhe shtegun e kontejnerit.

Kur vendos nëse një aftësi është relevante, model progresivisht eksploron udhëzimet e tij dhe ekzekuton skriptet e tij përmes komandave shell në container.

Për t’i bashkuar të gjitha pjesët: Responses API ofron orkestrimin, shell tool ofron veprime të ekzekutueshme, hosted container ofron kontekst të qëndrueshëm ekzekutimi, skills shtresëzon logjikë të ripërdorshme të rrjedhës së punës, dhe compaction i lejon një agjent të funksionojë për një kohë të gjatë me kontekstin që i nevojitet.

Me këto primitive, një kërkesë e vetme mund të zgjerohet në një rrjedhë pune nga fillimi në fund: të zbulojë aftësinë e duhur, të marrë të dhëna, t’i transformojë ato në gjendje të strukturuar lokale, t’i kërkojë ato në mënyrë efikase dhe të gjenerojë artefakte të qëndrueshme. 

Diagrami më poshtë tregon se si funksionon ky sistem për të krijuar një fletëllogaritëse nga të dhëna të drejtpërdrejta.

Për një shembull të thelluar të kombinimit të mjetit shell dhe mjedisit kompjuterik për flukse pune nga fundi në fund, shihni postimin tonë në blogun e zhvilluesve⁠(hapet në një dritare të re) dhe cookbook⁠(hapet në një dritare të re) që shpjegojnë paketimin e një skill dhe ekzekutimin e tij përmes Responses API.

Jemi të ngazëllyer të shohim se çfarë do të ndërtojnë zhvilluesit me këtë set primitivesh. Modeli i gjuhës është menduar të bëjë më shumë sesa të gjenerojë tekst, imazhe dhe audio, ne do të vazhdojmë të zhvillojmë platformën tonë për t’u bërë më e aftë në trajtimin e detyrave komplekse të botës reale në shkallë.