Agent Lightning v1.0 dissocie l’entraînement des agents de la réécriture du harness

Agent Lightning v1.0 donne à l’apprentissage par renforcement accès aux harnesses d’agents déployés grâce à environ 3 500 lignes de code de framework. Microsoft Research affirme que ce système open source reconstruit peut entraîner des agents sans recréer leurs outils, leur logique de contexte et leurs boucles d’exécution dans l’entraîneur.

Cette séparation remet en cause une hypothèse courante de l’apprentissage par renforcement agentique. De nombreux systèmes d’entraînement s’attendent à contrôler chaque action, observation et appel de modèle. Les agents réels placent de plus en plus ce contrôle au sein d’un harness, qui gère les outils, la mémoire, les sous-agents et l’évolution du contexte.

La réponse de Microsoft est un endpoint intermédiaire pour le modèle. Un agent existant envoie ses requêtes via un proxy Agent Lightning, tandis que le système d’entraînement observe les appels et les récompenses qui en résultent. Le harness reste responsable de l’exécution de l’agent.

L’approche est plus restreinte qu’un entraîneur universel d’agents. Les équipes ont toujours besoin de tâches évaluées, de modèles adaptés, d’importantes ressources de calcul et d’un environnement d’exécution stable. Toutefois, Agent Lightning v1.0 déplace la principale question d’intégration : il ne s’agit plus de reconstruire un agent, mais d’instrumenter son comportement réel.

Ce changement exerce une pression sur les flux de travail détenus par l’entraîneur, représentés par des systèmes comme verl, AReaL et slime. Il constitue aussi un test exigeant pour l’affirmation centrale de Microsoft : l’entraînement doit améliorer la même architecture d’agent que celle finalement utilisée par les utilisateurs.

Agent Lightning v1.0 intègre le véritable harness à l’entraînement

La version modifie l’endroit où l’apprentissage par renforcement rencontre un agent IA.

Microsoft Research a présenté Agent Lightning v1.0 comme une refonte complète fondée sur le « Harnessed Agentic RL ». Le terme désigne un entraînement dans lequel le harness de déploiement participe directement à l’apprentissage par renforcement.

Un harness d’agent est le logiciel qui entoure un modèle. Il assemble le contexte, invoque des outils, gère les erreurs, délègue le travail et décide quand la tâche est terminée. Les agents de programmation ajoutent souvent l’édition de fichiers, l’exécution de shell, les tests et la navigation dans les dépôts.

L’apprentissage par renforcement agentique traditionnel place généralement cette boucle d’interaction dans le système d’entraînement. L’entraîneur demande une action à un modèle, envoie cette action à un environnement, reçoit une observation et actualise le contexte du modèle. Cette structure fonctionne lorsque l’entraîneur contrôle l’intégralité du rollout.

Les agents de production compliquent cet agencement. Un harness peut résumer d’anciens messages, lancer un sous-agent, réessayer un appel d’outil ou choisir différents prompts selon l’état de la tâche. Reproduire ces choix dans un framework de RL peut créer une seconde implémentation de l’agent.

Cette duplication peut diverger du produit déployé. Une boucle réservée à l’entraînement peut tokeniser les messages différemment, omettre la logique de récupération ou simplifier le comportement des outils. Le modèle apprend alors dans un système qui ressemble à l’agent réel sans lui correspondre exactement.

Agent Lightning v1.0 laisse le harness aux commandes. Les développeurs redirigent l’endpoint du modèle de l’agent vers un proxy compatible OpenAI fourni par Agent Lightning. Le proxy enregistre les requêtes et réponses du modèle nécessaires au processus d’entraînement.

Microsoft détaille cette conception dans son annonce officielle. L’entreprise indique que le code des harnesses existants peut rester inchangé lorsque l’endpoint est redirigé.

Le framework prend également en charge les jobs Kubernetes pour les rollouts d’agents. Ce choix permet à chaque agent de fonctionner avec ses dépendances habituelles dans une couche d’infrastructure familière. Les équipes peuvent utiliser des systèmes locaux, des clusters autogérés ou des environnements Kubernetes dans le cloud.

Microsoft décrit le plan de contrôle comme comptant environ 3 500 lignes de code. Ce chiffre est significatif, car le projet cherche à exposer sa logique d’orchestration plutôt qu’à l’enfouir sous une vaste plateforme.

