Chiosa
FR
Software & Code

Spine aide les agents de programmation à suivre les tâches imbriquées

Spine: Compiling Subtask Trees into Structured Context for Long-Horizon Coding Agents · arXiv:2610.37224

4 min
Mis à jour

En termes simples

Les longues tâches de programmation comprennent de petites tâches, dont certaines sont terminées alors que d’autres sont encore en cours. Un historique continu peut devenir difficile à parcourir, tandis que le raccourcir peut compliquer le suivi du travail restant.

L’article présente Spine, un moyen pour les agents de programmation de marquer le début et la fin des tâches. Il conserve les détails, mais fournit au modèle le résultat d’une tâche terminée au lieu de tout son historique.

Dans une comparaison, SpineCodex a réalisé davantage de jalons dans un dépôt que Codex, pour un coût inférieur, dans le même cadre de test.

La recherche

Lorsqu’un agent de programmation mène une longue tâche composée de sous-tâches, comment peut-il conserver les détails nécessaires au travail inachevé sans accumuler l’historique de tout ce qui est déjà terminé ?

Confier chaque sous-tâche à un agent distinct peut ajouter de la coordination, même si l’agent en cours pourrait s’en charger.

Spine consigne les tâches de programmation imbriquées et leur état d’avancement, puis prépare chaque entrée du modèle à partir du travail en cours et des résultats des tâches terminées.

Les auteurs ont comparé SpineCodex à Codex sur SWE-Milestone, qui évalue l’avancement de jalons dépendants dans un dépôt tout en préservant son comportement existant. Avec GPT-5.6 Sol, le Score de l’évaluateur, qui combine des tests de nouvelles fonctionnalités et de prévention des régressions, était de 42,6 % contre 38,1 %. SpineCodex a résolu 19 jalons sur 98, contre 14, pour un coût inférieur.

Sur un échantillon aléatoire de 50 tâches ProgramBench, des tests cachés du comportement des programmes reconstruits ont également montré un taux moyen de réussite supérieur pour SpineCodex. Ensemble, ces comparaisons étayent l’intérêt d’organiser le contexte autour de l’état d’avancement des tâches dans les cadres testés.

Les évaluations portent sur une sélection de tâches, de modèles et d’environnements d’agents. Sept des 17 tâches de FrontierSWE n’étaient pas disponibles et ont été exclues.

Les résultats ne permettent donc pas d’établir les performances sur ces tâches ni sur toutes les longues tâches de programmation.

Ce que montrent les preuves

  • Le problème du contexte

    Spine est une interface et un environnement d’exécution pour agents de programmation qui organisent les informations données au modèle autour de sous-tâches imbriquées et de leur état d’avancement. Le problème est qu’un historique d’interactions qui s’allonge peut masquer le travail inachevé, tandis que sa compression risque d’écarter des informations nécessaires pour le reprendre.

    Imposer un agent secondaire à chaque limite entre tâches ajoute aussi de la coordination, même lorsque l’agent en cours pourrait s’en charger.

  • Marquer les limites des tâches

    Avec Spine, un agent ouvre un périmètre de travail pour une sous-tâche, puis le ferme en transmettant un résultat. Il peut gérer localement des périmètres imbriqués, tandis que des tâches indépendantes peuvent être confiées à d’autres agents.

    SpineTree consigne le contenu ordonné, l’imbrication, l’état d’avancement et les résultats renvoyés, ce qui rend explicites les limites entre tâches dans l’historique d’exécution.

  • Préparer les informations du modèle

    Avant chaque appel au modèle, l’environnement Spine conserve les messages et les descriptions des tâches en cours, et remplace les interactions détaillées d’une tâche terminée par le résultat transmis. Ces interactions détaillées restent dans SpineTree.

    Le modèle reçoit ainsi un compte rendu plus court du travail terminé, tandis que l’historique complet reste disponible pour référence.

  • Résultats sur des tâches de dépôt

    Sur SWE-Milestone, qui évalue l’avancement de jalons dépendants dans un dépôt tout en préservant son comportement existant, SpineCodex a obtenu un Score de 42,6 % avec GPT-5.6 Sol. Dans le cadre par défaut, sa comparaison avec quatre méthodes de référence pour la gestion du contexte a donné un Score comparable à celui de Recursive Subagent (42,6 % contre 42,4 %).

    SpineCodex a toutefois résolu davantage de jalons (19 contre 17) pour un coût nettement inférieur (460,77 $ contre 1 749,73 $).

  • Vérifications dans d’autres cadres

    ProgramBench vérifie si des agents peuvent reconstruire des programmes à partir de leur documentation et d’une implémentation de référence exécutable seule ; des tests cachés vérifient si le programme reconstruit reproduit le comportement de référence.

    Sur un échantillon aléatoire de 50 tâches, SpineCodex a obtenu un taux moyen de réussite aux tests supérieur à celui de Codex. Dans Pi, le Score de SpinePi sur SWE-Milestone a progressé de 9,5 % avec Gemini 3.8 Flash et de 17,5 % avec Qwen 3.8 27B.

    Sur ProgramBench, son taux moyen de réussite aux tests a également progressé avec les deux modèles : de 8,7 % avec Gemini et de 4,3 % avec Qwen. Des études d’ablation sur trois projets SWE-Milestone ont testé séparément la limitation de l’imbrication à un seul niveau sous la racine (Depth 1) et la suppression des marqueurs de limites et des états des périmètres dans les entrées du modèle, tout en conservant la compilation de l’état par l’environnement d’exécution.

    Ces deux changements ont augmenté le nombre moyen de jetons d’entrée par requête par rapport à SpineCodex complet : Depth 1 l’a fait passer de 59,8K–78,1K à 82,8K–99,5K ; la suppression des repères de limites l’a porté à 118,1K–128,6K, soit une hausse de 64–97 %.

Détails

Article suivantA search framework adapts recommendation pipelines across stages