Cursor Accidentally Exposed Grok Bot's Blueprint

O czym jest ten film

1. Zespół Cursora przypadkowo ujawnił fragmenty kodu Grokbota, a jedna osoba zrekonstruowała z nich większość architektury i opublikowała ją.
2. Autor przeanalizował tę rekonstrukcję, żeby zrozumieć, jak agenci się komunikują, przydzielają role i ustalają kolejność pracy.
3. Kluczowe odkrycie: agenci nie dzielą jednego wielkiego mózgu — każdy ma własne imię, zadanie, historię rozmowy i prywatne notatki.
4. Wymiana wiedzy odbywa się przez wiadomości i DM-y — narzędzie send to agent pozwala jednemu agentowi „obudzić” drugiego.
5. Komunikacja działa równolegle: agent nie musi przerywać pracy, żeby przyjąć notatkę od innego.
6. Wiadomości mają poziomy pilności — zwykłe czekają, priorytetowe potrafią anulować zadanie w tle i zmienić kierunek pracy.
7. Rozmowa użytkownika z systemem ma zawsze pierwszeństwo i nie jest przerywana.
8. Gdy potrzebna jest decyzja, a nie przekazanie gotowej pracy, agenci zwołują naradę prowadzoną przez menedżera — każdy może się wypowiedzieć albo spasować.
9. Każdy agent dostaje własny „komputer” z własnym ekranem w ramach większego sandboksa; uprawnienia działają podobnie do trybu auto w Claude Code.
10. Autor odtworzył własną wersję takiego systemu, działającą na subskrypcji Codex, OpenRouterze i modelach lokalnych.

Redakcyjne tłumaczenie

Skąd wziął się ten materiał

Wygląda na to, że zespół Cursora przez pomyłkę ujawnił fragmenty kodu Grokbota. Pewien człowiek zdołał zrekonstruować z tego większość całości i udostępnił ją publicznie. Post zebrał ponad milion wyświetleń, więc naturalnie sam też musiałem to przejrzeć i zrozumieć, jak działa każdy element Grokbota.

Po zajrzeniu pod maskę rozumiem już, jak agenci się ze sobą komunikują, jak przydzielają sobie role, jak decydują, który z nich ma pracować pierwszy, a wreszcie — jak wspólnie prowadzą naradę. Kiedy poznałem te techniki, byłem w stanie odbudować własną wersję Grokbota, która działa na mojej subskrypcji Codeksa, na OpenRouterze, a nawet na modelach lokalnych.

Niezależnie więc od tego, czy jesteś użytkownikiem Grokbota i chcesz po prostu zrozumieć, jak on działa, czy chcesz zbudować własną wersję — ten materiał rozłoży na czynniki pierwsze wszystkie części, które naprawdę mają znaczenie.

Zastrzeżenie na wstępie

Skoro większość ludzi, którzy pokochali Grokbota, ceni sobie przede wszystkim interakcje między agentami — to, jak pracują i jak wszystko wydaje się gotowe do użycia od ręki — na tych aspektach się skupię.

Zanim zaczniemy, ważna uwaga: repozytorium, które pokazałem, nie było kompletne. To nie był cały kod. To była zrekonstruowana wersja wielu elementów, które wyciekły. Ale patrząc na te elementy, naprawdę da się zrozumieć, jak wszystko ze sobą współgra. Przejdę więc przez każdą część krok po kroku i podam przykład, żeby utrwalić pojęcie.

(Informacja dodatkowa: „Grokbot” to w tym materiale nazwa produktu agentowego omawianego przez autora; transkrypcja automatyczna zapisuje ją miejscami jako „Rockbot” — chodzi o to samo narzędzie.)

Każdy agent ma własny mózg, nie wspólny

Mogłoby się wydawać, że wszyscy ci agenci dzielą jeden wielki mózg i jedną bazę pamięci. Za kulisami tak to jednak nie działa. Każdy agent ma własne imię, własne zadanie, własną historię rozmowy, a nawet własne prywatne notatki. W tym układzie agent-badacz może zebrać całą serię informacji, o których będzie wiedział wyłącznie on.

