Best practice per l’orchestrazione degli agenti IA: gestire errori, approvazioni e nuovi tentativi

Avere più agenti che lavorano sullo stesso progetto sembra estremamente efficiente. Uno pianifica il lavoro, un altro si occupa del design e un terzo scrive il codice. Funziona, finché non smette di funzionare. E i fallimenti si verificano più spesso di quanto vorresti.

Prevenire questi fallimenti richiede un’attenta progettazione dei flussi di lavoro. Vediamo quindi cosa rende inaffidabili i flussi di lavoro orchestrati ed esploriamo le best practice di orchestrazione per l’affidabilità in produzione.

Che cos’è l’orchestrazione degli agenti IA?

L’orchestrazione degli agenti IA coordina più agenti IA, modelli e strumenti per completare un’attività in più passaggi. Ma qualcuno — o qualcosa — deve comunque decidere quale agente viene eseguito per primo, quali informazioni riceve e cosa succede dopo che ha finito. Questo è il ruolo dell’orchestratore: un agente IA che agisce da manager oppure un livello di esecuzione controllato via software.

In parole semplici, un livello di orchestrazione scompone un obiettivo in attività più piccole, tiene traccia delle dipendenze, delega l’esecuzione agli agenti giusti, gestisce il contesto condiviso e riunisce i risultati.

Come funziona l’orchestrazione degli agenti IA: all’interno del motore di esecuzione

Espandi

Vediamo cosa succede dopo aver assegnato un’attività a un orchestratore.

Prendiamo un esempio dal workshop su Computer di Perplexity: la creazione di una dashboard di account intelligence con informazioni provenienti da Salesforce, Snowflake, email, calendario e notizie recenti.

1. Comprendere l’obiettivo e pianificare il lavoro. L’orchestratore parte dal risultato richiesto e lo scompone in attività con dipendenze esplicite. Nel nostro esempio della dashboard, questo significa raccogliere informazioni da fonti diverse e trasformarle in un prodotto finito. Il pianificatore stabilisce quali passaggi dipendono da altri e quali possono essere eseguiti in modo indipendente.
2. Instradare le attività agli agenti appropriati. L’orchestratore individua le attività le cui dipendenze sono soddisfatte e delega il lavoro ad agenti o modelli specializzati. Le attività dipendenti attendono i propri prerequisiti. Perplexity Computer utilizza più modelli di frontiera, instradando le diverse parti del flusso di lavoro verso i sistemi più adatti a quelle attività. Questo consente anche di eseguire in parallelo il lavoro indipendente.
3. Eseguire le chiamate agli strumenti in ambienti controllati. Gli agenti interagiscono con il proprio ambiente tramite strumenti come la ricerca web, le API, le applicazioni collegate, le operazioni sui file o l’esecuzione di codice. Il livello di esecuzione esegue queste azioni e restituisce i risultati agli agenti.
4. Passare risultati e contesto tra gli agenti. Quando un agente termina la propria attività, l’agente successivo a valle ha bisogno dell’output pertinente per proseguire. Un record di passaggio di consegne potrebbe contenere un ID attività, un riferimento all’output, una versione dello schema e metadati sulla fonte. L’orchestratore coordina questi passaggi di consegne mantenendo il contesto necessario per le fasi successive. È importante sottolineare che gli agenti non devono portarsi dietro l’intera cronologia del lavoro di ogni altro agente nelle proprie finestre di contesto.
5. Registrare lo stato di esecuzione separatamente dal contesto degli agenti. Man mano che gli agenti avviano, completano o non riescono a portare a termine le attività, il motore di esecuzione aggiorna un record persistente del flusso di lavoro con gli stati delle attività, i tentativi di esecuzione, i riferimenti agli output e il lavoro rimanente. Questo record consente all’orchestratore di monitorare i progressi e riprendere dopo eventuali interruzioni, senza dover ricorrere a un LLM per ricostruire il flusso di lavoro dalla cronologia della conversazione.
6. Convalidare i risultati e decidere cosa succede dopo. Quando un’attività restituisce un risultato, il livello di orchestrazione verifica se il suo output rispetta il contratto previsto e se le dipendenze dell’attività successiva sono soddisfatte. Se viene rilevato un problema, il flusso di lavoro può tornare a un passaggio precedente per una correzione o essere messo in pausa. In caso contrario, procede verso il completamento.

