HiSTEVE 1.0 joga Minecraft com mouse e teclado: 85,0% no MineStudio Bench

Pesquisadores que publicam sob a marca Tencent no Hugging Face apresentaram o HiSTEVE 1.0, um agente que cumpre tarefas longas no Minecraft como faria um jogador de verdade: olha para a tela, aperta teclas e move o mouse. No MineStudio Bench, o sistema marcou 85,0%, e no OpenHA mostrou 37,4% de sucesso médio. Além das tarefas atômicas, o agente executa sozinho cadeias longas, como fabricar uma picareta de ferro do zero. O trabalho saiu em 22 de outubro de 2026 (arXiv 2610.31162) e chegou direto ao segundo lugar no ranking diário do Hugging Face Daily Papers.

A lacuna que os autores querem fechar

Até agora, os agentes para Minecraft se dividiam em dois grupos. Um deles domina o controle visuomotor nativo, ou seja, trabalha com pixels e botões reais, mas não sustenta tarefas longas sem intervenção. O outro planeja bem em alto nível, mas executa o plano por meio de uma API do ambiente ou de um conjunto de habilidades predefinidas, e na prática usa privilégios "de trapaça", como acesso ao estado interno do jogo. O HiSTEVE tenta juntar as duas metades: planejamento autônomo e execução pela mesma interface que o humano usa.

A arquitetura tem dois níveis. No topo fica o chamado capability-aware agent harness, um orquestrador que sabe do que o modelo de baixo é capaz. Embaixo, uma única política VLA executa todas as subtarefas, apoiada apenas na visão.

Um orquestrador que conhece os limites do executor

O orquestrador tem três nós de trabalho. Uma memória estruturada acompanha o progresso da tarefa. O planejador VLM escolhe as subtarefas limitando-se às capacidades do VLA: ele não pede à política algo que ela não sabe fazer. O terceiro nó é o detector de conclusão de subtarefas acoplado ao contexto da política (policy-coupled task completion detector). Ele sinaliza uma possível conclusão, e com base nesse sinal o agente decide se segue adiante, se se recupera de uma falha ou se replaneja. A descrição também menciona a recuperação de execução baseada em evidências (evidence-driven execution recovery).

Um único VLA para gameplay e menus

O principal problema de engenharia do nível inferior é que o jogo em primeira pessoa e o trabalho com a GUI (inventário, crafting) são modos de interação distintos, e eles interferem um no outro dentro de um mesmo modelo. Os autores os separaram com duas soluções: ramos RMSNorm distintos para cada modo e embeddings de tokens separados para os movimentos do mouse.

O treinamento ocorre em três estágios: injeção de conhecimento de mundo (world knowledge injection), aprendizado por imitação e aprendizado por reforço com feedback do ambiente. Segundo os autores, o último estágio aumenta a confiabilidade e a capacidade de se recuperar de erros.

Composição do sistema e métricas

• Tipo de agente: Vision-Language-Action hierárquico, apenas percepção visual, ações nativas de teclado e mouse • Orquestração: memória estruturada, planejador VLM que considera as capacidades do VLA, detector de conclusão de subtarefas acoplado ao contexto da política • Controle: uma única política VLA para todas as subtarefas, incluindo a GUI • Mudanças de arquitetura: ramos RMSNorm específicos para cada modo, embeddings separados para os tokens de movimento do mouse • Treinamento: world knowledge injection, aprendizado por imitação, RL com feedback do ambiente • MineStudio Bench: 85,0%, com state-of-the-art declarado para tarefas atômicas • OpenHA: 37,4% de sucesso médio • Tarefa longa: picareta de ferro do zero • Autores: Zecong Tang, Zian Guan, Yuncheng Guo, Zhanqiu Zhang, Yiwen Guo, Bo Dai

Onde isso pode ser útil

O privilégio mínimo do ambiente importa além do Minecraft. Um agente que precisa apenas da tela e da entrada padrão pode ser transferido para qualquer jogo ou aplicativo desktop sem integração com uma API interna. É a mesma lógica dos agentes de computer use, só que em um campo de testes mais duro, com geração procedural de mundo e horizonte longo.

Há duas lições úteis para quem desenvolve agentes. O planejador deve ficar atrelado ao conjunto real de habilidades do executor, e não a um modelo abstrato "todo-poderoso". Já modos de entrada heterogêneos, como menu e cena, é melhor separar no nível de normalização e de embeddings do que esperar que uma política única e geral dê conta sozinha. Os números 85,0% e 37,4% valem, por ora, apenas para benchmarks específicos, e ainda precisam ser verificados por reprodução independente.