Fra modell til agent: Utstyre Responses API med et datamaskinmiljø

Vi er for tiden i et skifte fra å bruke modell, som utmerker seg i bestemte oppgaver, til å bruke agenter som kan håndtere komplekse arbeidsflyter. Ved å gi modell instruksjoner kan du bare få tilgang til trent intelligens. Men ved å gi modellen et datamiljø kan man oppnå et mye bredere spekter av bruksområder, som å kjøre tjenester, be om data fra API-er eller generere mer nyttige artefakter som regneark eller rapporter.

Noen praktiske problemer dukker opp når du prøver å bygge agenter: hvor du skal legge mellomliggende filer, hvordan du unngår å lime inn store tabeller i en prompt, hvordan du gir arbeidsflyten nettverkstilgang uten å skape et sikkerhetsmareritt, og hvordan du håndterer tidsavbrudd og nye forsøk uten å bygge et arbeidsflytsystem selv.

I stedet for å legge ansvaret på utviklere for å bygge sine egne utførelsesmiljøer, bygde vi de nødvendige komponentene for å utstyre Responses API⁠(åpnes i et nytt vindu) med et datamaskinmiljø for pålitelig å utføre oppgaver fra den virkelige verden.

OpenAI Responses API, sammen med skallverktøyet og et driftet container-arbeidsområde, er utformet for å løse disse praktiske problemene. Modellen foreslår trinn og kommandoer; plattformen kjører dem i et isolert miljø med et filsystem for inndata og utdata, valgfri strukturert lagring (som SQLite) og begrenset nettverkstilgang. 

I dette innlegget skal vi bryte ned hvordan vi bygde et datamiljø for agenter og dele noen tidlige lærdommer om hvordan du kan bruke det til raskere, mer repeterbare og tryggere arbeidsflyter i produksjon.

En god agentarbeidsflyt starter med en stram utførelsesløkke: modellen foreslår en handling som å lese filer eller hente data med API, plattformen kjører den, og resultatet mates inn i neste trinn. Vi starter med skallverktøyet—den enkleste måten å se denne løkken i aksjon på—og dekker deretter arbeidsområdet for beholderen, nettverk, gjenbrukbare ferdigheter og kontekstkomprimering.

For å forstå skallverktøyet er det først nyttig å forstå hvordan en språkmodell bruker verktøy generelt: til å gjøre ting som å kalle en funksjon eller samhandle med en datamaskin. Under opplæring blir en modell vist eksempler på hvordan verktøy brukes og de resulterende effektene, trinn for trinn. Dette hjelper en modell med å lære å avgjøre når den skal bruke et verktøy og hvordan den skal bruke det. Når vi sier «å bruke et verktøy», mener vi at modellen faktisk bare foreslår et verktøykall. Den kan ikke utføre kallet på egen hånd.

Skallverktøyet gjør modellen dramatisk mye kraftigere: det samhandler med en datamaskin gjennom kommandolinjen for å utføre et bredt spekter av oppgaver, fra å søke etter tekst til å sende API-forespørsler på datamaskinen din. Bygget på velkjente Unix-verktøy kan skallverktøyet vårt gjøre alt du forventer, med verktøy som grep, curl og awk tilgjengelig innebygd.

Sammenlignet med vår eksisterende kodetolker, som bare kjører Python, muliggjør shell-verktøyet et mye bredere spekter av bruksområder, som å kjøre Go- eller Java-programmer eller starte en NodeJS-server. Denne fleksibiliteten lar modellen utføre komplekse agentoppgaver.

På egen hånd kan en modell bare foreslå skallkommandoer, men hvordan blir disse kommandoene utført? Vi trenger en orkestrator for å hente modellutdata, kalle verktøy og sende verktøysvaret tilbake til modellen i en løkke, til oppgaven er fullført.

