Jeden Bot zbiera dane, drugi nimi zarządza. Przykład z katalogu samochodów elektrycznych

tymcio · 28 Sierpień 2026 19:39

W poprzednich wpisach pokazaliśmy już, czym jest Grok Bot i jak można zbudować pierwszego własnego Bota.

Teraz czas na coś ciekawszego.

Nie musimy mieć tylko jednego Bota.

Możemy stworzyć ich kilka i podzielić między nimi pracę.

Każdy dostaje konkretną rolę, a Boty mogą przekazywać sobie wyniki.

Dobrym przykładem jest system do monitorowania rynku samochodów elektrycznych.

Przykład: automatyczny monitoring nowych modeli EV

Wyobraźmy sobie, że prowadzimy katalog samochodów elektrycznych.

Chcemy wiedzieć:

kiedy producent pokaże nowy model,
kiedy pojawi się nowa wersja istniejącego samochodu,
czy zmieniły się dane techniczne,
czy pojawiła się nowa bateria,
czy zmienił się zasięg,
czy producent podał nowe ceny,
czy samochód pojawił się na nowym rynku,
czy pojawiły się oficjalne informacje dotyczące premiery.

Problem jest prosty.

Producentów są setki.

Do tego dochodzą różne rynki.

Informacje pojawiają się na stronach producentów, w materiałach prasowych, chińskich serwisach, europejskich stronach oraz innych źródłach.

Ręczne sprawdzanie wszystkiego byłoby bardzo czasochłonne.

I tutaj możemy podzielić pracę pomiędzy Boty.

Bot 1 – EV Researcher

Pierwszy Bot zajmuje się wyłącznie zbieraniem informacji.

Nie podejmuje decyzji o tym, co trafia do katalogu.

Nie publikuje danych.

Nie zmienia rekordów.

Jego zadaniem jest znalezienie zmian i przekazanie ich dalej.

Co robi?

Bot może regularnie sprawdzać strony producentów samochodów:

Polskie

strony marek,
informacje prasowe,
polskie konfiguratory,
strony importerów.

Europejskie

europejskie strony producentów,
materiały prasowe,
informacje o premierach,
dane dotyczące poszczególnych rynków.

Chińskie

chińskie strony producentów,
materiały dotyczące nowych modeli,
chińskie wersje konfiguratorów,
informacje o zmianach specyfikacji.

Pozostałe rynki

Jeżeli producent ma osobną stronę dla USA, Japonii, Australii czy innych rynków, również można ją uwzględnić.

Grok Bot może korzystać z przeglądarki i pracować w stronach internetowych również wtedy, gdy nie ma wygodnego API.

Co dokładnie powinien robić Bot 1?

Możemy dać mu zadanie:

Sprawdź wskazane źródła producentów samochodów elektrycznych i porównaj znalezione informacje z aktualnymi danymi w katalogu. Szukaj nowych modeli, nowych wersji istniejących modeli oraz zmian w specyfikacji. Zwracaj uwagę na baterię, pojemność, zasięg, moc, napęd, wymiary, ładowanie, wyposażenie i ceny. Nie traktuj informacji z nieoficjalnych źródeł jako potwierdzonych danych producenta. Dla każdej znalezionej zmiany podaj źródło, datę oraz dokładnie opisz, co się zmieniło. Jeśli nie znajdziesz żadnej potwierdzonej zmiany, nie generuj fikcyjnych aktualizacji.

To już jest całkiem konkretny proces.

Bot nie ma pisać artykułu.

Nie ma wymyślać nowych samochodów.

Ma znaleźć zmianę i udokumentować ją.

Bot 1 powinien być trochę „nudny”

I to jest bardzo ważne.

Dobry Bot nie musi być kreatywny.

W przypadku katalogu samochodów chcemy czegoś zupełnie innego.

Chcemy, żeby był dokładny.

Jeżeli producent zmienił zasięg z 500 na 520 km, Bot ma to zauważyć.

Jeżeli pojawiła się nowa wersja samochodu, ma ją wskazać.

Jeżeli znalazł informację tylko w nieoficjalnym źródle, powinien to zaznaczyć.

Jeżeli niczego nie znalazł, powinien powiedzieć:

„Nie znalazłem potwierdzonych zmian”.

To często jest lepszy wynik niż próba znalezienia czegoś na siłę.

Bot 2 – Founder

Drugi Bot ma zupełnie inną rolę.

Nie jest researcherem.

Jest menedżerem całego procesu.

W tym przykładzie może nazywać się:

Founder

Jego zadaniem jest odbieranie informacji od innych Botów, ocenianie ich i decydowanie, co powinno wydarzyć się dalej.

To właśnie tutaj zaczyna się robić naprawdę ciekawie.

Bot 1 znalazł zmianę

Załóżmy, że Bot 1 znajduje informację:

