Jak Zero Noichi stworzył grę AI w Wilkołaka z dziesięcioma agentami

野市 零 / Zero Noichi pokazuje, co się dzieje, gdy dziesięciu agentów AI dzieli jedną grę w wilkołaka: wyzwaniem nie jest już generowanie błyskotliwej odpowiedzi, lecz koordynowanie głosów, ról, pamięci, czasu i konfliktów bez nadawania rozmowie mechanicznego charakteru.

W tym artykule dziękujemy 野市 零 / Zero Noichi za udokumentowanie eksperymentu w oryginalnym filmie o wilkołaku AI. Film przedstawia eksperyment rozrywkowy, ale ujawnia też problemy inżynieryjne stojące za wiarygodną aplikacją wieloagentową: jak sprawić, by agenci czekali, przerywali sobie, pamiętali, wprowadzali w błąd i reagowali jako członkowie jednego wspólnego świata.

Informacja o współpracy: Oryginalny opis odnosi się do ZimaBoard 2, kuponu dla twórców, linków afiliacyjnych oraz usług programowych wykorzystanych w eksperymencie. Twórca udostępnia własną implementację i opisuje zamierzony sposób jej wykorzystania. Wersje modeli, usługi głosowe, interfejsy, zestawy sprzętowe i zgodność mogą ulec zmianie po publikacji.

Rezultat: ZimaBoard 2 – miniaturowy serwer domowy nie zastępuje dużego klastra inferencyjnego, który uruchamia dziesięć najnowocześniejszych modeli z pełną szybkością. Jego bardziej realistyczną zaletą jest rola kompaktowego, stale działającego węzła sterującego i usługowego dla aplikacji AI: koordynowanie promptów, stanu gry, interfejsów API, potoków audio, logów i dostępu do sieci, podczas gdy cięższe zadania modelowe są przekazywane do najlepiej dopasowanej usługi lub ścieżki obliczeniowej.

Najlepiej postrzegać ten projekt jako system warstwowy. Model językowy dostarcza decyzji i dialogów, ale warstwa orkiestracji decyduje, czyja jest kolej, warstwa stanu określa, co wie każda postać, warstwa głosowa zamienia tekst na mowę, a warstwa prezentacji sprawia, że wynik jest zrozumiały dla widza. Usuń dowolną z tych warstw, a dziesięciu „inteligentnych” agentów szybko zmieni się w dziesięć niezależnych okien czatu.

Trudność tkwi we wspólnej rzeczywistości, a nie w liczbie agentów

Dodanie drugiego modelu do rozmowy jest łatwe w porównaniu z dodaniem drugiego modelu, który musi przestrzegać tych samych zasad. W grze w wilkołaki każda postać potrzebuje prywatnej roli, publicznej historii, przekonania na temat innych graczy oraz dozwolonego zestawu działań dla bieżącej fazy. Aplikacja potrzebuje więc jednego nadrzędnego stanu gry, zamiast pozwalać każdemu modelowi tworzyć własną wersję wydarzeń.

Solidny projekt rozdziela stan publiczny i prywatny. Stan publiczny może obejmować bieżący dzień, wypowiedziane twierdzenia, głosy oraz wyeliminowanych graczy. Stan prywatny może zawierać informacje o członkach drużyny wilkołaka, wynik widzącego lub ukryte podejrzenia postaci. Orkiestrator tworzy następnie inny kontekst dla każdego agenta, zamiast rozgłaszać wszystkim każdy sekret.

To rozdzielenie umożliwia także debugowanie. Jeśli agent wysuwa podejrzane oskarżenie, deweloper może sprawdzić dokładny publiczny zapis rozmowy, prywatną pamięć, prompt roli oraz odpowiedź modelu, które doprowadziły do jego sformułowania. Bez tych granic pozorna „inteligencja” może być po prostu przypadkowym wyciekiem informacji z jednego promptu do innego.

Prompty postaci wymagają czegoś więcej niż przymiotnika opisującego osobowość

Samo nazwanie jednego agenta „pewnym siebie”, a drugiego „cichym” nie wystarczy, by stworzyć obsadę. Przydatna definicja postaci łączy styl wypowiedzi, tolerancję ryzyka, cel, określoną dla roli granicę wiedzy oraz zasadę opisującą, jak dowody zmieniają przekonania. Postać powinna brzmieć inaczej, ale także podejmować decyzje z powodów, które pozostają spójne w kolejnych turach.

Każdy agent korzysta z uporządkowanego profilu zawierającego imię, rolę, publiczną personę, prywatny cel, znane fakty, bieżące podejrzenia oraz zwięzłą pamięć wcześniejszych wydarzeń. Prompt może następnie poprosić zarówno o wewnętrzną decyzję, jak i wypowiedź skierowaną do widzów, podczas gdy aplikacja przechowuje tylko pola potrzebne do kolejnej zmiany stanu. Dzięki temu kontekst pozostaje czytelny w miarę rozwoju gry.

Istnieje tu ważna granica. Dłuższy prompt nie tworzy automatycznie głębszej postaci. Jeśli każda tura powtarza cały zapis rozmowy i wszystkie instrukcje, rosną opóźnienia oraz koszty, a model nadal nie ma jasno określonej zmiany stanu. Mniejsza, starannie wyselekcjonowana pamięć często zapewnia bardziej spójne zachowanie niż nieprzefiltrowany zrzut rozmowy.

Zmiana modelu zmienia rytm gry

Film przedstawia wybór modeli LLM jako część eksperymentu, zamiast traktować „AI” jako jeden wymienny komponent. W projekcie jako komponent modelu językowego wymieniono Moonshot Kimi K3, a wybór ten wpływa nie tylko na jakość odpowiedzi, lecz także na ich długość, opóźnienia, sposób odmawiania, styl języka oraz ilość kontekstu, którą można zachować między kolejnymi turami.

Praktyczna architektura może przypisywać różne zadania różnym modelom. Mocniejszy model może zajmować się trudnym, prywatnym wnioskowaniem, podczas gdy szybszy model generuje krótkie reakcje społeczne lub narrację. Najważniejsza zasada mówi, by kontrakt gry pozostawić poza modelem. Model może zaproponować działanie, ale serwer powinien sprawdzić, czy jest ono dozwolone, zanim zastosuje je do stanu.

Zdalne interfejsy API modeli zmieniają również granice prywatności i niezawodności. Jeśli gra wysyła prywatne informacje o rolach do zewnętrznej usługi, usługa ta staje się częścią modelu zaufania. Awarie sieci, limity zapytań i zmiany w API mogą wstrzymać grę, nawet gdy lokalne urządzenie działa prawidłowo. Buforowanie promptów, ponawianie żądań idempotentnych oraz rejestrowanie identyfikatorów żądań ułatwiają wznowienie eksperymentu i wyjaśnienie jego przebiegu.

Naturalna rozmowa wymaga silnika zarządzania kolejnością wypowiedzi

Dziesięciu agentów mówiących w ustalonej kolejce brzmiałoby jak telekonferencja sterowana arkuszem kalkulacyjnym. Bardziej przekonujące zachowanie zapewnia wyraźnie zdefiniowany silnik zarządzania kolejnością wypowiedzi, który wie, kiedy postać może się odezwać, kiedy dozwolone jest przerwanie oraz kiedy stół musi przejść do głosowania lub działania nocnego.

Przydatnym rozwiązaniem jest maszyna stanów z fazami takimi jak przedstawienie się, otwarta dyskusja, ukierunkowana odpowiedź, głosowanie, działania nocne i wyniki. W fazie dyskusji harmonogram może wybierać kolejnego mówcę na podstawie połączenia sprawiedliwości, istotności, podejrzaności i kontrolowanej losowości. Postać może poprosić o przerwanie, ale silnik decyduje, czy prośba jest uzasadniona i jak wpływa na kolejkę.

Dlatego „realistyczny głos” to coś więcej niż zamiana tekstu na mowę. System musi decydować, kiedy rozpoczyna się dźwięk, czy bieżącą wypowiedź można przerwać, jak kolejkować odpowiedzi oraz co zrobić w razie niepowodzenia żądania głosowego. Wyraźne oddzielenie decyzji dotyczących tekstu od odtwarzania dźwięku pozwala grze działać dalej, nawet gdy dostawca głosu reaguje z opóźnieniem.

