Cloudflare Computer dzieli komputer agenta między izolaty i kontenery

Cloudflare udostępniło Cloudflare Computer jako zapowiedź projektu open source 3 sierpnia 2026 roku, oferując agentom jedną trwałą przestrzeń roboczą działającą na trzech backendach wykonawczych. Właśnie w tej architekturze kryje się napięcie. Deweloperzy mogą kierować proste zadania do lekkich izolatów Workers, a kontenery Linux rezerwować dla bardziej wymagających prac, lecz projekt wyraźnie nie jest jeszcze gotowy do użycia produkcyjnego.

To rozróżnienie ma znaczenie, ponieważ infrastruktura dla agentów zmierzała w stronę pełnych, odizolowanych maszyn. Cloudflare Computer testuje inne założenie: agent potrzebuje możliwości komputera, ale nie każde działanie wymaga tego samego środowiska uruchomieniowego. Jego pliki mogą trwale istnieć niezależnie od środowiska wykonującego poszczególne polecenia.

W rezultacie rozwiązanie wywiera presję na dostawców, którzy traktują sandbox, kontener lub microVM jako podstawową jednostkę sesji agenta. Stanowi też wyzwanie dla istniejącego Sandbox SDK Cloudflare, które musi uzasadnić, kiedy deweloperzy rzeczywiście potrzebują dedykowanego kontenera. Ta zapowiedź jest mniej gotowym produktem, a bardziej publicznym argumentem dotyczącym tego, jak należy podzielić obliczenia dla agentów.

Cloudflare Computer oddziela pliki od wykonania

Kluczowa zmiana ma charakter architektoniczny: przestrzeń robocza agenta nie należy już do jednego uruchomionego kontenera.

Według repozytorium open source projektu, Cloudflare Computer przechowuje autorytatywny wirtualny system plików wewnątrz Durable Object. Durable Object to stanowy komponent Cloudflare z prywatną, trwałą pamięcią masową i pojedynczym punktem koordynacji.

Stan tego systemu plików przechowuje SQLite. Wykonanie odbywa się gdzie indziej, za pośrednictwem wspólnego interfejsu o nazwie workspace.runtime. Agent może odczytywać i modyfikować te same pliki, nawet gdy jego polecenia są wykonywane przez różne backendy.

W wersji zapoznawczej dostępne są trzy backendy. Backend kontenerowy zapewnia pełne środowisko Linux z rzeczywistymi binariami, menedżerami pakietów i dostępem do sieci. Backend powłoki Worker uruchamia polecenia przypominające polecenia shell za pomocą just-bash wewnątrz Dynamic Worker. Trzeci backend wykonuje moduły JavaScript w nowych instancjach Dynamic Workers.

Deweloperzy mogą zarejestrować dla jednej przestrzeni roboczej więcej niż jeden backend. Każdy otrzymuje stabilny identyfikator, a workspace.runtime.exec() staje się wspólnym punktem wejścia. Wywołujący może wybrać backend bezpośrednio albo framework agenta może dokonać wyboru na podstawie opisów dostarczonych przez dewelopera.

Taki układ sprawia, że system plików staje się trwałym centrum sesji. Obliczenia są wymienne. Lekkie polecenie może działać w izolacie, podczas gdy instalacja pakietu lub natywne budowanie może zostać przeniesione do Linuxa bez tworzenia odrębnej logicznej przestrzeni roboczej.

Cloudflare określa pakiet jako trwały, oparty na SQLite wirtualny system plików z wymiennymi mechanizmami wykonawczymi. Jego dokumentacja pakietu opisuje limit około 10 GB na przestrzeń roboczą. Magazyn współdzieli limity swojego Durable Object.

Pakiet działa również bez żadnego backendu wykonawczego. Aplikacja może korzystać wyłącznie z trwałego systemu plików, a wykonanie dodać dopiero wtedy, gdy wymaga go jej przepływ pracy. Dzięki temu model przechowywania danych jest czymś więcej niż funkcją pomocniczą dla sandboxa.

Publiczne API przypomina znane operacje systemu plików Node.js. Obejmuje funkcje odczytywania, zapisywania, listowania, usuwania i przeszukiwania plików. Łańcuchy znaków domyślnie używają UTF-8, a dane binarne można przesyłać za pomocą tablic bajtów lub strumieni.

