Cómo Zero Noichi creó un juego de hombres lobo con diez agentes de IA

野市 零 / Zero Noichi muestra qué ocurre cuando diez agentes de IA comparten una partida de hombres lobo: el desafío ya no consiste en generar una respuesta ingeniosa, sino en coordinar voces, roles, memoria, tiempos y conflictos sin que la conversación parezca mecánica.

Este artículo agradece a 野市 零 / Zero Noichi por documentar el experimento en el video original sobre hombres lobo con IA. El video se presenta como un experimento de entretenimiento, pero también expone los problemas de ingeniería que hay detrás de una aplicación multiagente convincente: cómo hacer que los agentes esperen, interrumpan, recuerden, engañen y reaccionen como miembros de un mismo mundo compartido.

Declaración sobre la colaboración: La descripción original menciona ZimaBoard 2, un cupón para creadores, enlaces de afiliados y los servicios de software utilizados en el experimento. El creador comparte su propia implementación y el uso previsto. Las versiones de los modelos, los servicios de voz, las interfaces, los paquetes de hardware y la compatibilidad pueden cambiar después de la publicación.

El resultado: Un ZimaBoard 2 - Mini servidor doméstico no sustituye a un gran clúster de inferencia que ejecute diez modelos de vanguardia a toda velocidad. Su fortaleza más realista es actuar como un nodo compacto de control y servicios, siempre activo, para una aplicación de IA: coordinar prompts, el estado del juego, las API, las canalizaciones de audio, los registros y el acceso a la red, mientras el trabajo más pesado de los modelos se asigna al servicio o recurso informático que mejor se adapte.

La forma útil de entender este proyecto es como un sistema por capas. El modelo de lenguaje proporciona decisiones y diálogos, pero una capa de orquestación decide de quién es el turno, una capa de estado determina qué sabe cada personaje, una capa de voz convierte el texto en habla y una capa de presentación hace que el resultado sea comprensible para el espectador. Si se elimina cualquiera de esas capas, diez agentes «inteligentes» se convierten rápidamente en diez ventanas de chat desconectadas.

La parte difícil es la realidad compartida, no el número de agentes

Añadir un segundo modelo a una conversación es fácil en comparación con añadir un segundo modelo que deba obedecer las mismas reglas. En un juego de hombres lobo, cada personaje necesita una función privada, un historial público, una creencia sobre los demás jugadores y un conjunto legal de acciones para la fase actual. Por lo tanto, la aplicación necesita un único estado de juego autoritativo, en lugar de permitir que cada modelo invente su propia versión de los acontecimientos.

Un diseño sólido separa el estado público del privado. El estado público puede incluir el día actual, las afirmaciones expresadas, los votos y los jugadores eliminados. El estado privado puede incluir los compañeros de un hombre lobo, el resultado de un vidente o la sospecha oculta de un personaje. Después, el orquestador crea un contexto diferente para cada agente en lugar de difundir todos los secretos entre todos.

Esta separación también permite depurar el sistema. Si un agente hace una acusación sospechosa, el desarrollador puede inspeccionar la transcripción pública exacta, la memoria privada, el prompt de función y la respuesta del modelo que la produjeron. Sin esos límites, la aparente «inteligencia» podría ser simplemente una filtración accidental de información de un prompt a otro.

Los prompts de personajes necesitan más que un adjetivo de personalidad

Llamar «confiado» a un agente y «callado» a otro no basta para crear un elenco. Una definición de personaje útil combina un estilo de habla, una tolerancia al riesgo, un objetivo, un límite de conocimiento específico de su función y una regla sobre cómo las pruebas modifican sus creencias. El personaje debe sonar diferente, pero también tomar decisiones por una razón que se mantenga coherente a lo largo de los turnos.

Cada agente se beneficia de un perfil estructurado: nombre, función, personalidad pública, objetivo privado, hechos conocidos, sospechas actuales y una memoria compacta de eventos anteriores. El prompt puede pedir tanto una decisión interna como una frase dirigida al público, mientras la aplicación almacena solo los campos necesarios para la siguiente transición. Así, el contexto sigue siendo legible a medida que crece el juego.

Aquí hay un límite importante. Un prompt más largo no produce automáticamente un personaje más profundo. Si cada turno repite toda la transcripción y todas las instrucciones, aumentan la latencia y el coste, mientras el modelo sigue sin tener una transición de estado clara. Una memoria más pequeña y seleccionada suele generar un comportamiento más coherente que volcar una conversación sin filtrar.

La selección del modelo cambia el ritmo del juego

