Agent Lightning 1.0 a été publié en open source le 7 octobre 2026 par Microsoft Research Asia, et l'ensemble du framework tient en environ 3 500 lignes de code. Il s'attaque à un défaut ancien de l'apprentissage par renforcement appliqué aux agents : pour entraîner un agent en RL, il fallait jusqu'ici le réimplémenter dans le framework d'entraînement, si bien que l'objet entraîné n'était jamais tout à fait l'agent déployé. Le paradigme proposé s'appelle Harnessed Agentic RL et tient en une phrase : le harnais (harness) utilisé en production doit participer lui-même à l'entraînement.
Ce qui cloche dans l'ancienne méthode
Un agent de code moderne ne se résume pas à un modèle. Gestion du contexte, protocoles d'outils, logique d'exécution et dépendances sont propres à chacun : mini-SWE-agent, OpenHands, Claude Code et Codex fonctionnent tous différemment. Les systèmes de RL agentique classiques comme verl, AReaL ou slime supposent que le framework d'entraînement possède la boucle d'interaction ; chaque nouvel agent impose donc de reconstruire sa boucle. C'est coûteux, et la copie peut diverger silencieusement de l'original : bons scores en entraînement, comportement différent en production. C'est la friction qui revenait sans cesse pendant que l'infrastructure de développement à l'échelle des agents gonflait cette dernière année.
L'idée centrale : un proxy au milieu
Agent Lightning intercale un proxy LLM compatible OpenAI entre l'agent et le modèle. Le code de l'agent ne change pas : il suffit de diriger l'adresse qu'il appelait déjà vers ce proxy, et le système d'entraînement enregistre chaque prompt, chaque réponse et les probabilités logarithmiques comme matière d'entraînement RL. La version 1.0 compte trois composants : une passerelle API qui stocke les rollouts et sert de proxy, un contrôleur de rollout qui lance les exécutions, et un entraîneur personnalisé bâti sur verl. L'exécution est native Kubernetes, les agents tournant comme des jobs standard plutôt que sur des bacs à sable commerciaux payants, ce qui rend les gros volumes de rollouts abordables. Un ordonnancement baptisé Collocated Async RL fait partager les mêmes GPU entre rollouts et mises à jour du modèle, avec un gain de vitesse global d'environ 2x par rapport au RL synchrone, et moins de GPU que les approches totalement asynchrones.
Six mille exemples, 14,6 points de mieux
La publication inclut un pipeline complet d'entraînement d'agent de code : données SWE-smith, mini-SWE-agent comme harnais, Qwen3.5-9B comme modèle de base, et seulement 6 000 exemples environ, sans gros calcul. Le seul entraînement RL a fait passer le Pass@1 sur SWE-bench Verified de 41,8 % à 56,4 %, soit 14,6 points gagnés. Un détail compte pour les praticiens : quand un rollout se scinde en plusieurs exemples, le calcul d'avantage et la normalisation de la perte doivent se faire au niveau du rollout, pas de l'exemple, sinon les rollouts prolifiques sont comptés plusieurs fois et la récompense de validation comme l'entropie de la politique deviennent instables.
Qui devrait l'essayer dès maintenant
Si vous disposez déjà d'un harnais d'agent qui tourne et que vous avez renoncé au post-entraînement RL à cause du coût de réimplémentation, cet outil est fait pour vous : un point d'intégration unique, le proxy, et un code assez court pour être lu en entier. Si votre agent est encore instable ou votre signal de récompense encore flou, attendez : le framework répond à la question du comment entraîner le vrai harnais, pas à celle de ce que « meilleur » signifie chez vous. À ce jour, le seul pipeline démontré de bout en bout concerne un agent de code ; pour les autres types d'agents, il faudra les retours de la communauté.