Responses API er slik utviklere samhandler med OpenAI-modell. Når den brukes med egendefinerte verktøy, gir Responses API kontrollen tilbake til klienten, og klienten krever sin egen sele for å kjøre verktøyene. Denne API-en kan imidlertid også orkestrere mellom modell og hostede verktøy rett ut av boksen. 

Når Responses API-en mottar en prompt, setter den sammen modellkontekst: brukerprompt, tidligere samtaletilstand og verktøyinstruksjoner. For at skallkjøring skal fungere, må prompten nevne bruk av skallverktøyet and den valgte modellen må være trent til å foreslå skallkommandoer—modellene GPT‑5.2 og senere er trent for dette. Med all denne konteksten bestemmer modell deretter den neste handlingen. Hvis den velger skallkjøring, returnerer den én eller flere skallkommandoer til Responses API-tjenesten. API-en videresender disse kommandoene til beholderkjøretiden, strømmer tilbake skallutdata og mater dem til modellen i konteksten for neste forespørsel. Modellen kan deretter inspisere resultatene, gi oppfølgingskommandoer eller produsere et endelig svar. Responses API gjentar denne sløyfen til modellen returnerer en completion uten flere shell commands.

Når Responses API kjører en skallkommando, opprettholder den en strømmet tilkobling til containertjenesten. Etter hvert som utdata produseres, videresender API-et dem til modellen i nesten sanntid slik at modellen kan avgjøre om den skal vente på mer utdata, kjøre en annen kommando eller gå videre til et endelig svar.

Modell kan foreslå flere skallkommandoer i ett trinn, og Responses API kan kjøre dem samtidig ved å bruke separate containersesjoner. Hver økt strømmer utdata uavhengig, og API-et multiplekser disse strømmene tilbake til strukturerte verktøyutdata som kontekst. Med andre ord kan agent-loopen parallellisere arbeid, som å søke i filer, hente data og validere mellomliggende resultater.

Når kommandoen innebærer filoperasjoner eller databehandling, kan skallutdata bli svært store og bruke opp kontekstbudsjetter uten å tilføre nyttige signaler. For å kontrollere dette spesifiserer modell en utdatagrense per kommando. Responses API håndhever denne grensen og returnerer et avgrenset resultat som bevarer både begynnelsen og slutten av utdataene, samtidig som utelatt innhold markeres. For eksempel kan du begrense utdataene til 1,000 tegn, med bevart begynnelse og slutt:

tekst i begynnelsen ... 1000 tegn avkortet ... tekst på slutten

Sammen gjør samtidig kjøring og avgrenset utdata agentsløyfen både rask og konteksteffektiv, slik at modellen kan fortsette resonnement over relevante resultater i stedet for å bli overveldet av rå terminallogger.

Et potensielt problem med agent-løkker er at oppgaver kan kjøre i lang tid. Langvarige oppgaver fyller kontekstvinduet, noe som er viktig for å gi kontekst på tvers av omganger og på tvers av agenter. Se for deg en agent som kaller en ferdighet, får et svar, legger til verktøykall og resonnering—det begrensede kontekstvinduet fylles raskt opp. For å unngå å miste den viktige konteksten mens agent fortsetter å kjøre, trenger vi en måte å beholde nøkkeldetaljene og fjerne alt overflødig. I stedet for å kreve at utviklere designer og vedlikeholder tilpassede oppsummerings- eller tilstandsbærende systemer, la vi til innebygd komprimering i Responses API, utformet for å samsvare med hvordan modellen oppfører seg og hvordan den er trent.

Våre nyeste modeller er trent til å analysere tidligere samtaletilstand og produsere et komprimeringselement som bevarer viktig tidligere tilstand i en kryptert token-effektiv representasjon. Etter komprimering består det neste kontekstvinduet av dette komprimeringselementet og deler med høy verdi fra det tidligere vinduet. Dette gjør at arbeidsflyter kan fortsette sammenhengende på tvers av vindusgrenser, selv i utvidede flertrinns og verktøydrevne økter. Codex er avhengig av denne mekanismen for å opprettholde langvarige kodeoppgaver og iterativ verktøykjøring uten at kvaliteten forringes.

