Wie Zero Noichi ein KI-Werwolfspiel mit zehn Agenten entwickelt hat

野市 零 / Zero Noichi zeigt, was passiert, wenn zehn KI-Agenten ein gemeinsames Werwolfspiel spielen: Die Herausforderung besteht nicht mehr darin, eine schlaue Antwort zu erzeugen, sondern Stimmen, Rollen, Erinnerungen, Zeitabläufe und Konflikte zu koordinieren, ohne dass sich das Gespräch mechanisch anfühlt.

Dieser Artikel bedankt sich bei 野市 零 / Zero Noichi für die Dokumentation des Experiments im ursprünglichen KI-Werwolf-Video. Das Video wird als Unterhaltungsexperiment präsentiert, zeigt aber auch die technischen Herausforderungen hinter einer glaubwürdigen Multi-Agenten-Anwendung: Wie bringt man Agenten dazu zu warten, zu unterbrechen, sich zu erinnern, zu täuschen und als Mitglieder einer gemeinsamen Welt zu reagieren?

Hinweis zur Zusammenarbeit: Die ursprüngliche Beschreibung erwähnt ZimaBoard 2, einen Creator-Gutschein, Affiliate-Links und die im Experiment verwendeten Softwaredienste. Der Creator stellt seine eigene Implementierung und den vorgesehenen Anwendungszweck vor. Modellversionen, Sprachdienste, Benutzeroberflächen, Hardware-Bundles und Kompatibilität können sich nach der Veröffentlichung ändern.

Das Ergebnis: Ein ZimaBoard 2 – Mini-Home-Server ist kein Ersatz für einen großen Inferenz-Cluster, auf dem zehn Spitzenmodelle mit voller Geschwindigkeit laufen. Seine realistischere Stärke liegt darin, als kompakter, ständig verfügbarer Steuerungs- und Serviceknoten für eine KI-Anwendung zu fungieren: Er koordiniert Prompts, Spielzustand, APIs, Audio-Pipelines, Protokolle und Netzwerkzugriff, während umfangreichere Modellberechnungen dem dafür passenden Service- oder Rechenpfad zugewiesen werden.

Die sinnvollste Art, dieses Projekt zu verstehen, ist als geschichtetes System. Das Sprachmodell liefert Entscheidungen und Dialoge, aber eine Orchestrierungsebene bestimmt, wer an der Reihe ist, eine Zustandsebene legt fest, was jede Figur weiß, eine Sprachebene verwandelt Text in Sprache, und eine Präsentationsebene macht das Ergebnis für Zuschauer verständlich. Entfernt man eine dieser Ebenen, werden aus zehn „intelligenten“ Agenten schnell zehn voneinander getrennte Chatfenster.

Die schwierige Aufgabe ist eine gemeinsame Realität, nicht die Anzahl der Agenten

Ein zweites Modell zu einem Gespräch hinzuzufügen, ist im Vergleich dazu einfach, ein zweites Modell hinzuzufügen, das dieselben Regeln befolgen muss. In einem Werwolfspiel benötigt jede Figur eine private Rolle, eine öffentliche Chronik, eine Einschätzung der anderen Spieler und eine zulässige Menge an Aktionen für die aktuelle Phase. Die Anwendung benötigt daher einen maßgeblichen Spielzustand, statt jedem Modell zu erlauben, seine eigene Version der Ereignisse zu erfinden.

Ein robustes Design trennt den öffentlichen und den privaten Zustand. Der öffentliche Zustand kann den aktuellen Tag, geäußerte Behauptungen, Abstimmungen und ausgeschiedene Spieler umfassen. Der private Zustand kann die Teammitglieder eines Werwolfs, das Ergebnis einer Seherin oder den verborgenen Verdacht einer Figur enthalten. Der Orchestrator erstellt dann für jeden Agenten einen anderen Kontext, anstatt jedem alle Geheimnisse mitzuteilen.

Diese Trennung ermöglicht außerdem das Debugging. Wenn ein Agent eine verdächtige Anschuldigung erhebt, kann der Entwickler genau das öffentliche Transkript, den privaten Speicher, den Rollen-Prompt und die Modellantwort untersuchen, die dazu geführt haben. Ohne diese Grenzen kann die scheinbare „Intelligenz“ lediglich auf einem versehentlichen Informationsleck von einem Prompt in einen anderen beruhen.

Charakter-Prompts brauchen mehr als ein Persönlichkeitsadjektiv

