Flusso deterministico, agente singolo o sistema multi-agente: come scegliere il modello per un’attività

Prima di scegliere l’architettura, descrivi l’attività

La prima decisione non riguarda quanti agenti costruire, ma quale lavoro si vuole automatizzare e come si riconoscerà un risultato corretto. Se l’obiettivo, gli input e la sequenza dei passaggi si possono descrivere con precisione, potrebbe bastare un programma convenzionale. Se alcune decisioni dipendono dal contenuto di ciascun caso, può essere utile delegare al modello una parte della scelta. Se responsabilità distinte devono poter lavorare con un certo grado di indipendenza, si può valutare una composizione di agenti. Sono possibilità progettuali, non gradini di una scala in cui ogni opzione è necessariamente più avanzata o migliore della precedente.

Per confrontare le alternative, prepara una breve scheda dell’attività. Includi l’obiettivo, gli input previsti, i passaggi noti, le variazioni che si presentano nella pratica, il risultato osservabile e le conseguenze di un errore. Aggiungi anche le azioni che il sistema può compiere e quelle che richiedono un’autorizzazione o una revisione umana. Questa descrizione aiuta a non confondere un’attività con molti passaggi con un’attività che richiede autonomia: anche una sequenza lunga ma stabile può essere programmata in modo esplicito.

Le fonti disponibili offrono indicazioni per scegliere tra un agente singolo e più agenti, presentano modelli di progettazione e confrontano agenti e flussi di lavoro. Nei frammenti disponibili, però, non forniscono misurazioni comparabili di prestazioni, costi o tassi di errore per questi tre approcci. La matrice e gli esempi di questa guida sono quindi un quadro pratico di analisi, non la prova che un modello produca risultati migliori in generale.

Modello 1: flusso deterministico

In un flusso deterministico, il programma stabilisce la sequenza delle operazioni e le condizioni che fanno avanzare, ripetere o interrompere ciascuna fase. Il flusso può includere chiamate a un modello, per esempio per classificare un testo o estrarre campi, senza per questo diventare un agente autonomo. La distinzione utile riguarda chi decide il passaggio successivo: nel flusso, tale decisione è definita principalmente nel codice o in una configurazione esplicita.

Questo modello tende a essere adatto quando l’attività prevede input noti, regole relativamente stabili, poche diramazioni significative e un output verificabile con controlli concreti. Un processo di ricezione delle fatture potrebbe estrarre i dati, verificare i campi obbligatori, confrontare gli importi e inviare alla revisione i casi che non rispettano una regola. La sequenza può contemplare eccezioni, ma il team le rappresenta con condizioni esplicite, invece di chiedere al modello di inventare ogni volta il percorso di lavoro.

Come criterio di progettazione, il vantaggio di questo approccio è che il team può ispezionare l’ordine previsto e ricondurre ogni decisione a una regola o a una fase. Questo, da solo, non garantisce che i componenti funzionino correttamente: un’estrazione può essere errata e una regola può essere definita male. Il limite è che, per gestire una variazione non prevista, occorre modificare le regole, aggiungere diramazioni o inviare il caso a una persona. Se le eccezioni si moltiplicano, la manutenzione del flusso può diventare difficile; ciò non dimostra automaticamente che serva un agente, ma invita a riesaminare la progettazione.

In un flusso, gli strumenti possono essere limitati alle chiamate previste dal codice. Autorizzazioni e dati accessibili dipendono dall’implementazione e dalla configurazione del sistema: non si possono dedurre dal nome del modello. Neppure la memoria persistente è una caratteristica necessaria del flusso. Si può conservare lo stato necessario a completare un’esecuzione, ma è opportuno distinguere tale stato temporaneo dalla memoria riutilizzata tra attività diverse.

Modello 2: agente singolo con strumenti

In un modello con un solo agente, il modello partecipa alla scelta dei passaggi successivi sulla base dell’obiettivo, del contesto disponibile e degli strumenti messi a sua disposizione. Il programma continua a definire il perimetro: quale obiettivo viene comunicato, quali strumenti sono disponibili, quali limiti si applicano e quando il sistema deve fermarsi o chiedere aiuto. Autonomia non significa autorizzazione illimitata: la selezione dinamica di un’azione deve avvenire entro condizioni stabilite dal sistema.

Questo modello può essere preso in considerazione quando i casi variano in modo significativo e una sequenza rigida risulta poco naturale, ma le capacità necessarie rientrano in un insieme limitato di strumenti. Si pensi alle richieste di assistenza interne: una persona segnala un problema che può richiedere la consultazione della documentazione, la verifica dello stato di un servizio e la stesura di una risposta. In base al caso, l’agente potrebbe decidere quali consultazioni servono. Se l’azione può avere conseguenze rilevanti, il sistema può limitarsi a preparare una raccomandazione da sottoporre all’approvazione di una persona.

La flessibilità comporta un diverso carico di valutazione. Non basta controllare un unico percorso: occorre osservare quali azioni l’agente ha scelto, quali informazioni ha utilizzato, quando si è fermato e se ha richiesto una revisione nei casi ambigui. Una risposta finale corretta per caso non dimostra che i passaggi intermedi fossero appropriati. È utile registrare le decisioni rilevanti in modo proporzionato e riesaminare sia i casi risolti sia quelli rifiutati o inoltrati a un livello superiore.

