AgentOS 2 Live im Tiefgang: End-to-End-Echtzeit-Sprachagent – Schluss mit ASR→LLM→TTS

Die drei größten Schmerzpunkte herkömmlicher Sprachagenten

Wer schon einmal einen Sprachassistenten gebaut hat, kennt diese klassische Pipeline nur zu gut:

Benutzereingabe → ASR (Spracherkennung) → Text → LLM (Modellinferenz) → Antworttext → TTS (Sprachsynthese) → Wiedergabe

Diese ASR → LLM → TTS-Dreistufenarchitektur ist zwar ausgereift, doch jeder Schritt bringt zusätzliche Latenz und Informationsverluste mit sich:

Noch problematischer: Die drei Module arbeiten völlig unabhängig voneinander, was Debugging und Optimierung extrem aufwendig macht. Man hat die VAD (Voice Activity Detection) der ASR endlich im Griff – und stellt fest, dass die Satzgrenzenlogik der TTS nicht dazu passt. Man optimiert den Streaming-Output des LLM – und entdeckt, dass die TTS kein Streaming-Splicing unterstützt.

Gibt es eine Lösung, die direkt von Sprache zu Sprache arbeitet, ohne den Umweg über Texttranskription?

AgentOS 2 Live ist genau so eine Antwort.

Was ist AgentOS 2 Live?

AgentOS 2 Live ist eine von OrionStar (OrionStar) open-source bereitgestellte End-to-End-Echtzeit-Sprachinteraktionsplattform (Technische Vorschau), aufgebaut auf der OpenAI Realtime API. Das Grundprinzip ist einfach:

Audiodaten werden direkt einem multimodalen Modell zugeführt, das direkt Sprache ausgibt – ohne ASR und TTS dazwischen.

Benutzereingabe → [Opus-Kodierung] → WebSocket → OpenAI Realtime API → Audio-Stream → Wiedergabe

Durch den Wegfall zweier unabhängiger Modelle sinkt die Latenz erheblich, und gleichzeitig bleiben emotionale Nuancen, Tonfall und andere paraverbale Informationen in der Sprache erhalten.

Kern-Technologie-Stack

Das Projekt verwendet eine Monorepo-Struktur mit vier Subpaketen:

AgentOS2-Live/
├── client/        # React-Frontend: AgentSDK, VAD, Roboter-Gesichtsanimation
├── server/        # Node.js-Backend: WebSocket-Server, OpenAI-Orchestrierung
├── shared/        # Frontend-/Backend-übergreifende TypeScript-Typen und Kommunikationsprotokolle
└── e2e_android/   # OrionStar-Roboter-Android-WebView-Bridge

GitHub-Repository: OrionStarAI/end2end_sample

Technische Architektur im Detail

Funktionsweise der Realtime API

Das Herzstück der OpenAI Realtime API ist das gpt-4o-realtime-preview-Modell. Im Gegensatz zu herkömmlichen REST-APIs nutzt es eine WebSocket-Dauerverbindung mit bidirektionalem Streaming-Audio:

Client                           Server (OpenAI)
  |                                |
  |-- session.update (Konfig.) --->|
  |                                |
  |-- input_audio_buffer.append -->|  (laufend Opus-kodierte Audio-Frames)
  |                                |
  |-- input_audio_buffer.commit -->|  (VAD erkennt Pause, Audio wird übergeben)
  |                                |
  |<-- response.audio.delta -------|  (Modell gibt Audio-Stream zurück)
  |<-- response.audio.delta -------|
  |<-- response.done --------------|

Wesentliche Punkte: - Kein Zwischentext: Das Modell verarbeitet Audio-Merkmale direkt und gibt ebenfalls Audio aus - Streaming-Verarbeitung: Audio-Frames können während der Aufnahme gesendet werden – das Modell hört, denkt und spricht gleichzeitig - Sprachinformationen bleiben erhalten: Tonfall, Emotionen und Pausen werden vom Modell wahrgenommen

End-to-End-Sprachablauf

