OpenClaw Gateway

Cześć, tu Alex z DEV STORIES DOT EU. OpenClaw Gateway, odcinek 1 z 11. Jesteś z dala od biurka, ale potrzebujesz szybkiego code review. Wysyłasz wiadomość z telefonu, a kilka sekund później wraca do ciebie szczegółowa analiza, wygenerowana w całości przez prywatny serwer działający na twojej lokalnej maszynie. Architektura Personal AI Gateway to coś, co w ogóle umożliwia taki całkowicie self-hosted setup. Większość chatbotów AI przepycha twoje prywatne dane przez zewnętrzną warstwę orkiestracji. Jeśli chcesz połączyć komunikator z modelem językowym, zazwyczaj polegasz na usłudze w chmurze, która skleja ze sobą API. To ujawnia twoje prywatne zapytania i wprowadza opóźnienia. Architektura OpenClaw Gateway eliminuje usługę pośredniczącą, uruchamiając wszystko w ramach jednego procesu self-hosted. Ten proces działa jak dedykowany most. Znajduje się bezpośrednio między twoimi codziennymi komunikatorami a wybranym przez ciebie AI runtime. Prześledźmy dokładną ścieżkę wiadomości, aby zobaczyć, jak przebiega logika. Wysyłasz code snippet z telefonu przez WhatsApp. Na twojej lokalnej maszynie proces gatewaya jest już uruchomiony. Utrzymuje stałe połączenia z twoimi komunikatorami za pomocą konkretnych bibliotek. W przypadku WhatsAppa, gateway używa biblioteki Baileys do zarządzania bezpośrednim połączeniem socketowym. W przypadku Telegrama opiera się na frameworku grammY. Kiedy twoja wiadomość trafia na lokalny serwer, dociera opakowana w strukturę danych specyficzną dla danego protokołu. Event z WhatsAppa ma zupełnie inny kształt payloadu niż event z Telegrama. Gateway natychmiast parsuje te przychodzące wiadomości. Usuwa specyficzne dla platformy wrappery, wyciąga surowy tekst i identyfikator nadawcy, a następnie pakuje je w ustandaryzowany obiekt wewnętrzny. Oto kluczowa kwestia. Zanim twoja wiadomość dotrze do AI runtime, silnik nie wie, skąd pochodzi tekst. Runtime działa całkowicie niezależnie od Baileys czy grammY. Widzi jedynie czysty, jednolity request. AI przetwarza twój code snippet, generuje review i przekazuje odpowiedź w postaci zwykłego tekstu z powrotem do gatewaya. Następnie gateway odwraca ten przepływ. Sprawdza znacznik pochodzenia dołączony do początkowego requestu. Jeśli zadałeś pytanie przez WhatsApp, gateway formatuje odpowiedź AI do struktury kompatybilnej z Baileys i wypycha ją przez socket bezpośrednio na twój telefon. Jeśli request przyszedł z Telegrama, używa grammY do wysłania odpowiedzi. Utrzymanie tego wszystkiego w ramach jednego procesu self-hosted drastycznie zmniejsza złożoność operacyjną. Nie musisz deployować wielu mikroserwisów, konfigurować kolejek wiadomości ani wystawiać lokalnych endpointów dla zewnętrznych webhooków tylko po to, żeby zrutować tekst. Jedna odizolowana aplikacja zarządza socketami sieciowymi, wykonuje logikę normalizacji i wywołuje silnik AI. Ponieważ gateway wewnętrznie ujednolica wiele kanałów, twój kontekst rozmowy pozostaje scentralizowany. Możesz zacząć troubleshooting buga na Telegramie podczas spaceru, a później zadać pytanie uzupełniające na WhatsAppie. Gateway dba o to, by AI runtime zachował pełną historię, niezależnie od tego, którą aplikację mobilną otworzysz. Największą zaletą tej architektury jest absolutna kontrola nad twoimi inputami i outputami w każdym interfejsie komunikatora, całkowicie na twoim własnym sprzęcie. Jeśli podoba ci się podcast i chcesz wesprzeć program, możesz wyszukać DevStoriesEU w serwisie Patreon. To wszystko w tym odcinku. Dzięki za słuchanie i kodujcie dalej!

