Hoe Zero Noichi een AI-Weerwolfspel met tien agenten bouwde

野市 零 / Zero Noichi laat zien wat er gebeurt wanneer tien AI-agents één weerwolfspel delen: de uitdaging is niet langer een gevat antwoord genereren, maar stemmen, rollen, geheugen, timing en conflicten coördineren zonder dat het gesprek mechanisch aanvoelt.

Dit artikel bedankt 野市 零 / Zero Noichi voor het documenteren van het experiment in de oorspronkelijke AI-weerwolfvideo. De video wordt gepresenteerd als een entertainmentexperiment, maar legt ook de technische problemen bloot achter een geloofwaardige multi-agenttoepassing: hoe je agents laat wachten, onderbreken, onthouden, misleiden en reageren als leden van één gedeelde wereld.

Openbaarmaking over de samenwerking: De oorspronkelijke beschrijving verwijst naar ZimaBoard 2, een creatorcoupon, affiliatelinks en de softwareservices die in het experiment zijn gebruikt. De maker deelt zijn eigen implementatie en beoogde gebruik. Modelversies, stemservices, interfaces, hardwarebundels en compatibiliteit kunnen na publicatie veranderen.

Het resultaat: Een ZimaBoard 2 - Mini-thuisserver is geen vervanging voor een groot inferentiecluster dat tien geavanceerde modellen op volle snelheid uitvoert. De realistischere kracht ligt in het fungeren als een compacte, altijd ingeschakelde besturings- en servicenode voor een AI-toepassing: prompts, spelstatus, API’s, audiopijplijnen, logs en netwerktoegang coördineren, terwijl zwaarder modelwerk wordt toegewezen aan het service- of rekenspoor dat daarvoor geschikt is.

De nuttigste manier om dit project te lezen, is als een gelaagd systeem. Het taalmodel levert beslissingen en dialogen, maar een orkestratielaag bepaalt wie aan de beurt is, een toestandslaag bepaalt wat elk personage weet, een stemlaag zet tekst om in spraak en een presentatielaag maakt het resultaat begrijpelijk voor de kijker. Verwijder een van die lagen en tien ‘slimme’ agents worden al snel tien losse chatvensters.

Het moeilijke deel is gedeelde werkelijkheid, niet het aantal agents

Een tweede model aan een gesprek toevoegen is eenvoudig vergeleken met een tweede model toevoegen dat zich aan dezelfde regels moet houden. In een weerwolfspel heeft elk personage een privérol, een openbare geschiedenis, een overtuiging over andere spelers en een legale reeks acties voor de huidige fase nodig. De applicatie heeft daarom één gezaghebbende spelstatus nodig, in plaats van elk model zijn eigen versie van de gebeurtenissen te laten verzinnen.

Een robuust ontwerp scheidt de openbare en de privéstatus. De openbare status kan de huidige dag, uitgesproken beweringen, stemmen en geëlimineerde spelers bevatten. De privéstatus kan de teamgenoten van een weerwolf, het resultaat van een ziener of een verborgen verdenking van een personage bevatten. De orchestrator stelt vervolgens voor elke agent een andere context samen, in plaats van elk geheim naar iedereen uit te zenden.

Deze scheiding maakt debuggen ook mogelijk. Als een agent een verdachte beschuldiging uit, kan de ontwikkelaar het exacte openbare transcript, het privégeheugen, de rolprompt en het modelantwoord bekijken die ertoe hebben geleid. Zonder die grenzen kan schijnbare “intelligentie” simpelweg het gevolg zijn van een onbedoeld informatielek van de ene prompt naar de andere.

Karakterprompts hebben meer nodig dan een persoonlijkheidsbijvoeglijk naamwoord

