Anwendungsfall für agentische KI: Bidirektionales multimodales Livestreaming aktivieren

Last reviewed 2026-10-14 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 der Ausführung technischer Aufgaben wie dem Zusammenbau komplexer Komponenten, der Diagnose von Gerätefehlern oder der Durchführung komplexer Reparaturverfahren. Das agentische KI-System bietet fundierte technische Unterstützung und automatisiertes Sicherheitsmonitoring 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 Unterstützung und Sicherheitsmonitoring.

  • Der Workflow für die technische Unterstützung ermöglicht es Nutzern, in Echtzeit gesprochene Lösungen für komplexe technische Anfragen zu erhalten. In diesem Workflow werden multimodale Streams mit der Gemini Live API verarbeitet und mit einem Subagenten koordiniert, um fundierte Produktinformationen aus der Wissensdatenbank abzurufen.
  • Der Workflow für das Sicherheitsmonitoring bietet eine automatische Gefahrenerkennung, um die Sicherheit der Nutzer bei technischen Verfahren zu gewährleisten. In diesem Workflow werden Live-Video segmente mit Gemini analysiert, potenzielle Risiken identifiziert und über das Client-Dashboard sofort Warnungen ausgelöst.

Auf den folgenden Tabs finden Sie Architekturdiagramme, die die Workflows für die technische Unterstützung und das Sicherheitsmonitoring zeigen:

Workflow für die technische Unterstützung

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

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

Das obige Diagramm zeigt den folgenden Datenfluss:

  1. Ein Nutzer startet eine Sitzung, indem er über das Client-Dashboard eine gesprochene technische Anfrage stellt. Ein Techniker könnte beispielsweise seine Kamera auf ein Steuerfeld 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 Rohdaten von Multimedia 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 Unterstützung erfordern, und sendet den Eingabestream an die Gemini Live API.

  5. Das Gemini Live-Modell durchsucht die Rohdaten nach Ereignissen. 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 werden diese Ereignisse von Gemini nicht verarbeitet.

  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 VPC-Netzwerk (Virtual Private Cloud) zugreifen, das für die Speicherressourcen in dieser Architektur verwendet wird.

    5. Der Connector für serverlosen VPC-Zugriff interagiert mit den im Cache gespeicherten Daten die in Memorystore for Redis Cluster gespeichert sind. 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 empfängt 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 run_live Schleife des ADK, 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 das Sicherheitsmonitoring

Das folgende Diagramm zeigt eine detaillierte Architektur für einen Workflow für das Sicherheitsmonitoring.

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-Videostream zu beobachten. Die WebSocket-Nachricht packt diese Rohdaten von Multimedia in Blob Objekte und sendet sie mit der Komponente des ADK LiveRequestQueue kontinuierlich an den Streaming Puffer.
  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 neueste Videoframe 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, generiert Gemini 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 Streaming puffer weiter.
  6. Der Streamingpuffer verwendet die persistente WebSocket-Verbindung, um die Antwort mit der Gefahrenwarnung an das Client-Dashboard zu senden.
  7. Das Client-Dashboard extrahiert die Blob Daten aus der Antwort mit der Gefahren warnung, 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:

Informationen zum Auswählen alternativer Komponenten für Ihr agentisches KI System, einschließlich Framework, Agent-Laufzeit, Tools, Arbeitsspeicher und Designmustern, 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 ein dynamisches Gespräch, bei dem 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 korrigierenden Anweisungen.

Designaspekte

In diesem Abschnitt werden Designfaktoren, Best Practices und Empfehlungen beschrieben, die Sie berücksichtigen sollten, wenn Sie diese Referenzarchitektur verwenden, um eine Topologie zu entwickeln, die Ihren spezifischen Anforderungen an Sicherheit, Betrieb, Kosten und Leistung entspricht.

Die Anleitung in diesem Abschnitt ist nicht vollständig. Weitere Informationen zu Designfaktoren und Best Practices sowie Empfehlungen zum Erstellen und Bereitstellen eines Multi-Agent-KI-Systems finden Sie unter Multi-Agent-KI-System in Google Cloud.

Sicherheit, Datenschutz und Compliance

Um die besonderen Sicherheitsrisiken von KI-Agenten zu minimieren, empfiehlt Google einen Ansatz der deterministische Sicherheitskontrollen mit dynamischen, auf Schlussfolgerungen basierenden Abwehrmaßnahmen kombiniert:

Betriebliche Effizienz

Damit Ihre Agentenkonfigurationen Ihre Anforderungen an die betriebliche Effizienz erfüllen, empfehlen wir Folgendes:

  • 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 separates Hintergrund-Streamingtool, um Videofeeds unabhängig vom primären Agenten zu überwachen. Der Root-Agent in der Architektur ist bidirektional und kann seine eigene Rede sofort unterbrechen, um diese kritischen Sicherheitshinweise an den Nutzer zu senden. Außerdem kann es zu kognitiver Überlastung und Halluzinationen führen, wenn ein einzelner Agent einen Videofeed ständig überwachen muss.

Kostenoptimierung

Damit Ihre Agentenkonfigurationen Ihre Kostenanforderungen erfüllen, empfehlen wir Folgendes:

  • Datenaufnahme-Kosten: Um 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.
  • Kostengünstige Prompts: Die Länge Ihrer Prompts (Eingabe) und der generierten Antworten (Ausgabe) wirkt sich direkt auf Leistung und Kosten aus. Formulieren Sie kurze, direkte Prompts, die ausreichend Kontext bieten. Entwerfen Sie Ihre Prompts so, dass Sie prägnante Antworten vom Modell erhalten. Verwenden Sie beispielsweise Formulierungen wie „In zwei Sätzen zusammenfassen“ oder „Drei Hauptpunkte auflisten“. Weitere Informationen finden Sie unter Best Practices für das Prompt-Design.

Leistungsoptimierung

Damit Ihre Agentenkonfigurationen Ihre Leistungsanforderungen erfüllen, empfehlen wir Folgendes:

  • 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 Nutzerunterbrechungen reagiert, ohne die Benutzeroberfläche bei rechenintensiven Vorgängen einzufrieren.
  • 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, vermeidet Pausen bei Sprachinteraktionen in Echtzeit und bietet eine skalierbare Single Source of Truth.
  • Ressourcenzuweisung: Konfigurieren Sie je nach Ihren Leistungsanforderungen die Arbeitsspeicher-Limits und CPU -Limits, die dem Cloud Run-Dienst zugewiesen werden sollen.

Bereitstellung

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

Nächste Schritte

Beitragende

Autor*innen:

Weitere Beitragende: