Så byggde Zero Noichi ett AI-varulvsspel med tio agenter

野市 零 / Zero Noichi visar vad som händer när tio AI-agenter delar på ett varulvsspel: utmaningen är inte längre att generera ett fyndigt svar, utan att samordna röster, roller, minne, timing och konflikter utan att få samtalet att kännas mekaniskt.

I den här artikeln tackar vi 野市 零 / Zero Noichi för att ha dokumenterat experimentet i den ursprungliga AI-varulvsvideon. Videon presenteras som ett underhållningsexperiment, men den synliggör också ingenjörsproblemen bakom en trovärdig applikation med flera agenter: hur man får agenter att vänta, avbryta, minnas, vilseleda och reagera som medlemmar i en gemensam värld.

Information om samarbetet: Den ursprungliga beskrivningen hänvisar till ZimaBoard 2, en rabattkod för kreatörer, affiliatelänkar och de programvarutjänster som användes i experimentet. Kreatören delar sin egen implementation och avsedda användning. Modellversioner, rösttjänster, gränssnitt, hårdvarupaket och kompatibilitet kan ändras efter publiceringen.

Resultatet: En ZimaBoard 2 – minihemserver ersätter inte ett stort inferenskluster som kör tio avancerade modeller i full hastighet. Dess mer realistiska styrka är att fungera som en kompakt, alltid påslagen kontroll- och tjänstenod för en AI-applikation: den samordnar promptar, spelstatus, API:er, ljudpipelines, loggar och nätverksåtkomst, medan tyngre modellarbete tilldelas den tjänste- eller beräkningsväg som passar bäst.

Det användbara sättet att se på det här projektet är som ett system i flera lager. Språkmodellen står för beslut och dialog, men ett orkestreringslager avgör vems tur det är, ett tillståndslager avgör vad varje rollfigur känner till, ett röstlager omvandlar text till tal och ett presentationslager gör resultatet begripligt för tittaren. Ta bort något av dessa lager och tio ”smarta” agenter blir snabbt tio frånkopplade chattfönster.

Det svåra är en gemensam verklighet, inte antalet agenter

Att lägga till en andra modell i en konversation är enkelt jämfört med att lägga till en andra modell som måste följa samma regler. I ett varulvsspel behöver varje karaktär en privat roll, en offentlig historik, en uppfattning om de andra spelarna och en tillåten uppsättning handlingar för den aktuella fasen. Applikationen behöver därför ett enda auktoritativt speltillstånd i stället för att låta varje modell hitta på sin egen version av händelserna.

En robust design skiljer mellan offentligt och privat tillstånd. Det offentliga tillståndet kan innehålla aktuell dag, uttalade påståenden, röster och eliminerade spelare. Det privata tillståndet kan innehålla en varulvs lagkamrater, en sires resultat eller en karaktärs dolda misstanke. Orkestratorn bygger sedan en annan kontext för varje agent i stället för att sända ut varje hemlighet till alla.

Den här uppdelningen gör också felsökning möjlig. Om en agent framställer en misstänkt anklagelse kan utvecklaren granska det exakta offentliga transkriptet, det privata minnet, rollprompten och modellsvar som ledde fram till den. Utan dessa gränser kan upplevd ”intelligens” helt enkelt vara ett oavsiktligt informationsläckage från en prompt till en annan.

Karaktärsprompter behöver mer än ett personlighetsadjektiv

Det räcker inte att kalla en agent ”självsäker” och en annan ”tystlåten” för att skapa en rollbesättning. En användbar karaktärsdefinition kombinerar en talstil, en risktolerans, ett mål, en rollspecifik kunskapsgräns och en regel för hur bevis förändrar övertygelsen. Karaktären ska låta annorlunda, men också fatta beslut av en anledning som förblir konsekvent från tur till tur.

Varje agent drar nytta av en strukturerad profil: namn, roll, offentlig persona, privat mål, kända fakta, aktuella misstankar och ett kompakt minne av tidigare händelser. Prompten kan sedan be om både ett internt beslut och en replik riktad till tittaren, medan applikationen bara sparar de fält som behövs för nästa övergång. På så sätt förblir kontexten överskådlig när spelet växer.

Det finns en viktig gränsdragning här. En längre prompt skapar inte automatiskt en djupare karaktär. Om hela transkriptet och alla instruktioner upprepas i varje tur ökar fördröjningen och kostnaden, samtidigt som modellen fortfarande saknar en tydlig övergång mellan tillstånd. Ett mindre, kurerat minne skapar ofta mer konsekvent beteende än en ofiltrerad konversationsdump.

Modellvalet förändrar spelets rytm