BYD Sealion 7 otrzymał nową wersję na rynku chińskim.

Bot 1 przekazuje do Foundera:

model,
producenta,
rynek,
rodzaj zmiany,
stare dane,
nowe dane,
źródło,
datę znalezienia informacji,
poziom pewności,
ewentualne dodatkowe uwagi.

Founder dostaje taki materiał i zaczyna go analizować.

Founder sprawdza informację

Founder może sprawdzić:

Czy to rzeczywiście nowa wersja?

Czy źródło jest oficjalne?

Czy dane są kompletne?

Czy informacja nie dotyczy tylko chińskiego wariantu?

Czy w katalogu istnieje już taki model?

Czy zmiana dotyczy istniejącego rekordu, czy trzeba utworzyć nowy?

To bardzo ważne.

Pierwszy Bot znajduje informację.

Drugi Bot rozumie, co ta informacja oznacza dla naszego systemu.

Founder może poprosić o dodatkową weryfikację

Załóżmy, że Bot 1 znalazł informację na stronie producenta, ale dane są niepełne.

Founder może przekazać zadanie z powrotem:

Sprawdź jeszcze raz oficjalne źródła producenta i znajdź potwierdzenie pojemności baterii dla nowej wersji. Nie aktualizuj danych, dopóki nie znajdziesz wiarygodnego źródła.

Czyli nie mamy już prostego:

Bot → człowiek

Mamy:

Bot 1 → Founder → Bot 1 → Founder → człowiek

A człowiek pojawia się dopiero wtedy, kiedy naprawdę potrzebna jest jego decyzja.

Grok Bot został zaprojektowany właśnie z myślą o takich przekazaniach pracy między Botami. Bot może wysłać zadanie innemu Botowi, który przejmuje je i odpowiada później.

Founder podejmuje decyzję

Załóżmy, że informacja została potwierdzona.

Founder może stwierdzić:

To nowa wersja istniejącego modelu.

Wtedy aktualizujemy istniejący rekord.

Albo:

To zupełnie nowy model.

Wtedy trzeba utworzyć nowy rekord.

Albo:

To tylko informacja dotycząca rynku chińskiego.

Wtedy nie aktualizujemy europejskiej wersji samochodu.

Albo:

Informacja jest niepewna.

Wtedy trafia do człowieka do ręcznej weryfikacji.

To właśnie jest rola Bota zarządzającego.

Nie chodzi tylko o przekazywanie wiadomości.

Chodzi o podejmowanie decyzji zgodnie z ustalonymi zasadami.

A co dzieje się po mojej akceptacji?

Tutaj możemy zrobić kolejny etap.

Founder może przygotować dane w formacie, którego potrzebujemy.

Na przykład:

JSON

{
  "brand": "BYD",
  "model": "Sealion 7",
  "market": "CN",
  "change_type": "new_variant",
  "battery": "...",
  "range": "...",
  "source": "...",
  "verified": true
}

Albo:

Markdown

## BYD Sealion 7 – nowa wersja

Rynek: Chiny
Typ zmiany: nowa wersja

Bateria: ...
Zasięg: ...
Moc: ...

Źródło: ...
Data weryfikacji: ...

Albo dokładnie taki format, jakiego potrzebuje nasz system.

Dzięki temu Founder nie musi tylko powiedzieć:

„Znalazłem nowy model”.

Może przygotować gotowy materiał do dalszego wykorzystania.

A jeśli mamy API?

Wtedy możemy pójść jeszcze dalej.

Founder może po uzyskaniu akceptacji przekazać dane bezpośrednio do systemu.

Schemat może wyglądać tak:

Bot 1

↓
zbiera informacje

Founder

↓
weryfikuje

Founder

↓
prosi o akceptację

Człowiek

↓
akceptuje

Founder

↓
przygotowuje dane

API / baza danych

↓
aktualizuje katalog

Wtedy człowiek nie musi już ręcznie przepisywać danych.

Jego rolą jest przede wszystkim kontrola procesu i zatwierdzanie zmian.

Oczywiście wymaga to odpowiedniego połączenia Bota z naszym systemem. Grok Bot może korzystać z dostępnych konektorów/MCP, a także z obsługi komputera i stron internetowych, więc zakres możliwych integracji zależy od konkretnego środowiska.

Możemy dodać trzeciego Bota

I tutaj zaczyna się robić jeszcze ciekawiej.

Możemy stworzyć:

Bot 1 – Researcher

Znajduje informacje.

Bot 2 – Founder

Ocenia informacje i zarządza procesem.

Bot 3 – Data Manager

Przygotowuje i wprowadza dane do katalogu.

Wtedy każdy ma bardzo konkretną odpowiedzialność.

Researcher nie powinien zmieniać bazy.

Data Manager nie musi samodzielnie przeszukiwać internetu.

