Co się dzieje, gdy planujesz duży projekt bez osoby decyzyjnej? Większość stosów oprogramowania zakłada istnienie pojedynczego orkiestratora. Jeden proces zarządza stanem, kolejkuje zadania i przydziela prace. Jeśli ten koordynator zostanie zrestartowany, cały przepływ pracy napotyka problemy. Nowy projekt całkowicie odwraca to założenie. Pokazuje, jak rój agentów AI może rozbić cel, taki jak „zaplanuj dwutygodniową podróż do Japonii”, na pełne drzewo zadań, bez konieczności posiadania pojedynczego węzła, który w dowolnym momencie posiadałby kompletny plan.

Dlaczego warto budować system bez lidera?

Scentralizowani planiści są łatwi w analizie. Wysyłasz żądanie do serwera, on dzieli pracę, a pracownicy raportują wyniki. Problem polega na tym, że serwer staje się wąskim gardłem poznawczym i fizycznym. To on posiada prawdę.

W rozproszonej konfiguracji prawda zmienia się w obraz współdzielony przez sieć, do którego dąży ona poprzez protokół gossip. Ta konkretna implementacja w języku Python łączy dwa odrębne pojęcia. Pierwszym jest iteracyjna pętla ulepszania: jeden agent tworzy propozycję, drugi ją ocenia, a trzeci dopracowuje. Drugim jest warstwa sieci peer-to-peer zbudowana na libp2p, która pozwala agentom automatycznie odkrywać się nawzajem bez rejestru czy load balancera. Wynikiem jest klaster, w którym rówieśnicy (peers) pojawiają się, proponują, głosują i wykonują zadania, nie wymagając obecności dyrygenta.

Cztery role

System przypisuje każdemu uczestnikowi jedną z czterech osobowości. Nie potrzebujesz do tego czterech fizycznych maszyn. Mogą one współistnieć na jednym laptopie lub być rozproszone w sieci domowej. Role to:

  • Dekompozytor. Ten agent otrzymuje cel nadrzędny i proponuje jego podział na cele podrzędne. Ponieważ system uruchamia wielu dekompozytorów równolegle, możesz otrzymać trzy różne scenariusze tej samej podróży do Japonii. Jeden może podzielić podróż według geografii: Tokio, Kioto, Osaka. Inny może podzielić ją według aktywności: transport, zakwaterowanie, wyżywienie, zwiedzanie. Trzeci może uporządkować ją według dni. Sieć bierze pod uwagę wszystkie te propozycje.

  • Scorer. Agenci ci pełnią rolę redakcji. Analizują zaproponowany podział i oceniają go. Wynik odzwierciedla to, czy cele podrzędne są wystarczająco konkretne, nie nakładają się na siebie i są zbiorczo wyczerpujące. Co ważniejsze, scorer decyduje, czy propozycja jest wystarczająco dobra, aby ją przyjąć. Bez jego błogosławieństwa podział pozostaje w zawieszeniu.

  • Executor. Gdy drzewo osiągnie węzły liściaste na tyle małe, by móc je wykonać, executorzy ścigają się, aby je przejąć. Nie czekają na pozwolenie z centralnej kolejki. Zamiast tego używają protokołu znaczników czasu (timestamp), aby ustalić, kto ma pierwszeństwo do zadania. Zwycięzca wykonuje zadanie poprzez lokalne wywołanie LLM i rozgłasza wynik.

  • Obserwator. To osoba stojąca z boku, której potrzebuje każda sieć. Słucha po cichu komunikatów gossip, rekonstruuje drzewo planu z szumu informacyjnego i wyświetla czytelną migawkę stanu. Ponieważ nigdy nie zabiera głosu, udowadnia ważną kwestię: każdy, kto dołączy później, może poznać cały plan tylko dzięki podsłuchiwaniu.

Gossip jako źródło prawdy

Warstwa libp2p obsługuje odkrywanie i przesyłanie wiadomości. Agenci znajdują się nawzajem dzięki wbudowanemu w protokół mechanizmowi peer discovery, a następnie rozgłaszają wiadomości na wspólnym temacie. Nie ma tu głównej bazy danych ani pamięci cache Redis przechowującej kanoniczny plan.

Każdy peer przechowuje własną kopię drzewa planu i aktualizuje ją na podstawie słyszanych komunikatów gossip. Gdy dekompozytor rozgłasza propozycję, każdy inny węzeł ją otrzymuje, waliduje format i dodaje gałąź do swojego lokalnego drzewa. Gdy scorerzy oddają głosy, wynik głosowania rozprzestrzenia się w ten sam sposób. Jeśli dwaj executorzy opublikują sprzeczne roszczenia do tego samego zadania, protokół znaczników czasu rozwiązuje kolizję. Sieć akceptuje wcześniejsze roszczenie i odrzuca późniejsze.

Z czasem drzewo rośnie w dół od oryginalnego celu, przechodząc przez kolejne warstwy zaakceptowanych celów podrzędnych, aż dotrze do małych, łatwych do wykonania zadań. Proces ten przypomina osiąganie konsensusu przez blockchain, z tą różnicą, że ładunkiem jest plan podróży lub specyfikacja oprogramowania, a nie księga rachunkowa monet.

Głosowanie i wyścig do wykonania

Demokracja jest kosztowna, a ten system płaci za nią opóźnieniem (latency). Podział wygrywa tylko wtedy, gdy wystarczająca liczba scorerów się na niego zgodzi. Próg ten może być prostą większością głosów lub surowszym kworum, w zależności od konfiguracji klastra. Dekompozytorzy nie przestają proponować, więc sieć często ocenia kilka rywalizujących drzew jednocześnie. W końcu jedno z nich zdobywa wymaganą liczbę głosów, a jego cele podrzędne przechodzą ze statusu roboczego do zaakceptowanych.

Wykonawcy dodają kolejną warstwę koordynacji. Ponieważ zadania są publiczne na kanale gossip, wielu wykonawców może próbować przejąć ten sam atrakcyjny węzeł liściasty. Protokół znaczników czasu pełni rolę rozstrzygającą. Każde zgłoszenie posiada monotoniczny znacznik czasu, a sieć honoruje ten najwcześniejszy. Przegrany po prostu przechodzi do następnego dostępnego zadania. Jest to rozwiązanie uproszczone, ale pozwala uniknąć konieczności stosowania centralnego schedulera blokującego wiersze w bazie danych.

Odporność wpisana w projekt

Architektura pokazuje swoją wartość, gdy dochodzi do awarii. Jeśli dekompozytor ulegnie awarii po zaproponowaniu połowy podcelów, pozostałe dekompozytory kontynuują oferowanie podziałów. Plan nie zostaje wstrzymany w oczekiwaniu na ponowne uruchomienie. Jeśli scorer zostanie rozłączony z siecią, pozostali głosujący wciąż mogą osiągnąć kworum, o ile klaster został odpowiednio skalibrowany.

Prawdziwą korzyścią są późne dołączenia. Nowy agent, który uruchamia się w połowie procesu, nie potrzebuje migawki ani