Dostęp do kontenera wymaga kolejnej warstwy. Wewnątrz sandboxa działa demon o nazwie computerd, który udostępnia trwałą przestrzeń roboczą jako punkt montowania FUSE. FUSE pozwala procesowi działającemu w przestrzeni użytkownika prezentować pliki przez standardowy interfejs systemu plików.

Demon synchronizuje zmiany z autorytatywnym Durable Object przez kanał RPC. Zapewnia to narzędziom Linuxa konwencjonalny katalog, przy jednoczesnym zachowaniu SQLite poza kontenerem jako źródła prawdy.

Backendy oparte na izolatach wybierają krótszą drogę. Ich operacje na plikach wywołują ten sam Durable Object przez Workers RPC, dzięki czemu nie muszą utrzymywać drugiego magazynu. Unikają też kroku synchronizacji wymaganego po pracy w kontenerze.

Właśnie to sprawia, że ogłoszenie jest czymś więcej niż kolejną usługą wykonywania kodu. Cloudflare Computer rozkłada znany komputer na trwałe pliki, wybieralne wykonanie, synchronizację i pomocnicze funkcje publikowania. Agent nadal widzi jedną przestrzeń roboczą, choć infrastruktura pod spodem może zmieniać się z polecenia na polecenie.

Dlaczego agenci nie mieszczą się już w jednym środowisku uruchomieniowym

Obciążenia agentów łączą drobne operacje na plikach z okazjonalną pracą na poziomie systemu, przez co jedno stałe środowisko wykonawcze jest nieefektywnym ustawieniem domyślnym.

Agent programistyczny rzadko wykonuje jednorodne zadanie. Może sprawdzić plik konfiguracyjny, przeszukać repozytorium, zmodyfikować kilka linii, uruchomić testy, zainstalować zależność, utworzyć obraz i opublikować artefakt. Te działania mają różne wymagania wobec środowiska uruchomieniowego.

Odczyt pliku nie wymaga kompletnego kontenera Linux. Podobnie jak parsowanie tekstu czy wykonanie kontrolowanego modułu JavaScript. Natywna kompilacja, instalacja pakietów i narzędzia systemu operacyjnego zazwyczaj już tego wymagają.

Tradycyjne zdalne sandboxy łączą te potrzeby w jednym pakiecie. Sandbox zapewnia system plików, powłokę, procesy i dostęp do sieci w ramach jednego środowiska. Model ten jest łatwy do zrozumienia, ale wiąże trwałość danych i wykonanie z tym samym cyklem życia.

Wcześniejsze Sandbox SDK Cloudflare w dużej mierze opiera się na tym modelu. Firma udostępniła Sandboxes w wersji ogólnodostępnej 13 kwietnia 2026 roku, po tym jak dziewięć miesięcy wcześniej po raz pierwszy przedstawiła je jako środowiska dla poleceń i systemów plików.

W momencie ogólnej dostępności każdy Sandbox stał się środowiskiem programistycznym z terminalem, procesami działającymi w tle, monitorowaniem plików, adresami URL podglądu na żywo, kontrolą ruchu wychodzącego i migawkami. Cloudflare informowało, że standardowe konta mogą uruchamiać 15 000 współbieżnych lekkich instancji, 6 000 podstawowych instancji oraz ponad 1 000 większych instancji.

Firma przeszła też na rozliczanie Sandboxes według aktywnego czasu CPU, dzięki czemu okresy bezczynności nie zużywają płatnego czasu procesora. Ta zmiana ograniczyła jeden z kosztów długotrwałych sesji agentów. Nie zatarła jednak architektonicznej różnicy między uruchomieniem kontenera a wykonywaniem kodu w lekkim izolacie.

Cloudflare Computer przekształca tę różnicę w decyzję o routingu. Backendy łączą się leniwie, co oznacza, że inicjalizują się dopiero wtedy, gdy po raz pierwszy trafia do nich praca. Przepływ pracy może zacząć się od plików i izolatu, a po Linux sięgnąć dopiero wtedy, gdy polecenie rzeczywiście go potrzebuje.

Strategia ta odzwierciedla szersze stanowisko Cloudflare, zgodnie z którym obciążenia agentów wymagają kilku skal obliczeniowych. W podsumowaniu Agents Week firma argumentowała, że niektórzy agenci potrzebują pełnych systemów operacyjnych, podczas gdy większość zadań wymaga lżejszych środowisk uruchamiających się w milisekundach.