Verfolgen wir ein Audio-Frame auf seinem vollständigen Weg vom Mikrofon zum Lautsprecher:

1. Mikrofon erfasst PCM-Audio (48kHz, 16bit, mono)
   ↓
2. Opus-Kodierung (komprimiert auf ~32kbps, reduziert Bandbreite)
   ↓
3. WebSocket-Sendung an das Backend (input_audio_buffer.append)
   ↓
4. Backend leitet an OpenAI Realtime API weiter (nahezu null Verarbeitung)
   ↓
5. Modell verarbeitet das Audio und generiert eine Sprachantwort
   ↓
6. Rückgabe als Opus-kodierter Audio-Stream (response.audio.delta)
   ↓
7. Client dekodiert und spielt ab

Während des gesamten Vorgangs gibt es keine ASR-Transkription und keine TTS-Synthese – das Modell „hört" und „spricht" direkt.

Function-Call-Integration: Dem Agenten Handlungsfähigkeit geben

Echtzeitsprache ist nur die Grundlage. Wirklich mächtig wird der Agent durch Function Calls. AgentOS 2 Live unterstützt Tool-Aufrufe mitten im Sprachgespräch:

const agent = new AgentSDK({
  modelType: 'openai',
  systemPrompt: 'Du bist ein intelligenter Assistent, der Wetter abfragen und Geräte steuern kann.',
  voice: 'alloy',
  tools: [
    {
      name: 'get_weather',
      description: 'Aktuelles Wetter für eine Stadt abfragen',
      parameters: {
        type: 'object',
        properties: {
          city: { type: 'string', description: 'Name der Stadt' }
        },
        required: ['city']
      }
    },
    {
      name: 'control_light',
      description: 'Smartes Licht ein-/ausschalten',
      parameters: {
        type: 'object',
        properties: {
          action: { type: 'string', enum: ['on', 'off'] },
          color: { type: 'string' }
        }
      }
    }
  ]
});

agent.on('tool_call', async (toolCall) => {
  console.log('Tool aufgerufen:', toolCall.name, toolCall.arguments);

  if (toolCall.name === 'get_weather') {
    const weather = await fetchWeather(toolCall.arguments.city);
    agent.sendToolResult(toolCall.call_id, weather);
  }
});

Typisches Szenario: - Benutzer sagt: „Wie ist heute das Wetter in Berlin?" - Das Modell erkennt die Absicht und löst das get_weather-Tool aus - Das Backend führt die Abfrage durch und liefert das Ergebnis - Das Modell antwortet per Sprache: „In Berlin scheint heute die Sonne, 25 Grad."

Der gesamte Vorgang läuft nahtlos im Sprachgespräch ab – der Benutzer fühlt sich wie in einem Gespräch mit einem echten Menschen.

Architekturvergleich: Klassisch vs. AgentOS 2 Live

Latenzvergleich – Visualisierung:

Klassische Architektur:
Benutzereingabe ──[ASR 300ms]──> Text ──[LLM 500ms]──> Antwort ──[TTS 400ms]──> Wiedergabe
         Gesamlatenz: 1200ms+

AgentOS 2 Live:
Benutzereingabe ──[Opus-Kodierung 50ms]──> WebSocket ──[Realtime API 400ms]──> Audio-Stream ──> Wiedergabe
         Gesamlatenz: 450-800ms

Kernfunktionen im Detail

1. Ultra-niedrige Latenz bei der Sprachinteraktion

Die Latenzvorteile von AgentOS 2 Live resultieren aus der architektonischen Vereinfachung. Herkömmliche Ansätze benötigen drei unabhängig arbeitende Modelle in Serie, jedes mit eigener Inferenzzeit und Netzwerk-Roundtrip-Zeit. Die Realtime API hingegen bündelt Sprachverständnis, Inferenz und Sprachgenerierung in einem einzigen Modell:

