Microsoft apre Orchard, ma l'addestramento riutilizzabile degli agenti ha ancora un problema di scala

Microsoft Research ha reso disponibile Orchard con tre ricette per l'addestramento degli agenti, mettendo in discussione l'idea che ogni progetto sugli agenti necessiti di un'infrastruttura specializzata propria. Il framework copre l'ingegneria del software, l'interazione con il browser e le attività di assistente personale. La sua promessa centrale è il riuso: un unico livello di ambiente può supportare la raccolta dati, l'addestramento supervisionato, il reinforcement learning e la valutazione.

È rilevante perché la ricerca aperta sugli agenti ha un problema infrastrutturale. I ricercatori possono esaminare numerose librerie di orchestrazione, ma riprodurre i sistemi di addestramento alla base di agenti capaci rimane difficile. Sandbox, interfacce degli strumenti, funzioni di ricompensa e traiettorie di lunga durata finiscono spesso per essere strettamente legati a un singolo compito.

Microsoft Orchard cerca di separare questi elementi. Invece di presentare un altro framework applicativo, si concentra sull'ambiente in cui gli agenti agiscono e apprendono. Questa distinzione lo avvicina più a una piattaforma sperimentale di addestramento che a Microsoft Agent Framework o AutoGen, che aiutano principalmente gli sviluppatori a costruire e gestire applicazioni basate su agenti.

I risultati riportati sono significativi. Restano tuttavia risultati di ricerca del team del progetto, non conferme indipendenti delle prestazioni o dell'accessibilità. Il rilascio comporta inoltre una tensione pratica: il software riutilizzabile può ridurre la duplicazione ingegneristica, mentre l'addestramento di agenti su larga scala richiede ancora modelli, capacità di calcolo, ambienti di task e competenze operative.

Orchard trasforma l'ambiente dell'agente in infrastruttura condivisa

Il cambiamento importante non è un'altra interfaccia per agenti. È un livello di ambiente riutilizzabile che accompagna un agente per l'intero ciclo di addestramento.

Il progetto ruota attorno a Orchard Env, un servizio nativo Kubernetes per gestire ambienti isolati. Una sandbox è uno spazio di lavoro controllato in cui un agente può eseguire comandi, modificare file, navigare nelle applicazioni e ricevere osservazioni senza avere accesso illimitato al sistema host.

Secondo il framework di modellazione agentica del progetto, questo servizio espone operazioni comuni tramite un'interfaccia REST. Tali operazioni includono la creazione e l'eliminazione di sandbox, l'esecuzione di comandi, la lettura o scrittura di file e l'applicazione di policy di rete.

L'ambiente rimane separato dall'harness dell'agente, il software che traduce gli output del modello in azioni sugli strumenti. Rimane inoltre separato dal sistema di inferenza e dall'algoritmo di addestramento. I ricercatori possono quindi modificare un modello o un harness senza ricostruire ogni componente della gestione degli ambienti.

Questa separazione affronta una fonte ricorrente di attrito. Un agente di coding potrebbe aver bisogno di uno snapshot del repository, strumenti di build e test nascosti. Un agente browser necessita di un'interfaccia visiva e dello stato del sito web. Un assistente personale richiede API di strumenti e verifiche specifiche per il task.

Queste configurazioni appaiono diverse a livello applicativo. Al di sotto, ciascuna richiede un ambiente isolato, un gestore del ciclo di vita, un canale di osservazione e un metodo per valutare i risultati. Il framework cerca di rendere espliciti questi requisiti condivisi.

Microsoft afferma che il servizio ha registrato in media 0,28 secondi per l'esecuzione dei comandi nei suoi test. Il documento allegato riporta anche uno stress test che coinvolge 1.000 sandbox con un tasso di successo del 100 per cento. Queste misurazioni descrivono la configurazione dei ricercatori e non dovrebbero essere considerate garanzie universali per la produzione.

L'architettura utilizza l'iniezione dell'agente a runtime, consentendo alle immagini di container specifiche per il task di rimanere separate dal servizio di controllo. Instrada inoltre le operazioni di esecuzione e sui file direttamente agli indirizzi dei pod sandbox. Il documento sostiene che ciò eviti parte dell'overhead associato ai canali di esecuzione Kubernetes.