Cloudflare Computer nadaje temu twierdzeniu konkretny model programistyczny. Nie wymaga od deweloperów ręcznego przenoszenia plików między niepowiązanymi usługami. Przestrzeń robocza zapewnia ciągłość, podczas gdy granica wykonania się zmienia.

Dla autorów frameworków ta ciągłość jest istotna. Agent może otrzymać standardowe narzędzia o nazwach read, write, edit, ls i exec. Pakiet oferuje adaptery dla aplikacji AI SDK, a deweloper opisuje, co potrafi obsłużyć każdy backend.

Model może następnie kierować szybkie operacje tekstowe do izolatu, a cięższe polecenia do kontenera. W ten sposób wybór backendu staje się częścią polityki narzędziowej agenta. Tworzy to również nowy tryb awarii, jeśli opisy są niejasne albo model dokonuje złego wyboru.

Projekt jest szczególnie istotny dla agentów, które często się zatrzymują. Wnioskowanie modelu, zatwierdzanie przez człowieka, żądania sieciowe i wywołania zewnętrznych API tworzą przerwy w bezczynności. Utrzymywanie pełnego środowiska aktywnego przez każdą taką przerwę może zapewniać wygodę, ale nie jest jedynym sposobem na zachowanie pracy agenta.

Trwały system plików pozwala warstwie wykonawczej zniknąć bez usuwania stanu sesji. Kolejne działanie może ponownie otworzyć te same pliki przez inny backend. Z perspektywy agenta przypomina to komputer, choć żadna pojedyncza maszyna nie posiada całej sesji.

Ta abstrakcja wywiera presję na dostawców stawiających na kontenery, ale nie eliminuje ich najsilniejszego argumentu. Kompletne odizolowane środowisko zapewnia przewidywalne narzędzia, znane metody debugowania i spójną granicę bezpieczeństwa. Podział sesji między środowiska uruchomieniowe dodaje problemy związane z koordynacją i synchronizacją.

Wywiera również presję na granice produktów Cloudflare. Deweloperzy muszą rozumieć, czy potrzebują Sandbox SDK, Cloudflare Computer, Dynamic Workers czy ich kombinacji. Pakiet w wersji zapoznawczej może badać nakładanie się funkcji, lecz platforma produkcyjna ostatecznie potrzebuje prostej odpowiedzi.

Najprawdopodobniej odpowiedź zależy od rodzaju obciążenia. Cloudflare Computer sprzyja agentom, które wykonują wiele małych operacji i sporadycznie potrzebują Linuxa. Kontener pozostaje bardziej przejrzysty, gdy niemal każdy krok zależy od natywnych narzędzi, rozbudowanych lokalnych zależności lub dostępu do dysku o wysokiej przepustowości.

To jest prawdziwe pytanie o stawkę. Zapowiedź pyta, czy jednostką, którą deweloperzy powinni udostępniać, jest maszyna, czy przestrzeń robocza zdolna pożyczać różne maszyny.

Jak Cloudflare Computer kieruje jedną przestrzeń roboczą na trzy backendy

Cloudflare Computer zyskuje elastyczność, czyniąc wybór środowiska wykonawczego jawnym, lecz każdy backend ma inny profil możliwości i synchronizacji.

Backend powłoki Worker to najlżejsza ścieżka dla znanych poleceń. Korzysta z just-bash, implementacji TypeScript środowiska podobnego do Bash, zaprojektowanej do działania bez uruchamiania procesów systemu operacyjnego.

Ten backend może obsługiwać zorientowaną na tekst pracę w powłoce względem trwałej przestrzeni roboczej. Nie potrzebuje Dockera ani Cloudflare Container. Operacje na plikach wracają do Durable Object, utrzymując autorytatywny stan w jednym miejscu.

Backend Worker JavaScript obsługuje moduły ECMAScript zamiast poleceń powłoki. Każde wykonanie działa wewnątrz nowego Dynamic Worker i może przyjmować dane strukturalne lub zwracać wyniki strukturalne. Obsługuje dostęp do plików oparty na przestrzeni roboczej oraz skonfigurowane biblioteki.

Cloudflare zapewnia również zaufane moduły dla Git i Cloudflare Artifacts. Operacje Git mogą działać przez klienta isomorphic-git bezpośrednio na wirtualnym systemie plików. Nie wymagają kontenera ani konwencjonalnego binarnego programu Git.

Backend kontenerowy obejmuje zadania, których izolaty nie mogą obsłużyć. Zapewnia Linux, natywne binaria, Node.js, npm, sieć i inne możliwości systemu operacyjnego. Przestrzeń robocza jest w nim dostępna przez punkt montowania FUSE computerd.

Ten backend tworzy najtrudniejszy problem dotyczący danych. Cloudflare musi odwzorować stan oparty na SQLite w kontenerze, pozwolić konwencjonalnym narzędziom go modyfikować, a następnie zsynchronizować te zmiany. Pakiet utrzymuje niezależne kursory synchronizacji dla każdego zarejestrowanego backendu.

Jeśli polecenie powiedzie się, ale pobranie po jego wykonaniu zakończy się niepowodzeniem, wynik wykonania może zgłosić oczekujący stan synchronizacji. Aplikacje mogą konfigurować ponowne próby z ograniczonym wykładniczym opóźnieniem. Biblioteka nie przejmuje jednak odpowiedzialności za planowanie alarmów Durable Object.

Ten szczegół pokazuje, jak wiele odpowiedzialności nadal spoczywa na deweloperze. Użytkownik widzi jedną przestrzeń roboczą, ale aplikacja musi obsłużyć rejestrację backendów, planowanie ponownych prób, cykl życia wykonania i nierozwiązaną synchronizację.

Projekt wymaga również zdyscyplinowanego zwalniania zasobów. Warstwa RPC nie zbiera automatycznie zdalnych stubów. Długotrwałe sesje, które wielokrotnie uzyskują uchwyty przestrzeni roboczej lub wykonania, mogą je gromadzić, jeśli aplikacja nie zwalnia każdego uchwytu.

Cloudflare dokumentuje obsługę debugowania umożliwiającą wykrywanie takich wycieków. Nadal jest to jednak infrastruktura z okresu preview, a nie niewidoczna usługa platformowa. Deweloperzy eksperymentujący z nią muszą rozumieć jej mechanizmy.

Publikowanie plików wprowadza kolejną granicę. Pakiet może przesłać plik z przestrzeni roboczej do R2 i zwrócić podpisany wcześniej link. Może również połączyć sesję z Cloudflare Artifacts, zgodną z Git usługą przechowywania kodu i wyników kompilacji.

Jeden z dołączonych samouczków pokazuje zamierzony podział. Agent zapisuje w swojej przestrzeni roboczej kartę przepisu w Markdown, a następnie używa pandoc w kontenerze do utworzenia PDF-a. Pamięć trwała pozostaje oddzielona, podczas gdy narzędzie Linux obsługuje konwersję formatu.

Inny przykład wysyła generowanie obrazów do Workers AI, zapisuje wynik w przestrzeni roboczej i zwraca zasób, który można udostępnić. Interfejs porównawczy uruchamia to samo zadanie równolegle w środowiskach kontenera i Worker.

Przykłady wskazują na szerszy wzorzec dla agentów. Przestrzeń robocza staje się wspólnym stanowiskiem pracy, a różne środowiska wykonawcze działają jak wyspecjalizowane narzędzia. Agent nie musi traktować każdego backendu jak osobnego komputera.

Mechanizm może także wspierać rozwój wymagający intensywnego korzystania z wiedzy. Zespół inżynierski może przechowywać w przestrzeni roboczej pliki zadań, wygenerowane raporty i wyniki testów, a następnie kopiować trwałe rezultaty do przeszukiwalnej bazy wiedzy. Środowisko wykonawcze pozostaje tymczasowe, podczas gdy przydatna praca staje się dostępna poza sesją agenta.

Abstrakcja ma jednak ograniczenia. System plików po stronie kontenera jest przechowywany w pamięci, a Cloudflare zaleca przestrzenie robocze o rozmiarze odpowiednim dla agentów, a nie pełne monorepozytoria. Limit około 10 GB jest znaczący dla dokumentów i małych projektów, ale nie czyni tej usługi uniwersalnym zamiennikiem dysków deweloperskich.