Cześć, tu Alex z DEV STORIES DOT EU. OpenClaw Gateway, odcinek 2 z 11. Twój bot służbowy i bot asystenta osobistego nigdy nie powinny współdzielić pamięci, a jednak stawianie osobnej instancji serwera dla każdej nowej persony bota to koszmar operacyjny. Właśnie ten problem rozwiązuje Multi-Agent Routing. Słuchacze często mylą ten setup z architekturą multi-tenant SaaS. Wyjaśnijmy to od razu. Multi-Agent Routing nie jest przeznaczony do hostowania różnych botów dla tysięcy zewnętrznych klientów. Zamiast tego, służy do organizowania różnych person jednego właściciela, albo do łączenia konkretnych czatów grupowych ze specjalnie zbudowanymi botami, a wszystko to działa wydajnie pod jednym dachem. Aby to działało, system ściśle oddziela dwa pojęcia. Musisz zrozumieć różnicę między account ID a agent ID. Account ID to człowiek. To identyfikator osoby wysyłającej wiadomość. Agent ID to bot. Definiuje konkretną personę, model i instrukcje, z którymi komunikuje się człowiek. Pojedynczy człowiek z jednym account ID będzie rutynowo rozmawiał z wieloma różnymi agent ID w ciągu dnia. Na OpenClaw Gateway wielu odizolowanych agentów działa obok siebie. Nie współdzielisz między nimi stanów pamięci. Każde agent ID dostaje swój własny, dedykowany workspace i swój własny, odrębny session store. Kiedy wiadomość przychodząca trafia na Gateway, system musi dokładnie ustalić, który odizolowany workspace powinien ją odebrać. Robi to za pomocą reguł routingu znanych jako bindings. Bindings to deterministyczne mapowania. Analizują dokładne metadane dołączone do wiadomości przychodzącej i odpowiednio ją routują. Każda wiadomość przychodząca niesie ze sobą payload z danymi połączenia. Obejmuje to channel, taki jak WhatsApp czy Telegram. Zawiera account ID nadawcy. Może również zawierać peer identifier, który może wskazywać na konkretny pokój czatu grupowego. Konfigurujesz bindings, żeby analizowały te metadane. Na przykład, możesz utworzyć binding, który określa, że każda wiadomość przychodząca przez channel WhatsApp jest routowana bezpośrednio do szybkiego, codziennego agent ID. Ten agent obsługuje szybkie zadania, listy zakupów lub proste wyszukiwania w internecie. W tej samej konfiguracji ustawiasz kolejny binding, który mówi, że każda wiadomość przychodząca przez Telegram jest routowana do agent ID do cięższych zadań, korzystającego z większego modelu, takiego jak Opus, do zaawansowanego kodowania. Logika działania jest prosta. Gateway odbiera wiadomość z Telegramu. Odczytuje metadane channelu i twoje account ID. Sprawdza bindings, znajduje regułę pasującą do Telegramu i przekazuje payload do agent ID Opusa. Agent Opus budzi się w swoim odizolowanym workspace. Odpytuje swój własny, dedykowany session store, aby pobrać historię konwersacji. Nie ma absolutnie żadnego dostępu do listy zakupów, którą właśnie wysłałeś do agenta WhatsApp. Oto kluczowy wniosek. Multi-Agent Routing zamienia pojedynczy Gateway w deterministyczną centralę, wykorzystując metadane channelu i użytkownika, aby zagwarantować, że właściwa persona zawsze obsłuży właściwy request, bez ryzyka mieszania ich pamięci. Jak zawsze, dzięki za wysłuchanie. Do zobaczenia w następnym odcinku.

Cześć, tu Alex z DEV STORIES DOT EU. OpenClaw Gateway, odcinek 3 z 11. Chciałeś kiedyś dosłownie napisać duszę dla swojego AI, na przykład sprawić, by odpowiadało wyłącznie jako zrzędliwy kosmiczny homar? W OpenClaw osiągnięcie takiego poziomu kontroli nad postacią nie wymaga żadnego kodu. Wszystko odbywa się wyłącznie za pomocą zwykłego tekstu, co prowadzi nas do workspace'u agenta i system promptów. Agent w OpenClaw jest definiowany przez swój workspace. Ten workspace to po prostu katalog zawierający określony zestaw plików bootstrapowych w Markdownie. Zamiast zakopywać twój system prompt w logice aplikacji lub skomplikowanych polach bazy danych, OpenClaw wystawia główne instrukcje jako czytelne, wersjonowalne dokumenty. Kiedy aplikacja startuje, OpenClaw czyta te pliki, żeby zbudować monolityczny system prompt, który steruje dużym modelem językowym. Konstrukcja opiera się na czterech głównych dokumentach. Pierwszy to plik markdown agents. Ten dokument ustala główną tożsamość, podstawowe cele i ścisłe granice operacyjne agenta. Pomyśl o tym jak o podstawowym opisie stanowiska. Mówi modelowi, co ma osiągnąć i jakich tematów musi całkowicie unikać. Drugi dokument to plik markdown soul. To tutaj żyje osobowość, ton i styl konwersacji. To dokładnie tutaj instruujesz model, żeby zachowywał się jak zrzędliwy kosmiczny homar. Piszesz wprost instrukcje, każąc agentowi narzekać na lodowatą próżnię kosmosu, używać skorupiakowych metafor i zachowywać się tak, jakby był ogólnie zirytowany ludzkimi pytaniami. Izolując osobowość od głównej logiki, możesz podmienić ton swojego agenta bez ryzyka dla jego funkcjonalnej niezawodności. Trzeci komponent to plik markdown tools. Ten tekst wyjaśnia zewnętrzne możliwości dostępne dla agenta. Opisuje, jakie funkcje model może wywołać, wymagane parametry dla tych funkcji i jak logicznie interpretować wyniki. Wypełnia lukę między wewnętrznym rozumowaniem modelu a twoim faktycznym codebase'em. Ostatni dokument to plik markdown user. Ten plik wstrzykuje kontekst o osobie, która wchodzi w interakcję z agentem. Może przechowywać preferencje użytkownika, poziom jego umiejętności technicznych czy ograniczenia konta. Zapewnia to, że agent dostosowuje swoje odpowiedzi do konkretnego człowieka po drugiej stronie czatu, zamiast rzucać ogólnymi poradami. Oto kluczowa sprawa. OpenClaw bierze zawartość tych czterech plików i konkatenuje je ze sobą. Ten połączony string staje się ostatecznym system promptem. Kluczowy detal jest taki, że ten prompt jest wstrzykiwany do context window przy każdej pojedynczej turze konwersacji. Model nie czyta tych plików tylko raz przy starcie, żeby jakoś trzymać je w oddzielnym banku pamięci. Czyta cały skonkatenowany blok za każdym razem, gdy użytkownik wysyła nową wiadomość. Ten wybór architektoniczny dyktuje, jak musisz pisać pliki w swoim workspace. Ponieważ cały tekst z workspace'u jest doklejany na początku każdej pojedynczej interakcji, twój token count będzie agresywnie rósł. Jeśli napiszesz trzystronicową historię w pliku soul, płacisz koszt przetwarzania tych trzech stron za każdym razem, gdy użytkownik po prostu powie cześć. Co ważniejsze, duże system prompty zużywają dostępne limity context window. Rozdmuchany workspace wypycha właściwą historię konwersacji, sprawiając, że model znacznie szybciej zapomina wcześniejsze części czatu. Musisz być bezwzględny podczas edytowania dokumentów w swoim workspace. Usuwaj zbędne instrukcje. Używaj precyzyjnego języka. Jeśli jakaś reguła w pliku agents nigdy nie jest triggerowana, usuń ją. System prompt to nie jest jednorazowy krok konfiguracyjny. To powracający podatek nałożony na twoje context window i twój budżet API, płacony przy każdej pojedynczej turze konwersacji. Zadbaj, by był zwięzły, a twój agent pozostanie skupiony. Dzięki za wysłuchanie. Trzymajcie się wszyscy.