Dietro quella che sembra una semplice orchestrazione di agenti IA si muovono molti ingranaggi. Il modo in cui organizzi il coordinamento degli agenti determina quanto controllo hai sull’esecuzione. E naturalmente, tutto questo coordinamento comporta costi aggiuntivi. Quindi non sempre ne vale la pena.

Quando conviene usare l’orchestrazione degli agenti IA?

Valuta l’orchestrazione multi-agente quando parti diverse dell’attività richiedono competenze distinte, il lavoro indipendente può essere eseguito in parallelo o non è possibile stabilire in anticipo il passaggio successivo.

L’orchestrazione è quindi utile in tre scenari:

• Le attività richiedono specializzazioni diverse. Un progetto di sviluppo software, ad esempio, potrebbe trarre vantaggio da agenti separati per pianificazione, design, sviluppo e revisione.
• Le attività indipendenti possono essere eseguite in parallelo. Invece di far completare tutto in sequenza a un unico agente, più agenti possono lavorare contemporaneamente e restituire i propri risultati a un orchestratore.
• Il problema è aperto. Gli agenti potrebbero dover esplorare approcci diversi, prendere decisioni e collaborare anziché seguire una sequenza predefinita.

Al di fuori di questi casi, l’orchestrazione è solo una tendenza costosa. Più agenti significano anche più coordinamento e, potenzialmente, costi in token più elevati.

“Di solito parto dall’opzione più semplice e costruisco da lì. Se conosciamo i passaggi e sono ripetibili, probabilmente si tratta di un flusso di lavoro. Vedo un motivo per introdurre più agenti solo quando hanno responsabilità, autorizzazioni o utenti diversi”, afferma Josh Spilker, responsabile del search marketing di AirOps.

Anche in quel caso, valuta i benefici rispetto alle chiamate aggiuntive ai modelli, ai passaggi di consegne, alla latenza e ai punti di errore.

Architetture di orchestrazione degli agenti IA e relativi compromessi

Esistono tre modi comuni per strutturare il coordinamento degli agenti: orchestrazione centralizzata, decentralizzata e gerarchica. La scelta dell’architettura giusta si riduce a una domanda: chi controlla il lavoro e in che modo gli agenti si coordinano tra loro?

Orchestrazione centralizzata

Nell’orchestrazione centralizzata, un unico orchestratore gestisce il processo. Scompone l’attività, delega il lavoro ad agenti specializzati, ne monitora i progressi e ne riunisce i risultati.

Espandi

Il compromesso: il coordinamento centralizzato rende più semplice monitorare l’esecuzione e applicare regole comuni in un unico punto di controllo. Tuttavia, l’orchestratore può diventare un collo di bottiglia e un suo malfunzionamento può interrompere l’intero flusso di lavoro, a meno che il sistema non supporti il ripristino.

Orchestrazione decentralizzata

Nell’orchestrazione decentralizzata, gli agenti si coordinano in modo più diretto anziché affidarsi a un unico manager per ogni decisione. Possono scambiarsi messaggi, leggere uno stato condiviso e determinare in autonomia i passaggi successivi.

Espandi

Il compromesso: gli agenti possono operare senza attendere un pianificatore centrale, il che rende questo approccio utile per il lavoro esplorativo e i contributi indipendenti. Ma il coordinamento diventa più difficile quando gli agenti sono in disaccordo, aggiornano informazioni condivise o devono raggiungere un risultato coerente.

Orchestrazione gerarchica

L’orchestrazione gerarchica estende l’approccio basato su un manager a più livelli. Un orchestratore di livello superiore delega la responsabilità a orchestratori subordinati, che coordinano i propri gruppi di agenti specializzati.

