Modelli di orchestrazione dell'agente di intelligenza artificiale

Man mano che architetti e sviluppatori progettano il proprio carico di lavoro per sfruttare appieno le funzionalità del modello linguistico, i sistemi degli agenti di intelligenza artificiale diventano sempre più complessi. Questi sistemi spesso superano le capacità di un singolo agente che ha accesso a molti strumenti e origini di conoscenza. Questi sistemi usano invece orchestrazioni multi-agente per gestire in modo affidabile attività complesse e collaborative. Questa guida illustra i modelli di orchestrazione fondamentali per le architetture multi-agente e consente di scegliere l'approccio più adatto ai requisiti specifici.

Informazioni generali

Quando si usano più agenti di intelligenza artificiale, è possibile suddividere i problemi complessi in unità specializzate di lavoro o conoscenza. Ogni attività viene assegnata agli agenti di intelligenza artificiale dedicati con funzionalità specifiche. Questi approcci rispecchiano le strategie trovate nel lavoro di squadra umano. L'uso di più agenti offre diversi vantaggi rispetto alle soluzioni monolitiche a agente singolo.

• Specializzazione: I singoli agenti possono concentrarsi su un dominio o una funzionalità specifica, riducendo il codice e la complessità della richiesta.

• Scalabilità: Gli agenti possono essere aggiunti o modificati senza riprogettare l'intero sistema.

• Manutenibilità: Il test e il debug possono essere incentrati su singoli agenti, riducendo la complessità di queste attività.

• Ottimizzazione: Ogni agente può usare modelli distinti, approcci di risoluzione delle attività, conoscenze, strumenti e calcolo per ottenere i risultati.

I modelli in questa guida illustrano approcci collaudati per orchestrare più agenti per lavorare insieme e ottenere un risultato. Ogni modello è ottimizzato per diversi tipi di requisiti di coordinamento. Questi modelli di orchestrazione dell'agente di intelligenza artificiale integrano ed estendono i modelli di progettazione cloud tradizionali risolvendo le sfide uniche del coordinamento dei componenti autonomi nelle funzionalità dei carichi di lavoro basate sull'intelligenza artificiale.

Orchestrazione sequenziale

Il modello di orchestrazione sequenziale concatena gli agenti di intelligenza artificiale in un ordine lineare predefinito. Ogni agente elabora l'output dell'agente precedente nella sequenza, che crea una pipeline di trasformazioni specializzate.

L'immagine mostra diverse sezioni con frecce e linee di connessione. Una freccia punta dall'Input all'Agente 1. Una riga collega l'Agente 1 a una sezione che riporta Modello, conoscenza e strumenti. Una freccia punta da Agente 1 ad Agente 2. Una linea connette l'Agente 2 a una sezione intitolata Modello, conoscenze e strumenti. Una freccia punta da agente 2 a una scatola con ellissi. Una freccia punta da questa casella all'Agente n. Una riga connette Agent n a una sezione che legge Modelli, conoscenze e strumenti. Freccia punta da Agent n a Result. Una sezione che descrive lo Stato Comune si estende dalla sezione Agent 1 fino alla sezione Agent n.

Il modello di orchestrazione sequenziale risolve i problemi che richiedono l'elaborazione dettagliata, in cui ogni fase si basa sulla fase precedente. Si adatta ai flussi di lavoro che hanno dipendenze chiare e migliorano la qualità dell'output attraverso il perfezionamento progressivo. Questo modello è simile al modello di progettazione cloud Pipe e Filtri , ma usa agenti di intelligenza artificiale anziché componenti di elaborazione codificati personalizzati. La scelta di quale agente viene richiamato successivamente è definita in modo deterministico come parte del flusso di lavoro e non è una scelta concessa agli agenti nel corso del processo.

Quando usare l'orchestrazione sequenziale

Prendere in considerazione il modello di orchestrazione sequenziale negli scenari seguenti:

• Processi multistage con dipendenze lineari chiare e avanzamento prevedibile del flusso di lavoro

• Pipeline di trasformazione dei dati, in cui ogni fase aggiunge un valore specifico da cui dipende la fase successiva

• Fasi del flusso di lavoro che non possono essere parallelizzate

• Requisiti di perfezionamento progressivo, come i flussi di lavoro di bozza, revisione e rifinitura

• Sistemi in cui si conoscono le caratteristiche di disponibilità e prestazioni di ogni agente di intelligenza artificiale nella pipeline e dove errori o ritardi nell'elaborazione di un agente di intelligenza artificiale sono tollerabili per l'attività complessiva da eseguire

Quando evitare l'orchestrazione sequenziale

Evitare questo modello negli scenari seguenti:

• Le fasi sono imbarazzanti parallele. È possibile parallelizzarli senza compromettere la qualità o creare conflitti di stato condivisi.

• Processi che includono solo alcune fasi che un singolo agente di intelligenza artificiale può eseguire in modo efficace.

• Le fasi iniziali potrebbero non riuscire o produrre output di bassa qualità e non esiste un modo ragionevole per evitare che i passaggi successivi vengano elaborati usando l'output degli errori accumulato.

• Gli agenti di intelligenza artificiale devono collaborare invece di consegnare il lavoro.

• Il flusso di lavoro richiede il backtracking o l'iterazione.

• È necessario eseguire il routing dinamico in base ai risultati intermedi.

Esempio di orchestrazione sequenziale

Un software di gestione dei documenti di uno studio legale usa agenti sequenziali per la generazione di contratti. L'applicazione intelligente elabora le richieste tramite una pipeline di quattro agenti specializzati. I passaggi sequenziali e predefiniti della pipeline assicurano che ogni agente funzioni con l'output completo della fase precedente.

L'immagine mostra diverse sezioni con frecce e linee di connessione. Una freccia punta dai requisiti di creazione dei documenti agli agenti di selezione modelli. Una riga connette l'agente della sezione Modello a una sezione che include modello, libreria di modelli e strumenti di ricerca. Una freccia punta dall'agente di selezione modello all'agente di personalizzazione clausola. Una riga collega l'agente di personalizzazione della clausola a una sezione etichettata come Modello Ottimizzato. Una freccia punta dall'agente di personalizzazione della clausola all'agente di conformità alle normative. Una riga connette l'agente di conformità alle normative a una sezione che dice Modello, conoscenze sulle conformità. Una freccia punta dall'agente di conformità alle normative all'agente di valutazione dei rischi. Una riga connette l'agente di valutazione dei rischi a una sezione con la dicitura strumenti di modellazione, competenza in responsabilità e strumenti di persistenza. Una freccia punta dall'agente di valutazione dei rischi a una sezione che legge il documento proposto. Una sezione che riguarda lo stato del documento collega l'agente di personalizzazione delle clausole alla sezione Documento proposto.

1. L'agente di selezione del modello riceve specifiche del cliente, ad esempio il tipo di contratto, la giurisdizione e le parti coinvolte, e seleziona il modello di base appropriato dalla libreria dell'azienda.

2. L'agente di personalizzazione della clausola accetta il modello selezionato e modifica le clausole standard in base alle condizioni aziendali negoziate, incluse le pianificazioni dei pagamenti e le limitazioni di responsabilità.

3. L'agente di conformità alle normative esamina il contratto personalizzato in base alle leggi applicabili e alle normative specifiche del settore.

4. L'agente di valutazione dei rischi esegue un'analisi completa del contratto completo. Valuta i meccanismi di esposizione della responsabilità e risoluzione delle controversie, fornendo al tempo stesso valutazioni dei rischi e raccomandazioni del linguaggio protettivo.

Orchestrazione simultanea

Il modello di orchestrazione simultanea esegue più agenti di intelligenza artificiale contemporaneamente nella stessa attività. Questo approccio consente a ogni agente di fornire analisi o elaborazione indipendenti dalla sua prospettiva o specializzazione univoca.

L'immagine contiene tre sezioni chiave. Nella sezione superiore, una freccia indica il passaggio da Input all'agente iniziatore e al raccoglitore. Una freccia punta dall'agente iniziatore e agente di raccolta a una sezione che legge i risultati aggregati in base ai risultati combinati, confrontati e selezionati. Una linea collega l'agente iniziatore e l'agente collettore a una linea che si connette a quattro sezioni mediante frecce. Queste sezioni sono Agent 1, Agent 2, una sezione senza etichetta con puntini di sospensione e Agent n. Una freccia punta da Agente 1 a Risultato intermedio. Una linea parte da Agente 1 e si suddivide in due flussi. Il primo flusso mostra una sezione Sub agent 1.1 e una sezione che recita Modello, conoscenza e strumenti. Il secondo flusso mostra un sub agente 1.2 e una sezione che legge Modello, conoscenza e strumenti. Una freccia punta da Agente 2 a Risultato intermedio. Una linea connette l'Agente 2 a una sezione intitolata Modello, conoscenze e strumenti. Una freccia punta dalla sezione senza etichetta che include ellissi ai risultati intermedi. Una freccia punta da Agente n al Risultato intermedio. Una riga connette Agent n a una sezione che legge Modelli, conoscenze e strumenti.

Questo modello risolve gli scenari in cui sono necessarie informazioni dettagliate o approcci diversi allo stesso problema. Anziché l'elaborazione sequenziale, tutti gli agenti funzionano in parallelo, riducendo così il tempo di esecuzione complessivo e offre una copertura completa dello spazio dei problemi. Questo modello di orchestrazione è simile al modello di progettazione cloud Fan-out/Fan-in. I risultati di ogni agente vengono spesso aggregati per restituire un risultato finale, ma non è obbligatorio. Ogni agente può produrre in modo indipendente i propri risultati all'interno del carico di lavoro, ad esempio richiamare gli strumenti per eseguire attività o aggiornare archivi dati diversi in parallelo.

Gli agenti operano in modo indipendente e non consegnano i risultati l'uno all'altro. Un agente potrebbe richiamare agenti di intelligenza artificiale aggiuntivi usando il proprio approccio di orchestrazione nell'ambito dell'elaborazione indipendente. Gli agenti disponibili devono conoscere quali agenti sono disponibili per l'elaborazione. Questo modello supporta entrambe le chiamate deterministiche a tutti gli agenti registrati e la selezione dinamica degli agenti da richiamare in base ai requisiti dell'attività.

Quando usare l'orchestrazione simultanea

Prendere in considerazione il modello di orchestrazione simultanea negli scenari seguenti:

• Attività che è possibile eseguire in parallelo, usando un set fisso di agenti o scegliendo in modo dinamico gli agenti di intelligenza artificiale in base a requisiti di attività specifici.

• Attività che traggono vantaggio da più prospettive indipendenti o diverse specializzazioni, ad esempio approcci tecnici, aziendali e creativi, che possono tutti contribuire allo stesso problema. Questa collaborazione si verifica in genere in scenari che presentano le tecniche di processo decisionale multi-agente seguenti:

  • Brainstorming

  • Ragionamento dell'insieme

  • Decisioni basate su quorum e voto

• Scenari sensibili al tempo in cui l'elaborazione parallela riduce la latenza.

Quando evitare l'orchestrazione simultanea

Evitare questo modello di orchestrazione negli scenari seguenti:

• Gli agenti devono basarsi sul lavoro dell'altro o richiedere un contesto cumulativo in una sequenza specifica.

