Modelli di orchestrazione multi-agente e procedure consigliate

L'orchestrazione generativa supporta anche sistemi multi-agente, in cui un agente chiama altri agenti. Quando suddividi i problemi in più agenti specializzati, rendi la tua applicazione più modulare, scalabile e gestibile.

Agenti inline

Gli agenti inline, noti anche come agenti figlio, sono piccoli flussi di lavoro riutilizzabili all'interno dello stesso agente. Spesso sono semplicemente degli argomenti che l'agente principale utilizza come routine secondaria. Ad esempio, l'agente principale può richiamare un argomento "Traduci testo" come un passaggio in un piano più ampio. Gli agenti inline condividono il contesto con l'agente principale, quindi il passaggio dei dati tra loro è semplice.

Procedura consigliata: mantieni gli agenti inline focalizzati su una sola responsabilità e testali accuratamente.

Agenti connessi

Gli agenti connessi sono agenti separati con la propria orchestrazione, strumenti e conoscenze. L'agente principale delega parte di una richiesta a un agente figlio. Ad esempio, un agente IT contatta un agente di vendita per ottenere informazioni sui prezzi. Gli agenti connessi consentono modularità e separazione dei domini e possono bypassare i limiti del piano. Potrebbero avere privilegi o conoscenze diversi; pertanto, è necessario applicare controlli di governance e controllo.

Tuttavia, l'uso di agenti connessi richiede una governance attenta:

• Orchestrazione: l'orchestratore padre dovrebbe avere criteri chiari su quando effettuare il passaggio a un agente connesso. L'orchestratore effettua il passaggio quando l'intento dell'utente corrisponde al dominio dell'agente connesso. Per supportare questo processo, descrivi chiaramente lo scopo dell'agente connesso nella configurazione del padre. Considera l'intero agente connesso come uno "strumento agentico" con una descrizione, dal punto di vista del padre.

• Passaggio di dati: devi gestire il passaggio di dati. Decidi quale contesto passare dal genitore all'agente connesso. Copilot Studio trasferisce la cronologia delle conversazioni per impostazione predefinita quando un agente chiama un altro, consentendo all'agente collegato di comprendere il contesto precedente della conversazione. Ma potresti dover trasmettere anche parametri specifici. Ad esempio, se l'agente principale conosce già il nome dell'utente da prima, potrebbe inviarlo all'agente connesso per evitare di chiederlo di nuovo.

• Sicurezza: l'agente collegato potrebbe avere accesso a risorse che l'agente padre non ha. Assicurati che chiamare l'agente collegato non aggiri involontariamente le restrizioni. Ad esempio, se l'agente genitore non può cancellare i record ma l'agente connesso può, l'agente genitore non dovrebbe chiamare l'agente connesso in situazioni in cui la cancellazione potrebbe avvenire senza la dovuta approvazione. Tratta una chiamata dell'agente connesso come qualsiasi altra azione potente. Se si tratta di un'operazione sensibile, richiedi i controlli necessari o il consenso dell'utente.

• Audit e monitoraggio: registra quando è stato invocato un agente connesso e cosa ha fatto. Poiché si tratta di un agente separato, hai trascrizioni separate. Per il debug è importante correlare le sessioni padre e quelle connesse. Tipicamente, gli identificatori nella telemetria collegano le due sessioni.

Quando separare gli agenti

Non creare un agente separato per ogni attività secondaria. Usa agenti separati se l'attività secondaria:

• È abbastanza complesso da avere una propria suite di strumenti o conoscenze (campo di competenza diverso)
• Richiede regole di governance o controlli di accesso diversi rispetto all'agente principale
• Può essere riutilizzato in molti agenti principali (quindi è come un agente di servizio)