El vídeo destaca la elección de modelos de LLM como parte del experimento, en lugar de tratar la «IA» como un componente intercambiable. En el proyecto se menciona Moonshot Kimi K3 como componente del modelo de lenguaje, y esa elección afecta no solo a la calidad de las respuestas, sino también a su longitud, latencia, comportamiento ante rechazos, estilo lingüístico y cantidad de contexto que puede conservarse entre turnos.

Una arquitectura práctica puede asignar distintas tareas a modelos diferentes. Un modelo más potente puede encargarse de una deducción privada difícil, mientras que uno más rápido genera reacciones sociales breves o narraciones. La regla importante es mantener el contrato del juego fuera del modelo. El modelo puede proponer una acción, pero el servidor debe validar si esa acción es legal antes de aplicarla al estado.

Las API de modelos remotos también modifican los límites de privacidad y fiabilidad. Si el juego envía información privada sobre los roles a un servicio externo, ese servicio pasa a formar parte del modelo de confianza. Los fallos de red, los límites de frecuencia y los cambios en la API pueden pausar el juego incluso cuando el dispositivo local funciona correctamente. Almacenar en caché las indicaciones, reintentar solicitudes idempotentes y registrar los identificadores de solicitud facilita reanudar el experimento y explicar lo ocurrido.

La conversación natural requiere un motor de gestión de turnos

Diez agentes hablando en una cola fija sonarían como una llamada de conferencia controlada por una hoja de cálculo. El comportamiento más convincente surge de un motor explícito de gestión de turnos que sabe cuándo puede hablar un personaje, cuándo se permite una interrupción y cuándo la mesa debe pasar a una votación o a una acción nocturna.

Un patrón útil es una máquina de estados con fases como introducción, debate abierto, respuesta dirigida, votación, acciones nocturnas y resultados. Dentro de una fase de debate, el planificador puede elegir al siguiente hablante combinando equidad, relevancia, sospecha y aleatoriedad controlada. Un personaje puede solicitar una interrupción, pero el motor decide si la solicitud es válida y cómo afecta a la cola.

Por eso, la «voz realista» es mucho más que la conversión de texto a voz. El sistema debe decidir cuándo comienza el audio, si se puede interrumpir una intervención en curso, cómo se pone en cola una respuesta y qué ocurre si falla una solicitud de voz. Una separación clara entre las decisiones de texto y la reproducción de audio permite que el juego continúe incluso cuando un proveedor de voz responde lentamente.

La voz añade señales sociales y nuevos modos de fallo

El diálogo hablado cambia la forma en que los espectadores juzgan a los agentes. Las pausas, las confirmaciones, las interrupciones y las diferencias de identidad vocal hacen que una respuesta breve parezca parte de una mesa en directo. El vídeo utiliza Fish Audio para la capa de voz, que cumple una función estructural: convierte las transiciones de estado en eventos que una persona puede seguir en tiempo real.

El audio también puede revelar errores que el texto oculta. Una solicitud de síntesis retrasada puede hacer que un personaje hable después de que la partida ya haya pasado a otra fase. Una respuesta generada demasiado larga puede bloquear la cola y hacer que los agentes más silenciosos desaparezcan. Por eso, la aplicación debería asociar cada clip de audio con un evento y una fase del juego, de modo que los clips obsoletos puedan descartarse en lugar de reproducirse fuera de contexto.

La identidad de voz también necesita una política de coherencia. Si la voz de un personaje cambia entre turnos, los espectadores pueden interpretar un fallo técnico como la aparición de un personaje nuevo. Mantener la asignación de voz en la configuración, en lugar de incluirla en el prompt del modelo, hace que la capa de presentación sea predecible y más fácil de reemplazar.

El ciclo del juego necesita una fuente de verdad en el servidor

Durante la partida en directo, el sistema debe coordinar algo más que mensajes de chat. Necesita saber quién sigue con vida, qué fase está activa, qué acciones siguen siendo legales, qué ha escuchado cada personaje y cuándo un resultado se vuelve oficial. Esos datos pertenecen a la capa de aplicación, no a una respuesta de formato libre de un agente.

Un buen registro de eventos podría incluir la fase, el interlocutor, el texto visible, la acción privada, el modelo utilizado, el estado de la solicitud y la versión del estado resultante. Esta estructura permite la reproducción: el desarrollador puede volver a ejecutar la presentación a partir de los mismos eventos sin pedir a cada modelo que regenere toda la partida. También facilita la comparación de dos configuraciones de modelos en el mismo escenario.

La reproducción es especialmente valiosa para un proyecto que parece espontáneo. Si un personaje gana gracias a una deducción convincente, el desarrollador puede preguntarse si el resultado se debió al diseño del rol, a una respuesta afortunada del modelo, a un secreto filtrado o a una peculiaridad de la programación. La observabilidad convierte una demostración entretenida en un sistema que realmente se puede mejorar.