• Opus-Codec: Audio wird mit Opus kodiert – hohe Kompression, niedrige Latenz, ideal für Echtzeitübertragung
• WebSocket-Dauerverbindung: Vermeidet den Handshake-Overhead von HTTP-Anfragen, Audio-Frames fließen kontinuierlich in beide Richtungen
• Frontend-VAD: Erkennt Sprachaktivität im Browser – sobald der Nutzer aufhört zu sprechen, wird das Audio sofort übertragen, keine Verschwendung durch Stillesegmente
• Backend-Durchleitung: Das Node.js-Backend verarbeitet kaum zusätzlich, es ist lediglich für WebSocket-Routing und API-Key-Sicherheit zuständig

2. Integrierte Spracherkennung (VAD)

Die VAD ist eine Kernkomponente jedes Echtzeitsprachsystems. Ohne VAD weiß das System nicht, wann der Nutzer fertig gesprochen hat. AgentOS 2 Live integriert ein leistungsstarkes VAD-Modul im Frontend:

// VAD-Arbeitsablauf
// 1. Kontinuierliches Überwachen des Mikrofon-Audiostreams
// 2. Spracherkennung → Aufnahme starten und Audio-Frames senden
// 3. Spracherkennung beendet (Pause überschreitet Schwellenwert) → automatischer Commit
// 4. Auf Modellantwort warten

Die Empfindlichkeit der VAD beeinflusst das Nutzererlebnis direkt – zu empfindlich führt zu häufigen Unterbrechungen, zu träge lässt es den Nutzer zu lange warten. Die VAD von AgentOS 2 Live wird über das postinstall-Skript automatisch konfiguriert und ist sofort einsatzbereit.

3. Roboter-Gesichtanimations-UI

Ein oft übersehenes, aber äußerst wichtiges Feature. Der Client von AgentOS 2 Live enthält eine Echtzeit-Roboter-Gesichtsanimation, die je nach Gesprächszustand den Ausdruck wechselt:

Dieses visuelle Feedback macht die Interaktion natürlicher – der Nutzer kann unmittelbar erkennen, was das System gerade tut, statt vor einer statischen Oberfläche zu rätseln.

4. Zwei integrierte Szenarien

Das Projekt bietet zwei sofort einsatzbereite Demoszenarien:

• Face Register: Gesichtserkennung und Identitätsregistrierung, geeignet für Mitgliedersysteme und实名制-Szenarien
• Advice 3C: 3C-Produktempfehlungsassistent – die KI empfiehlt basierend auf den Bedürfnissen des Nutzers Handys, Computer, Kopfhörer usw.

Beide Szenarien demonstrieren die Einsatzfähigkeit von AgentOS 2 Live in vertikalen Anwendungsbereichen.

Lokales Deployment in der Praxis

Hardwareanforderungen

Hinweis: AgentOS 2 Live selbst benötigt keine GPU – die gesamte KI-Inferenz läuft in der OpenAI-Cloud. Lokal werden nur Frontend- und Backend-Service betrieben.

Installationsschritte

Schritt 1: Repository klonen

git clone https://github.com/OrionStarAI/end2end_sample.git
cd end2end_sample

Schritt 2: Abhängigkeiten installieren

npm install

Das postinstall-Skript kopiert die VAD-Assets automatisch in das Verzeichnis client/public.

Schritt 3: Umgebungsvariablen konfigurieren

Im Projektstammverzeichnis eine .env-Datei erstellen:

# OpenAI API-Konfiguration (Realtime-API-Zugriff erforderlich)
OPENAI_API_KEY=«redacted:sk-…»

# Server-Port
PORT=8081

# SSL-Modus (in Produktion empfohlen)
USE_SSL=false

Wichtig: Der OpenAI API Key muss Zugriff auf das gpt-4o-realtime-preview-Modell haben. Bei einem 403-Fehler muss die Realtime-API-Berechtigung auf der OpenAI-Plattform beantragt werden.

Schritt 4: Entwicklungsmodus starten

npm run dev

Dabei werden Frontend und Backend gleichzeitig gestartet: - Frontend: http://localhost:3000 - Backend: http://localhost:8081