Se nessuna di queste condizioni si applica, un semplice agente inline potrebbe gestire bene il lavoro, pur essendo più semplice di un agente connesso completo. Gli agenti separati introducono un sovraccarico nel sistema. C'è un tempo di esecuzione leggermente più lungo dovuto al cambio di contesto, e una maggiore complessità nella gestione di più agenti. Quindi utilizzali con giudizio. Per un approccio pratico, inizia con un solo agente. Suddividi in più agenti solo quando vedi chiaramente la necessità di modularità o un confine che un singolo agente non dovrebbe superare.

Procedure consigliate per l'orchestrazione multi-agente

Le seguenti procedure consigliate si applicano quando si redigono istruzioni per agenti padre e agenti secondari in una configurazione multi-agente.

1. Principio di risposta unica

Assicurati che un solo agente parli con l'utente per turno. In una configurazione multi-agente, solo l'agente padre dovrebbe fornire la risposta finale. Gli agenti secondari sono ricercatori, non forniscono risposte.

• Esegui: aggiungi alle istruzioni dell'agente padre: "Sei l'unico agente che comunica con l'utente. Combina i risultati di tutti gli agenti figli in un'unica risposta".
• Non: non lasciare ambiguità. Senza indicazioni esplicite, i agenti secondari rispondono direttamente all'utente, causando messaggi duplicati o parziali.

2. Le istruzioni degli agenti secondari devono dichiarare il loro ruolo

Indica sempre agli agenti figlio che sono agenti figlio. Gli agenti secondari non sanno di far parte di un'orchestrazione. Senza una guida esplicita, si comportano come agenti autonomi e inviano messaggi direttamente all'utente.

• Esegui: aggiungi alle istruzioni di ogni agente secondario: "Sei un agente secondario. NON rispondere direttamente all'utente. Il tuo compito è cercare informazioni e restituire le tue scoperte all'agente padre. L'agente padre gestisce tutta la comunicazione con l'utente".
• Non: supporre che gli agenti secondari capiscano da soli il criterio di orchestrazione.

3. Usa un linguaggio chiaro e diretto nelle istruzioni

Usa sempre un linguaggio direttivo. Evita formulazioni attenuate o cortesi. La piattaforma inserisce istruzioni a livello di sistema utilizzando un linguaggio deciso (DEVI, NON, MAI). Le istruzioni scritte con linguaggio attenuato ("per favore prova a", "dovresti", "sarebbe opportuno") perdono priorità in caso di conflitto.

• Esegui: "MAI rispondere direttamente all'utente. Restituisci SOLO i tuoi risultati".
• Esegui: "Deve esserci esattamente una risposta finale per ogni domanda dell'utente".
• Da non fare: "evita di inviare messaggi all'utente e restituisci invece i tuoi risultati".
• Non: "idealmente, vogliamo una risposta unica combinata".

4. Utilizza una fonte delle informazioni per ogni agente secondario (nessuna sovrapposizione)

Assegna fonti delle informazioni distinte e non sovrapposte a ciascun agente secondario. Se due agenti secondari effettuano una ricerca nella stessa base di conoscenza, uno trova la risposta per primo. Il secondo agente secondario restituisce risultati duplicati oppure salta completamente la ricerca, senza aggiungere valore.

• Esegui: ricerche CA-1 nella fonte delle informazioni A (ad esempio, criteri HR). Ricerche CA-2 nella fonte delle informazioni B (ad esempio, documentazione IT).
• Non: dare a entrambi gli agenti secondari accesso agli stessi documenti, tabelle Dataverse o siti SharePoint.
• Nota: se hai una sola fonte delle informazioni, usa un singolo agente con conoscenza invece di suddividere in due agenti secondari. Il multi-agente aggiunge valore solo quando le fonti sono genuinamente diverse.

5. Usa descrizioni accurate e distinte per gli agenti secondari

Scrivi descrizioni chiare e distinte per ogni agente secondari visibile all'agente padre. L'agente padre utilizza le descrizioni degli agenti secondari per decidere il routing. Se le descrizioni sono vaghe, identiche o inesatte, l'elemento padre non può prendere decisioni adeguate per l'instradamento.

