AOS-Bench : deux agents séparés de 0,6 point livrent 54% et 68% des tâches

Les agents de codage ne se contentent plus d'exécuter des requêtes ponctuelles : ils deviennent des assistants permanents auxquels on confie un flux de travail, avec build, traitement de données et correction de bugs en même temps, le tout sur une seule machine. Une équipe de cinq auteurs menée par Erle Zhu a publié AOS-Bench, un benchmark qui évalue un système agentique précisément comme le gestionnaire d'une telle charge. Résultat principal : le succès en isolation prédit mal le succès en flux. Sur les charges lourdes, chacun des cinq systèmes testés perd de 13 à 23 points.

Pourquoi les tests habituels ignorent la file d'attente

Les benchmarks existants exécutent chaque tâche séparément, dans un environnement propre et avec toutes les ressources disponibles. Le travail réel ne se présente pas ainsi. Les tâches arrivent au fil du temps, et l'agent décide lui-même quand en prendre une nouvelle, comment la déléguer et lesquelles lancer en parallèle. Il doit en outre respecter les limites de processeur et de mémoire. S'il en lance trop, la machine sature. S'il en lance trop peu, une partie des tâches n'est jamais touchée.

AOS-Bench est conçu de sorte que des tâches vérifiées arrivent au fil du temps et doivent être livrées sous des contraintes communes de CPU et de mémoire. Ces mêmes tâches, exécutées une par une, servent de référence pour chaque système. L'écart entre le résultat isolé et le résultat en flux montre quelle part de la capacité de l'agent se perd dans la gestion.

Où les points se perdent

Les auteurs ont testé cinq paires « modèle–harness ». Le tableau est contrasté :

• sur les charges lourdes, chaque système perd 13 à 23 points par rapport à son succès en isolation ;
• sur les charges moyennes, les systèmes sont séparés de 11 points en succès isolé, mais déjà de 26 points en succès en flux ;
• deux systèmes séparés de 0,6 point en isolation livrent 54% et 68% des mêmes tâches ;
• avec une distribution séquentielle, 73% des tâches de la charge lourde ne sont pas prises en charge ;
• une concurrence fixe égale à deux reste au plus à 4 points de la meilleure politique pilotée par l'agent, aussi bien sur les charges moyennes que sur les charges lourdes ;
• quelle que soit la politique, la charge CPU médiane reste sous 30% des cœurs alloués pendant que des tâches attendent leur tour.

Les interventions sur la politique d'exécution montrent qu'une part importante de l'écart s'explique par la prise en charge des tâches. L'agent n'a tout simplement pas le temps de prendre le travail qui l'attend dans la file, ou ne décide pas de le faire. La qualité de la solution elle-même passe ici au second plan.

Une file simple contre un gestionnaire intelligent

La conclusion la plus gênante concerne la complexité. On pouvait s'attendre à ce qu'un agent qui planifie lui-même le chevauchement des tâches et répartit les ressources batte nettement un schéma rudimentaire. En pratique, une limite fixe de deux tâches simultanées se rapproche à quatre points de la meilleure gestion agentique. Pendant ce temps, la machine reste le plus souvent inactive : les cœurs sont occupés à moins de 30% en médiane, alors que la file contient du travail non exécuté.

Le goulot d'étranglement se situe donc dans la décision « prendre ou attendre », et non dans un manque de matériel. Les agents sont trop prudents, ou évaluent mal ce qui peut être lancé en même temps, et laissent des ressources inutilisées.

Les auteurs concluent que la gestion de la charge doit être considérée comme une capacité à part entière des agents, à mesurer séparément de l'aptitude à résoudre des tâches. Deux systèmes aux résultats quasi identiques en isolation se comportent de façon radicalement différente en flux, et les classements habituels ne le montreront pas.

Conséquence pratique pour les équipes qui déploient des agents de codage permanents : choisir un système d'après des benchmarks à tâche unique ne suffit pas. Il faut vérifier son comportement avec plusieurs tâches parallèles sur une machine réelle. Il faut regarder la part de tâches effectivement prises en charge et la charge CPU pendant l'attente. Avant de construire une orchestration complexe, il est utile de la comparer à une file rigide à deux slots : selon AOS-Bench, cette base de référence s'avère étonnamment solide. Pour les développeurs de harness, le test désigne un point d'amélioration précis : la politique de prise en charge des tâches, où se perd jusqu'à 73% du travail potentiel.

Le preprint a été publié sur arXiv le 23 octobre 2026, et une deuxième version est sortie le 27 octobre.