Il ne décrit toutefois pas l’empreinte logicielle ou matérielle complète. L’inférence de modèle, les mises à jour de politique, l’exécution distribuée et la planification des GPU dépendent toujours de composants environnants. Le framework compact coordonne cette pile au lieu de la remplacer.

La version crée donc une tension précise. Agent Lightning est léger au niveau de l’intégration, tandis que le RL agentique reste exigeant sur le plan opérationnel en dessous.

Le proxy est le mécanisme, pas un raccourci pour contourner le RL

Agent Lightning réduit le travail d’intégration du harness, mais n’élimine pas les difficultés de l’apprentissage par renforcement.

Le proxy sépare l’exécution de l’agent de l’entraînement du modèle. Un agent continue d’utiliser son propre flux de contrôle et ses outils, mais ses appels au modèle de langage passent par Agent Lightning. Le framework peut alors associer ces appels à un rollout et à sa récompense.

Un rollout est une tentative complète d’exécution d’une tâche. Dans un benchmark de programmation, cette tentative peut inclure l’inspection de fichiers, la modification de code, l’exécution de tests et la révision d’un correctif défaillant. Un rollout peut contenir de nombreux appels au modèle.

Cette structure diffère d’un entraînement simple à réponse unique. Un modèle conversationnel produit souvent une réponse qui reçoit un score. Un agent prend une succession de décisions interdépendantes, tandis que la récompense finale peut n’arriver qu’une fois la tâche entière terminée.

Les travaux originaux sur Agent Lightning ont abordé ce problème avec une architecture désagrégée et l’attribution du crédit. L’attribution du crédit détermine quelles décisions doivent être tenues responsables d’une récompense ultérieure. Le précédent article sur Agent Lightning décrivait la conversion de trajectoires d’agents complexes en transitions d’entraînement.

La version 1.0 s’intéresse plus directement à la relation entre l’entraînement et le harness. L’entraîneur ne suppose plus qu’un rollout se présente sous la forme d’une séquence de tokens unique et propre. Il observe des paires distinctes de requêtes et de réponses générées par un système qu’il ne contrôle pas.

Cela crée quatre problèmes techniques mis en évidence par Microsoft.

Premièrement, la retokenisation peut modifier les frontières entre tokens. Les harnesses stockent généralement le contexte sous forme de texte, tandis que l’apprentissage par renforcement nécessite les identifiants précis des tokens échantillonnés lors de l’inférence. Reconstruire ultérieurement les tokens peut produire des écarts.

Deuxièmement, un seul rollout peut devenir plusieurs échantillons d’entraînement. La synthèse de contexte, les sous-agents ou les appels répétés au modèle peuvent diviser une tâche en fragments inégaux. L’entraîneur doit éviter de considérer qu’un rollout comportant davantage de fragments est intrinsèquement plus important.

Troisièmement, la normalisation de la perte peut déformer l’apprentissage. Si l’entraîneur établit une moyenne par nombre d’échantillons, les agents qui effectuent davantage d’appels au modèle reçoivent plus de poids. Ce comportement peut refléter la conception du harness plutôt que la qualité de la tâche.

Quatrièmement, le backend reçoit des charges de travail variables. Le nombre et la longueur des échantillons ne sont connus qu’une fois le harness terminé. La topologie GPU et les paramètres d’entraînement distribué exigent généralement des formes plus prévisibles.

Le rapport technique v1.0 présente ces questions comme des différences fondamentales entre le RL agentique conventionnel et le RL agentique avec harness. L’article présente le framework comme un banc d’essai pour les étudier, et non comme la preuve qu’elles ont disparu.

Agent Lightning traite ces préoccupations grâce à un traitement conscient des rollouts. Les échantillons issus d’une même tentative restent liés, ce qui permet de calculer les avantages et les pertes sans compter aveuglément chaque appel au modèle comme une trajectoire indépendante.

Cette distinction compte pour les agents aux comportements très différents. L’un peut résoudre une tâche en trois appels. Un autre peut en utiliser vingt parce qu’il explore davantage de fichiers ou corrige à plusieurs reprises ses erreurs. Une moyenne au niveau des échantillons pourrait récompenser la verbosité ou pénaliser une récupération prudente.

Le proxy fournit également au framework une frontière stable. Les développeurs d’agents n’ont pas besoin d’exposer chaque branche interne de leur harness. Les appels au modèle, l’identité de la tâche et les informations de récompense doivent rester suffisamment observables pour l’entraînement.