• Esegui: CA-1: "Ricerche nei documenti dei criteri HR per domande relative ai dipendenti." CA-2: "Cerca domande di supporto tecnico nella base di conoscenza IT".
• Non: assegnare la stessa descrizione a entrambi gli agenti quando operano in domini diversi.
• Non: usare descrizioni generiche come "Questo agente può aiutare con le domande".

6. Le istruzioni padre devono definire il modello di orchestrazione

Spiega all'agente padre come orchestrare. Non limitarti a dire "usa agenti figli". L'agente padre ha bisogno di istruzioni esplicite sullo schema da seguire: invocare gli agenti, attendere i risultati, combinarli e poi rispondere.

• Esegui: "Quando l'utente fa una domanda: 1. Richiama entrambi gli agenti figlio per raccogliere informazioni. 2. Attendi che entrambi gli agenti figlio restituiscano i risultati. 3. Combina i risultati in una risposta unica e unificata. 4. Fornisci una sola risposta all'utente. Gli agenti figlio non devono rispondere direttamente all'utente".
• Cose da non fare: "quando l'utente pone una domanda, invoca agenti figlio, ottieni le risposte da entrambe le fonti e fornisci un'unica risposta combinata". Troppo vago: l'istruzione non dice agli agenti figlio di rimanere in silenzio.

7. Includere la direttiva "nessuna risposta diretta" nella delega dell'attività

Anche con istruzioni chiare per gli agenti secondari, l'aggiunta di rinforzi nel contesto dell'attività delegata fornisce una rete di sicurezza.

• Cose da fare: aggiungi alle istruzioni dell'agente padre: "Quando si delega a un agente figlio, includi sempre nell'attività: "restituisci solo i risultati". Non rispondere all'utente".
• Non: affidarti esclusivamente alle istruzioni dell'agente secondario. Il contesto dell'attività fornisce all'agente secondario più segnali che rafforzano il pattern.

8. Verifica con query con dominio non corrispondente

Esegui test sempre con domande che esulano dal dominio di qualsiasi agente secondario. Questo test rivela se gli agenti figlio restituiscono correttamente "nessuna informazione trovata" invece di fornire informazioni potenzialmente errate, bloccarsi o inviare messaggi confusi.

• Esegui: esegui test con query al di fuori di tutti i domini degli agenti secondari (ad esempio, chiedi informazioni sul meteo quando gli agenti gestiscono HR e IT).
• Cose da fare: verifica che il componente padre gestisca correttamente "nessuno dei due agenti ha trovato nulla".
• Non: limitarti a testare solo con domande semplici che corrispondono perfettamente al dominio di un agente secondario.

9. Preferisci la modalità di richiesta rispetto a quella di informazione quando prevedi un completamento

Usa interazioni di tipo richiesta quando ti aspetti che l'utente risponda. Usa esclusivamente lo stile inform/send per messaggi unidirezionali finali. Se l'agente pone una domanda all'utente tramite un messaggio unidirezionale (informare), la risposta dell'utente torna al planner padre come una query completamente nuova. In questo caso è meglio continuare la stessa conversazione con l'agente secondario.

• Esegui: scrivi istruzioni come: "Se hai bisogno di chiarimenti, fai una domanda all'utente e attendi la sua risposta".
• Non: scrivere istruzioni quali: "Informa l'utente sulle opzioni e lascia che sia lui a scegliere". "Informa" indica un messaggio unidirezionale, mentre "chiedi" indica uno scambio bidirezionale.

Elenco di controllo di riferimento rapido

Informazioni correlate

• Panoramica dell'aggiunta di altri agenti
• Aggiungere un agente figlio
• Connettersi a un agente Copilot Studio esistente
• Connettersi a un agente Microsoft Foundry
• Connettersi a un agente Microsoft Fabric Data
• Connettersi a un agente dell'SDK per agenti Microsoft 365
• Connettersi a un agente disponibile tramite il protocollo Agent2Agent (A2A)