Fra model til agent: Udstyring af Responses API med et computermiljø

Vi er i øjeblikket i gang med et skifte fra at bruge model, som udmærker sig ved bestemte opgaver, til at bruge agenter, der er i stand til at håndtere komplekse arbejdsgange. Ved at prompte model kan du kun få adgang til trænet intelligens. Dog kan det at give modellen et computermiljø opnå et langt bredere udvalg af anvendelsesscenarier, som f.eks. at køre tjenester, anmode om data fra API'er eller generere mere nyttige artefakter såsom regneark eller rapporter.

Der opstår nogle praktiske problemer, når man forsøger at bygge agenter. For eksemple hvor man placerer mellemliggende filer, hvordan man undgår at indsætte store tabeller i en prompt, hvordan man giver arbejdsgangens netværk adgang uden at skabe sikkerhedsproblemer, og hvordan man håndterer timeouts og gentagne forsøg uden selv at bygge et arbejdsgangssystem.

I stedet for at lægge ansvaret på udviklerne for at bygge deres egne eksekveringsmiljøer byggede vi de nødvendige komponenter til at udstyre Responses API⁠(åbner i et nyt vindue) med et computermiljø, så den på pålidelig vis kan udføre opgaver fra den virkelige verden.

OpenAI’s Responses API, sammen med shell-værktøjet og et hostet container-arbejdsområde, er designet til at løse disse praktiske problemer. Modellen foreslår trin og kommandoer, hvorefter platformen kører dem i et isoleret miljø med et filsystem til input og output, valgfri struktureret lagring (som SQLite) og begrænset netværksadgang. 

I dette indlæg vil vi gennemgå, hvordan vi byggede et computermiljø til agenter, og dele nogle tidlige erfaringer med, hvordan man bruger det til hurtigere, mere gentagelige og mere sikre produktionsarbejdsgange.

En god agent-arbejdsgang starter med en stram eksekveringsløkke: modellen foreslår en handling som at læse filer eller hente data med API, platformen kører den, og resultatet føder ind i det næste trin. Vi starter med shell-værktøjet, som erden enkleste måde at se dette loop i aktion på, og dækker derefter container-arbejdsområdet, netværk, genanvendelige færdigheder og kontekstkomprimering.

For at forstå shell-værktøjet er det først nyttigt at forstå, hvordan en model bruger værktøjer generelt, f.eks. til at gøre ting som at kalde en funktion eller interagere med en computer. Under træningen bliver en model vist eksempler på, hvordan værktøjer bruges, og de resulterende effekter, trin for trin. Dette hjælper modellen med at lære at beslutte, hvornår den skal bruge et værktøj, og hvordan den skal bruge det. Når vi siger “at bruge et værktøj”, mener vi, at modellen faktisk kun foreslår et værktøjsopkald. Den kan ikke udføre kaldet på egen hånd.

Shell-værktøjet gør modellen betydeligt mere kraftfuld. Værktøjet interagerer med en computer via kommandolinjen for at udføre en bred vifte af opgaver, fra at søge efter tekst til at sende API-anmodninger på din computer. Vores shell-værktøj er bygget på velkendte Unix-værktøjer og kan gøre alt, hvad man ville forvente, med hjælpeprogrammer såsom grep, curl og awk tilgængelige som standard.

Sammenlignet med vores eksisterende kodefortolker, som kun eksekverer Python, muliggør shell-værktøjet et meget bredere udvalg af anvendelsestilfælde, som f.eks. at køre Go- eller Java-programmer eller starte en NodeJS-server. Denne fleksibilitet gør det muligt for modellen at udføre komplekse agentiske opgaver.

I sig selv kan en model kun foreslå shell-kommandoer, men hvordan udføres disse kommandoer? Vi har brug for en orkestrator til at få modeloutput, kalde værktøjer og sende værktøjsresponsen tilbage til modellen i et loop, indtil opgaven er fuldført.

Responses API er den måde, udviklere interagerer med OpenAI-model på. Når den bruges med brugerdefinerede værktøjer, giver Responses API’en kontrollen tilbage til klienten, og klienten kræver sin egen ramme til at køre værktøjerne. Men denne API kan også orkestrere mellem modellen og hostede værktøjer direkte fra starten. 

Når Responses API modtager en prompt, samler den model: brugerprompt, tidligere samtaletilstand og værktøjsinstruktioner. For at shell-udførelse kan fungere, skal prompten nævne brug af shell-værktøjet og den valgte model skal være trænet til at foreslå shell-kommandoer. Modeller såsom GPT‑5.2 og senere er trænet til dette. Med al denne kontekst beslutter modellen derefter den næste handling. Hvis den vælger shell-eksekvering, returnerer den en eller flere shell-kommandoer til Responses API-tjenesten. API-tjenesten videresender disse kommandoer til containerkøretiden, streamer shell-output tilbage og føder det til modellen i konteksten for den næste anmodning. Modellen kan derefter inspicere resultaterne, udstede opfølgende kommandoer eller producere et endeligt svar. Responses API'en gentager dette loop, indtil modellen returnerer en fuldførelse uden yderligere shell-kommandoer.