Pensa a un flusso di lavoro aziendale che coinvolge i team commerciale, finanziario e legale. Un orchestratore di livello superiore potrebbe delegare ciascun flusso di attività a un coordinatore specifico del dominio. Questi coordinatori gestirebbero poi i propri agenti specializzati e riferirebbero i risultati consolidati.

Questa struttura può essere utile quando i flussi di lavoro sono troppo ampi perché un unico orchestratore possa gestirli in modo efficace.

Espandi

Il compromesso: le gerarchie consentono ai team di suddividere le responsabilità di coordinamento e, potenzialmente, di gestire gli errori all’interno dei singoli rami. Tuttavia, introducono ulteriori passaggi di consegne, una gestione dello stato più complessa e costi operativi più elevati. Anche il ripristino locale dipende da come vengono implementati i checkpoint e lo stato di esecuzione.

Come si confrontano queste architetture:

Esecuzione sequenziale, parallela e basata su passaggi di consegne

C’è un’altra distinzione che vale la pena comprendere. L’architettura determina chi coordina gli agenti. Il modello di esecuzione determina come procedono le loro attività.

Ecco tre modelli di esecuzione:

• Flussi di lavoro sequenziali: gli agenti lavorano in un ordine predefinito e il risultato di un agente diventa l’input di un altro.
• Esecuzione parallela: agenti indipendenti lavorano simultaneamente.
• Esecuzione basata su passaggi di consegne: il controllo passa da un agente specializzato all’altro man mano che l’attività procede. È utile quando un altro agente è più adatto a gestire il passaggio successivo, anche se ogni passaggio di consegne deve preservare le informazioni necessarie per proseguire.

Questi modelli non si escludono a vicenda e non corrispondono in modo univoco alle architetture di orchestrazione. L’obiettivo è scegliere la struttura più semplice in grado di supportare le dipendenze, i requisiti di coordinamento e l’overhead operativo accettabile del tuo flusso di lavoro.

Errori comuni nell’orchestrazione degli agenti AI

Nell’orchestrazione può andare storto qualsiasi cosa, dalle semplici sviste agli ostacoli più intricati. A volte un agente può persino sembrare svolgere correttamente il proprio lavoro mentre il flusso di lavoro complessivo fallisce. Partendo dalle esperienze di chi lavora sul campo, abbiamo raccolto alcuni degli errori più comuni alla base di flussi di lavoro orchestrati poco affidabili — tienili d’occhio:

• Passaggi di consegne tra agenti con perdita di informazioni. Un orchestratore passa un piano riassunto a un agente specializzato, ma il riepilogo omette vincoli, dipendenze o dettagli di implementazione.
• Esecuzione fan-in prematura. Un agente a valle inizia ad aggregare i risultati prima che tutte le attività a monte siano terminate.
• Aggiornamenti non deterministici dello stato condiviso. Agenti in parallelo scrivono sulle stesse chiavi di stato senza una semantica di merge ben definita. A seconda di come il framework gestisce gli aggiornamenti, ciò può causare scritture perse, dati duplicati, output dipendenti dall’ordine o modifiche in conflitto.
• Divergenza tra checkpoint ed effetti collaterali. Un’attività esegue un’operazione esterna, ma la sua esecuzione riuscita non viene registrata in modo durevole prima che il worker si arresti. Al ripristino, l’orchestratore vede un’attività non completata e la esegue di nuovo.
• Race condition nella ripresa dopo l’approvazione umana. Mettere in pausa e riprendere l’esecuzione introduce problemi di sincronizzazione specifici.
• Cicli di delega e amplificazione dei nuovi tentativi. Gli agenti si passano ripetutamente il lavoro perché le loro responsabilità si sovrappongono, le dipendenze sono circolari o le condizioni di completamento sono ambigue.
• Controlli a livello di istruzioni scambiati per sicurezza dell’esecuzione. Un orchestratore può dire agli agenti di non accedere a determinate risorse o di non eseguire azioni sensibili, ma le istruzioni del modello non applicano i permessi del sistema operativo, le restrizioni di rete o i confini di autorizzazione. La ricerca sull’ingegneria della sicurezza di Perplexity evidenzia perché gli agenti possono oltrepassare i confini di sicurezza mentre perseguono obiettivi legittimi, anche in assenza di istruzioni dannose