De ene agent “zelfverzekerd” en de andere “stil” noemen is niet genoeg om een cast te creëren. Een bruikbare karakterdefinitie combineert een spreekstijl, risicotolerantie, een doel, een rolspecifieke kennisgrens en een regel voor hoe bewijs overtuigingen verandert. Het personage moet anders klinken, maar ook beslissingen nemen om een reden die gedurende alle beurten consistent blijft.

Elke agent heeft baat bij een gestructureerd profiel: naam, rol, publieke persoonlijkheid, privédoel, bekende feiten, huidige vermoedens en een beknopt geheugen van eerdere gebeurtenissen. De prompt kan vervolgens zowel om een interne beslissing als om een regel voor de kijker vragen, terwijl de applicatie alleen de velden opslaat die nodig zijn voor de volgende overgang. Zo blijft de context leesbaar naarmate het spel vordert.

Hier ligt een belangrijke grens. Een langere prompt zorgt niet automatisch voor een dieper personage. Als elke beurt het volledige transcript en alle instructies opnieuw bevat, nemen latentie en kosten toe, terwijl het model nog steeds geen duidelijke statusovergang heeft. Een kleinere, samengestelde herinnering zorgt vaak voor consistenter gedrag dan een ongefilterde gespreksdump.

Modelkeuze verandert het ritme van het spel

De video benadrukt de keuze van LLM-modellen als onderdeel van het experiment, in plaats van “AI” te behandelen als één uitwisselbare component. Moonshot Kimi K3 wordt in het project genoemd als de taalmodelcomponent. Die keuze beïnvloedt niet alleen de kwaliteit van de antwoorden, maar ook de lengte van reacties, latentie, weigeringsgedrag, taalstijl en de hoeveelheid context die tussen beurten kan worden meegenomen.

Een praktische architectuur kan verschillende taken aan verschillende modellen toewijzen. Een sterker model kan een moeilijke privéafleiding uitvoeren, terwijl een sneller model korte sociale reacties of vertellingen produceert. De belangrijkste regel is om het spelcontract buiten het model te houden. Het model kan een actie voorstellen, maar de server moet valideren of die actie is toegestaan voordat deze op de toestand wordt toegepast.

Externe model-API's veranderen ook de grenzen rond privacy en betrouwbaarheid. Als het spel privé-informatie over rollen naar een externe dienst stuurt, wordt die dienst onderdeel van het vertrouwensmodel. Netwerkstoringen, limieten en API-wijzigingen kunnen het spel pauzeren, zelfs wanneer het lokale apparaat goed functioneert. Prompts cachen, idempotente verzoeken opnieuw proberen en verzoek-ID's vastleggen maken het experiment eenvoudiger om te hervatten en uit te leggen.

Natuurlijke gesprekken vereisen een engine voor beurtwisseling

Tien agenten die in een vaste volgorde spreken, zouden klinken als een conferencecall die door een spreadsheet wordt bestuurd. Overtuigender gedrag ontstaat door een expliciete engine voor beurtwisseling die weet wanneer een personage mag spreken, wanneer een onderbreking is toegestaan en wanneer de tafel moet doorgaan naar een stemming of nachtelijke actie.

Een bruikbaar patroon is een toestandsmachine met fasen zoals introductie, open discussie, gerichte reactie, stemmen, nachtelijke acties en resultaten. Binnen een discussie­fase kan de planner de volgende spreker kiezen op basis van een combinatie van eerlijkheid, relevantie, verdenking en gecontroleerde willekeur. Een personage kan om een onderbreking vragen, maar de engine bepaalt of dat verzoek geldig is en welke invloed het op de wachtrij heeft.

Daarom is “realistische spraak” meer dan tekst-naar-spraak. Het systeem moet bepalen wanneer de audio begint, of een huidige uiting mag worden onderbroken, hoe een reactie in de wachtrij wordt geplaatst en wat er gebeurt als een spraakverzoek mislukt. Door tekstbeslissingen en het afspelen van audio duidelijk van elkaar te scheiden, kan het spel doorgaan, zelfs wanneer een spraakprovider traag is.