Jak zatem dzielą się tym, co wiedzą? Wysyłają do siebie wiadomości i prywatne notatki. To nie jest zupełnie nowa koncepcja. Jeśli pamiętasz, jeszcze w lutym Claude Code wypuścił zespoły agentów. Cała idea polegała na tym, że każdy agent miał własną skrzynkę pocztową i wysyłali sobie nawzajem informacje o tym, kto nad czym pracuje, co kogo blokuje i co ma pierwszeństwo. Mieliśmy też agent mail — cały framework, z którego może korzystać dowolny model językowy i dowolny zespół czy rój agentów, żeby robić dokładnie to samo.

Jeśli więc zlecisz swojemu Grokbotowi zbadanie tematu, zbudowanie aplikacji i przetestowanie jej, powoła on badacza, który wyciągnie potrzebne informacje, a następnie przekaże budowniczemu najistotniejsze punkty. Kiedy budowniczy skończy, szturchnie recenzenta, żeby ten przyjrzał się temu, co powstało. Każdy z nich wykonuje inną pracę i zaczyna z innym zestawem faktów.

Narzędzie send to agent i praca równoległa

Pod spodem działa narzędzie o nazwie send to agent — to właśnie ono pozwala agentom pisać do siebie prywatnie. Mechanizm wygląda tak: agent A może uznać, że musi przekazać notatkę agentowi B, żeby go obudzić. A jeśli agent B nadal aktywnie nad czymś pracuje, nie zajrzy do kolejnej notatki, chyba że jest pilna.

Jeśli jesteś w połowie budowy, a badacz znalazł trzy bardzo przydatne zadania dla budowniczego, który już pracuje, może z wyprzedzeniem podrzucić mu notatkę, żeby ten uwzględnił to w kolejnych krokach — a sam może pracować dalej. Jeden nie musi się zatrzymywać, żeby drugi mógł działać. Obaj mogą pracować równolegle: notatka zostaje przekazana, budowniczy bierze ją pod uwagę w następnych fazach, a badacz idzie dalej.

Nie musisz więc wyłączać poszczególnych agentów tylko po to, żeby mogli się porozumieć. Mogą komunikować się w trakcie pracy i mogą uznać, że ich zadanie wcale nie jest skończone — w świetle nadrzędnego celu, który postawiłeś całemu zespołowi.

Priorytety i przerwania

Co się dzieje, gdy agent jest zajęty, a przychodzi nowa wiadomość? Jeśli to zwykła wiadomość, agent może ją zignorować do czasu ukończenia bieżącego zadania. Ale jeśli jest oznaczona jako priorytetowa albo skrajnie pilna, przeskanuje ją i faktycznie anuluje zadanie działające w tle, zmieniając kierunek.

Jedyną rzeczą, której nie przerwie, jest twoja rozmowa z systemem. To ty jako użytkownik masz pierwszeństwo — ale wszystko inne może zostać przerwane, zależnie od stopnia pilności.

Powiedzmy, że aplikacja, nad którą pracujesz, jest już w produkcji, a ty znajdujesz na stronie z cennikiem drobny problem z animacją, który chcesz poprawić. W trakcie tej poprawki system odkrywa, że zepsuty jest proces płatności. Wtedy interweniuje, przerywa dotychczasowy proces i stawia naprawę płatności na pierwszym miejscu — o ile twoja bieżąca wymiana zdań z botem została zakończona.

Narada przy okrągłym stole

Prywatne wiadomości świetnie sprawdzają się do przekazywania pracy, która jest już dopracowana i nie wymaga ocennych decyzji. Ale jeśli trzeba coś rozstrzygnąć i odbyć dyskusję, agenci mogą zebrać się przy okrągłym stole, tak jak zrobiliby to ludzie.

Żeby taki grupowy czat nie skończył się chaosem, zwykle wyznacza się menedżera, który obchodzi stół i pyta: „Czy masz coś do wniesienia do tej rozmowy?”. Każdy się wypowiada, a jeśli dany agent nie ma nic do dodania, wolno mu spasować. Możesz więc mieć serię rund, w których zabiera głos tylko jeden czy dwóch agentów.

Jeśli wypuszczasz coś na produkcję i chcesz zapytać: „Czy jesteśmy gotowi do startu?”, możesz zwołać taką rozmowę. Badacz powie „tak”. Budowniczy może powiedzieć „wszystko przeszło testy”. Ale QA stwierdzi: „coś jest zepsute”. A operator, patrząc na całość, pasuje, bo nie ma nic wartościowego do wniesienia akurat w tej sprawie. Wnioskiem z narady — kolejnym krokiem — będzie naprawienie tego, co zostało zidentyfikowane. Dzięki temu rozmowa jest znacznie efektywniejsza i maleje ryzyko niekończących się dyskusji o niczym, w których modele wciąż halucynują.