• L'attività richiede un ordine specifico di operazioni o risultati deterministici riproducibili dall'esecuzione in una sequenza definita.

• I vincoli delle risorse, ad esempio la quota del modello, rendono l'elaborazione parallela inefficiente o impossibile.

• Gli agenti non possono coordinare in modo affidabile le modifiche apportate allo stato condiviso o ai sistemi esterni durante l'esecuzione simultanea.

• Non esiste una strategia chiara di risoluzione dei conflitti per gestire risultati contraddittori o in conflitto da ogni agente.

• La logica di aggregazione dei risultati è troppo complessa o riduce la qualità dei risultati.

Esempio di orchestrazione simultanea

Una società di servizi finanziari ha creato un'applicazione intelligente che usa agenti simultanei specializzati in diversi tipi di analisi per valutare contemporaneamente lo stesso titolo. Ogni agente contribuisce a ottenere informazioni dettagliate dal suo punto di vista specializzato, che fornisce input diversificati e sensibili al tempo per decisioni rapide sugli investimenti.

L'immagine contiene tre sezioni chiave. Nella sezione superiore, una freccia punta dal simbolo Ticker all'agente di analisi delle azioni. Una connessione collega la mappatura dei simboli di borsa all'agente di analisi del mercato azionario. Una freccia punta dall'agente di analisi delle scorte a una sezione che legge Decisione con prove di supporto in base ai risultati intermedi combinati. Una linea connette l'agente di analisi delle azioni a una linea che collega quattro sezioni separate. Queste sezioni sono quattro flussi separati: Agente di Analisi Fondamentale, Agente di Analisi Tecnica, Agente di Analisi del Sentiment e Agente ESG. Una riga connette Model al flusso dell'agente di analisi fondamentale. Una freccia punta dal flusso dell'agente di analisi fondamentale al risultato intermedio. Una linea parte dal flusso dell'agente di analisi fondamentale e si divide in due flussi: agente di analisi finanziaria e dei ricavi e agente di analisi della concorrenza. Una riga connette Financials e l'agente di analisi dei ricavi a una sezione intitolata il Modello, informazioni finanziarie segnalate. Una linea connette l'agente di analisi competitiva a una sezione che riporta "Modello, conoscenza competitiva". Una freccia punta dall'agente di analisi tecnica al risultato intermedio. Una riga collega l'agente di analisi tecnica a una sezione che riporta modello ottimizzato, API di mercato. Una freccia punta dall'agente di analisi del sentiment al risultato intermedio. Una riga connette l'agente di analisi del sentiment a una sezione che legge Modello, API social e API di notizie. Una freccia punta dall'agente ESG al risultato intermedio. Una linea collega l'agente ESG a una sezione che legge Modello, conoscenza ESG.

Il sistema elabora le richieste di analisi delle azioni trasmettendo lo stesso simbolo ticker a quattro agenti specializzati che operano in parallelo.

• L'agente di analisi fondamentale valuta i rendiconti finanziari, le tendenze dei ricavi e il posizionamento competitivo per valutare il valore intrinseco.

• L'agente di analisi tecnica esamina i modelli di prezzo, gli indicatori di volume e i segnali di slancio per identificare le opportunità di trading.

• L'agente di analisi del sentiment elabora articoli di notizie, menzioni di social media e report analista per misurare il sentiment di mercato e la fiducia degli investitori.

• L'agente ambientale, sociale e di governance (ESG) esamina l'impatto ambientale, la responsabilità sociale e i rapporti sulle pratiche di governance per valutare i rischi e le opportunità di sostenibilità.

Questi risultati indipendenti vengono quindi combinati in una raccomandazione completa sugli investimenti, che consente ai gestori di portafoglio di prendere decisioni informate rapidamente.

Gestione chat di gruppo

Il modello di orchestrazione di chat di gruppo consente a più agenti di risolvere i problemi, prendere decisioni o convalidare il lavoro partecipando a un thread di conversazione condiviso in cui collaborano tramite discussione. Un gestore di chat coordina il flusso determinando quali agenti possono rispondere e gestendo diverse modalità di interazione, dal brainstorming collaborativo ai controlli di qualità strutturati.

L'immagine mostra diverse sezioni con frecce e linee di connessione. Una freccia punta da Input a Group Chat Manager. Una freccia inizia in Model, passa attraverso Gestione chat di gruppo e punta ad Accumulazione thread di chat. Una sezione sotto questa riga contiene le istruzioni del gruppo nuovo sulla base del contesto accumulato. Una riga si connette a una sezione che riporta la dicitura partecipante o osservatore della chat umana. Una freccia punta da Gestione chat di gruppo a Agent 2. Una freccia doppia connette l'Agente 1, una casella senza etichetta con puntini di sospensione, e l'Agente n. Una riga connette Agent 1, Agent 2, la casella senza etichetta e Agent n. Una linea collega l'Agente 1 al Modello e alla conoscenza. Una riga connette Agent 2 a Model e conoscenza. Una riga connette l'agente n al modello e alla conoscenza. Una freccia punta da una sezione che riporta l'output della chat dagli agenti alla sezione Thread di chat in accumulo. Una linea collega il flusso continuo di chat al Risultato.

Questo modello risolve gli scenari che vengono eseguiti al meglio tramite la discussione di gruppo per prendere decisioni. Questi scenari possono includere processi di ideazione collaborativa, convalida strutturata o controllo qualità. Il modello supporta diverse modalità di interazione, dal brainstorming in flusso libero ai flussi di lavoro di revisione formale con ruoli fissi e controlli di approvazione.

