Slankere harness og agenter, der eksekverer kode, egner sig bedre til åbne opgaver, hvor alt for rigid orkestrering kan begrænse modellens ydeevne.
Dermed er kodeeksekvering og sandboxing nu centrale arkitektoniske hensyn i agentbaserede systemer.
Agents SDK reducerer kompleksiteten og mængden af kode, der kræves for at bygge agenter, som eksekverer kode – med op til en faktor 6 i vores test.
I lang tid blev agentsystemer bedre ved at forbedre orkestreringen: bedre promptning, værktøjsgrænseflader, kontekststyring og strammere kontrolflow. Men i takt med at kodeagenter bliver dygtigere, begynder denne balance at ændre sig.
I mange åbne arbejdsgange er flaskehalsen ikke længere selve agentløkken, men eksekveringslaget: den sandbox, hvor modellen skriver kode, kører kommandoer, undersøger output og gentager processen. Efterhånden som mere ræsonnering på opgaveniveau flyttes ind i dette miljø, skal den omgivende orkestrering forenkles, så modellen kan udnytte hele sin kapacitet.
Det er netop dette skifte, den nye version af Agents SDK muliggør. Vores test under den tidlige adgang viste, at løsningen ikke tilføjer endnu et lag frameworklogik, men i stedet gør eksekveringslaget mere modulært og kombinerbart, så resten af systemet kan forblive enkelt.
Inden for harness engineering er det blevet populært at reducere et harness til dets mindst mulige effektive form. Overordnet set er et harness den software, der omgiver modellen: laget, som håndterer kontekst, værktøjer, kontrolflow og feedbacksløjfer, så modellen kan arbejde pålideligt.
I løbet af de seneste år er agenternes ydeevne ofte blevet forbedret ved at styrke dette lag. Bedre værktøjer, bedre hukommelse og informationssøgning, mere eksplicit opdeling og strammere orkestrering gjorde ofte systemerne mere pålidelige og effektive. I dette paradigme betød fremskridt hovedsageligt, at mere opgavelogik blev indbygget i softwaren omkring modellen.
Dette mønster er nu ved at miste betydning, i hvert fald for en bestemt type åbne opgaver. Flere og flere projekter og forskningsartikler tyder på, at ydeevnen ikke altid forbedres, når et harness bliver mere styrende. Inden for assisteret programmering, langvarige opgaver, brug af browsere, og opgaver med lang kontekst ses det samme mønster igen og igen: Når modellen er intelligent nok, kan for meget påtvungen opgavestruktur i den omgivende software blive en begrænsning frem for en fordel.
Et harness spiller derfor en ny rolle. I stedet for at forsøge at foregribe opgaven gennem rigid orkestrering skal et harness i stigende grad levere en enkel eksekveringsflade: en sandbox, hvor modellen kan undersøge tilstanden, køre kode, rette fejl og tilpasse sin egen tilgang, samtidig med at systemets grænseflader og sikkerhedsforanstaltninger sætter grænserne. Det ligger tæt på det skifte, Andrej Karpathy beskrev i Software Engineer 3.0: Noget af den logik, der tidligere lå i softwaren, flyttes op i »prompten«.
Pointen er ikke, at agentsystemer helt skal fjerne strukturen. Mange opgaver har stadig gavn af eksplicitte arbejdsgange, heuristikker og deterministiske sikkerhedsbarrierer – især når opgaven er snæver, udføres i stort omfang eller har et klart succeskriterium. Som vi argumenterede for i vores tidligere indlæg om heuristikker til design af agentbaserede systemer, er stærk orkestrering stadig vigtig, når et pålideligt logikflow både er muligt og ønskeligt.
For åbne opgaver er fokus ved at flytte sig. Udfordringen handler mindre om at designe stadig mere avancerede orkestreringslag og mere om at bygge eksekveringsmiljøer, der er enkle, observerbare og modulære nok til, at modellen kan arbejde effektivt i dem.
Når en agent kan læse filer, skrive kode, køre shellkommandoer og starte langvarige opgaver, ændrer den tekniske udfordring sig. Det svære er ikke længere kun at optimere prompts eller dirigere brugen af værktøjer. Når en agent arbejder på et rigtigt system, bliver den markant mere effektiv, men også mere følsom, fordi sikkerhedsfladen bliver større. En agent, der kan eksekvere kode, kan eksempelvis udføre skadelige handlinger, hvis dens miljø er dårligt isoleret (se AISI's Sandbox Bench).
Sandboxing er derfor ved at blive et afgørende hensyn i agentframeworks. I tidligere systemer blev eksekvering ofte behandlet som en tilføjelse: et værktøj, der var koblet på et harness. Men når eksekveringen bliver tilstandsbaseret, langvarig eller ekstern, begynder denne tilgang at bryde sammen. Administration af selve sandboxen, dens livscyklus, tilstand og grænseflader samt dens forbindelse til agentløkken bliver hurtigt en selvstændig systemdesignopgave. Det er en af grundene til, at stadig flere udbydere nu tilbyder administrerede miljøer til kodeeksekvering, herunder OpenAIs Container API og shellværktøj, Modal, Cloudflare, Daytona og E2B.
Denne grænse er vigtig, fordi kodeeksekvering kræver stærkere isolering og strammere kontrol under kørslen end resten af et harness. I praksis kan dårligt implementerede agenter, der eksekverer kode, medføre tre forretningskritiske risici: ukontrollerede beregningsudgifter, destruktive handlinger på interne systemer og eksponering af følsomme oplysninger. Med korrekt containerisering, isolering og beskyttelse under kørslen kan disse risici begrænses til et niveau, der er acceptabelt ved implementering i praksis.
Man kan sammenligne det med at give en agent sit eget forseglede arbejdsrum i stedet for nøglerne til hele kontoret. Den kan stadig udføre nyttigt arbejde i dette rum, men kun inden for klart definerede grænser. Du kan begrænse dens beregningsforbrug, hvilke systemer og filer den kan tilgå, og hvilke oplysninger den overhovedet har adgang til.
Det fjerner ikke risikoen helt, men ændrer problemet fra »en agent på fri fod i din infrastruktur« til »en agent, der arbejder i et kontrolleret miljø«. Hvis dette lag skal være en fast bestanddel af agentsystemer, kræver det indbygget understøttelse i selve frameworket. Dermed bliver sandboxen et modulært eksekveringslag med flytbare grundelementer, som udviklere hurtigt kan tage i brug, skifte mellem udbydere og skalere uden konstant at skulle omarbejde agentlogikken.
Når en agent eksekverer kode, skal selve sandboxen også orkestreres. Skiftet fra et lokalt proof of concept til ekstern eksekvering, flere backends eller langvarige sessioner øger den driftsmæssige byrde eksponentielt. Du har brug for en ensartet metode til at oprette og stoppe miljøer, sætte dem på pause og genoptage dem, tage snapshots af tilstanden, genoprette forbindelsen senere og håndtere alt dette på tværs af udbydere.
Intet af dette lyder umiddelbart spændende, men det har stor praktisk betydning. Det er netop den type infrastruktur, der giver problemer, når hvert team bygger en agentbaseret pipeline helt fra bunden – især når den ikke er integreret i agentframeworket …
Her bliver bedre understøttelse i frameworket vigtig. Vi fik tidlig adgang til det nye OpenAI Agents SDK og brugte det selv til at bygge agenter i sandboxes. Det mest iøjnefaldende var det ændrede arkitektoniske fokus: SDK'et behandler eksekvering som et centralt lag frem for et perifert værktøj. I praksis betyder det, at du kan starte en agent i en sandbox, tage et snapshot af en sandbox eller genoptage eksekveringen med mindre kode – omkring seks gange mindre i nogle af vores test – og derefter skifte backend uden at omskrive den omgivende agentlogik.
Denne tydeligere ansvarsfordeling gør det muligt for et harness at fokusere på ræsonnering, kontekst og arbejdsgange. Eksekveringslaget kan fokusere på isolering, flytbarhed og tilstand under kørslen. Denne abstraktion gør det nemmere at bygge kodeagenter, der både er dygtigere og lettere at videreudvikle, kan skifte mellem lokal og ekstern eksekvering, understøtter mere langvarige opgaver og kan skifte eksekveringsbackend uden at kræve et redesign af hele systemet.
Efterhånden som mere logik på opgaveniveau flyttes fra et harness ind i modellen, følger noget af systemets kompleksitet med ned i eksekveringslaget. Kodeeksekvering og sandboxing er nu centrale arkitektoniske hensyn i agentbaserede systemer – især ved kodeintensive og åbne opgaver. Det er nu lige så vigtigt at designe den agentbaserede pipeline som det miljø, hvor agenten kan handle sikkert, pålideligt og over længere tid.
Derfor er abstraktioner på et højere niveau omkring eksekvering i sandboxes vigtige. Det nye OpenAI Agents SDK bevæger sig i denne retning ved at behandle eksekvering som et modulært systemlag: flytbart mellem backends, tilstandsbaseret på tværs af langvarige opgaver og enkelt nok til at kunne bruges uden at genopbygge den samme infrastruktur til hver ny opsætning.
Den overordnede lære er, at næste generation af agentframeworks sandsynligvis i mindre grad vil blive defineret af, hvor meget orkestreringslogik de tilføjer, og i højere grad af, hvor godt de strukturerer de eksekveringsmiljøer, som agenter i stigende grad er afhængige af.