Videon lyfter fram valet av LLM-modeller som en del av experimentet, i stället för att behandla ”AI” som en enda utbytbar komponent. Moonshot Kimi K3 nämns i projektet som språkmodellskomponenten, och det valet påverkar inte bara svarskvaliteten utan även svarslängd, fördröjning, vägransbeteende, språkstil och hur mycket kontext som kan föras vidare mellan turerna.

En praktisk arkitektur kan tilldela olika modeller olika uppgifter. En starkare modell kan hantera en svår privat slutledning, medan en snabbare modell genererar korta sociala reaktioner eller berättarröst. Den viktiga regeln är att hålla spelkontraktet utanför modellen. Modellen kan föreslå en handling, men servern bör validera om handlingen är tillåten innan den tillämpas på tillståndet.

Fjärranslutna modell-API:er förändrar också gränsen för integritet och tillförlitlighet. Om spelet skickar privat rollinformation till en extern tjänst blir den tjänsten en del av förtroendemodellen. Nätverksfel, hastighetsbegränsningar och API-ändringar kan pausa spelet även när den lokala enheten fungerar. Genom att cachelagra promptar, försöka igen med idempotenta förfrågningar och spara förfrågnings-ID:n blir experimentet enklare att återuppta och förklara.

Naturlig konversation kräver en turordningsmotor

Tio agenter som talar i en fast kö skulle låta som ett konferenssamtal styrt av ett kalkylblad. Det som ger ett mer övertygande beteende är en uttrycklig turordningsmotor som vet när en karaktär får tala, när ett avbrott är tillåtet och när bordet måste gå vidare till en omröstning eller nattlig handling.

Ett användbart mönster är en tillståndsmaskin med faser som introduktion, öppen diskussion, riktat svar, röstning, nattliga handlingar och resultat. Under en diskussionsfas kan schemaläggaren välja nästa talare utifrån en kombination av rättvisa, relevans, misstänksamhet och kontrollerad slumpmässighet. En karaktär kan begära ett avbrott, men spelmotorn avgör om begäran är giltig och hur den påverkar kön.

Det är därför ”realistisk röst” är mer än text-till-tal. Systemet måste avgöra när ljudet ska börja, om ett pågående yttrande kan avbrytas, hur ett svar ska köas och vad som händer om en röstförfrågan misslyckas. En tydlig åtskillnad mellan textbeslut och ljuduppspelning gör att spelet kan fortsätta även när en röstleverantör är långsam.

Röst tillför sociala signaler – och nya felmoder

Talad dialog förändrar hur tittarna bedömer agenterna. Pauser, bekräftelser, avbrott och skillnader i röstidentitet får ett kort svar att kännas som en del av ett livespel runt ett bord. Videon använder Fish Audio för röstlagret, vilket fyller en strukturell funktion: det omvandlar tillståndsövergångar till händelser som en människa kan följa i realtid.

Ljud kan också avslöja buggar som text döljer. En fördröjd syntesbegäran kan få en karaktär att tala efter att spelet redan har gått vidare till en annan fas. Ett långt genererat svar kan blockera kön och göra att tystare agenter försvinner. Applikationen bör därför koppla varje ljudklipp till en spelhändelse och fas, så att inaktuella klipp kan kastas i stället för att spelas upp ur sitt sammanhang.

Röstidentiteten behöver också en konsekvenspolicy. Om en karaktärs röst ändras mellan turerna kan tittarna tolka ett tekniskt fel som en ny karaktär. Genom att hålla rösttilldelningen i konfigurationen i stället för i modellens prompt blir presentationslagret förutsägbart och enklare att ersätta.

Spelloopen behöver en källa till sanning på serversidan

Under livespelet måste systemet samordna mer än chattmeddelanden. Det behöver veta vem som lever, vilken fas som är aktiv, vilka handlingar som fortfarande är tillåtna, vad varje karaktär har hört och när ett resultat blir officiellt. Dessa fakta hör till applikationslagret, inte till en agents fria svar.

En bra händelsepost kan innehålla fas, talare, synlig text, privat handling, använd modell, status för begäran och den resulterande tillståndsversionen. Den strukturen stöder replay: utvecklaren kan köra presentationen igen från samma händelser utan att be varje modell återskapa hela spelet. Det blir också enklare att jämföra två modellkonfigurationer under samma scenario.

Replay är särskilt värdefullt för ett projekt som ser spontant ut. Om en karaktär vinner tack vare en övertygande slutsats kan utvecklaren undersöka om resultatet berodde på rollens utformning, ett lyckosamt modellsvar, en läckt hemlighet eller en schemaläggningsdetalj. Observerbarhet förvandlar en underhållande demo till ett system som faktiskt kan förbättras.