Founder nie musi ręcznie przepisywać danych.

Każdy robi swoją część.

Możemy dodać jeszcze Reviewera

Czwarty Bot może być kontrolerem jakości.

Po przygotowaniu danych sprawdza:

czy wszystkie wymagane pola są wypełnione,
czy format danych jest prawidłowy,
czy wartości mają właściwe jednostki,
czy nie ma sprzeczności,
czy źródło istnieje,
czy nowe dane nie nadpisują przypadkiem niewłaściwego modelu.

Dopiero wtedy materiał trafia do Foundera.

Powstaje więc mały zespół AI:

Researcher → Reviewer → Founder → Data Manager

A człowiek pozostaje właścicielem procesu.

Możemy uruchomić to według harmonogramu

Nie musimy codziennie pamiętać o uruchamianiu Researchera.

Możemy ustawić rutynę.

Na przykład:

Codziennie o 6:00

Researcher sprawdza strony producentów.

O 7:00

Founder analizuje nowe informacje.

O 7:30

Reviewer sprawdza przygotowane dane.

O 8:00

Founder przedstawia mi tylko informacje wymagające decyzji.

Grok Bot pozwala przypisywać Botom rutyny i uruchamiać powtarzalne procesy według harmonogramu. Boty mogą też pracować równolegle i przekazywać sobie zadania.

W praktyce rano nie muszę więc sprawdzać kilkudziesięciu stron producentów.

Dostaję tylko:

„Znaleziono 4 nowe modele i 7 zmian specyfikacji. 8 zmian zostało automatycznie odrzuconych jako niepotwierdzone. 3 wymagają Twojej decyzji.”

I to jest zupełnie inny sposób korzystania z AI.

To nie musi być katalog samochodów

Ten sam schemat można wykorzystać praktycznie wszędzie.

Sklep internetowy

Bot 1: sprawdza ceny konkurencji.

Bot 2: analizuje zmiany.

Bot 3: przygotowuje rekomendacje cenowe.

Człowiek: zatwierdza.

Bot 3: wprowadza zmiany.

Monitoring konkurencji

Bot 1: codziennie sprawdza strony konkurentów.

Bot 2: wykrywa nowe produkty, promocje i zmiany.

Bot 3: przygotowuje raport.

Founder: decyduje, co jest istotne.

SEO

Bot 1: monitoruje konkurencję i wyniki.

Bot 2: analizuje spadki i wzrosty.

Bot 3: przygotowuje propozycje zmian.

Człowiek: zatwierdza.

Monitoring rynku

Jeden Bot zbiera informacje z wielu źródeł.

Drugi je porównuje.

Trzeci przygotowuje raport.

Founder decyduje, które informacje mają znaczenie.

Programowanie

Jeden Bot zbiera zgłoszenia błędów.

Drugi próbuje odtworzyć problem.

Trzeci analizuje kod.

Czwarty przygotowuje propozycję poprawki.

To również jest zgodne z kierunkiem, który pokazuje xAI w swoich przykładach, np. w przypadku Bota do reprodukcji błędów czy orkiestracji wielu agentów.

Najważniejsza zasada: jeden Bot = jedna odpowiedzialność

Można oczywiście stworzyć jednego ogromnego Bota, który ma robić wszystko.

Tylko po co?

Jeżeli Bot ma jednocześnie:

szukać informacji,
oceniać ich wiarygodność,
zarządzać bazą,
pisać teksty,
analizować dane,
kontaktować się z użytkownikami,

to bardzo szybko robi się z tego trudny do kontrolowania chaos.

Lepszy jest podział.

Researcher ma znaleźć.

Reviewer ma sprawdzić.

Founder ma zdecydować.

Data Manager ma wykonać.

Każdy Bot ma konkretny cel, źródła, sposób pracy i granice odpowiedzialności. Dokumentacja Grok Bot również zaleca tworzenie osobnych Botów wtedy, gdy różnią się celem, narzędziami, stylem pracy, granicami akceptacji lub harmonogramem.

I właśnie tutaj Grok Bot zaczyna być naprawdę ciekawy

Największa zmiana nie polega na tym, że mamy kolejnego chatbota.

Chodzi o zmianę sposobu pracy.

Zamiast:

„Grok, znajdź mi informacje o nowych samochodach.”

możemy zbudować cały proces:

Bot zbiera → Bot sprawdza → Bot ocenia → Bot przekazuje → człowiek zatwierdza → Bot wykonuje.

A jeżeli proces działa dobrze, możemy uruchomić go automatycznie.

Wtedy AI nie jest już tylko narzędziem, do którego przychodzimy z pytaniem.

Staje się zespołem, któremu możemy przekazać konkretny fragment naszej pracy.

I właśnie od takich małych, konkretnych procesów warto zaczynać.