Microsoft ouvre Orchard, mais l’entraînement réutilisable des agents reste confronté à un problème d’échelle

Microsoft Research a ouvert Orchard avec trois recettes d’entraînement d’agents, remettant en cause l’idée selon laquelle chaque projet d’agent nécessite sa propre infrastructure spécialisée. Le framework couvre l’ingénierie logicielle, l’interaction avec le navigateur et les tâches d’assistant personnel. Sa promesse centrale est la réutilisation : une même couche d’environnement peut prendre en charge la collecte de données, l’entraînement supervisé, l’apprentissage par renforcement et l’évaluation.

C’est important, car la recherche ouverte sur les agents souffre d’un problème d’infrastructure. Les chercheurs peuvent examiner de nombreuses bibliothèques d’orchestration, mais reproduire les systèmes d’entraînement qui sous-tendent des agents performants reste difficile. Les sandbox, les interfaces d’outils, les fonctions de récompense et les trajectoires de longue durée deviennent souvent étroitement liés à une seule tâche.

Microsoft Orchard tente de séparer ces éléments. Au lieu de présenter un nouveau framework applicatif, il se concentre sur l’environnement dans lequel les agents agissent et apprennent. Cette distinction le rapproche davantage d’une plateforme expérimentale d’entraînement que de Microsoft Agent Framework ou AutoGen, qui aident principalement les développeurs à construire et exploiter des applications d’agents.

Les résultats rapportés sont importants. Toutefois, il s’agit encore de résultats de recherche produits par l’équipe du projet, et non de confirmations indépendantes des performances ou de l’accessibilité. La publication s’accompagne également d’une tension pratique : les logiciels réutilisables peuvent réduire la duplication des efforts d’ingénierie, tandis que l’entraînement d’agents à grande échelle exige toujours des modèles, de la puissance de calcul, des environnements de tâches et une expertise opérationnelle.

Orchard transforme l’environnement des agents en infrastructure partagée

Le changement important n’est pas une nouvelle interface d’agent. Il s’agit d’une couche d’environnement réutilisable qui accompagne un agent durant tout son cycle d’entraînement.

Le projet s’articule autour d’Orchard Env, un service natif Kubernetes destiné à gérer des environnements isolés. Un sandbox est un espace de travail contrôlé dans lequel un agent peut exécuter des commandes, modifier des fichiers, parcourir des applications et recevoir des observations sans bénéficier d’un accès illimité à son système hôte.

Selon le framework de modélisation agentique du projet, ce service expose des opérations courantes via une interface REST. Elles comprennent la création et la suppression de sandbox, l’exécution de commandes, la lecture ou l’écriture de fichiers, ainsi que l’application de politiques réseau.

L’environnement reste distinct du harnais d’agent, le logiciel qui traduit les sorties du modèle en actions d’outils. Il reste également séparé du système d’inférence et de l’algorithme d’entraînement. Les chercheurs peuvent ainsi modifier un modèle ou un harnais sans reconstruire chaque composant de gestion des environnements.

Cette séparation répond à une source récurrente de friction. Un agent de programmation peut avoir besoin d’un instantané de dépôt, d’outils de compilation et de tests cachés. Un agent navigateur a besoin d’une interface visuelle et de l’état d’un site web. Un assistant personnel nécessite des API d’outils et une vérification spécifique à la tâche.

Ces contextes semblent différents au niveau applicatif. En dessous, chacun exige un environnement isolé, un gestionnaire de cycle de vie, un canal d’observation et une méthode d’évaluation des résultats. Le framework cherche à rendre ces exigences communes explicites.

Microsoft indique que le service a atteint en moyenne 0,28 seconde pour l’exécution de commandes dans ses tests. L’article associé rapporte également un test de charge impliquant 1 000 sandbox avec un taux de réussite de 100 %. Ces mesures décrivent la configuration des chercheurs et ne doivent pas être considérées comme des garanties universelles en production.

L’architecture utilise l’injection d’agents à l’exécution, ce qui permet de conserver les images de conteneurs propres à chaque tâche séparées du service de contrôle. Elle achemine également les opérations d’exécution et de fichiers directement vers les adresses des pods sandbox. L’article soutient que cela évite une partie de la surcharge associée aux canaux d’exécution Kubernetes.

D’autres détails opérationnels révèlent l’ampleur de l’infrastructure nécessaire à l’entraînement des agents. Le système comprend la création asynchrone de sandbox, le suivi de leur disponibilité, le nettoyage fondé sur des signaux de vie, l’isolation réseau, les nouvelles tentatives et l’augmentation des ressources. Ces fonctions ne sont pas spectaculaires, mais une défaillance de l’une d’entre elles peut invalider ou bloquer un cycle d’entraînement.

Cette ampleur explique la valeur du projet pour la recherche. Les équipes qui étudient différentes tâches d’agents peuvent réutiliser la même couche de contrôle tout en préservant leurs propres modèles, outils et systèmes de récompense. En principe, les expériences deviennent plus faciles à comparer, car moins de variables d’infrastructure changent entre elles.

Le framework n’élimine pas la conception spécialisée des tâches. Les chercheurs doivent toujours créer des environnements valides, définir les actions autorisées, sécuriser les sandbox et développer des évaluateurs pertinents. Il réduit les efforts d’ingénierie répétés autour de ces décisions plutôt que de faire disparaître les décisions elles-mêmes.

La véritable pression s’exerce sur les piles d’entraînement propres à chaque tâche

Orchard remet en cause l’hypothèse selon laquelle les agents de programmation, de navigation et d’assistance nécessitent des systèmes d’entraînement distincts de bout en bout.

La plupart des frameworks publics d’agents se concentrent sur l’orchestration. Ils aident les modèles à appeler des outils, échanger des messages, suivre des workflows ou coordonner plusieurs agents. Ces capacités sont importantes pour les applications, mais elles ne produisent pas automatiquement les données et les retours nécessaires pour améliorer un modèle.

L’entraînement ajoute une couche supplémentaire. Un agent doit tenter des tâches dans un environnement contrôlé, générer des trajectoires en plusieurs étapes, recevoir des récompenses fiables et transformer ces interactions en mises à jour du modèle. Chaque étape peut dépendre de logiciels et d’infrastructures différents.

Une trajectoire est la séquence complète de raisonnements, d’actions, de réponses d’outils et d’états d’environnement générés durant une tâche. Ces enregistrements peuvent devenir des exemples d’entraînement, mais uniquement lorsque le système préserve leur structure et détermine quels comportements ont contribué au résultat.

Cette difficulté s’accentue avec les tâches à long horizon. Un agent de programmation peut examiner plusieurs fichiers, tenter un correctif, exécuter des tests, revoir son approche, puis échouer malgré tout à la fin. Une simple étiquette de réussite ou d’échec n’explique pas quelles décisions intermédiaires ont été utiles.

La réponse du projet consiste à réutiliser à la fois les environnements et les trajectoires entre les différentes étapes du pipeline. Le même service d’environnement prend en charge la collecte de données par modèle enseignant, le fine-tuning supervisé, les rollouts d’apprentissage par renforcement et l’évaluation finale. Les chercheurs n’ont pas besoin de systèmes de sandbox distincts pour chaque étape.

Cette conception contraste avec l’orchestration orientée production. Le framework applicatif d’agents distinct de Microsoft vise la construction et le déploiement d’agents en Python et .NET. AutoGen a également établi des modèles courants pour les conversations multi-agents et l’utilisation d’outils.

La nouvelle pile de recherche répond à une autre question : comment les équipes peuvent-elles entraîner la politique sous-jacente qui décide de l’action suivante d’un agent ? Cette différence empêche une comparaison directe des produits. Un framework applicatif et un environnement d’entraînement peuvent se compléter.

La pression s’exerce plutôt sur les pipelines de recherche fermés et verticalement intégrés. Si une même couche d’environnement ouverte fonctionne dans plusieurs domaines, les équipes ont moins de raisons d’accepter un ensemble indissociable combinant modèle, harnais, sandbox et évaluateur.

En théorie, les petits groupes de recherche en bénéficient le plus. Ils peuvent démarrer avec des primitives d’environnement partagées et des recettes publiées au lieu de concevoir un service distribué complet de sandbox. Ils peuvent aussi tester des modèles plus petits sur des tâches auparavant associées à des systèmes beaucoup plus vastes.

Pourtant, « plus petit » reste relatif. L’exploitation de sandbox Kubernetes, de serveurs d’inférence, de modèles enseignants et de tâches d’apprentissage par renforcement exige toujours une solide expertise technique. La publication réduit une catégorie de complexité sans transformer l’entraînement des agents en workflow ordinaire sur un ordinateur portable.

