O czym jest ten film
- Bot sprawdza kalendarz autora i przygotowuje propozycje dojazdu, noclegu oraz opieki nad psem przed wyjazdem.
- Asystent publikacji sprawdza film po premierze i wraca z oceną jego wyników po 24 godzinach.
- Dwa boty pilnują serwera: jeden przypomina o kończących się usługach, drugi tworzy codzienną migawkę.
- „Czujka” obserwuje reklamy konkurencji oraz zmiany na jej stronach internetowych.
- Bot z kolekcji Grokbota pomaga wykrywać błędy automatyzacji i rozmowy, których długość podnosi koszt kolejnych uruchomień.
- Nocny audytor przegląda repozytorium i przygotowuje propozycje poprawek; kolejny bot przekazuje je agentom pracującym na komputerze autora.
- „Timy” przyjmuje zadania od autora, przedstawia plan do zatwierdzenia i uruchamia pracę modeli używanych lokalnie.
- Przez wszystkie przykłady przewija się jedna zasada: bot powinien odzywać się wtedy, gdy wydarzyło się coś istotnego albo potrzebna jest decyzja człowieka.
10 najważniejszych takeaways — z kontekstem zastosowania
1.Zacznij od zadania, które regularnie umyka uwadze
Na czym polega: Konsjerż autora codziennie sprawdza kalendarz i rozpoznaje wyjazdy wymagające przygotowań.
Jak stosować: Wybierz powtarzalny obowiązek, na przykład organizację podróży. Określ, skąd bot ma brać dane, z jakim wyprzedzeniem ma działać i jakie propozycje powinien przygotować.
Na co uważać: Wydarzenie bez miejsca lub z niejednoznaczną nazwą może zostać przeoczone. Bot powinien zgłaszać również brak dostępu do kalendarza.
2.Oddziel przygotowanie propozycji od zakupu
Na czym polega: Konsjerż wyszukuje połączenia i noclegi, ale autor sam wybiera i opłaca rezerwacje.
Jak stosować: Zleć botowi zebranie opcji z cenami, lokalizacją i zasadami anulowania. Zakup zostaw do własnej akceptacji.
Na co uważać: Ceny i dostępność mogą się zmienić między wyszukaniem a rezerwacją. Sprawdź je ponownie przed płatnością.
3.Uruchamiaj bota po zdarzeniu, gdy liczy się konkretna chwila
Na czym polega: Asystenta premiery filmu budzi sygnał wysłany przez automatyzację n8n, kiedy pojawia się nowa publikacja.
Jak stosować: Jeśli zadanie ma sens dopiero po publikacji, zakupie czy otwarciu zgłoszenia, użyj webhooka, czyli automatycznego powiadomienia przekazywanego między narzędziami.
Na co uważać: Sam proces wykrywania zdarzenia też wymaga konfiguracji. W przykładzie autora n8n sprawdza nowe filmy co 10 minut; oszczędność dotyczy rzadszego uruchamiania Grokbota.
4.Dobierz częstotliwość kontroli do tempa zmian
Na czym polega: Informacja o wygasającej domenie i kopia serwera nie wymagają sprawdzania co kwadrans.
Jak stosować: Dla wolno zmieniających się spraw ustaw kontrolę raz dziennie lub rzadziej. Ustal, kiedy bot ma milczeć, a kiedy zgłosić problem.
Na co uważać: Cisza po udanym zadaniu ma sens tylko wtedy, gdy awaria połączenia lub nieudana kopia wywoła alarm.
5.Przy częstym zbieraniu danych sprawdź dostępne integracje
Na czym polega: „Czujka” pobiera reklamy przez Apify, a treść stron przez Firecrawl, zamiast za każdym razem otwierać je w przeglądarce.
Jak stosować: Zanim zlecisz botowi codzienne klikanie po stronach, sprawdź, czy dana usługa udostępnia API lub gotowy konektor.
Na co uważać: Darmowe plany i limity usług mogą się zmieniać. Kontroluj także koszt oraz zakres pobieranych danych.
6.Pilnuj długości rozmów z botem
Na czym polega: Według autora długi czat może podnieść koszt późniejszych uruchomień, bo bot ponownie korzysta z historii rozmowy.
Jak stosować: Przeglądaj boty wykonujące zadania cykliczne. Gdy historia staje się zbyt długa, rozważ nową rozmowę z tym samym botem albo kopię bota z przeniesionymi ustawieniami.
Na co uważać: Przed usunięciem starej wersji sprawdź, czy nowa ma potrzebną pamięć, umiejętności, połączenia i rutyny.
7.Testuj rutyny przed włączeniem harmonogramu
Na czym polega: Autor zaleca pojedynczy przebieg próbny, by wykryć błędne ustawienia przed codziennym uruchamianiem.
Jak stosować: Sprawdź, czy bot ma dostęp do właściwych danych, rozpoznaje zdarzenie i wykonuje oczekiwaną czynność.
Na co uważać: Próbne uruchomienie może działać na rzeczywistym repozytorium lub serwerze. Przed testem sprawdź, jakie zmiany bot może wprowadzić.
8.W pracy nad kodem zachowaj etap przeglądu przez człowieka
Na czym polega: Nocny bot przygotowuje propozycję poprawki, a kolejne narzędzia mogą ją opracować i sprawdzić. Autor rano ocenia wynik.
Jak stosować: Zleć automatyczny przegląd repozytorium i przygotowanie poprawki, ale przed przyjęciem zmian przejrzyj różnice oraz wyniki testów.
Na co uważać: Sam fakt, że kod został poprawiony i sprawdzony przez inne modele, nie zastępuje decyzji właściciela projektu.
9.Przed dłuższą pracą agenta zatwierdź zakres
Na czym polega: „Timy” przedstawia autorowi plan. Dopiero po jego zgodzie uruchamia pracę agentów na komputerze.
Jak stosować: Wymagaj krótkiej propozycji zawierającej cel, zakres i zadania. Daj wyraźny sygnał do rozpoczęcia pracy, gdy plan się zgadza.
Na co uważać: Niejasne polecenie może uruchomić wiele godzin pracy w złym kierunku. Sprawdź plan przed zatwierdzeniem.
10.Powiadamiaj o wyniku, blokadzie lub potrzebnej decyzji
Na czym polega: Autor stara się ograniczyć liczbę wiadomości od botów do zdarzeń, które wymagają jego uwagi.
Jak stosować: Ustal trzy podstawowe powody powiadomienia: zakończenie zadania, przeszkoda w pracy oraz konieczność podjęcia decyzji.
Na co uważać: Zbyt surowa zasada milczenia może ukryć awarię. Rozróżnij sytuację „nic się nie zmieniło” od „nie udało się sprawdzić”.
Redakcyjne tłumaczenie
Po trzech tygodniach pracy z Grokbotem
W poprzednim materiale obiecałem kolejny odcinek o Grokbocie, jeśli pod filmem pojawi się co najmniej 123 polubień. Było ich ponad 170, więc wracam do tematu. Po trzech intensywnych tygodniach korzystania z narzędzia chcę pokazać osiem praktycznych zastosowań i kilka sposobów na oszczędzanie limitów.
Najdalej idący przykład dotyczy pracy nad kodem. Mam bota, który potrafi uruchomić na moim komputerze Claude Code i Codex, zlecić im współpracę oraz przekazać zadanie wtedy, gdy śpię albo jestem poza domem. Zanim do niego przejdziemy, zacznę od prostszej sprawy: przygotowań do wyjazdu.
Konsjerż, który pamięta o podróży
Zdarza mi się zbyt późno zabrać za organizowanie wyjazdu. Dlatego stworzyłem „Konsjerża”. Bot ma dostęp do udostępnionego kalendarza Google. Codziennie o dziewiątej rano uruchamia się i sprawdza wydarzenia na 30 dni do przodu.
Jeśli znajdzie wydarzenie poza Wrocławiem, gdzie mieszkam, albo jego nazwa wskazuje na wyjazd, odzywa się do mnie tydzień wcześniej. Wyszukuje połączenia kolejowe w Koleo, sprawdza noclegi i pyta, czy mam z kim zostawić mojego psa, Bezę.
Na potrzeby próby dodałem do kalendarza fikcyjny wyjazd do Warszawy. Konsjerż zapytał najpierw, czy moja narzeczona ma wtedy koncert lub wyjazd. Pracuje także w weekendy, więc od tego zależy opieka nad psem. Gdy odpowiedziałem, że będzie w domu, bot uznał sprawę za załatwioną. Gdyby jej nie było, zaproponowałby inne możliwości.
Potem przedstawił połączenia z Wrocławia do Warszawy: godziny, ceny i odnośniki do biletów. Dodał też wariant podróży samochodem wraz z szacowanym czasem przejazdu i kosztem paliwa. Wśród noclegów pokazał ceny, oceny, lokalizacje i warunki odwołania rezerwacji. Początkowo korzystałem między innymi z Booking.com i Google Hotels. Później dodałem Airbnb, bo częściej szukam apartamentów.
Ustalone informacje Konsjerż dopisuje do wydarzenia w kalendarzu: linki do połączeń i wybrane propozycje noclegu. Nic jednak sam nie kupuje. To ja podejmuję decyzję i dokonuję rezerwacji.
Bot ma jeszcze jedną ważną instrukcję: jeśli nie znalazł niczego, co wymaga mojej uwagi, nie wysyła wiadomości. Przez większość tygodni jego czat milczy. Nie może jednak przemilczeć awarii. Gdy straci dostęp do kalendarza albo strona z połączeniami przestanie odpowiadać, ma mnie o tym poinformować.
Codzienny przegląd kalendarza zużywa limit także wtedy, gdy nie ma żadnego wyjazdu. Najdroższe bywa jednak korzystanie z przeglądarki na wirtualnym komputerze: bot otwiera strony i klika po nich jak człowiek. U mnie robi to tylko raz na kilka tygodni, więc koszt jest do przyjęcia. Przy codziennym wyszukiwaniu sprawdziłbym najpierw, czy potrzebne usługi mają API albo serwer MCP, przez który bot może się z nimi połączyć.
Dyżurny premiery: bot budzony przez zdarzenie
Konsjerż działa o ustalonej godzinie. „Dyżurny premiery” potrzebny jest przede wszystkim wtedy, gdy publikuję nowy film. Budzi go webhook: sygnał wysłany z innego narzędzia po wystąpieniu konkretnego zdarzenia.
Po publikacji bot sprawdza, czy opis filmu odpowiada przygotowanej wersji, czy są rozdziały i krótkie linki oraz czy zgadzają się tytuł, przypięty komentarz i karta końcowa. Jeśli czegoś brakuje, mogę szybko to poprawić. Później dostaję również ocenę wyników materiału.
Sygnał wysyła automatyzacja zbudowana w n8n, którą uruchamiam na serwerze VPS. Dzięki temu działa również przy wyłączonym komputerze. Sam proces n8n sprawdza nowe filmy przez YouTube API co 10 minut. Następnie porządkuje pobrane dane, wyodrębnia identyfikator filmu, tytuł i datę publikacji, filtruje nowe materiały oraz pilnuje, by nie obsłużyć tej samej premiery dwukrotnie.
Po wykryciu publikacji automatyzacja wysyła pierwszy sygnał do Grokbota, który kontroluje przygotowanie filmu. Po 24 godzinach wysyła kolejny. Wtedy Dyżurny podaje liczbę wyświetleń, polubień i komentarzy, ocenia, czy materiał radzi sobie lepiej lub gorzej niż zwykle, i proponuje zmianę, jeśli widzi ku temu powód. W pokazanym przykładzie wyniki były w porządku, więc nie zalecił żadnej korekty.
Po co ten dodatkowy mechanizm? Gdyby sam Grokbot uruchamiał rutynę co 15 minut, oznaczałoby to około stu uruchomień dziennie. Każde zużywa limit. Webhook pozwala włączyć go wtedy, gdy ma już konkretne zadanie. Osoba, która dopiero zaczyna pracę z n8n, może zbudować taki proces z pomocą asystenta AI. Ja korzystam także z Claude Code i Codex, które potrafią pracować z n8n przez jego serwer MCP.
Serwer pod opieką Mike’a i Frizia
Skoro n8n działa na moim serwerze, ktoś musi pilnować również samego VPS. Rozdzieliłem to między dwa boty.
„Mike” korzysta z oficjalnego konektora Hostingera. Sprawdza terminy odnowienia domen i planów. Gdy zbliża się koniec usługi, informuje mnie o tym. Jeśli nie ma nic nowego, milczy.
„Frizio” codziennie rano tworzy migawkę serwera, czyli jego kopię zapasową. Pokazuję w panelu Hostingera migawkę wykonaną 24 września o 6:11. Frizio odzywa się, gdy jej utworzenie się nie uda; udana kopia nie wymaga osobnego komunikatu.
Żaden z tych botów nie musi budzić się co kwadrans. Termin odnowienia domeny nie zmienia się tak szybko, a jedna migawka dziennie wystarcza na moje potrzeby. Dostęp do działań na serwerze zapewnia oficjalna integracja Hostingera dostępna w katalogu Grokbota.
Przy tej okazji wspomnę o sponsorze kanału, Hostingerze. Na jego VPS uruchamiam n8n, Claude Code i inne aplikacje. W materiale pokazuję wybór lokalizacji serwera oraz instalację wybranego narzędzia podczas zamawiania usługi. Polecam na początek plan KVM2 i podaję link oraz kod rabatowy w opisie filmu. Pokazana cena, warunki promocji, miejsce na dysku i możliwość zwrotu dotyczą oferty przedstawionej w chwili nagrania.
„Czujka” obserwuje reklamy i strony
Kolejnego bota przygotowałem na warsztat dla AI Marketers prowadzony z Arturem Jabłońskim. „Czujka” przydaje się osobom, które chcą śledzić działania konkurencji.
W tym przypadku celowo zrezygnowałem z ręcznego przeglądania stron przez bota. Reklamy z biblioteki Meta pobiera za pośrednictwem Apify. Do odczytu treści stron internetowych używa konektora Firecrawl dostępnego w Grokbocie. Dzięki temu może porównywać obecną wersję strony z wcześniejszą i wychwytywać zmiany.
W chwili nagrania obie usługi miały darmowe plany, które według moich potrzeb wystarczały do pracy na małą skalę. Gotową „Czujkę” udostępniłem członkom swojej społeczności. Starego bota usunąłem — powód wiąże się z długością rozmowy i kosztem jej dalszego używania.
Doktor Eggbot i porządek w rozmowach
W katalogu botów zespołu Grokbota jest „Doktor Eggbot”. Ma dwie wbudowane rutyny. Jedna szuka błędów i utrudnień w historii uruchomień innych botów. Druga sprawdza, czy ich rozmowy nie stały się zbyt długie.
Problem polega na tym, że przy kolejnym uruchomieniu bot korzysta z historii swojego czatu. Im więcej wiadomości się w nim zgromadzi, tym większe może być zużycie limitu. Dotyczy to zwłaszcza rutyn wykonywanych regularnie.
U mnie sam Doktor Eggbot również zgromadził długą rozmowę. Podzieliłem więc jego obowiązki między dwa boty. „Audytor” sprawdza historię uruchomień i długość czatów, a z Eggbotem pracuję nad tworzeniem nowych botów. Ten drugi ma przygotowane przez zespół Grokbota instrukcje, które pomagają mu w tym zadaniu.
Gdy Audytor uzna, że rozmowa któregoś bota jest zbyt długa, może zaproponować utworzenie jego kopii. Przenosi do niej pamięć, umiejętności i rutyny. Ja sprawdzam, czy wszystko działa, a dopiero potem mogę zarchiwizować lub usunąć starą wersję. Nowy bot zachowuje potrzebne ustawienia, lecz zaczyna z pustym czatem.
Jest też prostszy sposób na rozpoczęcie świeżej rozmowy: w aplikacji komputerowej można wybrać „Nowy czat” i wskazać istniejącego bota. Zachowa on swoje instrukcje i pamięć, ale nowa konwersacja nie będzie zawierała poprzedniej wymiany wiadomości.
Nocny audyt projektu
Następny przykład dotyczy mojego projektu Tumforge, aplikacji do tworzenia miniatur z pomocą agenta AI. „Nightly Audit Engineer”, bot z kolekcji zespołu Grokbota, co noc przegląda repozytorium i rano zostawia propozycję poprawek.
U mnie jego rutyna uruchamia się o czwartej rano. Bot łączy się z GitHubem przez integrację MCP. Godzinę i sposób działania można dostosować do własnego projektu.
Przed uruchomieniem nowej rutyny według harmonogramu zawsze warto wykonać próbę. Pozwala sprawdzić dostęp do repozytorium i wychwycić błędy konfiguracji, zanim zaczną powtarzać się każdego dnia. Trzeba przy tym pamiętać, że takie uruchomienie działa na prawdziwych danych, a nie na ich próbnej kopii.
Nocny audyt kończy się propozycją zmian w repozytorium, czyli pull requestem. Jej pojawienie się budzi następnego bota.
Eli przekazuje poprawkę agentom na komputerze
„Eli” czeka na nowy pull request w repozytorium Tumforge. Gdy ten się pojawi, uruchamia na moim komputerze narzędzie HerdR i przekazuje mu zadanie. W HerdR mogą współpracować agenci korzystający między innymi z Claude Code i Codex.
Jeden model koordynuje pracę. Może przekazać część zadania innemu modelowi albo sam przygotować prostą poprawkę, a następnie poprosić o jej sprawdzenie. Pokazuję sesję, w której modele pracują nad niewielką zmianą i przeprowadzają jej przegląd.
Rano nie muszę zaczynać od samodzielnego szukania rzeczy do poprawy. Dostaję gotową propozycję i informację od Eli. Przeglądam ją, po czym decyduję, czy zmiany przyjąć i wysłać dalej, czy je odrzucić. Ostateczna decyzja należy do mnie.
Timy zarządza pracą, którą sam zlecam
Najbardziej rozbudowany bot to „Timy”. Korzystałem z inspiracji systemem pokazanym przez Adama Gospodarczyka podczas webinaru Brave, a potem zbudowałem własny sposób pracy z Claude Code i Codex.
Zwykle wszystko zaczyna się ode mnie: określam cel i zatwierdzam zakres. Robię to w rozmowie z Timym. Bot przygotowuje propozycję, sprawdza zadania z listy projektu i pokazuje, co zamierza zrobić. Dopiero kiedy wpiszę „go”, uruchamia przebieg na moim Macu.
Na komputerze startuje HerdR z modelem koordynującym pracę. Ten rozpisuje zadania, dobiera modele do ich wykonania, obserwuje postęp i sprawdza wynik. Model wykonujący zadanie przygotowuje zmianę i uruchamia testy. Jeśli coś jest nie w porządku, koordynator odsyła ją do poprawy. Przy trudniejszych zadaniach może wybrać mocniejszy model; gdy dany model jest niedostępny, sięga po inny.
W mojej konfiguracji wybór zależy od rodzaju pracy. Do specyfikacji i trudnych decyzji mogę użyć mocniejszego modelu, a prostsze zadania powierzyć tańszemu. Ważniejsza od samych nazw modeli jest zasada: Grokbot przyjmuje zlecenie i przekazuje je dalej, natomiast dłuższa praca nad kodem odbywa się na moim komputerze. W całym procesie korzystam także z pakietu narzędzi Mata Pococka oraz przygotowanej przeze mnie umiejętności „go loop”, która pomaga agentom kontynuować pracę przez dłuższy czas.
Gdy lokalny przebieg się kończy, system zapisuje stan i raport. Następnie wysyła webhook, który budzi Timiego. Bot odczytuje wynik i przekazuje mi informację. Pracuję nad tym, by odzywał się tylko wtedy, gdy zadanie zostało ukończone, coś się zablokowało albo potrzebna jest moja decyzja. Zbyt częste meldunki zajmowałyby miejsce w rozmowie i zużywały limit.
Pilnuję również długości sesji modeli działających w HerdR. W mojej konfiguracji przy wykorzystaniu 40 procent dostępnego kontekstu pojawia się ostrzeżenie. Przy 45 procentach model przygotowuje podsumowanie dotychczasowej pracy, po czym może wznowić zadanie w świeższej sesji. Ma to ograniczać problemy, które pojawiają się, gdy rozmowa agenta staje się zbyt długa.
Pokazuję przykład zadania z mojej listy. Timy sprawdził jego opis i powiązane materiały, przedstawił mi zakres prac, a po otrzymaniu „go” uruchomił koordynatora w HerdR. Mogłem otworzyć sesję i zobaczyć zarówno pracę modelu zarządzającego, jak i modelu wykonującego poszczególne zadania.
Całość łączy się z wcześniejszym przykładem. W nocy Nightly przygotowuje propozycję poprawki. Eli przekazuje ją agentom na komputerze. Rano przeglądam wynik. Timy prowadzi z kolei prace, które sam mu zlecam. Chciałbym jeszcze połączyć go z listą zadań tak, aby dodanie nowej pozycji mogło uruchamiać odpowiedni proces.
Mniej pilnowania, mniej powiadomień
Zacząłem od Konsjerża, który przypomina mi o wyjeździe, a skończyłem na Timym, który organizuje pracę nad kodem pod moją nieobecność. W obu przypadkach chodzi mi o to samo: powtarzalne czynności mają zajmować mniej mojego czasu.
Dlatego boty powinny pracować, kiedy są potrzebne, i zgłaszać sprawy wymagające uwagi. Jeśli nic się nie zmieniło, mogą milczeć. Jeśli zadanie się nie udało, powinienem o tym wiedzieć.