Altri dettagli operativi rivelano quanta infrastruttura richieda l'addestramento degli agenti. Il sistema include la creazione asincrona delle sandbox, il monitoraggio della prontezza, la pulizia basata sugli heartbeat, l'isolamento di rete, i tentativi ripetuti e l'escalation delle risorse. Non sono funzionalità appariscenti, ma un guasto in una qualsiasi di esse può invalidare o bloccare un'esecuzione di addestramento.

Questa ampiezza spiega il valore di ricerca del progetto. I team che studiano diversi task per agenti possono riutilizzare lo stesso livello di controllo preservando i propri modelli, strumenti e sistemi di ricompensa. In linea di principio, gli esperimenti diventano più facili da confrontare perché tra essi cambiano meno variabili infrastrutturali.

Il framework non elimina la progettazione specializzata dei task. I ricercatori devono ancora creare ambienti validi, definire le azioni consentite, proteggere le sandbox e sviluppare valutatori significativi. Riduce l'ingegneria ripetuta attorno a queste decisioni, anziché far scomparire le decisioni stesse.

La vera pressione ricade sugli stack di addestramento specifici per il task

Orchard mette in discussione l'assunto secondo cui gli agenti per coding, browser e assistenza richiedano sistemi di addestramento end-to-end separati.

La maggior parte dei framework pubblici per agenti si concentra sull'orchestrazione. Aiutano i modelli a chiamare strumenti, scambiare messaggi, seguire workflow o coordinare più agenti. Queste capacità sono importanti per le applicazioni, ma non producono automaticamente i dati e il feedback necessari per migliorare un modello.

L'addestramento aggiunge un ulteriore livello. Un agente deve tentare task in un ambiente controllato, generare traiettorie in più passaggi, ricevere ricompense affidabili e trasformare tali interazioni in aggiornamenti del modello. Ogni fase può dipendere da software e infrastrutture differenti.

Una traiettoria è la sequenza completa di ragionamenti, azioni, risposte degli strumenti e stati dell'ambiente generata durante un task. Questi record possono diventare esempi di addestramento, ma solo quando il sistema ne preserva la struttura e determina quale comportamento sia stato utile.

La sfida si acuisce con task a orizzonte lungo. Un agente di coding potrebbe ispezionare vari file, tentare una patch, eseguire test, rivedere il proprio approccio e fallire comunque alla fine. Una semplice etichetta di successo o fallimento non spiega quali decisioni intermedie siano state utili.

La risposta del progetto è riutilizzare sia gli ambienti sia le traiettorie tra le fasi della pipeline. Lo stesso servizio di ambiente supporta la raccolta dati con modelli insegnanti, il fine-tuning supervisionato, i rollout di reinforcement learning e la valutazione finale. I ricercatori non hanno bisogno di sistemi sandbox separati per ogni fase.

Questo design contrasta con l'orchestrazione orientata alla produzione. Il separato framework applicativo per agenti di Microsoft mira alla costruzione e al deployment di agenti in Python e .NET. AutoGen ha inoltre consolidato schemi comuni per le conversazioni multi-agente e l'uso degli strumenti.

Il nuovo stack di ricerca affronta una domanda diversa: come possono i team addestrare la policy sottostante che decide cosa debba fare un agente dopo? Questa differenza impedisce un confronto diretto tra prodotti. Un framework applicativo e un ambiente di addestramento possono completarsi a vicenda.

La pressione ricade invece sulle pipeline di ricerca chiuse e verticalmente integrate. Se lo stesso livello di ambiente aperto funziona in più domini, i team hanno meno ragioni per accettare un pacchetto inseparabile di modello, harness, sandbox e valutatore.

In teoria, i gruppi di ricerca più piccoli ne traggono il maggiore beneficio. Possono iniziare da primitive di ambiente condivise e ricette pubblicate, invece di progettare un intero servizio sandbox distribuito. Possono inoltre testare modelli più piccoli su task precedentemente associati a sistemi molto più grandi.

Tuttavia, “più piccoli” resta un concetto relativo. Gestire sandbox Kubernetes, server di inferenza, modelli insegnanti e job di reinforcement learning richiede ancora una notevole profondità tecnica. Il rilascio riduce una categoria di complessità senza trasformare l'addestramento degli agenti in un normale workflow da laptop.

Le organizzazioni necessitano inoltre di una gestione disciplinata della conoscenza attorno a questi esperimenti. Traiettorie, fallimenti nelle valutazioni, modifiche alla configurazione e definizioni dei task diventano rapidamente difficili da cercare. Una base di conoscenza tecnica può preservare il ragionamento alla base dei risultati, non soltanto il punteggio finale del benchmark.