Cześć, tu Alex z DEV STORIES DOT EU. OpenClaw Gateway, odcinek 4 z 11. Robisz deploy nowego chatbota na swój firmowy workspace. Alice prosi go o podsumowanie jej prywatnych notatek ze spotkania, a pięć minut później bot przypadkowo cytuje te notatki Bobowi. Twój agent właśnie doprowadził do wycieku danych, ponieważ traktuje wszystkich na workspace jako dokładnie tę samą osobę. Żeby to naprawić, musisz zrozumieć Session Management i DM Isolation. Zanim naprawimy ten overlap, musimy rozwiać pewne powszechne nieporozumienie. Inżynierowie często mylą session keys z authentication tokens. To nie jest to samo. Session keys to nie są bariery bezpieczeństwa. To po prostu selektory routingu. Mówią systemowi OpenClaw, który blok historii konwersacji wyciągnąć z bazy danych i wstrzyknąć do prompta. Jeśli musisz ograniczyć to, kto może rozmawiać z twoim agentem, używasz odpowiedniej autentykacji. Session keys po prostu separują tekst. Każda interakcja z agentem OpenClaw odbywa się w ramach sesji. Sesja przechowuje historię konwersacji i aktywny, krótkoterminowy kontekst. Domyślnie OpenClaw routuje cały ruch przez jeden, współdzielony session key o nazwie main. Jeśli odpalasz lokalny skrypt w terminalu albo osobistego asystenta tylko dla siebie, to domyślne zachowanie sprawdza się idealnie. Cały twój kontekst zostaje w jednym, ciągłym wątku. Ale jeśli podepniesz dokładnie tego samego agenta do platformy multi-user, to domyślne ustawienie przestaje działać. Każdy użytkownik gadający z botem pisze do dokładnie tej samej historii main. Agent czyta prompt od Alice, generuje odpowiedź i ją zapisuje. Kiedy dziesięć sekund później Bob wysyła wiadomość, agent czyta input od Boba razem z poprzednim inputem od Alice. I tu robi się ciekawie. Zapobiegasz temu overlapowi, używając ustawień DM Isolation. Kiedy konfigurujesz integrację z platformą, zmieniasz strategię routingu sesji z domyślnej na per-channel-peer. Kiedy włączysz per-channel-peer, OpenClaw przestaje routować ruch do sesji main. Zamiast tego, dynamicznie generuje unikalny session key dla każdej przychodzącej wiadomości. Robi to, łącząc identyfikator kanału platformy z identyfikatorem użytkownika. Teraz, kiedy Alice pisze do bota na konkretnym kanale, OpenClaw buduje session key unikalny dla niej i dla tego kanału. Kiedy Bob pisze do bota, jego identyfikator użytkownika generuje zupełnie inny session key. System ładuje czysty, pusty state dla Boba. Ich konteksty są całkowicie odizolowane. Jeśli Alice gada z botem na zupełnie innym kanale, tam też dostaje świeżą sesję. Te sesje nie trzymają state'u w nieskończoność. OpenClaw ogarnia czyszczenie sesji przez dwa konkretne lifecycle events. Pierwszy to idle reset. Jeśli konkretna sesja nie otrzyma żadnych nowych wiadomości przez skonfigurowany czas, system dropuje kontekst. Kiedy następnym razem użytkownik wyśle wiadomość, zaczyna z czystą kartą. Drugi mechanizm czyszczenia to twardy daily reset. Niezależnie od tego, jak aktywna jest konwersacja, OpenClaw na siłę czyści wszystkie konteksty sesji dokładnie o 4:00 rano czasu serwera. Ten daily reset działa jak zautomatyzowany krok garbage collection. Zapewnia to zwolnienie pamięci i gwarantuje, że długo działające konwersacje nie będą po cichu zużywać ogromnych ilości context tokens przez tygodnie używania. Kiedy robisz deploy agentów do środowisk grupowych, nigdy nie zakładaj, że platforma ogarnie za ciebie separację użytkowników. Jawne mapowanie twoich session keys do odpowiednich granic użytkownika to jedyny sposób, żeby zapobiec przypadkowym wyciekom kontekstu. To wszystko w tym odcinku. Dzięki za wysłuchanie i buduj dalej!

