Modelli di orchestrazione multi-agente e procedure consigliate

L'orchestrazione generativa supporta anche sistemi multi-agente, in cui un agente chiama altri agenti. Quando si suddivideno i problemi in più agenti specializzati, l'applicazione diventa più modulare, scalabile e gestibile.

Agenti inline

Gli agenti inline, noti anche come child agent, sono piccoli flussi di lavoro riutilizzabili all'interno dello stesso agente. Spesso sono solo argomenti che l'agente principale usa come subroutine. Ad esempio, l'agente principale può definire un argomento "Traduci testo" come un passo in un piano più ampio. Gli agenti inline condividono il contesto con l'agente principale, quindi il passaggio dei dati tra loro è semplice.

Buona pratica: 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 minore. Ad esempio, un agente IT chiama un agente sales per ottenere informazioni sui prezzi. Gli agenti connessi consentono la modularità e la separazione dei domini e possono ignorare i limiti del piano. Potrebbero avere privilegi o conoscenze differenti, quindi applica controlli di governance e audit.

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

• Orchestrazione: L'orchestratore principale dovrebbe avere criteri chiari su quando delegare a un agente connesso. L'agente di orchestrazione in genere si spegne quando la finalità dell'utente corrisponde al dominio dell'agente connesso. Per supportare questo processo, descrivi chiaramente lo scopo dell'agente connesso nella configurazione del genitore. Considera l'intero agente connesso come uno "strumento agentico" con una descrizione, dal punto di vista del padre.

• Passaggio dati: Devi gestire il passaggio di dati. Decidi quale contesto passare dal genitore all'agente connesso. Copilot Studio passa lungo la cronologia delle conversazioni per impostazione predefinita quando un agente chiama un altro, in modo che l'agente connesso comprenda il contesto precedente della conversazione. Ma potresti dover superare 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 chiedere di nuovo.

• Sicurezza: L'agente collegato potrebbe avere accesso a cose che l'agente genitore non ha. Assicurati che la chiamata all'agente connesso 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 di un agente connesso come qualsiasi altra azione potente. Se sta facendo qualcosa di sensibile, sottoponilo ai controlli necessari o al consenso dell'utente.

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

Quando separare gli agenti

Non creare un agente separato per ogni sotto-attività. Usa agenti separati se il sottocompito:

• È 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 diversi (quindi è come un agente del servizio)

Se nessuna di queste condizioni si applica, un semplice agente inline potrebbe gestire correttamente il processo, pur essendo più semplice rispetto a un agente connesso completo. Gli agenti separati introducono un sovraccarico per il sistema. Il tempo di esecuzione è leggermente più lungo a causa del cambio di contesto e della complessità nella gestione di più agenti. Quindi usali con giudizio. Per un approccio pratico, iniziare con un agente. Quindi è possibile suddividere in più agenti solo quando si vede chiaramente la necessità di modularità o un limite che un singolo agente non deve superare.

Procedure consigliate per l'orchestrazione multi-agente

Le procedure consigliate seguenti si applicano quando si creano istruzioni per gli agenti padre e i subagenti in una configurazione multi-agente.

1. Principio di risposta singola

Assicurarsi che solo un agente parli con l'utente a turno. In una configurazione multi-agente, l'agente padre è l'unico che deve fornire la risposta finale. I subagenti sono ricercatori, non risponditori.

• Do: Aggiungi alle istruzioni principali: "Sei l'unico agente che comunica con l'utente." Combina i risultati di tutti gli agenti figli in un'unica risposta".
• Non: lasciarlo ambiguo. Senza indicazioni esplicite, i subagenti rispondono direttamente all'utente, causando messaggi duplicati o parziali.

2. Le istruzioni del subagente devono dichiarare il proprio ruolo

Indica sempre agli agenti figlio che sono agenti figlio. I subagenti non sanno intrinsecamente che fanno parte di un'orchestrazione. Senza indicazioni esplicite, si comportano come agenti autonomi e inviano messaggi direttamente all'utente.

• Do: Aggiungi alle istruzioni di ogni subagente: "Sei un subagente. Non rispondere direttamente all'utente. Il tuo compito è cercare informazioni e restituire i risultati all'agente principale. L'agente padre gestisce tutte le comunicazioni con l'utente."
• Non: dare per scontato che i subagenti capiscano da soli il modello di orchestrazione.

3. Usare un linguaggio chiaro e diretto nelle istruzioni

Usare sempre il linguaggio di direttiva. Evitare formulazioni morbide o educate. La piattaforma inserisce istruzioni a livello di sistema usando un linguaggio sicuro (MUST, DO NOT, NEVER). Le istruzioni scritte con un linguaggio morbido ("si prega di provare a", "dovresti", "sarebbe bene") perdere la priorità quando sono in conflitto.