Komprimering er tilgjengelig enten innebygd på serveren eller via et frittstående `/compact`-endepunkt. Komprimering på serversiden lar deg konfigurere en terskel, og systemet håndterer tidspunktet for komprimering automatisk, noe som eliminerer behovet for kompleks logikk på klientsiden. Det gir et litt større effektivt inndatakontekstvindu for å tåle små overskridelser rett før komprimering, slik at forespørsler nær grensen fortsatt kan behandles og komprimeres i stedet for å bli avvist. Etter hvert som modellopplæringen utvikler seg, utvikler den innebygde komprimeringsløsningen seg sammen med den for hver OpenAI-modellutgivelse.

Codex hjalp oss med å bygge komprimeringssystemet samtidig som det fungerte som en tidlig bruker av det. Når én Codex-forekomst traff på en komprimeringsfeil, startet vi opp en andre forekomst for å undersøke. Resultatet var at Codex fikk et innebygd, effektivt komprimeringssystem bare ved å jobbe med problemet. Denne evnen Codex har til å inspisere og forbedre seg selv har blitt en spesielt interessant del av det å jobbe hos OpenAI. De fleste verktøy krever bare at brukeren lærer å bruke dem; Codex lærer sammen med oss.

Nå skal vi dekke tilstand og ressurser. Containeren er ikke bare et sted å kjøre kommandoer, men også arbeidskonteksten for modellen. Inne i containeren kan modellen lese filer, kjøre spørringer mot databaser og få tilgang til eksterne systemer under nettverkspolicykontroller.

Den første delen av beholderkonteksten er filsystemet for filopplasting, organisering og administrasjon av ressurser. Vi bygde container- og fil⁠(åpnes i et nytt vindu) -API-er for å gi modellen et kart over tilgjengelige data og hjelpe den med å velge målrettede filoperasjoner i stedet for å utføre brede, støyende skanninger.

Et vanlig anti-mønster er å pakke alle inndata direkte inn i prompt-konteksten. Etter hvert som inndataene vokser, blir det dyrt å overfylle prompt og vanskelig for modellen å navigere. Et bedre mønster er å klargjøre ressurser i beholderens filsystem og la modellen bestemme hva som skal åpnes, parses eller transformeres med skallkommandoer. Akkurat som mennesker fungerer modell bedre med organisert informasjon.

Den andre delen av containerkonteksten er databaser. I mange tilfeller foreslår vi at utviklere lagrer strukturerte data i databaser som SQLite og spør dem. I stedet for å kopiere et helt regneark inn i prompten, for eksempel, kan du gi modellen en beskrivelse av tabellene—hvilke kolonner som finnes og hva de betyr—og la den hente radene den trenger.

For eksempel, hvis du spør: «Hvilke produkter hadde fallende salg dette kvartalet?», kan modellen spørre just de relevante radene i stedet for å skanne hele regnearket. Dette er raskere, billigere og mer skalerbart for større datasett.

Den tredje delen av containerkonteksten er nettverkstilgang, en viktig del av agentarbeidsbelastninger. Agentens arbeidsflyt kan måtte hente sanntidsdata, kalle eksterne API-er eller installere pakker. Samtidig kan det være risikabelt å gi containere ubegrenset internettilgang: det kan eksponere informasjon for eksterne nettsteder, utilsiktet berøre sensitive interne eller tredjepartssystemer, eller gjøre det vanskeligere å beskytte mot lekkasje av legitimasjon og dataeksfiltrering.

