Caso d'uso dell'AI agentica: abilitare lo streaming multimodale bidirezionale live

Last reviewed 2026-04-06 UTC

Questo documento fornisce un'architettura di alto livello per un sistema di AI multi-agente bidirezionale live su Google Cloud. Il sistema aiuta gli utenti a completare attività tecniche, come l'assemblaggio di componenti complessi, la diagnosi di malfunzionamenti delle apparecchiature o la navigazione in procedure di riparazione complesse. Il sistema di AI agente fornisce indicazioni tecniche basate su dati reali e monitoraggio automatico della sicurezza tramite un flusso continuo e bidirezionale di dati multimodali.

Il pubblico di destinazione di questo documento include architetti, sviluppatori e amministratori che creano e gestiscono infrastrutture e applicazioni di AI nel cloud. Questo documento presuppone che tu abbia una conoscenza di base degli agenti e dei modelli di AI. Il documento non fornisce indicazioni specifiche per la progettazione e la codifica degli agenti AI.

La sezione Deployment di questo documento elenca esempi di codice che puoi utilizzare per imparare a creare e implementare sistemi di AI multi-agente.

Architettura

Il seguente diagramma mostra una visione di alto livello di un'architettura che utilizza un sistema di AI multi-agente per abilitare lo streaming di dati multimodali bidirezionali in tempo reale:

Architettura di alto livello di un sistema di AI multi-agente che consente lo streaming bidirezionale di dati multimodali.

L'architettura nel diagramma precedente ha due flussi di lavoro: indicazioni tecniche e monitoraggio della sicurezza.

  • Il workflow di assistenza tecnica consente agli utenti di ricevere soluzioni narrate in tempo reale a domande tecniche complesse. Questo flusso di lavoro utilizza il modello Gemini Live per elaborare flussi multimodali e coordinarsi con un subagente per recuperare informazioni sui prodotti fondate dal database delle conoscenze.
  • Il flusso di lavoro di monitoraggio della sicurezza fornisce il rilevamento automatico dei pericoli per garantire la sicurezza dell'utente durante le procedure tecniche. Questo workflow utilizza Gemini per analizzare i segmenti video in diretta, identificare potenziali rischi e attivare avvisi immediati tramite la dashboard del client.

Le seguenti schede forniscono diagrammi dell'architettura che mostrano le indicazioni tecniche e i flussi di lavoro di monitoraggio della sicurezza:

Flusso di lavoro per la consulenza tecnica

Il seguente diagramma mostra un'architettura dettagliata per un flusso di lavoro di indicazioni tecniche.

Architettura che mostra il flusso di lavoro della guida tecnica.

