Sber dévoile Universal Agent : le même modèle résout 24 points de tâches supplémentaires grâce à un nouvel environnement d’exécution

Ouvrez le code de n’importe quel agent et vous trouverez presque toujours la même chose : le modèle choisit un outil, du code classique l’exécute, puis le résultat est renvoyé au modèle. La boucle se répète jusqu’à la clôture de la tâche. C’est le principe ReAct, qui tient en dix lignes de pseudocode. Pourquoi existe-t-il alors autant de produits fondés sur cette boucle, et pourquoi fonctionnent-ils différemment ?

L’équipe GigaCode R&D de Sber a répondu avec un article et un projet Python open source, GigaCode Universal Agent. Sa thèse : tout le travail d’ingénierie réside dans le harness, c’est-à-dire l’environnement d’exécution qui entoure la boucle.

Ce qui entoure les dix lignes

Imaginez la tâche suivante : vous disposez d’un cahier des charges et de trois offres de prestataires. Les prix couvrent des périodes différentes, certaines conditions sont dissimulées dans des annexes et une offre omet une prestation obligatoire. L’agent doit tout lire, ramener les données à une base comparable et rédiger une note citant ses sources.

Trois éléments sont nécessaires. La tâche décrit les données à prendre et le résultat à rendre. Une compétence est une procédure réutilisable, comparable au guide remis à un nouvel employé : comment ramener les prix à une même période, signaler « non indiqué » et poser une question au lieu de considérer une omission comme une prestation gratuite. Les outils donnent accès aux données et aux actions ; les systèmes externes sont connectés via MCP. Les règles résident dans la compétence, les accès dans les outils, tandis que le noyau reste inchangé.

Viennent ensuite des questions absentes du pseudocode. Une tâche exécutée en arrière-plan n’a pas d’observateur : l’unité d’exécution est donc ici une Run qui fixe le modèle, la version de la compétence, les outils et les limites de temps, de tokens, d’étapes et d’appels. Lorsqu’une limite est atteinte, l’exécution s’arrête, conserve le travail accompli et indique la raison. Chaque lancement produit une trace permettant de comprendre l’origine d’une conclusion et pourquoi le système fonctionnait hier, mais plus aujourd’hui.

Un juge distinct, c’est-à-dire un second modèle doté de ses propres instructions, compare le rapport et la trace avec la tâche. Si une exigence a disparu ou si une conclusion n’a pas de source, l’agent reçoit des remarques et poursuit son travail. Lorsqu’une vérification peut être effectuée par programme — fichier créé, test réussi, JSON valide — mieux vaut la confier au code. Pour les tâches longues, un mécanisme de journalisation automatique permet à l’agent de condenser son état dans une note brève et de continuer au-delà d’une seule fenêtre de contexte.

La sécurité relève elle aussi du harness. Si l’instruction précise « ne rien envoyer », l’agent ne doit tout simplement pas disposer d’un outil d’envoi d’e-mails. S’y ajoutent les contrôles de lecture et d’écriture, la modération des commandes par le juge et l’isolation des conteneurs.

Ce que montrent les chiffres

Avec le même Qwen3.6-35B-A3B, Universal Agent a été comparé à OpenCode et Qwen Code. Sur SWE-bench Verified : 69,9 %, contre 66,4 % et 65,0 %. Sur Terminal Bench 2.1 : 65,5 %, contre 62,1 % et 41,4 %. Sur SWE-bench Pro et Multilingual, les résultats sont approximativement équivalents. Conclusion des auteurs : un même modèle placé dans un autre harness produit un autre résultat.

En cybersécurité, sur CyberGym lvl1 avec DeepSeek-V4-Flash, une compétence métier a fait passer le score de 70,6 % à 76,7 % sans modifier le noyau. Sur SWE-bench Verified, le coût de l’agent était environ un tiers inférieur à celui de Qwen Code. Les auteurs calculent le coût par tâche réussie : le coût de toutes les exécutions, y compris les échecs et les corrections manuelles, est divisé par le nombre de tâches résolues. Le routage automatique light/default/max a transféré 50–60 % des requêtes vers des modèles plus petits, avec une qualité proche du niveau max, mais cette piste reste expérimentale.

Limites et marche à suivre

Il s’agit d’un article rédigé par les développeurs sur leur propre produit, et la comparaison repose sur leur propre ensemble de conditions. Le juge peut se tromper, la compression du contexte peut faire perdre des détails et l’agent consomme beaucoup de tokens sur les tâches difficiles. Les capacités de recherche scientifique de tous les participants à la comparaison restent modestes. Pour des scénarios métier tels que la comparaison de prestataires, la qualité devra être mesurée sur ses propres exemples.

La conclusion pratique est simple. Lorsque vous choisissez ou construisez un agent, ne débattez pas seulement du modèle : examinez le harness. Vérifiez la présence de limites et de traces, si le résultat est validé indépendamment des affirmations du modèle, si les droits des outils sont restreints et si le coût mesuré est celui d’une tâche accomplie plutôt que celui d’un token. C’est là que se situe aujourd’hui la véritable différence.