Les organisations ont également besoin d’une gestion rigoureuse des connaissances autour de ces expériences. Les trajectoires, les échecs d’évaluation, les changements de configuration et les définitions de tâches deviennent rapidement difficiles à rechercher. Une base de connaissances technique peut préserver le raisonnement derrière les résultats, et pas uniquement le score final d’un benchmark.

Le changement stratégique porte donc sur la modularité. Les chercheurs peuvent conserver leur modèle et leur interface d’agent préférés tout en remplaçant un backend d’environnement personnalisé. Si ce modèle est adopté, la réutilisation de l’infrastructure pourrait devenir une attente de référence pour la recherche ouverte sur les agents.

Microsoft Orchard apprend à partir des éléments utiles de l’échec

L’idée la plus forte du framework est qu’une exécution d’agent infructueuse peut malgré tout contenir des preuves d’entraînement précieuses.

La recette d’ingénierie logicielle, appelée Orchard-SWE, commence avec environ 107 000 trajectoires distillées à partir de MiniMax-M2.5 et Qwen3.5-397B. Microsoft indique que le corpus couvre 2 788 dépôts GitHub.

Le jeu de données de trajectoires du projet décrit 107 185 enregistrements d’ingénierie logicielle. Il recense 74 649 trajectoires résolues et 32 536 trajectoires non résolues. Un enregistrement résolu signifie que le correctif final a réussi la suite de tests cachés de la tâche.

Le fine-tuning supervisé traditionnel privilégie les exemples réussis. Cela paraît intuitif, car le modèle apprend à reproduire un comportement qui a atteint le résultat correct. Toutefois, écarter chaque trajectoire échouée peut gaspiller des travaux intermédiaires utiles.

Une exécution de programmation échouée peut correctement localiser le module concerné, identifier une condition défectueuse et rédiger l’essentiel d’un correctif valide. Une modification ultérieure peut faire échouer la solution. Considérer la trajectoire complète comme inutile fait perdre les progrès antérieurs.

La recette introduit un fine-tuning supervisé par attribution de crédit afin de récupérer ce signal. L’attribution de crédit consiste à identifier les actions qui ont contribué aux progrès plutôt que d’attribuer un seul résultat à chaque étape.

Pour les exécutions non résolues, un modèle enseignant examine la trajectoire complète parallèlement au résultat final des tests. Il estime comment la probabilité de résoudre la tâche a évolué après chaque étape. Le pipeline sélectionne ensuite des segments continus dans lesquels cette probabilité estimée a augmenté.

Ces segments ascendants deviennent des cibles supervisées. Les observations antérieures restent disponibles comme contexte, tandis que la perte d’entraînement se concentre sur les raisonnements et actions générés par l’assistant, considérés comme représentant des progrès. Les réponses des outils sont exclues de la perte de prédiction.

Cette technique ne transforme pas l’échec en réussite. Elle avance une affirmation plus limitée : certaines parties d’une tentative infructueuse peuvent apprendre à un modèle à quoi ressemble une exploration productive. La fiabilité de cet enseignement dépend des estimations rétrospectives du modèle enseignant.

La recette ajoute ensuite l’apprentissage par renforcement, dans lequel le modèle génère de nouvelles tentatives et reçoit des récompenses au niveau de la tâche. La partie difficile consiste à obtenir des groupes de tentatives informatifs sans consacrer la majeure partie du budget à des résultats uniformes.

Si chaque tentative réussit, le groupe fournit peu d’informations sur les choix de politique les plus pertinents. Le même problème survient lorsque toutes les tentatives échouent. L’échantillonnage standard à taille fixe peut consacrer une puissance de calcul considérable à générer ces groupes à faible variance.

Microsoft appelle son alternative Balanced Adaptive Rollout. La méthode génère des tentatives progressivement et cherche à constituer un groupe d’entraînement présentant un équilibre utile entre récompenses positives et négatives. Elle peut s’arrêter après avoir trouvé un groupe informatif ou continuer dans une limite budgétaire maximale fixe.

L’approche vise l’efficacité, et pas seulement la précision. Elle consacre davantage d’échantillonnage aux requêtes qui nécessitent plusieurs tentatives pour produire une comparaison significative. Les groupes qui restent inadaptés peuvent être filtrés puis remplacés par des données issues d’autres tâches.

Le projet indique qu’un modèle initialisé à partir de Qwen3-30B-A3B-Thinking a atteint 64,3 % sur SWE-bench Verified après un fine-tuning supervisé. Il a atteint 67,5 % après apprentissage par renforcement.