Cette conception ressemble davantage à un point de contrôle réseau qu’à un nouveau framework d’agents. Elle n’impose pas la manière dont un agent planifie, les outils qu’il utilise ou la façon dont son contexte est assemblé. Elle relie ces décisions à une boucle d’apprentissage.

L’observabilité a toutefois ses limites. Un proxy peut enregistrer le trafic du modèle, mais n’explique pas automatiquement chaque changement d’état au sein d’un harness. Les effets de bord des outils, les caches cachés, les services non déterministes et les API externes peuvent toujours affecter le résultat.

Les équipes doivent aussi définir des récompenses qui représentent la réussite réelle. Une suite de tests peut évaluer un correctif de code, mais de nombreuses tâches métier ne disposent pas d’un vérificateur aussi clair. De mauvaises récompenses peuvent entraîner un agent à exploiter le processus de mesure au lieu d’améliorer le comportement visé.

Agent Lightning supprime donc une barrière d’intégration. Il ne transforme pas un flux de travail impossible à mesurer en tâche de RL fiable.

L’entraînement sur de vrais harnesses remet en cause les boucles d’agents détenues par l’entraîneur

L’enjeu principal est de préserver un harness déployé ou de reconstruire son comportement dans un moteur d’entraînement.

Les boucles détenues par l’entraîneur offrent des avantages importants. Elles donnent aux chercheurs un accès direct aux actions, observations, tokens et états de l’environnement. Ce contrôle peut simplifier le batching, le débogage et l’optimisation.

La faiblesse apparaît lorsque l’agent de production devient plus complexe que l’abstraction d’entraînement. Les agents modernes de programmation disposent de schémas d’outils, de prompts, de politiques de contexte, de gestionnaires de dépendances et de logiques de récupération distinctifs. Leurs performances proviennent de l’ensemble du système, et pas seulement du modèle sous-jacent.

Microsoft cite mini-SWE-agent, OpenHands, OpenCode, Claude Code et Codex comme exemples d’agents dont le comportement du harness est significatif. Reconstruire l’un d’eux au sein d’un entraîneur nécessiterait davantage que la reproduction d’une boucle ReAct de base.

L’entraînement avec harness propose une autre répartition des responsabilités. L’équipe chargée de l’agent possède le runtime, tandis que le framework de RL possède la collecte de données et les mises à jour du modèle. Le proxy devient le contrat entre ces couches.

Cet agencement pousse les projets d’entraînement existants à prendre plus naturellement en charge des runtimes arbitraires. Le rapport v1.0 indique que des frameworks connexes ont adopté des variantes de l’entraînement d’agents désagrégé, y compris des travaux plus récents associés à verl, AReaL, slime et Polar.

Cela ne rend pas ces projets interchangeables avec Agent Lightning. Chaque système fait des choix différents concernant la génération de rollouts, l’entraînement distribué, l’inférence et les algorithmes pris en charge. La contribution de Microsoft est une affirmation architecturale plus tranchée sur l’entité qui doit posséder la boucle d’interaction.

Cette conception est particulièrement pertinente pour les organisations qui exploitent déjà un agent. Remplacer un harness fonctionnel uniquement pour l’entraînement crée un risque d’ingénierie. Maintenir des implémentations parallèles ajoute aussi des besoins de tests et de coordination des versions.

Avec Agent Lightning, une équipe peut orienter l’agent existant vers le proxy et l’exécuter sur des tâches évaluées. Si l’entraînement réussit, le modèle qui en résulte revient dans le même système environnant. Cela réduit une source de décalage entre l’entraînement et le service.

Le décalage entre entraînement et service se produit lorsque les conditions utilisées pendant l’optimisation diffèrent de celles de la production. Le concept est familier en apprentissage automatique conventionnel, mais les agents élargissent le problème. Leur runtime inclut les outils, les prompts, les politiques d’exécution et les dépendances environnementales.

Préserver le harness ne peut pas éliminer chaque différence. Les dépôts de benchmark ne sont pas des environnements clients réels. Les autorisations de sandbox peuvent différer, les outils peuvent renvoyer d’autres données et les utilisateurs réels fournissent rarement des signaux de récompense clairs.

Pour autant, l’utilisation du harnais de production élimine un décalage évitable. Elle permet à l’entraînement d’exercer la même gestion du contexte et le même flux de contrôle que ceux qui façonneront le modèle après son déploiement.

