SoL-Pi : rendre les harnais d’agents de codage plus économes

Le problème n’est pas seulement le modèle

Un agent de développement logiciel ne se résume pas à un modèle qui produit du texte. Entre une demande et une modification de dépôt, il doit choisir quand lire, quand appeler un outil, comment conserver le contexte, quand déléguer une partie du travail, comment vérifier un résultat et quand s’arrêter. Cette couche d’orchestration est souvent appelée le harnais de l’agent. Elle transforme les capacités générales du modèle en une trajectoire concrète de travail.

Le preprint « SoL-Pi: Recursively Scaling Auto-Research Loops for Efficient Agent Harness » part d’un constat simple : plus les agents travaillent longtemps et de manière autonome, plus le volume de tokens et d’appels API devient une contrainte de production. Une amélioration du modèle peut donc être neutralisée par un harnais qui répète des lectures, conserve trop de contexte ou déclenche des étapes de contrôle coûteuses. Les auteurs étudient une autre voie : faire évoluer le harnais lui-même avec une boucle de recherche automatisée.

Le sujet intéresse directement les produits SaaS qui intègrent des assistants de programmation, de support technique ou de maintenance de dépôts. La question n’est pas de rendre chaque réponse moins chère à n’importe quel prix. Il s’agit de réduire le travail superflu tout en maintenant une capacité comparable sur les tâches évaluées.

Une boucle de recherche pour le harnais

SoL-Pi utilise une configuration où une IA de recherche observe les traces d’exécution d’un agent piloté par un harnais de base. Elle propose ensuite des modifications, les teste dans des environnements préparés et conserve celles qui passent des contrôles de capacité et d’efficacité. Les résultats obtenus dans les environnements de développement servent à orienter les itérations suivantes ; l’évaluation finale est réalisée sur des tâches tenues à l’écart de la recherche.

Ce détail est important. Le système ne consiste pas simplement à demander à un modèle de « faire mieux ». Il organise une expérience : un harnais produit une trajectoire, les traces sont examinées, des changements sont proposés, puis ces changements sont soumis à des portes de sélection. Les auteurs cherchent ainsi à éviter qu’une réduction de coût locale soit retenue alors qu’elle dégrade la réussite ou déplace le coût vers une étape ultérieure.

Le processus est inspiré de la recherche récursive, mais l’objet optimisé reste le harnais. Les auteurs ne présentent pas une nouvelle procédure d’entraînement des poids du modèle. Ils travaillent sur les décisions qui entourent le modèle : exécution d’actions, gestion du contexte, traitement des observations et lecture déléguée.

Quatre mécanismes retenus

La version SoL-Pi décrite dans le preprint rassemble quatre mécanismes qui ont survécu au processus de sélection.

Le premier concerne l’exécution des actions. Un agent qui traite un dépôt doit enchaîner des opérations avec suffisamment de contrôle pour ne pas multiplier les appels inutiles. Le deuxième porte sur la compaction du contexte : lorsqu’une trajectoire devient longue, conserver tout l’historique brut augmente le volume lu à chaque étape. Le troisième concerne les observations, c’est-à-dire la manière de décider quelles informations issues de l’environnement méritent d’être conservées ou présentées au modèle. Le quatrième s’appuie sur la lecture déléguée, afin de répartir certaines explorations plutôt que de faire porter toute la collecte d’information au même fil d’exécution.

Ces mécanismes ne sont pas des règles universelles à copier telles quelles dans un produit. Leur intérêt vient de leur combinaison dans un harnais évalué sous contrainte. Une compaction trop agressive peut retirer un détail nécessaire à la correction d’un bug. Une délégation mal contrôlée peut augmenter le nombre de trajectoires sans améliorer la décision finale. Une politique d’observation trop sélective peut économiser des tokens tout en supprimant le signal qui permet de vérifier une action. Le résultat rapporté par SoL-Pi dépend donc du système complet et de ses contrôles.

Les résultats sur EdgeBench

Sur l’évaluation EdgeBench de 51 tâches, le preprint rapporte une performance comparable à celle de Pi avec GPT-5.6 Sol et Opus 5. Dans cette comparaison, le trafic de tokens enregistré baisse de 44,7 à 49,0 %. Le coût API diminue d’environ un tiers selon le résumé, avec des économies horaires estimées entre 8,75 et 13,50 dollars par rapport aux harnais natifs de Codex et Claude Code, et entre 4,36 et 5,71 dollars par rapport à Pi.

La figure de synthèse rapportée par les auteurs donne aussi des réductions de coût API de 50,0 % face à Codex avec GPT-5.6 Sol et de 54,3 % face à Claude Code avec Opus 5 dans les comparaisons présentées. Ces nombres décrivent les configurations et les tarifs de l’expérience ; ils ne constituent pas un prix garanti pour un autre fournisseur, un autre modèle ou un autre dépôt.

