Como a Zero Noichi criou um jogo de lobisomem com dez agentes de IA

野市 零 / Zero Noichi mostra o que acontece quando dez agentes de IA partilham um único jogo de lobisomens: o desafio já não é gerar uma resposta inteligente, mas coordenar vozes, papéis, memória, ritmo e conflito sem fazer a conversa parecer mecânica.

Este artigo agradece a 野市 零 / Zero Noichi por documentar a experiência no vídeo original sobre lobisomens de IA. O vídeo é apresentado como uma experiência de entretenimento, mas também expõe os problemas de engenharia por trás de uma aplicação multiagente convincente: como fazer com que os agentes esperem, interrompam, se lembrem, enganem e reajam enquanto membros de um único mundo partilhado.

Declaração de colaboração: A descrição original faz referência à ZimaBoard 2, a um cupão para criadores, a ligações de afiliados e aos serviços de software utilizados na experiência. O criador partilha a sua própria implementação e utilização prevista. As versões dos modelos, os serviços de voz, as interfaces, os pacotes de hardware e a compatibilidade podem mudar após a publicação.

O resultado: Um ZimaBoard 2 - Mini Home Server não substitui um grande cluster de inferência a executar dez modelos de ponta à velocidade máxima. A sua capacidade mais realista é funcionar como um nó compacto de controlo e serviços, sempre ativo, para uma aplicação de IA: coordenando prompts, o estado do jogo, APIs, pipelines de áudio, registos e acesso à rede, enquanto o processamento mais pesado dos modelos é atribuído ao serviço ou caminho computacional mais adequado.

A forma útil de interpretar este projeto é como um sistema por camadas. O modelo de linguagem fornece decisões e diálogo, mas uma camada de orquestração decide de quem é a vez, uma camada de estado determina o que cada personagem sabe, uma camada de voz transforma texto em fala e uma camada de apresentação torna o resultado compreensível para quem vê. Retire qualquer uma dessas camadas e dez agentes «inteligentes» rapidamente se transformam em dez janelas de chat desligadas.

A parte difícil é a realidade partilhada, não o número de agentes

Adicionar um segundo modelo a uma conversa é fácil em comparação com adicionar um segundo modelo que tenha de obedecer às mesmas regras. Num jogo de lobisomens, cada personagem precisa de uma função privada, um histórico público, uma convicção sobre os outros jogadores e um conjunto legal de ações para a fase atual. A aplicação precisa, por isso, de um único estado de jogo autoritativo, em vez de permitir que cada modelo invente a sua própria versão dos acontecimentos.

Um design robusto separa o estado público do privado. O estado público pode incluir o dia atual, as afirmações proferidas, os votos e os jogadores eliminados. O estado privado pode incluir os companheiros de um lobisomem, o resultado de uma vidente ou a suspeita oculta de uma personagem. O orquestrador cria então um contexto diferente para cada agente, em vez de transmitir todos os segredos a toda a gente.

Esta separação também torna possível a depuração. Se um agente fizer uma acusação suspeita, o programador pode inspecionar a transcrição pública exata, a memória privada, o prompt da função e a resposta do modelo que a produziram. Sem esses limites, a aparente “inteligência” pode ser simplesmente uma fuga acidental de informação de um prompt para outro.

Os prompts de personagens precisam de mais do que um adjetivo de personalidade

Chamar a um agente “confiante” e a outro “calado” não é suficiente para criar um elenco. Uma definição de personagem útil combina um estilo de fala, uma tolerância ao risco, um objetivo, um limite de conhecimento específico da função e uma regra para determinar como as provas alteram as convicções. A personagem deve soar diferente, mas também deve tomar decisões por uma razão que se mantenha consistente ao longo dos turnos.

Cada agente beneficia de um perfil estruturado: nome, função, persona pública, objetivo privado, factos conhecidos, suspeitas atuais e uma memória compacta de acontecimentos anteriores. O prompt pode então pedir tanto uma decisão interna como uma fala dirigida aos espectadores, enquanto a aplicação guarda apenas os campos necessários para a transição seguinte. Assim, o contexto mantém-se legível à medida que o jogo cresce.

Existe aqui um limite importante. Um prompt mais longo não produz automaticamente uma personagem mais profunda. Se cada turno repetir toda a transcrição e todas as instruções, a latência e o custo aumentam, enquanto o modelo continua sem uma transição de estado clara. Uma memória mais pequena e selecionada cria frequentemente um comportamento mais consistente do que uma cópia integral e não filtrada da conversa.

A seleção do modelo muda o ritmo do jogo

