SafeHarness : des agents de code qui évitent les obstacles

Ce que rapporte l'article

Un nouvel article arXiv (arXiv:2609.20822, catégorie cs.RO, soumis le 17 septembre 2026) de Bingxin Xu (USC), Yuzhang Shang (UCF), Zhen Dong (UCSB) et Emilio Ferrara (USC) pose une question que, selon les auteurs, les travaux précédents ont laissée ouverte. Dans l'approche des « agents de code » pour la manipulation robotique, un modèle de langage écrit le contrôleur du robot sous forme de programme. Ces agents pilotent désormais des robots sans entraînement propre à la robotique. Mais cette approche est-elle sûre ?

Pour le savoir, les auteurs évaluent un agent de code sous contrainte de sécurité. Chaque tâche associe un objectif de manipulation à un obstacle que le robot ne doit pas toucher. L'agent poursuit son objectif et, dans la plupart des cas, heurte l'obstacle. L'article présente alors SafeHarness, qui ajoute deux « harnais sensibles aux obstacles » autour de l'agent. Avec GPT-6 comme modèle de base, SafeHarness atteint 71,9 % de réussite des tâches et 87,5 % d'évitement des collisions sur le banc d'essai SafeLIBERO. Selon l'article, c'est 6,5 % et 27,0 % de mieux que l'état de l'art précédent, et 2,3 fois et 1,5 fois mieux que le même agent sans harnais.

Contexte : pourquoi la sécurité n'était pas mesurée

L'article résume la lignée de travaux dont il part. Code as Policies a fixé le schéma : le modèle assemble des API de perception et de commande en un programme, et ce programme est la politique. Des agents ultérieurs réécrivent leur code de contrôle après un échec, conservent une bibliothèque de compétences qui ont fonctionné et dépensent du calcul supplémentaire à l'inférence pour gagner en fiabilité. Harness VLA laisse l'agent explorer une scène, stocker ce qui a marché dans une mémoire de compétences et n'appeler une politique vision-langage-action (VLA) figée que lorsque la tâche devient riche en contacts.

Les auteurs soutiennent que ces travaux notent un essai selon que l'objectif est atteint ou non. Ce que le robot a touché en chemin n'est jamais mesuré. Ils citent aussi des études antérieures pour appuyer l'idée que le succès n'implique pas la sécurité : d'une génération de modèles à l'autre, les deux peuvent évoluer en sens opposé, et entraîner une politique avec dix fois plus de démonstrations sans collision ne réduit son taux de collision que de moins de trois points. Dans leurs mots, terminer la tâche et ne rien toucher d'autre sont les deux moitiés d'une même exigence.

Le diagnostic : la contrainte ne devient jamais une priorité

Les auteurs évaluent d'abord un agent de code sur un banc d'essai de sécurité robotique. Il réussit des tâches mais heurte l'obstacle dans la plupart des cas. Ils écartent deux explications faciles. La perception n'est pas en cause, car l'agent identifie correctement l'obstacle et le mentionne dans son raisonnement. L'instruction non plus, car le prompt interdit déjà de le toucher. L'agent répète la contrainte, puis la viole.

L'article situe la faute dans la planification et découpe chaque phase de manipulation en deux parties. Sur le trajet à travers l'espace libre, le modèle n'a aucune notion d'un chemin qui dégage l'obstacle, donc il prend le plus court. Il n'a pas non plus la notion de replanifier quand le trajet choisi devient irréalisable. Au contact, moment riche en interactions qui clôt la phase, le modèle ne reconnaît pas que le contact lui-même est soumis à la même contrainte. Un planificateur plus puissant ne comble pas l'écart, d'après l'ablation de la section 4.3.

La section 3.4 propose une explication. Un épisode est une seule longue conversation de centaines d'étapes. Chaque appel d'outil et chaque image s'ajoutent au contexte, qui atteint des dizaines de milliers de jetons, alors que la phrase qui nomme l'obstacle reste près du début. Les auteurs renvoient à des travaux montrant que le rappel du contenu situé au milieu, le respect des consignes et la fidélité au prompt système se dégradent quand le contexte s'allonge. Dans leurs essais, la contrainte apparaît dans les premières étapes de raisonnement, puis disparaît.

Fonctionnement de SafeHarness

SafeHarness découpe une tâche en phases aux événements de contact. Chaque harnais s'exécute une fois par phase.

La planification de trajet sensible aux obstacles suit un cycle planifier, vérifier, exécuter. Un modèle de segmentation (SAM-3) localise la cible et l'obstacle sous forme de boîtes englobantes. Le modèle de langage propose un trajet sous forme de ligne brisée de points de passage, qui doit finir à la cible et ne pas traverser la boîte de l'obstacle. Une vérification extérieure au modèle de langage teste ensuite le trajet contre la boîte. Elle couvre la pince et, si un objet est tenu, l'objet aussi. Un trajet qui pénètre dans la boîte est rejeté et le modèle replanifie. La replanification se déclenche aussi pendant l'exécution : si le bras s'arrête, par exemple coincé, un nouveau trajet est planifié depuis le point d'arrêt. Le harnais limite en outre le nombre de lectures de l'image du plan pendant l'exécution, car des images identiques répétées ne font qu'allonger le contexte.

L'exécution du contact sensible aux obstacles commence par un test d'adjacence entre l'obstacle et la cible du contact. Sans obstacle adjacent, toute stratégie est permise. Avec un obstacle adjacent, la pince aborde depuis une direction qui garde du dégagement, en choisissant la plus éloignée de l'obstacle. Si aucune direction ne convient, la pince pivote pour que son axe d'ouverture soit tangent à l'obstacle, et la charge descend à la verticale. Le même test s'applique à la prise et à la dépose.