Backendy Worker wymagają również eksperymentalnych funkcji Cloudflare i powiązania Worker Loader. Sam pakiet wymaga flagi kompatybilności nodejs_compat. Wymagania te potwierdzają jego status preview.

Najważniejsza kwestia w tej analizie wyjaśniającej Cloudflare Computer nie polega na tym, że izolaty zastępują kontenery. Nie zastępują. Mechanizm pozwala aplikacji zdecydować, kiedy kontener jest wart kosztów uruchomienia, możliwości i synchronizacji.

Wybór ten może następować w warstwie aplikacji albo za pośrednictwem frameworka agenta. Model widzi opisy backendów i może wybrać miejsce docelowe. Deweloperzy potrzebują więc mechanizmów kontroli polityk, a nie tylko wskazówek w języku naturalnym.

System produkcyjny prawdopodobnie ograniczałby dostęp każdego backendu do określonych poleceń, plików, sieci i poświadczeń. Potrzebowałby też wiarygodnych zapisów wskazujących, dlaczego polecenie trafiło do konkretnego środowiska wykonawczego. Obecne repozytorium udostępnia hooki obserwowalności, ale nie rozwiązuje pełnego problemu zarządzania.

Cloudflare Computer jest najbardziej przekonujący, gdy praca naturalnie dzieli się na etapy. Wyszukiwanie i edycja w izolacie, kompilacja w Linuxie, a następnie publikacja przez usługę artefaktów. Jego przewaga staje się mniej wyraźna, gdy każda akcja wymaga kontenera lub gdy zadanie wielokrotnie przenosi duże pliki.

Ostrzeżenia dotyczące preview i benchmarki komplikują przekaz

Repozytorium przedstawia wyjątkowo bezpośrednie ograniczenia, w tym wyraźne ostrzeżenie dotyczące produkcji oraz benchmarki pokazujące dużą karę za duże sekwencyjne operacje na plikach.

Cloudflare twierdzi, że pakiet nadaje się do eksperymentów, eksploracji i prototypów. Informuje, że API są niestabilne, projekt może się zmienić, a pakiet nie nadaje się do użytku produkcyjnego.

To ostrzeżenie powinno stanowić kontekst dla każdego twierdzenia o tym, czym Cloudflare Computer jest dzisiaj. Repozytorium zawiera działające pakiety, przykłady i setki commitów, lecz części jego dokumentacji projektowej wybiegają w przyszłość. Cloudflare zaleca czytelnikom traktować te specyfikacje jako deklarację intencji, a nie opis obecnego kodu.

Wydajność jest najczytelniejszym kompromisem. Firma przeprowadziła benchmark computerd na standardowym kontenerze z jednym wirtualnym CPU, 6 GiB pamięci i 12 GB dysku. Porównała przestrzeń roboczą FUSE z systemem plików w pamięci oraz dyskiem ext4 kontenera.

Wyniki faworyzują wirtualny system plików w przypadku kilku operacji intensywnie korzystających z metadanych. Usunięcie 1 000 plików zajęło około dwóch trzecich czasu ext4. Utworzenie zagnieżdżonego drzewa katalogów zajęło mniej więcej trzy czwarte tego czasu. Odnalezienie tego drzewa również zajęło około trzech czwartych.

Inicjalizacja Git i commit obejmujący 100 plików zajęły 459,2 milisekundy w computerd, w porównaniu z 635,4 milisekundy w ext4. Płytkie sklonowanie repozytorium o rozmiarze około 1 MB zajęło 549,1 milisekundy, wobec 576,2 milisekundy na dysku.

Duże operacje sekwencyjne przyniosły odwrotny rezultat. Zapis pliku o rozmiarze 64 MiB zajął 230,6 milisekundy w computerd, wobec 16,8 milisekundy w ext4. Skopiowanie tej samej ilości danych zajęło 1 037,2 milisekundy, wobec 39,8 milisekundy.

Czysty odczyt 64 MiB był około 30 razy wolniejszy niż bazowy wynik dla dysku. Czyste kopiowanie było ponad 41 razy wolniejsze. Te różnice mają znaczenie dla archiwów, drzew zależności, multimediów, plików modeli i obciążeń przetwarzania danych.