Cześć, tu Alex z DEV STORIES DOT EU. OpenClaw Gateway, odcinek 5 z 11. Context windows w AI nie są nieskończone, ale twoja rozmowa często musi taka być. Gdy długa sesja dobija do limitu, standardowym rozwiązaniem jest całkowite wyrzucenie starszych wiadomości, przez co agent nagle zapomina o krytycznych krokach setupu. Zarządzanie limitami kontekstu za pomocą compaction rozwiązuje ten problem, płynnie zwijając starsze wiadomości w gęste podsumowania, zanim limit zostanie w ogóle przekroczony. Zanim przyjrzymy się mechanice, nie myl tego z session pruning. Session pruning to osobna operacja, która usuwa jedynie nadmiarowe tool results. Compaction działa bezpośrednio na głównej historii konwersacji. Pomyśl o długiej sesji kodowania. Agent przez godzinę generował boilerplate, czytał lokalne pliki i debugował błędy logiczne. Każda interakcja zwiększa liczbę tokenów. Jeśli system dobije do hard limitu bazowego modelu językowego, API odrzuca request, a sesja crashuje. Potrzebujesz sposobu na odzyskanie miejsca bez psucia logiki asystenta. OpenClaw ogarnia to przez Context Engine. Context Engine zarządza całym flow wiadomości między użytkownikiem a modelem. Wewnątrz tego silnika znajduje się konkretny lifecycle point o nazwie compact. Ta faza działa jak automatyczny zawór bezpieczeństwa na wypadek context overflow. Silnik aktywnie monitoruje zużycie tokenów w bieżącej konwersacji. W konfiguracji definiujesz maksymalny próg tokenów. Dopóki konwersacja pozostaje poniżej tego progu, wiadomości przechodzą normalnie. Gdy liczba tokenów zbliża się do limitu, silnik automatycznie odpala memory flush przez lifecycle point compact. Kiedy flush się odpala, system dzieli historię wiadomości na dwie sekcje. Oddziela najnowsze wiadomości od starszych, historycznych. Najnowsze wiadomości pozostają całkowicie nienaruszone. Silnik zachowuje dokładne brzmienie ostatniej wymiany zdań, dzięki czemu agent nie traci bieżącego toku myślenia ani dokładnej składni funkcji, nad którą aktywnie pracujesz. I tu jest kluczowa sprawa. Starsze wiadomości nie są wyrzucane. Zamiast tego trafiają do dodatkowego procesu podsumowywania. Proces ten czyta większość początkowej konwersacji i streszcza ją do krótkiego tekstu. Tekst ten zachowuje pierwotne cele, wczesne decyzje architektoniczne i wszelkie ustalone reguły, jednocześnie wycinając zbędne wypełniacze z rozmowy i przestarzałe iteracje kodu. Następnie silnik restrukturyzuje pamięć aktywną. Zastępuje duży blok surowych, starszych wiadomości tym jednym blokiem podsumowującym. Nowo ustrukturyzowany prompt zawiera najpierw blok podsumowujący, a po nim dosłowne ostatnie wiadomości. Całkowita liczba tokenów drastycznie spada. Agent nadal rozumie historyczny kontekst dzięki podsumowaniu i może kontynuować aktywne zadanie na podstawie ostatnich wiadomości. Rozmowa toczy się dalej płynnie, bez żadnej ręcznej interwencji. Efektywne zarządzanie kontekstem nie polega na trzymaniu każdego wpisanego przez ciebie słowa, ale na systematycznym kompresowaniu przeszłości, tak aby agent miał maksimum miejsca na analizowanie teraźniejszości. To wszystko w tym odcinku. Dzięki za wysłuchanie i buduj dalej!

Cześć, tu Alex z DEV STORIES DOT EU. OpenClaw Gateway, odcinek 6 z 11. Umieszczenie AI we współdzielonym workspace na Slacku z dostępem do terminala brzmi jak gwarantowany incydent bezpieczeństwa, chyba że ściśle zdefiniujesz, kto może wydawać jej polecenia. Dzisiaj omówimy bezpieczeństwo i granice zaufania. Podstawową zasadą OpenClaw Gateway jest to, że działa w oparciu o model zaufania osobistego asystenta. Wielu developerów zakłada, że gatewaye AI mają wbudowaną, złożoną autoryzację na poziomie użytkownika. OpenClaw jej nie ma. OpenClaw nie jest zaprojektowany do izolacji we wrogich środowiskach multi-tenant. Nie próbuje bezpiecznie oddzielać od siebie złośliwych użytkowników na jednej współdzielonej instancji. Zamiast tego cały Gateway działa jak pojedyncza granica reprezentująca jednego zaufanego operatora. System zakłada, że każdy, kto może komunikować się z Gatewayem, jest upoważniony do działania w imieniu właściciela. Pomyśl o tym jak o odblokowanej stacji roboczej. Jeśli twoja instancja OpenClaw jest skonfigurowana z narzędziem modyfikującym infrastrukturę, każdy, kto może komunikować się z tą instancją, może wywołać tę modyfikację. Sam model AI nie ma pojęcia o rolach użytkowników ani tokenach dostępu. Widzi jedynie strumień przychodzącego tekstu. To prowadzi nas do poważnego ryzyka związanego ze współdzielonymi kanałami. Jeśli podłączysz swój Gateway do publicznej grupy na Telegramie lub dużego kanału zespołu na Slacku, każdy użytkownik na tym kanale znajduje się teraz wewnątrz twojej granicy zaufania. AI traktuje każdą przeczytaną wiadomość jako prawidłową instrukcję. Jeśli zewnętrzny użytkownik wpisze na czacie atak typu prompt injection, przejmuje delegowane uprawnienia narzędzi twojego bota. Gateway nie jest w stanie odróżnić ciebie proszącego o status systemu, od atakującego, który podstępem zmusza model do uruchomienia destrukcyjnego shell scriptu. Uprawnienia należą do bota, ale kontrola należy do tego, kto dostarcza prompt. Jeśli masz wystawione na zewnątrz połączenie, takie jak bot na Telegramie, musisz je zabezpieczyć. Po pierwsze, wyłącz narzędzia z podwyższonymi uprawnieniami dla tego konkretnego profilu Gatewaya. Nie dawaj publicznie dostępnemu botowi dostępu do lokalnego systemu plików ani wrażliwych, wewnętrznych API. Ogranicz jego zestaw narzędzi do akcji read-only lub nieszkodliwych działań. Po drugie, ogranicz warstwę komunikacyjną. Skonfiguruj połączenie tak, aby akceptowało direct messages tylko od konkretnych, sparowanych użytkowników, całkowicie ignorując czaty grupowe i nieznajomych. Ograniczając to, kto może wprowadzać tekst i jakie narzędzia bot może wykonywać, zabezpieczasz tę granicę. Aby sprawdzić, czy nie zostawiłeś otwartych drzwi, użyj wbudowanego narzędzia command line. Uruchom polecenie openclaw security audit. To narzędzie skanuje twoją aktywną konfigurację Gatewaya i sprawdza dwa główne ryzyka. Po pierwsze, sprawdza twoją ekspozycję sieciową. Ostrzeże cię, jeśli twoja instancja nasłuchuje na publicznych interfejsach, zamiast być bezpiecznie zbindowana do localhosta. Po drugie, oflaguje zbyt permisywne narzędzia. Audyt zaalarmuje cię, jeśli masz włączone funkcje wysokiego ryzyka, takie jak arbitrary code execution, w tym samym czasie co publiczne integracje czatu. Oto kluczowy wniosek. Granica bezpieczeństwa twojego systemu to dokładnie granica tego, kto może wysyłać tekst do twoich modeli. Jeśli nie możesz ograniczyć odbiorców, musisz ograniczyć narzędzia. Dzięki za spędzenie ze mną tych kilku minut. Do usłyszenia następnym razem, trzymaj się.