Var ZimaBoard 2 passar in i arkitekturen

ZimaBoard 2 passar bäst vid systemets alltid påslagna kant. Den placeringen stämmer överens med den bredare installationen av en lokal AI-assistent med ZimaBoard 2: kortet kan vara värd för koordinatorn, en liten databas, instrumentpaneler, webhooktjänster, ljudköer eller containeriserade stöddelar, samtidigt som det ansluter dem till externa modell- och röst-API:er på ett tillförlitligt sätt. Den rollen gynnas mer av låg energiförbrukning, ett kompakt format och nätverksanslutning än av ett stort antal processorkärnor.

Om kortet kan köra en viss modell lokalt beror på modellens storlek, kvantisering, minne, maskinvaruacceleration och den fördröjning som upplevelsen kräver. Därför är den separata Zero Noichis bygge med ZimaBoard 2 och AMD MI50 en användbar jämförelse: ytterligare GPU-beräkningskapacitet förändrar inferensvägen, medan kortet fortfarande kan tillhandahålla det stabila värd- och tjänstelagret. En säker planeringsregel är att skilja orkestrering från inferens: utforma applikationen så att tillståndsmotorn förblir användbar även om modellens slutpunkt flyttas mellan en lokal tjänst, en annan maskin eller ett värdbaserat API.

Direktlagring och expansionsmöjligheter kan också stödja loggar, promptversioner, cachat ljud och spelrepriser. Dessa filer är inte själva modellen, men de är de bevis som behövs för att förstå hur systemet betedde sig. En liten server som håller projektet reproducerbart kan vara mer värdefull än en snabbare enhet som bara skapar en imponerande engångsdemonstration.

Vad det direkta resultatet avslöjar om AI med flera agenter

Experimentet är intressant eftersom agenterna verkar ha sociala avsikter: de avbryter, försvarar sig, misstänker varandra och samordnar sig utifrån ofullständig information. Tekniskt sett uppstår dessa beteenden genom samspelet mellan rollinstruktioner, privat kontext, tillståndsövergångar och schemaläggaren. Inget enskilt modellsvar förklarar hela upplevelsen.

Den skillnaden är viktig för alla som bygger en lokal AI-applikation. Fler agenter innebär inte automatiskt mer intelligens. De ökar samordningskostnaderna, kraven på kontexthantering och observerbarhet samt antalet möjliga felpunkter. En mindre grupp med tydliga gränser mellan tillstånd kan ge ett mer trovärdigt resultat än en större grupp som glömmer sina regler.

Projektet visar också varför fördröjning är ett produktbeslut. Ett långsamt men genomtänkt svar kan vara acceptabelt under en turbaserad deduktion, medan samma fördröjning känns fel under en kort bekräftelse eller ett avbrott. Schemaläggaren bör därför anpassa modellens arbetsinsats och röstlängden efter händelsens betydelse i stället för att behandla alla meddelanden likadant.

Så återskapar du idén utan att kopiera hela produktionen

Börja med tre agenter och en enkel regel för dolda roller. Bygg händelseloggen, tillståndsmaskinen och separationen mellan privat och offentlig kontext innan du lägger till röst. När den textbaserade loopen kan spela upp en hel runda igen utan att information läcker, lägger du till en enda röstleverantör och mäter var interaktionen faktiskt känns långsam.

Gör sedan konfigurationen explicit. Lagra karaktärsprofiler, rollregler, modellrutter, rösttilldelningar och policyer för nya försök utanför prompttexten. Då blir en engångsdemonstration ett system som kan finjusteras utan att varje agent måste skrivas om. Det ger också hårdvarunoden en tydlig uppgift: att hålla tjänster, konfiguration och underlag samlade medan inferensbackend kan bytas ut. Samma separering är användbar i ett bredare bygge av en lokal AI-server, där körmiljön och de stödjande tjänsterna kan utvecklas i olika takt.

Testa slutligen fel i stället för att bara testa det lyckade scenariot. Stoppa en modellförfrågan, fördröj ett ljudklipp, ta bort en spelare, starta om koordinatorn och spela upp samma händelselogg igen. En övertygande applikation med flera agenter definieras inte bara av sitt bästa samtal; den definieras av om systemet kan återhämta sig utan att ändra reglerna halvvägs genom spelet.

För en kompakt hemserverplattform som kan vara värd för orkestreringen och de stödjande tjänsterna kan du utforska ZimaBoard 2 – miniserver för hemmet och din stora idé. Om du vill jämföra idéer med andra utvecklare kan du gå med i ZimaSpace Discord-communityt.