Benchmarki systemu plików Cloudflare wyjaśniają mechanizm stojący za spowolnieniem. Ścieżka zapisu haszuje fragmenty o wielkości 512 KiB do adresowanego zawartością magazynu blobów. Wspiera to deduplikację i synchronizowanie wyłącznie zmienionych fragmentów, ale zwiększa nakład pracy przy operacjach wymagających surowej przepustowości.

Pełna instalacja Sandbox SDK Cloudflare jeszcze wyraźniej pokazała ten koszt. Test objął 854 pakiety i 36 675 plików. Instalacja trwała 124,7 sekundy w przestrzeni roboczej FUSE, 63,9 sekundy w ext4 i 34,3 sekundy w pamięci.

Cloudflare określa ext4 jako bardziej realistyczny punkt odniesienia dla ogólnego użycia. Wobec tego punktu odniesienia instalacja FUSE trwała mniej więcej dwa razy dłużej. Deweloperzy tworzący projekty JavaScript z dużą liczbą zależności zauważą tę różnicę.

Benchmarki nie podważają projektu. Wiele zadań agentów obejmuje metadane, drobne edycje, wyszukiwanie i zmiany przyrostowe, a nie ciągłe sekwencyjne I/O. Wyniki określają raczej, gdzie routing backendów ma znaczenie.

Rozsądny przepływ pracy może przechowywać pliki źródłowe w trwałej przestrzeni roboczej, unikając jednocześnie wielokrotnego rozpakowywania dużych archiwów. Może buforować zależności gdzie indziej albo wybierać zadania, których wartość przewyższa narzut synchronizacji. Cloudflare nie ustaliło jeszcze najlepszych wzorców produkcyjnych.

Bezpieczeństwo stanowi drugą niewiadomą. Repozytorium opisuje powierzchnie wykonawcze i zachowanie pamięci masowej, lecz nie twierdzi, że wszystkie trzy backendy zapewniają identyczną izolację. Izolat JavaScript, powłoka zaimplementowana w TypeScript i kontener Linux to zasadniczo różne środowiska wykonawcze.

Powłoka Worker zyskuje szybkość częściowo dlatego, że nie jest pełnym systemem operacyjnym. Ogranicza to jej kompatybilność, ale może również zawężać możliwości poleceń. Kontener zapewnia szersze możliwości i dlatego wymaga silniejszych mechanizmów kontroli dostępu do sieci, pakietów i poświadczeń.

Przechodzenie między tymi środowiskami może tworzyć luki w politykach. Polecenie odrzucone w jednym backendzie może uruchomić się w innym. Agent może wybrać Linux, ponieważ jego opis obiecuje większe możliwości, nawet gdy zadanie ich nie wymaga.

Pakiet zawiera hooki obserwatora dla połączenia z przestrzenią roboczą, synchronizacji, wykonywania i operacji na systemie plików. Hooki te mogą zasilać śledzenie Cloudflare lub inny rejestrator. To przydatne podstawy, ale użytkownicy produkcyjni będą potrzebować reguł autoryzacji oraz możliwej do audytowania polityki wyboru backendu.

Trwałość rodzi własne pytania dotyczące bezpieczeństwa. Pliki przetrwają restarty Durable Object, co jest funkcją potrzebną agentom do długich zadań. Trwałe przestrzenie robocze mogą także przechowywać wrażliwe prompty, kod źródłowy, wygenerowane poświadczenia lub pobrane dane dłużej, niż zamierzano.

Aplikacje potrzebują zasad usuwania i separacji tenantów dopasowanych do poziomu ryzyka. Montowania R2 w trybie tylko do odczytu pomagają chronić dane referencyjne, ale nie odpowiadają na wszystkie pytania dotyczące retencji danych ani dostępu wychodzącego.

Odbiór na GitHubie jest sygnałem zainteresowania wdrożeniem, a nie dowodem gotowości produkcyjnej. Repozytorium wyświetlało około 3 100 gwiazdek i 141 forków 6 sierpnia. Liczby te pokazują ciekawość deweloperów po ogłoszeniu, zwłaszcza biorąc pod uwagę jego pozycję w GitHub Trending.

Nie dowodzą one niezawodności, bezpieczeństwa ani trwałego użytkowania. Gwiazdki mogą szybko gromadzić się wokół atrakcyjnej architektury. Rzeczywista walidacja nadejdzie wraz z obciążeniami działającymi przez tygodnie, odzyskującymi sprawność po częściowych awariach i konsekwentnie zachowującymi pliki mimo zmian środowiska wykonawczego.