Questo modello funziona bene per gli scenari umani nel ciclo in cui gli esseri umani possono facoltativamente assumere responsabilità di gestione delle chat dinamiche e guidare le conversazioni verso i risultati produttivi. In questo modello di orchestrazione, gli agenti sono in genere in modalità di sola lettura . Non usano strumenti per apportare modifiche ai sistemi in esecuzione.

Quando utilizzare l'orchestrazione delle chat di gruppo

Prendere in considerazione l'orchestrazione di chat di gruppo quando lo scenario può essere risolto tramite la collaborazione spontanea o guidata o i cicli iterativi del controllo degli autori. Tutti questi approcci supportano la supervisione o la partecipazione umana in tempo reale. Poiché tutti gli agenti e gli esseri umani nel ciclo generano l'output in un singolo thread di accumulo, questo modello offre trasparenza e controllabilità.

Scenari di collaborazione

• Sessioni creative di brainstorming in cui gli agenti con prospettive e fonti di conoscenza diverse si basano sui contributi degli altri alla chat

• Processi decisionali che traggono vantaggio dal dibattito e dalla costruzione del consenso

• Scenari decisionali che richiedono perfezionamento iterativo tramite discussione

• Problemi multidisciplinari che richiedono un dialogo interfunzionale

Scenari di convalida e controllo qualità

• Requisiti di controllo della qualità che coinvolgono processi di revisione strutturati e iterazione

• Conformità e convalida delle normative che richiedono più prospettive di esperti

• Flussi di lavoro di creazione del contenuto che richiedono una revisione editoriale con una netta separazione delle problematiche tra la creazione e la convalida

Quando evitare l'orchestrazione di chat di gruppo

Evitare questo modello negli scenari seguenti:

• La delega di attività semplice o l'elaborazione lineare della pipeline è sufficiente.

• I requisiti di elaborazione in tempo reale rendono inaccettabile il sovraccarico della discussione.

• I flussi di lavoro gerarchici o deterministici chiari senza discussione sono più appropriati.

• Il gestore di chat non ha alcun modo obiettivo per determinare se l'attività è stata completata.

La gestione del flusso di conversazione e la prevenzione di cicli infiniti richiedono un'attenzione attenta, soprattutto perché più agenti rendono il controllo più difficile da gestire. Per mantenere un controllo efficace, è consigliabile limitare l'orchestrazione di chat di gruppo a tre o meno agenti.

Ciclo di creazione e verifica

Il ciclo maker-checker è un tipo specifico di orchestrazione di chat di gruppo in cui un agente, l'autore, crea o propone qualcosa. Un altro agente, il verificatore, fornisce un'analisi del risultato. Questo modello è iterativo, con l'agente di controllo che rimanda la conversazione all'agente creatore per aggiornare e ripetere il processo. Anche se il modello di chat di gruppo non richiede che gli agenti si alternino nella chat, il ciclo maker-checker richiede una sequenza formale basata su turni che il gestore della chat guida.

Esempio di orchestrazione di chat di gruppo

Un reparto parchi cittadini e ricreazione usa software che include orchestrazione chat di gruppo per valutare nuove proposte di sviluppo del parco. Il software legge la proposta bozza e più agenti specializzati discetono diverse prospettive di impatto della comunità e lavorano verso il consenso sulla proposta. Questo processo si verifica prima dell'apertura della proposta per la revisione della community per anticipare il feedback che potrebbe ricevere.

L'immagine mostra diverse sezioni con frecce e linee di connessione. Una freccia punta dalla proposta di sviluppo Park al responsabile della chat di gruppo. Una riga inizia da Model, passa attraverso Gestore chat di gruppo e punta ad Accumulo di conversazioni. Una linea collega l'impiegato del Dipartimento dei Parchi a questa linea. Una sezione che presenta le istruzioni in base al contesto accumulato e alle nuove intuizioni si trova sotto questa sezione. Una freccia punta dal responsabile della chat di gruppo all'agente di pianificazione ambientale. Una freccia a doppia punta collega l'agente di coinvolgimento della comunità e l'agente per il budget e le operazioni dei parchi. Una linea collega l'agente di engagement della Community all'agente di pianificazione ambientale e all'agente di budget e operazioni parchi. Una riga connette l'agente di coinvolgimento della comunità a una sezione che legge il modello e la conoscenza civica. Una riga connette l'agente di pianificazione ambientale a una sezione che specifica il modello e la conoscenza ambientale locale. Una freccia connette una sezione che legge l'output della chat dagli agenti civici alla conversazione accumulata. Una linea connette la conversazione accumulando al consenso della proposta di Park. Una riga connette l'agente di parchi di budget e operazioni a una sezione che indica le conoscenze del modello e della città.

Il sistema elabora le proposte di sviluppo del parco avviando una consultazione di gruppo con agenti municipali specializzati che si impegnano nel compito da più prospettive civiche.

• L'agente di engagement della community valuta i requisiti di accessibilità, i feedback residenti previsti e i modelli di utilizzo per garantire un accesso equo alla community.

• L'agente di pianificazione ambientale valuta l'impatto ecologico, le misure di sostenibilità, lo spostamento della vegetazione nativa e la conformità alle normative ambientali.

• L'agente di budget e operazioni analizza i costi di costruzione, le spese di manutenzione in corso, i requisiti di personale e la sostenibilità operativa a lungo termine.

Il manager della chat facilita il dibattito strutturato in cui gli agenti sfidano le raccomandazioni degli altri e difendono il loro ragionamento. Un dipendente del reparto parchi partecipa al thread di chat per aggiungere informazioni dettagliate e rispondere alle richieste di informazioni degli agenti in tempo reale. Questo processo consente al dipendente di aggiornare la proposta originale per risolvere i problemi identificati e prepararsi meglio per il feedback della community.

Orchestrazione del trasferimento