Głos dodaje sygnały społeczne — i nowe tryby awarii

Dialog mówiony zmienia sposób, w jaki widzowie oceniają agentów. Pauzy, potwierdzenia, przerwania i różnice w tożsamości głosowej sprawiają, że krótka odpowiedź brzmi jak część rozmowy przy żywym stole. Film wykorzystuje Fish Audio jako warstwę głosową, która pełni funkcję strukturalną: zamienia zmiany stanu w zdarzenia, które człowiek może śledzić w czasie rzeczywistym.

Dźwięk może również ujawniać błędy, które tekst ukrywa. Opóźnione żądanie syntezy może sprawić, że postać odezwie się po przejściu gry do innej fazy. Długa wygenerowana odpowiedź może zablokować kolejkę i sprawić, że cichsi agenci znikną z rozmowy. Dlatego aplikacja powinna przypisywać każdy klip audio do zdarzenia i fazy gry, aby nieaktualne klipy można było odrzucić, zamiast odtwarzać je poza kontekstem.

Tożsamość głosowa również wymaga spójnej polityki. Jeśli głos postaci zmienia się między turami, widzowie mogą uznać usterkę techniczną za pojawienie się nowej postaci. Przechowywanie przypisania głosu w konfiguracji, zamiast w prompcie modelu, sprawia, że warstwa prezentacji jest przewidywalna i łatwiejsza do wymiany.

Pętla gry potrzebuje źródła prawdy po stronie serwera

Podczas gry na żywo system musi koordynować więcej niż tylko wiadomości na czacie. Musi wiedzieć, kto żyje, która faza jest aktywna, które akcje są nadal dozwolone, co usłyszała każda postać oraz kiedy wynik staje się oficjalny. Te informacje należą do warstwy aplikacji, a nie do swobodnej odpowiedzi agenta.

Dobry zapis zdarzenia może zawierać fazę, mówcę, widoczny tekst, prywatną akcję, użyty model, status żądania oraz wynikową wersję stanu. Taka struktura obsługuje odtwarzanie: deweloper może ponownie uruchomić prezentację na podstawie tych samych zdarzeń, bez proszenia każdego modelu o ponowne wygenerowanie całej gry. Ułatwia też porównywanie dwóch konfiguracji modeli w tym samym scenariuszu.

Odtwarzanie jest szczególnie cenne w przypadku projektu, który sprawia wrażenie spontanicznego. Jeśli postać wygrywa dzięki przekonującej dedukcji, deweloper może sprawdzić, czy wynik wynikał z projektu roli, szczęśliwej odpowiedzi modelu, ujawnionego sekretu czy nietypowego harmonogramu. Obserwowalność zmienia efektowne demo w system, który można rzeczywiście ulepszać.

Rola ZimaBoard 2 w architekturze

ZimaBoard 2 najlepiej sprawdza się na stale działającym obrzeżu tego systemu. Takie zastosowanie jest zgodne z szerszym zestawem lokalnego asystenta AI na ZimaBoard 2: płyta może hostować koordynator, niewielką bazę danych, pulpity, usługi webhooków, kolejki audio lub konteneryzowane komponenty pomocnicze, jednocześnie niezawodnie łącząc je z zewnętrznymi API modeli i głosu. W tej roli bardziej liczą się niski pobór energii, kompaktowe rozmiary i łączność sieciowa niż duża liczba rdzeni CPU.

To, czy płyta może lokalnie uruchomić konkretny model, zależy od rozmiaru modelu, kwantyzacji, pamięci, akceleracji i wymaganych opóźnień. Dlatego osobny zestaw Zero Noichi z ZimaBoard 2 i AMD MI50 jest przydatnym punktem odniesienia: dodatkowa moc obliczeniowa GPU zmienia ścieżkę wnioskowania, a płyta nadal może zapewniać stabilną warstwę hosta i usług. Bezpieczna zasada planowania polega na oddzieleniu orkiestracji od wnioskowania: zaprojektuj aplikację tak, aby silnik stanu pozostał użyteczny nawet wtedy, gdy punkt końcowy modelu zostanie przeniesiony między usługą lokalną, innym komputerem a hostowanym API.