Il cambiamento strategico riguarda quindi la modularità. I ricercatori possono mantenere il proprio modello preferito e la propria interfaccia per agenti, sostituendo al contempo un backend di ambiente personalizzato. Se questo modello verrà adottato, il riuso dell'infrastruttura potrebbe diventare un'aspettativa di base per la ricerca aperta sugli agenti.

Microsoft Orchard apprende dalle parti utili dei fallimenti

L'idea più forte del framework è che un'esecuzione dell'agente non riuscita possa comunque contenere evidenze preziose per l'addestramento.

La ricetta per l'ingegneria del software, chiamata Orchard-SWE, parte da circa 107.000 traiettorie distillate da MiniMax-M2.5 e Qwen3.5-397B. Microsoft riporta che il corpus copre 2.788 repository GitHub.

Il dataset delle traiettorie del progetto descrive 107.185 record di ingegneria del software. Elenca 74.649 traiettorie risolte e 32.536 traiettorie non risolte. Un record risolto significa che la patch finale ha superato la suite di test nascosti del task.

Il fine-tuning supervisionato tradizionale privilegia gli esempi riusciti. Ciò è intuitivo perché il modello apprende a riprodurre il comportamento che ha raggiunto il risultato corretto. Tuttavia, scartare ogni traiettoria fallita può sprecare lavoro intermedio utile.

Un'esecuzione di coding fallita potrebbe individuare correttamente il modulo pertinente, identificare una condizione difettosa e scrivere la maggior parte di una patch valida. Una modifica successiva potrebbe compromettere la soluzione. Trattare l'intera traiettoria come priva di valore fa perdere i progressi precedenti.

La ricetta introduce il fine-tuning supervisionato con assegnazione del credito per recuperare questo segnale. L'assegnazione del credito significa identificare quali azioni hanno contribuito al progresso, anziché attribuire un unico esito a ogni passaggio.

Per le esecuzioni non risolte, un modello insegnante esamina l'intera traiettoria insieme al risultato finale dei test. Stima come sia cambiata la probabilità di risolvere il task dopo ogni passaggio. La pipeline seleziona quindi segmenti contigui in cui tale probabilità stimata è aumentata.

Questi segmenti in crescita diventano obiettivi supervisionati. Le osservazioni precedenti restano disponibili come contesto, mentre la loss di addestramento si concentra sui ragionamenti e sulle azioni generati dall'assistente e giudicati rappresentativi di progresso. Le risposte degli strumenti sono escluse dalla loss di previsione.

Questa tecnica non trasforma il fallimento in successo. Formula un'affermazione più circoscritta: alcune parti di un tentativo non riuscito possono insegnare a un modello come appare un'esplorazione produttiva. L'affidabilità di questo insegnamento dipende dalle stime retrospettive del modello insegnante.

La ricetta aggiunge poi il reinforcement learning, in cui il modello genera nuovi tentativi e riceve ricompense a livello di task. La parte difficile consiste nell'ottenere gruppi informativi di tentativi senza spendere la maggior parte del budget in esiti uniformi.

Se ogni tentativo riesce, il gruppo fornisce poche informazioni su quali scelte di policy siano state migliori. Lo stesso problema si verifica quando ogni tentativo fallisce. Il campionamento standard a dimensione fissa può consumare notevoli risorse computazionali generando questi gruppi a bassa varianza.

Microsoft chiama la sua alternativa Balanced Adaptive Rollout. Il metodo genera tentativi progressivamente e cerca di assemblare un gruppo di addestramento contenente un utile equilibrio tra ricompense positive e negative. Può interrompersi dopo aver individuato un gruppo informativo o proseguire entro un budget massimo fisso.

L'approccio punta all'efficienza, non soltanto all'accuratezza. Assegna più campionamenti ai prompt che richiedono ulteriori tentativi per produrre un confronto significativo. I gruppi che rimangono inadatti possono essere filtrati e rimpiazzati con altri compiti.

Il progetto riporta che un modello inizializzato da Qwen3-30B-A3B-Thinking ha raggiunto il 64,3% su SWE-bench Verified dopo il fine-tuning supervisionato. Dopo il reinforcement learning ha raggiunto il 67,5%.