Im Browser Port 3000 aufrufen, um die Roboter-Gesichtsoberfläche zu sehen. Auf das Mikrofon-Symbol klicken, um das Gespräch zu starten.

Produktions-Deployment

# Frontend und Produktions-Backend bauen
npm run build

# Produktionsserver starten (ein Prozess liefert statische Dateien und WebSocket)
node server/dist/index.js

Im Produktionsmodus übernimmt der server sowohl den statischen Dateiservice als auch den WebSocket-Service – eine zusätzliche Nginx-Reverse-Proxy-Konfiguration ist nicht erforderlich (in der Produktion wird jedoch Nginx für SSL-Terminierung und Lastverteilung empfohlen).

Nginx-Reverse-Proxy-Konfiguration (optional)

server {
    listen 443 ssl;
    server_name voice.yourdomain.com;

    ssl_certificate /path/to/cert.pem;
    ssl_certificate_key /path/to/key.pem;

    location / {
        proxy_pass http://127.0.0.1:8081;
        proxy_http_version 1.1;
        proxy_set_header Upgrade $http_upgrade;
        proxy_set_header Connection "upgrade";
        proxy_set_header Host $host;
        proxy_read_timeout 86400;  # WebSocket-Dauerverbindung
    }
}

Roboter-Hardwareintegration

Die einzigartige Fähigkeit von AgentOS 2 Live ist die direkte Steuerung physischer Roboter. Das Projekt enthält eine Android-WebView-Bridging-Schicht (e2e_android/), die es dem Web-Frontend ermöglicht, die Hardware-Fähigkeiten von OrionStar-Robotern aufzurufen.

Architekturdesign

React-Frontend (Web)
    ↓ JavaScript Bridge
Android WebView (Kotlin)
    ↓ RobotService SDK
Roboterhardware (Kopfbewegung, Chassisnavigation, Sensoren)

Deployment auf einem OrionStar-Roboter

Vorbereitung: - Android Studio - robotservice_xx.jar vom Robotersystem beziehen und in e2e_android/app/libs/ ablegen

Build und Installation:

# 1. Verzeichnis e2e_android in Android Studio öffnen
# 2. Gradle-Synchronisierung
# 3. Roboter per USB verbinden (ADB muss aktiviert sein)
# 4. Auf „Run" klicken, um auf dem Roboter zu installieren

Serveradresse konfigurieren:

Standardmäßig wird http://localhost:3000 geladen. Wenn der Service unter einer anderen Adresse bereitgestellt wird, MainActivity.kt anpassen:

// e2e_android/app/src/main/java/com/e2e/orionstar/MainActivity.kt
private val DEFAULT_URL = "http://your-server-ip:3000";

Hardware-Steuerungsfähigkeiten

Über die WebView-Bridge kann das Frontend folgende Funktionen aufrufen: - Kopfbewegung: Den Roboter in Sprechrichtung blicken lassen - Chassisnavigation: Autonome Bewegung zu einem bestimmten Ort - Sensorauslesung: Umgebungsdaten abrufen - LED-Steuerung: Lichteffekte anpassen

Das bedeutet, dass sich mit React-Code eine vollständige Roboterinteraktion realisieren lässt – Sprachdialog + Körperbewegungen + Umgebungswahrnehmung.

Entwicklerleitfaden: Eigene Functions

Das AgentSDK von AgentOS 2 Live macht benutzerdefinierte Tools einfach. Hier ist der vollständige Entwicklungsablauf:

Tool-Schema definieren

const tools = [
  {
    name: 'search_products',
    description: 'Produkte basierend auf Kundenbedürfnissen suchen',
    parameters: {
      type: 'object',
      properties: {
        category: { 
          type: 'string', 
          enum: ['Handy', 'Computer', 'Kopfhörer'] 
        },
        budget: { 
          type: 'number', 
          description: 'Maximalbudget (Euro)' 
        },
        brand: { 
          type: 'string', 
          description: 'Markenpräferenz' 
        }
      },
      required: ['category']
    }
  }
];

