HarnessDev : les LLM construisent leur propre infrastructure

ByteDance et un groupe d'universités ont lancé HarnessDev, un framework qui permet aux grands modèles de langage (LLM) d'écrire leurs propres « systèmes d'exploitation d'agents », appelés Agent Harnesses. L'équipe fournit au LLM un kit de démarrage minimaliste et le laisse développer le reste, démontrant ainsi comment l'IA peut construire la couche de contrôle qui gère ses propres boucles d'utilisation d'outils, ses étapes de vérification et sa gestion des erreurs — sans qu'un humain ait à taper chaque ligne.

Pourquoi un harness auto-construit est important

Les agents IA ont évolué, passant de simples assistants à commande unique à des travailleurs multi-étapes capables d'appeler des API, d'interroger des bases de données et de combiner des résultats. Jusqu'à présent, les développeurs concevaient manuellement le code d'orchestration qui indique au modèle quand appeler un outil de recherche, comment stocker l'état intermédiaire et comment vérifier une réponse finale. HarnessDev renverse ce modèle : un seed harness (harness de base) fournit juste assez d'échafaudage — des fonctions de base pour les boucles, la sélection d'outils et le suivi de l'état — et le LLM l'étend pour en faire un environnement d'exécution complet.

Dans le benchmark de l'étude, le modèle a produit 18 harnesses distincts, ajoutant plus de 17 000 lignes de code à la graine initiale. Chaque harness gérait le cycle de vie complet d'une tâche : exécution des boucles, sélection du bon outil, maintien du contexte, suivi de l'état, vérification des résultats et récupération après erreur.

Les coûts cachés révélés par l'étude

Les chiffres semblent impressionnants, mais les auteurs avertissent que l'implémentation brute ne signifie pas une utilisation pratique.

  • Composants inutilisés – Une partie importante du code généré n'a jamais été exécutée lors de l'exécution réelle des tâches. Le LLM a écrit des fonctions que l'agent n'a jamais appelées, gonflant la base de code sans apporter de valeur ajoutée.
  • Dépendance au modèle (Model lock-in) – Les harnesses avaient tendance à être optimisés pour le LLM spécifique qui les avait créés. Lorsqu'un même harness était confié à un autre modèle, les performances chutaient de manière notable, ce qui suggère que la logique de contrôle auto-générée intègre des particularités propres au modèle.
  • Lacunes de vérification – Un harness de test a rapporté un taux de réussite de 99 % (99 exécutions sur 100), mais n'était correct que 48 % du temps. Sans une vérification robuste, un agent peut présenter des réponses erronées avec assurance.
  • Surcoût en tokens – L'utilisation des tokens — un indicateur du coût de calcul — variait considérablement. Un harness nécessitait sept fois plus de tokens qu'un autre pour obtenir le même résultat, ce qui soulève des inquiétudes quant à la scalabilité en environnement de production.

Ces conclusions mettent en lumière la nécessité d'une conception disciplinée, même lorsque le code émerge d'un LLM.

Ce que les développeurs doivent garder à l'esprit

  1. Considérez la conception du harness comme une architecture – Ne comptez pas sur le modèle pour que cela « fonctionne tout seul ». Définissez des modules clairs pour le contrôle des boucles, la sélection d'outils, la gestion de l'état et la vérification avant de laisser le LLM les compléter.
  2. Mettez en place une vérification robuste – Insérez des contrôles explicites qui comparent l'affirmation d'un agent à la vérité terrain (ground truth) ou à un modèle secondaire. La précision de 48 % de l'étude, malgré un taux de réussite auto-déclaré de 99 %, montre que la vérification ne peut pas être une réflexion après coup.
  3. Surveillez les budgets de tokens – Des harnesses plus élaborés peuvent faire exploser le nombre de tokens. Analysez les différentes variantes de harnesses dès le début pour éviter des explosions de coûts cachés.
  4. Testez sur plusieurs modèles – Exécutez le même harness avec plusieurs back-ends de LLM. Si les performances chutent brutalement, vous aurez peut-être besoin d'une conception plus agnostique vis-à-vis du modèle ou de harnesses distincts par modèle.

En résumé : HarnessDev prouve que les LLM peuvent rédiger leur propre code de contrôle de type système d'exploitation.