Come Zero Noichi ha creato un gioco di Lupi Mannari con dieci agenti IA

野市 零 / Zero Noichi mostra cosa accade quando dieci agenti di IA condividono una partita a Lupo mannaro: la sfida non consiste più nel generare una risposta brillante, ma nel coordinare voci, ruoli, memoria, tempistiche e conflitti senza far sembrare meccanica la conversazione.

Questo articolo ringrazia 野市 零 / Zero Noichi per aver documentato l'esperimento nel video originale sull'uomo lupo dell'IA. Il video viene presentato come un esperimento d'intrattenimento, ma mette anche in luce i problemi ingegneristici alla base di un'applicazione multi-agente credibile: come fare in modo che gli agenti aspettino, interrompano, ricordino, ingannino e reagiscano come membri di un unico mondo condiviso.

Informativa sulla collaborazione: La descrizione originale fa riferimento a ZimaBoard 2, a un codice sconto per creator, a link affiliati e ai servizi software utilizzati nell'esperimento. Il creator condivide la propria implementazione e il proprio utilizzo previsto. Le versioni dei modelli, i servizi vocali, le interfacce, i bundle hardware e la compatibilità possono cambiare dopo la pubblicazione.

Il risultato: Uno ZimaBoard 2 - Mini server domestico non sostituisce un grande cluster di inferenza che esegue a piena velocità dieci modelli di punta. Il suo punto di forza più realistico è fungere da nodo compatto, sempre attivo, per il controllo e i servizi di un'applicazione di IA: coordinare prompt, stato del gioco, API, pipeline audio, log e accesso alla rete, mentre il lavoro più pesante dei modelli viene assegnato al servizio o al percorso di calcolo più adatto.

Il modo più utile di leggere questo progetto è considerarlo un sistema a strati. Il modello linguistico fornisce decisioni e dialoghi, ma un livello di orchestrazione decide di chi è il turno, un livello di stato stabilisce cosa sa ciascun personaggio, un livello vocale trasforma il testo in parlato e un livello di presentazione rende il risultato comprensibile a chi guarda. Rimuovi anche solo uno di questi livelli e dieci agenti “intelligenti” diventano rapidamente dieci finestre di chat scollegate.

La parte difficile è la realtà condivisa, non il numero di agenti

Aggiungere un secondo modello a una conversazione è facile rispetto ad aggiungere un secondo modello che deve rispettare le stesse regole. In una partita a lupi mannari, ogni personaggio ha bisogno di un ruolo privato, di una cronologia pubblica, di una convinzione sugli altri giocatori e di un insieme legale di azioni per la fase corrente. L’applicazione ha quindi bisogno di un’unica fonte autorevole per lo stato della partita, invece di permettere a ogni modello di inventare la propria versione degli eventi.

Una progettazione solida separa lo stato pubblico da quello privato. Lo stato pubblico può includere il giorno corrente, le dichiarazioni pronunciate, i voti e i giocatori eliminati. Lo stato privato può includere i compagni di squadra di un lupo mannaro, il risultato di un veggente o il sospetto nascosto di un personaggio. L’orchestratore crea quindi un contesto diverso per ogni agente, invece di trasmettere ogni segreto a tutti.

Questa separazione rende possibile anche il debug. Se un agente fa un’accusa sospetta, lo sviluppatore può esaminare l’esatta trascrizione pubblica, la memoria privata, il prompt del ruolo e la risposta del modello che l’hanno prodotta. Senza questi confini, la cosiddetta “intelligenza” potrebbe essere semplicemente una fuga accidentale di informazioni da un prompt all’altro.

I prompt dei personaggi richiedono più di un aggettivo caratteriale

Definire un agente “sicuro di sé” e un altro “silenzioso” non basta per creare un cast. Una definizione utile del personaggio combina stile di comunicazione, propensione al rischio, obiettivo, limite di conoscenza specifico del ruolo e una regola che stabilisce come le prove modificano le sue convinzioni. Il personaggio dovrebbe parlare in modo diverso, ma anche prendere decisioni per una ragione che rimane coerente nel corso dei turni.

Ogni agente trae vantaggio da un profilo strutturato: nome, ruolo, persona pubblica, obiettivo privato, fatti noti, sospetti attuali e una memoria compatta degli eventi precedenti. Il prompt può quindi chiedere sia una decisione interna sia una battuta rivolta agli spettatori, mentre l’applicazione conserva solo i campi necessari per la transizione successiva. In questo modo il contesto rimane leggibile man mano che la partita cresce.

Qui esiste un limite importante. Un prompt più lungo non produce automaticamente un personaggio più profondo. Se ogni turno ripete l’intera trascrizione e ogni istruzione, latenza e costi aumentano, mentre il modello continua a non avere una transizione di stato chiara. Una memoria più piccola e curata spesso crea un comportamento più coerente rispetto a un dump non filtrato della conversazione.

La scelta del modello cambia il ritmo della partita