Transparentność Cloudflare pomaga w tym przypadku. Publikowanie niekorzystnych wyników I/O daje deweloperom lepszą podstawę do eksperymentów. Wyraźne ostrzeżenie zapobiega również myleniu wysokiej pozycji w rankingach z premierą ogólnej dostępności.

Ostrożny wniosek jest prosty. Cloudflare Computer oferuje wiarygodny mechanizm oddzielania stanu agenta od wykonywania, ale preview nie dowiodło jeszcze, że dodatkowa koordynacja przewyższa dedykowany sandbox w środowisku produkcyjnym.

Co deweloperzy powinni obserwować po wzroście zainteresowania na GitHubie

Kolejna faza zależy od trzech sygnałów: stabilizacji API, dowodów z rzeczywistych obciążeń oraz egzekwowalnych polityk wyboru backendu.

Pierwszym sygnałem jest wersjonowane wydanie ukierunkowane na produkcję. Cloudflare Computer obecnie oferuje niestabilne API i eksperymentalne wymagania dotyczące backendów. Przejście w stronę stabilnego interfejsu pokazałoby, że Cloudflare rozwiązało granice odpowiedzialności między Computer, Sandbox SDK, Dynamic Workers i Durable Objects.

To wydanie powinno wyjaśnić zachowanie podczas odzyskiwania po awarii. Deweloperzy potrzebują przewidywalnych rezultatów, gdy polecenie w kontenerze kończy się, ale synchronizacja zawodzi. Potrzebują również gwarancji dotyczących współbieżnego dostępu, czyszczenia, limitów pamięci masowej i długo działających sesji RPC.

Jeśli Cloudflare opublikuje stabilne wydanie z wytycznymi migracyjnymi, argument architektoniczny stanie się silniejszy. Jeśli API będą często się zmieniać lub pakiet pozostanie eksperymentem, zespoły nadal będą traktować repozytorium jako badanie projektowe.

Drugim sygnałem są dowody pochodzące z kompletnych obciążeń agentów. Mikrobenchmarki już pokazują, gdzie FUSE działa dobrze, a gdzie ma trudności. Trudniejsze pytanie brzmi, czy routing poleceń między izolatami i kontenerami poprawia całkowity czas realizacji zadania, niezawodność lub wykorzystanie zasobów.

Przydatne oceny porównywałyby identycznych agentów programistycznych, badawczych i analitycznych. Powinny mierzyć opóźnienie uruchomienia, czas wykonania, awarie synchronizacji, ilość przesłanych danych oraz pomyślne ukończenie zadań. Surowy benchmark systemu plików nie może uchwycić tych połączonych efektów.

Przykłady w repozytorium są punktem wyjścia, zwłaszcza interfejs porównujący środowiska wykonawcze przy tym samym zadaniu. Niezależne testy powinny objąć większe repozytoria, powtarzane instalacje pakietów, równoległych agentów oraz sesje wznawiane po przerwaniach.

Jeśli przepływy pracy wykorzystujące mieszane środowiska wykonawcze będą niezawodnie kończyć się przy użyciu mniejszej liczby kontenerów, mechanizm Cloudflare zyska potwierdzenie. Jeśli synchronizacja i routing zniwelują te oszczędności, trwały sandbox pozostanie prostszym wyborem.

Trzecim sygnałem jest polityka backendu. Obecnie aplikacja może opisać dostępne backendy i pozwolić agentowi wybrać jeden z nich. Nabywcy rozwiązań produkcyjnych będą oczekiwać deterministycznych mechanizmów kontroli określających, który backend może uzyskać dostęp do każdego pliku, sieci, sekretu i polecenia.

Cloudflare ma już powiązaną infrastrukturę. Jego platforma Sandbox obejmuje programowalne mechanizmy kontroli ruchu wychodzącego, podczas gdy Durable Objects zapewniają prywatny, trwały stan. Cloudflare Computer musi połączyć te elementy w model polityk, który deweloperzy będą mogli zrozumieć.

