Els entorns d'execució més lleugers i els agents que executen codi són més adequats per a tasques obertes, en què una orquestració massa rígida pot limitar el rendiment del model.
Per tant, l'execució de codi i l'aïllament en entorns de proves són ara aspectes arquitectònics essencials dels sistemes d'agents.
L'Agents SDK redueix la complexitat i la quantitat de codi necessàries per crear agents que executen codi, fins a sis vegades segons les nostres proves.
Durant molt de temps, els avenços en els sistemes d'agents van provenir de millorar l'orquestració: indicacions més eficaces, interfícies d'eines, gestió del context i un flux de control més estricte. Però, a mesura que els agents de programació esdevenen més capaços, aquest equilibri comença a canviar.
En molts fluxos de treball oberts, el coll d'ampolla ja no és el bucle de l'agent, sinó la capa d'execució: l'entorn aïllat on el model escriu codi, executa ordres, examina els resultats i itera. A mesura que una part més gran del raonament de les tasques es trasllada a aquest entorn, l'orquestració que l'envolta s'ha de simplificar perquè el model pugui desplegar tota la seva capacitat.
Aquest canvi és precisament el que permet la nova versió de l'Agents SDK. En les proves que vam fer durant l'accés anticipat, vam constatar que, en lloc d'afegir una altra capa de lògica de framework, fa que la capa d'execució sigui més modular i combinable, de manera que la resta del sistema es pugui mantenir lleugera.
En l'enginyeria d'entorns d'execució, s'ha posat de moda reduir l'entorn d'execució a la mínima expressió efectiva. En termes generals, l'entorn d'execució és el programari que envolta el model: la capa que gestiona el context, les eines, el flux de control i els bucles de retroalimentació perquè el model pugui treballar de manera fiable.
Durant els darrers anys, moltes millores en el rendiment dels agents han provingut de reforçar aquesta capa. Unes eines millors, una memòria i una recuperació més eficaces, una descomposició més explícita i una orquestració més estricta sovint feien que els sistemes fossin més fiables i capaços. En aquest paradigma, avançar significava principalment codificar més lògica de les tasques en el programari que envolta el model.
Aquest patró ara perd força, almenys en una classe de tasques obertes. Cada vegada més projectes i estudis indiquen que el rendiment no sempre millora quan l'entorn d'execució esdevé més prescriptiu. En la programació assistida, les tasques de llarga durada, l'ús del navegador i les tasques de context llarg, es repeteix el mateix patró: quan el model és prou intel·ligent, imposar massa estructura de tasques al programari que l'envolta pot esdevenir una limitació en lloc d'un avantatge.
Per tant, el paper de l'entorn d'execució està canviant. En lloc d'intentar preveure la tasca mitjançant una orquestració rígida, l'entorn d'execució serveix cada cop més per oferir una superfície d'execució neta: un entorn aïllat on el model pot examinar l'estat, executar codi, recuperar-se dels errors i adaptar el seu enfocament, sempre dins dels límits de les interfícies i les salvaguardes del sistema. Aquest canvi s'assembla al que Andrej Karpathy va descriure a Software Engineer 3.0: una part de la lògica que abans residia en el programari puja fins a la "indicació".
La conclusió no és que calgui eliminar l'estructura de tots els sistemes d'agents. Moltes tasques encara es beneficien de fluxos de treball explícits, heurístiques i mecanismes de protecció deterministes, sobretot si són acotades, tenen un volum elevat o disposen d'un criteri d'èxit clar. Com defensàvem a l'article anterior sobre heurístiques per dissenyar sistemes d'agents, una orquestració sòlida continua sent important quan és possible i desitjable disposar d'un flux lògic fiable.
En les tasques obertes, el focus està canviant. El repte ja no consisteix tant a dissenyar capes d'orquestració cada cop més elaborades, sinó a crear entorns d'execució prou senzills, observables i modulars perquè el model hi pugui treballar de manera eficaç.
Quan un agent pot llegir fitxers, escriure codi, executar ordres de l'intèrpret d'ordres i iniciar tasques de llarga durada, el repte d'enginyeria canvia. La part difícil ja no és només optimitzar les indicacions o encaminar les eines. El fet que l'agent operi ara en un sistema real fa que aquests agents siguin molt més potents, però també més delicats, perquè amplien la superfície de seguretat i protecció. Per exemple, un agent capaç d'executar codi pot dur a terme accions perjudicials si el seu entorn no està ben aïllat (vegeu el Sandbox Bench de l'AISI).
Per tant, l'aïllament en entorns de proves esdevé un aspecte crític dels frameworks d'agents. En els sistemes anteriors, l'execució sovint es considerava un complement: una eina afegida a l'entorn d'execució. Però, quan l'execució conserva l'estat, és de llarga durada o és remota, aquest enfocament comença a fallar. Gestionar el mateix entorn aïllat —el seu cicle de vida, l'estat, les interfícies i la connexió amb el bucle de l'agent— esdevé ràpidament un problema de disseny de sistemes per si sol. Aquest és un dels motius pels quals cada vegada més proveïdors ofereixen entorns gestionats per executar codi, com ara l'API de contenidors i l'eina d'intèrpret d'ordres d'OpenAI, Modal, Cloudflare, Daytona i E2B.
Aquesta separació és important perquè l'execució de codi requereix un aïllament més robust i un control en temps d'execució més estricte que la resta de l'entorn d'execució. A la pràctica, els agents que executen codi i estan mal implementats poden introduir tres riscos crítics per al negoci: despesa informàtica descontrolada, accions destructives en sistemes interns i exposició d'informació sensible. Amb una contenidorització i un aïllament adequats, juntament amb salvaguardes en temps d'execució, aquests riscos es poden contenir fins a un nivell acceptable per a desplegaments reals.
Una manera d'entendre-ho és imaginar que es proporciona a l'agent un espai de treball propi i segellat, en lloc de donar-li les claus de tota l'oficina. Encara pot fer feina útil dins d'aquest espai, però només dins d'uns límits ben definits. Pots limitar els recursos informàtics que utilitza, restringir els sistemes i fitxers als quals pot accedir i controlar quina informació té disponible d'entrada.
Això no elimina del tot el risc, però transforma el problema d' Així, l'entorn aïllat esdevé una capa d'execució modular amb components portables que els desenvolupadors poden adoptar ràpidament, intercanviar entre proveïdors i escalar sense haver de refer constantment la lògica dels agents.
Quan un agent executa codi, també cal orquestrar el mateix entorn aïllat. Passar d'una prova de concepte local a l'execució remota, a diversos backends o a sessions de llarga durada augmenta exponencialment la càrrega operativa. Cal una manera coherent de crear entorns, aturar-los, posar-los en pausa i reprendre'ls, capturar-ne l'estat, tornar-s'hi a connectar més endavant i gestionar tot això entre proveïdors.
Res d'això no és especialment atractiu en teoria, però a la pràctica és important. És justament el tipus d'infraestructura que esdevé problemàtica quan cada equip reconstrueix des de zero una canalització d'agents, sobretot si no està integrada en el framework d'agents…
És aquí on esdevé important que el framework ofereixi més compatibilitat. Vam tenir accés anticipat a la nova versió de l'OpenAI Agents SDK i la vam utilitzar per crear els nostres propis agents aïllats. El més destacable va ser el canvi d'èmfasi arquitectònic: l'SDK tracta l'execució com una capa essencial, no com una eina perifèrica. A la pràctica, això permet iniciar un agent aïllat, capturar l'estat d'un entorn aïllat o reprendre l'execució amb menys codi —unes sis vegades menys en algunes proves— i després canviar de backend sense reescriure la lògica d'agents que l'envolta.
Aquesta separació més clara de responsabilitats permet que l'entorn d'execució se centri en el raonament, el context i el flux de treball. La capa d'execució es pot centrar en l'aïllament, la portabilitat i l'estat en temps d'execució. Aquesta abstracció facilita la creació d'agents de programació més capaços i fàcils d'evolucionar, que poden alternar entre l'execució local i la remota, admetre tasques de més durada i canviar de backend d'execució sense haver de redissenyar tot el sistema.
A mesura que més lògica de les tasques es trasllada de l'entorn d'execució al model, una part de la complexitat del sistema també es desplaça cap a la capa d'execució. L'execució de codi i l'aïllament en entorns de proves són ara aspectes arquitectònics essencials dels sistemes d'agents, sobretot per a tasques obertes i amb molta programació. Dissenyar la canalització d'agents és ara tan important com dissenyar l'entorn en què l'agent pot actuar de manera segura, fiable i continuada.
Per això són importants les abstraccions d'alt nivell per a l'execució en entorns aïllats. La nova versió de l'OpenAI Agents SDK avança en aquesta direcció perquè tracta l'execució com una capa modular del sistema: portable entre backends, amb estat persistent durant tasques llargues i prou senzilla d'utilitzar per no haver de reconstruir la mateixa infraestructura per a cada configuració nova.
La conclusió general és que la pròxima generació de frameworks d'agents probablement es definirà menys per la quantitat de lògica d'orquestració que afegeixin i més per com estructurin els entorns d'execució dels quals els agents depenen cada vegada més.