Clawdbot, czyli dzisiejszy OpenClaw
Jeśli szukasz Clawdbota, projekt nadal istnieje, tylko pod inną nazwą. W styczniu 2026 roku zmienił się najpierw na Moltbot, a trzy dni później na OpenClaw. To ta sama rzecz: osobisty asystent uruchamiany na własnym sprzęcie, który nie tylko odpowiada, ale wykonuje zadania.
Skąd dwie zmiany nazwy w tydzień
Pierwsza zmiana wynikła ze zgłoszenia znaku towarowego. Anthropic zwróciło uwagę na podobieństwo fonetyczne nazwy oraz na maskotkę nawiązującą do skojarzeń z ich produktem, a autor projektu przemianował go na Moltbot 27 stycznia 2026 roku.
Druga zmiana nastąpiła trzy dni później, 30 stycznia, i wynikła już tylko z tego, że autorowi nazwa Moltbot nie leżała w wymowie. Nazwa OpenClaw podkreśla otwartość projektu i zachowuje nawiązanie do pierwotnego motywu, a zarazem zamyka serię przemianowań. Projekt trafił następnie pod opiekę niezależnej fundacji, co oznacza rozwój prowadzony przez społeczność, a nie przez jedną osobę.
Warto o tym wiedzieć przy szukaniu materiałów. Sporo poradników i wpisów opisuje starą nazwę, a polecenia instalacyjne z tamtego okresu zwykle już nie działają. Przy problemach szukaj pod bieżącą nazwą, a starsze materiały traktuj jako opis idei, nie jako instrukcję.
Czym ten asystent właściwie jest
Różnica wobec zwykłego czatu polega na tym, że narzędzie działa. Przeczyta wiadomość, sprawdzi kalendarz, napisze odpowiedź, wyszuka coś w sieci, uruchomi polecenie na Twojej maszynie. Rozmawiasz z nim zwykle przez komunikator, którego i tak używasz, a nie przez osobne okno w przeglądarce.
Drugą różnicą jest miejsce działania. Asystent uruchamia się na Twoim komputerze albo serwerze, więc treść wiadomości i pliki nie przechodzą przez cudzą infrastrukturę poza wywołaniami modelu, których i tak nie da się uniknąć. Dla części zastosowań to jedyny akceptowalny układ.
Trzecią jest tempo rozwoju. Projekt zebrał ponad sto tysięcy gwiazdek na GitHubie w kilka tygodni, a w sierpniu 2026 roku ma ich ponad trzysta osiemdziesiąt tysięcy, co plasuje go wśród najszybciej rosnących inicjatyw otwartego kodu. Ta popularność ma dwie strony: dużo materiałów i wtyczek, ale też dużo poradników niskiej jakości i podszywających się pod projekt oszustw.
Jak to działa w praktyce
Typowy scenariusz wygląda tak: piszesz do asystenta w komunikatorze, on wykonuje zadanie i odpisuje, kiedy skończy. Zadania są tego rodzaju, których nie chce się robić ręcznie, a które są zbyt drobne, żeby budować pod nie automatyzację.
Przejrzenie skrzynki i wypisanie tego, co wymaga odpowiedzi. Sprawdzenie, czy w kalendarzu na jutro nie ma kolizji. Wyszukanie informacji i podanie streszczenia zamiast dziesięciu linków. Uruchomienie skryptu na serwerze i zameldowanie wyniku. Zapisanie notatki tam, gdzie jej potem poszukasz.
Model językowy odpowiada za rozumienie polecenia i wybór działania, a narzędzia za wykonanie. Możesz podpiąć własne funkcje, więc zakres ogranicza to, co jesteś w stanie opisać, a nie lista gotowych integracji.
Sposób rozmowy też ma znaczenie. Polecenie sformułowane konkretnie, z podaniem zakresu i oczekiwanego wyniku, daje efekt przewidywalny, a ogólne „ogarnij mi skrzynkę" zostawia asystentowi decyzję, czego dotyczy zadanie. Przy narzędziu, które faktycznie wykonuje działania, ta różnica ma wagę większą niż w zwykłym czacie, bo błędne odczytanie intencji kończy się wykonaną czynnością, a nie tylko nietrafioną odpowiedzią.
Warto ustawić oczekiwania. To narzędzie do zadań pomocniczych, nie do procesów, w których błąd jest kosztowny. Asystent czasem źle zrozumie polecenie, a przy szerokich uprawnieniach skutki takiej pomyłki bywają realne.
Bezpieczeństwo, czyli najważniejsza część tej instalacji
Ta sekcja jest ważniejsza niż konfiguracja, bo mówimy o narzędziu, które ma dostęp do Twoich wiadomości i może uruchamiać polecenia. Rozgłos projektu przyciągnął też uwagę osób szukających łatwych celów.
Pierwsza zasada: nie wystawiaj instancji na publiczny adres bez uwierzytelniania. Agent z dostępem do powłoki systemowej i otwartym portem to nie jest luka, tylko zaproszenie.
Druga: ograniczaj uprawnienia do minimum. Osobne konto systemowe, dostęp tylko do wskazanych katalogów, brak kluczy do usług, których zadanie nie wymaga. Agent, który potrafi czytać pocztę, nie musi jednocześnie mieć dostępu do repozytoriów i portfela.
Trzecia: uważaj na treści z zewnątrz. Wiadomość, strona internetowa albo dokument mogą zawierać instrukcje skierowane do modelu, a nie do Ciebie. To realna klasa ataku przy agentach czytających cudzą korespondencję, więc traktuj każdą przeczytaną treść jako dane, nie jako polecenie.
Czwarta: pobieraj wyłącznie z oficjalnego źródła. Wokół projektu pojawiły się podszywające się pakiety i strony, a instalacja narzędzia z takimi uprawnieniami z przypadkowego źródła kończy się źle.
Piąta: zaczynaj od trybu tylko do odczytu. Niech asystent najpierw czyta i proponuje, a dopiero po kilku dniach dostanie prawo do działania. To najtańszy sposób, żeby zobaczyć, jak interpretuje Twoje polecenia.
Instalacja i konfiguracja
Instalacja wymaga środowiska uruchomieniowego, klucza do modelu i skonfigurowania kanału komunikacji. Projekt podaje dwie drogi: pakiet z rejestru npm albo skrypt instalacyjny ze strony projektu.
npm install -g openclaw@latestPonieważ nazwa i polecenia zmieniały się w krótkim czasie, resztę komend warto brać z bieżącej dokumentacji projektu, a nie z artykułów opisujących wcześniejsze wersje. Dotyczy to zwłaszcza skryptu instalacyjnego pobieranego z sieci: wykonywanie czegoś takiego bez przeczytania to dokładnie ten nawyk, przed którym ostrzega poprzednia sekcja.
curl -fsSL https://openclaw.ai/install.sh -o install.sh
less install.sh
bash install.shSensowna kolejność wygląda tak. Najpierw uruchom asystenta lokalnie i porozmawiaj z nim bez podpiętych narzędzi, żeby sprawdzić, czy w ogóle działa. Potem podłącz jeden kanał komunikacji, najlepiej ten, którego używasz najczęściej. Następnie dodawaj narzędzia pojedynczo, sprawdzając po każdym, czy asystent używa go tak, jak zakładałeś.
Klucze przechowuj w zmiennych środowiskowych albo w menedżerze sekretów, nigdy w pliku konfiguracyjnym trafiającym do repozytorium. Ta zasada obowiązuje wszędzie, ale tutaj ma dodatkową wagę, bo asystent czyta pliki w katalogu, w którym pracuje.
sudo useradd --system --create-home --shell /usr/sbin/nologin asystent
sudo install -o asystent -g asystent -m 600 /dev/null /home/asystent/.env
printf 'ANTHROPIC_API_KEY=%s\n' "$KLUCZ" | sudo -u asystent tee /home/asystent/.env >/dev/nullOsobne konto systemowe bez powłoki logowania jest tu tańsze niż jakakolwiek późniejsza naprawa. Asystent działający na Twoim koncie ma dostęp do wszystkiego, co Ty, łącznie z kluczami do repozytoriów i zapisanymi sesjami przeglądarki.
Warto od razu włączyć zapis tego, co asystent robi, i przechowywać go osobno od samego narzędzia. Log z listą wykonanych czynności odpowiada na pytanie, dlaczego coś się wydarzyło, a przy narzędziu działającym w tle bez tego zapisu zostaje tylko domysł. Przy okazji zdecyduj, jak długo te logi trzymasz, bo zawierają treść poleceń, a więc też fragmenty Twojej korespondencji.
Przy uruchomieniu na serwerze domowym rozważ kontener. Izolacja procesu ogranicza skutki błędu i ułatwia usunięcie całości, gdy narzędzie przestanie być potrzebne.
docker run -d --name asystent \
--read-only \
--cap-drop=ALL \
--security-opt no-new-privileges \
--tmpfs /tmp \
-v /srv/asystent/dane:/dane \
--env-file /home/asystent/.env \
obraz-asystenta:przypieta-wersjaCztery pierwsze przełączniki robią tu większość roboty. System plików tylko do odczytu, zdjęte uprawnienia jądra i zablokowane podnoszenie uprawnień sprawiają, że nawet udane wejście do procesu daje niewiele. Jedyny zapisywalny katalog to ten, który sam wskazałeś.
Ile to kosztuje
Sam projekt jest otwarty i darmowy. Płacisz za model językowy, a rachunek zależy od tego, jak często rozmawiasz z asystentem i jak długie konteksty przekazujesz.
Rząd wielkości przy codziennym użyciu do zadań pomocniczych to kilka do kilkunastu dolarów miesięcznie na modelu średniej klasy. Rachunek rośnie szybko przy dwóch rzeczach: długiej historii rozmowy przekazywanej przy każdym wywołaniu oraz zadaniach wymagających wielu kroków, gdzie każdy krok to osobne wywołanie.
Dwie rzeczy tną koszt najskuteczniej. Kierowanie prostych poleceń do tańszego modelu, bo przypomnienie o spotkaniu nie wymaga najmocniejszego dostępnego. Oraz ograniczanie historii, którą asystent dostaje przy każdym pytaniu, do tego, co faktycznie potrzebne.
Do rachunku dolicz sprzęt, jeśli uruchamiasz to na osobnej maszynie. Mały serwer wystarcza, bo obliczenia modelu i tak dzieją się u dostawcy, chyba że zdecydujesz się na model lokalny przez Ollamę, co zmienia rachunek na koszt sprzętu.
Czego nauczyła ta historia poza samą zmianą nazwy
Ta sprawa jest dobrym studium przypadku dla każdego, kto rozważa oparcie procesu o młody projekt otwartego kodu, i warto wyciągnąć z niej trzy wnioski.
Nazwa nie jest gwarantowana. Projekt oparty o skojarzenie z cudzą marką może zostać zmuszony do zmiany, a razem z nazwą zmieniają się adresy pakietów, polecenia instalacyjne i nazwy katalogów konfiguracyjnych. Jeśli wpinasz takie narzędzie w automatyzację, przypnij konkretną wersję i zaplanuj, kto sprawdzi zmiany przed aktualizacją.
Popularność przyciąga oszustów. Przy projekcie rosnącym o dziesiątki tysięcy gwiazdek tygodniowo pojawiają się pakiety o łudząco podobnych nazwach, strony z instrukcją prowadzącą do zmodyfikowanego kodu i filmy z poradnikami, które przy okazji instalują coś jeszcze. Reguła jest prosta: adres repozytorium bierzesz z jednego, znanego źródła i nie klikasz w linki z komentarzy.
Zmiana opiekuna projektu jest sygnałem, nie problemem. Przejście pod fundację zwykle oznacza stabilniejszy rozwój i mniejsze ryzyko, że projekt zniknie razem z zainteresowaniem jednej osoby. Warto natomiast sprawdzić, jak wygląda proces wydawania wersji, bo to on decyduje o tym, czy aktualizacje będą przewidywalne.
Przy narzędziach z tak szerokimi uprawnieniami dochodzi jeszcze jedna zasada: nowa wersja to nowe uprawnienia. Aktualizacja może dodać integrację albo rozszerzyć dostęp, więc czytanie listy zmian przed instalacją jest tu bardziej uzasadnione niż przy zwykłej bibliotece.
OpenClaw kontra alternatywy
| Rozwiązanie | Mocna strona | Słabość | Kiedy wybrać |
|---|---|---|---|
| OpenClaw | Działa na własnym sprzęcie, szerokie możliwości, rozwój społeczności | Szerokie uprawnienia oznaczają realne ryzyko | Zadania osobiste, dane, które mają zostać u Ciebie |
| n8n | Przewidywalne przepływy, setki integracji | Mniej elastyczny przy poleceniach w języku naturalnym | Automatyzacja o ustalonym przebiegu |
| Claude Code | Dojrzałe narzędzie do pracy z kodem | Zakres ograniczony do programowania | Praca nad repozytorium |
| Asystent wbudowany w system | Zero konfiguracji | Ograniczony zakres, dane u dostawcy | Proste polecenia bez wymagań co do prywatności |
Te narzędzia nie wykluczają się nawzajem. Częsty układ to przepływ obsługujący powtarzalną część procesu i asystent wywoływany tam, gdzie polecenie przychodzi od człowieka i za każdym razem brzmi inaczej.
Podział przebiega wzdłuż pytania o powtarzalność. Zadania, które wykonujesz w ten sam sposób co tydzień, taniej i bezpieczniej opisać jako przepływ. Zadania formułowane za każdym razem inaczej lepiej pasują do asystenta rozumiejącego polecenie w języku naturalnym.
Typowe błędy
Pierwszy to nadanie pełnych uprawnień od razu. Agent z dostępem do wszystkiego przy pierwszym uruchomieniu to najprostszy sposób na kosztowną lekcję.
Drugi to instalowanie z przypadkowego źródła. Po zmianach nazwy w sieci krąży sporo pakietów i poradników udających oryginał.
Trzeci to traktowanie treści z zewnątrz jak poleceń. Wiadomość od nieznanej osoby może zawierać instrukcję skierowaną do modelu, a agent czytający pocztę wykona ją, jeśli nic go przed tym nie powstrzyma.
Czwarty to brak logów. Bez zapisu, co asystent zrobił i dlaczego, diagnoza dziwnego zachowania sprowadza się do zgadywania.
Piąty to zostawienie asystenta bez limitu wydatków. Zadanie zapętlone na błędzie potrafi wywoływać model bez końca, a rachunek zobaczysz dopiero na fakturze. Limit po stronie dostawcy modelu jest tu najprostszym zabezpieczeniem.
Szósty to poleganie na nim w sprawach, które mają termin. Asystent może źle zrozumieć polecenie albo zatrzymać się na błędzie, więc przypomnienie o wizycie u lekarza lepiej mieć również w kalendarzu.
FAQ
Czy Clawdbot nadal istnieje?
Tak, pod nazwą OpenClaw. Projekt zmienił nazwę dwukrotnie w styczniu 2026 roku: najpierw na Moltbot po zgłoszeniu dotyczącym znaku towarowego, potem na OpenClaw, żeby zakończyć zamieszanie. Kod i idea pozostały te same, a opiekę nad projektem przejęła niezależna fundacja.
Czy to jest darmowe?
Kod jest otwarty i nie ma opłat licencyjnych. Płacisz za wywołania modelu językowego, czyli zwykle od kilku do kilkunastu dolarów miesięcznie przy codziennym użyciu, oraz opcjonalnie za sprzęt, jeśli uruchamiasz to na osobnym serwerze.
Czy moje dane wychodzą na zewnątrz?
Asystent działa na Twoim sprzęcie, więc pliki i wiadomości nie przechodzą przez cudzą infrastrukturę. Wychodzą natomiast te fragmenty, które trafiają do modelu językowego, bo tam odbywa się rozumienie polecenia. Pełną lokalność uzyskasz tylko przy modelu uruchomionym u siebie.
Czy to bezpieczne?
Zależy od konfiguracji. Narzędzie z dostępem do powłoki i do Twoich wiadomości jest tak bezpieczne, jak ostrożnie je ustawisz. Minimum to brak publicznego dostępu bez uwierzytelniania, ograniczone uprawnienia, oficjalne źródło instalacji i traktowanie treści z zewnątrz jako danych, nie poleceń.
Czy nadaje się do pracy?
Do zadań pomocniczych tak, do procesów o krytycznym znaczeniu ostrożnie. Przy danych klientów i wymogach zgodności rozważ najpierw, czy dostęp agenta do tych danych jest w ogóle dopuszczalny, a przy powtarzalnych procesach sprawdź, czy przepływ w n8n nie będzie tańszy i bardziej przewidywalny.
Bieżący kod i dokumentacja stoją w repozytorium projektu, a historię zmian nazwy opisuje artykuł na Wikipedii.