Dojrzała implementacja powinna uwidaczniać eskalację. Gdy agent przechodzi z powłoki Worker do Linuxa, aplikacja powinna wiedzieć dlaczego, jakie nowe możliwości stały się dostępne oraz jakie dane przekroczyły granicę.

To pytanie wykracza poza Cloudflare. LangChain, Daytona, Ona, Modal i inne platformy rozwijają środowiska dla agentów, łącząc w różny sposób microVM, kontenery, trwałość danych i narzędzia dla deweloperów. Ich konkurencja dotyczy definicji komputera agenta, a nie tylko szybkości wykonywania.

Niektórzy dostawcy twierdzą, że niezaufany kod agentów wymaga izolacji na poziomie sprzętowym i pełnej granicy maszyny. Cloudflare Computer koncentruje się natomiast na dekompozycji, pozwalając przestrzeni roboczej korzystać z lżejszego wykonywania zadań, dopóki nie potrzebuje Linuxa. Te podejścia mogą współistnieć, ponieważ potrzeby w zakresie izolacji różnią się w zależności od zadania.

Korporacyjne agenty programistyczne mogą nadal preferować dedykowane środowiska z odtwarzalnymi łańcuchami narzędzi i ścisłymi granicami między tenantami. Agenty przetwarzające duże ilości dokumentów mogą bardziej skorzystać z trwałych plików i lekkich poleceń. Agenty danych obsługujące duże wejścia mogą ujawnić ograniczenia przepustowości projektu FUSE.

Deweloperzy powinni więc przetestować swój zestaw zadań przed wdrożeniem tej koncepcji. Należy policzyć, ile kroków rzeczywiście wymaga natywnych binariów. Zmierzyć, ile danych przepływa przez przestrzeń roboczą. Celowo wywołać błędy synchronizacji i potwierdzić odzyskiwanie po awarii.

Powinni również oddzielić atrakcyjne doświadczenie pracy z agentem od odpowiedniego projektu bezpieczeństwa. „Jedna przestrzeń robocza” to użyteczny interfejs, ale nie oznacza, że każda ścieżka wykonania ma tę samą granicę zaufania. Eskalacja środowiska uruchomieniowego zasługuje na taką samą kontrolę jak eskalacja uprawnień.

Cloudflare Computer ma znaczenie, ponieważ wyraźnie przedstawia ten wybór projektowy. Zachęca deweloperów, by traktowali pliki jako trwały stan, wykonywanie jako wybieralną usługę, a pozorny komputer jako abstrakcję składaną dla każdego zadania.

To ujęcie wpłynie na infrastrukturę agentów, nawet jeśli ten podgląd znacząco się zmieni. Oferuje alternatywę dla utrzymywania jednego kontenera lub microVM przy życiu tylko dlatego, że agent później potrzebuje jego plików.

Wzrost zainteresowania na GitHubie potwierdza zainteresowanie tym pomysłem. Nie rozstrzyga jednak, czy deweloperzy wolą operacyjną prostotę jednej maszyny, czy wydajność obiecywaną przez kilka środowisk uruchomieniowych współdzielących jedną przestrzeń roboczą.

W ciągu najbliższych kilku miesięcy warto obserwować repozytorium, a nie liczbę gwiazdek. Stabilne API, kompleksowe benchmarki i rygorystyczne polityki backendu zadecydują, czy Cloudflare Computer stanie się infrastrukturą produkcyjną, czy pozostanie przekonującym podglądem.

Zespoły oceniające podgląd cloudflare computer powinny zacząć od ograniczonego obciążenia, udokumentować każde przejście między środowiskami uruchomieniowymi i przetestować odzyskiwanie przed zaufaniem trwałemu stanowi. Które operacje naprawdę potrzebują Linuxa, a którym wystarczą pliki i niewielka powierzchnia wykonywania? Odpowiedź na to pytanie oparta na śladach i testach awarii pokaże, czy model hybrydowy pasuje do waszych agentów. Ujawni też, gdzie konwencjonalny sandbox pozostaje łatwiejszy do zabezpieczenia i obsługi. Szersza lekcja jest już użyteczna: komputer agenta nie musi być jedną maszyną działającą nieprzerwanie. Podział go na usługi przenosi jednak złożoność do routingu, synchronizacji i polityk. Traktujcie te mechanizmy jako podstawową infrastrukturę, a nie szczegóły implementacyjne.