Einen Agenten als „selbstbewusst“ und einen anderen als „still“ zu bezeichnen, reicht nicht aus, um ein Ensemble zu erschaffen. Eine nützliche Charakterdefinition kombiniert einen Sprechstil, eine Risikobereitschaft, ein Ziel, eine rollenspezifische Wissensgrenze und eine Regel dafür, wie Beweise die Überzeugung verändern. Der Charakter sollte anders klingen, aber auch aus einem Grund Entscheidungen treffen, der über mehrere Runden hinweg konsistent bleibt.

Jeder Agent profitiert von einem strukturierten Profil: Name, Rolle, öffentliche Persona, privates Ziel, bekannte Fakten, aktuelle Verdachtsmomente und eine kompakte Erinnerung an frühere Ereignisse. Der Prompt kann dann sowohl nach einer internen Entscheidung als auch nach einer an die Zuschauer gerichteten Äußerung fragen, während die Anwendung nur die für den nächsten Übergang benötigten Felder speichert. So bleibt der Kontext übersichtlich, wenn das Spiel wächst.

Hier gibt es eine wichtige Grenze. Ein längerer Prompt erzeugt nicht automatisch einen vielschichtigeren Charakter. Wenn jede Runde das gesamte Transkript und jede Anweisung erneut übermittelt, steigen Latenz und Kosten, während dem Modell weiterhin ein klarer Zustandsübergang fehlt. Ein kleinerer, sorgfältig kuratierter Speicher führt oft zu konsistenterem Verhalten als ein ungefilterter Gesprächsverlauf.

Die Modellauswahl verändert den Rhythmus des Spiels

Das Video hebt die Auswahl der LLM-Modelle als Teil des Experiments hervor, statt „KI“ als eine austauschbare Komponente zu behandeln. Moonshot Kimi K3 wird im Projekt als Sprachmodellkomponente genannt, und diese Wahl beeinflusst nicht nur die Antwortqualität, sondern auch Antwortlänge, Latenz, Verweigerungsverhalten, Sprachstil und die Menge an Kontext, die zwischen den Gesprächsrunden übertragen werden kann.

Eine praktische Architektur kann verschiedenen Modellen unterschiedliche Aufgaben zuweisen. Ein leistungsfähigeres Modell kann eine schwierige private Schlussfolgerung übernehmen, während ein schnelleres Modell kurze soziale Reaktionen oder Erzähltexte erzeugt. Die wichtigste Regel ist, den Spielvertrag außerhalb des Modells zu halten. Das Modell kann eine Aktion vorschlagen, aber der Server sollte prüfen, ob diese Aktion zulässig ist, bevor er sie auf den Spielstatus anwendet.

Remote-Modell-APIs verändern auch die Grenzen für Datenschutz und Zuverlässigkeit. Wenn das Spiel private Rolleninformationen an einen externen Dienst sendet, wird dieser Dienst Teil des Vertrauensmodells. Netzwerkausfälle, Ratenbegrenzungen und API-Änderungen können das Spiel pausieren, selbst wenn das lokale Gerät fehlerfrei funktioniert. Das Zwischenspeichern von Prompts, das Wiederholen idempotenter Anfragen und das Protokollieren von Anfrage-IDs erleichtern es, das Experiment fortzusetzen und nachzuvollziehen.

Natürliche Gespräche erfordern eine Engine für den Sprecherwechsel

Zehn Agenten, die in einer festen Reihenfolge sprechen, würden wie eine von einer Tabellenkalkulation gesteuerte Telefonkonferenz klingen. Überzeugenderes Verhalten entsteht durch eine explizite Engine für den Sprecherwechsel, die weiß, wann eine Figur sprechen darf, wann eine Unterbrechung zulässig ist und wann die Runde mit einer Abstimmung oder einer nächtlichen Aktion fortgesetzt werden muss.

Ein nützliches Muster ist eine Zustandsmaschine mit Phasen wie Einführung, offener Diskussion, gezielter Antwort, Abstimmung, nächtlichen Aktionen und Ergebnissen. Innerhalb einer Diskussionsphase kann der Scheduler den nächsten Sprecher anhand einer Kombination aus Fairness, Relevanz, Verdacht und kontrolliertem Zufall auswählen. Eine Figur kann eine Unterbrechung anfordern, aber die Engine entscheidet, ob die Anfrage gültig ist und wie sie sich auf die Warteschlange auswirkt.

Deshalb ist „realistische Sprachausgabe“ mehr als Text-to-Speech. Das System muss entscheiden, wann die Audiowiedergabe beginnt, ob eine aktuelle Äußerung unterbrochen werden darf, wie eine Antwort in die Warteschlange eingereiht wird und was passiert, wenn eine Sprachanfrage fehlschlägt. Eine klare Trennung zwischen Textentscheidungen und Audiowiedergabe ermöglicht es dem Spiel, weiterzulaufen, selbst wenn ein Sprachanbieter langsam ist.