Il video mette in evidenza la scelta dei modelli LLM come parte dell’esperimento, invece di trattare l’“IA” come un unico componente intercambiabile. Moonshot Kimi K3 è indicato nel progetto come componente linguistico, e questa scelta influisce non solo sulla qualità delle risposte, ma anche sulla loro lunghezza, sulla latenza, sul comportamento in caso di rifiuto, sullo stile linguistico e sulla quantità di contesto che può essere mantenuta tra un turno e l’altro.

Un’architettura pratica può assegnare compiti diversi a modelli diversi. Un modello più potente può gestire una deduzione privata complessa, mentre un modello più rapido può produrre brevi reazioni sociali o la narrazione. La regola importante è mantenere il contratto di gioco fuori dal modello. Il modello può proporre un’azione, ma il server deve verificare che sia legale prima di applicarla allo stato.

Anche le API di modelli remoti modificano i confini di privacy e affidabilità. Se il gioco invia informazioni private sui ruoli a un servizio esterno, quel servizio entra a far parte del modello di fiducia. Problemi di rete, limiti di frequenza e modifiche alle API possono mettere in pausa il gioco anche quando il dispositivo locale funziona correttamente. Memorizzare nella cache i prompt, riprovare le richieste idempotenti e registrare gli ID delle richieste rende l’esperimento più facile da riprendere e da spiegare.

La conversazione naturale richiede un motore di gestione dei turni

Dieci agenti che parlano seguendo una coda fissa sembrerebbero partecipare a una teleconferenza gestita da un foglio di calcolo. Il comportamento più convincente nasce da un motore esplicito di gestione dei turni, che sa quando un personaggio può parlare, quando è consentita un’interruzione e quando il tavolo deve passare alla votazione o a un’azione notturna.

Un modello utile è una macchina a stati con fasi come introduzione, discussione aperta, risposta mirata, votazione, azioni notturne e risultati. All’interno di una fase di discussione, lo scheduler può scegliere il prossimo interlocutore combinando equità, pertinenza, sospetti e casualità controllata. Un personaggio può richiedere un’interruzione, ma spetta al motore decidere se la richiesta è valida e come influisce sulla coda.

Ecco perché la “voce realistica” è qualcosa di più della sintesi vocale. Il sistema deve decidere quando inizia l’audio, se è possibile interrompere un enunciato in corso, come mettere in coda una risposta e cosa succede se una richiesta vocale non va a buon fine. Una separazione netta tra le decisioni testuali e la riproduzione audio permette al gioco di continuare anche quando un provider vocale è lento.

La voce aggiunge segnali sociali e nuovi punti di rottura

Il dialogo parlato cambia il modo in cui gli spettatori giudicano gli agenti. Pause, cenni di assenso, interruzioni e differenze nell’identità vocale fanno sembrare una risposta breve parte di un tavolo dal vivo. Il video utilizza Fish Audio per il livello vocale, che svolge una funzione strutturale: trasforma i cambiamenti di stato in eventi che una persona può seguire in tempo reale.

L’audio può anche rivelare bug che il testo nasconde. Una richiesta di sintesi ritardata potrebbe far parlare un personaggio dopo che la partita è già passata a un’altra fase. Una risposta generata molto lunga può bloccare la coda e far sparire gli agenti più silenziosi. L’applicazione dovrebbe quindi associare ogni clip audio a un evento e a una fase di gioco, così da poter scartare le clip obsolete invece di riprodurle fuori contesto.

Anche l’identità vocale richiede una politica di coerenza. Se la voce di un personaggio cambia tra un turno e l’altro, gli spettatori potrebbero interpretare un problema tecnico come l’arrivo di un nuovo personaggio. Mantenere l’assegnazione della voce nella configurazione, anziché inserirla nel prompt del modello, rende il livello di presentazione prevedibile e più facile da sostituire.

Il ciclo di gioco ha bisogno di una fonte di verità lato server

Durante la partita dal vivo, il sistema deve coordinare più delle sole conversazioni in chat. Deve sapere chi è ancora in gioco, quale fase è attiva, quali azioni sono ancora consentite, che cosa ha sentito ogni personaggio e quando un risultato diventa ufficiale. Questi dati appartengono al livello applicativo, non alla risposta libera di un agente.

Un buon record degli eventi potrebbe includere la fase, il parlante, il testo visibile, l’azione privata, il modello utilizzato, lo stato della richiesta e la versione dello stato risultante. Questa struttura supporta la riproduzione: lo sviluppatore può rieseguire la presentazione a partire dagli stessi eventi senza chiedere a ogni modello di rigenerare l’intera partita. Inoltre, facilita il confronto tra due configurazioni del modello nello stesso scenario.

La riproduzione è particolarmente utile per un progetto che sembra spontaneo. Se un personaggio vince grazie a una deduzione convincente, lo sviluppatore può chiedersi se il risultato sia dovuto alla progettazione del ruolo, a una risposta fortunata del modello, a un segreto trapelato o a un problema di sincronizzazione. L’osservabilità trasforma una demo divertente in un sistema che può essere realmente migliorato.