O vídeo destaca a escolha de modelos LLM como parte da experiência, em vez de tratar a «IA» como um componente intercambiável. O Moonshot Kimi K3 é mencionado no projeto como o componente de modelo de linguagem, e essa escolha afeta não só a qualidade das respostas, mas também o comprimento das respostas, a latência, o comportamento perante recusas, o estilo linguístico e a quantidade de contexto que pode ser mantida entre turnos.

Uma arquitetura prática pode atribuir tarefas diferentes a modelos diferentes. Um modelo mais potente pode tratar de uma dedução privada difícil, enquanto um modelo mais rápido produz reações sociais curtas ou narração. A regra importante é manter o contrato do jogo fora do modelo. O modelo pode propor uma ação, mas o servidor deve validar se essa ação é legal antes de a aplicar ao estado.

As APIs de modelos remotos também alteram os limites de privacidade e fiabilidade. Se o jogo enviar informações privadas sobre os papéis para um serviço externo, esse serviço passa a fazer parte do modelo de confiança. Falhas de rede, limites de utilização e alterações à API podem interromper o jogo mesmo quando o dispositivo local está a funcionar corretamente. Colocar pedidos em cache, repetir pedidos idempotentes e registar IDs de pedido torna a experiência mais fácil de retomar e explicar.

Uma conversa natural requer um motor de gestão de turnos

Dez agentes a falar numa fila fixa soariam como uma chamada de conferência controlada por uma folha de cálculo. O comportamento mais convincente resulta de um motor explícito de gestão de turnos, que sabe quando uma personagem pode falar, quando é permitida uma interrupção e quando a mesa tem de avançar para uma votação ou ação noturna.

Um padrão útil é uma máquina de estados com fases como introdução, discussão aberta, resposta direcionada, votação, ações noturnas e resultados. Durante uma fase de discussão, o agendador pode escolher o próximo orador com base numa combinação de justiça, relevância, suspeita e aleatoriedade controlada. Uma personagem pode pedir uma interrupção, mas o motor decide se o pedido é válido e de que forma afeta a fila.

É por isso que a «voz realista» é mais do que conversão de texto em voz. O sistema tem de decidir quando começa o áudio, se a fala atual pode ser interrompida, como é colocada uma resposta em fila e o que acontece se um pedido de voz falhar. Uma separação clara entre as decisões de texto e a reprodução de áudio permite que o jogo continue mesmo quando um fornecedor de voz está lento.

A voz acrescenta pistas sociais — e novos modos de falha

O diálogo falado altera a forma como os espectadores avaliam os agentes. Pausas, confirmações, interrupções e diferenças na identidade vocal fazem com que uma resposta curta pareça parte de uma mesa ao vivo. O vídeo utiliza o Fish Audio para a camada de voz, que desempenha uma função estrutural: transforma transições de estado em eventos que uma pessoa consegue acompanhar em tempo real.

O áudio também pode revelar erros que o texto oculta. Um pedido de síntese atrasado pode fazer com que uma personagem fale depois de o jogo já ter avançado para outra fase. Uma resposta longa gerada pode bloquear a fila e fazer desaparecer agentes mais silenciosos. Por isso, a aplicação deve associar cada clipe de áudio a um evento e a uma fase do jogo, para que os clipes desatualizados possam ser descartados em vez de serem reproduzidos fora de contexto.

A identidade vocal também precisa de uma política de consistência. Se a voz de uma personagem mudar entre turnos, os espectadores podem interpretar uma falha técnica como uma nova personagem. Manter a atribuição de vozes na configuração, em vez de a colocar no prompt do modelo, torna a camada de apresentação previsível e mais fácil de substituir.

O ciclo de jogo precisa de uma fonte de verdade do lado do servidor

Durante o jogo ao vivo, o sistema tem de coordenar mais do que mensagens de chat. Precisa de saber quem está vivo, que fase está ativa, que ações continuam a ser legais, o que cada personagem ouviu e quando um resultado se torna oficial. Esses factos pertencem à camada da aplicação, não à resposta livre de um agente.

Um bom registo de eventos pode incluir a fase, o orador, o texto visível, a ação privada, o modelo utilizado, o estado do pedido e a versão do estado resultante. Essa estrutura permite a reprodução: o programador pode voltar a executar a apresentação a partir dos mesmos eventos sem pedir a cada modelo que regenere o jogo inteiro. Também facilita a comparação entre duas configurações de modelos no mesmo cenário.

A reprodução é especialmente valiosa para um projeto que parece espontâneo. Se uma personagem vence devido a uma dedução convincente, o programador pode perguntar se o resultado veio do design do papel, de uma resposta feliz do modelo, de um segredo revelado ou de uma particularidade do agendamento. A observabilidade transforma uma demonstração divertida num sistema que pode realmente ser melhorado.

