Anwendungsfall für agentische KI: Bidirektionales multimodales Livestreaming aktivieren

Last reviewed 2026-04-06 UTC

Dieses Dokument bietet eine allgemeine Architektur für ein bidirektionales Multi-Agent-KI-System auf Google Cloud. Das System unterstützt Nutzer bei der Erledigung technischer Aufgaben, z. B. beim Zusammenbau komplizierter Komponenten, bei der Diagnose von Gerätefehlfunktionen oder bei der Durchführung komplexer Reparaturen. 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. In diesem Dokument wird davon ausgegangen, 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-Agents.

Im Abschnitt Bereitstellung dieses Dokuments finden Sie Codebeispiele, mit denen Sie lernen können, wie Sie KI-Systeme mit mehreren Agents erstellen und bereitstellen.

Architektur

Das folgende Diagramm zeigt eine allgemeine Ansicht einer Architektur, die ein KI-System mit mehreren Agents verwendet, um bidirektionales Multimodaldaten-Streaming 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 hat zwei Workflows: technische Anleitung und Sicherheitsüberwachung.

  • Mit dem Workflow für technische Unterstützung können Nutzer in Echtzeit gesprochene Lösungen für komplexe technische Anfragen erhalten. In diesem Workflow wird das Gemini Live-Modell verwendet, um multimodale Streams zu verarbeiten und mit einem untergeordneten Agent zusammenzuarbeiten, um fundierte Produktinformationen aus der Wissensdatenbank abzurufen.
  • Der Workflow für die Sicherheitsüberwachung bietet eine automatische Gefahrenerkennung, um die Sicherheit der Nutzer bei technischen Verfahren zu gewährleisten. In diesem Workflow wird Gemini verwendet, um Live-Videosegmente zu analysieren, potenzielle Risiken zu erkennen und über das Client-Dashboard sofort Warnungen auszulösen.

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

Workflow für die technische Anleitung

Das folgende Diagramm zeigt eine detaillierte Architektur für einen Workflow mit technischer Anleitung.

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 Bedienfeld richten und fragen: „Hilfe, was bedeutet dieses blinkende rote Fehlerlicht?“

  2. Im Client-Dashboard wird eine dauerhafte WebSocket-Verbindung zwischen dem Frontend und dem Backend-Server hergestellt.

  3. Bei WebSocket-Nachrichten werden die Multimedia-Rohdaten in Blob-Objekte verpackt. Die ADK-Komponente (Agent Development Kit) LiveRequestQueue streamt die Eingabedaten kontinuierlich an den Dispatcher-Agent.

  4. Der Dispatcher-Agent erkennt Audio- oder visuelle Befehle, die technische Unterstützung 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-Schlüsselwörter wie „montieren“ oder „Hilfe“ oder visuelle Hinweise wie Handbewegungen.

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

  6. Für jedes relevante Ereignis ermöglicht Gemini den Funktionsaufruf, um zu prüfen, ob zusätzlicher Kontext erforderlich ist. Je nachdem, ob zusätzlicher Kontext erforderlich ist, sendet entweder Gemini oder ein Architect-Agent eine Antwort an den Dispatcher-Agent zurück.

    1. Wenn mehr Kontext erforderlich ist, ruft Gemini die Agent-Karte des Architekten auf, um zu erfahren, wie die Anfrage strukturiert werden muss.

    2. Gemini sendet eine strukturierte Anfrage an den Dispatcher-Agent. 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 Architect-Agent zu senden.

    4. Der Architect-Agent sendet die Anfrage über einen Connector für serverlosen VPC-Zugriff . Der Connector ermöglicht dem Agent den sicheren Zugriff auf Ressourcen im VPC-Netzwerk (Virtual Private Cloud), 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 Architect-Agent mit den Compute Engine-Instanzen, auf denen die Wissensdatenbank gehostet wird.

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

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

    Wenn kein weiterer 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 Architektur-Agenten und generiert eine multimodale Antwort:

    1. Verwendet das Gemini Live-Modell und die ADK-Funktion run_live, 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. Im Client-Dashboard werden die Blob-Daten aus der technischen Lösung extrahiert, um sofortige gesprochene Anleitungen zu geben. Außerdem wird die Benutzeroberfläche mit relevanten Transkriptionen aktualisiert. Die Anforderungsschleife wird abgeschlossen, während der aktive bidirektionale Stream aufrechterhalten wird.

Workflow für das Sicherheitsmonitoring

