Quatre agents Gemini 4 Argon vainquent le dragon de Minecraft en 27 heures d'autonomie

Une réalisation concrète, non une preuve d'autonomie générale

Quatre agents basés sur Gemini 4 Argon ont vaincu le Dragon de l'End dans une partie de survie de Minecraft, selon un préprint de chercheurs de Google DeepMind. L'exécution a duré 27 heures et 14 minutes. Pendant ce temps, les agents ont écrit 2 783 programmes et leurs personnages sont morts 605 fois avant d'atteindre l'objectif.

L'expérience se distingue par la combinaison de planification prolongée, de programmation itérative et de coordination entre agents pendant plus d'une journée. Cependant, son périmètre est spécifique : elle a été réalisée dans un monde Minecraft généré aléatoirement, en difficulté Facile et dans un environnement isolé. Une exécution réussie ne permet pas à elle seule de conclure que le système peut résoudre de manière fiable des tâches d'entreprise ou du monde réel.

Comment les agents se sont organisés

Chaque agent contrôlait un joueur via Mineflayer, une bibliothèque open source pour interagir avec Minecraft. Pour se coordonner, les agents ont utilisé le chat du jeu et une mémoire partagée. Le résumé de l'étude indique que personne ne leur a assigné de rôles ni écrit à l'avance la logique spécifique du jeu : ils ont planifié, programmé et débogué leurs propres programmes.

L'équipe a divisé les tâches et partagé ce qu'elle avait appris. Elle a également récupéré des objets perdus par des coéquipiers, un détail important dans une partie où mourir pouvait entraîner la perte de ressources nécessaires pour progresser. Cela permet de décrire une coordination opérationnelle observée pendant l'exécution, mais ne prouve pas que les agents aient développé une stratégie optimale ni que leur organisation soit apparue sans aucune infrastructure préparée : l'expérience comptait bien l'environnement, la bibliothèque et les mécanismes de communication établis par les chercheurs.

Programmer, échouer et réessayer

Les chiffres de 2 783 correspondent aux programmes écrits pendant la partie, et les 605 morts reflètent les échecs et les risques accumulés dans le jeu. Ces deux métriques montrent que le résultat n'a pas été une séquence propre d'instructions exécutée du premier coup. L'équipe a dû maintenir l'objectif général tout en produisant et en déboguant du code pour avancer par étapes interdépendantes.

La donnée de durée a également besoin de contexte. Les 27 heures et 14 minutes mesurent le temps de l'exécution rapportée, non nécessairement le temps de travail des chercheurs ni le coût total de la préparation de l'expérience. La source primaire fournie ne spécifie pas dans le matériel vérifié le nombre d'accélérateurs, la configuration matérielle ni un coût économique. Par conséquent, il n'est pas possible de calculer de manière responsable le coût computationnel à partir de ces données.

L'affirmation d'absence d'intervention humaine

Les chercheurs affirment qu'ils pouvaient observer la partie via un tableau de bord en temps réel et la mettre en pause ou l'arrêter, mais qu'ils n'avaient aucune raison d'intervenir. Cette description soutient l'affirmation selon laquelle les agents ont mené la partie sans intervention humaine pendant l'exécution rapportée, sous supervision disponible.

La formulation ne signifie pas que l'expérience était exempte d'intervention humaine à toutes ses étapes. Les humains ont choisi l'objectif, monté l'environnement isolé, configuré les agents et activé Mineflayer, le chat et la mémoire partagée. Aucune audit indépendant de l'exécution n'est fourni dans la documentation disponible ici. La conclusion la plus précise est que le papier déclare une exécution sans intervention active, dans une configuration créée et supervisée par des chercheurs.

Ce que cela apporte à la recherche sur les agents collaboratifs

L'intérêt technique réside dans la durée et la dépendance entre les étapes : les agents devaient conserver un plan utile, le convertir en actions et en code, partager des informations et se remettre des contretemps. Minecraft offre un environnement interactif où ces capacités peuvent être observées avec un objectif final clair. L'expérience fonctionne comme une démonstration d'intégration de plusieurs compétences, non comme une évaluation large des performances.

Les auteurs relient ce type de défi à des tâches complexes d'ingénierie logicielle et de travail d'entreprise, car elles peuvent également exiger une planification prolongée et une coordination. Cette connexion est une hypothèse de pertinence, non une validation que le résultat se transfère directement. Les environnements réels ont des exigences, des risques, des données et des critères de succès différents ; des évaluations spécifiques seraient nécessaires pour savoir si les agents généralisent et avec quelle fiabilité.

Limites et questions ouvertes

Le document cité est la version 1 d'un préprint publié sur arXiv le 15 octobre 2026. C'est un travail de recherche de ses auteurs, mais les informations fournies n'attestent pas qu'il a été évalué par des pairs ni reproduit de manière indépendante. L'affirmation selon laquelle il s'agirait de la première complétion autonome de bout en bout est présentée comme une revendication des auteurs eux-mêmes — « à notre connaissance » — et doit conserver cette portée.

Pour mesurer la fiabilité, il faudrait plusieurs exécutions et des conditions comparables : par exemple, des mondes différents, des niveaux de difficulté variés et des registres d'échecs et de complétion. Il serait également utile de connaître le coût des modèles et des ressources de calcul, le comportement de chaque agent et l'effet de la mémoire partagée. Sans ces données, il n'est pas possible d'établir un taux de succès ni de répondre à la question du coût de l'essai.

Poursuivre l’exploration

Corrections et transparence

Si vous repérez une information incorrecte ou obsolète, envoyez-nous la page et la source à vérifier.