For å håndtere disse bekymringene uten å begrense agentenes nytte, bygde vi hostede containere for å bruke en sidecar egress proxy. Alle utgående nettverksforespørsler går gjennom et sentralisert lag for retningslinjer som håndhever tillatelseslister og tilgangskontroller, samtidig som trafikken forblir observerbar. For legitimasjon bruker vi domeneavgrenset hemmelighetsinjeksjon ved egress. Modellen og containeren ser bare plassholdere, mens rå hemmelige verdier forblir utenfor modellens synlige kontekst og bare blir brukt for godkjente destinasjoner. Dette reduserer risikoen for lekkasje samtidig som det fortsatt muliggjør autentiserte eksterne kall.

Skallkommandoer er kraftige, men mange oppgaver gjentar de samme flertrinnsmønstrene. Agenter må gjenoppdage arbeidsflyten hver gang—planlegge på nytt, utstede kommandoer på nytt og lære konvensjoner på nytt—noe som fører til inkonsekvente resultater og bortkastet utførelse. Agentferdigheter⁠(åpnes i et nytt vindu) pakker disse mønstrene inn i gjenbrukbare, sammensettbare byggeklosser. Konkret er en ferdighet en mappepakke som inkluderer ‘SKILL.md⁠(åpnes i et nytt vindu)’ (inneholder metadata og instruksjoner) pluss eventuelle støtteressurser, som API-spesifikasjoner og UI-ressurser.

Denne strukturen samsvarer naturlig med kjøremiljøarkitekturen vi beskrev tidligere. Beholderen tilbyr vedvarende filer og utførelseskontekst, og skallverktøyet tilbyr utførelsesgrensesnittet. Med begge på plass kan modellen oppdage ferdighetsfiler ved hjelp av skallkommandoer (`ls`, `cat`, etc.) når den trenger det, tolke instruksjoner og kjøre ferdighetsskript – alt i den samme agent-løkken.

Vi tilbyr API-er⁠(åpnes i et nytt vindu) for å administrere ferdigheter på OpenAI-plattformen. Utviklere laster opp og lagrer ferdighetsmapper som versjonerte pakker, som senere kan hentes ved hjelp av ferdighets-ID. Før prompten sendes til modellen, laster Responses API-en inn ferdigheten og inkluderer den i modellkonteksten. Denne sekvensen er deterministisk:

1. Hent ferdighetsmetadata, inkludert navn og beskrivelse.
2. Hent ferdighetspakken, kopier den inn i beholderen, og pakk den ut.
3. Oppdater modellkonteksten med ferdighetsmetadata og containerbanen.

Når den avgjør om en ferdighet er relevant, utforsker modellen instruksjonene sine gradvis og kjører skriptene sine gjennom skallkommandoer i containeren.

For å sette alle brikkene sammen: Responses API gir orkestrering, shell tool leverer kjørbare handlinger, hosted container sørger for vedvarende kjøretidskontekst, skills legger et lag med gjenbrukbar arbeidsflytlogikk, og compaction gjør det mulig for en agent å kjøre lenge med nødvendig kontekst.

Med disse primitivene kan en enkelt prompt utvides til en ende-til-ende-arbeidsflyt: finne riktig ferdighet, hente data, transformere dem til lokal strukturert tilstand, spørre dem effektivt og generere varige artefakter. 

Diagrammet nedenfor viser hvordan dette systemet fungerer for å opprette et regneark fra sanntidsdata.

For et inngående eksempel på å kombinere skallverktøyet og datamiljøet for ende-til-ende-arbeidsflyter, se utviklerblogginnlegget⁠(åpnes i et nytt vindu) og cookbook⁠(åpnes i et nytt vindu) som går gjennom pakking av en skill og kjøring av den gjennom Responses API.

Vi gleder oss til å se hva utviklere bygger med dette settet med primitive elementer. Språkmodeller er ment å gjøre mer enn å generere tekst, bilder og lyd–vi vil fortsette å utvikle plattformen vår for å bli mer kapabel til å håndtere komplekse oppgaver i den virkelige verden i stor skala.