Nota quanto sono diversi questi errori. Una transizione prematura dello scheduler o una scrittura esterna ambigua possono entrambe produrre un risultato errato, ma hanno origine in parti diverse del ciclo di vita dell’esecuzione. Ecco perché un’orchestrazione affidabile richiede più che migliorare i prompt o aggiungere nuovi tentativi.

7 best practice di orchestrazione degli agenti AI per l’affidabilità in produzione

1. Definisci contratti di attività espliciti, criteri di accettazione e condizioni di arresto

Obiettivi vaghi e una definizione di completamento poco chiara portano spesso a risultati deludenti da parte degli agenti. La soluzione è un contratto di prompt (un ambito di lavoro per un agente): concorda obiettivo, vincoli, formato dell’output e condizioni di fallimento prima che inizi l’esecuzione.

Ad esempio, ecco come potresti definire un contratto per un agente incaricato di correggere un test di integrazione che fallisce in modo intermittente:

• Obiettivo: individuare e correggere la causa di un test di integrazione instabile dell’API di checkout.
• Input: codice sorgente dei test, log degli errori della CI, commit recenti e codice dell’applicazione pertinente.
• Vincoli: non disattivare i test, non allentare le asserzioni e non modificare comportamenti dell’applicazione non correlati.
• Output previsto: una patch del codice, una spiegazione della causa principale e i risultati dell’esecuzione dei test.
• Criteri di accettazione: il test che prima falliva viene superato in 10 esecuzioni consecutive e la suite di regressione pertinente viene superata.
• Condizioni di fallimento: non è possibile stabilire la causa principale, la correzione introduce regressioni oppure l’ambiente di test necessario non è disponibile.

Ma c’è un’altra parte importante: quando dovrebbe fermarsi l’agente?

Un agente non dovrebbe continuare a iterare all’infinito solo perché non ha prodotto un risultato soddisfacente. Definisci cosa costituisce un completamento riuscito, quando restituire un’attività parzialmente completata e quando fermarsi perché un requisito non può essere soddisfatto. Imposta una profondità massima di delega e limiti di iterazione o budget di esecuzione, in modo che le attività irrisolte non si trasformino in cicli infiniti.

Torniamo al nostro esempio della CI. Potresti definire le seguenti condizioni di arresto:

• Successo: la correzione supera 10 esecuzioni consecutive dei test e la suite di regressione pertinente.
• Limite di iterazioni: l’agente può tentare al massimo due correzioni candidate.
• Budget di esecuzione: l’agente deve fermarsi dopo 60 minuti, anche se il problema rimane irrisolto.
• Limite di delega: l’agente può delegare il lavoro a un solo agente specializzato, senza ulteriori deleghe a subagenti.
• Completamento parziale: se entrambi i tentativi falliscono o il limite di tempo scade, l’agente restituisce le proprie conclusioni, le modifiche tentate e i risultati dei test.
• Esecuzione bloccata: se l’ambiente di test non è disponibile, l’agente si ferma e segnala l’ostacolo invece di dichiarare il successo.

2. Mantieni gli orchestratori snelli e imponi passaggi di consegne strutturati

A volte gli sviluppatori assegnano troppe responsabilità a un orchestratore che, invece di coordinare gli agenti specializzati, inizia a scrivere codice, fare debug o eseguire revisioni dettagliate in prima persona. Questo crea un collo di bottiglia: l’orchestratore consuma il proprio budget di contesto in dettagli di implementazione, ritarda la delega e rende meno chiara la responsabilità dei risultati.