Gli strumenti sono una parte centrale dei limiti operativi: descrivono le azioni disponibili, ma la loro portata effettiva dipende dall’implementazione, dall’autenticazione e dai controlli. Non si deve presumere che un’istruzione in linguaggio naturale sostituisca i controlli tecnici di accesso. La memoria può essere assente, limitata all’interazione corrente oppure persistente, a seconda del prodotto e della progettazione. Per una prima valutazione è preferibile dichiarare esplicitamente quale contesto viene conservato e verificare se sia necessario, invece di presumere che più memoria migliori il risultato.

Modello 3: sistema multi-agente

Un sistema multi-agente riunisce più componenti con funzioni diverse che interagiscono per completare un’attività. Le modalità di coordinamento possono variare: un componente può assegnare il lavoro, i componenti possono scambiarsi risultati oppure il sistema può organizzare una sequenza di funzioni specializzate. La sola etichetta non chiarisce chi decide il flusso, quali informazioni vengono condivise o come si risolvono i disaccordi. Queste proprietà vanno specificate per poter valutare la progettazione.

La domanda per giustificare più agenti non è se il problema sembri grande, ma se separare le responsabilità offra un vantaggio verificabile rispetto a una singola unità di lavoro o a un flusso esplicito. Si potrebbe valutare questa opzione in presenza di attività distinguibili, contesti che conviene mantenere separati o operazioni che devono produrre risultati indipendenti prima della sintesi. La suddivisione, tuttavia, introduce coordinamento, trasferimento del contesto e più punti in cui possono emergere incoerenze. Senza misurazioni sul caso specifico, non si dovrebbe affermare che questa separazione migliori la qualità o riduca i tempi.

Torniamo alla fattura. Una progettazione ipotetica potrebbe separare l’estrazione del documento, il controllo delle policy e la preparazione di una revisione per una persona. Prima di realizzarla, bisognerebbe chiedersi se queste responsabilità siano davvero indipendenti, se ciascuna possa essere valutata separatamente e se il risultato combinato sia migliore o più facile da ispezionare rispetto a un flusso fisso o a un agente singolo dotato degli stessi strumenti. Se la risposta è no, i componenti aggiuntivi potrebbero rappresentare un costo senza un beneficio dimostrato.

È importante poter vedere le interazioni: occorre ricostruire quali informazioni ha ricevuto ciascun componente, quale risultato ha prodotto e come tale risultato è stato utilizzato in seguito. Questo aiuta a indagare i problemi, ma non elimina la possibilità che si verifichino. Autorizzazioni, strumenti e memoria dipendono dall’implementazione: l’architettura non li risolve automaticamente. Una separazione funzionale può delimitare le responsabilità, ma solo se accessi e scambi di dati sono progettati e verificati esplicitamente.

Confronto applicato e matrice decisionale

Per confrontare i modelli in modo equo, definisci prima la stessa attività, lo stesso insieme di casi e lo stesso criterio di successo. Nell’esempio delle fatture, significa usare documenti rappresentativi, le stesse regole contabili e una definizione comune di estrazione corretta, inoltro appropriato e registrazione accettabile. Il confronto non sarebbe utile se un modello avesse più contesto, strumenti o interventi umani di un altro senza che questa differenza venisse documentata.

La tabella seguente non assegna punteggi universali. Riassume domande a cui il team può rispondere sulla base di prove ricavate dal processo, dai test e dalle misurazioni. Per esempio, “variabilità elevata” dovrebbe indicare la presenza di differenze osservabili che modificano i passaggi necessari, non semplicemente il fatto che il team non conosca ancora il processo. Analogamente, “facile da verificare” richiede un test o un criterio di accettazione, non una semplice impressione soggettiva.

Strumenti, autorizzazioni, memoria e supervisione

Questi elementi non vengono determinati automaticamente dalla scelta di un modello o di un altro. Il modello cambia il luogo in cui si prendono le decisioni e il numero di componenti coinvolti; la portata effettiva dipende dagli strumenti collegati, dai controlli di accesso, dai dati forniti e dalla logica di revisione. Perciò un’architettura non dovrebbe essere descritta come “sicura” o “controllata” soltanto perché è un flusso o perché è composta da più agenti.

Per gli strumenti, documenta ogni azione disponibile, i suoi effetti e chi può invocarla. Distingui le operazioni di sola lettura da quelle che modificano dati, inviano messaggi o producono altri effetti. In un flusso può essere il programma stesso a invocare ciascuno strumento in un punto previsto. In un agente, il modello può selezionare uno strumento tra quelli consentiti. In un sistema multi-agente, va chiarito quali componenti hanno accesso a quali strumenti e come si verifica che un output trasferito non inneschi un’azione non autorizzata.