Tool-Logik implementieren

agent.on('tool_call', async (toolCall) => {
  if (toolCall.name === 'search_products') {
    const { category, budget, brand } = toolCall.arguments;

    // Backend-API aufrufen
    const products = await fetch('/api/products', {
      method: 'POST',
      body: JSON.stringify({ category, budget, brand })
    }).then(r => r.json());

    // Ergebnis an das Modell zurückgeben
    agent.sendToolResult(toolCall.call_id, {
      success: true,
      count: products.length,
      items: products.slice(0, 5)
    });
  }
});

Szenarien dynamisch wechseln

Man kann den systemPrompt basierend auf der Benutzerabsicht dynamisch umschalten:

// Erkannt: Benutzer möchte einkaufen
if (userIntent === 'shopping') {
  agent.updateConfig({
    systemPrompt: 'Du bist ein 3C-Produktberater. Empfehle Produkte basierend auf den Kundenbedürfnissen.'
  });
}

// Erkannt: Benutzer möchte plaudern
if (userIntent === 'chat') {
  agent.updateConfig({
    systemPrompt: 'Du bist ein freundlicher Gesprächspartner, mit dem man über alles reden kann.'
  });
}

Leistungsbenchmark

Wir haben die Latenz der ersten Antwort unter verschiedenen Netzwerkbedingungen getestet:

Testbedingungen: - Hardware: MacBook Pro M2, 16GB RAM - Mikrofon: Integriertes Mikrofon - Modell: gpt-4o-realtime-preview-2024-10-01 - Stimme: alloy (weibliche Stimme) - Testsätze: 10 kurze Sätze, jeweils 5-mal wiederholt, Durchschnittswert

Wesentliche Erkenntnisse: - Netzwerklatenz beeinflusst AgentOS 2 Live weniger stark (nur ein Roundtrip) - Herkömmliche Lösungen sind netzwerkanfälliger (drei Roundtrips addieren sich) - In ruhiger Umgebung arbeitet die VAD stabil; in lauter Umgebung wird ein geräuschunterdrückendes Mikrofon empfohlen

Einschränkungen und Hinweise

Status als technische Vorschau

AgentOS 2 Live ist derzeit eine technische Vorschau. Für den Produktionseinsatz ist Folgendes zu beachten:

1. API-Kosten: Die Realtime API wird nach Audiodauer abgerechnet – lange Gespräche sind kostenintensiv
2. Modelleinschränkung: Derzeit wird nur die OpenAI Realtime API unterstützt, keine lokalen Modelle oder andere Cloud-Anbieter
3. Sprachunterstützung: Obwohl das Modell mehrsprachig ist, ist die deutsche/englische Sprachqualität besser als die chinesische
4. Parallelitätsgrenzen: Eine einzelne Instanz kann nur eine Gesprächssitzung verarbeiten – für mehrere Nutzer müssen mehrere Instanzen bereitgestellt werden
5. Kein Offline-Betrieb: Vollständige Abhängigkeit von der OpenAI-Cloud – ohne Netz kein Betrieb

Geeignete Einsatzszenarien

Geeignet für: - Intelligente Beratungsroboter in Ausstellungen/Geschäften - Kundenservice-Informationsschalter - Smart-Home-Sprachassistenten - Bildungsunterstützungsroboter

Nicht geeignet für: - Szenarien, die Offline-Betrieb erfordern - Szenarien mit höchsten Datenschutzanforderungen (Audio wird in die Cloud hochgeladen) - Projekte mit begrenztem Budget, die die API-Kosten nicht tragen können

Häufige Fragen (FAQ)

F1: Muss man die OpenAI Realtime API verwenden? Kann man andere Modelle nutzen?

Derzeit unterstützt das Projekt nur die OpenAI Realtime API (modelType: 'openai'). Da das Kommunikationsprotokoll in shared/ jedoch klar definiert ist, könnte man theoretisch andere WebSocket-kompatible Echtzeitmodelle erweitern (z.B. Azure OpenAI, lokal bereitgestellte Open-Source-Echtzeitmodelle). Dies erfordert jedoch erhebliche Anpassungsarbeit.