SWE-bench Verified verifica se gli agenti sono in grado di risolvere problemi GitHub reali in ambienti di repository riproducibili. I punteggi dipendono dalla versione del benchmark, dall'harness, dalle impostazioni di inferenza e dalle procedure di valutazione, quindi i confronti richiedono un allineamento metodologico rigoroso.

Microsoft descrive il proprio risultato come un nuovo massimo tra i modelli aperti di dimensioni comparabili. Questa precisazione è importante. Il risultato non dimostra una superiorità rispetto a ogni sistema di agenti, in particolare rispetto ai modelli chiusi che usano budget computazionali diversi o scaffolding non divulgato.

Tuttavia, il meccanismo è più interessante della posizione in classifica. L'addestramento a partire da progressi parziali e il campionamento per ottenere variazioni informative della ricompensa sono tecniche che altri team possono testare in modo indipendente. Il loro valore non dipende interamente da un singolo punteggio riportato.

Un ambiente supporta tre agenti molto diversi

Le tre ricette verificano se il riuso dell'infrastruttura resiste ai cambiamenti di dimensione del modello, interfaccia, struttura dei compiti e progettazione della ricompensa.

La programmazione è la dimostrazione più ampia, ma non è l'unica. Orchard-GUI applica la stessa astrazione dell'ambiente a un modello vision-language da 4 miliardi di parametri che interagisce con interfacce del browser.

Secondo quanto riportato, la ricetta utilizza circa 400 traiettorie distillate e 2.200 compiti aperti. Microsoft afferma che il modello risultante ha ottenuto un tasso di successo del 74,1% su WebVoyager, del 67,0% su Online-Mind2Web e del 64,0% su DeepShop.

Questi benchmark coprono diverse forme di interazione sul web. Un agente browser deve interpretare lo stato visivo, scegliere azioni e adattarsi quando un sito web risponde. A differenza di un compito di programmazione, il successo può dipendere dalla navigazione in interfacce dinamiche anziché dalla produzione di una patch verificabile.

Il volume di dati riportato è degno di nota perché è molto inferiore al corpus di ingegneria del software. Sostiene l'argomento di Microsoft secondo cui una ricetta mirata e un ambiente stabile possono aiutare un modello più piccolo a competere senza eguagliare in numero di parametri i più grandi sistemi proprietari.

Tuttavia, il successo nei benchmark non garantisce una navigazione affidabile al di fuori della distribuzione di test. I siti web cambiano, le interfacce espongono stati ambigui e piccole differenze visive possono deviare un agente. I valutatori necessitano inoltre di una definizione precisa del completamento del compito.

La terza ricetta, Orchard-Claw, si rivolge agli agenti assistente personale. Secondo il paper, utilizza una base Qwen3-30B-A3B-Thinking e circa 200 compiti sintetici.

Microsoft riporta il 59,6% di pass@3 su Claw-Eval. Pass@3 consente all'agente fino a tre tentativi e considera il compito riuscito quando almeno un tentativo va a buon fine. Il risultato sale al 73,9% quando il modello opera con l'harness ZeroClaw più potente.

Questo divario illustra una lezione essenziale sui benchmark per agenti. Il modello è solo una parte di un sistema di agenti. La progettazione dell'harness, la formattazione degli strumenti, il comportamento dei tentativi ripetuti, la gestione del contesto e le regole di valutazione possono influire significativamente sul risultato finale.

Complica anche le affermazioni sui modelli più piccoli. Una policy compatta può funzionare bene se circondata da un'infrastruttura efficace, ma il sistema complessivo può comunque essere oneroso dal punto di vista operativo. Il numero di parametri da solo non misura il costo o la complessità di implementazione.

Insieme, le tre ricette creano un test di portabilità più credibile rispetto a tre varianti di un singolo benchmark di programmazione. Coprono testo e visione, test deterministici e interfacce aperte, oltre a diverse scale di modello.

Il livello comune non rende ogni dominio identico. Ogni ricetta conserva la propria raccolta dati, il calcolo delle ricompense, il modello di base e l'harness dell'agente. Il riuso avviene al di sotto di queste scelte specifiche del compito.

Questo confine è sensato. Un servizio di ambiente universale dovrebbe standardizzare il ciclo di vita e le primitive di comunicazione senza fingere che un compito browser e la riparazione di un repository abbiano gli stessi criteri di successo.