Cette approche modifie également ce qui peut être inspecté. Si un déploiement échoue, une équipe peut examiner la séquence de l’agent réel plutôt qu’une réplique d’entraînement simplifiée. Cela peut révéler si le problème provient du modèle, de l’interface d’outils, de la récompense ou de la politique du harnais.

Pour les organisations d’ingénierie, ces traces créent un second défi opérationnel. L’entraînement d’agents produit des prompts, des résultats d’outils, des modifications de code, des sorties de récompense et des notes d’expérimentation répartis entre plusieurs systèmes. Une base de connaissances d’ingénierie consultable peut aider à préserver le raisonnement à l’origine de ces expériences.

L’implication plus profonde n’est pas que chaque entraîneur doit devenir un proxy. C’est que les frameworks d’agents ne peuvent plus être considérés comme de simples enveloppes jetables autour d’un modèle.

Un modèle peut se comporter différemment lorsque le harnais tronque l’historique, modifie la description d’un outil ou délègue une tâche. Un entraînement qui ignore ces comportements n’optimise qu’une représentation partielle de l’agent déployé.

Agent Lightning v1.0 transforme cette observation en frontière architecturale. La question de savoir si cette frontière deviendra une norme dépendra de résultats allant au-delà des exemples de Microsoft.

Le gain sur SWE-bench est prometteur, mais exige une lecture attentive

Microsoft rapporte une forte amélioration en programmation, mais un seul résultat de benchmark ne peut valider tous les harnais ni toutes les charges de travail.

L’expérience phare utilise Qwen3.5-9B et SWE-bench Verified. Microsoft indique que le Pass@1 est passé de 41,8 % à 56,4 % après un apprentissage par renforcement sur environ 6 000 exemples d’entraînement.

Cela représente une amélioration absolue de 14,6 points de pourcentage. Le Pass@1 mesure si l’agent résout une tâche lors de sa première tentative évaluée. SWE-bench Verified utilise des problèmes logiciels filtrés par des humains et issus de dépôts réels.

Le dépôt du projet présente le pipeline de programmation comme un exemple reproductible. Il comprend la préparation des données, l’exécution des rollouts, des scripts d’entraînement et des protections contre le piratage de récompense. Ces détails rendent l’affirmation plus utile qu’un score isolé.

Microsoft a ensuite ajouté un second exemple impliquant Qwen3.5-35B-A3B. Le dépôt indique que le RL pur a fait passer son score SWE-bench Verified de 47,8 % à 61,6 % avec 1 800 exemples d’entraînement.

Ces deux résultats restent des mesures rapportées par le projet. Les lecteurs ne doivent pas les considérer comme des audits indépendants du benchmark. Les paramètres matériels, la configuration de l’agent, le filtrage des tâches, la conception de la récompense et les procédures d’évaluation influencent tous le résultat.

Le benchmark lui-même mesure également un type limité de comportement agentique. Il teste si un système de programmation peut résoudre des problèmes de dépôt acceptés par l’évaluateur. Il ne mesure ni la maintenance à long terme, ni le jugement en matière de sécurité, ni la collaboration avec des développeurs humains.

SWE-bench reste néanmoins pertinent parce qu’il fournit un retour exécutable. Les tests peuvent souvent distinguer un correctif fonctionnel d’un correctif infructueux. Cela rend les tâches de programmation plus adaptées à l’apprentissage par renforcement que les workflows évalués uniquement au moyen de préférences subjectives.

Le projet public SWE-bench offre également aux chercheurs un point de comparaison commun. Toutefois, les comparaisons ne restent significatives que lorsque les systèmes utilisent des versions de benchmark et des conditions d’évaluation alignées.

Le résultat rapporté soutient le mécanisme de Microsoft d’une manière importante. Il montre qu’un véritable harnais de programmation peut générer des données d’entraînement sans être réécrit sous la forme d’une boucle contrôlée par l’entraîneur. Le modèle s’améliore ensuite dans le cadre de l’évaluation rapportée.

Il ne prouve pas que la même recette se transpose sans difficulté aux agents commerciaux, aux assistants de recherche ou aux workflows d’entreprise. Ces systèmes peuvent manquer d’environnements déterministes et de fonctions de récompense fiables.

Un agent de support pourrait optimiser la clôture des tickets plutôt que la résolution des problèmes des clients. Un agent de recherche pourrait apprendre à satisfaire un correcteur automatisé tout en négligeant des éléments de preuve contradictoires. Une automatisation interne pourrait exploiter des autorisations prévues uniquement pour les tests.