Når Respons-API udfører en shell-kommando, opretholder den en streamingforbindelse til container-tjenesten. Efterhånden som output produceres, videresender API'et det til modellen i næsten realtid, så modellen kan beslutte, om den vil vente på mere output, køre en anden kommando eller gå videre til et endeligt svar.

Modellen kan foreslå flere shell-kommandoer i ét trin, og Responses API kan udføre dem samtidigt ved hjælp af separate container-sessioner. Hver session streamer output uafhængigt, og API’et multiplekser disse streams tilbage til strukturerede værktøjsoutputs som kontekst. Med andre ord kan agent-loopet parallelisere arbejde, såsom at søge i filer, hente data og validere mellemliggende resultater.

Når kommandoen involverer filoperationer eller databehandling, kan shell-output blive meget stort og forbruge kontekstbudgetter uden at tilføje nyttige signaler. Modellen styrer dette ved at specificere en outputgrænse pr. kommando. Responses API'et håndhæver den grænse og returnerer et afgrænset resultat, der bevarer både begyndelsen og slutningen af outputtet, samtidig med at udeladt indhold markeres. For eksempel kan du begrænse outputtet til 1.000 tegn, med bevaret begyndelse og slutning:

tekst i begyndelsen ... 1000 tegn afkortet ... tekst i slutningen

Sammen gør samtidig udførelse og afgrænset output agentens sløjfe både hurtig og konteksteffektiv, så modellen kan fortsætte med at ræsonnering over relevante resultater i stedet for at blive overvældet af rå terminal-logfiler.

Et potentielt problem med agent loops er, at opgaver kan køre i lang tid. Langvarige opgaver fylder kontekstvinduet, hvilket er vigtigt for at give kontekst på tværs af omgange og agenter. Forestil dig en agent, der kalder en skill, får et svar, tilføjer værktøjskald og ræsonnering. Det begrænsede kontekstvindue fyldes hurtigt op. For at undgå at miste den vigtige kontekst, mens agenten fortsætter med at køre, har vi brug for en måde til at bevare de vigtigste detaljer på og fjerne alt overflødigt. I stedet for at kræve, at udviklere designer og vedligeholder brugerdefinerede opsummerings- eller tilstandsbærende systemer, tilføjede vi indbygget komprimering i Responses API, designet til at være i tråd med, hvordan modellen opfører sig, og hvordan den er blevet trænet.

Vores nyeste model er trænet til at analysere tidligere samtaletilstand og producere et komprimeringselement, der bevarer den vigtigste tidligere tilstand i en krypteret, token-effektiv repræsentation. Efter komprimering består det næste kontekstvindue af dette komprimeringselement og dele af høj værdi fra det tidligere vindue. Dette gør det muligt for arbejdsgange at fortsætte sammenhængende på tværs af vinduesgrænser, selv i udvidede sessioner med flere trin og værktøjsdrevne sessioner. Codex er afhængig af denne mekanisme for at understøtte langvarige kodningsopgaver og iterativ udførelse af værktøjer uden at forringe kvaliteten.

Komprimering er tilgængelig enten indbygget på serveren eller via et selvstændigt `/compact` endepunkt. Komprimering på serversiden gør det muligt at konfigurere en tærskel, og systemet håndterer automatisk timingen af komprimeringen, hvilket eliminerer behovet for kompleks logik på klientsiden. Det giver et lidt større effektivt inputkontekstvindue til at tolerere små overskridelser lige før komprimering, så anmodninger tæt på grænsen stadig kan behandles og komprimeres i stedet for at blive afvist. Efterhånden som modeltræningen udvikler sig, udvikler den indbyggede komprimeringsløsning sig med den for hver OpenAI-model release.

Codex hjalp os med at bygge komprimeringssystemet, samtidig med at det fungerede som en tidlig bruger af det. Når én Codex-instans ramte en komprimeringsfejl, ville vi starte en anden instans for at undersøge det. Resultatet var, at Codex fik et indbygget, effektivt komprimeringssystem blot ved at arbejde på problemet. Denne evne for Codex til at inspicere og forfine sig selv er blevet en særligt interessant del af at arbejde hos OpenAI. De fleste værktøjer kræver kun, at brugeren lærer at bruge dem; Codex lærer sammen med os.

Lad os nu gennemgå tilstand og ressourcer. Containeren er ikke kun et sted at køre kommandoer, men også arbejdskonteksten for modellen. Inde i containeren kan modellen læse filer, forespørge databaser og få adgang til eksterne systemer under netværkspolitikkontroller.

Den første del af containerkonteksten er filsystemet til at uploade, organisere og administrere ressourcer. Vi udviklede container- og fil-API’er⁠(åbner i et nyt vindue) for at give modellen et kort over tilgængelige data og hjælpe den med at vælge målrettede filhandlinger frem for at udføre brede, støjende scanninger.

Et almindeligt anti-mønster er at pakke al input direkte ind i prompt-konteksten. Når input vokser, bliver det dyrt at overfylde prompten, og det bliver svært for modellen at navigere. Et bedre mønster er at klargøre ressourcer i beholderens filsystem og lade modellen beslutte, hvad der skal åbnes, parses eller transformeres med shell-kommandoer. Ligesom mennesker fungerer model bedre med organiseret information.

