Anwendungsfall für agentische KI: Bidirektionales multimodales Livestreaming aktivieren

Last reviewed 2026-04-06 UTC

In diesem Dokument wird eine allgemeine Architektur für ein bidirektionales Multi-Agent-KI-System in Echtzeit auf beschrieben Google Cloud. Das System unterstützt Nutzer bei technischen Aufgaben wie dem Zusammenbau komplexer Komponenten, der Diagnose von Gerätefehlern oder der Durchführung komplexer Reparaturverfahren. Das agentische KI-System bietet fundierte technische Anleitungen und automatisierte Sicherheitsüberwachung durch einen kontinuierlichen, bidirektionalen Stream multimodaler Daten.

Die Zielgruppe für dieses Dokument umfasst Architekten, Entwickler und Administratoren, die KI-Infrastruktur und ‑Anwendungen in der Cloud erstellen und verwalten. Dabei wird vorausgesetzt, dass Sie über grundlegende Kenntnisse zu KI-Agenten und ‑Modellen verfügen. Das Dokument enthält keine spezifischen Anleitungen zum Entwerfen und Programmieren von KI-Agenten.

Im Abschnitt zur Bereitstellung dieses Dokuments finden Sie Codebeispiele, mit denen Sie erfahren, wie Sie Multi-Agent-KI-Systeme erstellen und bereitstellen.

Architektur

Das folgende Diagramm zeigt eine allgemeine Ansicht einer Architektur, die ein Multi-Agent-KI-System verwendet, um bidirektionales multimodales Datenstreaming in Echtzeit zu ermöglichen:

Übersicht über die Architektur eines Multi-Agenten-KI-Systems, das bidirektionales multimodales Datenstreaming ermöglicht.

Die Architektur im vorherigen Diagramm umfasst zwei Workflows: technische Anleitung und Sicherheitsüberwachung.

  • Der Workflow für die technische Anleitung ermöglicht es Nutzern, in Echtzeit gesprochene Lösungen für komplexe technische Anfragen zu erhalten. In diesem Workflow wird das Gemini Live-Modell verwendet, um multimodale Streams zu verarbeiten und mit einem Subagenten zu koordinieren, um fundierte Produktinformationen aus der Wissensdatenbank abzurufen.
  • Der Workflow für die Sicherheitsüberwachung bietet eine automatisierte Gefahrenerkennung, um die Sicherheit der Nutzer bei technischen Verfahren zu gewährleisten. In diesem Workflow wird Gemini verwendet, um Live-Video segmente zu analysieren, potenzielle Risiken zu identifizieren und über das Client-Dashboard sofort Warnungen auszulösen.

Auf den folgenden Tabs finden Sie Architekturdiagramme, die die Workflows für die technische Anleitung und die Sicherheitsüberwachung zeigen:

Workflow für die technische Anleitung

Das folgende Diagramm zeigt eine detaillierte Architektur für einen Workflow für die technische Anleitung.

Architektur, die den Workflow für die technische Anleitung zeigt.