Il modello di orchestrazione handoff consente la delega dinamica delle attività tra agenti specializzati. Ogni agente può valutare l'attività e decidere se gestirla direttamente o trasferirla a un agente più appropriato in base al contesto e ai requisiti.

L'immagine mostra cinque sezioni chiave. La sezione Agente 1 include un input, un modello e una sezione di conoscenze generali, e un risultato. La sezione Agent 2 include una sezione relativa ai risultati e al modello e alla knowledge base. La sezione Agent 3 include la sezione modello, informazioni e strumenti, un risultato e una sezione senza etichetta che si connette a un risultato. La sezione Agent n include un modello, una sezione di conoscenza e un risultato. La sezione Customer Support Employee (Dipendente supporto clienti) include un risultato. Le frecce curve passano dall'agente all'agente e al dipendente del supporto clienti.

Questo modello risolve gli scenari in cui l'agente ottimale per un'attività non è noto in anticipo o in cui i requisiti dell'attività diventano chiari solo durante l'elaborazione. Consente il routing intelligente e garantisce che le attività raggiungano l'agente più idoneo. Gli agenti in questo modello in genere non funzionano in parallelo. Il controllo completo viene trasferito da un agente a un altro.

Quando usare l'orchestrazione del trasferimento

Prendere in considerazione il modello di handoff dell'agente negli scenari seguenti:

• Attività che richiedono conoscenze o strumenti specializzati, ma in cui il numero di agenti necessari o il relativo ordine non può essere predeterminato

• Scenari in cui i requisiti di competenza emergono durante l'elaborazione, con conseguente routing di attività dinamiche basato sull'analisi del contenuto

• Problemi a più domini che richiedono specialisti diversi che operano uno alla volta

• Relazioni logiche e segnali che puoi predeterminare per indicare quando un agente raggiunge il suo limite di capacità e quale agente debba gestire l'attività successiva.

Quando evitare l'orchestrazione del passaggio

Evitare questo modello negli scenari seguenti:

• Gli agenti appropriati e il loro ordine sono sempre noti in anticipo.

• Il routing delle attività è semplice e deterministico basato su regole, non basato sulla finestra di contesto dinamica o sull'interpretazione dinamica.

• Le decisioni di routing non ottimali possono causare un'esperienza utente scarsa o frustrante.

• Più operazioni devono essere eseguite contemporaneamente per risolvere l'attività.

• Evitare un ciclo di handoff infinito o evitare un rimbalzo eccessivo tra gli agenti è impegnativo.

Esempio di modello di trasferimento dell'agente

Una soluzione CRM (Telecommunications Customer Relationship Management) usa agenti di handoff nel portale Web del supporto clienti. Un agente iniziale inizia ad aiutare i clienti, ma scopre che ha bisogno di competenze specializzate durante la conversazione. L'agente iniziale passa l'attività all'agente più appropriato per risolvere il problema del cliente. Solo un agente alla volta opera sull'input originale e la catena di trasferimento restituisce un singolo risultato.

L'immagine include cinque sezioni chiave. La sezione Triage support agent include una sezione modello, una sezione di conoscenza generale, un input e un risultato. La sezione Agente infrastruttura tecnica include un risultato e una sezione modello, conoscenza dell'infrastruttura e strumenti. La sezione Agente di risoluzione finanziaria include un modello, informazioni sull'account di fatturazione, una sezione di accesso all'API di fatturazione e un risultato. La sezione Agente di accesso all'account include un risultato e una sezione di conoscenza del modello e del cliente. La sezione Customer Support Employee (Dipendente supporto clienti) include un risultato. Le frecce curve fluiscono da un agente all'altro e arrivano al dipendente del supporto clienti.

In questo sistema, l'agente di supporto per la valutazione interpreta la richiesta e tenta di gestire direttamente i problemi comuni. Quando raggiunge i suoi limiti, consegna problemi di rete a un agente dell'infrastruttura tecnica, controversie di fatturazione a un agente di risoluzione finanziaria e così via. Gli altri handoff si verificano all'interno di tali agenti quando l'agente corrente riconosce i propri limiti di capacità e sa che un altro agente può supportare meglio lo scenario.

Ogni agente è in grado di completare la conversazione se determina che il successo del cliente è stato ottenuto o che nessun altro agente può trarre ulteriore vantaggio dal cliente. Alcuni agenti sono progettati anche per distribuire l'esperienza utente a un agente di supporto umano quando il problema è importante da risolvere, ma nessun agente di intelligenza artificiale ha attualmente le funzionalità per risolverlo.

Un esempio di istanza di passaggio è evidenziato nello schema. Inizia con l'agente di triage che consegna l'attività all'agente dell'infrastruttura tecnica. L'agente dell'infrastruttura tecnica decide quindi di consegnare l'attività all'agente di risoluzione finanziaria, che in definitiva reindirizza l'attività al supporto clienti.

Orchestrazione magnetica

Il modello di orchestrazione magentico è progettato per problemi aperti e complessi che non hanno un piano di approccio predeterminato. Gli agenti in questo modello in genere dispongono di strumenti che consentono di apportare modifiche dirette nei sistemi esterni. L'attenzione riguarda la creazione e la documentazione dell'approccio per risolvere il problema in quanto riguarda l'implementazione di tale approccio. L'elenco di attività viene compilato e perfezionato dinamicamente come parte del flusso di lavoro tramite la collaborazione tra agenti specializzati e un agente di gestione magentico. Man mano che il contesto si evolve, l'agente manager magentico crea un libro mastro attività per sviluppare il piano di approccio con obiettivi e sottogoali, che alla fine viene finalizzato, seguito e monitorato per completare il risultato desiderato.

