Der größte Vorteil der Google Gemini Live API ist nicht nur die Sprachsynthese: Sie kann dir zuhören und gleichzeitig sofort antworten, und du kannst sie jederzeit unterbrechen, was sich anfühlt wie ein echtes Telefongespräch. Google Cloud Tech hat kürzlich ein ausführliches Tutorial veröffentlicht, das den gesamten Live-Sprachagenten in drei Teile aufteilt: die Unterschiede zwischen Gemini Live und traditionellem TTS, die dreischichtige Architektur und einen Websocket-Kernzyklus sowie drei Schlüsselkonzepte, die den Agenten „lebendig“ machen. In diesem Artikel haben wir die Kerninhalte dieses Tutorials zusammengefasst und die von Google bereitgestellten Code-Links und Dokumente beigefügt, um Entwicklern, die an der Erstellung eines eigenen Echtzeit-Sprach-AI-Agenten interessiert sind, einen vollständigen Überblick zu geben.
Die 3 großen Unterschiede zwischen Gemini Live und traditionellem TTS: audio-to-audio + bidirektional + Echtzeit-Streaming
Traditionelle Text-to-Speech (TTS)-Systeme funktionieren sehr direkt: Du gibst Text ein, und sie geben Sprache aus, ein eindimensionaler Pipeline-Prozess. TTS-Systeme können sprechen, hören dich aber nicht; sie wissen nicht einmal, ob du da bist.
Gemini Live geht in eine völlig andere Richtung: audio-to-audio, bidirektional und gleichzeitig. Es empfängt direkt dein Sprachsignal, erkennt Tonfall, Pausen, Energie und die Art, wie du sprichst, und generiert sofort Sprache, die gestreamt wird.
Die drei Kernunterschiede:
- Richtung: TTS ist text → audio einseitig; Gemini Live ist audio ↔ audio bidirektional
- Wahrnehmung: TTS weiß nicht, dass du da bist; Gemini Live erkennt Ton, Pausen, Energie und andere Sprachhinweise
- Timing: TTS wartet, bis die gesamte Antwort fertig ist, bevor es anfängt zu lesen; Gemini Live denkt und spricht gleichzeitig und kann bereits mit dem Streaming von Audio beginnen, während es eine Antwort generiert
Anders ausgedrückt: „TTS liest, Live hört“ – traditionelles TTS liest vor, Gemini Live hört tatsächlich, was du sagst.
Dreischichtige Architektur: Browser + Backend + Gemini Live, verbunden über WebSocket
Die gesamte Architektur des Live-Sprachagenten besteht aus drei Teilen:
- Browser: Verantwortlich für das Erfassen deines Mikrofon-Audios und das Abspielen von Geminis Antworten
- Gemini Live: Das Live-Sprachmodell selbst
- Backend: Hält die dauerhafte Verbindung zu Gemini aufrecht und dient als Audio-Kanal zwischen dem Browser und Gemini
Die Kommunikation zwischen Browser und Backend erfolgt über WebSocket und nicht über eine herkömmliche HTTP-Anfrage. Der Grund dafür ist: Eine normale HTTP-Anfrage kann nur „einmal fragen und dann trennen“, aber Live-Sprach benötigt einen bidirektionalen, kontinuierlichen Audiofluss, daher muss WebSocket verwendet werden, um die dauerhafte Verbindung aufrechtzuerhalten.
Das Backend führt tatsächlich zwei parallele Aufgaben aus:
- Aufgabe A: Streamt kontinuierlich dein Mikrofon-Audio zu Gemini
- Aufgabe B: Empfängt Geminis Sprachantwort und sendet sie zurück an den Browser zur Wiedergabe
Die beiden Aufgaben laufen unabhängig voneinander, sodass du den Agenten jederzeit unterbrechen kannst, während er spricht.
Der Kernzyklus besteht aus 4 Schritten: Open → Send → Receive → Play
Beim tatsächlichen Programmieren besteht der gesamte Dialog aus einem Zyklus von 4 Schritten:
- Open: Eine Sitzung mit Gemini Live öffnen
- Send: Das vom Browser erfasste Mikrofon-Audio an das Backend senden
- Receive: Das Backend empfängt Geminis Sprachantwort und sendet sie zurück an den Browser
- Play: Der Browser spielt Geminis Antwort sofort ab
Google betont im Tutorial: „Dieser Zyklus ist sehr einfach – Open, Send, Receive, Play, alles andere ist nur Klempnerarbeit (Plumbing).“ Wenn du diesen Zyklus beherrschst, hast du bereits einen funktionierenden Sprachagenten.
Drei Kernkonzepte, die den Agenten „lebendig“ machen: VAD, Barge-in, Tools
Konzept 1: Voice Activity Detection (VAD), wie weiß man, wann du fertig bist zu sprechen?
VAD (Voice Activity Detection) ist das Modell, das sich ständig die Frage stellt: Spricht gerade jemand oder ist es still? Diese Entscheidung ermöglicht es dem Modell, den Anfang und das Ende deines Sprechturns zu finden – also zu wissen, wann du anfängst zu sprechen und wann du aufhörst.
Deshalb muss dein Mikrofon auch dann kontinuierlich Audio an das Modell streamen, wenn du nicht sprichst, da das Modell diesen „kontinuierlichen Stream“ benötigt, um den Moment zu erfassen, in dem du sprichst.
Die gute Nachricht ist: Geminis VAD ist eingebaut, du musst es nicht selbst programmieren.
Konzept 2: Barge-in, du kannst den Agenten unterbrechen
Barge-in bedeutet: Du unterbrichst den Agenten, während er spricht, und er stoppt sofort. Walkie-Talkies können das nicht, aber echte Gespräche zwischen Menschen können es.
Gemini Live verwendet intern dasselbe VAD-Mechanismus, um zu erkennen, ob du „anfängst, dem Agenten ins Wort zu fallen“. Wenn es erkennt, dass du unterbrichst, stoppt das Modell sofort und sendet ein „unterbrochen“-Signal zurück an das Backend.
Ein Schlüsseltrick, um das Unterbrechen sofort erscheinen zu lassen:
- Warte nicht, bis das unterbrochene Signal über das Netzwerk übertragen wird, bevor du das lokale Audio stoppst
- Sobald der Browser von deinem Mikrofon „hört“, dass du anfängst zu sprechen, stoppe sofort die aktuelle Sprachwiedergabe des Agenten
- Warte, bis dein Sprachinput beendet ist, und bestätige dann den Status mit dem unterbrochenen Signal des Modells
Dieses Design des „lokalen sofortigen Stopp“ ist das Geheimnis, um das Unterbrechen natürlich erscheinen zu lassen.
Konzept 3: Tools, um dem Agenten praktische Fähigkeiten zu geben
Das Gemini Live-Modell kann nur sprechen – es hat keine Fähigkeit, Musik abzuspielen, Songs zu überspringen oder Knöpfe zu drücken. Daher musst du ihm Tools geben – eine Reihe von Funktionsaufrufen, wobei jedes Tool einen eigenen Namen, eine Beschreibung und eine Aktion repräsentiert.
Beispiele für die im Tutorial gezeigten Tools:
- play_playlist: Spiele eine Playlist ab
- skip_current_track: Überspringe den aktuellen Song
- pause_music: Pausiere die Musik
Der Betriebsmodus ist: Nachdem das Modell entschieden hat, welches Tool es verwenden möchte, wird es nicht einfach „sagen“, was zu tun ist, sondern direkt den Befehl „verwende dieses Tool + diese Argumente“ ausgeben, der von deinem Backend-Code ausgeführt und das Ergebnis zurückgemeldet wird.
Google betont eine Regel zur Sprachverzögerung: „tool-latency rule“: „Wenn ein Tool ausgeführt wird, wartet das Modell.“ Wenn ein Tool zu lange braucht, um zurückzukehren, gerät das Gespräch in einen Stummzustand. Daher sollte dein Musik-Tool den Befehl sofort zurückgeben, ohne darauf zu warten, dass das gesamte Lied zu Ende gespielt wird.
Zusammenfassend in einem Satz: VAD erfasst deinen Turn, Barge-in ermöglicht dir das Unterbrechen, Tools geben dem Agenten die Fähigkeit zu handeln.
Fazit: Wahl zwischen raw API und Google ADK
Das in diesem Tutorial gezeigte Implementierungsbeispiel verwendet absichtlich die raw GenAI SDK – Entwickler können die Funktionsweise jedes Teils (Sitzung, Stream, Audio-Schleife, Tools) vollständig nachvollziehen, ohne dass ein Framework verborgen ist. Aber das bedeutet, dass mehr Klempnerarbeit (Plumbing-Code) geschrieben werden muss.
Google erwähnt, dass die nächste Episode das Google ADK (Agent Development Kit) verwenden wird, das ein Framework für solche Sprachagenten bereitstellt:
- Agent, Sitzung und Streaming-Schleife werden vom Framework verwaltet
- Integrierte Warteschlange für einen reibungslosen Live-Anruf
- Entwickler schreiben nur die hochgradige Geschäftslogik (Tools, Prompts)
Wenn du einfach nur schnell einen Live-Sprachagenten ausprobieren möchtest, ist das ADK die einfachere Wahl; wenn du die zugrunde liegenden Funktionsweisen verstehen oder umfangreiche Anpassungen vornehmen möchtest, ist die in diesem Tutorial gezeigte raw API klarer.
Offizielle vollständige Ressourcen
- Demo-Code: [g.dev/cloud/voicedemo1](https://g.dev/cloud/voicedemo1)
- Gemini Live API-Dokumentation: [g.dev/cloud/gemini-live](https://g.dev/cloud/gemini-live)
- Agent Development Kit-Dokumentation: [g.dev/cloud/adk-docs](https://g.dev/cloud/adk-docs)
- Google Cloud-Roadmap: [g.dev/cloud/mma-roadmap](https://g.dev/cloud/mma-roadmap)
- Vorschau auf die nächste Episode: Verwendung des Google ADK zur Neugestaltung derselben Sprachagenten-App