Dove si inserisce ZimaBoard 2 nell’architettura

ZimaBoard 2 è più adatta a operare al margine sempre attivo di questo sistema. Questa collocazione è coerente con la più ampia configurazione dell'assistente di IA locale con ZimaBoard 2: la scheda può ospitare il coordinatore, un piccolo database, dashboard, servizi webhook, code audio o componenti di supporto containerizzati, collegandoli in modo affidabile ad API esterne per modelli e voce. Questo ruolo trae più vantaggio dai consumi ridotti, dall'ingombro compatto e dalla connettività di rete che da un elevato numero di core CPU.

La possibilità per la scheda di eseguire localmente un modello specifico dipende dalle dimensioni del modello, dalla quantizzazione, dalla memoria, dall'accelerazione e dalla latenza richiesta dall'esperienza. Per questo, la realizzazione separata Zero Noichi con ZimaBoard 2 e AMD MI50 è un confronto utile: una maggiore potenza di calcolo della GPU modifica il percorso di inferenza, mentre la scheda può continuare a fornire un host stabile e il livello dei servizi. Una regola sicura per la pianificazione consiste nel separare l'orchestrazione dall'inferenza: progetta l'applicazione in modo che il motore di stato resti utile anche se l'endpoint del modello passa da un servizio locale a un'altra macchina o a un'API ospitata.

Lo storage diretto e l'espansione possono inoltre supportare log, versioni dei prompt, audio memorizzato nella cache e replay delle partite. Questi file non sono il modello in sé, ma costituiscono le prove necessarie per capire come si è comportato il sistema. Un piccolo server che mantiene il progetto riproducibile può essere più prezioso di un dispositivo più veloce che produce soltanto una demo impressionante una tantum.

Cosa rivela il risultato dal vivo sull'IA multi-agente

L'aspetto interessante dell'esperimento è che gli agenti sembrano avere intenzioni sociali: si interrompono, si difendono, sospettano l'uno dell'altro e si coordinano sulla base di informazioni incomplete. Tecnicamente, questi comportamenti emergono dall'interazione tra i prompt dei ruoli, il contesto privato, le transizioni di stato e lo scheduler. Nessuna singola risposta del modello spiega l'intera esperienza.

Questa distinzione è importante per chiunque stia creando un'applicazione di IA locale. Più agenti non significano automaticamente più intelligenza. Aumentano i costi di coordinamento, la gestione del contesto, la superficie di errore e i requisiti di osservabilità. Un gruppo più piccolo con confini di stato ben definiti può produrre un risultato più credibile di un gruppo più numeroso che dimentica le proprie regole.

Il progetto mostra anche perché la latenza è una decisione di prodotto. Una risposta lenta ma ponderata può essere accettabile durante una deduzione a turni, mentre lo stesso ritardo sembra un malfunzionamento durante un breve riconoscimento o un’interruzione. Lo scheduler dovrebbe quindi calibrare l’impegno del modello e la durata della voce in base all’importanza dell’evento, invece di trattare ogni messaggio allo stesso modo.

Come ricreare l’idea senza copiare l’intera produzione

Inizia con tre agenti e una semplice regola sui ruoli nascosti. Crea il registro degli eventi, la macchina a stati e la separazione tra contesto privato e pubblico prima di aggiungere la voce. Quando il ciclo basato solo sul testo sarà in grado di riprodurre un round completo senza divulgare informazioni, aggiungi un unico provider vocale e misura in quale punto l’interazione risulta davvero lenta.

Poi rendi esplicita la configurazione. Conserva i profili dei personaggi, le regole dei ruoli, i percorsi dei modelli, le assegnazioni vocali e le policy di ritentativo al di fuori del testo del prompt. Questo trasforma una dimostrazione una tantum in un sistema che può essere ottimizzato senza riscrivere ogni agente. Inoltre assegna al nodo hardware un compito chiaro: mantenere insieme servizi, configurazione e prove, mentre il backend di inferenza rimane sostituibile. La stessa separazione è utile in un più ampio progetto di server AI locale, dove il runtime e i servizi di supporto possono evolversi a velocità diverse.

Infine, testa i guasti invece di limitarti a verificare il percorso ideale. Interrompi una richiesta a un modello, ritarda una clip audio, rimuovi un player, riavvia il coordinatore e riproduci lo stesso registro degli eventi. Un’applicazione multi-agente convincente non si definisce solo per la sua conversazione migliore; si definisce in base alla capacità del sistema di riprendersi senza cambiare le regole a partita in corso.

Per una piattaforma server domestica compatta in grado di ospitare l’orchestrazione e i servizi di supporto, scopri ZimaBoard 2 - Mini server domestico per la tua grande idea. Per confrontarti con altri builder, entra nella community Discord di ZimaSpace.