L'immagine mostra una sezione agente manager. Include l'input e un modello. Una freccia con etichetta Richiama gli agenti punta dall'agente manager a Agent 2. Una freccia con etichetta "Evaluate goal loop" punta alla sezione "Task complete". Una freccia con etichetta Sì punta alla sezione Risultati e una freccia con l'etichetta No punta all'agente manager. Una freccia punta dall'agente Manager alla sezione attività e registro dei progressi. Una riga collega la sezione Task and progress ledger alla sezione Partecipante umano. Una riga con tre frecce che puntano a Agente 1, Agente 2, una sezione senza etichetta e Agente n. Una riga connette Agente 1 a una sezione con la scritta Modello e conoscenza. Una linea connette l'Agente 2 a una sezione intitolata Modello, conoscenze e strumenti. Una riga connette Agent n a Model e agli strumenti. Una freccia punta dalla sezione che recita Modello, conoscenze e strumenti a Sistemi esterni e dalla sezione Modello e strumenti a Sistemi esterni.

L'agente manager comunica direttamente con gli agenti specializzati per raccogliere informazioni mentre costruisce e affina il registro delle attività. Itera, arretra e delega quante volte necessario per sviluppare un piano completo che possa eseguire con successo. L'agente di gestione valuta spesso se la richiesta originale è pienamente soddisfatta o se si è arenata. Aggiorna il registro per aggiustare il piano.

In alcuni modi, questo modello di orchestrazione è un'estensione del modello di chat di gruppo . Il modello di orchestrazione magentica è incentrato su un agente che crea un piano di approccio, mentre altri agenti usano strumenti per apportare modifiche nei sistemi esterni anziché usare solo gli archivi conoscenze per raggiungere un risultato.

Quando usare l'orchestrazione magnetica

Si consideri il modello magentico negli scenari seguenti:

• Caso d'uso complesso o aperto senza percorso di soluzione predeterminato.

• Requisito di considerare l'input e il feedback di più agenti specializzati per sviluppare un percorso di soluzione valido.

• Un requisito per il sistema di intelligenza artificiale per generare un piano di approccio completamente sviluppato che un essere umano può esaminare prima o dopo l'implementazione.

• Gli agenti dotati di strumenti che interagiscono con sistemi esterni, utilizzano risorse esterne o possono indurre modifiche nei sistemi in esecuzione. Un piano documentato che mostra come questi agenti vengono sequenziati può essere presentato a un utente prima di consentire agli agenti di seguire le attività.

Quando evitare l'orchestrazione magnetica

Evitare questo modello negli scenari seguenti:

• Il percorso della soluzione viene sviluppato o deve essere affrontato in modo deterministico.

• Non è necessario produrre un libro mastro.

• L'attività presenta una bassa complessità e un modello più semplice può risolverlo.

• Il lavoro è sensibile al tempo, poiché il modello è incentrato sulla creazione e la discussione di piani validi, non sull'ottimizzazione per i risultati finali.

• Si prevedono blocchi frequenti o cicli infiniti che non hanno un percorso chiaro per la risoluzione.

Esempio di orchestrazione magentica

Un team SRE (Site Reliability Engineering) ha creato l'automazione che usa l'orchestrazione magentica per gestire scenari di risposta agli eventi imprevisti a basso rischio. Quando si verifica un'interruzione del servizio nell'ambito dell'automazione, il sistema deve creare e implementare in modo dinamico un piano di correzione. Questa operazione viene eseguita senza conoscere i passaggi specifici necessari in anticipo.

L'immagine mostra la sezione agente di Gestione automazione SRE che include input e un modello. Una freccia punta dall'agente di gestione automazione SRE alla sezione registro delle attività e dei progressi. Una freccia con etichetta Invoca agenti di conoscenza e azione punta a una linea che conduce agli agenti Infrastructure, Diagnostics, Rollback e Communication. Una freccia etichettata Valuta ciclo obiettivo punta dall'agente del gestore dell'automazione SRE alla sezione Risoluzione problemi sito attivo. Una freccia con l'etichetta 'Sì' punta da Problema live-site risolto a Risultato. La sezione Registro delle attività e dei progressi include un piano di risoluzione, gli stati delle attività di risoluzione e la sezione Problema risolto sul sito live. Una freccia etichettata "No" punta dal problema live-site all'agente di gestione dell'automazione SRE. Una linea inizia dall'agente diagnostico, passa attraverso la sezione dedicata alla conoscenza del modello, dei log e delle metriche, e punta ai sistemi di gestione del carico di lavoro. Una linea inizia dall'agente dell'infrastruttura, passa attraverso la sezione relativa al modello, alla conoscenza dei grafi e agli strumenti della CLI e si unisce alla linea che punta ai sistemi del carico di lavoro. Una riga inizia dall'agente di rollback, passa attraverso il modello, l'accesso Git, la sezione degli strumenti CLI e punta ai sistemi di gestione del carico di lavoro. Una linea inizia presso l'agente di comunicazione, attraversa la sezione di accesso alle API del modello e della comunicazione, e punta alla sezione del partecipante umano.

Quando l'automazione rileva un incidente qualificato, l'agente di gestione magnetico inizia creando un registro di attività iniziali con obiettivi di alto livello, come il ripristino della disponibilità del servizio e l'identificazione della causa principale. L'agente manager consulta quindi gli agenti specializzati per raccogliere informazioni e perfezionare il piano di correzione.

1. L'agente di diagnostica analizza i log di sistema, le metriche delle prestazioni e i modelli di errore per identificare le possibili cause. Riporta i risultati all'agente manager.

2. In base ai risultati di diagnostica, l'agente manager aggiorna il libro mastro delle attività con passaggi di indagine specifici e consulta l'agente dell'infrastruttura per comprendere lo stato corrente del sistema e le opzioni di ripristino disponibili.