La questione più ampia è se i team esterni possano riprodurre questa separazione. I sistemi di ricerca interni spesso appaiono modulari nei diagrammi, ma dipendono da convenzioni non documentate, configurazioni cloud o fasi di preparazione dei dati. L'uso da parte della comunità rivelerà se le interfacce siano realmente portabili.

La rivendicazione open source deve ancora superare un test di riproducibilità

Un'architettura pubblicata e solidi risultati nei benchmark sono solo l'inizio di un rilascio di ricerca aperto.

Il paper fornisce ampi dettagli di implementazione, descrizioni algoritmiche e impostazioni sperimentali. I materiali del progetto Microsoft identificano inoltre i ricercatori, i modelli, le fonti dei compiti e i principali risultati di valutazione.

Tuttavia, l'apertura pratica presenta diversi livelli. I ricercatori hanno bisogno di codice accessibile, istruzioni di installazione, dataset compatibili, checkpoint dei modelli, immagini degli ambienti, licenze e dettagli di configurazione sufficienti per ricreare gli esperimenti.

La pagina del dataset mostra attualmente un avviso secondo cui il rilascio è sospeso e i dati saranno caricati nuovamente. Indica che lo schema documentato è accurato ma potrebbe non rappresentare la forma finale. I team dovrebbero verificare lo stato della pagina prima di progettare una pipeline attorno a essa.

Questa sospensione non invalida la ricerca. Limita però la riproducibilità immediata, in particolare per la ricetta di ingegneria del software il cui valore dipende fortemente dalla raccolta delle traiettorie.

Anche le licenze richiedono un'attenzione scrupolosa. La documentazione del dataset avverte che le traiettorie fanno riferimento a repository upstream con licenze proprie. I ricercatori che ridistribuiscono patch, materiale di test o artefatti derivati devono esaminare singolarmente tali condizioni.

La sicurezza è un altro vincolo. L'addestramento degli agenti esegue deliberatamente azioni generate dal modello. Anche gli ambienti isolati richiedono policy di rete, limiti di risorse, controlli delle credenziali, scansione delle immagini e procedure di pulizia.

Il paper descrive meccanismi di isolamento della rete e gestione dei guasti, ma ogni implementazione controlla il proprio perimetro di minaccia. Un cluster di ricerca che gestisce repository pubblici presenta rischi diversi rispetto a un ambiente aziendale che contiene codice privato o strumenti interni.

Resta difficile escludere in modo conclusivo la contaminazione dei benchmark. I modelli teacher potrebbero aver incontrato problemi pubblici, patch o codice correlato durante il pretraining. I test di valutazione nascosti riducono alcuni rischi, ma non risolvono ogni interrogativo sulla memorizzazione.

Il metodo retrospettivo di attribuzione del merito aggiunge un'altra incertezza. Un modello teacher stima se i passaggi intermedi abbiano migliorato la probabilità di successo. Tali stime sono etichette utili solo quando il teacher è in grado di interpretare in modo affidabile la traiettoria e l'esito del test.

Una stima errata può ricompensare comportamenti plausibili ma irrilevanti. Può anche trascurare un passaggio il cui valore diventa chiaro solo in seguito. Ablation study indipendenti dovrebbero verificare quanto della prestazione derivi dai dati di fallimento parziale, anziché dalla scala del modello, dalla qualità del teacher o dalla composizione del dataset.

Balanced Adaptive Rollout richiede un esame analogo. Selezionare gruppi con variazioni utili della ricompensa può migliorare l'efficienza dell'addestramento, ma i guasti reali dell'ambiente possono sembrare fallimenti della policy. Timeout, errori del container o test non funzionanti non devono trasformarsi in ricompense fuorvianti.

Microsoft riporta logiche di ripetizione dei tentativi, controlli sui timeout e filtri per gruppi inutilizzabili. I team esterni devono stabilire se tali protezioni rimangano efficaci su cluster, carichi di lavoro e distribuzioni di compiti differenti.

I numeri riportati dovrebbero quindi essere letti come evidenza a sostegno di una progettazione, non come prova definitiva di generalità. La riproduzione su infrastrutture indipendenti rafforzerebbe il caso. Risultati su nuovi domini verificherebbero se l'astrazione dell'ambiente si estenda oltre le tre ricette predisposte.

L'esito più rilevante potrebbe non essere un altro record nei benchmark. Potrebbe essere un substrato sperimentale condiviso che consente ai ricercatori di confrontare metodi di addestramento senza ricostruire l'infrastruttura alla base di ciascun esperimento.

