Comment Zero Noichi a créé un jeu de Loup-garou avec dix agents IA

野市 零 / Zero Noichi montre ce qui se passe lorsque dix agents d’IA partagent une partie de loup-garou : le défi ne consiste plus à générer une réponse ingénieuse, mais à coordonner les voix, les rôles, la mémoire, le timing et les conflits sans donner à la conversation un aspect mécanique.

Cet article remercie 野市 零 / Zero Noichi d’avoir documenté l’expérience dans la vidéo originale sur le loup-garou IA. La vidéo est présentée comme une expérience de divertissement, mais elle met également en évidence les problèmes d’ingénierie propres à une application multi-agents crédible : faire attendre, interrompre, se souvenir, tromper et réagir les agents en tant que membres d’un même monde partagé.

Divulgation concernant la collaboration : La description originale fait référence à la ZimaBoard 2, à un code promotionnel destiné aux créateurs, à des liens affiliés et aux services logiciels utilisés dans l’expérience. Le créateur partage sa propre implémentation et son usage prévu. Les versions des modèles, les services vocaux, les interfaces, les ensembles matériels et la compatibilité peuvent changer après la publication.

Le résultat : Un ZimaBoard 2 - Mini serveur domestique ne remplace pas un vaste cluster d’inférence exécutant à pleine vitesse dix modèles de pointe. Sa force la plus réaliste est de servir de nœud compact de contrôle et de services, toujours allumé, pour une application d’IA : coordonner les invites, l’état du jeu, les API, les pipelines audio, les journaux et l’accès réseau, tandis que les tâches de modélisation plus lourdes sont confiées au service ou au chemin de calcul le mieux adapté.

La meilleure façon de comprendre ce projet est de le voir comme un système en couches. Le modèle de langage fournit les décisions et les dialogues, mais une couche d’orchestration détermine à qui revient le tour, une couche d’état détermine ce que chaque personnage sait, une couche vocale transforme le texte en parole, et une couche de présentation rend le résultat compréhensible pour le spectateur. Supprimez l’une de ces couches et dix agents « intelligents » deviennent rapidement dix fenêtres de discussion déconnectées.

La difficulté réside dans une réalité partagée, pas dans le nombre d’agents

Ajouter un deuxième modèle à une conversation est facile comparé à l’ajout d’un deuxième modèle qui doit respecter les mêmes règles. Dans une partie de loup-garou, chaque personnage a besoin d’un rôle privé, d’un historique public, d’une opinion sur les autres joueurs et d’un ensemble légal d’actions pour la phase en cours. L’application a donc besoin d’un état de jeu faisant autorité, au lieu de laisser chaque modèle inventer sa propre version des événements.

Une conception robuste sépare l’état public de l’état privé. L’état public peut inclure le jour en cours, les déclarations prononcées, les votes et les joueurs éliminés. L’état privé peut inclure les coéquipiers d’un loup-garou, le résultat d’un voyant ou les soupçons cachés d’un personnage. L’orchestrateur construit ensuite un contexte différent pour chaque agent au lieu de diffuser tous les secrets à tout le monde.

Cette séparation permet également le débogage. Si un agent porte une accusation suspecte, le développeur peut examiner la transcription publique exacte, la mémoire privée, le prompt de rôle et la réponse du modèle qui l’ont produite. Sans ces limites, l’« intelligence » apparente peut n’être qu’une fuite accidentelle d’informations d’un prompt vers un autre.

Les prompts de personnages nécessitent plus qu’un adjectif de personnalité

Qualifier un agent de « sûr de lui » et un autre de « silencieux » ne suffit pas à créer un casting. Une définition utile du personnage associe un style de parole, une tolérance au risque, un objectif, une limite de connaissances propre à son rôle et une règle déterminant la manière dont les preuves modifient ses convictions. Le personnage doit avoir une voix différente, mais aussi prendre des décisions pour une raison qui reste cohérente au fil des tours.

Chaque agent bénéficie d’un profil structuré : nom, rôle, persona publique, objectif privé, faits connus, soupçons actuels et mémoire concise des événements précédents. Le prompt peut alors demander à la fois une décision interne et une réplique destinée aux spectateurs, tandis que l’application ne conserve que les champs nécessaires à la transition suivante. Le contexte reste ainsi lisible à mesure que le jeu évolue.

Il existe ici une limite importante. Un prompt plus long ne produit pas automatiquement un personnage plus profond. Si chaque tour répète l’intégralité de la transcription et toutes les instructions, la latence et le coût augmentent, tandis que le modèle ne dispose toujours pas d’une transition d’état claire. Une mémoire plus réduite et soigneusement sélectionnée produit souvent un comportement plus cohérent qu’une copie brute de la conversation.

Le choix du modèle modifie le rythme du jeu