Il diagramma precedente mostra il seguente flusso di dati:

  1. Un utente avvia una sessione ponendo una domanda tecnica tramite comando vocale tramite la dashboard del cliente. Ad esempio, un tecnico potrebbe puntare la videocamera verso un pannello di controllo e chiedere: "Aiuto, cosa significa questa spia di errore rossa lampeggiante?"

  2. La dashboard client stabilisce una connessione WebSocket persistente tra il frontend e il server di backend.

  3. I messaggi WebSocket raggruppano i dati multimediali non elaborati in oggetti Blob. Il componente Agent Development Kit (ADK) LiveRequestQueue trasmette continuamente i dati di input all'agente dispatcher.

  4. L'agente dispatcher rileva i comandi audio o visivi che richiedono indicazioni tecniche e invia il flusso di input al modello Gemini Live.

  5. Il modello Gemini Live esamina i dati non elaborati per identificare gli eventi. Gli eventi sono parole chiave audio, come "assembla" o "aiuto", o segnali visivi, come i gesti delle mani.

    Gemini valuta ogni evento per determinare se è pertinente alla richiesta dell'utente. Ad esempio, un gesto con la mano o le parole di riempimento potrebbero non essere pertinenti, pertanto Gemini non elabora questi eventi.

  6. Per ogni evento pertinente, Gemini attiva la chiamata di funzione per valutare se ha bisogno di un contesto aggiuntivo. A seconda che sia necessario un contesto aggiuntivo, Gemini o un agente architetto invia una risposta all'agente dispatcher.

    1. Se ha bisogno di più contesto, Gemini cerca la scheda dell'agente per capire come strutturare la richiesta.

    2. Gemini invia una richiesta strutturata all'agente di distribuzione. La richiesta contiene i dettagli dell'evento, come tipo di prodotto, numero di modello, tipo di evento e attributi.

    3. L'agente dispatcher utilizza il protocollo Agent2Agent (A2A) per inviare la richiesta strutturata all'agente architetto.

    4. L'agente architetto invia la query tramite un connettore di accesso VPC serverless . Il connettore consente all'agente di accedere in modo sicuro alle risorse nella rete Virtual Private Cloud (VPC) utilizzata per le risorse di archiviazione in questa architettura.

    5. Il connettore di accesso VPC serverless interagisce con i dati memorizzati nella cache archiviati in Memorystore for Redis Cluster. Se i dati non sono disponibili nel livello memorizzato nella cache, l'agente architetto interagisce con le istanze Compute Engine che ospitano il database delle conoscenze.

    6. L'agente architetto riceve le informazioni sul prodotto dalla cache dei dati o dal database delle conoscenze. L'agente architetto invia le informazioni sul prodotto a Gemini per generare una risposta. Ad esempio, "Codice di errore 3B: malfunzionamento ventola. Comportamento consigliato: controlla che non ci siano ostruzioni.

    7. L'agente architetto invia le informazioni sul prodotto all'agente dispatcher.

    Se non ha bisogno di altro contesto, Gemini genera una risposta alla richiesta dell'utente direttamente.

  7. L'agente dispatcher riceve la risposta da Gemini o dall'agente di architettura e genera una risposta multimodale:

    1. Utilizza il modello Gemini Live e la funzione ADK run_live per generare una risposta multimodale che contenga la soluzione tecnica.

    2. Memorizza la risposta come oggetto Blob.

    3. Invia la soluzione tecnica tramite il buffer di streaming e la connessione WebSocket persistente per fornire la soluzione tecnica alla dashboard del client.

  8. La dashboard del cliente estrae i dati Blob dalla soluzione tecnica per fornire indicazioni immediate con voce narrante e aggiorna la UI con le trascrizioni pertinenti. Il ciclo di richiesta viene completato mentre viene mantenuto il flusso bidirezionale attivo.

Flusso di lavoro di monitoraggio della sicurezza

Il seguente diagramma mostra un'architettura dettagliata per un flusso di lavoro di monitoraggio della sicurezza.

Architettura che mostra il flusso di lavoro di monitoraggio della sicurezza.

Il diagramma precedente mostra il seguente flusso di dati:

  1. La dashboard client stabilisce una connessione WebSocket persistente tra il frontend e il server di backend per osservare lo stream video live. Il pacchetto di messaggi WebSocket raggruppa questi dati multimediali non elaborati in oggetti Blob e li invia continuamente al buffer di streaming, utilizzando il componente ADK LiveRequestQueue.
  2. Il buffer di streaming indirizza il flusso di input a uno strumento di streaming che viene eseguito in un ciclo continuo in background per rilevare i pericoli nel frame video.
  3. Lo strumento di streaming invia l'ultimo frame video dal buffer di streaming a Gemini.
  4. Gemini osserva i fotogrammi del video per rilevare pericoli, come una luce intensa o vapore.
    • Se non viene rilevato alcun pericolo, non succede nulla.
    • Se viene rilevato un pericolo, Gemini genera una risposta multimodale contenente il tipo di pericolo, gli attributi, la sua posizione e la memorizza come oggetto Blob. Gemini invia la risposta di avviso di pericolo allo strumento di streaming.
  5. Lo strumento di streaming inoltra la risposta di avviso di pericolo al buffer di streaming.
  6. Il buffer di streaming utilizza la connessione WebSocket persistente per fornire la soluzione tecnica alla dashboard del client.
  7. La dashboard del cliente estrae i dati Blob dalla soluzione tecnica per fornire indicazioni e aggiornamenti immediati e aggiorna la UI con le trascrizioni pertinenti. In questo modo si completa il ciclo di richieste mantenendo attivo il flusso bidirezionale.

