Cadrele de testare mai suple și agenții care execută cod sunt mai potriviți pentru sarcini deschise, unde orchestrarea prea rigidă poate limita performanța modelului.
Prin urmare, executarea codului și izolarea în sandbox sunt acum aspecte arhitecturale esențiale pentru sistemele bazate pe agenți.
În testele noastre, Agents SDK a redus de până la 6 ori complexitatea și volumul de cod necesare pentru a crea agenți care execută cod.
Multă vreme, progresul sistemelor bazate pe agenți a venit din îmbunătățirea orchestrării: solicitări mai bune, interfețe pentru instrumente, gestionarea contextului și un flux de control mai strict. Dar, pe măsură ce agenții de programare devin mai capabili, acest echilibru începe să se schimbe.
În multe fluxuri de lucru deschise, blocajul nu mai este bucla agentului, ci nivelul de execuție: sandboxul în care modelul scrie cod, rulează comenzi, analizează rezultatele și face ajustări succesive. Pe măsură ce tot mai mult raţionament la nivel de sarcină se mută în acel mediu, orchestrarea din jur trebuie simplificată pentru ca modelul să-și poată valorifica pe deplin capacitățile.
Tocmai această schimbare este facilitată de noua versiune Agents SDK. În urma testelor efectuate în perioada de acces anticipat, am constatat că, în loc să adauge încă un nivel de logică a cadrului software, acesta face nivelul de execuție mai modular și mai ușor de compus, astfel încât restul sistemului să rămână suplu.
În proiectarea cadrelor de testare, a devenit populară reducerea cadrului de testare la forma sa eficientă minimă. În linii mari, cadrul de testare este software-ul din jurul modelului: nivelul care gestionează contextul, instrumentele, fluxul de control și buclele de feedback, astfel încât modelul să poată lucra fiabil.
În ultimii ani, multe dintre progresele înregistrate în performanța agenților au rezultat din consolidarea acestui nivel. Instrumentele mai bune, memoria și regăsirea informațiilor îmbunătățite, descompunerea mai explicită și orchestrarea mai strictă au făcut adesea sistemele mai fiabile și mai capabile. În această paradigmă, progresul a însemnat în mare parte integrarea unei porțiuni mai mari din logica sarcinii în software-ul din jurul modelului.
Acest tipar începe acum să-și piardă relevanța, cel puțin pentru o categorie de sarcini deschise. Tot mai multe proiecte și lucrări sugerează că performanța nu se îmbunătățește întotdeauna atunci când cadrul de testare devine mai prescriptiv. În programarea asistată, sarcinile de lungă durată, utilizarea browserului și sarcinile cu un context extins, același tipar apare în mod repetat: odată ce modelul este suficient de inteligent, impunerea unei structuri excesive a sarcinii prin software-ul din jur poate deveni o constrângere, nu un avantaj.
Prin urmare, rolul cadrului de testare se schimbă. În loc să încerce să anticipeze sarcina printr-o orchestrare rigidă, cadrul de testare oferă tot mai des o suprafață de execuție simplă: un sandbox în care modelul poate analiza starea, rula cod, remedia erori și își poate adapta abordarea, rămânând totodată în limitele interfețelor și măsurilor de protecție ale sistemului. Această evoluție seamănă cu schimbarea descrisă de Andrej Karpathy în Software Engineer 3.0: o parte din logica aflată anterior în software urcă la nivelul „solicitării”.
Concluzia nu este că sistemele bazate pe agenți ar trebui să elimine structura de peste tot. Multe sarcini beneficiază în continuare de fluxuri de lucru explicite, euristici și mecanisme de protecție deterministe, mai ales când sunt restrânse, au un volum mare sau un criteriu clar de reușită. După cum am susținut în articolul nostru anterior, Euristici pentru proiectarea sistemelor bazate pe agenți, orchestrarea solidă rămâne importantă atunci când un flux logic fiabil este atât posibil, cât și de dorit.
Pentru sarcinile deschise, accentul se mută. Provocarea nu mai constă atât în proiectarea unor niveluri de orchestrare tot mai elaborate, cât în crearea unor medii de execuție suficient de simple, observabile și modulare pentru ca modelul să poată lucra eficient în ele.
Odată ce un agent poate citi fișiere, scrie cod, rula comenzi shell și porni sarcini de lungă durată, provocarea inginerească se schimbă. Dificultatea nu mai constă doar în optimizarea solicitărilor sau direcționarea instrumentelor. Faptul că agentul operează acum într-un sistem real îi conferă mult mai multe capacități, dar îl face și mai sensibil, deoarece extinde suprafața expusă riscurilor de siguranță și securitate. De exemplu, un agent care poate executa cod poate întreprinde acțiuni dăunătoare dacă mediul său nu este izolat corespunzător (consultați Sandbox Bench de la AISI).
Prin urmare, izolarea în sandbox devine un aspect esențial al cadrelor software pentru agenți. În sistemele anterioare, execuția era adesea tratată ca o extensie: un instrument atașat cadrului de testare. Dar, când execuția începe să păstreze starea, să ruleze îndelung sau să aibă loc la distanță, această abordare nu mai funcționează. Gestionarea sandboxului, a ciclului său de viață, a stării și interfețelor sale, precum și conectarea lui la bucla agentului devin rapid o problemă distinctă de proiectare a sistemului. Acesta este unul dintre motivele pentru care tot mai mulți furnizori oferă acum medii gestionate pentru executarea codului, inclusiv API-ul Container și instrumentul shell de la OpenAI, Modal, Cloudflare, Daytona, E2B etc.
Această delimitare este importantă deoarece executarea codului necesită o izolare mai solidă și un control mai strict al rulării decât restul cadrului de testare. În practică, agenții care execută cod și sunt implementați necorespunzător pot genera trei riscuri critice pentru afacere: cheltuieli de calcul necontrolate, acțiuni distructive asupra sistemelor interne și expunerea informațiilor sensibile. Prin containerizare și izolare adecvate, alături de măsuri de protecție la rulare, aceste riscuri pot fi menținute la un nivel acceptabil pentru implementări reale.
O analogie utilă este să ne imaginăm că îi oferim agentului propriul spațiu de lucru izolat, nu cheile întregului birou. Agentul poate desfășura activități utile în acel spațiu, dar numai în limite clar definite. Puteți limita resursele de calcul pe care le folosește, sistemele și fișierele pe care le poate accesa, precum și informațiile care îi sunt disponibile de la bun început.
Acest lucru nu elimină complet riscul, dar transformă problema din „un agent liber în infrastructura dvs.” în „un agent care operează într-un mediu controlat”. Dacă acest nivel urmează să devină o componentă standard a sistemelor bazate pe agenți, trebuie să beneficieze de suport de prim rang în cadrul software. Astfel, sandboxul devine un nivel modular de execuție, cu primitive portabile pe care dezvoltatorii le pot adopta rapid, le pot transfera între furnizori și le pot scala fără să refacă permanent logica agentului.
Odată ce un agent execută cod, sandboxul însuși trebuie orchestrat. Trecerea de la o demonstrație de concept locală la execuție la distanță, mai multe sisteme backend sau sesiuni de lungă durată crește exponențial povara operațională. Aveți nevoie de o metodă consecventă pentru a crea medii, a le opri, întrerupe și relua, a salva instantanee ale stării, a vă reconecta ulterior și a gestiona toate acestea la mai mulți furnizori.
Nimic din toate acestea nu este spectaculos la nivel conceptual, dar contează în practică. Este exact tipul de infrastructură care devine dificil de gestionat atunci când fiecare echipă reconstruiește de la zero un flux bazat pe agenți, mai ales dacă acesta nu este integrat în cadrul software pentru agenți…
Aici devine important un suport mai bun din partea cadrului software. Am beneficiat de acces anticipat la noul OpenAI Agents SDK și l-am folosit pentru a crea noi înșine agenți izolați în sandbox. S-a remarcat schimbarea accentului arhitectural: SDK-ul tratează execuția drept un nivel de prim rang, nu ca pe un instrument periferic. În practică, aceasta înseamnă că puteți porni un agent izolat în sandbox, salva o instantanee a sandboxului sau relua execuția folosind mai puțin cod (de circa 6 ori mai puțin în unele dintre testele noastre), apoi puteți schimba sistemul backend fără să rescrieți logica agentului din jur.
Această separare mai clară a responsabilităților permite cadrului de testare să se concentreze asupra raţionamentului, contextului și fluxului de lucru. Nivelul de execuție se poate concentra asupra izolării, portabilității și stării din timpul rulării. Această abstractizare facilitează crearea unor agenți de programare mai capabili și mai ușor de dezvoltat în continuare, care pot trece de la execuția locală la cea la distanță, pot susține sarcini de lungă durată și pot schimba sistemele backend de execuție fără să impună reproiectarea întregului sistem.
Pe măsură ce tot mai multă logică la nivel de sarcină se mută din cadrul de testare în model, o parte din complexitatea sistemului o urmează, coborând în nivelul de execuție. Executarea codului și izolarea în sandbox sunt acum aspecte arhitecturale esențiale pentru sistemele bazate pe agenți, mai ales în cazul sarcinilor deschise și al celor care implică multă programare. Proiectarea fluxului bazat pe agenți este acum la fel de importantă precum proiectarea mediului în care agentul poate acționa în siguranță, fiabil și pe termen lung.
De aceea sunt importante abstractizările de nivel înalt pentru execuția izolată în sandbox. Noul OpenAI Agents SDK avansează în această direcție tratând execuția ca pe un nivel modular al sistemului: portabil între sisteme backend, capabil să păstreze starea în sarcini de lungă durată și suficient de simplu de utilizat fără a reconstrui aceeași infrastructură pentru fiecare configurație nouă.
Concluzia mai generală este că următoarea generație de cadre software pentru agenți va fi definită probabil mai puțin de volumul logicii de orchestrare adăugate și mai mult de eficiența cu care structurează mediile de execuție de care agenții depind tot mai mult.