La vidéo met en avant le choix des modèles de LLM comme faisant partie intégrante de l’expérience, plutôt que de traiter l’« IA » comme un composant interchangeable. Moonshot Kimi K3 est cité dans le projet comme composant de modèle de langage, et ce choix influe non seulement sur la qualité des réponses, mais aussi sur leur longueur, la latence, le comportement en cas de refus, le style linguistique et la quantité de contexte pouvant être conservée entre les tours.

Une architecture pratique peut attribuer différentes tâches à différents modèles. Un modèle plus puissant peut s’occuper d’une déduction privée complexe, tandis qu’un modèle plus rapide génère de courtes réactions sociales ou une narration. La règle importante est de garder le contrat du jeu en dehors du modèle. Le modèle peut proposer une action, mais le serveur doit vérifier que cette action est légale avant de l’appliquer à l’état du jeu.

Les API de modèles distants modifient également les limites en matière de confidentialité et de fiabilité. Si le jeu envoie des informations privées sur les rôles à un service externe, ce service fait partie du modèle de confiance. Les défaillances réseau, les limites de débit et les changements d’API peuvent mettre le jeu en pause même lorsque l’appareil local fonctionne correctement. La mise en cache des invites, la nouvelle tentative des requêtes idempotentes et l’enregistrement des identifiants de requête facilitent la reprise et l’explication de l’expérience.

Une conversation naturelle nécessite un moteur de gestion des tours de parole

Dix agents qui parlent selon une file d’attente fixe donneraient l’impression d’une conférence téléphonique contrôlée par un tableur. Le comportement le plus convaincant vient d’un moteur explicite de gestion des tours de parole, qui sait quand un personnage peut parler, quand une interruption est autorisée et quand la table doit passer au vote ou à une action nocturne.

Un schéma utile consiste à utiliser une machine à états comportant des phases telles que la présentation, la discussion ouverte, la réponse ciblée, le vote, les actions nocturnes et les résultats. Au sein d’une phase de discussion, le planificateur peut choisir le prochain intervenant en combinant équité, pertinence, niveau de suspicion et aléatoire contrôlé. Un personnage peut demander une interruption, mais le moteur décide si la demande est valide et comment elle modifie la file d’attente.

C’est pourquoi une « voix réaliste » est bien plus que de la synthèse vocale. Le système doit décider quand l’audio démarre, si une prise de parole en cours peut être interrompue, comment une réponse est mise en file d’attente et ce qui se passe en cas d’échec d’une requête vocale. Une séparation nette entre les décisions textuelles et la lecture audio permet au jeu de continuer même lorsqu’un fournisseur de voix est lent.

La voix ajoute des indices sociaux — et de nouveaux modes de défaillance

Le dialogue parlé modifie la manière dont les spectateurs évaluent les agents. Les pauses, les acquiescements, les interruptions et les différences d’identité vocale donnent à une réponse courte l’impression de faire partie d’une table de jeu en direct. La vidéo utilise Fish Audio pour la couche vocale, qui joue un rôle structurel : elle transforme les changements d’état en événements qu’un humain peut suivre en temps réel.

L’audio peut également révéler des bugs que le texte dissimule. Une demande de synthèse retardée peut amener un personnage à parler alors que la partie est déjà passée à une autre phase. Une réponse générée trop longue peut bloquer la file d’attente et faire disparaître les agents plus discrets. L’application devrait donc associer chaque extrait audio à un événement et à une phase du jeu, afin de pouvoir supprimer les extraits obsolètes au lieu de les diffuser hors contexte.

L’identité vocale a également besoin d’une politique de cohérence. Si la voix d’un personnage change d’un tour à l’autre, les spectateurs peuvent prendre une défaillance technique pour l’apparition d’un nouveau personnage. Conserver l’attribution des voix dans la configuration, plutôt qu’à l’intérieur de l’invite du modèle, rend la couche de présentation prévisible et plus facile à remplacer.

La boucle de jeu a besoin d’une source de vérité côté serveur

Pendant la partie en direct, le système doit coordonner bien plus que des messages de discussion. Il doit savoir qui est encore en vie, quelle phase est active, quelles actions sont encore autorisées, ce que chaque personnage a entendu et à quel moment un résultat devient officiel. Ces informations relèvent de la couche applicative, et non de la réponse en texte libre d’un agent.

Un bon enregistrement d’événement peut inclure la phase, l’intervenant, le texte visible, l’action privée, le modèle utilisé, l’état de la requête et la version de l’état résultant. Cette structure permet la relecture : le développeur peut relancer la présentation à partir des mêmes événements sans demander à chaque modèle de régénérer l’intégralité de la partie. Elle facilite également la comparaison de deux configurations de modèles dans le même scénario.

La relecture est particulièrement précieuse pour un projet qui semble spontané. Si un personnage gagne grâce à une déduction convaincante, le développeur peut vérifier si le résultat provient de la conception du rôle, d’une réponse chanceuse du modèle, d’un secret divulgué ou d’une particularité de planification. L’observabilité transforme une démonstration divertissante en un système qui peut réellement être amélioré.

