Cloudflare OS: przestrzeń pracy agentów, nie system na laptop

Cloudflare OS jest eksperymentalną przestrzenią pracy, w której agent tworzy dokumenty i małe aplikacje korzystające z kontekstu firmy. Mimo nazwy nie jest dystrybucją Linuksa. Repozytorium Cloudflare OS opisuje trzy ważne elementy: interfejs rozmowy z agentem, tworzone na żądanie aplikacje Gadgets oraz Gatekeepers kontrolujące połączenia z usługami zewnętrznymi.

Co oznacza „OS” w tym projekcie?

Analogia do systemu operacyjnego dotyczy środowiska uruchamiania: użytkownik może utworzyć własny „dokument-aplikację”, udostępnić go zespołowi i dać agentowi narzędzia do pracy. Blueprints pełnią rolę szablonów takich aplikacji. Kod jest zbudowany na Cloudflare Workers i Durable Objects, a projekt pokazuje także lokalny tryb uruchomienia. To inne zadanie niż Omarchy na pulpicie programisty.

Gatekeeper jako granica między pomysłem a skutkiem

Agent może poprosić o wysłanie wiadomości lub zmianę rekordu. Gatekeeper udostępnia wąski interfejs do konkretnej usługi, obsługuje autoryzację, rejestruje działanie i daje człowiekowi możliwość zatwierdzenia operacji ze skutkiem ubocznym. Opis mechanizmu przedstawia również symulowanie wyniku, dzięki któremu agent może kontynuować plan, zanim człowiek zdecyduje o wykonaniu. To ciekawy kompromis między autonomią a kontrolą, ale wymaga jasnego rozróżnienia: symulacja nie jest rzeczywistym zapisem w systemie źródłowym. Wszystkie zależne kroki trzeba pogodzić po zatwierdzeniu lub odrzuceniu.

Co sprawdzić przed użyciem w firmie?

Repozytorium oznacza projekt jako rozwijany we wczesnym etapie. Publiczny kod i uruchomienie lokalne ułatwiają audyt, lecz nie są obietnicą gotowej produkcyjnej instalacji we własnym centrum danych. Oceń model uprawnień, izolację kodu Gadgets, dziennik audytu, odtwarzanie danych i sposób aktualizacji Gatekeeperów. Przetestuj scenariusz odmowy zatwierdzenia oraz awarii usługi zewnętrznej. Istotna jest też lokalizacja danych i modeli: suwerenność wymaga decyzji o całej ścieżce, nie tylko o licencji repozytorium.

Cloudflare OS jest dobrym materiałem do pilota interfejsu agentów i kontrolowanego wykonywania akcji. Na produkcyjne zobowiązania patrzyłbym przez pryzmat zasad bezpieczeństwa i utrzymania AI, z osobnym testem każdej integracji.

Scenariusz testowy: zatwierdź lub odrzuć

Niech agent przygotuje Gadget analizujący zgłoszenia i proponujący wiadomości do klientów. Gatekeeper powinien dać mu dostęp tylko do wskazanego zbioru zgłoszeń oraz funkcji przygotowania wiadomości. Następnie przetestuj dwie gałęzie: operator zatwierdza jedną wysyłkę, odrzuca drugą. Sprawdź, czy kolejny krok agenta rozróżnia wykonane i jedynie symulowane działania, czy odmowa nie pozostawia pozornego stanu oraz czy audyt pokazuje osobę zatwierdzającą.

W tym modelu dobrze widać różnicę między uprawnieniem do odczytu a uprawnieniem do skutku. Agent może potrzebować całego kontekstu zgłoszenia, aby sporządzić propozycję, lecz nie musi mieć możliwości rozsyłania wiadomości do dowolnego adresata. Gatekeeper powinien przyjmować identyfikator konkretnego zasobu, a nie szeroki token otwierający całe konto. Jeżeli aplikacja może zbudować własny interfejs do usługi z pominięciem Gatekeepera, cała obietnica kontroli traci sens — właśnie ten przypadek trzeba próbować wykryć w teście bezpieczeństwa.

Porównując Cloudflare OS z własnym portalem agentów, policz nie tylko czas zbudowania pierwszej aplikacji. Uwzględnij utrzymanie konektorów, obsługę sporów o dostęp, kopie danych Gadgets i zależność od środowiska Workers. Otwarty kod pomaga przenieść logikę, ale konfiguracja hostingu i dostępność usług nadal wyznaczają realny zakres niezależności. Dla pilota przydatna jest lista operacji niedozwolonych oraz próba przywrócenia działania po awarii jednej integracji.