Le piratage de récompense est particulièrement dangereux lorsque les agents peuvent utiliser des outils. Un modèle n’a pas besoin de produire directement une phrase trompeuse. Il peut manipuler des fichiers, des tests, l’état ou des services externes afin d’obtenir un score plus élevé.

Microsoft reconnaît ce risque en intégrant la prévention du piratage de récompense dans le workflow de programmation. La présence de ces défenses est précieuse, mais elle montre également pourquoi l’intégration par proxy n’est qu’un élément de la préparation au déploiement.

Les exigences de calcul apportent un autre rappel à la réalité. Le code du framework est compact, mais le guide de démarrage rapide requiert une machine équipée d’un GPU A100. Il lance également Ray, verl, vLLM, un serveur et un contrôleur.

Cette pile est normale pour un entraînement sérieux de modèles. Cela signifie simplement que « 3 500 lignes » doit décrire le plan de contrôle d’Agent Lightning, et non l’ensemble du système nécessaire pour exécuter du RL agentique.

Cette distinction compte pour l’adoption. Une équipe peut intégrer son harnais rapidement tout en consacrant des efforts considérables aux jeux de données, aux récompenses, aux opérations GPU, au suivi des expériences et à l’analyse des échecs.

Une autre incertitude concerne la reproductibilité entre les harnais. Le comportement des agents peut être non déterministe avant même l’échantillonnage du modèle. Les outils en réseau, les mises à jour de paquets, l’état des dépôts et la latence des services peuvent modifier les trajectoires.

Un suivi convaincant reproduirait les gains sur plusieurs implémentations d’agents indépendantes. Il rendrait également compte de la stabilité de l’entraînement, de l’utilisation du calcul, des exécutions échouées et de la sensibilité aux choix de récompense.

D’ici là, le benchmark doit être lu comme la preuve que cette conception peut fonctionner, et non comme la preuve qu’elle fonctionnera toujours.

Un contrôle léger ne signifie pas des opérations légères

Agent Lightning simplifie la connexion à l’entraînement tout en laissant à l’opérateur les obligations d’infrastructure, d’évaluation et de sécurité.

La prise en charge native de Kubernetes offre au projet une voie pratique pour des rollouts isolés. Un agent peut s’exécuter comme une tâche Kubernetes avec son propre conteneur, ses outils et ses dépendances. Le contrôleur peut lancer de nombreuses tâches tandis que le backend d’entraînement traite leurs résultats.

Cette configuration évite d’exiger un service de sandbox commercial. Elle permet également aux organisations de conserver les charges de travail sur une infrastructure qu’elles gèrent déjà. Cela peut compter lorsque l’entraînement utilise des dépôts privés ou des outils internes.

L’exécution autogérée transfère la responsabilité au lieu de l’éliminer. Les équipes doivent sécuriser les conteneurs, les identifiants, l’accès réseau, le stockage et les autorisations du cluster. Un agent RL produit de nombreuses actions, y compris des actions échouées et exploratoires.

Les rollouts de programmation peuvent exécuter des commandes shell et modifier des dépôts. Une tâche insuffisamment isolée pourrait atteindre des secrets, des services partagés ou des données non liées. Le même risque devient plus grave lorsque l’entraînement s’étend à de nombreuses tâches parallèles.

Le proxy ajoute un autre composant sensible. Il observe les prompts et les réponses du modèle, qui peuvent contenir du code source, des documents récupérés ou des instructions internes. Les opérateurs ont besoin de politiques de conservation, d’accès et de masquage adaptées à ces données.

Le dépôt open source utilise la licence MIT, ce qui réduit les frictions juridiques pour l’expérimentation. Il ne fournit toutefois ni sécurité gérée ni garanties opérationnelles.

La base de code compacte du framework peut aider les équipes expertes à auditer le chemin de contrôle. Un nombre moindre d’abstractions internes peut faciliter la compréhension de l’ordonnancement et du flux de données. Cependant, les dépendances environnantes restent nombreuses et évoluent indépendamment.

La compatibilité des versions mérite de l’attention. Agent Lightning repose sur des serveurs de modèles, des composants de calcul distribué, des backends d’entraînement, des images de conteneurs et des bibliothèques matérielles. Un petit projet peut tout de même se trouver au centre d’un graphe de dépendances complexe.

