《Architektura piaskownicy Openclaw: od wyboru technologii do opowieści o bezpieczeństwie, którą zrozumie każdy》 Dwa tryby Wyobraź sobie, że chcesz zatrudnić ochroniarza, który będzie pilnował twojego domu. Masz dwa wybory: Opcja pierwsza: Ochroniarz mieszka w twoim domu, ale narzędzia ma zamknięte w sejfie. Ochroniarz może się poruszać, widzi twój dom, ale nie ma klucza. Opcja druga: Ochroniarz mieszka w budce na zewnątrz, w twoim domu nie ma nic, co mógłby wziąć. Jeśli chce cokolwiek wziąć, musi poprosić twojego lokaja. Firma Browser Use (która obsługuje miliony agentów internetowych) wybrała opcję drugą. Ich historia tak naprawdę dotyczy każdego, kto korzysta z AI.

II. Jak korzystać z przeglądarki Początkowo używali rozwiązania pierwszego: Agent działał na własnym serwerze, a wykonanie kodu odbywało się w izolowanym piaskownicy. Brzmi dość bezpiecznie, prawda? Ale jest jeden problem: Agent sam w sobie jest na serwerze, może zobaczyć zmienne środowiskowe, klucze API, poświadczenia bazy danych. Co jeśli Agent zdecyduje się "ukraść coś"?

Trzy, więc przepisali całą architekturę: • Agent całkowicie izolowany: każdy Agent działa w swoim własnym Unikraft micro-VM, uruchomienie zajmuje mniej niż sekundę • Kontrolny panel jako zarządca: wszelka komunikacja zewnętrzna (wywołanie LLM, przechowywanie plików, rozliczenia) przechodzi przez kontrolny panel, który posiada wszystkie poświadczenia • Piaskownica nic nie wie: Agent otrzymuje tylko trzy zmienne środowiskowe — token sesji, URL kontrolnego panelu, ID sesji. Brak kluczy AWS, brak poświadczeń bazy danych • Możliwość porzucenia: Agent umarł? Uruchom nowego. Stan zniknął? Kontrolny panel ma pełny kontekst. Nie ma nic, co warto by ukraść, ani nic, co trzeba by zachować.

Cztery, Szczegóły techniczne: Unikraft micro-VM do produkcji (skala do zera, wstrzymanie w czasie bezczynności), kontenery Docker do rozwoju. Ten sam obraz wszędzie. Perspektywa zwykłego człowieka: Co to ma ze mną wspólnego? Możesz nie wiedzieć, czym jest "micro-VM" lub "presigned URLs", ale gdy korzystasz z AI, masz do czynienia z taką architekturą.

Pięć, Poczucie bezpieczeństwa: Kiedy korzystasz z jakiejś usługi AI do pisania kodu lub wyszukiwania informacji, twoje zapytania są w rzeczywistości przetwarzane w izolowanej maszynie wirtualnej. Jeśli architektura jest źle zaprojektowana (wariant pierwszy), teoretycznie ten agent AI może zobaczyć wszystkie sekrety dostawcy usługi — hasła do bazy danych, klucze API, dane innych użytkowników.

Sześć, Koszt i prędkość: Opcja druga ma swoją cenę — każda operacja wymaga dodatkowego skoku w sieci. Ale w porównaniu do czasu odpowiedzi LLM, to opóźnienie jest prawie nieistotne. Co ważniejsze, gdy Agent jest bezczynny, VM jest wstrzymywany, a koszt jest bliski zeru. Prywatność danych: Jak przechowujesz swoje pliki? Sandbox prosi kontrolny interfejs o presigned URL, a następnie bezpośrednio przesyła do S3. Cały proces sandbox nie widział kluczy AWS. Twoje dane nie będą ujawnione Agentowi.