Dónde encaja ZimaBoard 2 en la arquitectura

ZimaBoard 2 tiene más sentido en el extremo siempre activo de este sistema. Esa posición es coherente con la configuración de asistente de IA local con ZimaBoard 2: la placa puede alojar el coordinador, una base de datos pequeña, paneles, servicios de webhook, colas de audio o componentes auxiliares en contenedores, mientras se conecta de forma fiable a API externas de modelos y voz. Ese papel se beneficia más de un bajo consumo, un formato compacto y conectividad de red que de una gran cantidad de núcleos de CPU.

Que la placa pueda ejecutar localmente un modelo específico depende del tamaño del modelo, la cuantización, la memoria, la aceleración y la latencia que requiera la experiencia. Por eso, la configuración de Zero Noichi con ZimaBoard 2 y AMD MI50 es una comparación útil: añadir capacidad de cómputo de GPU cambia la ruta de inferencia, mientras la placa puede seguir proporcionando el host estable y la capa de servicios. La regla de planificación más segura es separar la orquestación de la inferencia: diseña la aplicación de modo que el motor de estado siga siendo útil incluso si el punto de acceso al modelo cambia entre un servicio local, otra máquina o una API alojada.

El almacenamiento directo y la expansión también pueden admitir registros, versiones de indicaciones, audio en caché y repeticiones de partidas. Esos archivos no son el modelo en sí, pero son las pruebas necesarias para entender cómo se comportó el sistema. Un servidor pequeño que mantenga el proyecto reproducible puede ser más valioso que un dispositivo más rápido que solo produzca una demostración impresionante de una sola vez.

Lo que revela el resultado en directo sobre la IA multiagente

Lo atractivo del experimento es que los agentes parecen tener intenciones sociales: interrumpen, se defienden, sospechan unos de otros y se coordinan con información incompleta. Técnicamente, esos comportamientos surgen de la interacción entre las indicaciones de rol, el contexto privado, las transiciones de estado y el planificador. Ninguna respuesta individual del modelo explica toda la experiencia.

Esa distinción importa para cualquiera que esté creando una aplicación de IA local. Más agentes no significan automáticamente más inteligencia. Aumentan el costo de coordinación, la gestión del contexto, la superficie de fallos y los requisitos de observabilidad. Un grupo más pequeño con límites de estado bien definidos puede producir un resultado más convincente que uno más grande que olvida sus reglas.

El proyecto también muestra por qué la latencia es una decisión de producto. Una respuesta lenta pero reflexiva puede ser aceptable durante una deducción por turnos, mientras que el mismo retraso parece un fallo durante una breve confirmación o interrupción. Por ello, el planificador debe adaptar el esfuerzo del modelo y la duración de la voz a la importancia del evento, en lugar de tratar todos los mensajes de la misma manera.

Cómo recrear la idea sin copiar toda la producción

Empieza con tres agentes y una regla sencilla de roles ocultos. Crea el registro de eventos, la máquina de estados y la separación entre el contexto privado y el público antes de añadir voz. Cuando el ciclo basado solo en texto pueda reproducir una ronda completa sin filtrar información, añade un único proveedor de voz y mide en qué punto la interacción se percibe realmente lenta.

A continuación, haz explícita la configuración. Guarda los perfiles de los personajes, las reglas de los roles, las rutas de los modelos, las asignaciones de voz y las políticas de reintento fuera del texto del prompt. Esto convierte una demostración puntual en un sistema que se puede ajustar sin reescribir cada agente. También asigna al nodo de hardware una función clara: mantener juntos los servicios, la configuración y las evidencias, mientras el backend de inferencia sigue siendo reemplazable. Esta misma separación resulta útil en una construcción de un servidor de IA local más amplia, donde el entorno de ejecución y los servicios auxiliares pueden evolucionar a ritmos diferentes.

Por último, prueba los fallos en lugar de probar únicamente el caso ideal. Detén una solicitud al modelo, retrasa un clip de audio, elimina un jugador, reinicia el coordinador y reproduce el mismo registro de eventos. Una aplicación multiagente convincente no se define solo por su mejor conversación; se define por si el sistema puede recuperarse sin cambiar las reglas a mitad de la partida.

Para una plataforma compacta de servidor doméstico capaz de alojar la orquestación y los servicios auxiliares, explora ZimaBoard 2 - Mini servidor doméstico para tu gran idea. Para intercambiar ideas con otros creadores, únete a la comunidad de Discord de ZimaSpace.