SWE-bench Verified évalue la capacité des agents à résoudre de véritables tickets GitHub dans des environnements de dépôt reproductibles. Les scores dépendent de la version du benchmark, du harnais, des paramètres d’inférence et des procédures d’évaluation ; les comparaisons exigent donc un alignement méthodologique rigoureux.

Microsoft présente son résultat comme un nouveau sommet parmi les modèles ouverts de taille comparable. Cette précision est importante. Le résultat n’établit pas une supériorité sur tous les systèmes d’agents, en particulier les modèles fermés utilisant des budgets de calcul différents ou un échafaudage non divulgué.

Le mécanisme reste toutefois plus intéressant que la position au classement. L’entraînement à partir de progrès partiels et l’échantillonnage visant une variation informative des récompenses sont des techniques que d’autres équipes peuvent tester de manière indépendante. Leur valeur ne dépend pas entièrement d’un seul score annoncé.

Un environnement prend en charge trois agents très différents

Les trois recettes vérifient si la réutilisation de l’infrastructure résiste aux changements de taille de modèle, d’interface, de structure des tâches et de conception des récompenses.

Le code constitue la démonstration la plus importante, mais ce n’est pas la seule. Orchard-GUI applique la même abstraction d’environnement à un modèle vision-langage de 4 milliards de paramètres qui interagit avec des interfaces de navigateur.

La recette utiliserait environ 400 trajectoires distillées et 2 200 tâches ouvertes. Microsoft indique que le modèle obtenu a atteint un taux de réussite de 74,1 % sur WebVoyager, 67,0 % sur Online-Mind2Web et 64,0 % sur DeepShop.

Ces benchmarks couvrent différentes formes d’interaction web. Un agent de navigateur doit interpréter l’état visuel, choisir des actions et s’adapter à la réponse d’un site web. Contrairement à une tâche de programmation, la réussite peut dépendre de la navigation dans des interfaces dynamiques plutôt que de la production d’un correctif testable.

Le volume de données annoncé est notable, car il est bien inférieur à celui du corpus d’ingénierie logicielle. Il étaye l’argument de Microsoft selon lequel une recette ciblée et un environnement stable peuvent aider un modèle plus petit à rivaliser sans égaler les plus grands systèmes propriétaires en nombre de paramètres.

Toutefois, la réussite sur un benchmark ne garantit pas une navigation fiable en dehors de la distribution de test. Les sites web évoluent, les interfaces exposent des états ambigus et de petites différences visuelles peuvent détourner un agent. Les évaluateurs doivent également définir avec précision ce qui constitue l’achèvement d’une tâche.

La troisième recette, Orchard-Claw, cible les agents assistants personnels. Selon l’article, elle utilise une base Qwen3-30B-A3B-Thinking et environ 200 tâches synthétiques.

Microsoft rapporte 59,6 % en pass@3 sur Claw-Eval. Le pass@3 donne à l’agent jusqu’à trois tentatives et considère la tâche comme réussie lorsqu’au moins une tentative passe. Le résultat atteint 73,9 % lorsque le modèle fonctionne avec le harnais ZeroClaw plus robuste.

Cet écart illustre une leçon essentielle sur les benchmarks d’agents. Le modèle n’est qu’une composante d’un système d’agents. La conception du harnais, le formatage des outils, le comportement de nouvelle tentative, la gestion du contexte et les règles d’évaluation peuvent influer fortement sur le résultat final.

Il complique également les affirmations concernant les petits modèles. Une politique compacte peut bien fonctionner lorsqu’elle est entourée d’une infrastructure efficace, mais le système dans son ensemble peut néanmoins être exigeant sur le plan opérationnel. Le nombre de paramètres ne mesure pas à lui seul le coût ni la complexité du déploiement.

Ensemble, les trois recettes offrent un test de portabilité plus crédible que trois variantes d’un même benchmark de programmation. Elles couvrent le texte et la vision, les tests déterministes et les interfaces ouvertes, ainsi que différentes échelles de modèles.

La couche commune ne rend pas tous les domaines identiques. Chaque recette conserve sa propre collecte de données, son calcul de récompense, son modèle de base et son harnais d’agent. La réutilisation se produit sous ces choix propres à chaque tâche.

Cette frontière est pertinente. Un service d’environnement universel devrait normaliser les primitives de cycle de vie et de communication sans prétendre qu’une tâche de navigateur et une réparation de dépôt partagent les mêmes critères de réussite.