Spraak voegt sociale signalen en nieuwe foutscenario's toe

Gesproken dialogen veranderen de manier waarop kijkers de agents beoordelen. Pauzes, bevestigingen, onderbrekingen en verschillen in stemidentiteit zorgen ervoor dat een kort antwoord aanvoelt als onderdeel van een live tafelgesprek. De video gebruikt Fish Audio voor de stemlaag, die een structurele functie heeft: deze zet statusovergangen om in gebeurtenissen die een mens in realtime kan volgen.

Audio kan ook bugs aan het licht brengen die in tekst verborgen blijven. Een vertraagd synthes verzoek kan ertoe leiden dat een personage spreekt nadat het spel al naar een andere fase is gegaan. Een lang gegenereerd antwoord kan de wachtrij blokkeren en ervoor zorgen dat stillere agents verdwijnen. De applicatie moet daarom elke audioclip aan een gamegebeurtenis en fase koppelen, zodat verouderde clips kunnen worden verwijderd in plaats van buiten hun context te worden afgespeeld.

Ook voor stemidentiteit is een consistentiebeleid nodig. Als de stem van een personage tussen beurten verandert, kunnen kijkers een technische storing interpreteren als een nieuw personage. Door de stemtoewijzing in de configuratie vast te leggen in plaats van in de modelprompt, blijft de presentatielaag voorspelbaar en eenvoudiger te vervangen.

De spellus heeft een bron van waarheid aan de serverzijde nodig

Tijdens het live spel moet het systeem meer coördineren dan alleen chatberichten. Het moet weten wie er nog leeft, welke fase actief is, welke acties nog toegestaan zijn, wat elk personage heeft gehoord en wanneer een resultaat officieel wordt. Die feiten horen bij de applicatielaag, niet bij een vrij geformuleerd antwoord van een agent.

Een goed gebeurtenisrecord kan de fase, spreker, zichtbare tekst, privéactie, het gebruikte model, de status van het verzoek en de resulterende statusversie bevatten. Die structuur ondersteunt replay: de ontwikkelaar kan de presentatie opnieuw afspelen aan de hand van dezelfde gebeurtenissen, zonder elk model te vragen het volledige spel opnieuw te genereren. Ook wordt het zo eenvoudiger om twee modelconfiguraties binnen hetzelfde scenario te vergelijken.

Replay is vooral waardevol voor een project dat spontaan lijkt. Als een personage wint dankzij een overtuigende deductie, kan de ontwikkelaar nagaan of de uitkomst voortkwam uit het rolontwerp, een gelukkige modelreactie, een gelekt geheim of een eigenaardigheid in de planning. Observability maakt van een vermakelijke demo een systeem dat daadwerkelijk kan worden verbeterd.

Waar ZimaBoard 2 in de architectuur past

ZimaBoard 2 komt het best tot zijn recht aan de altijd ingeschakelde rand van dit systeem. Die positionering sluit aan bij de bredere lokale AI-assistentconfiguratie met ZimaBoard 2: het board kan de coördinator, een kleine database, dashboards, webhookservices, audiowachtrijen of ondersteunende componenten in containers hosten en er tegelijkertijd betrouwbaar verbinding mee maken via externe model- en spraak-API's. Die rol heeft meer baat bij een laag energieverbruik, een compacte vormfactor en netwerkconnectiviteit dan bij een groot aantal CPU-cores.

Of het board een specifiek model lokaal kan uitvoeren, hangt af van de modelgrootte, quantisatie, het geheugen, versnelling en de latentie die de ervaring vereist. Daarom is de afzonderlijke ZimaBoard 2- en AMD MI50-configuratie van Zero Noichi een nuttige vergelijking: extra GPU-rekenkracht verandert het inferentiepad, terwijl het board nog steeds de stabiele host- en servicelaag kan leveren. Een veilige planningsregel is om orkestratie en inferentie van elkaar te scheiden: ontwerp de toepassing zo dat de toestandsengine nuttig blijft, zelfs als het modeleindpunt verschuift tussen een lokale service, een andere machine of een gehoste API.