Le point le plus intéressant n’est pas un pourcentage isolé. Les auteurs montrent qu’un harnais peut être traité comme un objet d’ingénierie mesurable. On peut comparer sa qualité fonctionnelle, son trafic de tokens et son coût, puis rechercher des changements qui améliorent le compromis. Cette approche est particulièrement pertinente quand un service exécute des milliers de tâches courtes ou un nombre réduit de tâches très longues : dans les deux cas, les appels répétés finissent par peser sur la facture et la latence.

Ce que cela change pour un produit SaaS

Dans un SaaS qui propose un agent de codage, l’optimisation du harnais peut agir à plusieurs niveaux. Une compaction mieux contrôlée peut réduire la quantité de contexte relue à chaque tour. Une observation structurée peut éviter de transmettre au modèle des sorties d’outils déjà devenues inutiles. Une lecture déléguée peut accélérer l’exploration de plusieurs modules d’un dépôt, si les résultats sont ensuite regroupés sans perdre leur provenance. Une politique d’action mieux bornée peut aussi limiter les essais redondants.

Mais la mesure doit rester alignée sur la valeur utilisateur. Un agent qui coûte moins cher mais oublie les tests, modifie un périmètre non demandé ou termine avant d’avoir vérifié son résultat n’est pas une optimisation réussie. Le preprint insiste sur les contrôles de capacité et d’efficacité : la baisse de coût doit être observée avec une capacité comparable dans le protocole retenu.

Pour une équipe produit, cela suggère de conserver au moins trois séries de mesures : réussite de la tâche, volume de tokens ou d’appels, et coût dans le harnais réellement déployé. Il faut également suivre les reprises, les échecs de vérification et les interventions humaines. Un harnais qui semble économique sur une moyenne peut devenir plus cher s’il génère davantage de reprises ou de tickets d’escalade.

Une évaluation à deux niveaux

La logique de SoL-Pi distingue la recherche et l’évaluation finale. Cette séparation est utile pour éviter une boucle qui apprend uniquement à réussir les tâches qu’elle a déjà vues. Dans un projet SaaS, on peut préparer un ensemble de tâches de développement représentatives pour la recherche : lecture de code, ajout de test, correction ciblée, modification de configuration et diagnostic. On conserve ensuite un ensemble séparé pour vérifier que les gains ne sont pas limités aux exemples utilisés pour guider les changements.

Les traces ont ici une fonction centrale. Elles permettent d’examiner où les tokens sont dépensés : lecture initiale, appels d’outils, planification, revues, récupération après échec ou synthèse finale. Sans cette décomposition, une baisse ou une hausse globale reste difficile à expliquer. Avec elle, l’équipe peut relier une modification de harnais à un changement observé dans la trajectoire.

La comparaison doit également utiliser le même périmètre de tâche et un protocole stable. Changer en même temps le modèle, le niveau de raisonnement, les outils et le harnais empêche d’attribuer correctement un effet. SoL-Pi fournit une démonstration de recherche automatisée, pas une dispense de contrôle expérimental.

Les limites à garder en tête

Les résultats annoncés reposent sur 51 tâches EdgeBench et sur les modèles et harnais comparés par les auteurs. Ils ne prouvent pas que les mêmes économies se reproduiront sur tous les dépôts, toutes les langues, tous les fournisseurs ou toutes les politiques de sécurité. Une tâche de maintenance avec un grand monorepo peut avoir un profil très différent d’une tâche de génération de code isolée.

Les économies horaires sont également des estimations liées aux tarifs et aux configurations de l’étude. Elles ne doivent pas être transformées en promesse commerciale sans mesure dans l’environnement cible. Enfin, optimiser un harnais peut introduire des compromis difficiles à voir dans une moyenne : couverture de tests moindre, erreurs rares, dérive du périmètre ou dépendance à une structure de dépôt particulière.

Le document est un preprint publié sur ArXiv. Il doit donc être lu comme un résultat de recherche disponible pour discussion, et non comme une validation définitive par les pairs. Les chiffres sont attribués au protocole décrit par les auteurs ; ils ne constituent pas une garantie de performance pour un déploiement donné.

Une lecture prudente

SoL-Pi propose une idée utile pour les équipes qui construisent des agents : le harnais mérite la même discipline d’expérimentation que le modèle et l’infrastructure. On peut observer ses traces, formuler des changements, mesurer le coût et la capacité, puis protéger l’évaluation finale contre la spécialisation aux tâches de recherche.

La contribution la plus transposable est donc moins le nom d’un mécanisme que la méthode de travail. Dans un service SaaS, chaque réduction de tokens devrait être accompagnée d’une vérification de tâche et d’un suivi des échecs. L’objectif raisonnable n’est pas le minimum d’appels possible, mais le meilleur rapport entre résultat vérifiable, coût et délai dans un périmètre clairement défini.

Sources

Haozhe Liu, Tian Ye, Sensen Gao, Qihang Cao, Yitong Li et coauteurs, « SoL-Pi: Recursively Scaling Auto-Research Loops for Efficient Agent Harness », ArXiv 2609.20519v1, consulté le 21 septembre 2026 : résumé et preprint, PDF.