Quindi lascia che gli orchestratori facciano il loro lavoro e imponi passaggi di consegne che facciano riferimento ad artifact concreti: l’attività originale, gli input pertinenti, gli artifact di output, lo stato dell’esecuzione ed eventuali problemi irrisolti.

Considera questo esempio: status: completed si riferisce al lavoro assegnato all’agente, non all’intero flusso di lavoro. Poiché i test sono ancora in stato pending, l’orchestratore non dovrebbe approvare il risultato finale.

3. Rendi persistente lo stato del flusso di lavoro e controlla la crescita del contesto

La cronologia delle conversazioni di un agente non è un registro affidabile dei progressi del flusso di lavoro. Quando la finestra di contesto si riempie, la compattazione automatica può eliminare dettagli importanti. E se un worker si arresta in modo anomalo, l’agente successivo deve sapere quali passaggi sono stati effettivamente completati.

Ad esempio, se l’agente di programmazione genera una patch e poi si arresta in modo anomalo, il worker successivo dovrebbe recuperare l’artifact salvato e proseguire dallo stato registrato del flusso di lavoro. Ma se l’agente ha anche avviato un’esecuzione esterna della CI, l’orchestratore deve riconciliare separatamente quell’esecuzione prima di ripetere l’azione

Quindi mantieni lo stato di esecuzione separato dal contesto di lavoro dell’agente. Salva gli stati delle attività, i tentativi di esecuzione, i passaggi completati e i riferimenti agli artifact in uno storage durevole. Nel frattempo, carica solo le istruzioni, gli input e i risultati pertinenti all’attività corrente dell’agente, invece di riempire la sua finestra di contesto con l’intera cronologia di esecuzione.

4. Progetta nuovi tentativi consapevoli degli errori e un’esecuzione degli strumenti recuperabile

Supponiamo che il tuo agente di CI avvii un’esecuzione dei test, ma che la richiesta API vada in timeout. L’esecuzione dei test non è partita, oppure il servizio di CI l’ha messa in coda e ha perso la risposta?

Un timeout non significa necessariamente che un’operazione sia fallita. Ecco perché devi distinguere tra i diversi errori prima di decidere cosa fare dopo:

• Errori transitori (429, 503): riprova con un backoff esponenziale limitato e jitter, rispettando Retry-After quando presente.
• Errori di convalida o di autorizzazione (400, 403): fermati o correggi il problema di fondo invece di ripetere la stessa richiesta.
• Esiti ambigui (timeout dopo una possibile scrittura): verifica se l’operazione è riuscita prima di tentarla di nuovo.

Nota: anche gli errori per cui è possibile riprovare richiedono dei limiti. Imposta un timeout per ogni chiamata a uno strumento, limita il numero di nuovi tentativi e il tempo totale dedicato ai tentativi e imponi una scadenza complessiva per il flusso di lavoro, in modo che gli agenti annidati non possano continuare a riavviare la stessa operazione. Se una dipendenza fallisce ripetutamente, usa un circuit breaker per sospendere temporaneamente le richieste.

Per le operazioni con effetti collaterali esterni, assegna una chiave di idempotenza stabile a ogni azione logica e riutilizzala a ogni nuovo tentativo. Se l’API supporta la deduplicazione lato server, può riconoscere le richieste ripetute senza eseguire l’azione due volte. In caso contrario, interroga il sistema esterno usando un ID di correlazione o un altro riferimento autorevole.

Quando non riesci a stabilire cosa è successo, fermati ed esegui un’escalation.

Un esempio della logica dei nuovi tentativi per il nostro agente di CI, espressa in pseudocodice:

Nota sul codice: l’esempio presuppone che l’API della CI supporti la ricerca delle esecuzioni tramite ID richiesta. Il request_id impedisce i duplicati solo se il provider garantisce esplicitamente l’idempotenza. bounded_retry() è pseudocodice a scopo illustrativo. In produzione, i nuovi tentativi dovrebbero essere limitati sia da un budget di tentativi per operazione (numero massimo di tentativi o tempo trascorso) sia dalla scadenza complessiva del flusso di lavoro.