Den anden del af containerkonteksten er databaser. I mange tilfælde foreslår vi, at udviklere gemmer strukturerede data i databaser som SQLite og forespørger dem. I stedet for at kopiere et helt regneark ind i prompten kan man for eksempel give modellen en beskrivelse af tabellerne såsom hvilke kolonner der findes, og hvad de betyder, og lade den hente de rækker, den har brug for.

Hvis man f.eks. spørger: “Hvilke produkter havde faldende salg i dette kvartal?” kan modellen forespørge kun de relevante rækker i stedet for at scanne hele regnearket. Dette er hurtigere, billigere, mere skalerbart til større datasæt.

Den tredje del af containerkonteksten er netværksadgang, som er en vigtig del af agentens arbejdsbyrde. Agentens arbejdsgange kan være nødt til at hente live-data, kalde eksterne API'er eller installere pakker. Samtidig kan det være risikabelt at give containere ubegrænset internetadgang: det kan eksponere information for eksterne websteder, utilsigtet berøringsfølsomme interne eller tredjepartssystemer eller gøre det sværere at beskytte sig mod lækager af legitimationsoplysninger og dataudrensning.

For at imødekomme disse bekymringer uden at begrænse agenternes anvendelighed byggede vi hostede containere til at bruge en sidecar-egress-proxy. Alle udgående netværksanmodninger går gennem et centraliseret politiklag, der håndhæver tilladelseslister og adgangskontrol, samtidig med at trafikken forbliver observerbar. Til legitimationsoplysninger bruger vi domæneafgrænset secret injection ved egress. Modellen og containeren ser kun pladsholdere, mens rå hemmelige værdier forbliver uden for modellens synlige kontekst og kun anvendes for godkendte destinationer. Dette reducerer risikoen for lækage, samtidig med at det stadig muliggør godkendte eksterne kald.

Shell-kommandoer er effektive, men mange opgaver gentager de samme mønstre i flere trin. Agenter er nødt til at genopdage arbejdsgangen ved hver kørsel såsom at omplanlægge, genudstede kommandoer og genlære konventioner, hvilket fører til inkonsistente resultater og spildt eksekvering. Agentfærdigheder⁠(åbner i et nyt vindue) pakker disse mønstre i genanvendelige, sammensættelige byggeklodser. Konkret er en skill en mappepakke, der indeholder ‘SKILL.md⁠(åbner i et nyt vindue)’ (indeholdende metadata og instruktioner) samt eventuelle understøttende ressourcer, såsom API-specifikationer og UI-aktiver.

Denne struktur passer naturligt til den runtime-arkitektur, vi beskrev tidligere. Containeren leverer vedvarende filer og en eksekveringskontekst, og shell-værktøjet leverer eksekveringsgrænsefladen. Når begge er på plads, kan modellen finde færdighedsfiler ved hjælp af shell-kommandoer (`ls`, `cat`, etc.), når den har brug for det, fortolke instruktioner og køre færdighedsscripts alt sammen i det samme agent-loop.

Vi tilbyder APIs⁠(åbner i et nyt vindue) til at administrere færdigheder på OpenAI-platformen. Udviklere uploader og gemmer færdighedsmapper som versionerede bundter, som senere kan hentes via færdigheds-id. Før prompten sendes til modellen, indlæser Responses API’en skillen og inkluderer den i modellens kontekst. Denne sekvens er deterministisk:

1. Hent metadata for skills, herunder navn og beskrivelse.
2. Hent skill-pakken, kopiér den ind i containeren, og pak den ud.
3. Opdater modelkonteksten med færdighedsmetadata og containerstien.

Når modellen beslutter, om en skill er relevant, udforsker den gradvist dens instruktioner og udfører dens scripts via shell-kommandoer i containeren.

For at samle alle delene: Responses API leverer orkestrering, shell-værktøjet leverer eksekverbare handlinger, den hostede container leverer vedvarende runtime-kontekst, genanvendelig workflow-logik i skill-laget, og komprimering giver en agent mulighed for at køre i lang tid med den kontekst, den har brug for.

Med disse primitiver kan en enkelt prompt udvides til en end-to-end-workflow: finde den rette færdighed, hente data, transformere dem til lokal struktureret tilstand, forespørge dem effektivt og generere holdbare artefakter. 

Diagrammet nedenfor viser, hvordan dette system fungerer til at oprette et regneark fra livedata.

For et dybdegående eksempel på at kombinere shell-værktøjet og computermiljøet til end-to-end-arbejdsgange henvises der til vores udviklerblogindlæg⁠(åbner i et nyt vindue) og kogebog⁠(åbner i et nyt vindue), der gennemgår pakning af en færdighed og eksekvering af den via Responses API.

Vi glæder os til at se, hvad udviklere bygger med dette sæt primitiver. Sprogmodeller er beregnet til at gøre mere end at generere tekst, billeder og lyd. Vi vil fortsat udvikle vores platform, så den bliver mere kapabel til at håndtere komplekse opgaver fra den virkelige verden i stor skala.