openJiuwen a publié un nouveau papier de recherche qui traite le harness d’un agent de codage comme une couche système à part entière, et non comme un simple wrapper autour d’un modèle. Le sujet est important parce que les performances sur les tâches de longue durée dépendent de plus en plus de la gestion du contexte, des outils, de la poursuite de tâche, des diagnostics, de la délégation et de l’arrêt, et pas seulement du modèle sous-jacent. Le papier décrit un substrat d’exécution commun aux agents seuls, sous-agents délégués et flux multi-agents, tandis que le dépôt JiuwenSwarm fournit une implémentation inspectable.
Les auteurs annoncent 82,6 % sur SWE-bench Verified et 87,19 % sur Terminal-Bench 2.1. Ces chiffres sont intéressants, mais la question d’ingénierie la plus utile est de savoir ce qu’ils démontrent réellement. Le papier précise lui-même que les systèmes de leaderboard diffèrent par les modèles, prompts, outils et implémentations. La conclusion la plus solide n’est donc pas qu’un harness a définitivement battu un autre, mais que l’orchestration est devenue une partie mesurable du système agentique et qu’elle doit être évaluée avec des contrôles propres.
Le harness devient un control plane
openJiuwen sépare l’exécution en une Inner Loop pour l’interaction modèle-outil et une Outer Loop pour la poursuite et le contrôle au niveau de la tâche. Les capacités transversales sont attachées au moyen d’un mécanisme appelé Rail, fondé sur des lifecycle hooks et un ordre explicite, plutôt que d’intégrer chaque capacité dans un chemin d’exécution distinct. Les mêmes sémantiques sont réutilisées pour un agent seul, des sous-agents et Swarm Flow.
Cette architecture répond à un problème concret. Les agents de codage cumulent planification, mémoire, gestion du contexte, contrôles de sécurité, intervention humaine, retries et délégation. Si chaque capacité modifie la boucle centrale, le harness devient difficile à raisonner et à tester. Un substrat partagé peut simplifier la composition, mais il transforme aussi la configuration du harness en surface de contrôle qui mérite versioning, observabilité et tests de régression.
Le dépôt montre que le travail ne se limite pas à une proposition théorique. JiuwenSwarm expose la collaboration multi-agent, des workflows Swarmflow déterministes, des permissions d’outils, l’exécution distribuée et un mécanisme Auto Harness visant à optimiser le harness sans modifier les poids du modèle. Le dépôt est sous licence Apache-2.0 et installable, ce qui améliore la possibilité d’inspection et de reproduction.
L’adaptation runtime modifie le framework, pas les poids du modèle
La seconde idée est la runtime adaptivity. Au lieu de réentraîner le modèle, openJiuwen modifie l’état contrôlé par le framework pendant l’exécution. Context Management compresse, réduit ou déporte des informations anciennes; Goal Mode contrôle l’acceptation et l’arrêt; les retours LSP injectent des diagnostics sémantiques; Self-Reflection conserve des expériences de trajectoires terminées.
Cette distinction est importante pour les équipes utilisant des modèles tiers. Une partie des gains sur les tâches longues peut venir du control plane autour d’un modèle fixe, ce qui est généralement plus rapide à faire évoluer que du fine-tuning. Mais cette couche crée aussi une nouvelle surface de panne. Un gestionnaire de contexte peut masquer une information utile, une règle d’arrêt peut terminer trop tôt et une boucle de diagnostic peut surpondérer des signaux statiques qui ne prouvent ni la qualité architecturale ni la conformité au besoin métier.
En production, le harness ne doit donc pas être considéré comme une infrastructure invisible. Les tests doivent couvrir la conservation du contexte, les conditions d’arrêt, les permissions d’outils, les retries et l’injection de diagnostics en plus du modèle.
Le résultat benchmark nécessite un audit de la revendication
Le papier indique qu’openJiuwen avec GPT-5.6 Sol atteint 87,19 % sur Terminal-Bench 2.1, contre 83,8 % pour un résultat sélectionné de Claude Code. Pris isolément, l’écart de 3,39 points peut sembler mesurer l’avantage du harness. Ce n’est pas une estimation contrôlée de cet effet, car les deux systèmes utilisent des modèles différents et peuvent également diverger sur les prompts, outils et implémentations.
Le papier fournit une comparaison plus informative avec Fable 5. Avec le même modèle, openJiuwen annonce 84,04 % et Claude Code 83,8 %, soit seulement 0,24 point. Les auteurs précisent que le model matching réduit un facteur de confusion, mais ne supprime pas les différences de prompts, d’outils ou d’implémentation des agents.
Sur SWE-bench Verified, la comparaison est un peu plus propre: openJiuwen et le meilleur résultat sélectionné utilisent tous deux Claude 4.5 Opus, avec 82,6 % contre 79,2 %. Là encore, il s’agit d’une comparaison de systèmes complets, pas d’une ablation contrôlée du harness. Le papier demande d’ailleurs des études plus larges et des ablations plus détaillées.
Les résultats soutiennent donc l’idée qu’openJiuwen est compétitif comme système agentique complet. Ils ne démontrent pas encore qu’un mécanisme précis comme Rail, Goal Mode ou la gestion adaptative du contexte cause le gain observé.
Ce que les équipes devraient réellement mesurer
Une évaluation utile devrait garder constants le modèle, l’effort de raisonnement, les outils, le budget de tokens et l’environnement, puis varier les composants du harness un par un. On pourrait alors mesurer l’effet réel de la gestion adaptative du contexte, du feedback LSP, de la logique d’arrêt, de la réflexion ou de la coordination multi-agent sur le taux de réussite, la latence, le coût et la fiabilité.
Il faut aussi mesurer les modes d’échec, pas seulement le pass rate. Un agent long-horizon peut boucler, oublier des contraintes, épuiser son budget, surutiliser des outils, s’arrêter avant les critères d’acceptation ou conserver un contexte périmé. Ces échecs correspondent directement aux mécanismes de contrôle que le projet cherche à formaliser.
La conséquence dépasse openJiuwen. L’évaluation des agents devient une discipline full-stack. Un score de modèle ne suffit pas lorsque le harness décide ce que le modèle voit, quels outils il peut appeler, quand il retente et quand il s’arrête. Les comparaisons à modèle constant et les ablations de harness devraient devenir une exigence pour les affirmations portant sur l’orchestration.
Pourquoi ce travail mérite d’être suivi
openJiuwen reste un preprint, et l’évaluation actuelle se limite à SWE-bench Verified et Terminal-Bench 2.1. Les auteurs demandent eux-mêmes davantage d’études contrôlées avec d’autres benchmarks, modèles et configurations. Il n’existe donc pas encore de base pour conclure à une supériorité générale ou à une maturité de production.
L’intérêt éditorial vient de la combinaison d’une implémentation open source inspectable, d’une architecture de harness explicite et de résultats benchmark qui peuvent être audités plutôt que simplement répétés. La contribution la plus importante est de traiter le contrôle runtime comme une couche d’ingénierie modifiable indépendamment des poids du modèle.
Pour les développeurs et architectes, la question devient plus précise: non pas « quel coding model est le meilleur ? », mais « quelle combinaison modèle plus harness produit des résultats fiables avec un budget et une frontière de contrôle fixes ? » C’est un benchmark plus difficile, mais beaucoup plus proche du fonctionnement réel des systèmes agentiques en production.