Per flussi di lavoro più lunghi che coinvolgono più servizi, valuta il pattern Saga per coordinare azioni compensative quando i passaggi successivi falliscono. Ricorda però che la compensazione non è sempre un rollback completo. Puoi annullare un aggiornamento del database, ma non puoi annullare l’invio di un’email.

5. Instrada e parallelizza il lavoro con budget di risorse espliciti

Qui ci sono due aspetti da bilanciare: quanta capacità del modello richiede ciascuna attività e quante attività puoi eseguire simultaneamente. Se sbagli uno dei due, rischi che gli agenti competano per le quote API condivise o che si affidino solo a costosi modelli di ragionamento.

Per la selezione del modello, adatta la capacità del modello e l’impegno di ragionamento alla complessità dell’attività — semplice, ma spesso trascurato. Tieni presente che puoi configurare tu stesso le regole di instradamento e valutare i modelli, oppure usare una piattaforma di orchestrazione che gestisce la selezione del modello per te.

Ad esempio, l’Effort Mode di Perplexity Computer ti permette di scegliere quanto impegno merita un’attività senza selezionare manualmente un modello. Scegli Light, Standard, High o Ultra e Perplexity seleziona automaticamente il modello orchestratore e il relativo livello di ragionamento. L’orchestratore delega poi le sottoattività ad agenti di supporto, che possono usare modelli di fornitori diversi.

Perplexity valuta le configurazioni dei modelli in base a qualità e costo, privilegiando le opzioni meno costose che offrono risultati comparabili. Puoi anche usare i controlli Custom se preferisci scegliere tu il modello e il livello di ragionamento.

Per il parallelismo, il limite dovrebbe dipendere dalla tua infrastruttura e dalle dipendenze esterne. Verifica i limiti di frequenza delle richieste e dei token delle API condivise, quindi esegui test di carico del flusso di lavoro aumentando la concorrenza. Osserva se il throughput migliora o se le richieste iniziano ad accodarsi, a rallentare o a restituire errori 429.

Per mantenere prevedibile il consumo di risorse, imponi limiti di risorse e controlli di pianificazione:

• Controlla la concorrenza e la frequenza delle richieste: limita le chiamate in corso per ciascun servizio e metti in coda il lavoro in eccesso. Ricorda che un limite di concorrenza da solo non impone limiti di richieste al minuto o di token al minuto.
• Monitora i budget di token e di costo: tieni conto dell’utilizzo nell’intero flusso di lavoro, inclusi i subagenti, e smetti di avviare nuovo lavoro quando il budget residuo è insufficiente.
• Imponi scadenze di esecuzione: imposta limiti di tempo per attività e flussi di lavoro e propaga l’annullamento agli agenti in esecuzione, ove supportato.
• Rispetta le dipendenze: avvia le attività a valle solo quando gli input necessari sono disponibili, invece di lanciare tutti gli agenti contemporaneamente.

6. Imponi le approvazioni e isola l’esecuzione degli agenti

Non chiedere mai al modello di decidere se le proprie azioni sono sicure. Assegna invece agli agenti permessi con privilegi minimi e applica regole di approvazione basate sul rischio nel codice dell’applicazione. Se gli agenti eseguono codice, isola tale esecuzione dal tuo ambiente host e limita l’accesso a file, reti e credenziali. In questo modo limiti i danni se l’agente commette un errore o esegue codice non sicuro.

«Sono scettico nei confronti dei sistemi multi-agente eccessivamente complicati, soprattutto quando gli agenti revisionano e approvano il lavoro l’uno dell’altro. Si rischia di ritrovarsi con diversi agenti che si passano con sicurezza lo stesso errore, senza che nessuno lo individui davvero», avverte Spilker.

Espandi

Per le azioni che richiedono l’approvazione umana, metti in pausa l’esecuzione e salva l’esatta operazione proposta:

• i suoi parametri
• la sua risorsa di destinazione
• il suo commit o la versione dello stato
• la decisione del revisore