Das folgende Diagramm zeigt eine detaillierte Architektur für einen Workflow zur 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 dauerhafte WebSocket-Verbindung zwischen dem Frontend und dem Backend-Server her, um den Live-Videostream zu beobachten. Die WebSocket-Nachricht verpackt diese Roh-Multimediadaten in Blob-Objekte und sendet sie kontinuierlich an den Streamingpuffer. Dazu wird die ADK-Komponente LiveRequestQueue verwendet.
  2. Der Streamingpuffer leitet den Eingabestream an ein Streamingtool weiter, das in einer kontinuierlichen Hintergrundschleife ausgeführt wird, um Gefahren im Videobild zu erkennen.
  3. Das Streaming-Tool sendet den letzten Videoframes aus dem Streaming-Puffer an Gemini.
  4. Gemini analysiert die Videoframes 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 Streaming-Tool.
  5. Das Streaming-Tool leitet die Antwort auf die Gefahrenwarnung an den Streaming-Puffer weiter.
  6. Der Streamingpuffer verwendet die persistente WebSocket-Verbindung, um die technische Lösung an das Client-Dashboard zu senden.
  7. Im Client-Dashboard werden die Blob-Daten aus der technischen Lösung extrahiert, um sofortige gesprochene Anleitungen zu geben und die Benutzeroberfläche mit relevanten Transkriptionen zu aktualisieren. Dadurch wird der Anforderungszyklus 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, Speicher und Designmustern, finden Sie unter Komponenten für die Architektur von agentischen KI-Systemen 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 Wartung im 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 Maschinenschemata abzurufen. Der KI-Assistent verwendet einen internen Datenbank-Agenten, der auf die Produktdokumentation zugreift, um fundierte Reparatur- und Montageanleitungen zu liefern. 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-Kamerafeed ihres Smartphones mit einem multimodalen KI-System zu teilen. Die bidirektionale Streaming-Architektur unterstützt dynamische Unterhaltungen, bei denen das System die Hardware in Echtzeit beobachtet. Wenn ein Hintergrundprozess zur Bildverarbeitung eine fehlerhafte Verbindung erkennt, z. B. ein Kabel im falschen Anschluss, wird der Nutzer über den Stream mit geringer Latenz sofort unterbrochen und erhält eine Anleitung zur Fehlerbehebung.

Designaspekte

In den folgenden Abschnitten finden Sie allgemeine Empfehlungen für das Design der KI-Agents und die Implementierung dieser Architektur für die Produktion.

Design von KI-Agenten

So können Sie die Kosten und Leistung Ihrer Agents verbessern:

  • Steuerungsschleifenskripts: Schreiben Sie Systemprompts für bidirektionale Live-Kundenservicemitarbeiter als strenge Statusautomaten-Verhaltensschleifen und nicht nur als Persönlichkeitsrichtlinien. Im System-Prompt sollte der Agent explizit angewiesen werden, bis zur Auslösung nicht zu reagieren. Es sollte kurze Antworten geben, die mit der Aktion beginnen, damit die Sprachinteraktion prägnant und natürlich ist.
  • Trennen Sie Zuständigkeiten: Verwenden Sie ein spezielles Tool für das Hintergrund-Streaming, um Videofeeds unabhängig vom primären Agent zu überwachen. Der Root-Agent in der Architektur ist bidirektional und kann seine eigene Sprachausgabe sofort unterbrechen, um diese wichtigen 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) wirkt sich direkt auf Leistung und Kosten aus. Formulieren Sie kurze, direkte Prompts, die ausreichend Kontext liefern. Formulieren Sie Ihre Prompts so, dass das Modell prägnante Antworten liefert. Sie können z. B. Formulierungen wie „Fasse in zwei Sätzen zusammen“ oder „Liste drei wichtige Punkte auf“ verwenden. Weitere Informationen finden Sie unter Best Practices für das Prompt-Design.

Szenenbild

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

  • Sicherheit für eingehenden Traffic: 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 eingehenden Traffic auf die Anwendung, sondern übernimmt auch die Verwaltung von SSL-Zertifikaten. Für zusätzlichen Schutz können Sie Google Cloud Armor-Sicherheitsrichtlinien verwenden, um Anfragen für den Dienst zu filtern, DDoS-Schutz zu bieten und die Raten zu begrenzen.
  • Zugriffssteuerung: Wenn Sie Berechtigungen für die Ressourcen in Ihrer Topologie konfigurieren, halten Sie sich an das Prinzip der geringsten Berechtigung.
  • Asynchrones Puffern: 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 dass die Benutzeroberfläche bei rechenintensiven Vorgängen einfriert.
  • Kosten für die Datenaufnahme: Um die Tokenkosten zu senken und zu verhindern, dass das Kontextfenster erschöpft ist, verwenden Sie eine Frame-Sampling-Frequenz von z. B. 2 Frames pro Sekunde und komprimieren Sie alle Daten in Base64-JPEG-Dateien.
  • In-Memory-Caching: Um Lesegeschwindigkeiten von weniger als einer Millisekunde zu erreichen, verwenden Sie eine Memorystore for Redis Cluster-Datenbank im Arbeitsspeicher für den Schemaspeicher des Architect-Agents. 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 Stimmprofile und Videos, indem Sie für alle bidirektionalen WebSocket-Verbindungen eine TLS-Verschlüsselung erzwingen.
  • Sichere A2A-Kommunikation:
  • Ressourcenzuweisung: Konfigurieren Sie je nach Ihren Leistungsanforderungen die Arbeitsspeicherlimits und CPU-Limits, die dem Cloud Run-Dienst zugewiesen werden sollen.

Weitere Informationen zu Designfaktoren, Best Practices und Empfehlungen zum Erstellen und Bereitstellen eines KI-Systems mit mehreren Agents finden Sie unter KI-System mit mehreren Agents 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: