Cloudflare Containers, przebudowane do skalowania sandboxów agentów, zastępują statyczne wdrażanie kontrolą w czasie działania

Według firmy Cloudflare Containers, przebudowane do skalowania sandboxów agentów, uruchamiają się teraz ponad sześć razy szybciej. Wydanie z 30 września dodaje również wybór obrazu w czasie działania, dobór rozmiaru instancji w czasie działania oraz migawki systemu plików w publicznej becie.

Istotna zmiana nie ogranicza się do krótszego zimnego startu. Cloudflare przeniosło kontrolę nad każdym sandboxem do Durable Object — swojego stanowego komponentu serverless do koordynowania żądań i trwałego stanu aplikacji. Ta decyzja podważa model statycznego wdrażania, który ukształtował pierwszą wersję Cloudflare Containers.

Deweloperzy mogą teraz pozwolić agentowi wybrać środowisko wymagane dla każdego zadania. Zadanie programistyczne może wymagać większej instancji i pełnego zestawu narzędzi Linux. Mniejsza automatyzacja może korzystać z lżejszego środowiska. Gdy praca zostaje wstrzymana, system może zapisać system plików, zatrzymać zasoby obliczeniowe i później przywrócić obszar roboczy.

To umieszcza Cloudflare bardziej bezpośrednio na zatłoczonym rynku infrastruktury agentowej. E2B, Modal, Daytona, Vercel oraz usługi chmurowe hiperskalerów oferują już różne podejścia do izolowanego wykonywania zadań. Cloudflare przekonuje, że globalnie adresowalny kontroler, izolowany obszar roboczy Linux i trwały stan powinny działać jako jedna programowalna jednostka.

Architektura wydaje się odpowiednia dla agentów programistycznych, ewaluacji i długotrwałych przepływów pracy. Jednak deklaracja sześciokrotnie szybszego uruchamiania pochodzi od Cloudflare, migawki nadal są w publicznej becie, a znaczenie ma kilka ograniczeń operacyjnych. Prawdziwym testem będzie to, czy zespoły zyskają niezawodną kontrolę bez przejęcia zbyt dużej złożoności cyklu życia.

Cloudflare Containers, przebudowane do skalowania sandboxów agentów, zmieniają płaszczyznę sterowania

Kluczową zmianą Cloudflare jest przeniesienie konfiguracji sandboxa z czasu wdrażania na moment, w którym agent rozpoczyna zadanie.

W poprzednim modelu aplikacja zazwyczaj deklarowała jeden obraz kontenera i typ instancji w konfiguracji wdrożenia. Zmiana któregokolwiek ustawienia uruchamiała wdrożenie na poziomie aplikacji. Ten schemat sprawdza się w przewidywalnych usługach, ale agenci generują obciążenia różniące się między kolejnymi żądaniami.

Agent naprawiający kod może potrzebować repozytorium, kompilatora, menedżera pakietów, przeglądarki i zestawu testów. Worker ewaluacyjny może wymagać czystego, powtarzalnego środowiska z ściśle kontrolowanymi danymi wejściowymi. Inne zadanie może potrzebować jedynie krótkiego skryptu z ograniczoną pamięcią i bez dostępu do internetu.

Nowa polityka harmonogramowania durable_object od Cloudflare pozwala kodowi aplikacji podejmować te decyzje w czasie działania. Kontrolujący Durable Object wywołuje ctx.container.start() i przekazuje obraz, migawkę oraz konfigurację instancji odpowiednią dla danego zadania.

Dostępne predefiniowane rozmiary obejmują lite i cztery konfiguracje standard. Deweloperzy mogą również przekazywać niestandardowe wartości CPU, pamięci i dysku w granicach limitów platformy. Polityka harmonogramowania w czasie działania zastępuje jedną centralnie wybraną konfigurację decyzjami podejmowanymi dla każdego sandboxa.

Wybór obrazu podlega temu samemu modelowi. Deweloperzy deklarują nazwane obrazy za pośrednictwem Wrangler, narzędzia Cloudflare do wdrażania z wiersza poleceń. Platforma przygotowuje niezmienne odwołania, a Durable Object wybiera jedno z nich podczas uruchamiania sandboxa.

Takie rozwiązanie pozwala jednej aplikacji obsługiwać kilka ról agentowych bez wdrażania osobnej aplikacji kontenerowej dla każdej roli. Koordynator może skierować lekkie zadanie badawcze do jednego obrazu, a następnie przypisać zadanie budowania do innego obrazu z większymi zasobami.

Cloudflare wprowadziło również cloudflare/debian-trixie, zarządzany obraz Debian zawierający Node.js. Agent może rozpocząć od tej podstawy, zainstalować narzędzia przez exec() i zachować wynikowy obszar roboczy jako migawkę.

Według zapowiedzi sandboxów Cloudflare nowa ścieżka harmonogramowania uruchamia Containers ponad sześć razy szybciej. Firma twierdzi, że usunęła kilka etapów koordynacji, które wcześniej znajdowały się między Durable Object a środowiskiem wykonawczym kontenerów.

To twierdzenie wymaga ostrożnej interpretacji. Cloudflare nie przedstawiło niezależnego benchmarku porównującego reprezentatywne obrazy, regiony ani rodzaje obciążeń. Gotowość kontenera zależy również od rozmiaru obrazu, zachowania entrypointu, dostępnej pojemności oraz kontroli stanu aplikacji.

Własna dokumentacja architektury Cloudflare wskazuje, że zimne starty często mieszczą się w przedziale od jednej do trzech sekund. Zaznacza też, że czas uruchomienia różni się zależnie od obrazu i wykonywanej przez niego pracy inicjalizacyjnej. Szybszy harmonogram nie może wyeliminować opóźnień powstających wewnątrz samego obrazu.

Platforma udostępnia właściwość running, zanim proces będzie koniecznie gotowy do przyjmowania ruchu. Deweloperzy nadal muszą sprawdzać gotowość portu przed wysłaniem pierwszego żądania. W przypadku agenta „kontener uruchomiony” i „obszar roboczy gotowy do użytecznej pracy” pozostają odrębnymi pomiarami.

Nawet przy tych zastrzeżeniach konfiguracja w czasie działania zmienia model operacyjny produktu. Cloudflare Containers nie są już wyłącznie wdrożonymi usługami, z których przypadkiem korzystają agenci. Stają się zasobami, które kontroler agenta może tworzyć, dobierać pod względem rozmiaru, zatrzymywać i odtwarzać wokół poszczególnych zadań.

Szybsze sandboxy agentów wywierają presję na statyczne modele wdrażania

Obciążenia agentowe premiują infrastrukturę, która może zmieniać kształt między zadaniami, a nie jedynie infrastrukturę sprawnie uruchamiającą jeden obraz.

Tradycyjne platformy kontenerowe zakładają, że deweloperzy znają kształt aplikacji przed wdrożeniem. Zespoły wybierają obraz, przydział zasobów, politykę sieciową i konfigurację skalowania. Harmonogram tworzy następnie repliki, które zasadniczo dzielą te właściwości.

Systemy agentowe naruszają to założenie. Ich kolejne działanie zależy od żądań użytkowników, decyzji modelu, wyników narzędzi oraz stanu pozostawionego przez wcześniejszą pracę. Dwa następujące po sobie zadania w tym samym produkcie mogą wymagać różnych systemów operacyjnych, zależności, limitów zasobów i uprawnień sieciowych.

Ta zmienność wywiera presję na dostawców opartych na statycznej konfiguracji aplikacji. Zespoły nadal mogą wdrażać kilka usług i kierować między nimi pracę. Jednak każdy nowy rodzaj obciążenia dodaje kolejną jednostkę wdrożeniową, ścieżkę wdrożenia, decyzję dotyczącą pojemności oraz źródło dryfu konfiguracji.

Model Cloudflare w czasie działania przenosi część tej decyzji do kodu aplikacji. Kontroler agenta może wybrać obraz sandboxa i typ instancji po zbadaniu zadania. Może również zdecydować, czy sandbox otrzymuje dostęp do internetu, czy uruchamia się z zapisanej migawki.

Głównym przeciwnikiem nie jest więc jeden nazwany dostawca. Jest nim statyczny model wdrażania, który traktuje każdy sandbox w aplikacji jako kopię tej samej, uprzednio zdefiniowanej usługi.

E2B, Modal, Daytona i Vercel już obsługują ten rynek za pośrednictwem własnych abstrakcji. Niektóre kładą nacisk na przyjazne deweloperom API sandboxów. Inne opierają się na funkcjach, maszynach wirtualnych, obszarach roboczych lub szerszej orkiestracji chmurowej. Zespoły uruchamiające bezpośrednio Kubernetes lub Firecracker zyskują większą kontrolę, ale odpowiadają też za większą część infrastruktury.

Czynnikiem wyróżniającym Cloudflare jest relacja między każdym kontenerem a jego Durable Object. Durable Object zapewnia stabilną tożsamość, kod aplikacji, magazyn danych, alarmy i koordynację poza środowiskiem Linux. Kontener zapewnia izolowane zasoby obliczeniowe dla narzędzi potrzebujących konwencjonalnego systemu operacyjnego.

Pętla decyzyjna agenta może pozostać aktywna, gdy obszar roboczy Linux jest uśpiony. Może komunikować się z użytkownikami, zachowywać stan autoryzacji i wywoływać modele bez utrzymywania cięższego sandboxa w działaniu. Gdy konieczny staje się kompilator lub serwer deweloperski, kontroler wybudza kontener.

Cloudflare opisuje ten podział jako oddzielenie „mózgu” agenta od jego „rąk”. Kontroler zachowuje intencję i stan, podczas gdy sandbox wykonuje polecenia, które mogą zakończyć się błędem, zatrzymać się lub wymagać zastąpienia.

Podział ten przynosi korzyści bezpieczeństwa oraz korzyści operacyjne. Durable Object może przechowywać poświadczenia poza kontenerem i pośredniczyć w żądaniach wychodzących. Agent nie musi koniecznie mieć bezpośredniego dostępu do każdego sekretu wymaganego dla autoryzowanego wywołania usługi.

Cloudflare wcześniej argumentowało, że dynamicznie generowany kod agentów wymaga izolowanego środowiska wykonawczego. Wcześniejszy model sandboxa kodu skupiał się na lekkich Dynamic Workers dla zadań, które nie wymagają pełnego systemu Linux.

Containers obejmują cięższą stronę tego podziału. Obsługują menedżery pakietów, natywne binaria, repozytoria, kompilatory, terminale i serwery deweloperskie. Dynamic Workers mogą realizować mniejsze zadania wykonywania kodu w węższym środowisku wykonawczym.

Tworzy to warstwową strategię wykonywania. Kontroler może użyć lekkiego sandboxa dla krótkiego przepływu pracy API i zarezerwować kontener dla zadań wymagających Linuxa. Wybór w czasie działania ma znaczenie, ponieważ utrzymywanie każdego zadania w pełnym kontenerze marnuje czas uruchamiania i zasoby.

Presja wykracza poza dostawców sandboxów. Wewnętrzne zespoły platformowe często utrzymują pule ciepłych środowisk deweloperskich, aby ukryć opóźnienia związane z provisioningiem. Szybsze zimne starty i wznawialne systemy plików osłabiają argument za utrzymywaniem dużych, bezczynnych pul.

Cloudflare nie eliminuje jednak orkiestracji. Przenosi ją do Durable Object i kodu aplikacji. Zespoły nadal muszą projektować zasady przyjmowania zadań, kontrolę współbieżności, zachowanie przy ponawianiu prób, autoryzację, czyszczenie i obserwowalność.

Zwycięskim modelem nie będzie platforma raportująca najniższy pojedynczy wynik uruchamiania w izolacji. Będzie nim model minimalizujący całkowity czas od decyzji agenta do zweryfikowanego wyniku zadania.

Obejmuje to przygotowanie obrazu, dostęp do repozytorium, przywracanie zależności, wykonywanie poleceń, opóźnienia sieciowe i zamykanie środowiska. Obejmuje też opóźnienia po stronie człowieka powodowane przez nieudane sesje lub utraconą pracę.

Dla zespołów inżynieryjnych porównujących opcje właściwy benchmark powinien odtwarzać ich kompletny przepływ pracy. Syntetyczny test pustego kontenera nie może reprezentować dużego repozytorium, instalacji pakietów, uruchamiania przeglądarki ani zestawu testów.

Takie ewaluacje tworzą również wiedzę projektową, którą zespoły muszą zachować. Przeszukiwalna baza wiedzy inżynieryjnej może przechowywać założenia benchmarków, decyzje dotyczące bezpieczeństwa i ustalenia migracyjne obok implementacji.

Durable Objects przekształcają Containers w zasoby obliczeniowe specyficzne dla zadań

Mechanizmem stojącym za wydaniem jest stanowy kontroler, który traktuje swój kontener jako wymienne zasoby obliczeniowe, a nie trwały stan aplikacji.

Każdy Cloudflare Container jest powiązany z Durable Object. Żądania najpierw trafiają do Worker, a następnie są kierowane przez ten obiekt, zanim dotrą do kontenera. Durable Object może adresować konkretny obszar roboczy i zachowywać stan połączony z jego tożsamością.

Dzięki nowemu API deweloperzy rozszerzają bezpośrednio DurableObject i uzyskują dostęp do podłączonego kontenera przez this.ctx.container. Usuwa to klasę opakowującą, której Cloudflare pierwotnie używało, aby Containers przypominały konwencjonalne usługi sandboxowe.

Kontroler może uruchamiać kontener, wykonywać polecenia, sprawdzać jego stan, monitorować zakończenia procesów, wysyłać sygnały procesom, ustawiać limit bezczynności i niszczyć instancję. Może łączyć te mechanizmy sterowania z magazynem Durable Object, alarmami, WebSockets i zdalnymi wywołaniami procedur.

Wyobraźmy sobie agenta programistycznego odpowiadającego na zgłoszenie błędu. Durable Object może przechowywać identyfikator sesji, zatwierdzone repozytorium, uprawnienia użytkownika i bieżącą fazę zadania. Następnie może wybrać obraz zawierający odpowiedni zestaw narzędzi dla danego języka i uruchomić odpowiednią instancję.

Kontener klonuje repozytorium, instaluje zależności, uruchamia zestaw testów i edytuje pliki. W tym czasie Durable Object może przekazywać postępy przez WebSocket i zapisywać punkty kontrolne poza kontenerem.

Jeśli proces kontenera zakończy działanie, kontroler zachowuje tożsamość i metadane sesji. Może sprawdzić przyczynę awarii, uruchomić środowisko ponownie ze znanego stanu lub zgłosić problem bez utraty całej interakcji.

Cloudflare uruchamia każdy kontener wewnątrz mikroVM Firecracker — lekkiej maszyny wirtualnej z własnym jądrem i siecią. Obraz klienta działa jako kontener Linux wewnątrz tej maszyny wirtualnej.

Architektura kontenerów platformy stwierdza, że inne obciążenia Cloudflare nie współdzielą tego jądra. Ta izolacja ma znaczenie, ponieważ polecenia generowane przez agenta nie powinny być uruchamiane bezpośrednio w aplikacji obsługującej zaufane dane użytkowników.

Lokalizacja pozostaje dynamiczna. Cloudflare wybiera dostępną pojemność obliczeniową tam, gdzie wymagany obraz jest dostępny, a na lokalizację wpływają routing i szybkość uruchamiania. Durable Object i kontener nie muszą działać w tym samym miejscu.

To zastrzeżenie ma znaczenie dla pętli sterowania wrażliwych na opóźnienia. Globalnie adresowalna tożsamość nie oznacza, że każda operacja jest wykonywana blisko użytkownika, dostawcy modelu lub sandboxa. Zespoły powinny mierzyć pełną ścieżkę żądania w oczekiwanych regionach.

Pojemność obliczeniowa może także zmieniać się między sesjami. Jeśli kontener zatrzyma się i później zostanie uruchomiony ponownie, Cloudflare może umieścić jego zastępstwo w innym miejscu. Aplikacje nie mogą traktować lokalnej tożsamości jednej maszyny jako trwałej.

Durable Object staje się warstwą ciągłości. Przechowuje informacje wymagane do odnalezienia, odtworzenia lub przywrócenia przestrzeni roboczej. Instancja Linux staje się zasobem wykonawczym, który może zniknąć w okresie bezczynności.

Ta architektura obsługuje również rozgałęzione obciążenia. Koordynator może uruchomić kilka niezależnych prób z tej samej przygotowanej podstawy. Każda próba może testować inny model, prompt systemowy, zestaw umiejętności lub strategię naprawy.

Kontroler może monitorować te uruchomienia, porównywać wyniki i zachowywać preferowany rezultat. Systemy uczenia ze wzmocnieniem mogą wykorzystywać podobne wzorce do tworzenia kontrolowanych środowisk, oceniania wyników i resetowania stanu między próbami.

Dobór rozmiaru instancji w czasie działania wzmacnia ten model. Kontroler może przydzielić więcej zasobów kompilacjom, a ograniczyć je dla lżejszych poleceń. Statyczny rozmiar dla całej aplikacji zmuszałby zespoły do zapewniania zasobów dla największego typowego zadania albo utrzymywania osobnych wdrożeń.

Programowalność przenosi jednak odpowiedzialność na aplikację. Kontroler musi uniemożliwić modelowi wybieranie zasobów bez ograniczeń. Powinien mapować żądania agenta na zatwierdzone zasady, zamiast przekazywać dowolne dane wyjściowe modelu do interfejsów API infrastruktury.

Ta sama zasada dotyczy obrazów. Zezwolenie na wybór w czasie działania nie oznacza zgody na wykonywanie przez agenta dowolnego niezweryfikowanego obrazu. Cloudflare wymaga zadeklarowanych referencji obrazów przypiętych do digestów, co pomaga zachować powtarzalność wdrożeń.

Zespoły nadal powinny utrzymywać listę dozwolonych obrazów, skanować zależności, ograniczać dostęp wychodzący i oddzielać poświadczenia od środowiska gościa. Sandbox ogranicza ekspozycję, ale nie definiuje kompletnej polityki bezpieczeństwa.

Z operacyjnego punktu widzenia Durable Object powinien pozostać źródłem prawdy dla stanu cyklu życia. Bezpośrednie API Cloudflare zapewnia kontrolę, ale aplikacje muszą zdecydować, kiedy zadanie staje się możliwe do odzyskania, porzucone, ukończone lub bezpieczne do ponowienia.

To jest rzeczywisty mechanizm stojący za szybszymi sandboxami dla agentów. Usprawnienie harmonogramu ma znaczenie, lecz trwałą zmianą jest jawna płaszczyzna sterowania, która przetrwa poza pojedynczym procesem kontenera.

Migawki systemu plików zachowują pliki, a nie działające sesje

Migawki ograniczają powtarzalne prace przygotowawcze, ale są niezmiennymi punktami kontrolnymi systemu plików, a nie kompletnymi obrazami zawieszenia i wznowienia.

Natywne migawki systemu plików Cloudflare są dostępne w publicznej wersji beta za pośrednictwem zasady harmonogramowania durable_object. Działający kontener wywołuje snapshotContainer(), aby w określonym momencie uchwycić swój zapisywalny główny system plików.

Zwrócony uchwyt zawiera identyfikator, rozmiar i opcjonalną nazwę. Deweloperzy muszą zapisać ten uchwyt, często w pamięci Durable Object, ponieważ Worker API nie udostępnia polecenia do wyświetlania listy migawek.

Późniejszy kontener może zostać uruchomiony z zapisanego uchwytu. Dzięki temu przestrzeń robocza do programowania staje się możliwa do odzyskania po zatrzymaniu pierwotnych zasobów obliczeniowych. Repozytorium, zainstalowane zależności, pamięci podręczne kompilacji, pliki konfiguracyjne i zmiany mogą powrócić wraz z przywróconym systemem plików.

Model ten rozwiązuje częstą rozbieżność w infrastrukturze agentów. Uruchomienie pustego sandboxa może zająć sekundy, podczas gdy przygotowanie użytecznego środowiska programistycznego może trwać minuty. Powtarzanie instalacji zależności może dominować nad czasem uruchomienia, którego faktycznie doświadczają użytkownicy.

Migawki zapewniają także stabilną bazę dla ewaluacji. Zespół może przygotować jedno repozytorium i zestaw narzędzi, zapisać je, a następnie uruchomić wiele eksperymentów z tego samego punktu kontrolnego. Po przywróceniu każdy sandbox otrzymuje niezależne, zapisywalne środowisko.

Ogranicza to dryf środowisk między próbami. Jeśli dwie wersje modelu widzą różne stany zależności, wyniki testów stają się trudniejsze do porównania. Wspólny niezmienny punkt kontrolny pomaga wyizolować ocenianą zmienną.

Funkcja obsługuje również dłuższe projekty. Agent może zapisać przestrzeń roboczą, gdy użytkownik ją opuszcza, zatrzymać zasoby obliczeniowe i przywrócić pliki po powrocie użytkownika. Oddziela to ciągłość systemu plików od ciągłego zużywania zasobów.

Słowo „migawka” może jednak sugerować więcej, niż Cloudflare obecnie zachowuje. Dokumentacja migawek podaje, że system przechwytuje pełny system plików kontenera, ale nie pamięć, działające procesy ani osobno montowane systemy plików.

Przywrócony kontener ponownie uruchamia swój punkt wejścia. Kompilacja w pamięci, aktywny debugger, proces terminala lub serwer programistyczny nie zostają wznowione dokładnie od instrukcji, na której się zatrzymały. Aplikacja musi odtworzyć te procesy.

Migawki są także powiązane z wersją obrazu użytego do ich utworzenia. Deweloperzy nie mogą przywrócić jednej migawki do innego obrazu. Gdy obraz bazowy się zmienia, zespół musi utworzyć nową zgodną migawkę.

Każdy uchwyt migawki ma domyślny 30-dniowy czas życia. Jego przywrócenie odświeża ten okres, lecz deweloperzy nie mogą obecnie skonfigurować innego okresu retencji. To ograniczenie sprawia, że migawki nie nadają się na bezterminowe archiwum bez zewnętrznego planu przechowywania.

Migawki są niezmienne. Zmiany wprowadzone po przywróceniu wymagają kolejnej migawki, jeśli zespół chce je zachować. Aplikacje potrzebują zatem zasad tworzenia punktów kontrolnych, które równoważą wartość odzyskiwania z kosztami przechowywania, opóźnieniami i złożonością operacyjną.

Status publicznej wersji beta daje kolejny powód do ostrożności. Zespoły produkcyjne powinny weryfikować tworzenie i przywracanie migawek w warunkach przerwań, równoczesnego dostępu, aktualizacji obrazów i zmian regionalnego rozmieszczenia.

Powinny także testować granice awarii. Jeśli kontener zatrzyma się podczas tworzenia punktu kontrolnego, aplikacja potrzebuje jasnego zapisu, która migawka pozostaje prawidłowa. Jeśli zadanie zmienia system zewnętrzny, przywrócenie jego systemu plików nie cofnie tej zewnętrznej akcji.

To rozróżnienie jest szczególnie ważne dla autonomicznych agentów. Wycofanie może przywrócić lokalne pliki, pozostawiając bez zmian pull request, aktualizację bazy danych, e-mail lub zasób chmurowy. Bezkrytyczne ponowienie zadania mogłoby powielić nieodwracalną czynność.

Kontroler potrzebuje zatem rejestru zadań poza sandboxem. Powinien zapisywać zatwierdzone operacje, zewnętrzne skutki uboczne i ukończone punkty kontrolne. Sam system plików nie może przedstawiać pełnej prawdy o pracy agenta.

Zespoły bezpieczeństwa muszą również sprawdzać, co zachowują migawki. Repozytoria, wygenerowany kod, logi, pakiety z pamięci podręcznej i tymczasowe poświadczenia mogą trafić do zapisywalnego systemu plików. Migawka może zachować wrażliwe materiały dłużej niż działająca sesja.

Cloudflare oferuje przechwytywanie żądań wychodzących i zewnętrzną obsługę poświadczeń, co może ograniczyć ekspozycję sekretów wewnątrz środowiska gościa. Deweloperzy nadal powinni sprawdzać, czy narzędzia nie kopiują tokenów do plików konfiguracyjnych, historii powłoki lub pamięci podręcznych pakietów.

Kierunek migracji firmy wprowadza również inną praktyczną kwestię. Nowe funkcje, w tym szybsza ścieżka i natywne migawki, wymagają bezpośredniego dostępu do ctx.container. Cloudflare twierdzi, że będzie utrzymywać starsze klasy Container i legacy Sandbox do 31 grudnia 2026 roku.

Według firmy istniejące wdrożenia będą nadal działać po tej dacie, ale klasy te przestaną otrzymywać aktualizacje. Zespoły chcące korzystać z nowych możliwości muszą przenieść logikę cyklu życia do bezpośredniego API Durable Object.

To istotna zmiana architektury, a nie flaga, którą każdy zespół może bezpiecznie włączyć. Bezpośrednie API ujawnia więcej z modelu tożsamości i koordynacji systemu. Wymaga też od deweloperów przejęcia wyraźnej odpowiedzialności za zachowania wcześniej ukryte przez klasę bazową.

Cloudflare przekształca Sandbox SDK 1.0 w zbiór narzędzi, a nie nadklasę. Powinno to umożliwić zespołom łączenie wygodnych pomocników z natywną kontrolą cyklu życia. Potwierdza to również, że Cloudflare chce, by podstawową abstrakcję definiował Durable Object, a nie opakowanie SDK.