Directe opslag en uitbreidingsmogelijkheden kunnen ook logs, promptversies, gecachte audio en spelreplays ondersteunen. Die bestanden zijn niet het model zelf, maar wel het bewijsmateriaal dat nodig is om te begrijpen hoe het systeem zich gedroeg. Een kleine server die het project reproduceerbaar houdt, kan waardevoller zijn dan een sneller apparaat dat slechts één indrukwekkende demo oplevert.

Wat het live resultaat onthult over multi-agent-AI

De aantrekkingskracht van het experiment is dat de agents sociale intentie lijken te hebben: ze onderbreken elkaar, verdedigen zichzelf, verdenken elkaar en stemmen hun acties af op basis van onvolledige informatie. Technisch gezien ontstaan deze gedragingen uit de wisselwerking tussen rolprompts, privécontext, toestandsovergangen en de scheduler. Geen enkele modelreactie verklaart de volledige ervaring.

Dat onderscheid is belangrijk voor iedereen die een lokale AI-toepassing bouwt. Meer agents betekenen niet automatisch meer intelligentie. Ze verhogen de coördinatiekosten, de vereisten voor contextbeheer en observeerbaarheid, en het aantal mogelijke foutpunten. Een kleinere groep met duidelijke grenzen tussen toestanden kan een geloofwaardiger resultaat opleveren dan een grotere groep die zijn regels vergeet.

Het project laat ook zien waarom latentie een productbeslissing is. Een langzaam maar doordacht antwoord kan tijdens een deductieronde acceptabel zijn, terwijl dezelfde vertraging tijdens een korte bevestiging of onderbreking gebrekkig aanvoelt. De planner moet de modelinspanning en de lengte van de spraak daarom afstemmen op het belang van de gebeurtenis, in plaats van elk bericht hetzelfde te behandelen.

Zo boots je het idee na zonder de volledige productie te kopiëren

Begin met drie agents en één eenvoudige regel voor verborgen rollen. Bouw het gebeurtenislogboek, de toestandsmachine en de scheiding tussen privé- en openbare context voordat je spraak toevoegt. Zodra de tekstlus een volledige ronde kan afspelen zonder informatie te lekken, voeg je één spraakprovider toe en meet je waar de interactie daadwerkelijk traag aanvoelt.

Maak vervolgens de configuratie expliciet. Sla karakterprofielen, rolregels, modelroutes, stemtoewijzingen en retrybeleid buiten de prompttekst op. Zo wordt een eenmalige demonstratie een systeem dat kan worden afgesteld zonder elke agent opnieuw te schrijven. Ook krijgt de hardwareknooppunt een duidelijke taak: services, configuratie en bewijsmateriaal bij elkaar houden terwijl de inference-backend vervangbaar blijft. Dezelfde scheiding is nuttig bij een bredere lokale AI-serverbuild, waarbij de runtime en de ondersteunende services zich in verschillend tempo kunnen ontwikkelen.

Test ten slotte ook fouten, in plaats van alleen het ideale scenario. Stop één modelaanvraag, vertraag één audioclip, verwijder een speler, start de coördinator opnieuw op en speel hetzelfde gebeurtenislogboek opnieuw af. Een overtuigende multi-agenttoepassing wordt niet alleen bepaald door het beste gesprek, maar ook door de vraag of het systeem kan herstellen zonder de regels halverwege het spel te veranderen.

Voor een compact thuisserverplatform dat de orkestratie en ondersteunende services kan hosten, bekijk ZimaBoard 2 - Mini-thuisserver voor jouw grote idee. Wil je ideeën uitwisselen met andere bouwers, word dan lid van de ZimaSpace Discord-community.