Siedem, Moje przemyślenia: lokalnie vs w chmurze Moje obecne ustawienie (OpenClaw + LM Studio + x-reader) to typowy "tryb offline": • model działa lokalnie (Qwen3.5-35B na RTX 3090) • Agent nie jest izolowany (bo jest na twoim komputerze) • dane są całkowicie lokalne To w porównaniu do rozwiązania z użyciem przeglądarki: Wymiary Lokalny pojedynczy Agent (my) Izolowany Agent w chmurze (użycie przeglądarki) Prywatność Dane nie opuszczają lokalizacji Dane w chmurze, ale Agent nie ma dostępu do kluczy Bezpieczeństwo Zależność od lokalnej ochrony Agent całkowicie izolowany, nie ma możliwości kradzieży Koszt Jednorazowa inwestycja w sprzęt Płatność za użycie (skala do zera) Skalowalność Ograniczona przez lokalny sprzęt Nieskończona skalowalność, wiele Agentów równolegle Opóźnienie Brak opóźnienia sieciowego Jedno dodatkowe skok sieciowy (ale można to zignorować)

Osiem, Moja ocena: w przyszłości będzie to model hybrydowy. • Proste zadania lokalnie: napisanie skryptu, wyszukiwanie informacji, porządkowanie dokumentów - to wszystko można załatwić lokalnie, co zapewnia prywatność i szybkość. • Złożone zadania w chmurze: wymagające równoległego działania wielu Agentów, przetwarzania dużych ilości danych, długotrwałego działania - w takim przypadku bardziej odpowiednia jest architektura typu Browser Use.

Dziewiąte, Z początku nie ma nic, skąd więc kurz? Twój Agent nie powinien mieć niczego, co warto by ukraść, ani żadnego stanu, który trzeba by zachować. Innymi słowy: • Nie warto kraść: Agent nie zna żadnych tajemnic. Potrzebuje tokenów do LLM? Daje je kontrola, używa i wyrzuca. Musi przechować plik? presigned URL jest tymczasowy, po wygaśnięciu traci ważność. • Nie trzeba zachować: Agent umarł? Uruchom nowego. Pamięta kontekst? W bazie danych kontrolnej są pełne zapisy. To w rzeczywistości zastosowanie architektury zero zaufania w erze AI: nie ufaj żadnemu komponentowi, nawet jeśli to twój własny Agent.

Dziesięć. Jak powinien uczyć się początkujący w AI? 1. Wybór narzędzi AI: korzystając z chmurowych usług AI, zapytaj siebie - co się stanie, jeśli ten Agent wymknie się spod kontroli? Dobra architektura powinna sprawić, że będzie "nic nie wiedział". 2. Świadomość prywatności: lokalne AI wykonujące proste zadania (OpenClaw, LM Studio), wrażliwe dane nie powinny trafiać do chmury. Złożone zadania powinny korzystać z chmurowych rozwiązań izolacyjnych, ale należy pamiętać, że dane opuszczą lokalizację. 3. Przyszłe przepływy pracy: współpraca jednej osoby z wieloma Agentami to trend (Karpathy mówił o Tab→Agent→Równoległych Agentach→Zespołach Agentów). Ale każdy Agent powinien być izolowany, nie powinien "mieszkać w twoim domu".

Jedenaście, Równowaga między bezpieczeństwem a wydajnością Rozwiązanie Browser Use nie jest doskonałe — wymaga wdrożenia trzech dodatkowych usług, a każda operacja wiąże się z dodatkowym skokiem sieciowym. Ale w porównaniu do ryzyka, że "Agent ukradnie wszystkie klucze", te koszty są warte poniesienia. Dla nas, osób korzystających z lokalnego setupu AI, wnioski są następujące: • Proste scenariusze: kontynuować korzystanie z lokalnego rozwiązania (OpenClaw + LM Studio), dobre dla prywatności, niskie koszty • Złożone scenariusze: w przyszłości może być konieczne połączenie z chmurową usługą izolacji Agenta, aby profesjonaliści mogli zająć się profesjonalnymi sprawami Bezpieczeństwo AI to nie ezoteryka, to projektowanie architektury. Dobrze zaprojektowana architektura sprawia, że Agent "nie ma nic" — nie ma sekretów do kradzieży, nie ma stanu do oszukiwania.

Dwanaście, To mniej więcej tak będzie wyglądać przyszła infrastruktura AI: Agent jest jednorazowy, płaszczyzna kontrolna jest zaufana, a dane użytkowników są chronione. A co z nami? Kontynuujemy uruchamianie lokalnego Agenta za pomocą OpenClaw, a gdy przyjdzie czas na równoległe uruchamianie dziesiątek lub setek, wtedy rozważymy podłączenie do architektury Browser Use. Jutro będzie lepsze