Kolejne testy dotyczą niezawodności, adopcji i reakcji konkurencji

Wydanie stanie się istotne tylko wtedy, gdy rzeczywiste systemy agentowe przełożą jego nowe mechanizmy sterowania na niższe opóźnienia zadań i niezawodne odzyskiwanie.

Pierwszym sygnałem, który warto obserwować, jest wydajność produkcyjna w pełnych obciążeniach. Raportowana przez Cloudflare sześciokrotna poprawa dotyczy ścieżki uruchamiania, ale deweloperzy potrzebują pomiarów od wysłania zadania do gotowości aplikacji.

Przydatne testy powinny obejmować małe i duże obrazy, kilka regionów, przywrócone migawki, świeże systemy plików i różne rozmiary instancji. Powinny rozróżniać opóźnienie harmonogramu od inicjalizacji obrazu, przywracania zależności i gotowości usługi.

Jeśli te pomiary wykażą konsekwentnie krótsze opóźnienia od początku do końca, argument Cloudflare zyska na sile. Jeśli korzyści znikają po włączeniu do procesu repozytoriów i serwerów programistycznych, szybkość uruchamiania staje się węższą przewagą.

Drugim sygnałem jest niezawodność migawek, gdy publiczna wersja beta trafi do wymagających obciążeń. Zespoły powinny obserwować wskaźniki błędów przywracania, czas tworzenia punktów kontrolnych, zachowanie pamięci masowej, procedury aktualizacji obrazów i odzyskiwanie po przerwanych sesjach.

Szczególnie wymowna byłaby skuteczna adopcja przez agentów programistycznych. Cloudflare już wskazuje Base44 i Kilo Code jako użytkowników izolowanych środowisk do pracy agentowej. Wcześniejsze materiały Cloudflare wymieniały także Figma Make jako klienta Containers do wykonywania niezaufanego kodu.

Te odniesienia do klientów pokazują realne przypadki użycia, ale nie dostarczają porównawczych danych dotyczących wydajności. Niezależne raporty inżynieryjne miałyby większą wagę niż opinie z okazji premiery.

Znaczenie będzie miało również zachowanie migawek w przypadku dużych repozytoriów. Katalogi pakietów i wyniki kompilacji mogą szybko rosnąć. Zespoły muszą zrozumieć, czy migawki pozostają szybkie i łatwe w zarządzaniu, gdy przestrzenie robocze rosną w kolejnych punktach kontrolnych.

Jeśli Cloudflare rozszerzy mechanizmy kontroli retencji migawek, API listowania, obserwowalność lub narzędzia migracji między wersjami, będzie to sugerować, że funkcja zmierza w stronę szerszego użycia produkcyjnego. Utrzymujące się ograniczenia osłabiłyby narrację o długotrwałych przestrzeniach roboczych.

Trzecim sygnałem jest to, jak konkurenci odpowiedzą na połączony model kontrolera i sandboxa Cloudflare. Rynek sandboxów dla agentów obejmuje wyspecjalizowanych dostawców i szersze platformy obliczeniowe, z których każda ma inne mocne strony.

E2B kładzie nacisk na tworzone z myślą o konkretnych celach środowiska chmurowe dla agentów. Modal łączy odizolowane środowiska obliczeniowe z większą platformą serverless. Daytona koncentruje się na środowiskach programistycznych, a Vercel integruje możliwości sandboxów ze swoją platformą aplikacyjną.

Chmury hiperskalowe zapewniają zespołom szeroką kontrolę za pośrednictwem maszyn wirtualnych, kontenerów, systemów tożsamości i usług orkiestracji. Ich wadą jest często nakład prac inżynieryjnych potrzebnych do połączenia tych komponentów w produkt agentowy o niskich opóźnieniach.

Cloudflare stawia na to, że Durable Objects upraszczają ten proces składania. Tożsamość, stan, komunikacja, polityki i cykl życia mogą działać obok kontrolera sandboxa. Jego globalna sieć zapewnia routing i przygotowaną pojemność.

Konkurencyjna odpowiedź może przybrać kilka form. Inni dostawcy mogą dodać silniejszą koordynację stanową, bardziej elastyczne snapshoty, dokładniejsze dostosowywanie wielkości środowiska wykonawczego lub ściślejsze pośredniczenie w obsłudze poświadczeń. Mogą również opublikować benchmarki podważające deklaracje Cloudflare dotyczące uruchamiania.

Jeśli konkurenci zbiegną się wokół zewnętrznego, stanowego kontrolera, architektura Cloudflare będzie wyglądać na dalekowzroczną nawet wtedy, gdy klienci wybiorą inną platformę. Jeśli deweloperzy będą preferować prostsze hostowane API sandboxów, model Durable Object może wydawać się zbyt obciążony infrastrukturą.

Wdrożenie będzie częściowo zależeć od tego, jak dużej kontroli oczekują zespoły aplikacyjne. Startup budujący agenta do programowania może cenić bezpośrednie programowanie cyklu życia. Zespół dodający jedną funkcję wykonywania kodu może preferować ukierunkowaną usługę wymagającą mniej decyzji.

Cloudflare musi obsłużyć obie grupy, nie ukrywając możliwości wyróżniających platformę. Nowy kierunek SDK próbuje pogodzić te potrzeby, oferując narzędzia wokół natywnego API zamiast kolejnej obowiązkowej warstwy abstrakcji.

Incydenty bezpieczeństwa będą kolejnym decydującym miernikiem. Sandboksy agentów wykonują niezaufane lub nieprzewidywalne polecenia, często z dostępem do sieci i bliskością zastrzeżonego kodu. Szybkie środowisko, które ujawnia poświadczenia lub umożliwia dostęp między tenantami, nie spełniłoby swojego podstawowego celu.

Wykorzystanie przez Cloudflare mikromaszyn wirtualnych Firecracker zapewnia izolację na poziomie jądra między obciążeniami. Bezpieczne działanie zależy jednak również od higieny obrazów, kontroli ruchu wychodzącego, autoryzacji, obsługi sekretów, logowania i polityk aplikacyjnych.

Zespoły powinny traktować ten model jako warstwową ochronę, a nie przyzwolenie na zaufanie kodowi wygenerowanemu przez agenta. Durable Object może stać się punktem egzekwowania polityk, ale deweloperzy muszą te polityki wdrożyć i przetestować.

Premiera rodzi również szersze pytanie o architekturę produktów agentowych. Czy agent powinien działać poza obszarem roboczym i traktować go jako wymienne narzędzie, czy też powinien działać wewnątrz własnego komputera?

Cloudflare obsługuje oba wzorce. Uruchamianie agenta w Durable Object utrzymuje dostępność komunikacji i stanu, gdy zasoby obliczeniowe są uśpione. Uruchamianie go wewnątrz kontenera oferuje znany model procesu Linux, podczas gdy obiekt nadzoruje go z zewnątrz.

Pierwszy wzorzec wyraźnie oddziela granicę między mózgiem a rękami. Drugi może uprościć działanie istniejących środowisk uruchomieniowych agentów, które oczekują lokalnych plików i procesów. Rzeczywiste wdrożenie pokaże, który model deweloperzy uznają za łatwiejszy w obsłudze.

Cloudflare Containers, przebudowane z myślą o skalowaniu sandboxów agentów, to coś więcej niż poprawa czasu zimnego startu. Przekształcają wybór środowiska wykonawczego, ciągłość systemu plików i politykę cyklu życia w decyzje na poziomie aplikacji kontrolowane przez trwały stan.

Ta zmiana wywiera presję na statyczne wdrożenia i uproszczone API sandboxów. Daje też deweloperom więcej sposobów na tworzenie subtelnych błędów. Elastyczność środowiska wykonawczego wymaga rygorystycznych polityk, trwałych rekordów zadań i benchmarków mierzących użyteczną gotowość, a nie pusty proces.

Zespoły oceniające tę premierę powinny zacząć od jednego rzeczywistego obciążenia. Należy zmierzyć świeży start, start po przywróceniu, gotowość zależności, odzyskiwanie po awarii i całkowite ukończenie zadania. Następnie warto sprawdzić, czy kontroler przetrwa utratę kontenerów bez powtarzania działań zewnętrznych.

Najbliższe miesiące powinny pokazać, czy snapshoty publicznej bety Cloudflare pozostaną niezawodne, czy klienci opublikują niezależne wyniki dotyczące opóźnień oraz czy konkurenci przyjmą podobne stanowe mechanizmy kontroli. Te sygnały określą, czy architektura ta stanie się powszechnym fundamentem dla długotrwałych agentów, czy kolejną wyspecjalizowaną opcją na coraz bardziej zatłoczonym rynku.