3. L'agente di comunicazione fornisce funzionalità di notifica agli stakeholder e l'agente manager incorpora checkpoint di comunicazione e fasi di approvazione nel piano in evoluzione in base alle procedure di escalation del team SRE.

4. Man mano che lo scenario diventa più chiaro, l'agente manager potrebbe aggiungere l'agente di rollback al piano se è necessario il ripristino della distribuzione o escalare ai tecnici SRE umani se l'incidente esce dall'ambito dell'automazione.

Durante questo processo, l'agente manager affina continuamente il libro mastro delle attività in base alle nuove informazioni. Aggiunge, rimuove o riordina le attività man mano che l'evento imprevisto si evolve. Ad esempio, se l'agente di diagnostica individua un problema di connessione al database, l'agente di gestione potrebbe passare da una strategia di rollback della distribuzione a un piano incentrato sul ripristino della connettività del database.

L'agente manager controlla gli stalli eccessivi nel ripristino del servizio e protegge da cicli di correzione infiniti. Gestisce un audit trail completo del piano in evoluzione e dei passaggi di implementazione, che fornisce trasparenza per la revisione post-evento imprevisto. Questa trasparenza garantisce che il team SRE possa migliorare sia il carico di lavoro che l'automazione in base alle lezioni apprese.

Considerazioni sull'implementazione

Quando si implementa uno di questi modelli di progettazione dell'agente, è necessario tenere presenti alcune considerazioni. La revisione di queste considerazioni consente di evitare insidie comuni e assicura che l'orchestrazione dell'agente sia affidabile, sicura e gestibile.

Singolo agente, utensile multifunzione

È possibile risolvere alcuni problemi con un singolo agente se si concede l'accesso sufficiente agli strumenti e alle origini delle conoscenze. Man mano che aumenta il numero di origini di conoscenza e strumenti, diventa difficile offrire un'esperienza prevedibile dell'agente. Se un singolo agente può risolvere in modo affidabile lo scenario, prendere in considerazione l'adozione di tale approccio. Il processo decisionale e il sovraccarico del controllo del flusso spesso superano i vantaggi di suddividere l'attività tra più agenti. Tuttavia, i limiti di sicurezza, la linea di rete e altri fattori possono comunque rendere infeasible un approccio a agente singolo.

Routing deterministico

Alcuni modelli richiedono di instradare il flusso tra gli agenti in modo deterministico. Altri si basano sugli agenti per scegliere le proprie route. Se gli agenti sono definiti in un ambiente senza codice o con poco codice, è possibile non controllare tali comportamenti. Se si definiscono gli agenti nel codice usando SDK come Microsoft Agent Framework o Semantic Kernel, si ha più controllo.

Finestra di contesto

Gli agenti di intelligenza artificiale hanno spesso finestre di contesto limitate. Questo vincolo può influire sulla capacità di elaborare attività complesse. Quando si implementano questi modelli, decidere quale contesto il prossimo agente richiede per essere efficace. In alcuni scenari è necessario il contesto non elaborato completo raccolto finora. In altri scenari, una versione riepilogata o troncata è più appropriata. Se l'agente può funzionare senza contesto accumulato e richiede soltanto un nuovo set di istruzioni, adottare questo approccio anziché fornire un contesto che non aiuta a svolgere il compito dell'agente.

Affidabilità

Questi modelli richiedono agenti funzionanti correttamente e transizioni affidabili tra di esse. Spesso generano problemi di sistemi distribuiti classici, ad esempio errori dei nodi, partizioni di rete, perdita di messaggi ed errori a catena. Le strategie di mitigazione devono essere adottate per affrontare queste sfide. Gli agenti e i relativi orchestratori devono eseguire i passaggi seguenti.

• Implementare i meccanismi di timeout e ripetizione dei tentativi.

• Includere un'implementazione di degradazione graduale per gestire uno o più agenti all'interno di un modello di errore.

• Metti in evidenza gli errori anziché nasconderli, in modo che gli agenti downstream e la logica dell'orchestratore possano rispondere in modo appropriato.

• Prendere in considerazione i modelli di interruttore per le dipendenze dell'agente.

• Progettare gli agenti in modo che siano il più isolati possibile tra loro, con punti di guasto singoli non condivisi tra gli agenti. Per esempio:

  • Assicurare l'isolamento del calcolo tra gli agenti.

  • Valutare come l'uso di un singolo modello di tipo Models as a Service (MaaS) o di un archivio di conoscenze condiviso possa comportare una limitazione della frequenza quando gli agenti sono eseguiti simultaneamente.

• Usare le funzionalità del checkpoint disponibili nell'SDK per eseguire il ripristino da un'orchestrazione interrotta, ad esempio da un errore o da una nuova distribuzione del codice.

Sicurezza

L'implementazione di meccanismi di sicurezza appropriati in questi modelli di progettazione riduce al minimo il rischio di esporre il sistema di intelligenza artificiale agli attacchi o alla perdita di dati. La protezione delle comunicazioni tra agenti e la limitazione dell'accesso di ogni agente ai dati sensibili sono strategie di progettazione della sicurezza chiave. Prendere in considerazione le misure di sicurezza seguenti:

• Implementare l'autenticazione e usare la rete sicura tra gli agenti.

• Prendere in considerazione le implicazioni sulla privacy dei dati delle comunicazioni degli agenti.

• Progettare audit trail per soddisfare i requisiti di conformità.

• Progettare agenti e orchestratori seguendo il principio dei privilegi minimi.

• Valutare come gestire l'identità dell'utente tra gli agenti. Gli agenti devono avere accesso ampio agli archivi conoscenze per gestire le richieste da tutti gli utenti, ma non devono restituire dati inaccessibili all'utente. Il security trimming deve essere implementato in ogni agente nello schema.