Où ZimaBoard 2 s’intègre dans l’architecture

ZimaBoard 2 est particulièrement pertinente à la périphérie toujours active de ce système. Ce positionnement est cohérent avec la configuration d’assistant d’IA locale avec ZimaBoard 2 présentée plus largement : la carte peut héberger le coordinateur, une petite base de données, des tableaux de bord, des services webhook, des files d’attente audio ou des composants de support conteneurisés, tout en assurant une connexion fiable aux API externes de modèles et de voix. Ce rôle tire davantage parti d’une faible consommation, d’un encombrement réduit et d’une connectivité réseau que d’un grand nombre de cœurs CPU.

La capacité de la carte à exécuter localement un modèle donné dépend de la taille du modèle, de sa quantification, de la mémoire, de l’accélération et de la latence requise par l’expérience. C’est pourquoi le montage Zero Noichi avec ZimaBoard 2 et AMD MI50 constitue une comparaison utile : une puissance de calcul GPU supplémentaire modifie le chemin d’inférence, tandis que la carte peut toujours fournir la couche stable d’hébergement et de services. La règle de planification la plus sûre consiste à séparer l’orchestration de l’inférence : concevez l’application de manière à ce que le moteur d’état reste utile, même si le point de terminaison du modèle passe d’un service local à une autre machine ou à une API hébergée.

Le stockage direct et l’extension peuvent également prendre en charge les journaux, les versions des prompts, les fichiers audio mis en cache et les replays des parties. Ces fichiers ne constituent pas le modèle lui-même, mais ils fournissent les éléments nécessaires pour comprendre le comportement du système. Un petit serveur qui maintient la reproductibilité du projet peut avoir davantage de valeur qu’un appareil plus rapide qui ne produit qu’une démonstration impressionnante en une seule fois.

Ce que le résultat en direct révèle sur l’IA multi-agents

L’intérêt de l’expérience vient du fait que les agents semblent avoir une intention sociale : ils s’interrompent, se défendent, se soupçonnent mutuellement et se coordonnent à partir d’informations incomplètes. Techniquement, ces comportements émergent de l’interaction entre les prompts de rôle, le contexte privé, les transitions d’état et le planificateur. Aucune réponse unique du modèle n’explique l’ensemble de l’expérience.

Cette distinction est importante pour quiconque développe une application d’IA locale. Un plus grand nombre d’agents ne signifie pas automatiquement davantage d’intelligence. Cela augmente les coûts de coordination, les besoins en gestion du contexte et en observabilité, ainsi que la surface de défaillance. Un groupe plus restreint doté de limites d’état claires peut produire un résultat plus crédible qu’un groupe plus nombreux qui oublie ses règles.

Le projet montre également pourquoi la latence est une décision produit. Une réponse lente mais réfléchie peut être acceptable lors d’une déduction au tour par tour, tandis que le même délai semble problématique pendant une brève confirmation ou une interruption. Le planificateur doit donc adapter l’effort du modèle et la longueur de la voix à l’importance de l’événement, au lieu d’appliquer le même traitement à chaque message.

Comment recréer l’idée sans copier toute la production

Commencez avec trois agents et une seule règle simple de rôle caché. Créez le journal d’événements, la machine à états et la séparation entre les contextes privés et publics avant d’ajouter la voix. Une fois que la boucle textuelle peut rejouer un tour complet sans divulguer d’informations, ajoutez un seul fournisseur vocal et mesurez les moments où l’interaction semble réellement lente.

Ensuite, rendez la configuration explicite. Stockez les profils des personnages, les règles de rôle, les routes des modèles, les attributions vocales et les politiques de nouvelle tentative en dehors du texte des invites. Vous transformerez ainsi une démonstration ponctuelle en un système qui peut être ajusté sans réécrire chaque agent. Cela donne également au nœud matériel une mission claire : conserver les services, la configuration et les éléments de preuve au même endroit, tandis que le backend d’inférence reste remplaçable. Cette séparation est également utile dans le cadre plus large de la création d’un serveur d’IA local, où l’environnement d’exécution et les services associés peuvent évoluer à des rythmes différents.

Enfin, testez les défaillances au lieu de tester uniquement le scénario idéal. Arrêtez une requête de modèle, retardez un extrait audio, retirez un joueur, redémarrez le coordinateur et rejouez le même journal d’événements. Une application multi-agents convaincante ne se définit pas seulement par sa meilleure conversation ; elle se définit par la capacité du système à récupérer sans modifier les règles en cours de partie.

Pour une plateforme compacte de serveur domestique capable d’héberger l’orchestration et les services associés, découvrez ZimaBoard 2 - Mini-serveur domestique pour vos grandes idées. Pour échanger avec d’autres créateurs, rejoignez la communauté Discord ZimaSpace.