Onde se enquadra o ZimaBoard 2 na arquitetura

A ZimaBoard 2 faz mais sentido na extremidade sempre ligada deste sistema. Esse posicionamento é consistente com a configuração de assistente de IA local com a ZimaBoard 2: a placa pode alojar o coordenador, uma pequena base de dados, painéis, serviços de webhook, filas de áudio ou componentes de suporte em contentores, ligando-os de forma fiável a APIs externas de modelos e voz. Essa função beneficia mais de um baixo consumo de energia, de uma estrutura compacta e de conectividade de rede do que de um grande número de núcleos de CPU.

A possibilidade de a placa executar localmente um modelo específico depende do tamanho do modelo, da quantização, da memória, da aceleração e da latência exigida pela experiência. É por isso que a configuração da Zero Noichi com a ZimaBoard 2 e a AMD MI50 é uma comparação útil: a capacidade de computação adicional da GPU altera o percurso de inferência, enquanto a placa pode continuar a fornecer a camada estável de anfitrião e serviços. A regra segura de planeamento é separar a orquestração da inferência: conceba a aplicação de modo a que o motor de estado continue a ser útil mesmo que o endpoint do modelo passe de um serviço local para outra máquina ou para uma API alojada.

O armazenamento direto e a expansão também podem suportar registos, versões de instruções, áudio em cache e replays de jogos. Esses ficheiros não são o próprio modelo, mas são as provas necessárias para compreender como o sistema se comportou. Um pequeno servidor que mantenha o projeto reproduzível pode ser mais valioso do que um dispositivo mais rápido que apenas produza uma demonstração impressionante uma única vez.

O que o resultado em direto revela sobre a IA multiagente

O interesse do experimento está no facto de os agentes parecerem ter uma intenção social: interrompem, defendem-se, suspeitam uns dos outros e coordenam-se com base em informação incompleta. Tecnicamente, estes comportamentos emergem da interação entre as instruções de função, o contexto privado, as transições de estado e o agendador. Nenhuma resposta individual do modelo explica toda a experiência.

Essa distinção é importante para quem está a criar uma aplicação de IA local. Mais agentes não significam automaticamente mais inteligência. Aumentam o custo de coordenação, a gestão do contexto, a superfície de falhas e os requisitos de observabilidade. Um grupo mais pequeno, com limites de estado bem definidos, pode produzir um resultado mais convincente do que um grupo maior que se esquece das suas regras.

O projeto também mostra por que razão a latência é uma decisão de produto. Uma resposta lenta mas ponderada pode ser aceitável durante uma dedução por turnos, enquanto o mesmo atraso parece um erro durante um breve reconhecimento ou uma interrupção. O programador deve, por isso, ajustar o esforço do modelo e a duração da voz à importância do evento, em vez de tratar todas as mensagens da mesma forma.

Como recriar a ideia sem copiar toda a produção

Comece com três agentes e uma regra simples de papéis ocultos. Crie o registo de eventos, a máquina de estados e a separação entre contexto privado e público antes de adicionar voz. Quando o ciclo apenas com texto conseguir reproduzir uma ronda completa sem divulgar informações, adicione um único fornecedor de voz e avalie onde a interação parece realmente lenta.

Em seguida, torne a configuração explícita. Armazene os perfis das personagens, as regras dos papéis, as rotas dos modelos, as atribuições de voz e as políticas de repetição fora do texto do prompt. Isto transforma uma demonstração única num sistema que pode ser ajustado sem reescrever cada agente. Também dá ao nó de hardware uma função clara: manter os serviços, a configuração e as provas em conjunto, enquanto o back-end de inferência continua a poder ser substituído. A mesma separação é útil numa configuração de servidor de IA local mais abrangente, na qual o runtime e os serviços de suporte podem evoluir a ritmos diferentes.

Por fim, teste as falhas em vez de testar apenas o caminho ideal. Interrompa um pedido ao modelo, atrase um clipe de áudio, remova um leitor, reinicie o coordenador e reproduza novamente o mesmo registo de eventos. Uma aplicação multiagente convincente não se define apenas pela sua melhor conversa; define-se pela capacidade de o sistema recuperar sem alterar as regras a meio do jogo.

Para uma plataforma compacta de servidor doméstico capaz de alojar a orquestração e os serviços de suporte, explore o ZimaBoard 2 - Mini servidor doméstico para a sua grande ideia. Para trocar ideias com outros criadores, junte-se à comunidade ZimaSpace no Discord.