Das obige Diagramm zeigt den folgenden Datenfluss:

  1. Ein Nutzer initiiert eine Sitzung, indem er über das Client-Dashboard eine gesprochene technische Anfrage stellt. Ein Techniker könnte beispielsweise seine Kamera auf ein Bedienfeld richten und fragen: „Hilfe, was bedeutet dieses blinkende rote Fehlerlicht?“

  2. Das Client-Dashboard stellt eine persistente WebSocket Verbindung zwischen dem Frontend und dem Backend-Server her.

  3. WebSocket-Nachrichten packen die unformatierten Multimediadaten in Blob-Objekte. Die Komponente des Agent Development Kit (ADK) LiveRequestQueue streamt die Eingabedaten kontinuierlich an den Dispatcher Agenten.

  4. Der Dispatcher-Agent erkennt Audio- oder visuelle Befehle, die technische Anleitung erfordern, und sendet den Eingabestream an das Gemini Live Modell.

  5. Das Gemini Live-Modell durchsucht die Rohdaten, um Ereignisse zu identifizieren. Ereignisse sind Audio-Keywords wie „zusammenbauen“ oder „Hilfe“ oder visuelle Hinweise wie Handgesten.

    Gemini wertet jedes Ereignis aus, um festzustellen, ob es für die Anfrage des Nutzers relevant ist. Eine Handgeste oder Füllwörter sind beispielsweise möglicherweise nicht relevant. Daher verarbeitet Gemini diese Ereignisse nicht.

  6. Für jedes relevante Ereignis aktiviert Gemini den Funktions aufruf, um zu prüfen, ob zusätzlicher Kontext erforderlich ist. Je nachdem, ob zusätzlicher Kontext erforderlich ist, sendet entweder Gemini oder ein Architekten-Agent eine Antwort an den Dispatcher-Agenten.

    1. Wenn mehr Kontext erforderlich ist, sucht Gemini die Karte des Architekten Agenten Karte, um zu erfahren, wie die Anfrage strukturiert werden muss.

    2. Gemini sendet eine strukturierte Anfrage an den Dispatcher-Agenten. Die Anfrage enthält Ereignisdetails wie Produkttyp, Modellnummer, Ereignistyp und Attribute.

    3. Der Dispatcher-Agent verwendet das Agent2Agent-Protokoll (A2A) um die strukturierte Anfrage an den Architekten-Agenten zu senden.

    4. Der Architekten-Agent sendet die Abfrage über einen Connector für serverlosen VPC-Zugriff . Mit dem Connector kann der Agent sicher auf Ressourcen im Virtual Private Cloud-Netzwerk (VPC) zugreifen, das für die Speicherressourcen in dieser Architektur verwendet wird.

    5. Der Connector für serverlosen VPC-Zugriff interagiert mit den im Memorystore for Redis-Cluster gespeicherten Cache-Daten. Wenn die Daten in der Cache-Ebene nicht verfügbar sind, interagiert der Architekten-Agent mit den Compute Engine-Instanzen, die die Wissensdatenbank hosten.

    6. Der Architekten-Agent erhält die Produktinformationen aus dem Datencache oder der Wissensdatenbank. Der Architekten-Agent sendet die Produktinformationen an Gemini, um eine Antwort zu generieren. Beispiel: „Fehlercode 3B: Lüfter defekt. Empfohlene Maßnahme: Auf Verstopfungen prüfen.“

    7. Der Architekten-Agent sendet die Produktinformationen zurück an den Dispatcher-Agenten.

    Wenn kein zusätzlicher Kontext erforderlich ist, generiert Gemini direkt eine Antwort auf die Anfrage des Nutzers.

  7. Der Dispatcher-Agent empfängt die Antwort von Gemini oder vom Architekten-Agenten und generiert eine multimodale Antwort:

    1. Verwendet das Gemini Live-Modell und die ADK run_live Funktion, um eine multimodale Antwort mit der technischen Lösung zu generieren.

    2. Speichert die Antwort als Blob-Objekt.

    3. Sendet die technische Lösung über den Streamingpuffer und die persistente WebSocket-Verbindung an das Client-Dashboard.

  8. Das Client-Dashboard extrahiert die Blob-Daten aus der technischen Lösung, um sofort eine gesprochene Anleitung zu geben, und aktualisiert die Benutzeroberfläche mit relevanten Transkriptionen. Die Anfrageschleife wird abgeschlossen, während der aktive bidirektionale Stream beibehalten wird.

Workflow für die Sicherheitsüberwachung

Das folgende Diagramm zeigt eine detaillierte Architektur für einen Workflow für die Sicherheitsüberwachung.

Architektur, die den Workflow für die Sicherheitsüberwachung zeigt.

Das obige Diagramm zeigt den folgenden Datenfluss:

  1. Das Client-Dashboard stellt eine persistente WebSocket Verbindung zwischen dem Frontend und dem Backend-Server her, um den Live-Video Stream zu beobachten. Die WebSocket-Nachricht packt diese unformatierten Multimediadaten in Blob Objekte und sendet sie mit der ADK LiveRequestQueue-Komponente kontinuierlich an den Streamingpuffer.
  2. Der Streamingpuffer leitet den Eingabestream an ein Streaming Tool weiter, das in einer kontinuierlichen Hintergrundschleife ausgeführt wird, um Gefahren im Videobild zu erkennen.
  3. Das Streamingtool sendet das letzte Videobild aus dem Streamingpuffer an Gemini.
  4. Gemini beobachtet die Videobilder auf Gefahren wie helles Licht oder Dampf.
    • Wenn keine Gefahr erkannt wird, passiert nichts.
    • Wenn eine Gefahr erkannt wird, Gemini generiert eine multimodale Antwort mit dem Gefahrentyp, den Attributen und dem Standort und speichert sie als Blob Objekt. Gemini sendet die Antwort mit der Gefahrenwarnung zurück an das Streamingtool.
  5. Das Streamingtool leitet die Antwort mit der Gefahrenwarnung an den Streamingpuffer weiter.
  6. Der Streamingpuffer verwendet die persistente WebSocket-Verbindung, um die technische Lösung an das Client-Dashboard zu senden.
  7. Das Client-Dashboard extrahiert die Blob Daten aus der technischen Lösung, um sofort eine gesprochene Anleitung zu geben, und aktualisiert die Benutzeroberfläche mit relevanten Transkriptionen. Dadurch wird die Anfrageschleife abgeschlossen, während der aktive bidirektionale Stream beibehalten wird.

