Från modell till agent: Utrusta Responses API med en datormiljö

Vi befinner oss för närvarande i en övergång från användning av modeller (som är väldigt bra på specifika uppgifter) till användning av agenter som kan hantera komplexa arbetsflöden. Genom att uppmana modeller kan man endast få åtkomst till tränad intelligens. Fast om modellen får en datormiljö kan den uppnå ett mycket bredare spektrum av användningsfall såsom att köra tjänster, begära data från API:er eller generera mer användbara artefakter som kalkylark eller rapporter.

Ett par praktiska problem uppstår när man försöker skapa agenter: vart man ska placera mellanliggande filer, hur kan man undviker att klistra in stora tabeller i en prompt, hur ger man arbetsflödesnätverket åtkomst utan att skapa säkerhetsproblem, och hur hanterar man timeouts och återförsök utan att skapa ett arbetsflödessystem.

I stället för att placera ansvaret på utvecklare att skapa sina egna exekveringsmiljöer byggde vi de nödvändiga komponenterna för att utrusta Responses API⁠(öppnas i ett nytt fönster) med en datormiljö för tillförlitlig exekvering av verkliga uppgifter.

OpenAI:s Responses API (tillsammans med skalverktyget och en värdbaserad arbetsyta) är utformad för att hantera dessa praktiska problem. Modellen föreslår steg och kommandon som plattformen sedan kör i en isolerad miljö med ett filsystem för indata och utdata, valfri strukturerad lagring (såsom SQLite) och begränsad nätverksåtkomst. 

I det här inlägget går vi igenom hur vi skapade en datormiljö för agenter samt delar med oss av några tidiga lärdomar om hur man använder den för snabbare, mer repeterbara och säkrare produktionsarbetsflöden.

Ett bra arbetsflöde för en agent börjar med en tajt exekveringsloop: modellen föreslår en åtgärd såsom att läsa filer eller hämta data med API, plattformen kör den, och resultatet matas in i nästa steg. Vi börjar med skalverktyget som är det enklaste sättet att se den här loopen i praktiken och går sedan igenom containerarbetsytan, nätverk, återanvändbara färdigheter och kontextkomprimering.

För att förstå skalverktyget är det användbart att först förstå hur en modell använder verktyg i allmänhet, t.ex. för att anropa en funktion eller interagera med en dator. Under träning visas en modell steg för steg exempel på hur verktyg används och vilka effekter det ger. Detta hjälper modellen att lära sig att avgöra när den ska använda ett verktyg och hur den ska använda det. När vi säger "använda ett verktyg" menar vi att modellen egentligen bara föreslår ett verktygsanrop. Den kan inte utföra anropet på egen hand.

Skalverktyget gör modellen dramatiskt mer kraftfull: det interagerar med en dator via kommandoraden för att utföra en mängd olika uppgifter, från att söka efter text till att skicka API-begäranden på din dator. Skalverktyget är byggt på välbekanta Unix-verktyg och kan göra allt man kan förvänta sig med hjälp av verktyg som grep, curl och awk tillgängliga direkt från start.

Jämfört med vår befintliga kodtolkare som endast exekverar Python möjliggör skalverktyget ett mycket bredare spektrum av användningsfall såsom att köra Go- eller Java-program, eller starta en NodeJS-server. Den här flexibiliteten låter modellen utföra komplexa agentiska uppgifter.

På egen hand kan en modell endast föreslå skalkommandon, fast hur körs dessa kommandon? Vi behöver en orkestrerare för att hämta modellens utdata, anropa verktyg och skicka verktygssvaret tillbaka till modellen i en loop tills uppgiften är slutförd.

Responses API är hur utvecklare interagerar med OpenAI-modeller. När den används med anpassade verktyg ger Responses API kontrollen tillbaka till klienten och klienten behöver sitt eget ramverk för att köra verktygen. Den här API:n kan dock även orkestrera mellan modellen och värdbaserade verktyg direkt. 

När Responses API tar emot en prompt sammanställer den modellkontext: användarprompt, tidigare konversationstillstånd och verktygsinstruktioner. För att skalexekvering ska fungera måste prompten nämna att skalverktyget ska användas och den valda modellen måste vara tränad för att föreslå skalkommandon (modeller GPT‑5.2 och senare är tränade för detta). Med all denna kontext beslutar modellen sedan om nästa åtgärd. Om den väljer skalexekvering returnerar den ett eller flera skalkommandon till Responses API-tjänsten. API-tjänsten vidarebefordrar dessa kommandon till containerkörningen, strömmar tillbaka skalutdata och matar in dem i modellens kontext för nästa begäran. Modellen kan sedan granska resultaten, utfärda uppföljningskommandon eller producera ett slutgiltigt svar. Responses API upprepar denna loop tills modellen returnerar ett slutförande utan ytterligare skalkommandon.

När Responses API kör ett skalkommando upprätthåller den en strömmande anslutning till containertjänsten. När utdata produceras vidarebefordrar API:n datan till modellen i näst intill realtid så att modellen kan avgöra om den ska vänta på mer utdata, köra ett annat kommando eller fortsätta till ett slutgiltigt svar.

Modellen kan föreslå flera skalkommandon i ett steg och Responses API kan köra dem samtidigt i separata containersessioner. Varje session strömmar utdata oberoende och API:n multiplexar dessa strömmar tillbaka till strukturerade verktygsutdata som kontext. Agent-loopen kan med andra ord parallellisera arbete, t.ex. söka i filer, hämta data och validera mellanliggande resultat.

När kommandot involverar filoperationer eller databehandling kan skalutdata bli mycket stora och förbruka kontextbudgetar utan att tillföra användbara signaler. För att kontrollera detta anger modellen ett tak för utdata per kommando. Responses API:n upprätthåller gränsen och returnerar ett avgränsat resultat som bevarar både början och slutet av utdata samtidigt som utelämnat innehåll markeras. Du kan till exempel begränsa utdata till 1 000 tecken med bevarad början och slut:

text i början ... 1000 tecken trunkerade ... text i slutet

Samtidig exekvering och begränsad utdata gör tillsammans agentens loop både snabb och kontexteffektiv så att modellen kan fortsätta sitt resonemang kring relevanta resultat istället för att bli överväldigad av råa terminalloggar.

Ett potentiellt problem med agentloopar är att uppgifter kan köras under lång tid. Långvariga uppgifter fyller kontextfönstret, vilket är viktigt för att tillhandahålla kontext under olika omgångar och agenter. Föreställ dig en agent som anropar en färdighet, får ett svar, lägger till verktygsanrop och resonemang, det begränsade kontextfönstret fylls snabbt upp. För att undvika att förlora viktig kontext när agenten fortsätter att köras behöver vi ett sätt att behålla de viktigaste detaljerna och ta bort allt som är överflödigt. Istället för att kräva att utvecklare utformar och underhåller anpassade sammanfattnings- eller tillståndsbärande system har vi lagt till inbyggd komprimering i Responses API:n utformad för att stämma överens med hur modellen beter sig och hur den tränats.

Våra senaste modeller är tränade för att analysera tidigare samtalstillstånd och skapa ett komprimeringsobjekt som bevarar viktiga tidigare tillstånd i en krypterad token-effektiv representation. Efter komprimeringen består nästa kontextfönster av detta komprimeringsobjekt och delar med högt värde från det tidigare fönstret. Detta gör att arbetsflöden kan fortsätta sammanhängande över fönstergränser, även i utökade flerstegs- och verktygsdrivna sessioner. Codex förlitar sig på den här mekanismen för att upprätthålla långvariga kodningsuppgifter och iterativ verktygsexekvering utan försämring av kvaliteten.

Komprimering är tillgänglig antingen inbyggd på servern eller via en fristående "/compact"-slutpunkt. Komprimering på serversidan låter dig konfigurera ett tröskelvärde och systemet hanterar tidpunkten för komprimering automatiskt vilket eliminerar behovet av komplicerad logik på klientsidan. Det möjliggör ett något större effektivt kontextfönster för indata för tolerans av små överskridanden precis före kompaktering så att begäranden nära gränsen fortfarande kan behandlas och komprimeras i stället för att avvisas. I takt med att modellträningen utvecklas, utvecklas även den inbyggda komprimeringslösningen med varje OpenAI-modellrelease.

Codex hjälpte oss att skapa komprimeringssystemet och var samtidigt en tidig användare av det. När en Codex-instans stötte på ett komprimeringsfel startade vi upp en andra instans för att undersöka. Resultatet blev att Codex fick ett inbyggt, effektivt komprimeringssystem genom att arbeta med problemet. Denna förmåga hos Codex att granska och förfina sig själv har blivit en väldigt intressant del av att arbeta på OpenAI. De flesta verktyg kräver endast att användaren lär sig hur man använder dem, Codex lär sig tillsammans med oss.

Låt oss nu gå igenom tillstånd och resurser. Containern är inte bara en plats för att köra kommandon utan även arbetskontexten för modellen. Inuti containern kan modellen läsa filer, fråga databaser och komma åt externa system under nätverkspolicykontroller.

Den första delen av containerkontexten är filsystemet för att ladda upp, organisera och hantera resurser. Vi skapade API:er för containrar och filer⁠(öppnas i ett nytt fönster) för att ge modellen en karta över tillgängliga data och hjälpa den att välja riktade filåtgärder i stället för att utföra breda, brusiga genomsökningar.

Ett vanligt antimönster är att packa all inmatning direkt i promptkontext. När indata växer blir det dyrt och svårt för modellen att navigera i en överfylld prompt. Ett bättre mönster är att mellanlagra resurser i containerfilsystemet och låta modellen bestämma vad som ska öppnas, tolkas eller transformeras med skalkommandon. Precis som för människor fungerar modeller bättre med organiserad information.

Den andra delen av containerkontexten är databaser. I många fall föreslår vi att utvecklare lagrar strukturerade data i databaser såsom SQLite och använder dem. Istället för att kopiera ett helt kalkylblad i prompten kan du till exempel ge modellen en beskrivning av tabellerna (vilka kolumner som finns och vad de betyder) och låta den hämta de rader den behöver.

Om du till exempel frågar: "Vilka produkter sålde sämre under det här kvartalet?" kan modellen begära endast de relevanta raderna i stället för att skanna hela kalkylarket. Det här är snabbare, billigare och mer skalbart för större datamängder.

Den tredje delen av containerkontexten är nätverksåtkomst, en viktig del av agentens arbetsbelastningar. Agentens arbetsflöde kan behöva hämta realtidsdata, anropa externa API:er eller installera paket. Det kan samtidigt vara riskabelt att ge containrar obegränsad internetåtkomst: det kan exponera information för externa webbplatser, oavsiktligt beröra känsliga interna eller tredjepartssystem, eller orsaka läckor av autentiseringsuppgifter och göra det svårare att skydda sig mot dataexfiltrering.

För att åtgärda dessa problem utan att begränsa agenternas användbarhet skapade vi värdbaserade containrar för att använda en sidecar-utgående proxy. Alla utgående nätverksförfrågningar går genom ett centraliserat policylager som tillämpar tillåtelselistor och åtkomstkontroller samtidigt som trafiken hålls observerbar. För autentiseringsuppgifter använder vi domänberoende hemlig injektion vid utgående trafik. Modellen och containern ser endast platshållare medan råa hemliga värden förblir utanför modellens synliga kontext och endast tillämpas för godkända destinationer. Detta minskar risken för läckage samtidigt som det fortfarande möjliggör autentiserade externa anrop.

Skalkommandon är kraftfulla men många uppgifter upprepar samma flerstegsmönster. Agenter måste återupptäcka arbetsflödet vid varje körning (planera om, utfärda kommandon på nytt och lära om konventioner) vilket leder till inkonsekventa resultat och bortkastad exekvering. Agentfärdigheter⁠(öppnas i ett nytt fönster) paketerar dessa mönster i återanvändbara och kombinerbara byggstenar. En färdighet är kortfattat ett mappaket med "SKILL.md⁠(öppnas i ett nytt fönster)" (innehåller metadata och instruktioner) samt eventuella stödresurser såsom API-specifikationer och UI-tillgångar.

Denna struktur kartläggs naturligt till den körarkitektur som beskrevs tidigare. Containern tillhandahåller beständiga filer och exekveringskontext medan skalverktyget tillhandahåller exekveringsgränssnittet. Med båda på plats kan modellen upptäcka färdighetsfiler med hjälp av skalkommandon ("ls", "cat", etc.) när så behövs, tolka instruktioner och köra färdighetsskript i samma agent-loop.

Vi tillhandahåller API:er⁠(öppnas i ett nytt fönster) för hantering av färdigheter på OpenAI-plattformen. Utvecklare laddar upp och lagrar färdighetsmappar som versionshanterade paket som senare kan hämtas med färdighets-ID. Innan prompten skickas till modellen läser Responses API in färdigheten och inkluderar den i modellens kontext. Den här sekvensen är deterministisk:

1. Hämta metadata för färdigheter, inklusive namn och beskrivning.
2. Hämta färdighetspaketet, kopiera det till containern och packa upp det.
3. Uppdatera modellens kontext med metadata för färdigheter och containersökvägen.

När modellen avgör om en färdighet är relevant utforskar den stegvis dess instruktioner och exekverar skriptet via skalkommandon i containern.

För att sätta ihop alla delar: Responses API tillhandahåller orkestrering, skalverktyget tillhandahåller körbara åtgärder, värdbaserad container tillhandahåller beständig körkontext, färdigheter skapar ett lager av återanvändbar arbetsflödeslogik, och komprimering gör det möjligt för en agent att köra under lång tid med den kontext den behöver.

Med dessa primitiver kan en enda prompt utvecklas till ett heltäckande arbetsflöde från början till slut: hitta rätt färdighet, hämta data, omvandla den till ett lokalt strukturerat tillstånd, fråga den effektivt och generera hållbara artefakter. 

Diagrammet nedan visar hur systemet fungerar när det skapar ett kalkylblad från realtidsdata.

För ett djupgående exempel på hur man kombinerar skalverktyget och datormiljön för heltäckande arbetsflöden, se vårt blogginlägg för utvecklare⁠(öppnas i ett nytt fönster) och vår kokbok⁠(öppnas i ett nytt fönster) som går igenom hur man paketerar en färdighet och kör den via Responses API.

Vi ser fram emot att få se vad utvecklare skapar med den här uppsättningen primitiver. Språkmodeller är avsedda att göra mer än att bara generera text, bilder och ljud. Vi kommer att fortsätta utveckla vår plattform så att den blir bättre på att hantera komplicerade, verkliga uppgifter i stor skala.