Le demo multi-agente sono ovunque in questo momento.
Il problema è che molte si fermano proprio prima della parte che fa male nella vita reale: forma del deployment, wiring dei servizi, health, telemetria, confini runtime e il puro caos dei sistemi distribuiti.
Ecco perché il nuovo sample Aspire + Microsoft Agent Framework merita attenzione.
No, la parte interessante non è lo scenario del concierge di una stazione sciistica.
La parte interessante è che il sample mostra un pattern molto più realistico per costruire un sistema di agenti distribuito con:
- agenti hosted personalizzati
- agenti prompt
- runtime multipli
- riferimenti a servizi
- fonti dati live
- osservabilità e struttura di deployment
Questa è la vera storia.
Questo è più di “un agente che usa strumenti”
L’architettura nel sample va oltre il familiare modello a ciclo singolo dell’agente.
Hai:
- agenti specializzati con responsabilità ristrette
- agenti advisor che li orchestrano
- risorse gestite da Foundry
- servizi .NET, Python e Go nello stesso grafo
- punti di ingresso vocali e chat
Questo è molto più vicino a come i sistemi di agenti seri appariranno in pratica.
Ed è qui che Aspire diventa improvvisamente molto importante.
Aspire sta facendo la parte difficile che gli umani di solito tengono nella testa
Quello che mi piace di più qui non è nemmeno la logica dell’agente. È il fatto che il grafo dell’applicazione è esplicito.
Aspire viene usato per descrivere:
- quali servizi esistono
- da cosa dipendono
- quali deployment di modello servono
- quale runtime usa ogni servizio
- quali relazioni di health e deployment esistono
Questo conta perché i sistemi di agenti distribuiti diventano rapidamente caotici. Se la topologia esiste solo nelle teste delle persone e in documenti di setup casuali, il tuo sistema diventa fragile immediatamente.
Mettere quella topologia nell’AppHost è un enorme passo verso qualcosa di riproducibile.
Gli agenti specializzati come strumenti è ancora il pattern da osservare
Una delle mie parti preferite dell’architettura è il modo in cui gli agenti specializzati vengono presentati come capacità richiamabili per un orchestratore.
Questo pattern continua a emergere per una ragione. Ti dà:
- separazione delle preoccupazioni
- migliori confini di dominio
- osservabilità più chiara
- sostituzione più facile di uno specialista senza riscrivere tutto
Per i team .NET, questo è un modello mentale molto più sano che costruire un agente onnisciente gigante e sperare che le istruzioni del prompt lo mantengano stabile.
Il mio parere
La cosa importante che questo sample dimostra non è che le app multi-agente sono possibili. Lo sapevamo già.
Dimostra che lo stack Microsoft sta iniziando a offrire una risposta coerente alla domanda successiva:
come si costruiscono sistemi multi-agente che rimangono operabili?
Aspire per il grafo. Agent Framework per le astrazioni runtime. Foundry per risorse AI gestite e hosting. Quella combinazione sta iniziando a sembrare meno sperimentale e più una vera storia di piattaforma.
Questo è ciò che osserverei qui.
Post originale: Distributed multi-agent systems with Aspire and Microsoft Agent Framework
