
HexaShell : un cadre minimaliste pour explorer les limites des agents VLM comme agents de programmation de robots
HexaShell, un système décrit dans un preprint arXiv (2610.23479) par l'équipe HexaFuture, confie le pilotage d'un robot bimanuel à un agent de code basé sur un modèle vision-langage (VLM), via une unique ligne de commande. Le « harnais » reste volontairement mince : il se limite à convertir les commandes de l'agent en mouvements. L'agent dispose de trois caméras RGB calibrées, lit les journaux après chaque échec, identifie la cause et écrit ou corrige de petits programmes, les « outils », qui conservent l'apprentissage sous forme de code. Ces outils n'exploitent que les observations du robot : triangulation entre deux caméras, ou intersection d'un rayon avec un plan connu (table, dessus d'un cube), et déplacement d'une caméra poignet pour obtenir une seconde vue si la caméra de tête ne suffit pas. Les outils sont construits sur dix configurations d'une seule graine par tâche, puis gelés et testés sur dix nouvelles configurations. Avec Codex et GPT-6-Astra à effort de raisonnement moyen, HexaShell atteint 39,7 % de succès et un score de progression de 48,0 sur les 42 tâches de RoboDojo, moyennés comme le classement officiel, ce que les auteurs présentent comme un nouvel état de l'art. Les outils sont publiés en open source sur GitHub.
Le résultat est surtout instructif par sa répartition. Les tâches de poussée atteignent 92,5 % et celles qui demandent de la mémoire 65,0 %, mais l'insertion serrée plafonne à 8,3 %. Le goulot n'est donc pas le raisonnement : l'agent voit généralement son échec mais ne parvient pas à produire le mouvement de contact qui le corrige. Pour les intégrateurs, cela suggère que la perception géométrique et la planification de haut niveau peuvent être largement déléguées à un agent de code, tandis que la manipulation riche en contact reste le domaine où les politiques apprises ou le contrôle en force gardent l'avantage. Cela contredit aussi l'idée qu'un VLA entraîné de bout en bout serait indispensable pour battre les classements de manipulation. Plusieurs réserves s'imposent toutefois : un taux de succès inférieur à 40 % reste loin d'un usage industriel, le test porte sur une seule graine par tâche, la validation se fait en simulation, et le choix d'un modèle propriétaire limite la reproductibilité.
Ce travail s'inscrit dans une tendance récente : des agents fondés sur des VLM rivalisent désormais avec des politiques apprises sur les classements de manipulation, en s'appuyant sur le code comme mémoire explicite plutôt que sur des poids réseau. Il se positionne face aux approches de type VLA (Pi-0, GR00T, Helix), qui apprennent le contrôle directement à partir de démonstrations, et face aux pipelines modulaires classiques de vision et de planification. Les auteurs ne font état d'aucun test sur robot réel ni d'une feuille de route de déploiement. La suite logique serait d'améliorer les outils de contact, par exemple avec un retour d'effort, et de vérifier que les outils gelés se transfèrent à d'autres graines, d'autres robots et au monde physique.
Dans nos dossiers