Cześć, tu Alex z DEV STORIES DOT EU. OpenClaw Gateway, odcinek 7 z 11. Dawanie modelowi AI surowego dostępu do command-line'a brzmi jak szybka droga do rozwalenia systemu. Ale co, gdyby agent mógł automatycznie odpalać nieszkodliwe komendy do parsowania danych, jednocześnie jawnie pytając cię o zgodę przed dotknięciem czegokolwiek destrukcyjnego? Exec Tool i Runtime Approvals dbają dokładnie o tę równowagę. Exec Tool pozwala agentowi OpenClaw odpalać komendy shellowe, żeby wchodzić w interakcję z systemem. Kiedy agent decyduje, że musi wykonać komendę, uderza bezpośrednio w hosta albo w wyznaczony kontener typu sandbox. Użycie kontenera typu sandbox ogranicza zasięg rażenia przy zwykłym wykonywaniu kodu. Czasami jednak agent naprawdę musi wejść w interakcję z twoim lokalnym systemem plików, przeczytać twoje lokalne logi albo odpalić lokalne procesy. Odpalanie komend na hoście daje ogromne możliwości, i właśnie dlatego istnieje model autoryzacji. OpenClaw używa dwupoziomowego systemu autoryzacji, żebyś miał pełną kontrolę bez niepotrzebnego spowalniania agenta. Pierwszy poziom opiera się na tak zwanych safe bins. Są to konkretne binarki, które jawnie dodajesz do whitelisty jako nieszkodliwe, takie jak jq do parsowania JSON-a czy grep do przeszukiwania tekstu. Jeśli agent wywoła komendę, która używa tylko tych safe bins, Gateway wykonuje ją natychmiast. Nie ma żadnych promptów, a agent utrzymuje swoje tempo. Drugi poziom wyłapuje całą resztę. Jeśli agent próbuje odpalić pełnego shella albo użyć binarki, której nie ma na liście safe bins, Gateway przechwytuje to żądanie. Zatrzymuje agenta i odpala system runtime approvals. W twoim Gateway UI albo w companion app pojawia się prompt. Możesz przejrzeć dokładny command string, który agent chce uruchomić. Jeśli go zatwierdzisz, Gateway wykonuje komendę i zwraca output do agenta. Jeśli go odrzucisz, komenda nigdy się nie uruchomi. Zamiast tego agent dostaje błąd execution denied i musi wymyślić inny sposób na kontynuację albo poprosić cię o wyjaśnienie. Oto jak to dokładnie wygląda w praktyce. Powiedzmy, że agent musi przeanalizować ogromny plik z logami. Wywołuje grepa, żeby wyciągnąć błędy. To odpala się natychmiast. Następnie musi skompilować projekt, więc próbuje odpalić npm run build jako proces w tle. Gateway zatrzymuje agenta i pinguje twoją companion app. Czytasz komendę, stwierdzasz, że ma sens, i klikasz approve. Build startuje w tle. Później agent postanawia zrobić porządki i próbuje usunąć plik źródłowy. Gateway znowu cię pinguje. Odrzucasz żądanie. Twój plik zostaje nietknięty, a agent uczy się, że nie ma uprawnień do tej akcji. Jest jedno surowe ograniczenie bezpieczeństwa, o którym musisz wiedzieć przy odpalaniu komend na hoście. Gateway jawnie odrzuca każdą próbę nadpisania zmiennej środowiskowej path. To zapobiega hijackingowi. Bez tej blokady złośliwy prompt mógłby zmanipulować agenta do zmiany patha, sprawiając, że nazwa z listy safe bins, taka jak grep, odpaliłaby destrukcyjny skrypt ukryty w innym folderze. Ponieważ path jest zablokowany, lista safe bins pozostaje bezwzględna. Prawdziwa moc Exec Tool polega nie tylko na tym, że AI może odpalać komendy, ale na tym, że warstwowy model bezpieczeństwa wymusza obecność człowieka w pętli decyzyjnej tylko wtedy, gdy stawka jest wysoka, zostawiając agentowi pełną autonomię w rutynowych zadaniach. Jeśli chcesz pomóc w utrzymaniu tego podcastu, wyszukaj DevStoriesEU na Patreonie. To wszystko w tym odcinku. Dzięki za wysłuchanie i keep building!