Definisci inoltre cosa succede se l’approvazione viene rifiutata, scade o richiede un’escalation. Questo è essenziale per i framework che supportano la ripresa, poiché la ripresa di un nodo interrotto riesegue il codice dall’inizio di quel nodo. Eventuali effetti collaterali precedenti all’interruzione potrebbero verificarsi di nuovo.

Quindi, se l’approvazione viene rifiutata o scade, la richiesta viene chiusa. Se il commit di destinazione, i parametri o i permessi cambiano prima dell’esecuzione, invalida l’approvazione e richiedine una nuova.

Spilker, inoltre, non condivide l’idea che l’obiettivo debbano essere agenti completamente autonomi ed end-to-end. «Per me l’approccio migliore è creare pochi agenti mirati con responsabilità chiare, permessi definiti e revisione umana nei momenti giusti. Si ottiene comunque efficienza senza rinunciare al pieno controllo», conclude.

7. Verifica gli output in modo indipendente e testa il comportamento di ripristino

Ti è mai capitato che un agente segnalasse Success quando in realtà aveva fallito? Fastidioso, se non esasperante, e la soluzione non è rapida perché il messaggio finale dell’agente non ti dirà necessariamente dove le cose sono andate storte.

Per indagare, traccia ciò che è successo durante l’esecuzione e verifica i risultati in modo indipendente. Dedichiamo quindi un po’ di tempo a isolare e risolvere il problema.

Traccia il flusso di lavoro per individuare cosa è andato storto

Prima di eseguire il debug dei prompt di un agente, acquisisci l’intero percorso di esecuzione. Ti serve una traccia che colleghi invocazioni degli agenti, chiamate agli strumenti, errori e nuovi tentativi all’interno della stessa esecuzione del flusso di lavoro.

Le convenzioni semantiche GenAI di OpenTelemetry forniscono un modo standardizzato per descrivere queste operazioni. Ad esempio, invoke_workflow identifica l’esecuzione di un flusso di lavoro, invoke_agent l’invocazione di un agente ed execute_tool una chiamata a uno strumento. Ogni operazione può essere registrata come span con la relativa tempistica, lo stato e i metadati pertinenti.

Questo passaggio ti fornisce una traccia del percorso di esecuzione, così puoi individuare dove un agente si è inceppato.

Un esempio di traccia di esecuzione.

Esamina l’output in modo indipendente

Usa controlli programmatici ovunque possibile. Convalida gli output rispetto a schemi JSON, esegui test unitari e di integrazione, verifica che gli artifact richiesti esistano e interroga i sistemi esterni per confermare che le azioni siano effettivamente riuscite.

Per gli output che richiedono un giudizio soggettivo — e che quindi non possono essere valutati tramite controlli programmatici — introduci un agente revisore indipendente. Un approccio è un ciclo implementatore–revisore–risolutore, in cui un agente produce un artifact, un revisore con un contesto nuovo individua i problemi e un risolutore li affronta prima che la convalida venga eseguita di nuovo.

Devi comunque convalidare i risultati del revisore ove possibile e, se usi valutatori basati su LLM per valutazioni ripetute, calibrarne i giudizi rispetto a esempi revisionati da persone.

Inietta errori per testare il ripristino

Finora hai tracciato ciò che gli agenti hanno eseguito e verificato se i loro output fossero corretti. Ma cosa succede quando un worker si arresta in modo anomalo a metà di un’attività o un’API va in timeout dopo aver accettato una richiesta? Sorprendentemente, il tuo flusso di lavoro potrebbe funzionare perfettamente in condizioni normali, ma fallire durante il ripristino.

Per verificarlo, inserisci deliberatamente dei guasti in un ambiente di test:

• Simula timeout delle API
• Fai arrestare i worker tra le scritture esterne e i checkpoint
• Restituisci output degli strumenti malformati
• Fai scadere le approvazioni

Dopo ogni test, esamina la traccia di esecuzione per vedere quali passaggi sono stati eseguiti, da dove è ripreso il flusso di lavoro e se alcune azioni sono state ripetute o saltate. Poi controlla i risultati effettivi.

