Sprachgesteuertes Dokumenten-Editing mit Gemini Live: Architektur & Kompromisse

Die meisten Demos zu "sprachgesteuerten Editoren", die du gesehen hast, machen im Stillen etwas Aufwendiges: Das Audio läuft durch ein Transkriptionsmodell, das Transkript läuft durch ein Anweisungsmodell, und das Anweisungsmodell sendet Tool-Aufrufe an den Editor. Drei Roundtrips, zwei LLMs, und die Oberfläche, die das Sprachmodell sieht, ist nicht die Oberfläche, die der Editor bereitstellt.

AgentDoc geht einen anderen Weg. Wir verbinden Gemini 3.1 Flash Live – die native-audio-Variante – direkt mit demselben MCP-Server, den auch der Text-Agent nutzt. Es gibt keinen Transkriptions-Proxy, kein zweites LLM und keine separate Tool-Oberfläche für Sprache. Dieser Beitrag erklärt, warum wir uns für dieses Design entschieden haben, was es kostet und wo die rauen Kanten noch sind.

Das naive Design (und warum es verliert)

Das Transkriptions-Proxy-Muster sieht so aus:

mic → STT → transcript → text-LLM → tool-call → MCP → editor
                              ↑
                        (instructions, tool list, history)

Es hat drei echte Probleme. Erstens ist die Latenz die Summe von drei aufeinanderfolgenden Modellaufrufen; du spürst die Pause jedes Mal, wenn du zu Ende gesprochen hast. Zweitens wirft der STT-Schritt die Prosodie weg – also genau das Signal, das "kursives 'wirklich'" von "wirklich, kursiv" unterscheidet. Drittens pflegst du zwei voneinander abweichende Prompt-Oberflächen: die Tool-Dokumentation des Text-Agenten und die des Sprach-Agenten, die mit der Zeit auseinanderdriften.

Das native-audio-Design

Der native-audio-Pfad von Gemini Live nimmt rohes Audio entgegen, führt Tool-Aufrufe gegen ein typisiertes Schema aus und streamt Audio zurück. Das Diagramm reduziert sich auf:

mic → Gemini Live → tool-call → MCP → editor
                      ↑
                (same tool list as text agent)

Daraus ergeben sich zwei Konsequenzen:

• Eine einzige Quelle der Wahrheit für die Tool-Oberfläche. Der Sprach-Agent ruft insert_text mit demselben Schema auf, das der Text-Agent verwendet. Wir pflegen keine parallele "Sprach-Tool-Liste".
• Die Prosodie bleibt erhalten. Das Modell erhält das Audio direkt, sodass Betonung und Pausen die Auswahl der Tool-Aufrufe beeinflussen, ohne dass wir Regeln dafür schreiben müssen.

Was wir bauen mussten

Drei Integrationspunkte mussten bearbeitet werden:

• WebSocket-Bridging. Gemini Live spricht ein WS-Protokoll; der Editor verwendet ein anderes für die Echtzeit-Dokumentensynchronisation. Der Agent-Dienst betreibt beide und übersetzt Tool-Aufruf-Ergebnisse in Editor-Render-Events. Siehe [agent/](agent/).
• Tool-Aufruf-Beobachtbarkeit. Das Sprachmodell braucht strukturiertes Feedback, um Index-Drift nach Mutationen zu vermeiden. Wir geben dieselben Dirty-Range-Deskriptoren zurück, die auch der Text-Agent erhält (behandelt im Beitrag zur Tool-Granularität).
• FSM-Gating, Sprach-Variante. Der State-Constrained-ReAct-FSM kümmert sich nicht um die Modalität – die Sperre auf Schreib-Tools nach einer Mutation funktioniert für Sprache identisch. Wir mussten nur sicherstellen, dass der Audio-Ausgabekanal nicht blockiert, wenn der FSM ein erneutes Lesen erzwingt.

Latenz: der erwartete Gewinn und der unerwartete

Die Ende-zu-Ende-Latenz "Ich höre auf zu sprechen → Dokument mutiert" sinkt von etwa 2,4 s im Proxy-Design auf ~700 ms mit native audio. Der erwartete Gewinn.

Der unerwartete Gewinn ist das, was während mehrstufiger Abläufe passiert. Weil wir den STT-Roundtrip pro Runde nicht bezahlen, kann das Modell einen längeren Kontext der gesprochenen Unterhaltung kostengünstig halten. Zusammengesetzte Anweisungen ("mach den Titel fett, dann den nächsten Absatz kursiv, dann exportieren"), die wir früher in separate LLM-Aufrufe zerlegen mussten, laufen jetzt als eine einzige Tool-Aufruf-Sequenz in einer einzigen Live-Sitzung.

Wie die rauen Kanten aussehen

Drei Dinge machen noch Ärger:

• Live-API-Kontingent. Native-audio-Sitzungen zählen gegen ein anderes Kontingent als Text-Completions, und eine lange Sprachsitzung kann es schneller aufbrauchen, als ein Tippender erwarten würde. Unser Kontingent-Status-Pill (das neue quota_status.js-Modul) ist die für Nutzer sichtbare Antwort.
• Unterscheidung von Homophonen. "Insert here" und "insert hear" klingen für ein Mikrofon in einem lauten Raum nicht unterschiedlich. Wir haben eine kleine Reihe von Bestätigungsabfragen bei nicht umkehrbaren Operationen hinzugefügt – laut gesprochen "Absatz 3 wird gelöscht, bestätigen?" – die die tatsächliche Mutation absichern.
• Neuverbindungen. Der Live-WebSocket kann in instabilen Netzwerken abbrechen, und der Zustand des Audiopuffers im Moment des Abbruchs ist nicht immer wiederherstellbar. Wir spielen derzeit die letzten ~3 Sekunden des bestätigten Texts in eine frische Sitzung ein, was für die meisten Nutzer gut genug ist, aber das nächste Element auf der Politur-Liste darstellt.

Warum das für die Barrierefreiheit wichtig ist

Die ursprüngliche Motivation für den voice-first-Build steht auf der Barrierefreiheit-Seite: AgentDoc soll für Menschen nutzbar sein, die keine Maus und Tastatur verwenden können oder wollen. Das Transkriptions-Proxy-Design fühlte sich für dieses Publikum immer falsch an, weil es jeder Äußerung eine 2-Sekunden-Strafe auferlegte, die sich über eine lange Schreibsitzung übel summiert.

Native audio ist nicht nur eine technische Vorliebe. Es ist der Unterschied zwischen Sprache als einer Neuheits-Eingabe und Sprache als einer primären.

Was als Nächstes kommt

Laufende Arbeit: bessere Handhabung von Neuverbindungen, ein kontingentbewusster Rückfall auf den Textmodus, wenn das Live-Budget niedrig ist, und eine Studie, die die Bearbeitungszeiten von Nur-Sprache vs. Nur-Text über die 13 Benchmark-Szenarien vergleicht. Diese letzte bekommt hier ihren eigenen Beitrag, sobald die Daten vorliegen.