Zerar Minecraft parece brincadeira, mas quando quatro agentes com Gemini 4 Argon conseguem fazer isso sem ajuda humana, o recado é sério. Não foi speedrun com roteiro pronto nem demo controlada. Foi um mundo aleatório, 27 horas de caos, 605 mortes e um Ender Dragon morto no final. Se você constrói agentes hoje, esse teste importa mais do que parece, porque ele expõe onde a autonomia colaborativa realmente está.

O fato

O time do Google DeepMind colocou quatro agentes rodando Gemini 4 Argon em um mundo gerado de forma aleatória, sem definir papéis, sem entregar estratégia pronta e sem ferramenta específica para o jogo. Ninguém disse quem minera, quem explora ou quem ataca. Os agentes precisaram descobrir isso jogando, errando e conversando entre si pelo chat interno.

PublicidadeAnuncie aqui336x280 / responsivo

Em 27 horas e 14 minutos de execução contínua, eles completaram o jogo e derrotaram o Ender Dragon. Nesse período, os quatro agentes escreveram juntos 2.783 programas em JavaScript, trocaram 229 mensagens de coordenação e morreram 605 vezes. O custo total da sessão foi calculado em 1.620 dólares, considerando o preço padrão do Gemini 4 Argon que passa a valer em 2027.

Como funciona na visão de operador

Pelo comportamento descrito, o esquema é o clássico código como ação. O modelo não aperta teclas como um humano, ele gera programas em JavaScript que executam tarefas no jogo, como andar até uma coordenada, minerar um bloco, craftar um item ou atacar um inimigo. Cada programa é uma tentativa pequena, observada pelo próprio agente, corrigida e reenviada. É um loop de planejar, executar, observar o erro e tentar de novo, repetido milhares de vezes.

A parte mais interessante é a camada de coordenação. Os agentes usaram o chat como um barramento simples de comunicação, avisando sobre ameaças, pedindo ajuda e dividindo tarefas de forma emergente. Quando um agente morria, outro ia recuperar os itens. Quando uma estratégia falhava, o erro era registrado em uma memória compartilhada para ninguém repetir o mesmo vacilo. Na prática, isso é uma memória externa acessível por todos, provavelmente com resumo e busca, funcionando como um caderno coletivo.

Dá para inferir bastante sobre custo e latência mesmo sem os números oficiais de infraestrutura. Cada ação relevante parece exigir uma ou mais chamadas ao modelo, mais o processamento do estado do jogo. Em 27 horas, isso significa milhares de inferências longas, com contexto crescendo por causa do histórico e da memória. Funciona, mas é lento e caro. É o padrão atual de agentes: raciocínio forte, atuação fraca, e um custo por passo que ainda assusta em tarefas longas.

Por que Minecraft é um benchmark brutal

Minecraft não é só andar e bater. Para zerar, é preciso encadear dezenas de dependências em ordem: madeira, pedra, ferro, diamante, portal do Nether, blaze rods, ender pearls, portal do End e a luta final. É planejamento de longo prazo com recursos escassos, mapa desconhecido e morte permanente de inventário. Um erro lá atrás quebra tudo lá na frente. Por isso esse jogo virou teste de fogo para agentes, ele pune memória ruim e falta de coordenação muito rápido.

O que isso muda na prática

Para quem constrói produto com agentes, o recado não é sobre games. É sobre colaboração sem orquestrador central. Até pouco tempo, multiagente significava definir função fixa para cada agente, com prompts amarrados e fluxo controlado. Aqui a divisão de trabalho emergiu da interação. Um explorava, outro minerava, outro dava suporte. Isso sugere que modelos atuais já conseguem negociar tarefas simples se tiverem canal de comunicação e memória comum.

  • Quem ganha: times que operam agentes em tarefas longas e paralelizáveis, como pesquisa, engenharia de dados e operações com muitas etapas.
  • Quem perde: quem apostava que autonomia se resolve só com prompt melhor. O diferencial aqui foi memória compartilhada e log de erros, não só raciocínio.
  • O que ajustar agora: revisite sua camada de estado. Sem memória persistente e observável, multiagente vira quatro solistas perdidos.

A ação prática mais direta é copiar o caderno de erros. Crie uma memória compartilhada onde cada agente registra o que tentou, o que falhou e o que funcionou, com contexto suficiente para outro agente reaproveitar. Em testes internos, esse padrão simples reduz repetição de erro e melhora divisão de tarefa mais do que aumentar o tamanho do prompt. Comece pequeno, com um arquivo estruturado ou tabela, e meça quantas falhas se repetem antes e depois.

O custo real por trás da demo

Aqui entra a tensão que importa. Gastar 1.620 dólares e morrer 605 vezes para zerar um jogo é aceitável em pesquisa, mas seria inviável em produção. Nenhum cliente paga essa conta para automatizar uma rotina que um humano faz em uma tarde. E nenhuma operação crítica tolera 605 falhas para um acerto. O feito prova capacidade, não eficiência. Escalar isso para e commerce, suporte ou código real exige cortar custo por tarefa em pelo menos uma ordem de magnitude.

Tem outro ponto incômodo. O sistema resolveu o planejamento, mas moveu o gargalo para outro lugar: avaliação e recuperação. Os agentes só progrediram porque podiam errar barato e tentar de novo. No mundo real, errar custa dinheiro, reputação ou segurança. Sem um ambiente simulado e sem rollback confiável, essa mesma arquitetura trava. Então a pergunta não é se o modelo é inteligente, e sim se temos sandbox, observabilidade e limites de ação bons o suficiente para deixar ele errar 600 vezes sem quebrar nada.

Conclusão

Quatro agentes zeraram Minecraft sem ajuda porque combinaram código como ação, chat para coordenar e memória coletiva para não repetir erro. É um marco real de autonomia colaborativa, mas ainda caro e lento. Será que seu caso de uso aguenta esse custo de tentativa e erro até o acerto final?