• Do: "NON rispondere MAI direttamente all'utente. Restituisci solo i risultati.
• Do: "Deve essere presente esattamente una risposta finale per ogni domanda dell'utente".
• Non farlo: "Per favore, cerca di evitare di inviare messaggi all'utente e, invece, restituisci le tue conclusioni."
• Non: "Idealmente, vogliamo una singola risposta combinata".

4. Usa una fonte di conoscenza per ogni subagente (senza sovrapposizioni)

Assegnare origini di conoscenza distinte e non sovrapposte a ogni subagente. Se due subagenti eseguono ricerche nella stessa Knowledge Base, un subagente trova prima la risposta. Il secondo subagente restituisce risultati duplicati oppure salta completamente la ricerca, senza aggiungere alcun valore.

• Do: CA-1 cerca l'origine delle informazioni A (ad esempio, i criteri HR). CA-2 cerca l'origine delle informazioni B (ad esempio, documentazione IT).
• Non: concedere a entrambi i subagenti l'accesso agli stessi documenti, alle tabelle di Dataverse o ai siti di SharePoint.
• Nota: se disponi di un'unica fonte di conoscenza, usa un singolo agente con conoscenza anziché suddividerlo in due sottoagenti. Multi-agent aggiunge valore solo quando le origini sono veramente diverse.

5. Utilizzare descrizioni accurate e distinte per i subagenti

Scrivi descrizioni chiare e distinte per ogni agente secondari visibile all'agente padre. L'agente principale usa le descrizioni dei sottoagenti per determinare l'instradamento. Se le descrizioni sono vaghe, identiche o inesatte, l'elemento padre non può prendere decisioni adeguate per l'instradamento.

• Do: CA-1: "Cerca nei documenti dei criteri HR domande correlate ai dipendenti". CA-2: "Cerca nella Knowledge Base IT domande di supporto tecnico".
• Non: assegnare a entrambi gli agenti la stessa descrizione quando gestiscono domini diversi.
• Non: usare descrizioni generiche come "Questo agente può essere utile per domande".

6. Le istruzioni principali devono definire il modello di orchestrazione

Di' all'agente principale come eseguire l'orchestrazione. 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.

• Do: "Quando l'utente pone una domanda: 1. Richiama entrambi gli agenti figlio per raccogliere informazioni. 2. Attendi che entrambi gli agenti figlio restituiscano i risultati. 3. Combinare i risultati in una singola risposta unificata. 4. Fornire esattamente 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 sul subagente, l'aggiunta di rinforzo nell'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 fare affidamento esclusivamente sulle istruzioni del subagente. Il contesto dell'attività fornisce al subagent più segnali che rafforzano il modello.

8. Verifica con query con dominio non corrispondente

Eseguire sempre test con domande che non corrispondono al dominio di nessun subagente. Questo test rivela se gli agenti figlio restituiscono correttamente "nessuna informazione trovata" invece di fornire informazioni potenzialmente errate, bloccarsi o inviare messaggi confusi.

• Operazione: eseguire il test con query esterne a tutti i domini subagente( ad esempio, chiedere informazioni sul meteo quando gli agenti gestiscono risorse umane e IT).
• Cose da fare: verifica che il componente padre gestisca correttamente "nessuno dei due agenti ha trovato nulla".
• Don't: test solo con le query case più semplici che corrispondono perfettamente al dominio di un subagente.

9. Preferisci fare una domanda piuttosto che informare quando ti aspetti una domanda di follow-up

Usare le interazioni di tipo domanda/domanda quando si prevede che l'utente risponda. Usare lo stile inform/send solo per i messaggi unidirezionale 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 è preferibile continuare la stessa conversazione con il subagent.

• Do: scrivere istruzioni come: "Se hai bisogno di chiarimenti, chiedi all'utente una domanda e attendi la risposta".
• Non: scrivere istruzioni come: "Informare l'utente sulle opzioni e consentire loro di scegliere". "Inform" segnala un messaggio unidirezionale, mentre "ask" segnala uno scambio bidirezionale.

Elenco di controllo di riferimento rapido

Informazioni pertinenti

• Panoramica degli altri agenti
• Aggiungi un agente per bambini
• Connetti a un agente di Copilot Studio esistente
• Connettiti a un agente Microsoft Foundry
• Connetti a un agente dati Microsoft Fabric
• Connetti a un agente Managed Disks
• Collega un agente disponibile tramite il protocollo Agent2Agent (A2A)