F2: Wie hoch ist die Latenz konkret?

Nach unseren Tests liegt die Latenz der ersten Antwort in ruhiger Umgebung bei 600-1000ms (inklusive Netzwerk-Roundtrip). Das ist 40-50% schneller als herkömmliche ASR→LLM→TTS-Lösungen, aber es gibt noch Optimierungspotenzial. Bei hoher Netzwerklatenz (z.B. grenzüberschreitender Zugriff) steigt die Latenz auf 1000-1500ms.

F3: Wie wird die Roboter-Gesichtsanimation umgesetzt?

Über React-Komponenten, die den Gesprächszustand in Echtzeit überwachen (Benutzer spricht, KI spricht, denkt, idle) und verschiedene SVG- oder Lottie-Animationen umschalten. Der Code befindet sich in den UI-Komponenten im Verzeichnis client/ – die Animationsstile können nach Markenbedarf angepasst werden.

F4: Wie fügt man neue Szenarien hinzu?

Der einfachste Weg ist die Anpassung des systemPrompt, oder man verwaltet mehrere Sessions im Backend und schaltet je nach Benutzerabsicht dynamisch zwischen Prompts um. Der Tool-Call-Mechanismus unterstützt auch die Erweiterung komplexer Geschäftsabläufe. Die integrierten Szenarien Face Register und Advice 3C sind gute Referenzvorlagen.

F5: Was ist bei der kommerziellen Nutzung zu beachten?

Das README weist ausdrücklich darauf hin: Dieses Projekt dient nur zu Demonstrations- und Testzwecken. Bei kommerzieller Nutzung müssen die OpenAI-Nutzungsrichtlinien beachtet werden, insbesondere: - Bei Sprachsynthese muss offengelegt werden, dass „die Stimme von KI generiert wurde" - Keine Verwendung für betrügerische, irreführende oder rechtswidrige Zwecke - API-Aufrufkosten sind selbst zu tragen - Juristische Beratung zur Compliance wird empfohlen

Fazit und Ausblick

AgentOS 2 Live repräsentiert eine wichtige Richtung für Sprachagenten: End-to-End-Echtzeitinteraktion. Es beweist, dass man ohne komplexe ASR→LLM→TTS-Pipelines niedrigschwellige, natürliche Sprachassistenten bauen kann.

Kernwerte: - Architekturvereinfachung: Ein Modell ersetzt drei Module - Latenzreduktion: Erste Antwort 40-50% schneller - Informationserhalt: Emotionen und Tonfall in der Sprache bleiben vollständig erhalten - Entwicklungseffizienz: Einheitliches Debugging, kein Zusammenführen mehrerer Streams

Zukunftsausblick: Mit der Reife von Open-Source-Echtzeitmodellen (wie Metas SpeechLlama, Googles Gemini Realtime) können wir erwarten: - Lokal bereitgestellte Echtzeitsprachlösungen (Lösung von Datenschutz- und Kostenproblemen) - Multimodale Fusion (Sprache + Visuelles + Bewegung) - Noch niedrigere Latenz (<300ms) - Vielfältigerer sprachlicher Ausdruck (Emotionen, Dialekte, mehrere Rollen)

Wer nach einem schnell einsetzbaren Framework für Echtzeit-Sprachassistenten sucht, findet in AgentOS 2 Live einen hervorragenden Ausgangspunkt. Die komplexesten Probleme – Audio-Codec, VAD, Frontend-Backend-Protokollkonsistenz – sind bereits gelöst. Vom Klonen des Repository bis zum laufenden Dialog vergehen in der Regel weniger als 30 Minuten.

Weiterführende Links: - OpenAI Realtime API – Offizielle Dokumentation - OrionStarAI/end2end_sample GitHub - OpenAI Agents SDK

Schlagwörter: AI Agent, Echtzeitsprache, OpenAI, Realtime API, Sprachassistent, Roboter