Sprachausgabe fügt soziale Signale hinzu – und neue Fehlerquellen

Gesprochene Dialoge verändern die Wahrnehmung der Agenten durch die Zuschauer. Pausen, Bestätigungen, Unterbrechungen und Unterschiede in der Stimmidentität lassen eine kurze Antwort wie einen Teil einer Live-Runde wirken. Für die Sprachschicht verwendet das Video Fish Audio, die eine strukturelle Funktion erfüllt: Sie verwandelt Zustandsänderungen in Ereignisse, die ein Mensch in Echtzeit verfolgen kann.

Audio kann außerdem Fehler sichtbar machen, die Text verbirgt. Eine verzögerte Sprachsyntheseanfrage kann dazu führen, dass eine Figur spricht, nachdem das Spiel bereits in eine andere Phase gewechselt hat. Eine lange generierte Antwort kann die Warteschlange blockieren und dafür sorgen, dass leisere Agenten nicht zu hören sind. Daher sollte die Anwendung jeden Audioclip mit einem Spielereignis und einer Phase verknüpfen, damit veraltete Clips verworfen werden können, statt sie aus dem Kontext gerissen abzuspielen.

Auch die Stimmidentität braucht eine Konsistenzrichtlinie. Wenn sich die Stimme einer Figur zwischen den Runden ändert, könnten Zuschauer einen technischen Fehler für eine neue Figur halten. Wenn die Stimmzuordnung in der Konfiguration statt im Modell-Prompt festgelegt wird, bleibt die Präsentation vorhersehbar und lässt sich leichter austauschen.

Der Spielablauf benötigt eine serverseitige Quelle der Wahrheit

Während des Live-Spiels muss das System mehr als nur Chatnachrichten koordinieren. Es muss wissen, wer noch lebt, welche Phase aktiv ist, welche Aktionen noch zulässig sind, was jede Figur gehört hat und wann ein Ergebnis offiziell wird. Diese Fakten gehören in die Anwendungsschicht, nicht in eine frei formulierte Antwort eines Agenten.

Ein guter Ereigniseintrag könnte die Phase, den Sprecher, den sichtbaren Text, die private Aktion, das verwendete Modell, den Status der Anfrage und die resultierende Zustandsversion enthalten. Diese Struktur unterstützt Replay: Der Entwickler kann die Präsentation anhand derselben Ereignisse erneut ausführen, ohne jedes Modell das gesamte Spiel neu generieren zu lassen. Außerdem wird es einfacher, zwei Modellkonfigurationen unter identischen Bedingungen zu vergleichen.

Replay ist besonders wertvoll für ein Projekt, das spontan wirkt. Wenn eine Figur aufgrund einer überzeugenden Schlussfolgerung gewinnt, kann der Entwickler prüfen, ob das Ergebnis auf dem Rollendesign, einer glücklichen Modellantwort, einem durchgesickerten Geheimnis oder einer Eigenheit der Ablaufplanung beruhte. Beobachtbarkeit macht aus einer unterhaltsamen Demo ein System, das tatsächlich verbessert werden kann.

Wo ZimaBoard 2 in die Architektur passt

ZimaBoard 2 eignet sich am besten für die dauerhaft aktive Edge-Ebene dieses Systems. Diese Positionierung entspricht dem umfassenderen Setup eines lokalen KI-Assistenten mit ZimaBoard 2: Das Board kann den Koordinator, eine kleine Datenbank, Dashboards, Webhook-Dienste, Audio-Warteschlangen oder containerisierte Support-Komponenten hosten und sie zuverlässig mit externen Modell- und Sprach-APIs verbinden. Diese Rolle profitiert stärker von geringem Stromverbrauch, einer kompakten Bauform und Netzwerkkonnektivität als von einer großen Anzahl an CPU-Kernen.

Ob das Board ein bestimmtes Modell lokal ausführen kann, hängt von der Modellgröße, der Quantisierung, dem Arbeitsspeicher, der Beschleunigung und der für das Erlebnis erforderlichen Latenz ab. Deshalb ist der separate Aufbau von Zero Noichi mit ZimaBoard 2 und AMD MI50 ein nützlicher Vergleich: Zusätzliche GPU-Rechenleistung verändert den Inferenzpfad, während das Board weiterhin die stabile Host- und Service-Ebene bereitstellen kann. Die sichere Planungsregel lautet, Orchestrierung und Inferenz zu trennen: Entwerfen Sie die Anwendung so, dass die Zustands-Engine weiterhin nützlich bleibt, selbst wenn der Modellendpunkt zwischen einem lokalen Dienst, einem anderen Rechner oder einer gehosteten API wechselt.