Cześć, tu Alex z DEV STORIES DOT EU. OpenClaw Gateway, odcinek 8 z 11. Chcesz, żeby twój agent manipulował obrazami za pomocą narzędzia command-line. Zazwyczaj oznacza to pisanie wrapperów w Pythonie, definiowanie schematów i nadzieję, że model językowy zrozumie parametry. Ale tak naprawdę nie potrzebujesz kodu, żeby nauczyć AI nowego skilla. Wystarczy ci tylko plik tekstowy. Dzisiaj skupimy się na uczeniu agentów przy użyciu Skills w OpenClaw. Skill w OpenClaw to w zasadzie instrukcja obsługi. To zwykły plik tekstowy o nazwie SKILL dot md, sformatowany zgodnie ze standardem AgentSkills. To nie jest skompilowana binarka ani skrypt w Pythonie. To dokument Markdown, który dokładnie mówi agentowi, jak orkiestrować istniejące narzędzia. W tym pliku piszesz instrukcje krok po kroku. Definiujesz cel danego skilla, narzędzia, których używa, oraz sekwencję akcji, które agent musi wykonać. Jeśli budujesz skill do przetwarzania obrazów o nazwie image-lab, twój plik SKILL dot md wyjaśni, jak sformatować argumenty command-line, żeby zmienić rozmiar lub przyciąć obrazek. Agent czyta ten plik i tłumaczy twoje angielskie instrukcje na precyzyjne wywołania z command-line'a. Skill jest bezużyteczny, jeśli w systemie brakuje narzędzia, na którym się opiera. OpenClaw zapobiega tu błędom, używając load-time gating. Pozwala to zdefiniować wymagania, dzięki czemu twój agent nigdy nie spróbuje użyć softu, który nie jest zainstalowany. Obsługujesz to, deklarując wymagania w konfiguracji skilla. Dla skilla image-lab możesz potrzebować konkretnego package managera do odpalania komend. Określasz to za pomocą właściwości requires dot bins, podając nazwę pliku wykonywalnego, na przykład uv. Możesz też wymagać konkretnych zmiennych środowiskowych używając właściwości requires dot env, co gwarantuje, że klucz API lub ścieżka konfiguracji będą dostępne przed aktywacją skilla. Kiedy OpenClaw startuje, weryfikuje te bramki. Sprawdza lokalne środowisko pod kątem binarki uv i wszystkich wymaganych zmiennych. Jeśli ich brakuje, OpenClaw po cichu pomija tego skilla. System nie zcrashuje, a agent nie będzie halucynował nieobsługiwanych komend. Po prostu działa bez możliwości image-lab. I tu jest kluczowa sprawa. OpenClaw musi wydajnie dostarczyć te poprawne skille do modelu językowego. Bierze wszystkie skille, które przeszły load-time checks, i kompiluje je w kompaktową listę XML. Ten blok XML jest wstrzykiwany bezpośrednio do system promptu agenta. Modele językowe są mocno zoptymalizowane pod kątem parsowania tagów XML. Formatując instrukcję w ten sposób, agent czysto oddziela swoją główną personę od ścisłej logiki krok po kroku, zdefiniowanej w twoich skillach. Nie musisz pisać każdego skilla samodzielnie. OpenClaw integruje się z ClawHub, oficjalnym rejestrem skilli tworzonych przez społeczność. Jeśli potrzebujesz, żeby twój agent obsługiwał konkretną bazę danych lub narzędzie chmurowe, możesz przeszukać ClawHub i zainstalować istniejącego skilla. Pobiera się on do twojego środowiska, przechodzi przez te same load-time checks i automatycznie wstrzykuje się do system promptu. Najcenniejszym aspektem architektury Skills jest decoupling funkcjonalności od kodu. Możesz całkowicie przepiąć sposób, w jaki twój agent rozwiązuje złożone, wieloetapowe problemy, po prostu edytując plik Markdown, bez jakiejkolwiek modyfikacji logiki aplikacji czy kompilowania nowego buildu. Dzięki za spędzenie ze mną tych kilku minut. Do usłyszenia następnym razem, trzymaj się.