Własne imię, własna skrzynka, własny ekran

Kolejną rzeczą, którą ludzie kochają w swoich Grokbotach, jest wrażenie, że agenci są niezależni, jakby mieli własne życie i osobowość. Bierze się to stąd, że — jak już wiemy — mają własne imię, przypisane zadanie, własną skrzynkę i sposób komunikacji, a do tego własny komputer z własnym ekranem. Model AI jest pracownikiem, a komputer jego biurkiem.

Gdybyś powiedział: „zbuduj tę aplikację, przetestuj ją i zrecenzuj”, wszyscy ci agenci powołaliby własne ekrany, a na tych ekranach działyby się różne rzeczy. Badacz miałby serię kart przeglądarki, z których pobiera materiały. Budowniczy mógłby użyć ekranu tylko po to, żeby otworzyć terminal i wprowadzić zmiany w aplikacji. A QA renderowałby albo lokalny serwer uruchomiony przez ten terminal, albo prowadził własną, niezależną pracę.

Narzędzia, wtyczki i uprawnienia

Jeśli chodzi o narzędzia, wtyczki i uprawnienia, Grokbot działa bardzo podobnie do trybu auto w Claude Code. W zależności od zadania i jego wagi sam decyduje, czy potrzebuje twojej zgody. Nawet jeśli dasz mu kartę kredytową, żeby autonomicznie robił zakupy, przez pierwszych kilka razy będzie pytał, czy to w porządku. Kiedy zrozumie, że tak, dopisze to do listy zaakceptowanych uprawnień i od tej pory będzie działał samodzielnie.

Wracając do wcześniejszego przykładu: publikujesz ponownie stronę z cennikiem po naprawieniu płatności. Edycja plików zostanie dopuszczona automatycznie. Testowanie również. Ale przy drugiej czy trzeciej próbie publikacji system dwa i trzy razy upewni się, czy na pewno o to chodzi.

Sześć elementów, w których leży cały sekret

Można oczywiście schodzić coraz głębiej i doszukiwać się kolejnych szczegółów i drobnego druku, ale wygląda na to, że sekretny składnik Grokbota sprowadza się do sześciu elementów:

1. Interfejs.
2. Warstwa orkiestracji, w której ustala się, który agent działa jako następny i w jakiej kolejności.
3. Wiadomości — pokój pocztowy i kanał prywatnych notatek.
4. Warstwy pamięci.
5. Osobny ekran dla każdego agenta, będący częścią większego sandboksa.
6. Model, który to wszystko napędza pod spodem.

Własna wersja: aplikacja Grokky

Mając to zrozumienie, można dosłownie podać ten transkrypt modelowi i zbudować coś takiego, co zbudowałem ja. Wchodzę do aplikacji Grokky, powołuję kilku agentów, klikam na agenta-eksploratora i agenta-wykonawcę, i pytam: „Czy możesz przeprowadzić pogłębione badanie i powiedzieć mi, jakie są najnowsze funkcje Grokbota?”.

Da się odtworzyć dokładnie to samo środowisko: masz własny pokój pocztowy, w którym każdy z agentów czeka w kolejce, dopóki zadanie nie zostanie zrozumiane, odbywają krótką naradę, przekazują sobie zadanie pierwsze i drugie, a na końcu jest lider, który przygląda się wszystkiemu, co dzieje się pod spodem. Kiedy skończą, dostajesz to samo doświadczenie: odpowiedź w pełni skomponowaną przez różnych agentów, którzy pracują komunikując się ze sobą, składają razem różne fragmenty kontekstu i dostarczają jedną spójną odpowiedź o niesamowitym poziomie szczegółowości.

Najlepsze jest to, że możesz zbudować własną wersję opartą na subskrypcji, którą już masz, bez dopłacania za zużycie. A co ważniejsze — nie musisz czekać, aż zewnętrzny zespół zdecyduje, kiedy wypada zwiększyć limity albo dodać nowe funkcje, bo wszystko to jest w pełni pod twoją kontrolą.

Wskazówka eksperta