La question plus large est de savoir si des équipes externes peuvent reproduire cette séparation. Les systèmes de recherche internes paraissent souvent modulaires dans les schémas, mais dépendent de conventions non documentées, de configurations cloud ou d’étapes de préparation des données. L’usage par la communauté révélera si les interfaces sont réellement portables.

L’affirmation open source doit encore passer l’épreuve de la reproductibilité

Une architecture publiée et de solides résultats sur benchmark ne sont que le début d’une publication de recherche ouverte.

L’article fournit de nombreux détails d’implémentation, descriptions algorithmiques et paramètres expérimentaux. Les ressources du projet Microsoft identifient également les chercheurs, les modèles, les sources de tâches et les principaux résultats d’évaluation.

Toutefois, l’ouverture pratique comporte plusieurs dimensions. Les chercheurs ont besoin de code accessible, d’instructions d’installation, de jeux de données compatibles, de points de contrôle de modèles, d’images d’environnement, de licences et d’assez de détails de configuration pour recréer les expériences.

La page du jeu de données affiche actuellement un avis indiquant que sa publication est suspendue et que les données seront de nouveau téléversées. Elle précise que le schéma documenté est exact, mais qu’il pourrait ne pas représenter sa forme finale. Les équipes devraient vérifier l’état de la page avant de concevoir un pipeline autour de celle-ci.

Cette suspension n’invalide pas la recherche. Elle limite toutefois la reproductibilité immédiate, en particulier pour la recette d’ingénierie logicielle, dont la valeur dépend fortement de la collecte de trajectoires.

Les licences exigent également une attention particulière. La documentation du jeu de données avertit que les trajectoires renvoient à des dépôts amont possédant leurs propres licences. Les chercheurs qui redistribuent des correctifs, du matériel de test ou des artefacts dérivés doivent examiner ces conditions individuellement.

La sécurité constitue une autre contrainte. L’entraînement d’agents exécute délibérément des actions générées par les modèles. Même les environnements isolés nécessitent des politiques réseau, des limites de ressources, des contrôles des identifiants, une analyse des images et des procédures de nettoyage.

L’article décrit des mécanismes d’isolation réseau et de gestion des pannes, mais chaque déploiement contrôle sa propre frontière de menace. Un cluster de recherche traitant des dépôts publics présente des risques différents d’un environnement d’entreprise contenant du code privé ou des outils internes.

La contamination des benchmarks reste difficile à exclure de manière concluante. Les modèles enseignants ont pu rencontrer des tickets publics, des correctifs ou du code associé lors du préentraînement. Les tests d’évaluation cachés réduisent certains risques, mais ne résolvent pas toutes les questions liées à la mémorisation.

La méthode rétrospective d’attribution du crédit ajoute une autre incertitude. Un modèle enseignant estime si des étapes intermédiaires ont amélioré les chances de réussite. Ces estimations ne constituent des étiquettes utiles que si le modèle enseignant peut interpréter de manière fiable la trajectoire et le résultat du test.

Une estimation erronée peut récompenser un comportement plausible mais non pertinent. Elle peut également négliger une étape dont la valeur ne devient claire que plus tard. Des ablations indépendantes devraient mesurer quelle part des performances provient des données d’échecs partiels plutôt que de l’échelle du modèle, de la qualité de l’enseignant ou de la composition du jeu de données.

Balanced Adaptive Rollout exige un examen similaire. Sélectionner des groupes présentant une variation utile des récompenses peut améliorer l’efficacité de l’entraînement, mais de véritables défaillances de l’environnement peuvent ressembler à des défaillances de la politique. Les délais d’expiration, les erreurs de conteneur ou les tests défectueux ne doivent pas devenir des récompenses trompeuses.

Microsoft indique avoir mis en place une logique de nouvelle tentative, des contrôles de délai d’expiration et des filtres pour les groupes inutilisables. Les équipes externes doivent déterminer si ces protections restent efficaces avec différents clusters, charges de travail et distributions de tâches.

Les chiffres annoncés doivent donc être lus comme des éléments étayant une conception, et non comme une preuve définitive de généralité. Une reproduction sur une infrastructure indépendante renforcerait l’argument. Des résultats dans de nouveaux domaines testeraient si l’abstraction d’environnement s’étend au-delà des trois recettes préparées.