Cześć, tu Alex z DEV STORIES DOT EU. OpenClaw Gateway, odcinek 9 z 11. Twój agent próbuje wyciągnąć dane ze strony internetowej, ale to nie jest tylko parsowanie surowego HTML-a. Musi wyrenderować dynamiczny dashboard w React, kliknąć przycisk i poczekać na załadowanie wykresu. Musisz dać agentowi w pełni funkcjonalny interfejs webowy, ale absolutnie nie chcesz, żeby mieszał w twoich otwartych kartach albo przejmował kontrolę nad myszką. Managed Browser Tool zajmuje się dokładnie tym. To narzędzie daje agentowi możliwość klikania, pisania, nawigowania i wizualnego przechwytywania dokładnie tego, co zobaczyłby człowiek. Odpala prawdziwe środowisko przeglądarki, żeby wchodzić w interakcje z aplikacjami renderowanymi po stronie klienta, omijając ograniczenia prostych requestów HTTP. Żeby zapewnić bezpieczeństwo twojego workspace'u, Managed Browser Tool używa różnych profili operacyjnych. Domyślny to odizolowany profil openclaw. Kiedy agent korzysta z tego profilu, narzędzie uruchamia całkowicie oddzielną, dedykowaną instancję Chromium. Ma własne cookies, własny local storage i własną, czystą historię. Agent nawiguje we własnej, dedykowanej przeglądarce. Może wypełniać formularze i klikać po menu, w ogóle nie dotykając twojej osobistej sesji Chrome. Czasami jednak agent potrzebuje dostępu do wewnętrznych narzędzi, w których jesteś już uwierzytelniony. Do tego narzędzie udostępnia profil user. Zamiast startować z czystą kartą, profil user podpina się do twojej istniejącej, zalogowanej sesji Chrome. Łączy się przez DevTools Protocol za pomocą Model Context Protocol. Pozwala to agentowi wykorzystać twoje aktywne tokeny logowania do tego konkretnego taska, bez wymagania od ciebie przekazywania credentialsów bezpośrednio do AI. I tu jest kluczowa sprawa. Danie agentowi AI zautomatyzowanej przeglądarki w twoim środowisku wprowadza natychmiastowe ryzyko bezpieczeństwa. Żeby to zminimalizować, kontrola nad Managed Browser Tool jest ściśle ograniczona do loopbacku. Agent komunikuje się z przeglądarką wyłącznie przez lokalny interfejs loopback. Co ważniejsze, każdy request nawigacji jest chroniony przez politykę Server-Side Request Forgery. Ta polityka gwarantuje, że agent nie może użyć swojej instancji przeglądarki jako proxy do cichego skanowania portów w twojej sieci lokalnej albo uderzania do nieautoryzowanych wewnętrznych serwisów. Pomyśl o scenariuszu z dashboardem w React. Najpierw agent wydaje komendę uruchomienia przeglądarki przy użyciu domyślnego, izolowanego profilu. Nawiguje do URL-a dashboardu i aktywnie czeka na zamontowanie komponentów JavaScript i ustabilizowanie się DOM-u. Następnie lokalizuje konkretny element wykresu za pomocą selektora CSS i triggeruje event click, żeby rozwinąć widok. Na koniec wydaje komendę zrobienia screenshota. Przeglądarka przechwytuje wyrenderowaną ramkę i zwraca bufor obrazu bezpośrednio do gatewaya. Danie agentowi przeglądarki nigdy nie powinno oznaczać oddania kluczy do twojej sieci wewnętrznej albo twojej osobistej sesji Chrome. Managed Browser Tool sprawia, że agent ma ogromne możliwości, ale jest ściśle odizolowany. To wszystko na dzisiaj. Do usłyszenia następnym razem!

Cześć, tu Alex z DEV STORIES DOT EU. OpenClaw Gateway, odcinek 10 z 11. Prosisz swoje AI o zeskrapowanie złożonej strony albo przetworzenie tysięcy linijek logów, a potem po prostu siedzisz. Gapisz się na kręcący się spinner przez dziesięć minut, nie mogąc zadać kolejnego pytania, dopóki task się nie skończy. Żeby rozwiązać ten blokujący problem, używasz efemerycznych sub-agentów. Efemeryczny sub-agent to tymczasowy, odizolowany background worker. Zamiast samodzielnie wykonywać ciężkie obliczenia, twój główny agent czatu deleguje tę robotę. Robi to za pomocą specjalnego toola systemowego o nazwie sessions spawn. Gdy główny agent napotka ogromny task, odpala tego toola. Przekazuje jasny prompt, wszystkie wymagane pliki kontekstowe i konkretne instrukcje dla tego zadania. Ta akcja tworzy zupełnie nową, niewidoczną sesję czatu działającą całkowicie w tle. Ponieważ ta sesja jest odizolowana, twój główny agent zostaje natychmiast odblokowany. Możesz dalej gadać ze swoim głównym asystentem, zadawać niezwiązane z tematem pytania albo przypisywać kolejne taski, podczas gdy sub-agent mieli te ciężkie dane poza zasięgiem twojego wzroku. Spójrzmy na konkretny scenariusz. Wrzucasz ogromny error log z serwera na główny czat i prosisz o audyt bezpieczeństwa. Przetwarzanie tego loga linijka po linijce przez twój główny, potężny LLM zajmuje mnóstwo czasu i przepala dużo drogich tokenów. Zamiast tego, twój główny agent deleguje ten task. I tu jest kluczowa sprawa. Podczas wywoływania sessions spawn, główny agent może określić zupełnie inny model dla tego taska w tle. Może przypisać sub-agentowi tańszy i szybszy LLM. Ten background worker używa szybszego modelu, żeby przemielić tę powtarzalną analizę logów. Główny agent pozostaje responsywny używając mądrzejszego modelu, podczas gdy sub-agent odwala czarną robotę na tym szybkim. Kiedy sub-agent w końcu skończy parsowanie tych logów, potrzebuje sposobu na przekazanie danych z powrotem. Robi to, ogłaszając swój końcowy wynik w górę chaina. Sub-agent bierze swoje skompilowane podsumowanie i wstrzykuje wiadomość bezpośrednio z powrotem do oryginalnego czatu. Po prostu widzisz, jak wyskakuje nowa wiadomość od sub-agenta z gotową analizą logów, którą ty i główny agent możecie od razu omówić. Ta architektura jest znana jako orchestrator pattern i opiera się na zasadach dotyczących nesting depth. Scenariusz, który właśnie omówiliśmy, to nesting depth jeden. User gada z głównym agentem, a główny agent spawnuje sub-agenta. OpenClaw wspiera też nesting depth dwa. W scenariuszu z depth dwa, twój sub-agent parsujący logi może natrafić na mocno zakodowany payload w logach. Może wtedy zespawnować swojego własnego sub-agenta tylko po to, żeby zdekodować ten konkretny payload. Ten agent drugiego poziomu dekoduje tekst, przekazuje go z powrotem do pierwszego sub-agenta, który następnie kończy analizę logów i raportuje z powrotem do twojego głównego czatu. System sztywno limituje to do depth dwa. Ten hard limit zapobiega niekontrolowanym pętlom rekurencyjnym, w których agenci w nieskończoność spawnują kolejnych agentów, drenując twoje zasoby obliczeniowe. Efemeryczni sub-agenci fundamentalnie zmieniają to, jak wchodzisz w interakcję z interfejsem promptu. Przestajesz traktować swój LLM jak pojedynczy zablokowany thread, a zaczynasz traktować go jak asynchronicznego task managera. To wszystko na dzisiaj. Do usłyszenia następnym razem!

