Lżejsze otoczenia operacyjne i agenty wykonujące kod lepiej sprawdzają się w zadaniach otwartych, w których nadmiernie sztywna orkiestracja może ograniczać możliwości modelu.
Dlatego wykonywanie kodu i izolacja w piaskownicy stają się kluczowymi zagadnieniami architektonicznymi w systemach agentowych.
Agents SDK ogranicza złożoność i ilość kodu potrzebnego do tworzenia agentów wykonujących kod — w naszych testach nawet sześciokrotnie.
Przez długi czas rozwój systemów agentowych opierał się na ulepszaniu orkiestracji: poleceń, interfejsów narzędzi, zarządzania kontekstem i ściślejszej kontroli przepływu. Jednak wraz ze wzrostem możliwości agentów programistycznych ta równowaga zaczyna się zmieniać.
W wielu otwartych przepływach pracy wąskim gardłem nie jest już sama pętla agenta, lecz warstwa wykonawcza: piaskownica, w której model pisze kod, uruchamia polecenia, analizuje wyniki i wprowadza kolejne poprawki. Ponieważ coraz więcej rozumowania dotyczącego zadania przenosi się do tego środowiska, otaczająca je orkiestracja musi być prostsza, aby model mógł w pełni wykorzystać swoje możliwości.
Właśnie tę zmianę umożliwia nowa wersja Agents SDK. Podczas testów w ramach wczesnego dostępu przekonaliśmy się, że zamiast dodawać kolejną warstwę logiki frameworka, nowe rozwiązanie zwiększa modułowość i elastyczność warstwy wykonawczej, dzięki czemu reszta systemu może pozostać lekka.
W projektowaniu otoczeń operacyjnych popularne stało się ograniczanie ich do minimalnej skutecznej formy. Ogólnie rzecz biorąc, otoczenie operacyjne to oprogramowanie otaczające model — warstwa, która zarządza kontekstem, narzędziami, przepływem sterowania i pętlami informacji zwrotnej, aby model mógł niezawodnie wykonywać pracę.
W ostatnich latach poprawa wydajności agentów często wynikała ze wzmacniania tej warstwy. Lepsze narzędzia, pamięć i wyszukiwanie informacji, bardziej jednoznaczny podział zadań oraz ściślejsza orkiestracja często zwiększały niezawodność i możliwości systemów. W tym paradygmacie postęp oznaczał głównie zapisywanie coraz większej części logiki zadania w oprogramowaniu otaczającym model.
Ten wzorzec traci obecnie na znaczeniu, przynajmniej w pewnej klasie zadań otwartych. Coraz więcej projektów i publikacji wskazuje, że wydajność nie zawsze rośnie, gdy otoczenie operacyjne narzuca bardziej szczegółowy sposób działania. W programowaniu wspomaganym, zadaniach długotrwałych, korzystaniu z przeglądarki i zadaniach wymagających długiego kontekstu stale pojawia się ten sam wzorzec: gdy model jest już wystarczająco inteligentny, narzucanie zbyt rozbudowanej struktury zadania w otaczającym go oprogramowaniu może stać się ograniczeniem zamiast zaletą.
Rola otoczenia operacyjnego ulega więc zmianie. Zamiast z góry przewidywać przebieg zadania za pomocą sztywnej orkiestracji, otoczenie operacyjne coraz częściej zapewnia przejrzystą przestrzeń wykonawczą: piaskownicę, w której model może sprawdzać stan, uruchamiać kod, naprawiać błędy i dostosowywać swoje podejście, pozostając w granicach wyznaczonych przez interfejsy i zabezpieczenia systemu. Przypomina to zmianę opisaną przez Andreja Karpathy’ego w materiale „Software Engineer 3.0”: część logiki, która wcześniej znajdowała się w oprogramowaniu, przenosi się na wyższy poziom — do „polecenia”.
Nie oznacza to, że z systemów agentowych należy całkowicie usuwać strukturę. W wielu zadaniach nadal pomagają jawne przepływy pracy, heurystyki i deterministyczne mechanizmy zabezpieczające, zwłaszcza gdy zadanie ma wąski zakres, jest wykonywane na dużą skalę lub ma jednoznaczne kryterium sukcesu. Jak argumentowaliśmy w poprzednim artykule „Heurystyki projektowania systemów agentowych”, solidna orkiestracja pozostaje istotna, gdy niezawodny przepływ logiki jest zarówno możliwy, jak i pożądany.
W przypadku zadań otwartych punkt ciężkości się jednak przesuwa. Wyzwanie polega już nie tyle na projektowaniu coraz bardziej rozbudowanych warstw orkiestracji, ile na tworzeniu środowisk wykonawczych, które są wystarczająco proste, obserwowalne i modułowe, aby model mógł w nich efektywnie działać.
Gdy agent potrafi odczytywać pliki, pisać kod, uruchamiać polecenia powłoki i inicjować długotrwałe zadania, zmienia się charakter wyzwania inżynieryjnego. Najtrudniejsze nie jest już wyłącznie optymalizowanie poleceń ani kierowanie wywołaniami narzędzi. Działanie agenta w rzeczywistym systemie znacznie zwiększa jego możliwości, ale też podnosi poziom ryzyka, ponieważ poszerza obszar wymagający ochrony i zabezpieczeń. Na przykład agent wykonujący kod może podjąć szkodliwe działania, jeśli jego środowisko nie jest odpowiednio odizolowane (zob. test porównawczy AISI Sandbox Bench).
Izolacja w piaskownicy staje się więc kluczowym zagadnieniem w frameworkach agentowych. We wcześniejszych systemach wykonywanie kodu często traktowano jako dodatek — narzędzie dołączone do otoczenia operacyjnego. Takie podejście przestaje jednak działać, gdy wykonywanie kodu wymaga zachowania stanu, trwa długo lub odbywa się zdalnie. Zarządzanie samą piaskownicą, jej cyklem życia, stanem, interfejsami i połączeniem z pętlą agenta szybko staje się odrębnym problemem z zakresu projektowania systemów. To jeden z powodów, dla których coraz więcej dostawców oferuje dziś zarządzane środowiska wykonywania kodu, w tym Container API i narzędzie powłoki OpenAI, a także rozwiązania firm Modal, Cloudflare, Daytona, E2B i innych.
To rozgraniczenie jest ważne, ponieważ wykonywanie kodu wymaga skuteczniejszej izolacji i ściślejszej kontroli środowiska uruchomieniowego niż pozostałe elementy otoczenia operacyjnego. W praktyce źle zaimplementowane agenty wykonujące kod mogą powodować trzy krytyczne zagrożenia biznesowe: niekontrolowane koszty mocy obliczeniowej, destrukcyjne działania w systemach wewnętrznych oraz ujawnienie informacji poufnych. Odpowiednia konteneryzacja, izolacja i zabezpieczenia środowiska uruchomieniowego pozwalają ograniczyć te zagrożenia do poziomu akceptowalnego we wdrożeniach produkcyjnych.
Można to porównać do udostępnienia agentowi własnej, zamkniętej przestrzeni roboczej zamiast kluczy do całego biura. Wciąż może w niej wykonywać użyteczną pracę, ale tylko w jasno określonych granicach. Można ograniczyć ilość używanej mocy obliczeniowej, wskazać systemy i pliki, do których ma dostęp, oraz kontrolować informacje udostępniane mu od samego początku.
Nie eliminuje to całkowicie ryzyka, ale zmienia problem z „agenta działającego bez nadzoru w infrastrukturze” w „agenta działającego w kontrolowanym środowisku”. Jeśli ta warstwa ma stać się standardowym elementem systemów agentowych, sam framework musi zapewniać jej pełne, natywne wsparcie. Dzięki temu piaskownica staje się modułową warstwą wykonawczą z przenośnymi mechanizmami, które programiści mogą szybko wdrażać, przenosić między dostawcami i skalować bez ciągłego modyfikowania logiki agenta.
Gdy agent wykonuje kod, sama piaskownica również wymaga orkiestracji. Przejście od lokalnego prototypu do wykonywania zdalnego, obsługi wielu backendów lub długotrwałych sesji gwałtownie zwiększa obciążenia operacyjne. Potrzebny jest spójny sposób tworzenia i zatrzymywania środowisk, wstrzymywania i wznawiania ich działania, zapisywania migawek stanu, późniejszego ponownego łączenia oraz zarządzania tym wszystkim u różnych dostawców.
Żaden z tych elementów nie jest szczególnie efektowny, ale wszystkie mają znaczenie w praktyce. To właśnie ten rodzaj infrastruktury, którego tworzenie staje się uciążliwe, gdy każdy zespół od podstaw buduje własny potok agentowy — zwłaszcza jeśli nie jest on zintegrowany z frameworkiem agentowym…
Właśnie tutaj istotne staje się lepsze wsparcie ze strony frameworka. Otrzymaliśmy wczesny dostęp do nowszej wersji OpenAI Agents SDK i wykorzystaliśmy ją do samodzielnego tworzenia agentów działających w piaskownicach. Szczególnie wyróżniała się zmiana priorytetów architektonicznych: SDK traktuje wykonywanie kodu jako pełnoprawną warstwę, a nie dodatkowe narzędzie. W praktyce oznacza to, że można uruchomić agenta w piaskownicy, zapisać migawkę piaskownicy lub wznowić wykonywanie przy użyciu mniejszej ilości kodu — w niektórych naszych testach około sześciokrotnie mniejszej — a następnie zmienić backend bez przepisywania otaczającej logiki agenta.
Ten wyraźniejszy podział odpowiedzialności pozwala skupić otoczenie operacyjne na rozumowaniu, kontekście i przepływie pracy. Warstwa wykonawcza może natomiast odpowiadać za izolację, przenośność i stan środowiska uruchomieniowego. Ta abstrakcja ułatwia tworzenie agentów programistycznych, które mają większe możliwości i łatwiej je rozwijać, mogą przechodzić między lokalnym a zdalnym wykonywaniem, obsługiwać długotrwałe zadania i zmieniać backendy wykonawcze bez konieczności przeprojektowywania całego systemu.
Wraz z przenoszeniem coraz większej części logiki zadania z otoczenia operacyjnego do modelu część złożoności systemu również zmienia miejsce — trafia niżej, do warstwy wykonawczej. Wykonywanie kodu i izolacja w piaskownicy są obecnie kluczowymi zagadnieniami architektonicznymi systemów agentowych, zwłaszcza w przypadku zadań programistycznych i otwartych. Zaprojektowanie środowiska, w którym agent może działać bezpiecznie, niezawodnie i przez długi czas, jest dziś równie ważne jak zaprojektowanie samego potoku agentowego.
Dlatego abstrakcje wyższego poziomu do wykonywania kodu w piaskownicy są tak ważne. Nowsza wersja OpenAI Agents SDK zmierza w tym kierunku, traktując wykonywanie kodu jako modułową warstwę systemu: przenośną między backendami, zachowującą stan podczas długotrwałych zadań i na tyle prostą w użyciu, że nie trzeba ponownie budować tej samej infrastruktury dla każdej nowej konfiguracji.
Ogólniejszy wniosek jest taki, że następną generację frameworków agentowych będzie prawdopodobnie definiować nie ilość dodawanej przez nie logiki orkiestracji, lecz jakość struktury środowisk wykonawczych, od których agenty są coraz bardziej zależne.