L’issue la plus importante ne sera peut-être pas un nouveau record de benchmark. Il pourrait s’agir d’un socle expérimental partagé permettant aux chercheurs de comparer des méthodes d’entraînement sans reconstruire la mécanique sous-jacente à chaque expérience.

Ce que les chercheurs devraient surveiller ensuite

Trois signaux détermineront si Orchard devient une infrastructure de recherche courante ou demeure une impressionnante implémentation de référence de Microsoft.

Le premier signal est l’exhaustivité de la publication. Les chercheurs devraient surveiller le rétablissement de l’accès au jeu de données, des dépôts de code stables, des instructions d’installation reproductibles, des artefacts de modèles et des définitions d’environnement versionnées.

Une publication complète renforcerait l’affirmation de Microsoft selon laquelle des équipes plus petites peuvent réutiliser le système. Des lacunes persistantes l’affaibliraient, car les aspects les plus difficiles de l’entraînement d’agents résident souvent dans la préparation des données et la configuration opérationnelle.

Le deuxième signal est la reproduction indépendante. Un test crédible utiliserait les recettes publiées sur une infrastructure gérée séparément et rendrait compte à la fois des résultats de benchmark et des besoins totaux en ressources.

Reproduire exactement le score phare n’est pas le seul résultat utile. Les chercheurs devraient documenter le temps de configuration, les taux d’échec du sandbox, le débit de trajectoires, la consommation de calcul et la sensibilité aux choix de harnais. Ces mesures révèlent si la réutilisation génère des économies significatives.

Les expériences indépendantes devraient également isoler la contribution du fine-tuning par attribution du crédit. Les comparaisons peuvent entraîner des modèles équivalents uniquement avec des trajectoires réussies, avec l’ensemble des trajectoires non résolues et avec des segments de progression sélectionnés.

La même approche s’applique aux rollouts adaptatifs. Les chercheurs peuvent comparer un échantillonnage fixe à un échantillonnage équilibré tout en maintenant constants les modèles, les tâches, les fonctions de récompense et les budgets. Cela montrerait si la méthode produit davantage de signal d’apprentissage par trajectoire générée.

Le troisième signal est l’adoption au-delà des domaines préparés par Microsoft. Un nouvel environnement offrirait le test le plus solide, en particulier s’il comporte des outils et des structures de récompense différents.

L’analyse de sécurité, le travail sur les données, les workflows scientifiques et les applications bureautiques sont des candidats plausibles. Chacun introduit des exigences environnementales distinctes de la réparation de dépôts ou de la navigation dans un navigateur. Une réutilisation réussie étayerait l’affirmation selon laquelle l’abstraction est réellement indépendante du harnais.

Les réactions des concurrents comptent également, même si elles doivent rester des éléments de soutien plutôt que l’axe principal du récit. D’autres projets d’entraînement d’agents pourraient adopter des interfaces d’environnement compatibles, publier des backends alternatifs ou standardiser les formats de trajectoires.

L’interopérabilité créerait plus de valeur que la prolifération de frameworks. Les chercheurs pourraient déplacer jeux de données, politiques et évaluateurs entre systèmes sans traduire chaque format d’action et d’observation.

Les développeurs devraient néanmoins éviter de considérer cette publication comme un agent de production prêt à l’emploi. Le projet constitue une infrastructure de recherche destinée à créer et évaluer des politiques. Les systèmes de production ont toujours besoin de logique applicative, d’autorisations utilisateur, de surveillance, de comportements de repli et d’un examen de sécurité.

Pour les acheteurs en entreprise, la question pertinente n’est pas de savoir si le framework remporte un benchmark. Il s’agit de déterminer si une infrastructure d’entraînement modulaire réduit la dépendance à un modèle propriétaire unique ou à une pile d’évaluation contrôlée par un fournisseur.

Pour les chercheurs, la prochaine étape pratique est plus limitée. Examinez l’article de recherche, vérifiez quels artefacts sont disponibles et choisissez une recette correspondant à un environnement d’évaluation existant. Mesurez le coût opérationnel parallèlement aux performances sur les tâches.

Microsoft a avancé une proposition claire : la recherche ouverte sur les agents s’améliore lorsque les environnements deviennent une infrastructure réutilisable plutôt que des rouages de projet dissimulés. La communauté doit désormais mettre à l’épreuve la partie la plus difficile de cette proposition. Des équipes indépendantes peuvent-elles reproduire les résultats, adapter cette infrastructure à de nouvelles tâches et préserver les gains d’efficacité annoncés en dehors de la configuration propre à Microsoft ?