Osservabilità e test

La distribuzione del sistema di intelligenza artificiale tra più agenti richiede il monitoraggio e il test di ogni agente singolarmente, nonché il sistema nel suo complesso, per garantire una corretta funzionalità. Quando si progettano le strategie di osservabilità e test, prendere in considerazione le raccomandazioni seguenti:

• Strumentare tutte le operazioni e i passaggi dell'agente. La risoluzione dei problemi dei sistemi distribuiti è un problema di informatica e gli agenti di intelligenza artificiale orchestrati non fanno eccezione.

• Tenere traccia delle metriche di utilizzo delle risorse e delle prestazioni per ogni agente in modo da poter stabilire una baseline, trovare colli di bottiglia e ottimizzare.

• Progettare interfacce testabili per singoli agenti.

• Implementare i test di integrazione per i flussi di lavoro multi-agente.

Insidie comuni e anti-pattern

Evitare questi errori comuni quando si implementano modelli di orchestrazione dell'agente:

• Creare una complessità di coordinamento non necessaria usando un modello complesso quando sarebbe sufficiente un'orchestrazione sequenziale o simultanea semplice.

• Aggiungere agenti che non offrono una specializzazione significativa.

• Trascurare gli effetti della latenza delle comunicazioni a più hop.

• Condivisione dello stato modificabile tra agenti simultanei, che può comportare dati transazionalmente incoerenti a causa dell'assunzione di aggiornamenti sincroni attraverso i confini dell'agente.

• Uso di modelli deterministici per i flussi di lavoro intrinsecamente non deterministici.

• Uso di modelli non deterministici per i flussi di lavoro intrinsecamente deterministici.

• Ignorare i vincoli delle risorse quando si sceglie l'orchestrazione simultanea.

• Utilizzo eccessivo delle risorse del modello perché le finestre di contesto aumentano man mano che gli agenti accumulano altre informazioni e consultano il modello per eseguire progressi nell'attività.

Combinazione di modelli di orchestrazione

Le applicazioni talvolta richiedono la combinazione di più modelli di orchestrazione per soddisfare i requisiti. Ad esempio, è possibile usare l'orchestrazione sequenziale per le fasi iniziali di elaborazione dei dati e quindi passare all'orchestrazione simultanea per le attività di analisi parallelizzabili. Non provare a adattare un flusso di lavoro a un unico modello quando diverse fasi del carico di lavoro hanno caratteristiche diverse e possono trarre vantaggio da ogni fase usando un modello diverso.

Relazione con i modelli di progettazione cloud

I modelli di orchestrazione degli agenti di intelligenza artificiale estendono e integrano i modelli di progettazione cloud tradizionali risolvendo le sfide uniche del coordinamento di componenti intelligenti e autonomi. I modelli di progettazione cloud si concentrano sulle problematiche strutturali e comportamentali nei sistemi distribuiti, ma i modelli di orchestrazione dell'agente di intelligenza artificiale riguardano in modo specifico il coordinamento dei componenti con funzionalità di ragionamento, comportamenti di apprendimento e output non deterministici.

Implementazioni basate su SDK

Molti di questi modelli si basano su un'implementazione basata su codice per gestire la logica di orchestrazione. Gli SDK che supportano un framework agente spesso forniscono supporto per molti dei modelli di orchestrazione dell'agente.

Microsoft Agent Framework

Microsoft Agent Framework SDK include indicazioni sull'implementazione per l'orchestrazione di Agent Framework.

• Orchestrazione sequenziale con Agent Framework
• Orchestrazione simultanea tramite Agent Framework
• Orchestrazione del trasferimento tramite Agent Framework
• Orchestrazione magentica con Agent Framework

Per l'implementazione pratica, esplorare esempi di flussi di lavoro dichiarativi di Agent Framework in GitHub che illustrano alcuni di questi modelli in pratica.

Kernel semantico

Semantic Kernel SDK include indicazioni sull'implementazione per il framework dell'agente.

• Orchestrazione sequenziale con il kernel semantico
• Orchestrazione simultanea con kernel semantico
• Orchestrazione di Chat di gruppo con il kernel semantico
• Orchestrazione del trasferimento con il kernel semantico
• Orchestrazione magentica con il kernel semantico

Per l'implementazione pratica, esplorare gli esempi di orchestrazione multi-agente del Semantic Kernel su GitHub che illustrano questi modelli.

È anche possibile trovare molti di questi modelli in AutoGen, ad esempio Magentic-One.

Implementazioni nel servizio Microsoft Foundry Agent

È anche possibile usare il servizio Microsoft Foundry Agent per concatenare gli agenti in flussi di lavoro relativamente semplici usando la relativa funzionalità degli agenti connessi . I flussi di lavoro implementati tramite questo servizio sono principalmente non deterministici, che limitano i modelli che possono essere completamente implementati in questo ambiente senza codice.

Contributori

Microsoft gestisce questo articolo. I collaboratori seguenti hanno scritto questo articolo.

Autori principali:

• Chad Kittel | Principal Software Engineer - Modelli e procedure di Azure
• Clayton Siemens | Principale sviluppatore di contenuti - Modelli e procedure di Azure

Altri collaboratori:

• Hemavathy Alaganandam | Principal Software Engineer
• James Lee | Data Scientist 2
• Ritesh Modi | Ingegnere Software Principale
• Mahdi Setayesh | Principal Software Engineer
• Mark Taylor | Principal Software Engineer
• Yaniv Vaknin | Senior Technical Specialist

Per visualizzare i profili LinkedIn non pubblici, accedere a LinkedIn.

Passo successivo

Implementare l'orchestrazione dell'agente con il kernel semantico