Supponiamo che il tuo agente CI invii una richiesta per avviare un’esecuzione di test, ma che la risposta dell’API vada in timeout. L’agente riprova, riceve una risposta positiva e segnala Successo. Sembra tutto a posto finché non controlli il servizio CI e scopri che sono state create due esecuzioni di test anziché una.

Per questo motivo dovresti verificare sia lo stato registrato dal flusso di lavoro sia le modifiche effettive nei sistemi esterni. Un test di ripristino dovrebbe essere superato solo quando il flusso di lavoro raggiunge lo stato previsto senza effetti collaterali indesiderati.

Aggiungi gli errori che scopri ai tuoi test di regressione, così le modifiche future non li reintrodurranno.

In definitiva, successo significa che il flusso di lavoro ha superato i controlli richiesti e che i suoi risultati esterni sono stati verificati.

Domande frequenti sull’orchestrazione degli agenti IA

Perché gli agenti IA isolati falliscono su scala aziendale?

Gli agenti isolati possono completare correttamente le singole attività, ma produrre insieme risultati incoerenti. Immagina un agente di vendita che recupera le condizioni di un cliente alle 10:00, un agente dei prezzi che calcola un preventivo usando prezzi aggiornati alle 10:05 e un agente legale che controlla un contratto modificato alle 10:07. Ogni agente lavora con un’istantanea diversa dell’azienda, quindi i loro output possono contraddirsi a vicenda.

Il problema diventa più evidente su scala aziendale perché gli agenti interagiscono con più sistemi che si aggiornano in modo indipendente, operano con autorizzazioni diverse e non condividono necessariamente il contesto o lo stato di esecuzione.

Come si evitano i loop infiniti di nuovi tentativi negli agenti IA?

Imposta limiti a più livelli: numero massimo di nuovi tentativi per le chiamate agli strumenti, numero massimo di iterazioni dell’agente, profondità di delega e una scadenza complessiva per il flusso di lavoro. Classifica gli errori prima di riprovare. Per le risposte 429 transitorie, rispetta Retry-After quando è presente. Altrimenti, usa un backoff esponenziale limitato con jitter.

Smetti di ripetere richieste invariate dopo errori di convalida o di autorizzazione. Se un servizio a valle fallisce ripetutamente, un circuit breaker può impedire agli agenti di generare ulteriore carico.

Come si riprende un flusso di lavoro di un agente IA dopo un arresto anomalo?

Il meccanismo di ripristino dipende dal runtime. Con LangGraph, un checkpointer persistente come PostgresSaver memorizza lo stato del grafo associato a un thread_id, consentendo all’esecuzione di proseguire dallo stato persistito. Con Temporal, un altro worker può ricostruire un flusso di lavoro riproducendone la cronologia degli eventi. Durante la riproduzione, riutilizza i risultati delle attività registrati in precedenza.

Se l’applicazione viene ridistribuita mentre i flussi di lavoro sono ancora in esecuzione, lo stato salvato e le cronologie di esecuzione potrebbero non essere più compatibili. Temporal risolve questo problema con Worker Versioning e il patching dei flussi di lavoro. Per i sistemi basati su checkpoint, pianifica le migrazioni dello schema e testa il ripristino sugli stati salvati esistenti prima di distribuire modifiche incompatibili.

Come si testa l’affidabilità dell’orchestrazione degli agenti IA?

Esegui più volte le stesse attività rappresentative e distingui pass@k (se almeno uno dei k tentativi riesce) da pass^k (se tutti i k tentativi riescono)

Misura i risultati per categoria di attività e versione del flusso di lavoro, anziché basarti su un unico tasso di successo aggregato. Monitora il successo al primo tentativo, la coerenza tra esecuzioni ripetute, la latenza p95, il costo per attività completata e la percentuale di casi che richiedono l’intervento umano. Riporta le dimensioni dei campioni e gli intervalli di incertezza per i tassi di successo.