HiSTEVE 1.0 juega a Minecraft con ratón y teclado: 85,0% en MineStudio Bench

Investigadores que publican bajo la marca Tencent en Hugging Face han presentado HiSTEVE 1.0, un agente que completa tareas largas en Minecraft como lo haría un jugador humano: mira la pantalla, pulsa teclas y mueve el ratón. En MineStudio Bench el sistema obtuvo un 85,0%, y en OpenHA mostró un 37,4% de éxito medio. Además de las tareas atómicas, el agente ejecuta por sí solo cadenas largas, como fabricar un pico de hierro desde cero. El trabajo se publicó el 22 de octubre de 2026 (arXiv 2610.31162) y entró directamente en el segundo puesto del ranking diario de Hugging Face Daily Papers.

La brecha que quieren cerrar los autores

Hasta ahora, los agentes para Minecraft se dividían en dos bandos. Unos dominan el control visomotor nativo, es decir, trabajan con píxeles y botones reales, pero no sostienen tareas largas sin intervención. Otros planifican bien a alto nivel, pero ejecutan el plan mediante la API del entorno o un conjunto de habilidades predefinidas, y en la práctica disfrutan de privilegios «tramposos», como el acceso al estado interno del juego. HiSTEVE intenta unir ambas mitades: planificación autónoma y ejecución a través de la misma interfaz que usa una persona.

La arquitectura tiene dos niveles. Arriba está el llamado capability-aware agent harness, un orquestador que conoce de qué es capaz el modelo inferior. Abajo trabaja una única política VLA que ejecuta todas las subtareas apoyándose solo en la visión.

Un orquestador que conoce los límites del ejecutor

El orquestador tiene tres nodos de trabajo. Una memoria estructurada registra el progreso de la tarea. Un planificador VLM elige las subtareas y se limita a las capacidades del VLA: no le pide a la política nada que esta no sepa hacer. El tercer nodo es un detector de finalización de subtareas vinculado al contexto de la política (policy-coupled task completion detector). Emite una señal de posible finalización, y a partir de ella el agente decide si avanzar, recuperarse de un fallo o replanificar. La descripción menciona además la recuperación de la ejecución basada en evidencias (evidence-driven execution recovery).

Un solo VLA para el juego y los menús

El principal problema de ingeniería del nivel inferior es que el juego en primera persona y el trabajo con la GUI (inventario, fabricación) son modos de interacción distintos que se interfieren entre sí dentro de un mismo modelo. Los autores los separan con dos recursos: ramas RMSNorm independientes para cada modo y embeddings de tokens separados para los movimientos del ratón.

El entrenamiento consta de tres etapas: inyección de conocimiento del mundo (world knowledge injection), aprendizaje por imitación y aprendizaje por refuerzo con la retroalimentación del entorno. Según los autores, esta última etapa mejora la fiabilidad y la capacidad de recuperarse de los errores.

Composición del sistema y métricas

• Tipo de agente: Vision-Language-Action jerárquico, con percepción exclusivamente visual y acciones nativas de teclado y ratón • Orquestación: memoria estructurada, planificador VLM que tiene en cuenta las capacidades del VLA y detector de finalización de subtareas vinculado al contexto de la política • Control: una sola política VLA para todas las subtareas, incluida la GUI • Cambios de arquitectura: ramas RMSNorm específicas para cada modo y embeddings independientes para los tokens de movimiento del ratón • Entrenamiento: world knowledge injection, aprendizaje por imitación, RL con retroalimentación del entorno • MineStudio Bench: 85,0%, con state-of-the-art declarado en tareas atómicas • OpenHA: 37,4% de éxito medio • Tarea larga: pico de hierro desde cero • Autores: Zecong Tang, Zian Guan, Yuncheng Guo, Zhanqiu Zhang, Yiwen Guo, Bo Dai

Dónde puede resultar útil

El privilegio mínimo del entorno importa más allá de Minecraft. Un agente que solo necesita la pantalla y la entrada estándar se puede trasladar a cualquier juego o aplicación de escritorio sin integrarse con una API interna. Es la misma lógica que hay detrás de los agentes computer-use, pero en un terreno de pruebas más exigente, con generación procedural del mundo y un horizonte largo.

Hay dos conclusiones útiles para quienes desarrollan agentes. La primera: conviene vincular el planificador al conjunto real de habilidades del ejecutor, y no a un modelo abstracto «omnipotente». La segunda: es mejor separar los modos de entrada heterogéneos, como el menú y la escena, a nivel de normalización y de embeddings que confiar en que una única política común se las arregle sola. Las cifras de 85,0% y 37,4% corresponden por ahora a benchmarks concretos, y queda pendiente verificarlas mediante reproducción independiente.