Verwendete Produkte

In dieser Referenzarchitektur werden die folgenden Google Cloud Produkte und Tools verwendet:

  • Cloud Run: Eine serverlose Computing-Plattform, mit der Sie Container direkt auf der skalierbaren Infrastruktur von Google ausführen können.
  • Gemini: Eine Familie multimodaler KI-Modelle, entwickelt von Google.
  • Vertex AI: Eine ML-Plattform, mit der Sie ML-Modelle und KI-Anwendungen trainieren und bereitstellen und LLMs für die Verwendung in KI-basierten Anwendungen anpassen können.
  • Agent Development Kit (ADK): Eine Sammlung von Tools und Bibliotheken zum Entwickeln, Testen und Bereitstellen von KI-Agenten.
  • Das Agent2Agent-Protokoll (A2A): Ein offenes Protokoll, das die Kommunikation und Interoperabilität zwischen Agenten unabhängig von ihrer Programmiersprache und Laufzeit ermöglicht.
  • Serverless VPC Access: Der serverlose VPC-Zugriff ist ein Dienst, mit dem Ihre serverlosen Umgebungen eine Verbindung zu Ressourcen in einem Virtual Private Cloud-Netzwerk herstellen können.
  • Virtual Private Cloud (VPC) ist ein virtuelles System, das globale, skalierbare Netzwerkfunktionen für Ihre Google Cloud Arbeitslasten bietet. VPC umfasst VPC-Netzwerk-Peering, Private Service Connect, Zugriff auf private Dienste und freigegebene VPC.
  • Memorystore for Redis Cluster: Ein vollständig verwalteter In-Memory-Datenspeicherdienst für Redis.
  • Compute Engine: Ein sicherer und anpassbarer Computing-Dienst, mit dem Sie virtuelle Maschinen in der Infrastruktur von Google erstellen und ausführen können.

Informationen zum Auswählen alternativer Komponenten für Ihr agentisches KI System, einschließlich Framework, Agent-Laufzeit, Tools, Arbeitsspeicher und Designmuster, finden Sie unter Komponenten für agentische KI-Architektur auswählen.

Anwendungsfall

Diese Referenzarchitektur ist für Anwendungsfälle konzipiert, die die Echtzeitsynthese kontinuierlicher, bidirektionaler multimodaler Datenstreams erfordern. Im Folgenden finden Sie Beispiele für Anwendungsfälle für die in diesem Dokument beschriebene Architektur:

  • Industrielle Fertigung und Außendienst: Ermöglichen Sie die Reparatur komplexer Maschinen per Sprachbefehl, indem Sie Technikern einen KI-Assistenten zur Verfügung stellen, der Live-Audio und ‑Video von Smart Glasses verarbeitet. Der Techniker unterhält sich mit dem KI-Assistenten, um Maschinenschemas abzurufen. Der KI-Assistent verwendet einen internen Datenbank-Agenten, der auf die Produktdokumentation zugreift, um fundierte Reparatur- und Montageanleitungen zu erhalten. Ein gleichzeitiges Hintergrund-Vision-Tool überwacht den bidirektionalen Stream, um den Techniker proaktiv vor mechanischen Gefahren oder falschen Montageschritten zu warnen.
  • Technischer Remote-Support: Verbessern Sie die Ergebnisse der Fehlerbehebung für Kunden, indem Sie Nutzern ermöglichen, einen Live-Feed der Telefonkamera mit einem multimodalen agentischen KI-System zu teilen. Die bidirektionale Streamingarchitektur unterstützt eine dynamische Unterhaltung, bei der das System die Hardware in Echtzeit beobachtet. Wenn ein Hintergrund-Vision-Prozess eine fehlerhafte Verbindung erkennt, z. B. ein Kabel im falschen Anschluss, unterbricht das System den Nutzer sofort mit einer korrigierenden Anleitung.

Designaspekte

In den folgenden Abschnitten finden Sie allgemeine Empfehlungen zum Entwerfen der KI-Agenten und zum Implementieren dieser Architektur für die Produktion.

KI-Agent-Design

Beachten Sie die folgenden Empfehlungen, um die Kosten und die Leistung Ihrer Agenten zu verbessern:

  • Skripts für Kontrollschleifen: Schreiben Sie Systemprompts für bidirektionale Live-Agenten als strenge Zustandsautomaten-Verhaltensschleifen und nicht nur als Richtlinien für die Persönlichkeit. Der Systemprompt sollte den Agenten explizit anweisen, stumm zu bleiben, bis er ausgelöst wird. Er sollte kurze Antworten erzwingen, bei denen die Aktion im Vordergrund steht, damit die Sprachinteraktion prägnant und natürlich ist.
  • Trennung von Zuständigkeiten: Verwenden Sie ein spezielles Hintergrund-Streamingtool, um Videofeeds unabhängig vom primären Agenten zu überwachen. Der Root-Agent in der Architektur ist bidirektional und kann seine eigene Sprache sofort unterbrechen, um diese kritischen Sicherheitswarnungen an den Nutzer zu senden. Wenn Sie einen einzelnen Agenten bitten, einen Videofeed ständig zu überwachen, kann dies außerdem zu kognitiver Überlastung und Halluzinationen führen.
  • Kostengünstige Prompts: Die Länge Ihrer Prompts (Eingabe) und der generierten Antworten (Ausgabe) wirken sich direkt auf die Leistung und die Kosten aus. Formulieren Sie Prompts, die kurz und direkt sind und ausreichend Kontext bieten. Entwerfen Sie Ihre Prompts so, dass Sie prägnante Antworten vom Modell erhalten. Fügen Sie beispielsweise Formulierungen wie „In zwei Sätzen zusammenfassen“ oder „Drei Hauptpunkte auflisten“ ein. Weitere Informationen finden Sie unter Best Practices für das Prompt-Design.

Produktionsdesign

Beachten Sie die folgenden Empfehlungen, um diese Architektur für die Produktion zu implementieren:

  • Ingress-Sicherheit: Um den Zugriff auf die Anwendung zu steuern, deaktivieren Sie die Standard-URL run.app des Frontend-Cloud Run-Dienstes und richten Sie einen regionalen externen Application Load Balancer ein. Der Load Balancer verteilt nicht nur den eingehenden Traffic auf die Anwendung, sondern verwaltet auch SSL-Zertifikate. Für zusätzlichen Schutz können Sie Google Cloud Armor-Sicherheitsrichtlinien verwenden, um die Anfragen für den Dienst zu filtern, DDoS-Schutz zu bieten und die Ratenbegrenzung zu ermöglichen.
  • Zugriffssteuerung: Wenn Sie Berechtigungen für die Ressourcen in Ihrer Topologie konfigurieren, folgen Sie dem Prinzip der geringsten Berechtigung.
  • Asynchrone Pufferung: Um eingehende Audio- und Videopakete von der Inferenz-Engine des Modells zu entkoppeln, verwenden Sie einen threadsicheren, asynchronen FIFO-Puffer (First-In-First-Out). Dieser Puffer fungiert als Multiplexer, der dafür sorgt, dass das System auf Unterbrechungen durch Nutzer reagiert, ohne die Benutzeroberfläche bei rechenintensiven Vorgängen einzufrieren.
  • Kosten für die Datenaufnahme: Um die Tokenkosten zu senken und die Erschöpfung des Kontextfensters zu vermeiden, verwenden Sie eine Frame-Samplingrate mit niedriger Frequenz, z. B. 2 Bilder pro Sekunde, und komprimieren Sie alle Daten in Base64-JPEG-Dateien.
  • In-Memory-Caching: Um Lesegeschwindigkeiten im Submillisekundenbereich zu erreichen, verwenden Sie eine In-Memory Memorystore for Redis Cluster Datenbank für den Schemaspeicher des Architekten-Agenten. Diese Implementierung minimiert die Latenz, verhindert Pausen bei Sprachinteraktionen in Echtzeit und bietet eine skalierbare Single Source of Truth.
  • WebSocket-Sicherheit: Schützen Sie sensible multimodale Daten wie Stimm abdrücke und Videos, indem Sie die TLS-Verschlüsselung für alle bidirektionalen WebSocket-Verbindungen erzwingen.
  • Sichere A2A-Kommunikation:
  • Ressourcenzuweisung: Konfigurieren Sie je nach Leistungsanforderungen die Arbeitsspeicher- und CPU -Limits, die dem Cloud Run-Dienst zugewiesen werden sollen.

Weitere Informationen zu Designfaktoren, Best Practices und Empfehlungen zum Erstellen und Bereitstellen eines Multi-Agent-KI-Systems finden Sie unter Multi-Agent-KI-System in Google Cloud.

Bereitstellung

Wenn Sie eine Beispielimplementierung dieser Architektur bereitstellen möchten, probieren Sie die folgenden Codelabs aus:

Nächste Schritte

Beitragende

Autor*innen:

Weitere Beitragende: