Enklare körmiljöer och agenter som kör kod lämpar sig bättre för öppna uppgifter, där alltför strikt orkestrering kan begränsa Modellens prestanda.
Därmed blir kodkörning och sandlådemiljöer centrala arkitekturfrågor för agentbaserade system.
Agents SDK minskar komplexiteten och mängden kod som krävs för att bygga agenter som kör kod – med upp till sex gånger i våra tester.
Under lång tid drevs utvecklingen av agentsystem genom förbättrad orkestrering: bättre promptar, verktygsgränssnitt, kontexthantering och striktare kontrollflöden. Men i takt med att kodningsagenter blir mer kapabla börjar den balansen förändras.
I många öppna arbetsflöden är flaskhalsen inte längre själva agentloopen, utan exekveringslagret: sandlådan där Modellen skriver kod, kör kommandon, granskar resultat och itererar. När mer Resonemang på uppgiftsnivå flyttar in i den miljön behöver den omgivande orkestreringen förenklas så att Modellen kan utnyttja hela sin kapacitet.
Det är precis den förändringen som den nya versionen av Agents SDK möjliggör. I våra tester under perioden med tidig åtkomst såg vi att SDK:n, i stället för att lägga till ännu ett lager med ramverkslogik, gör exekveringslagret mer modulärt och kombinerbart så att resten av systemet kan förbli enkelt.
Inom utveckling av körmiljöer har det blivit populärt att skala ned körmiljön till minsta effektiva form. På en övergripande nivå är körmiljön programvaran runt Modellen: lagret som hanterar kontext, verktyg, kontrollflöden och återkopplingsloopar så att Modellen kan utföra arbete tillförlitligt.
Under de senaste åren har många prestandaförbättringar för agenter kommit från att detta lager har stärkts. Bättre verktyg, minne och informationshämtning, tydligare uppdelning och striktare orkestrering gjorde ofta systemen mer tillförlitliga och kapabla. I det paradigmet innebar framsteg främst att mer uppgiftslogik kodades in i programvaran runt Modellen.
Det mönstret håller nu på att försvagas, åtminstone för en viss typ av öppna uppgifter. Allt fler projekt och forskningsartiklar tyder på att prestandan inte alltid förbättras när körmiljön blir mer styrande. Inom assisterad programmering, långvariga uppgifter, webbläsaranvändning och uppgifter med lång kontext återkommer samma mönster: när Modellen väl är tillräckligt intelligent kan alltför mycket påtvingad uppgiftsstruktur i den omgivande programvaran bli ett hinder snarare än en fördel.
Körmiljöns roll håller därför på att förändras. I stället för att försöka förutse uppgiften genom strikt orkestrering fungerar körmiljön i allt högre grad som en ren exekveringsyta: en sandlåda där Modellen kan granska tillstånd, köra kod, återhämta sig från fel och anpassa sitt arbetssätt, samtidigt som den begränsas av systemets gränssnitt och skyddsåtgärder. Det ligger nära den förändring som Andrej Karpathy beskrev i Software Engineer 3.0: en del av logiken som tidigare fanns i programvaran flyttas upp till ”Prompten”.
Slutsatsen är inte att agentsystem bör ta bort all struktur. Många uppgifter gynnas fortfarande av explicita arbetsflöden, heuristiker och deterministiska skyddsräcken, särskilt när uppgiften är avgränsad, har stor volym eller ett tydligt framgångskriterium. Som vi argumenterade för i vårt tidigare inlägg om heuristiker för utformning av agentbaserade system är kraftfull orkestrering fortfarande viktig när ett tillförlitligt logikflöde både är möjligt och önskvärt.
För öppna uppgifter håller fokus på att förskjutas. Utmaningen handlar mindre om att utforma allt mer avancerade orkestreringslager och mer om att bygga exekveringsmiljöer som är tillräckligt enkla, observerbara och modulära för att Modellen ska kunna arbeta effektivt i dem.
När en Agent kan läsa filer, skriva kod, köra skalkommandon och starta långvariga uppgifter förändras den tekniska utmaningen. Det svåra är inte längre enbart att optimera promptar eller dirigera verktyg. Att Agenten nu arbetar i ett verkligt system gör dessa agenter betydligt kraftfullare, men också känsligare eftersom de medför en större angreppsyta och fler säkerhetsrisker. En Agent som kan köra kod kan exempelvis utföra skadliga åtgärder om miljön är dåligt isolerad (se AISI:s Sandbox Bench).
Sandlådemiljöer blir därför en kritisk fråga i agentramverk. I tidigare system behandlades exekvering ofta som ett tillägg: ett verktyg som fogades till körmiljön. Men när exekveringen blir tillståndsbevarande, långvarig eller fjärrbaserad börjar det tillvägagångssättet falla samman. Att hantera själva sandlådan, dess livscykel, tillstånd och gränssnitt samt kopplingen till agentloopen blir snabbt ett eget problem inom systemdesign. Det är en av anledningarna till att allt fler leverantörer nu erbjuder hanterade miljöer för kodkörning, däribland OpenAI:s Container API och skalverktyg, Modal, Cloudflare, Daytona och E2B.
Denna gränsdragning är viktig eftersom kodkörning kräver starkare isolering och striktare kontroll vid körning än resten av körmiljön. I praktiken kan bristfälligt implementerade agenter som kör kod medföra tre verksamhetskritiska risker: okontrollerade beräkningskostnader, destruktiva åtgärder i interna system och exponering av känslig information. Med korrekt containerisering, isolering och skydd vid körning kan riskerna begränsas till en nivå som är acceptabel för verkliga driftsättningar.
Ett sätt att se på saken är att föreställa sig att Agenten får en egen förseglad arbetsyta i stället för nycklarna till hela kontoret. Den kan fortfarande utföra värdefullt arbete där, men bara inom tydligt definierade gränser. Du kan begränsa hur mycket beräkningskapacitet den använder, vilka system och filer den får komma åt och vilken information som över huvud taget görs tillgänglig för den.
Det eliminerar inte risken helt, men förändrar problemet från ”en Agent på fri fot i infrastrukturen” till ”en Agent som arbetar i en kontrollerad miljö”. Om detta lager ska bli en standarddel av agentsystem behöver det inbyggt stöd i själva ramverket. På så sätt blir sandlådan ett modulärt exekveringslager med portabla byggstenar som utvecklare snabbt kan införa, flytta mellan leverantörer och skala utan att ständigt behöva göra om agentlogiken.
När en Agent kör kod behöver även själva sandlådan orkestreras. Att gå från ett lokalt koncepttest till fjärrexekvering, flera backend-system eller långvariga sessioner ökar den operativa belastningen exponentiellt. Det behövs ett enhetligt sätt att skapa och stoppa miljöer, pausa och återuppta dem, ta ögonblicksbilder av tillståndet, återansluta senare och hantera allt detta mellan olika leverantörer.
Inget av detta är särskilt glamoröst i teorin, men det spelar stor roll i praktiken. Det här är precis den typ av infrastruktur som blir besvärlig när varje team bygger om en agentbaserad pipeline från grunden, särskilt när den inte är integrerad i agentramverket …
Det är här bättre stöd i ramverket blir viktigt. Vi fick tidig åtkomst till den nyare versionen av OpenAI Agents SDK och använde den för att själva bygga agenter i sandlådemiljöer. Det som utmärkte sig var det förändrade arkitekturfokuset: SDK:n behandlar exekvering som ett centralt lager snarare än som ett perifert verktyg. I praktiken innebär det att du kan starta en Agent i en sandlåda, ta en ögonblicksbild av sandlådan eller återuppta exekveringen med mindre kod – omkring sex gånger mindre i vissa av våra tester – och sedan byta backend utan att skriva om den omgivande agentlogiken.
Den tydligare ansvarsfördelningen gör att körmiljön kan fortsätta fokusera på Resonemang, kontext och arbetsflöde. Exekveringslagret kan fokusera på isolering, portabilitet och tillstånd vid körning. Denna abstraktion gör det enklare att bygga kodningsagenter som både är mer kapabla och lättare att vidareutveckla. De kan växla mellan lokal exekvering och fjärrexekvering, hantera långvariga uppgifter och byta exekveringsbackend utan att hela systemet måste utformas på nytt.
När mer logik på uppgiftsnivå flyttar från körmiljön till Modellen följer en del av systemkomplexiteten med – ned till exekveringslagret. Kodkörning och sandlådemiljöer är nu centrala arkitekturfrågor för agentbaserade system, särskilt vid kodintensiva och öppna uppgifter. Det är nu lika viktigt att utforma den agentbaserade pipelinen som att utforma den miljö där Agenten kan agera säkert, tillförlitligt och över tid.
Därför är abstraktioner på högre nivå för exekvering i sandlådemiljöer viktiga. Den nyare versionen av OpenAI Agents SDK går i den riktningen genom att behandla exekvering som ett modulärt systemlager: portabelt mellan backend-system, tillståndsbevarande under långvariga uppgifter och tillräckligt enkelt att använda utan att samma infrastruktur behöver byggas om för varje ny konfiguration.
Den bredare lärdomen är att nästa generations agentramverk sannolikt kommer att definieras mindre av hur mycket orkestreringslogik de lägger till och mer av hur väl de strukturerar de exekveringsmiljöer som agenter blir allt mer beroende av.