Agent Lightning v1.0 entraîne les agents avec leur harnais

Le 7 octobre 2026, Microsoft Research a détaillé le fonctionnement d’Agent Lightning v1.0 et rapporté une progression de 41,8 % à 56,4 % en Pass@1 pour une expérience avec Qwen3.5-9B sur SWE-bench Verified. Le framework avait été publié en open source en août 2026. Son idée centrale : entraîner un agent sans remplacer le harnais logiciel qui gère déjà ses interactions avec son environnement.

Ce qui change quand le harnais pilote la boucle d’interaction

L’apprentissage par renforcement (RL, pour reinforcement learning) entraîne un modèle à partir des résultats de ses actions. Dans le RL agentique classique décrit par Microsoft, le cadre d’entraînement gère la boucle d’interaction. Avec le principe nommé Harnessed Agentic RL, c’est le harnais de déploiement de l’agent qui conserve ce rôle.

Le harnais coordonne notamment le contexte et le déroulement des actions dans l’environnement. Agent Lightning interpose une passerelle compatible avec l’API d’OpenAI entre ce harnais et le modèle : elle transmet les appels du modèle et collecte les données associées. L’agent peut ainsi garder ses outils et son mode de contrôle, à condition que ses requêtes au modèle puissent passer par cette passerelle.

La passerelle, le contrôleur de rollouts et l’entraîneur

Agent Lightning v1.0 s’articule autour de trois composants. L’API Gateway relaie les requêtes et recueille les données des appels au modèle. Le Rollout Controller lance les agents sous forme de processus locaux ou de tâches Kubernetes (Kubernetes Jobs). Le Trainer, qui s’appuie sur verl et vLLM, utilise les échantillons recueillis pour mettre à jour la politique du modèle.

Dans ce dispositif, l’entraîneur observe des paires de requêtes et de réponses du modèle, plutôt qu’une trajectoire continue de toutes les interactions de l’agent avec son environnement. Le point pratique est important : l’intégration dépend de la possibilité de rediriger les requêtes du modèle vers le proxy, pas d’une compatibilité garantie avec tous les agents sans configuration.

La documentation d’Agent Lightning décrit aussi une boucle d’optimisation automatique de prompts, ou APO. Les traces d’exécution et les récompenses alimentent une critique puis une réécriture du modèle de prompt. Le workflow peut également actualiser des ressources telles que des prompts ou des poids de politique ; l’examen manuel des traces reste possible, mais n’est pas requis pour la boucle décrite.

Les défis techniques liés à cette approche

Lorsque le harnais conserve le contrôle de l’interaction, les données d’un rollout peuvent se transformer en un nombre variable d’échantillons. Microsoft identifie plusieurs difficultés qui en découlent : retokeniser et fusionner les échantillons, calculer les avantages lorsque le rollout est réparti en plusieurs échantillons, et normaliser la fonction de perte pour éviter que les rollouts produisant davantage d’échantillons pèsent davantage dans l’entraînement.

L’ordonnancement constitue un autre défi : les rollouts n’ont pas tous la même durée, alors que les ressources du système d’entraînement sont définies à l’avance. Ce sont des problèmes d’architecture que le projet dit devoir gérer, pas un constat de défaut propre à chaque déploiement.

Collocated Async RL partage les GPU entre rollouts et mises à jour

Avec sa méthode Collocated Async RL, Microsoft décrit un partage des GPU entre l’exécution des rollouts et les mises à jour du modèle. Au début d’une mise à jour, la passerelle suspend les nouvelles requêtes, laisse se terminer celles déjà en cours, puis reprend les rollouts une fois la mise à jour achevée.

Microsoft rapporte environ 2× d’accélération de bout en bout par rapport au RL synchrone dans son expérience. Ce chiffre concerne cette comparaison expérimentale ; il ne décrit pas les performances garanties d’autres agents ou environnements.

Deux expériences distinctes sur SWE-bench Verified

Microsoft rapporte les résultats de l’expérience Qwen3.5-9B sur SWE-bench Verified, un benchmark de programmation. Le score Pass@1 mesure la réussite avec une seule proposition : il est passé de 41,8 % à 56,4 % après environ 6 000 échantillons d’entraînement.

Le dépôt du projet présente séparément une expérience avec Qwen3.5-35B-A3B : le résultat sur SWE-bench Verified passe de 47,8 % à 61,6 % après 1 800 exemples. Les deux modèles et leurs volumes d’entraînement sont distincts.

Ces chiffres sont des résultats rapportés par Microsoft et par le dépôt du projet pour les expériences citées. Ils décrivent ces configurations sur SWE-bench Verified, et non une amélioration attendue pour tout modèle, agent ou tâche.