Prodotti utilizzati

Questa architettura di riferimento utilizza i seguenti prodotti e strumenti: Google Cloud

  • Cloud Run: una piattaforma di computing serverless che ti consente di eseguire container direttamente sull'infrastruttura scalabile di Google.
  • Gemini: una famiglia di modelli di AI multimodale sviluppati da Google.
  • Vertex AI: una piattaforma ML che ti consente di addestrare ed eseguire il deployment di modelli ML e applicazioni AI e personalizzare LLM da utilizzare nelle applicazioni basate sull'AI.
  • Agent Development Kit (ADK): un insieme di strumenti e librerie per sviluppare, testare e implementare agenti AI.
  • Protocollo Agent2Agent (A2A): un protocollo aperto che consente la comunicazione e l'interoperabilità tra gli agenti indipendentemente dal linguaggio di programmazione e dal runtime.
  • Accesso VPC serverless: un servizio che consente agli ambienti serverless di connettersi alle risorse in una rete Virtual Private Cloud.
  • Virtual Private Cloud (VPC): un sistema virtuale che fornisce funzionalità di rete globali e scalabili per i tuoi Google Cloud carichi di lavoro. VPC include il peering di rete VPC, Private Service Connect, l'accesso privato ai servizi e VPC condiviso.
  • Memorystore for Redis Cluster: un servizio di datastore in memoria completamente gestito per Redis.
  • Compute Engine: un servizio di calcolo sicuro e personalizzabile che ti consente di creare ed eseguire VM sull'infrastruttura di Google.

Per informazioni sulla selezione di componenti alternativi per il tuo sistema di AI agentica, inclusi framework, runtime dell'agente, strumenti, memoria e pattern di progettazione, consulta Scegliere i componenti dell'architettura di AI agentica.

Caso d'uso

Questa architettura di riferimento è progettata per casi d'uso che richiedono la sintesi in tempo reale di flussi di dati multimodali continui e bidirezionali. Di seguito sono riportati esempi di casi d'uso per l'architettura descritta in questo documento:

  • Produzione industriale e manutenzione sul campo: consente la riparazione a mani libere di macchinari complessi fornendo ai tecnici un assistente AI che elabora audio e video in diretta dagli occhiali smart. Il tecnico conversa con l'assistente AI per recuperare gli schemi della macchina. L'assistente AI utilizza un agente di database interno che accede alla documentazione del prodotto per garantire istruzioni di riparazione e assemblaggio basate su dati reali. Uno strumento di visione in background simultaneo monitora il flusso bidirezionale per avvisare in modo proattivo il tecnico di pericoli meccanici o passaggi di assemblaggio errati.
  • Assistenza tecnica remota: migliora i risultati della risoluzione dei problemi dei clienti consentendo agli utenti di condividere un feed videocamera live dello smartphone con un sistema di AI agentica multimodale. L'architettura di streaming bidirezionale supporta una conversazione dinamica in cui il sistema osserva l'hardware in tempo reale. Se un processo di visione in background identifica una connessione difettosa, ad esempio un cavo nella porta sbagliata, il sistema utilizza lo stream a bassa latenza per interrompere immediatamente l'utente con indicazioni correttive.

Considerazioni sulla progettazione

Le sezioni seguenti forniscono consigli generali per la progettazione degli agenti AI e l'implementazione di questa architettura per la produzione.

Progettazione di agenti AI

