Slankere rammeverk og agenter som kjører kode, egner seg bedre til åpne oppgaver, der for rigid orkestrering kan begrense modellens ytelse.
Dermed er kodekjøring og sandkasseisolering blitt sentrale arkitektoniske hensyn for agentsystemer.
Agents SDK reduserer kompleksiteten og kodemengden som kreves for å bygge agenter som kjører kode – med opptil seks ganger i testene våre.
Lenge kom fremskrittene innen agentsystemer fra bedre orkestrering: bedre prompting, verktøygrensesnitt, konteksthåndtering og strammere kontrollflyt. Men etter hvert som kodeagenter blir mer kapable, begynner denne balansen å forskyves.
I mange åpne arbeidsflyter er flaskehalsen ikke lenger selve agentsløyfen, men kjøringslaget: sandkassen der modellen skriver kode, kjører kommandoer, undersøker resultater og gjentar prosessen. Etter hvert som mer resonnering på oppgavenivå flyttes inn i dette miljøet, må orkestreringen rundt bli enklere, slik at modellen kan utnytte hele kapasiteten sin.
Det er nettopp denne endringen den nye versjonen av Agents SDK åpner for. I testene våre under tidlig tilgang fant vi at løsningen ikke legger til enda et lag med rammeverkslogikk, men gjør kjøringslaget mer modulært og fleksibelt, slik at resten av systemet kan forbli slankt.
Innen utvikling av rammeverk har det blitt populært å redusere rammeverket til den enkleste formen som fortsatt fungerer. På overordnet nivå er rammeverket programvaren rundt modellen: laget som håndterer kontekst, verktøy, kontrollflyt og tilbakemeldingssløyfer, slik at modellen kan utføre arbeid pålitelig.
De siste årene har mange forbedringer i agentytelse kommet fra å styrke dette laget. Bedre verktøy, bedre minne og gjenfinning, tydeligere oppdeling og strammere orkestrering gjorde ofte systemene mer pålitelige og kapable. I dette paradigmet handlet fremskritt i stor grad om å bygge mer oppgavelogikk inn i programvaren rundt modellen.
Dette mønsteret er nå i ferd med å svekkes, i hvert fall for en viss type åpne oppgaver. Stadig flere prosjekter og forskningsartikler tyder på at ytelsen ikke alltid blir bedre når rammeverket blir mer styrende. Innen assistert koding, langvarige oppgaver, bruk av nettlesere og oppgaver med lang kontekst ser vi det samme mønsteret igjen og igjen: Når modellen er intelligent nok, kan for mye påtvunget oppgavestruktur i programvaren rundt bli en begrensning snarere enn en fordel.
Rammeverkets rolle er derfor i endring. I stedet for å forsøke å forutse oppgaven gjennom rigid orkestrering fungerer rammeverket i stadig større grad som en ryddig kjøringsflate: en sandkasse der modellen kan undersøke tilstand, kjøre kode, rette opp feil og tilpasse sin egen fremgangsmåte, samtidig som den holdes innenfor systemets grensesnitt og sikkerhetstiltak. Dette ligger nær endringen Andrej Karpathy beskrev i Software Engineer 3.0: Noe av logikken som tidligere lå i programvaren, flyttes opp til «prompten».
Lærdommen er ikke at agentsystemer bør fjerne all struktur. Mange oppgaver har fortsatt nytte av eksplisitte arbeidsflyter, heuristikker og deterministiske sikkerhetsmekanismer, særlig når oppgaven er avgrenset, utføres i stort volum eller har et tydelig suksesskriterium. Som vi argumenterte for i det forrige innlegget vårt om heuristikker for utforming av agentsystemer, er god orkestrering fortsatt viktig når en pålitelig logisk flyt både er mulig og ønskelig.
For åpne oppgaver er tyngdepunktet i ferd med å flytte seg. Utfordringen handler mindre om å utforme stadig mer avanserte orkestreringslag og mer om å bygge kjøringsmiljøer som er enkle, observerbare og modulære nok til at modellen kan arbeide effektivt i dem.
Når en agent kan lese filer, skrive kode, kjøre skallkommandoer og starte langvarige oppgaver, endrer den tekniske utfordringen seg. Det vanskelige er ikke lenger bare å optimalisere prompter eller rute verktøy. At agenten nå opererer på et virkelig system, gjør disse agentene betydelig kraftigere, men også mer risikoutsatte fordi sikkerhetsflaten blir større. En agent som kan kjøre kode, kan for eksempel utføre skadelige handlinger hvis miljøet er dårlig isolert (se AISIs Sandbox Bench).
Sandkasseisolering blir derfor et kritisk hensyn i agentrammeverk. I tidligere systemer ble kjøring ofte behandlet som et tillegg: et verktøy festet utenpå rammeverket. Men når kjøringen blir tilstandsbevarende, langvarig eller ekstern, begynner denne tilnærmingen å bryte sammen. Håndteringen av selve sandkassen – livssyklusen, tilstanden, grensesnittene og koblingen til agentsløyfen – blir raskt et eget systemdesignproblem. Dette er en av grunnene til at stadig flere leverandører tilbyr administrerte miljøer for kodekjøring, blant annet OpenAIs Container API og skallverktøy, Modal, Cloudflare, Daytona og E2B.
Dette skillet er viktig fordi kodekjøring krever sterkere isolasjon og strammere kontroll under kjøring enn resten av rammeverket. I praksis kan dårlig implementerte agenter som kjører kode, medføre tre forretningskritiske risikoer: ukontrollerte databehandlingskostnader, destruktive handlinger i interne systemer og eksponering av sensitiv informasjon. Med riktig containerisering, isolasjon og sikkerhetstiltak under kjøring kan disse risikoene begrenses til et nivå som er akseptabelt ved reell produksjonssetting.
En måte å forstå dette på er å forestille seg at agenten får sitt eget forseglede arbeidsområde i stedet for nøklene til hele kontoret. Den kan fortsatt utføre nyttig arbeid der, men bare innenfor klart definerte grenser. Du kan sette et tak på hvor mye datakraft den bruker, begrense hvilke systemer og filer den kan berøre, og kontrollere hvilken informasjon den i utgangspunktet har tilgang til.
Det fjerner ikke risikoen fullstendig, men endrer problemet fra «en agent på frifot i infrastrukturen din» til «en agent som opererer i et kontrollert miljø». Hvis dette laget skal bli en standarddel av agentsystemer, må selve rammeverket ha førsteklasses støtte for det. Dermed blir sandkassen et modulært kjøringslag med portable grunnelementer som utviklere raskt kan ta i bruk, flytte mellom leverandører og skalere uten stadig å måtte omarbeide agentlogikken.
Når en agent kjører kode, må selve sandkassen også orkestreres. Overgangen fra et lokalt konseptbevis til ekstern kjøring, flere bakstykker eller langvarige økter øker den driftsmessige belastningen eksponentielt. Du trenger en konsekvent måte å opprette miljøer på, stoppe dem, sette dem på pause og gjenoppta dem, ta øyeblikksbilder av tilstanden, koble til igjen senere og håndtere alt dette på tvers av leverandører.
Ikke noe av dette er spesielt glamorøst som konsept, men det har stor betydning i praksis. Dette er nettopp den typen infrastruktur som blir smertefull når hvert team bygger en agentbasert prosess fra bunnen av, særlig når den ikke er integrert i agentrammeverket …
Det er her bedre støtte i rammeverket blir viktig. Vi fikk tidlig tilgang til den nyere versjonen av OpenAI Agents SDK og brukte den til å bygge våre egne agenter i sandkasser. Det som skilte seg ut, var endringen i arkitektonisk vektlegging: SDK-et behandler kjøring som et førsteklasses lag, ikke som et perifert verktøy. I praksis betyr det at du kan starte en agent i en sandkasse, ta et øyeblikksbilde av sandkassen eller gjenoppta kjøringen med mindre kode – rundt seks ganger mindre i noen av testene våre – og deretter bytte bakstykke uten å skrive om agentlogikken rundt.
Dette tydeligere skillet mellom ansvarsområder gjør at rammeverket kan holde oppmerksomheten på resonnering, kontekst og arbeidsflyt. Kjøringslaget kan konsentrere seg om isolasjon, portabilitet og tilstand under kjøring. Denne abstraksjonen gjør det enklere å bygge kodeagenter som både er mer kapable og enklere å videreutvikle, som kan veksle mellom lokal og ekstern kjøring, støtte mer langvarige oppgaver og bytte bakstykke for kjøring uten at hele systemet må utformes på nytt.
Etter hvert som mer logikk på oppgavenivå flyttes fra rammeverket og inn i modellen, følger noe av systemkompleksiteten med – ned i kjøringslaget. Kodekjøring og sandkasseisolering er nå sentrale arkitektoniske hensyn for agentsystemer, særlig for kodeintensive og åpne oppgaver. Det er nå like viktig å utforme den agentbaserte prosessen som miljøet der agenten kan handle sikkert, pålitelig og over tid.
Derfor er abstraksjoner på høyere nivå rundt kjøring i sandkasser viktige. Den nyere versjonen av OpenAI Agents SDK går i denne retningen ved å behandle kjøring som et modulært systemlag: portabelt mellom bakstykker, tilstandsbevarende gjennom langvarige oppgaver og enkelt nok til å bruke uten å bygge den samme infrastrukturen på nytt for hvert oppsett.
Den overordnede lærdommen er at neste generasjon agentrammeverk sannsynligvis vil defineres mindre av hvor mye orkestreringslogikk de legger til, og mer av hvor godt de strukturerer kjøringsmiljøene som agenter blir stadig mer avhengige av.