*Questo post è stato tradotto automaticamente. Per la versione originale, clicca qui.
Le novità sui framework di solito partono dalle funzionalità.
Questa invece è partita dalla filosofia di progettazione, e credo che sia esattamente il motivo per cui conta.
La nuova spiegazione di come Microsoft Agent Framework è strutturato attorno a agent loops, workflows e harnesses ci dà un segnale molto migliore di un’altra semplice lista di funzionalità. Ci dice come il team si aspetta che crescano le applicazioni reali.
E per chi costruisce agenti in .NET, questa è la parte davvero utile.
La maggior parte delle app agent supera molto in fretta la propria prima architettura
Si parte da una chiamata al modello.
Poi aggiungi gli strumenti.
Poi la memoria.
Poi un planner.
Poi retry, telemetria, approvazioni, agenti specializzati e un po’ di logica di workflow, perché un solo loop non basta più.
È qui che molte app AI diventano complicate. La prima versione funzionava, ma ogni nuova capacità veniva aggiunta da un livello di astrazione diverso.
Quello che mi piace del pezzo su Agent Framework è che rende espliciti i livelli:
- loops per il ciclo di esecuzione principale
- workflows per l’orchestrazione strutturata
- harnesses per le capacità runtime riutilizzabili intorno all’agente
All’inizio può sembrare accademico, ma risolve un problema molto pratico: puoi far evolvere l’app senza riscrivere il modello mentale ogni volta che diventa più complessa.
Il concetto di harness è particolarmente importante
Se dovessi scegliere un aspetto che secondo me diventerà sempre più importante, sarebbe l’idea di harness.
L’harness è il punto in cui lo sviluppo di agenti diventa ingegneria, non solo prompting.
È il livello in cui inizi a occuparti di:
- strumenti e middleware
- comportamento di pianificazione
- integrazione della memoria
- osservabilità
- controlli e governance
- comportamento runtime ripetibile
È anche per questo che il design si integra bene con il resto dello stack Microsoft. Foundry, gli strumenti di governance, gli hosted agent, le valutazioni e gli ecosistemi di strumenti hanno molto più senso quando l’involucro runtime attorno al modello viene trattato come un elemento di prima classe.
È un buon segnale per gli sviluppatori .NET
Una cosa che cerco sempre in questi ecosistemi è capire se il framework resta utile dopo la prima demo.
L’approccio a livelli suggerisce che Microsoft stia pensando all’intero percorso:
- creare un semplice agent loop
- aggiungere capacità strutturate senza caos
- passare a workflow più formali quando l’app ne ha bisogno
- mantenere il runtime abbastanza componibile da integrarsi con i sistemi aziendali
È un percorso di crescita molto più sano di: ecco un’astrazione monolitica, buona fortuna.
Ed è molto in linea con il modo in cui di solito lavorano gli sviluppatori .NET: sistemi a livelli, composizione esplicita, confini testabili e forte controllo del runtime.
La mia lettura
Questo post è facile da sottovalutare perché non presenta uno screenshot appariscente né un enorme dump di API.
Ma note architetturali come questa sono spesso un indicatore migliore di quanto un framework reggerà tra sei mesi.
Microsoft Agent Framework sta chiaramente cercando di essere più di un semplice wrapper giocattolo attorno alle chiamate al modello. La storia dell’SDK a livelli dice che il team sta costruendo per la parte difficile nel mezzo: il punto in cui gli agenti hanno bisogno di orchestrazione, strumenti, servizi runtime e disciplina da produzione.
Ed è esattamente il punto che mi interessa.
Articolo originale: ICYMI: Inside the Microsoft Agent Framework: How we designed a layered SDK