La charge opérationnelle variera selon l’utilisateur. Un laboratoire de recherche disposant déjà d’un cluster GPU et d’un pipeline de benchmark pourra trouver le framework réellement léger. Une équipe applicative sans infrastructure RL pourra considérer le proxy comme la plus petite partie du projet.

La conception de la récompense crée une séparation similaire. Les équipes qui disposent déjà de tests exécutables possèdent un solide point de départ. Les équipes qui évaluent un travail de connaissance ouvert doivent construire des correcteurs avant que l’apprentissage par renforcement puisse produire un retour fiable.

La revue humaine peut compléter les récompenses automatisées, mais elle augmente les coûts et ralentit l’itération. Les correcteurs fondés sur des modèles peuvent évoluer plus rapidement, mais ils introduisent leurs propres biais et vulnérabilités.

C’est pourquoi cette publication importe surtout comme proposition d’infrastructure. Elle affirme que les équipes devraient entraîner les agents via leurs véritables harnais, puis fournit une implémentation de référence compacte pour cette frontière.

La proposition est suffisamment crédible pour être testée. Sa valeur plus large dépendra de la capacité des utilisateurs à construire des récompenses fiables et à exploiter la pile environnante sans introduire de risques plus importants.

Trois signaux montreront si le RL agentique avec harnais se diffuse

Le prochain test sera l’adoption dans des harnais indépendants, suivie de résultats reproductibles et d’éléments de preuve plus larges au-delà de la programmation.

Le premier signal sera une intégration réussie avec des runtimes d’agents non liés. L’architecture de Microsoft promet la compatibilité parce que les agents communiquent via un endpoint de modèle standard. Des exemples indépendants devraient montrer la quantité de code, de configuration et de débogage requise pour chaque intégration.

Des intégrations fluides renforceraient l’idée qu’un proxy constitue une frontière durable. Des correctifs répétés spécifiques à chaque harnais affaibliraient l’affirmation selon laquelle Agent Lightning peut rester largement agnostique.

Le deuxième signal sera une reproduction indépendante des gains de programmation rapportés. Les chercheurs devraient réexécuter les workflows Qwen3.5 et documenter la sélection des données, le calcul, la logique de récompense et les paramètres d’évaluation. Des résultats sur plusieurs clusters révéleraient si la recette est stable.

La reproduction importe davantage qu’un meilleur chiffre au classement. Les preuves les plus solides montreraient que les équipes peuvent obtenir des améliorations similaires sans infrastructure non documentée ni intervention spécifique aux tâches.

Le troisième signal sera la performance sur des workflows dont le retour est moins déterministe. Des expériences de recherche, de récupération d’information et de suivi d’instructions figurent dans le programme de recherche, mais la programmation fournit actuellement le récit le plus clair de la v1.0.

Des tâches plus larges testeront la capacité du RL agentique avec harnais à gérer des récompenses bruitées. Elles révéleront également comment le framework se comporte lorsque la réussite dépend du jugement factuel, des préférences des utilisateurs ou de résultats commerciaux différés.

Ces signaux devraient émerger à travers les publications du projet, les rapports techniques et des expériences publiées de manière indépendante. L’activité GitHub témoignera à elle seule de l’intérêt, mais non de l’amélioration sûre des agents entraînés en production.

Agent Lightning v1.0 mérite l’attention parce qu’il identifie un véritable décalage architectural. Les agents dépendent désormais du comportement du harnais, alors que de nombreux systèmes d’apprentissage par renforcement supposent encore que l’entraîneur possède la boucle d’interaction.

Le proxy de Microsoft apporte une réponse ciblée. Conservez le harnais déployé, observez ses appels au modèle, préservez les relations entre les rollouts et entraînez la politique sans construire un second agent.

Cette approche réduit la duplication, non la difficulté. Les équipes ont toujours besoin de correcteurs fiables, d’environnements contrôlés, d’une infrastructure compatible et d’une évaluation rigoureuse. Les améliorations rapportées sur SWE-bench rendent cette approche digne d’être testée, mais ne tranchent pas la question.

Les développeurs qui évaluent Agent Lightning v1.0 devraient commencer par un workflow noté et un harnais existant. Mesurez les changements d’intégration, les rollouts échoués, l’utilisation du calcul et les exploitations de récompense avant d’élargir l’expérience. Si des équipes indépendantes reproduisent les résultats de Microsoft sur différents harnais, la frontière du proxy pourrait devenir une base commune pour l’entraînement d’agents.