Cześć, tu Alex z DEV STORIES DOT EU. OpenClaw Gateway, odcinek 11 z 11. Prawdziwy asystent nie siedzi bezczynnie, czekając, aż wpiszesz komendę. Proaktywnie sprawdza twoje systemy i powiadamia cię, gdy coś faktycznie wymaga twojej uwagi. Przejście z reaktywnej pętli prompt-odpowiedź na samosterującego agenta wymaga konkretnych mechanizmów harmonogramowania i egzekucji. To prowadzi nas do proaktywnych workflowów automatyzacji. OpenClaw obsługuje automatyzację opartą na czasie za pomocą dwóch odrębnych mechanizmów. Pierwszym jest Heartbeat. Drugim jest Cron. Inżynierowie często je mylą, ponieważ oba automatycznie triggerują akcje w oparciu o czas, ale mają zupełnie inne role architektoniczne, jeśli chodzi o stan i izolację sesji. Heartbeat to okresowa pętla, która działa nieprzerwanie w ramach twojej głównej, aktywnej sesji. Jest zaprojektowana do rutynowych, ciągłych checków, gdzie twój obecny kontekst ma znaczenie. I tu jest kluczowa sprawa. Ponieważ Heartbeat działa wewnątrz twojej obecnej sesji, ma bezpośredni dostęp do twojego aktywnego interfejsu. Pomyśl o scenariuszu, w którym chcesz monitorować swoją skrzynkę pod kątem pilnych wiadomości. Konfigurujesz Heartbeat, żeby odpalał check co trzydzieści minut. Jeśli wykryje krytycznego maila, Heartbeat może natychmiast wypchnąć alert w języku naturalnym prosto do twojego aktywnego strumienia konwersacji. Działa jak ciągły wątek w tle podpięty pod twój obecny stan użytkownika, pozwalając na natychmiastowe, kontekstowe przerwania. Cron działa zupełnie inaczej. Został stworzony do precyzyjnych, zaplanowanych jobów, które wymagają całkowitej izolacji. Jeśli chcesz, żeby system kompilował kompleksowy poranny briefing z różnych źródeł danych dokładnie o szóstej rano, używasz Crona. Kiedy odpala się harmonogram Crona, OpenClaw nie używa twojego aktywnego czatu. Zamiast tego, podnosi całkowicie odizolowaną sesję w tle. Pobiera potrzebne dane, po cichu odwala analityczną czarną robotę i śledzi całego joba wewnętrznie jako Background Task. To oznacza, że ciężkie przetwarzanie nie zaśmieca okna kontekstowego twojego aktywnego czatu na desktopie. Kiedy job się zakończy, gotowy briefing jest zapisywany i czeka, aż go odbierzesz po zalogowaniu. Heartbeat dzieli z tobą stan, podczas gdy Cron działa headless i w izolacji. Triggery oparte na czasie to tylko część workflowu. OpenClaw polega na Hookach i Standing Orders jako narzędziach komplementarnych, żeby domknąć pętlę automatyzacji. Podczas gdy Heartbeat i Cron dyktują, kiedy akcja ma się wydarzyć na podstawie zegara, Hooki obsługują zewnętrzne triggery event-driven. Hook wystawia nasłuchujący endpoint, który mogą wywołać zewnętrzne systemy. Jeśli krytyczny log serwera wskazuje na awarię, zewnętrzny system może uderzyć w Hook OpenClaw, budząc asystenta do natychmiastowej analizy błędu, bez czekania na kolejny zaplanowany puls Heartbeata. Standing Orders dostarczają trwałe reguły operacyjne dla wszystkich tych autonomicznych przebiegów. Kiedy ten odizolowany job Crona budzi się o szóstej rano, nie ma użytkownika, który mógłby pokierować jego wynikiem. Standing Orders definiują dokładny format, głębokość analizy i reguły priorytetów, których asystent musi przestrzegać, pracując całkowicie niezależnie. Łącząc okresowe Heartbeaty do aktywnego monitorowania, odizolowane joby Crona do ciężkich zaplanowanych tasków i trwałe Standing Orders do zarządzania zachowaniem bez nadzoru, fundamentalnie zmieniasz naturę aplikacji. Przestajesz budować prosty interfejs czatu i zaczynasz deployować prawdziwego autonomicznego asystenta. Ponieważ to ostatni odcinek naszej serii o OpenClaw, gorąco zachęcam cię do przejrzenia oficjalnej dokumentacji, spróbowania własnoręcznej konfiguracji tych background tasków, albo odwiedzenia devstories dot eu, żeby zaproponować tematy do naszej kolejnej serii. Dzięki za spędzenie ze mną tych kilku minut. Do następnego razu, trzymaj się.