Użyłem Codeksa nie tylko do zbudowania tej aplikacji, ale też do computer use — żeby przyjrzeć się działaniu i zachowaniu aplikacji Grokbota, tak aby móc je faktycznie obejrzeć, naśladować i odtworzyć.

(Informacja dodatkowa: computer use to tryb, w którym model steruje komputerem — klika, przewija i czyta ekran — zamiast operować wyłącznie tekstem.)

A jeśli chcesz zaimportować swoje umiejętności z Codeksa albo Claude Code — do czego możesz też wykorzystać SDK — możesz to zabrać, stworzyć i zbudować cały zespół agentów, stale go rozbudowywać i odtworzyć całą tę orkiestrację wieloagentową, którą znasz i lubisz z narzędzi pokroju Grokbota.

Mam nadzieję, że to rozjaśnia wszystkie tajemnice kryjące się pod maską Grokbota — żebyś lepiej rozumiał, jak go używać, jak go wykorzystać, albo, jak pokazałem, jak odtworzyć go na własnych zasadach i na własnym sprzęcie.

10 najważniejszych takeaways — z kontekstem zastosowania

1.Nie buduj jednej wspólnej pamięci dla wszystkich agentów

Na czym polega: W Grokbocie każdy agent ma osobne imię, zadanie, historię rozmowy i prywatne notatki. Nie ma jednego wielkiego mózgu — wiedza badacza nie trafia automatycznie do budowniczego.

Jak stosować: Projektując własny zespół agentów, domyślnie izoluj konteksty i dopiero świadomie decyduj, co jest przekazywane dalej. Wymusza to selekcję najistotniejszych informacji, zamiast zalewania wszystkich wszystkim.

Na co uważać: Izolacja oznacza, że coś ważnego może nie dotrzeć tam, gdzie trzeba. Potrzebujesz jawnego kanału przekazywania i kogoś, kto pilnuje, że kluczowe ustalenia rzeczywiście zostały przesłane.

2.Komunikacja przez wiadomości, nie przez wspólny stan

Na czym polega: Agenci wymieniają się wiedzą, wysyłając sobie wiadomości i prywatne notatki przez narzędzie send to agent, które potrafi „obudzić” adresata.

Jak stosować: Zbuduj warstwę skrzynek pocztowych jako podstawowy mechanizm koordynacji. Autor wskazuje, że to nie jest nowość — zespoły agentów w Claude Code i framework agent mail robią dokładnie to samo i można ich użyć zamiast pisać wszystko od zera.

Na co uważać: Mechanizm „budzenia” trzeba mieć pod kontrolą — inaczej agenci będą wybudzać się nawzajem w kółko i generować ruch, który nie posuwa zadania do przodu.

3.Praca równoległa zamiast sztafety

Na czym polega: Agent nie musi kończyć pracy, żeby przekazać notatkę. Badacz, który w trakcie budowy znajdzie trzy przydatne rzeczy, podrzuca je budowniczemu i pracuje dalej, a budowniczy uwzględnia je w kolejnych fazach.

Jak stosować: Zamiast projektować sztywny łańcuch „badanie → budowa → testy”, pozwól etapom się nakładać i przekazuj ustalenia przyrostowo. Skraca to czas oczekiwania i pozwala korygować kurs w trakcie.

Na co uważać: Notatka, która przychodzi w połowie pracy, potrafi zdestabilizować to, co już powstało. Warto, żeby wiadomość trafiała do „kolejnych kroków”, a nie kazała przerabiać tego, co jest już gotowe.

4.Trzy poziomy pilności wiadomości

Na czym polega: Zwykła wiadomość czeka, aż agent skończy bieżące zadanie. Priorytetowa lub skrajnie pilna zostaje przeskanowana natychmiast i może anulować zadanie działające w tle oraz zmienić kierunek pracy.

Jak stosować: Wprowadź w swoim systemie jawną klasyfikację pilności i zdefiniuj, co dokładnie uprawnia do przerwania. Bez tego albo wszystko przerywa wszystko, albo nic nie przerywa niczego.

Na co uważać: Inflacja priorytetów. Jeśli agenci sami oznaczają wiadomości jako pilne, szybko wszystko stanie się pilne i mechanizm przestanie mieć sens.

5.Rozmowa z użytkownikiem jest nietykalna

Na czym polega: Jedyną rzeczą, której system nie przerwie, jest twoja bieżąca wymiana zdań z botem. Wszystko inne może zostać przerwane w zależności od wagi sprawy.