Banc d'essai et résultats

SafeLIBERO prend quatre tâches dans chacune des suites LIBERO Spatial, Goal, Object et Long et ajoute un obstacle à chacune : une cafetière moka, une boîte de rangement, un carton de lait, une bouteille de vin, une tasse ou un livre. Le texte de la tâche ne mentionne jamais l'obstacle. Chaque tâche existe à deux niveaux. Au niveau I, l'obstacle est proche de la cible et gêne la prise ou le dépôt. Au niveau II, il est loin de la cible mais sur le trajet de transport. L'article utilise 32 tâches avec 10 graines par tâche. Il réutilise sans changement la boucle d'agent de code de Harness VLA, une politique π0.5 figée et la mémoire de compétences d'origine, si bien que la seule différence tient aux deux harnais. Les mesures sont le taux de réussite des tâches (TSR) et le taux d'évitement des collisions (CAR).

Moyennes du tableau 1, en pourcentage, TSR puis CAR : OpenVLA-OFT 26,2 et 5,7 ; π0.5 57,8 et 17,1 ; AEGIS, une couche de sécurité à fonctions barrières au-dessus de π0.5 et la meilleure méthode antérieure, 67,5 et 68,9 ; SafeHarness avec GPT-5.5 70,0 et 86,0 ; SafeHarness avec GPT-6 71,9 et 87,5. Sur la suite Long, AEGIS obtient 46,3 de TSR contre 54,3 pour la politique figée qu'il enveloppe.

L'ablation du tableau 2 compare trois agents. Avec GPT-6, le modèle seul obtient 6,0 de TSR et 50,0 de CAR. Les auteurs jugent ce CAR vide de sens, puisqu'un bras qui échoue tôt ne touche rien. L'ajout des compétences et du VLA figé donne 31,0 et 59,0. L'ajout des harnais donne 71,9 et 87,5. Avec GPT-5.5, les compétences sans harnais donnent 28,0 et 31,0, et SafeHarness 70,0 et 86,0. La conclusion de l'article : ici, la sécurité est une propriété du harnais, non du modèle qu'il enveloppe.

Notre analyse

Trois points ressortent. D'abord, l'idée centrale est une vieille habitude d'ingénieur appliquée à un nouvel endroit : ne pas se fier à une règle énoncée une fois dans un prompt, la revérifier avec un outil au moment où elle compte. L'article dit que ses outils de vérification n'ont pas d'état vis-à-vis de la conversation, et qu'une interface d'outil porte un invariant plus fiablement que le prompt.

Ensuite, les chiffres méritent une lecture attentive. Les gains de 6,5 % et 27,0 % correspondent à des écarts relatifs tirés du tableau 1 (71,9 contre 67,5, et 87,5 contre 68,9), non à des écarts en points. Les écarts en points sont d'environ 4,4 et 18,6. Les deux lectures montrent un gain, mais l'écart en points sur la réussite reste modeste. La comparaison de l'article avec le même agent sans harnais (40,9 et 28,5 points) est la preuve la plus solide.

Enfin, l'ablation montre un partage utile. Un planificateur plus fort améliore la décision locale du côté d'approche : avec les seules compétences, l'évitement au niveau I passe de 18,8 à 69,0. Il aide peu la sécurité du trajet au niveau II, où le gain est de six points. Avec les harnais, l'écart entre planificateurs se réduit.

Limites et questions ouvertes

Les auteurs énumèrent eux-mêmes leurs limites. L'évaluation suit SafeLIBERO, avec un obstacle par scène et une seule boîte alignée sur les axes comme modèle d'obstacle. Le test du côté de contact est réglé pour une pince à mâchoires parallèles. La qualité de la localisation vient du modèle de segmentation, et un échec de localisation apparaît comme un trajet rejeté plutôt que comme une collision. Chaque épisode coûte plusieurs minutes de temps de planification. L'évaluation se fait d'abord en simulation.

SafeHarness n'est pas non plus sans collision : il déplace encore l'obstacle dans environ un épisode sur huit. La réussite reste plus basse au niveau II (64,0 contre 76,0 avec GPT-5.5, et 62,5 contre 81,2 avec GPT-6). Les auteurs pensent que la cause la plus plausible est qu'un détour vérifié allonge l'épisode sous un budget d'étapes fixe. C'est une supposition, pas un résultat testé.

Nos propres limites de lecteurs : nous n'avons vu que le texte de l'article, pas le code, et nous n'avons pas pu concilier certaines valeurs des tableaux avec le protocole décrit. Les résultats viennent d'un seul banc d'essai, et aucun test sur robot réel n'est rapporté.

Enseignements pratiques

Les équipes qui construisent des agents LLM pour des systèmes physiques ou à enjeux élevés peuvent retenir trois leçons. Mesurer les effets de bord, pas seulement l'atteinte de l'objectif. Placer les contraintes dures dans des vérificateurs que l'agent doit franchir, et pas seulement dans le texte du prompt.

Contrôler les plans avant exécution et garder une voie de replanification pour ce que le vérificateur ne voit pas. L'article s'attend à ce que la même approche par outils s'étende aux limites d'espace de travail et de force, mais c'est une attente, non un résultat. Avant tout déploiement, il faut tester avec plusieurs obstacles, d'autres pinces et du matériel réel.