Direkter Speicher und Erweiterungsmöglichkeiten können außerdem Protokolle, Prompt-Versionen, zwischengespeicherte Audiodateien und Spielwiederholungen aufnehmen. Diese Dateien sind nicht das Modell selbst, aber sie liefern die Belege, die nötig sind, um das Verhalten des Systems zu verstehen. Ein kleiner Server, der das Projekt reproduzierbar hält, kann wertvoller sein als ein schnelleres Gerät, das nur eine beeindruckende einmalige Demo erzeugt.

Was das Live-Ergebnis über Multi-Agenten-KI zeigt

Der Reiz des Experiments liegt darin, dass die Agenten scheinbar soziale Absichten haben: Sie unterbrechen einander, verteidigen sich, verdächtigen sich gegenseitig und koordinieren sich anhand unvollständiger Informationen. Technisch entstehen diese Verhaltensweisen aus dem Zusammenspiel von Rollen-Prompts, privatem Kontext, Zustandsübergängen und dem Scheduler. Keine einzelne Modellantwort erklärt das gesamte Erlebnis.

Diese Unterscheidung ist für alle wichtig, die eine lokale KI-Anwendung entwickeln. Mehr Agenten bedeuten nicht automatisch mehr Intelligenz. Sie erhöhen den Koordinationsaufwand, die Anforderungen an Kontextverwaltung und Beobachtbarkeit sowie die Fehleranfälligkeit. Eine kleinere Gruppe mit klar abgegrenzten Zuständen kann ein glaubwürdigeres Ergebnis liefern als eine größere Gruppe, die ihre Regeln vergisst.

Das Projekt zeigt außerdem, warum Latenz eine Produktentscheidung ist. Eine langsame, aber durchdachte Antwort kann während einer rundenbasierten Deduktion akzeptabel sein, während dieselbe Verzögerung bei einer kurzen Bestätigung oder Unterbrechung fehlerhaft wirkt. Der Scheduler sollte daher den Modellaufwand und die Sprachlänge an die Bedeutung des Ereignisses anpassen, statt jede Nachricht gleich zu behandeln.

So reproduzieren Sie die Idee, ohne die gesamte Produktion zu kopieren

Beginnen Sie mit drei Agenten und einer einfachen Regel für verborgene Rollen. Erstellen Sie das Ereignisprotokoll, die Zustandsmaschine sowie die Trennung zwischen privatem und öffentlichem Kontext, bevor Sie Sprache hinzufügen. Sobald die rein textbasierte Schleife eine vollständige Runde wiedergeben kann, ohne Informationen preiszugeben, fügen Sie einen einzelnen Sprachanbieter hinzu und messen Sie, an welcher Stelle sich die Interaktion tatsächlich langsam anfühlt.

Machen Sie als Nächstes die Konfiguration explizit. Speichern Sie Charakterprofile, Rollenregeln, Modellrouten, Sprachzuweisungen und Wiederholungsrichtlinien außerhalb des Prompt-Texts. So wird aus einer einmaligen Demonstration ein System, das sich anpassen lässt, ohne jeden Agenten neu schreiben zu müssen. Außerdem erhält der Hardwareknoten eine klare Aufgabe: Dienste, Konfiguration und Nachweise zusammenzuhalten, während das Inferenz-Backend austauschbar bleibt. Dieselbe Trennung ist auch bei einem umfassenderen Aufbau eines lokalen KI-Servers nützlich, bei dem sich Laufzeit und unterstützende Dienste unterschiedlich schnell weiterentwickeln können.

Testen Sie schließlich Fehler, statt nur den Erfolgsfall zu prüfen. Stoppen Sie eine Modellanfrage, verzögern Sie einen Audioclip, entfernen Sie einen Spieler, starten Sie den Koordinator neu und spielen Sie dasselbe Ereignisprotokoll erneut ab. Eine überzeugende Multi-Agenten-Anwendung zeichnet sich nicht nur durch ihr bestes Gespräch aus, sondern auch dadurch, ob sich das System erholen kann, ohne die Regeln mitten im Spiel zu ändern.

Für eine kompakte Home-Server-Plattform, auf der die Orchestrierung und unterstützende Dienste betrieben werden können, entdecken Sie ZimaBoard 2 – Mini-Home-Server für Ihre große Idee. Um sich mit anderen Entwicklern auszutauschen, treten Sie der ZimaSpace-Discord-Community bei.