Cosa dovrebbero osservare i ricercatori

Tre segnali determineranno se Orchard diventerà un'infrastruttura di ricerca diffusa o rimarrà un'impressionante implementazione di riferimento di Microsoft.

Il primo segnale è la completezza del rilascio. I ricercatori dovrebbero monitorare il ripristino dell'accesso al dataset, repository di codice stabili, istruzioni di installazione riproducibili, artefatti dei modelli e definizioni versionate degli ambienti.

Un rilascio completo rafforzerebbe l'affermazione di Microsoft secondo cui i team più piccoli possono riutilizzare il sistema. Lacune persistenti la indebolirebbero, perché le parti più difficili dell'addestramento degli agenti risiedono spesso nella preparazione dei dati e nella configurazione operativa.

Il secondo segnale è la riproduzione indipendente. Un test credibile userebbe le ricette pubblicate su infrastrutture gestite separatamente e riporterebbe sia i risultati dei benchmark sia i requisiti complessivi di risorse.

Replicare l'esatto punteggio principale non è l'unico risultato utile. I ricercatori dovrebbero documentare il tempo di configurazione, i tassi di fallimento della sandbox, il throughput delle traiettorie, il consumo di calcolo e la sensibilità alle scelte dell'harness. Queste misurazioni rivelano se il riuso generi risparmi significativi.

Gli esperimenti indipendenti dovrebbero inoltre isolare il contributo del fine-tuning con attribuzione del merito. I confronti possono addestrare modelli equivalenti usando soltanto traiettorie riuscite, traiettorie complete non risolte e segmenti di progresso selezionati.

Lo stesso approccio si applica ai rollout adattivi. I ricercatori possono confrontare il campionamento fisso con quello bilanciato mantenendo costanti modelli, compiti, funzioni di ricompensa e budget. Ciò mostrerebbe se il metodo produca più segnale di apprendimento per ogni traiettoria generata.

Il terzo segnale è l'adozione oltre i domini predisposti da Microsoft. Un nuovo ambiente offrirebbe il test più solido, in particolare uno con strumenti e strutture di ricompensa differenti.

L'analisi della sicurezza, il lavoro sui dati, i flussi di lavoro scientifici e le applicazioni per ufficio sono candidati plausibili. Ciascuno introduce requisiti ambientali diversi dalla riparazione di repository o dalla navigazione nel browser. Un riuso riuscito sosterrebbe l'affermazione che l'astrazione sia realmente indipendente dall'harness.

Anche le risposte dei concorrenti contano, sebbene dovrebbero rimanere prove di supporto anziché la storia principale. Altri progetti di addestramento degli agenti potrebbero adottare interfacce ambientali compatibili, pubblicare backend alternativi o standardizzare i formati delle traiettorie.

L'interoperabilità creerebbe più valore della proliferazione di framework. I ricercatori potrebbero spostare dataset, policy e valutatori tra sistemi senza tradurre ogni formato di azione e osservazione.

Nel frattempo, gli sviluppatori dovrebbero evitare di interpretare il rilascio come un agente pronto per la produzione. Il progetto è un'infrastruttura di ricerca per creare e valutare policy. I sistemi di produzione necessitano ancora di logica applicativa, autorizzazioni utente, monitoraggio, comportamenti di fallback e revisione della sicurezza.

Per gli acquirenti aziendali, la domanda rilevante non è se il framework vinca un benchmark. È se un'infrastruttura di addestramento modulare riduca la dipendenza da un singolo modello proprietario o da uno stack di valutazione controllato dal fornitore.

Per i ricercatori, il prossimo passo pratico è più circoscritto. Esaminate il paper di ricerca, verificate quali artefatti sono disponibili e scegliete una ricetta che corrisponda a un ambiente di valutazione esistente. Misurate il costo operativo insieme alle prestazioni del compito.

Microsoft ha avanzato una proposta chiara: la ricerca aperta sugli agenti migliora quando gli ambienti diventano infrastrutture riutilizzabili anziché meccanismi nascosti di progetto. Ora la comunità deve mettere alla prova la parte più difficile di questa proposta. I team indipendenti possono riprodurre i risultati, trasferire questi strumenti a nuovi compiti e preservare l’efficienza promessa al di fuori della configurazione proprietaria di Microsoft?