Bezpośrednia pamięć masowa i możliwość rozbudowy mogą również obsługiwać logi, wersje promptów, buforowane nagrania audio i powtórki rozgrywek. Te pliki nie są samym modelem, ale stanowią dowody potrzebne do zrozumienia działania systemu. Niewielki serwer, który zapewnia odtwarzalność projektu, może być cenniejszy niż szybsze urządzenie tworzące jedynie efektowne demo za pierwszym razem.

Co ujawnia rzeczywisty rezultat na temat wieloagentowej AI

Eksperyment jest interesujący, ponieważ agenci sprawiają wrażenie, jakby mieli intencje społeczne: przerywają sobie, bronią się, podejrzewają się nawzajem i koordynują działania na podstawie niepełnych informacji. Z technicznego punktu widzenia te zachowania wynikają z interakcji między promptami ról, prywatnym kontekstem, zmianami stanu i harmonogramem. Żadna pojedyncza odpowiedź modelu nie wyjaśnia całego doświadczenia.

To rozróżnienie ma znaczenie dla każdego, kto tworzy lokalną aplikację AI. Większa liczba agentów nie oznacza automatycznie większej inteligencji. Zwiększa koszty koordynacji, zarządzania kontekstem, zakres potencjalnych awarii i wymagania dotyczące obserwowalności. Mniejsza grupa z wyraźnie oddzielonymi stanami może dać bardziej wiarygodny rezultat niż większa grupa, która zapomina swoich zasad.

Projekt pokazuje również, dlaczego opóźnienie jest decyzją produktową. Powolna, ale przemyślana odpowiedź może być akceptowalna podczas turowego dedukowania, podczas gdy to samo opóźnienie wydaje się błędem przy krótkim potwierdzeniu lub przerwaniu. Harmonogram powinien więc dopasowywać nakład pracy modelu i długość głosu do znaczenia zdarzenia, zamiast traktować każdą wiadomość tak samo.

Jak odtworzyć ten pomysł bez kopiowania całej produkcji

Zacznij od trzech agentów i jednej prostej zasady ukrytych ról. Zbuduj dziennik zdarzeń, maszynę stanów oraz rozdzielenie kontekstu prywatnego i publicznego, zanim dodasz głos. Gdy pętla tekstowa będzie potrafiła odtworzyć pełną rundę bez ujawniania informacji, dodaj jednego dostawcę głosu i zmierz, w którym miejscu interakcja faktycznie wydaje się powolna.

Następnie uczyń konfigurację jawną. Przechowuj profile postaci, zasady ról, trasy modeli, przypisania głosów i zasady ponawiania prób poza tekstem promptu. Dzięki temu jednorazowa demonstracja staje się systemem, który można dostrajać bez przepisywania każdego agenta. Nadaje to również węzłowi sprzętowemu jasne zadanie: przechowywać usługi, konfigurację i dane potwierdzające działanie w jednym miejscu, podczas gdy backend wnioskowania pozostaje wymienny. Ten sam podział jest przydatny przy szerszej budowie lokalnego serwera AI, w której środowisko uruchomieniowe i usługi pomocnicze mogą rozwijać się w różnym tempie.

Na koniec testuj awarie, zamiast sprawdzać wyłącznie prawidłowy przebieg. Zatrzymaj jedno żądanie modelu, opóźnij jeden klip audio, usuń jednego gracza, uruchom ponownie koordynatora i odtwórz ten sam dziennik zdarzeń. Przekonująca aplikacja wieloagentowa nie jest definiowana wyłącznie przez swoją najlepszą rozmowę, lecz przez to, czy system potrafi się zregenerować bez zmieniania zasad w trakcie gry.

Na kompaktowej platformie domowego serwera, która może obsługiwać orkiestrację i usługi pomocnicze, poznaj ZimaBoard 2 – miniaturowy domowy serwer dla Twojego wielkiego pomysłu. Aby wymieniać się pomysłami z innymi twórcami, dołącz do społeczności ZimaSpace na Discordzie.