Jak stosować: Ustal tę zasadę jako twardy wyjątek w swojej orkiestracji. Użytkownik ma zawsze pierwszeństwo, a przerwania obsługuj dopiero po zamknięciu wątku z człowiekiem.

Na co uważać: Odwrotna strona medalu: krytyczna naprawa może czekać, dopóki trwa rozmowa. W przykładzie z filmu zepsuty proces płatności zostaje naprawiony dopiero po zakończeniu wymiany zdań z użytkownikiem.

6.Poważny problem wypycha drobiazg z kolejki

Na czym polega: Prosisz o poprawkę animacji na stronie z cennikiem, a system przy okazji odkrywa, że zepsuty jest checkout — interweniuje i stawia naprawę płatności na pierwszym miejscu.

Jak stosować: Daj agentom prawo do zgłoszenia, że znaleźli coś ważniejszego niż zlecone zadanie, i zdefiniuj kryteria przewartościowania priorytetów.

Na co uważać: Agent, który sam przestawia priorytety, może zejść z zadania, na którym ci zależało. Warto wymagać, żeby zmiana kierunku była jawnie zakomunikowana użytkownikowi.

7.DM-y do przekazywania pracy, narada do decyzji

Na czym polega: Prywatne wiadomości nadają się do przekazywania dopracowanej pracy, w której nie ma miejsca na ocenne rozstrzygnięcia. Gdy trzeba coś zdecydować, agenci zwołują naradę przy okrągłym stole.

Jak stosować: Rozdziel te dwa tryby w swoim systemie. Nie zwołuj narady po to, żeby przekazać gotowy wynik, i nie próbuj rozstrzygać spornej kwestii pojedynczą notatką.

Na co uważać: Narada kosztuje — to wiele tur modelu. Rezerwuj ją na realne rozstrzygnięcia, takie jak pytanie „czy jesteśmy gotowi do wdrożenia?“.

8.Menedżer narady i prawo do spasowania

Na czym polega: Żeby grupowy czat nie skończył się chaosem, naradę prowadzi menedżer, który obchodzi stół i pyta każdego, czy ma coś do dodania. Kto nie ma — pasuje. Efekt: w danej rundzie odzywa się często tylko jeden czy dwóch agentów.

Jak stosować: Wpisz obie rzeczy w prompt narady: rotacyjne oddawanie głosu przez moderatora i wyraźne przyzwolenie na milczenie. Kończ naradę konkretnymi krokami do wykonania.

Na co uważać: Bez prawa do spasowania modele będą się wypowiadać zawsze, generując treść bez wartości. Autor wprost wskazuje, że to główny mechanizm ograniczający niekończące się dyskusje i halucynacje.

9.Każdy agent dostaje własny ekran w sandboksie

Na czym polega: Model to pracownik, a komputer to jego biurko. Badacz ma karty przeglądarki, budowniczy terminal, QA renderuje lokalny serwer. Wszystko w ramach większego sandboksa.

Jak stosować: Rozdziel środowiska wykonawcze między role, zamiast puszczać wszystkich agentów przez jedną sesję. Ogranicza to kolizje i sprawia, że widać, kto co faktycznie robi.

Na co uważać: To poważny narzut infrastrukturalny. Autor pokazuje też, że wrażenie „samodzielności i osobowości” agentów bierze się głównie z tego rozdzielenia — nie myl go z faktycznie wyższą jakością pracy.

10.Własna replika daje kontrolę nad kosztem i tempem rozwoju

Na czym polega: Autor odtworzył zbliżony system na subskrypcji Codeksa, OpenRouterze i modelach lokalnych. Nie dopłaca za zużycie i nie czeka, aż zewnętrzny zespół podniesie limity albo doda funkcje.

Jak stosować: Jeśli już płacisz za subskrypcję Codeksa czy Claude Code, możesz oprzeć na niej własną orkiestrację, a umiejętności zaimportować przez SDK. Autor sugeruje też podejście pomocnicze: użyć computer use, żeby obserwować zachowanie oryginału i je naśladować.

Na co uważać: Punktem wyjścia jest niekompletna rekonstrukcja wycieku, a nie oficjalna dokumentacja — sam autor to zaznacza. Traktuj opisane mechanizmy jako wzorce projektowe do przemyślenia, a nie jako pewny opis tego, co faktycznie działa w produkcie.