Per la memoria e il contesto, specifica cosa viene conservato durante un’esecuzione e cosa, eventualmente, viene riutilizzato in un’esecuzione successiva. Registra il motivo della conservazione e verifica gli effetti con casi di prova. Una memoria aggiuntiva può aiutare a mantenere informazioni necessarie, ma può anche introdurre contesto obsoleto o irrilevante: questa possibilità va trattata come un rischio progettuale da verificare, non come un risultato inevitabile.

La supervisione umana deve avere una funzione concreta. Può confermare azioni, risolvere eccezioni, verificare risultati o interrompere il processo. Una revisione che arriva troppo tardi potrebbe non impedire l’effetto che si voleva controllare; una revisione di ogni passaggio potrebbe rendere superflua l’automazione. Definisci i punti di controllo in base all’impatto degli errori e misura quanti casi vengono esaminati, quanto lavoro richiede la revisione e quali disaccordi emergono.

Valutazione iniziale: misurare prima di aumentare l’autonomia

Un progetto pilota utile non comincia con una dimostrazione preparata perché tutto funzioni alla perfezione. Comincia con un insieme di casi che rispecchi l’uso previsto: casi frequenti, limiti noti, documenti incompleti, input ambigui ed eccezioni che richiedono un’interruzione. Conserva un riferimento del processo attuale per confrontare i risultati e registra le condizioni di ogni test. Se cambiano istruzioni, strumenti o regole, annota la modifica, per non attribuire all’architettura un effetto che potrebbe dipendere da un altro cambiamento.

Valuta separatamente il risultato e il percorso. Tra le domande sul risultato: i dati sono stati estratti correttamente? È stato scelto il percorso autorizzato? È stata riconosciuta la necessità di una revisione? È stata evitata un’azione completata con informazioni insufficienti? Tra le domande sul processo: quali decisioni intermedie sono state prese? Quali strumenti sono stati usati? Sono state consultate informazioni pertinenti? Il sistema si è fermato quando avrebbe dovuto? Per agenti e sistemi multi-agente, queste registrazioni aiutano a capire se una risposta accettabile sia stata raggiunta attraverso un percorso adeguato.

Definisci in anticipo i criteri per proseguire, circoscrivere o interrompere il test. Se gli errori più gravi si verificano nella scelta delle azioni, potrebbe essere necessario limitare gli strumenti o restituire quella decisione al codice. Se i casi non si possono valutare in modo coerente, occorre prima migliorare la definizione del successo. Se la revisione umana corregge spesso lo stesso tipo di risultato, il sistema potrebbe aver bisogno di una regola esplicita, di input migliori o di una fase di convalida, non necessariamente di altri agenti.

Quando non usare un agente o quando ridurne l’autonomia

Non usare un agente può essere la scelta corretta se una routine nota si può gestire con codice convenzionale, se le regole sono stabili e verificabili o se non esiste un modo affidabile per controllare il risultato. Può essere preferibile mantenere una persona nel processo quando il costo di un errore è elevato e le azioni sono difficili da annullare. In questi casi, l’automazione può limitarsi a preparare dati, riassumere informazioni o suggerire un percorso senza eseguirlo.

Torna a un flusso deterministico, o limita l’agente a una sola fase, se la scelta delle azioni non offre un vantaggio misurabile, se l’agente usa strumenti non necessari, se le eccezioni si possono ora rappresentare con regole chiare oppure se è difficile ricostruire come sia stata presa una decisione. Se i componenti di un sistema multi-agente non concordano, valuta se la separazione sia davvero utile: per quel caso, un percorso esplicito con controlli potrebbe essere più facile da verificare, anche se il team deve accertarlo con prove.

Se valuti una composizione di agenti, inizia da funzioni separate con input, output e criteri di accettazione definiti. Non suddividere un’attività in molti ruoli astratti soltanto sulla base dell’intuizione. Prova prima una versione semplice, osserva dove fallisce e amplia il sistema solo quando è stato individuato un problema che la separazione potrebbe affrontare. Anche una delle fonti secondarie fornite consiglia di partire dal modello più semplice; qui il suggerimento è presentato come euristica progettuale da verificare nel caso d’uso, non come regola universale.

Checklist finale per documentare la scelta

Una decisione architetturale è più utile quando può essere riesaminata dopo aver osservato il sistema in condizioni reali. Documenta quale problema si vuole risolvere, quali alternative sono state confrontate e quali prove hanno determinato la scelta. Non è necessario presumere che la decisione sia permanente: se cambiano la variabilità dei casi, le conseguenze degli errori o gli strumenti disponibili, può cambiare anche il modello più adatto.

Per approfondire il confronto tra agente singolo e più agenti, consulta la guida di Microsoft Learn indicata tra le fonti. Per confrontare agenti e flussi di lavoro, si può consultare la documentazione di UiPath, tenendo presente che si tratta della documentazione di un fornitore. Le pagine di Microsoft Learn e Google Cloud dedicate ai modelli di progettazione offrono indicazioni architetturali; le loro raccomandazioni vanno valutate rispetto alle esigenze e ai vincoli del team. Questi riferimenti non sostituiscono le prove interne e non dimostrano, da soli, risultati prestazionali per una specifica attività.

Continua a esplorare

Correzioni e trasparenza

Se trovi un dato errato o non aggiornato, inviaci la pagina e la fonte da verificare.