Per migliorare il costo e il rendimento dei tuoi agenti, tieni presenti i seguenti consigli:

  • Script del ciclo di controllo: scrivi prompt di sistema per agenti live bidirezionali come cicli di comportamento rigidi della macchina a stati anziché semplici linee guida per la personalità. Il prompt di sistema deve indicare esplicitamente all'agente di rimanere in silenzio finché non viene attivato. Deve imporre risposte brevi e orientate all'azione in modo che l'interazione vocale sia concisa e naturale.
  • Separazione delle competenze: utilizza uno strumento di streaming in background dedicato per monitorare i feed video indipendentemente dall'agente principale. L'agente principale nell'architettura è bidirezionale e può interrompere immediatamente il proprio discorso per trasmettere all'utente questi avvisi di sicurezza critici. Inoltre, se chiedi a un singolo agente di monitorare costantemente un feed video, ciò può portare a un sovraccarico cognitivo e a delle allucinazioni.
  • Prompt convenienti: la lunghezza dei prompt (input) e delle risposte generate (output) influisce direttamente su prestazioni e costi. Scrivi prompt brevi, diretti e che forniscano un contesto sufficiente. Progetta i prompt per ottenere risposte concise dal modello. Ad esempio, includi frasi come "riassumi in due frasi" o "elenca tre punti chiave". Per saperne di più, consulta le best practice per la progettazione dei prompt.

Scenografia

Per implementare questa architettura per la produzione, considera i seguenti consigli:

  • Sicurezza in entrata: per controllare l'accesso all'applicazione, disattiva l'URL run.app predefinito del servizio Cloud Run frontend e configura un bilanciatore del carico delle applicazioni esterno regionale. Oltre a bilanciare il carico del traffico in entrata verso l'applicazione, il bilanciatore del carico gestisce i certificati SSL. Per una maggiore protezione, puoi utilizzare i criteri di sicurezza di Google Cloud Armor per fornire il filtraggio delle richieste, la protezione dagli attacchi DDoS e limitazione di frequenza per il servizio.
  • Controllo dell'accesso: quando configuri le autorizzazioni per le risorse nella tua topologia, segui il principio del privilegio minimo.
  • Buffer asincrono: per separare i pacchetti audio e video in entrata dal motore di inferenza del modello, utilizza un buffer FIFO (First-In-First-Out) asincrono e thread-safe. Questo buffer funge da multiplexer che garantisce che il sistema rimanga reattivo alle interruzioni dell'utente senza bloccare l'interfaccia utente durante i calcoli pesanti.
  • Costi di importazione dei dati: per ridurre i costi dei token ed evitare l'esaurimento della finestra contestuale, utilizza un campionamento dei frame a bassa frequenza, ad esempio 2 frame al secondo, e comprimi tutti i dati in file JPEG Base64.
  • Memorizzazione nella cache in memoria: per ottenere velocità di lettura inferiori al millisecondo, utilizza un database Memorystore for Redis Cluster in memoria per il vault schematico dell'agente architetto. Questa implementazione riduce al minimo la latenza, impedisce i silenzi durante le interazioni vocali in tempo reale e fornisce un'unica fonte attendibile scalabile.
  • Sicurezza WebSocket: proteggi i dati multimodali sensibili, come le impronte vocali e i video, applicando la crittografia TLS per tutte le connessioni WebSocket bidirezionali.
  • Comunicazione A2A sicura:
  • Allocazione delle risorse: a seconda dei requisiti di prestazioni, configura i limiti di memoria e i limiti di CPU da allocare al servizio Cloud Run.

Per saperne di più su fattori di progettazione, best practice e consigli per la creazione e l'implementazione di un sistema di AI multi-agente, consulta Sistema di AI multi-agente in Google Cloud.

Deployment

Per eseguire il deployment di un'implementazione di esempio di questa architettura, prova i seguenti Codelab:

Passaggi successivi

Collaboratori

Autori:

Altri collaboratori: