Analyse approfondie d'AgentOS 2 Live : Agent vocal temps réel de bout en bout, adieu ASR→LLM→TTS

Les trois principales douleurs des agents vocaux traditionnels

Si vous avez déjà construit un assistant vocal, vous connaissez bien cette chaîne de traitement classique :

L'utilisateur parle → ASR (reconnaissance vocale) → Texte → LLM (inférence du modèle) → Texte de réponse → TTS (synthèse vocale) → Lecture

Cette architecture en trois étapes ASR → LLM → TTS, bien que mature, introduit une latence supplémentaire et une perte d'information à chaque étape :

Plus grave encore, ces trois modules sont indépendants, rendant le débogage et l'optimisation extrêmement complexes. Vous avez réglé le VAD (détection d'activité vocale) de l'ASR, mais découvrez que la logique de ponctuation du TTS ne correspond pas ; vous avez optimisé la sortie en streaming du LLM, mais découvrez que le TTS ne supporte pas l'assemblage en streaming.

Existe-t-il une solution qui passe directement de la voix à la voix, sans transcription textuelle intermédiaire ?

AgentOS 2 Live est justement cette réponse.

Qu'est-ce qu'AgentOS 2 Live

AgentOS 2 Live est une plateforme d'interaction vocale temps réel de bout en bout open source (version de prévisualisation technique) développée par OrionStar (OrionStar), construite sur l'API OpenAI Realtime. Son concept central est simple :

Nourrir directement le modèle multimodal avec de l'audio, le modèle produit directement de l'audio — pas besoin d'ASR ni de TTS intermédiaire.

L'utilisateur parle → [Encodage Opus] → WebSocket → API OpenAI Realtime → Flux audio → Lecture

En éliminant les allers-retours de deux modèles indépendants, la latence est considérablement réduite, tout en conservant les informations riches de la voix comme les émotions et le ton.

Stack technique principale

Le projet utilise une structure Monorepo, comprenant quatre sous-packages :

AgentOS2-Live/
├── client/        # Frontend React : AgentSDK, VAD, animation de visage de robot
├── server/        # Backend Node.js : Service WebSocket, orchestration OpenAI
├── shared/        # Types TypeScript et protocoles de communication partagés frontend/backend
└── e2e_android/   # Pont Android WebView pour robots OrionStar

Dépôt GitHub : OrionStarAI/end2end_sample

Analyse approfondie de l'architecture technique

Principe de fonctionnement de l'API Realtime

Le cœur de l'API OpenAI Realtime est le modèle gpt-4o-realtime-preview. Contrairement aux API REST traditionnelles, il utilise une connexion WebSocket persistante, supportant le streaming audio bidirectionnel :

Client                           Serveur (OpenAI)
  |                                |
  |-- session.update (config) ---->|
  |                                |
  |-- input_audio_buffer.append -->|  (envoi continu de trames audio encodées Opus)
  |                                |
  |-- input_audio_buffer.commit -->|  (VAD détecte une pause, soumission de l'audio)
  |                                |
  |<-- response.audio.delta -------|  (le modèle renvoie un flux audio)
  |<-- response.audio.delta -------|
  |<-- response.done --------------|

Points clés : - Pas de texte intermédiaire : Le modèle traite directement les caractéristiques audio et produit également de l'audio - Traitement en streaming : Les trames audio peuvent être envoyées pendant l'enregistrement, le modèle écoute, réfléchit et parle simultanément - Préservation des informations vocales : Le ton, les émotions, les pauses sont tous perçus par le modèle

Flux vocal de bout en bout

Suivons le voyage complet d'une trame audio du microphone au haut-parleur :

1. Capture audio PCM par le microphone (48kHz, 16bit, mono)
   ↓
2. Encodage Opus (compression à ~32kbps, réduction de la bande passante)
   ↓
3. Envoi WebSocket au backend (input_audio_buffer.append)
   ↓
4. Le backend transmet à l'API OpenAI Realtime (traitement quasi nul)
   ↓
5. Le modèle traite l'audio et génère une réponse vocale
   ↓
6. Retour d'un flux audio encodé Opus (response.audio.delta)
   ↓
7. Décodage et lecture par le client

Tout au long du processus, pas de transcription ASR, pas de synthèse TTS, le modèle "écoute" et "parle" directement.

Intégration Function Call : permettre à l'Agent d'agir

La voix temps réel n'est que la base, ce qui rend l'Agent vraiment puissant est la capacité Function Call. AgentOS 2 Live supporte le déclenchement d'appels d'outils pendant les conversations vocales :

const agent = new AgentSDK({
  modelType: 'openai',
  systemPrompt: 'Vous êtes un assistant intelligent pouvant consulter la météo, contrôler des appareils.',
  voice: 'alloy',
  tools: [
    {
      name: 'get_weather',
      description: 'Consulter la météo actuelle d\'une ville spécifiée',
      parameters: {
        type: 'object',
        properties: {
          city: { type: 'string', description: 'Nom de la ville' }
        },
        required: ['city']
      }
    },
    {
      name: 'control_light',
      description: 'Contrôler l\'allumage d\'une lampe intelligente',
      parameters: {
        type: 'object',
        properties: {
          action: { type: 'string', enum: ['on', 'off'] },
          color: { type: 'string' }
        }
      }
    }
  ]
});

agent.on('tool_call', async (toolCall) => {
  console.log('Outil déclenché:', toolCall.name, toolCall.arguments);

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

Scénario typique : - L'utilisateur dit : "Quel temps fait-il à Paris aujourd'hui ?" - Le modèle identifie l'intention et déclenche l'outil get_weather - Le backend exécute la requête et renvoie le résultat - Le modèle annonce vocalement : "Il fait beau à Paris aujourd'hui, température de 25 degrés."

Tout le processus se déroule de manière transparente dans la conversation vocale, l'utilisateur a l'impression de parler à une personne réelle.

Comparaison d'architecture : Traditionnel vs AgentOS 2 Live

Visualisation de la comparaison de latence :

Architecture traditionnelle :
L'utilisateur parle ──[ASR 300ms]──> Texte ──[LLM 500ms]──> Réponse ──[TTS 400ms]──> Lecture
         Latence totale : 1200ms+

AgentOS 2 Live :
L'utilisateur parle ──[Encodage Opus 50ms]──> WebSocket ──[API Realtime 400ms]──> Flux audio ──> Lecture
         Latence totale : 450-800ms

Caractéristiques principales détaillées

1. Interaction vocale à très basse latence

L'avantage de latence d'AgentOS 2 Live provient de la simplification au niveau architectural. La solution traditionnelle nécessite trois modèles indépendants travaillant en série, chacun ayant son propre temps d'inférence et ses allers-retours réseau. L'API Realtime fusionne la compréhension vocale, le raisonnement et la génération vocale en un seul modèle :

• Encodage/décodage Opus : L'audio est encodé en Opus, avec un taux de compression élevé et une faible latence, adapté au transport temps réel
• Connexion WebSocket persistante : Évite les coûts de handshake des requêtes HTTP, les trames audio circulent continuellement dans les deux sens
• VAD frontend : Détecte l'activité vocale dans le navigateur, soumet l'audio immédiatement après que l'utilisateur arrête de parler, pas de temps perdu sur les segments silencieux
• Transmission backend : Le backend Node.js ne fait presque aucun traitement supplémentaire, responsable uniquement du routage WebSocket et de la sécurité des clés API

2. Détection d'activité vocale (VAD) intégrée

Le VAD est un composant central des systèmes vocaux temps réel. Sans VAD, le système ne peut pas savoir quand l'utilisateur a fini de parler. AgentOS 2 Live intègre un module VAD haute performance dans le frontend :

// Flux de travail VAD
// 1. Écoute continue du flux audio du microphone
// 2. Détection d'activité vocale → démarrage de l'enregistrement et envoi des trames audio
// 3. Détection de fin de voix (pause dépassant le seuil) → commit automatique
// 4. Attente de la réponse du modèle

La sensibilité du VAD affecte directement l'expérience utilisateur — trop sensible, il interrompt fréquemment l'utilisateur ; trop lent, il fait attendre l'utilisateur trop longtemps. Le VAD d'AgentOS 2 Live est automatiquement configuré via le script postinstall, prêt à l'emploi.

3. UI d'animation de visage de robot

C'est une caractéristique facilement négligée mais extrêmement importante. Le client d'AgentOS 2 Live comprend une animation de visage de robot en temps réel, changeant d'expression selon l'état de la conversation :

Ce retour visuel rend l'interaction plus naturelle — l'utilisateur peut percevoir intuitivement ce que le système fait actuellement, plutôt que de deviner face à une interface statique.

4. Deux scénarios intégrés

Le projet fournit deux scénarios de démonstration prêts à l'emploi :

• Face Register : Enregistrement de visage et identification d'identité, adapté aux systèmes de membres, scénarios de nom réel
• Advice 3C : Guide d'achat de produits 3C, l'IA recommande téléphones, ordinateurs, écouteurs selon les besoins de l'utilisateur

Ces deux scénarios démontrent la capacité d'AgentOS 2 Live à se déployer dans des domaines verticaux.

Déploiement local pratique

Configuration matérielle requise

Note : AgentOS 2 Live ne nécessite pas de GPU — toute l'inférence IA est effectuée dans le cloud OpenAI. Localement, seuls les services frontend et backend fonctionnent.

Étapes d'installation

Première étape : Cloner le dépôt

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

Deuxième étape : Installer les dépendances

npm install

Le script postinstall copiera automatiquement les actifs VAD dans le répertoire client/public.

Troisième étape : Configurer les variables d'environnement

Créer un fichier .env à la racine du projet :

# Configuration API OpenAI (doit avoir les permissions Realtime API)
OPENAI_API_KEY=«redacted:sk-…»

# Port de service
PORT=8081

# Mode SSL (recommandé en production)
USE_SSL=false

Important : Votre clé API OpenAI doit avoir accès au modèle gpt-4o-realtime-preview. Si l'appel renvoie 403, vous devez demander les permissions Realtime API sur la plateforme OpenAI.

Quatrième étape : Démarrer en mode développement

npm run dev

Cela démarrera simultanément le frontend et le backend : - Frontend : http://localhost:3000 - Backend : http://localhost:8081

Ouvrez le navigateur sur le port 3000 pour voir l'interface de visage de robot. Cliquez sur le bouton microphone pour démarrer la conversation.

Déploiement en production

# Construire le frontend et le backend de production
npm run build

# Démarrer le service de production (un processus fournit à la fois les fichiers statiques et le WebSocket)
node server/dist/index.js

En mode production, le server assume à la fois le service de fichiers statiques et le service WebSocket, sans configuration supplémentaire de proxy inverse Nginx (bien sûr, en production, il est recommandé d'ajouter Nginx pour la terminaison SSL et l'équilibrage de charge).

Configuration proxy inverse Nginx (optionnel)

server {
    listen 443 ssl;
    server_name voice.votredomaine.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;  # Connexion WebSocket persistante
    }
}

Intégration matérielle robot

La capacité la plus unique d'AgentOS 2 Live est le contrôle direct de robots physiques. Le projet comprend une couche de pont Android WebView (e2e_android/), permettant au frontend Web d'appeler les capacités matérielles des robots OrionStar.

Conception architecturale

Frontend React (Web)
    ↓ Pont JavaScript
Android WebView (Kotlin)
    ↓ SDK RobotService
Matériel robot (rotation de tête, navigation de châssis, capteurs)

Déploiement sur robot OrionStar

Préparation : - Android Studio - Obtenir robotservice_xx.jar du système du robot, le placer dans e2e_android/app/libs/

Construction et installation :

# 1. Ouvrir le répertoire e2e_android avec Android Studio
# 2. Synchronisation Gradle
# 3. Connecter le robot par USB (s'assurer que l'ADB est activé)
# 4. Cliquer sur Run pour installer sur le robot

Configuration de l'adresse du serveur :

Par défaut, charge http://localhost:3000. Si votre service est déployé à une autre adresse, modifiez MainActivity.kt :

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

Capacités de contrôle matériel

Via le pont WebView, le frontend peut appeler : - Rotation de tête : Faire regarder le robot dans la direction de la parole - Navigation de châssis : Déplacement autonome vers une position spécifiée - Lecture de capteurs : Obtenir des données environnementales - Contrôle LED : Ajuster les effets lumineux

Cela signifie que vous pouvez implémenter une interaction robot complète avec du code React — conversation vocale + mouvements corporels + perception environnementale.

Guide développeur : Function personnalisée

L'AgentSDK d'AgentOS 2 Live simplifie la création d'outils personnalisés. Voici le processus de développement complet :

Définir le schéma de l'outil

const tools = [
  {
    name: 'search_products',
    description: 'Rechercher des produits selon les besoins de l\'utilisateur',
    parameters: {
      type: 'object',
      properties: {
        category: { 
          type: 'string', 
          enum: ['téléphone', 'ordinateur', 'écouteurs'] 
        },
        budget: { 
          type: 'number', 
          description: 'Budget maximum (yuan)' 
        },
        brand: { 
          type: 'string', 
          description: 'Préférence de marque' 
        }
      },
      required: ['category']
    }
  }
];

Implémenter la logique de l'outil

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

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

    // Renvoyer le résultat au modèle
    agent.sendToolResult(toolCall.call_id, {
      success: true,
      count: products.length,
      items: products.slice(0, 5)
    });
  }
});

Changement dynamique de scénario

Vous pouvez changer dynamiquement le systemPrompt selon l'intention de l'utilisateur :

// Détection que l'utilisateur veut acheter
if (userIntent === 'shopping') {
  agent.updateConfig({
    systemPrompt: 'Vous êtes un guide d\'achat de produits 3C, recommandez des produits selon les besoins de l\'utilisateur.'
  });
}

// Détection que l'utilisateur veut discuter
if (userIntent === 'chat') {
  agent.updateConfig({
    systemPrompt: 'Vous êtes un compagnon de discussion amical, pouvez parler de n\'importe quel sujet.'
  });
}

Tests de performance de référence

Nous avons testé la latence de première réponse dans différentes conditions réseau :

Conditions de test : - Matériel : MacBook Pro M2, 16GB RAM - Microphone : Microphone intégré - Modèle : gpt-4o-realtime-preview-2024-10-01 - Voix : alloy (voix féminine) - Phrases de test : 10 phrases courtes en chinois, chaque phrase répétée 5 fois pour la moyenne

Constatations clés : - La latence réseau affecte moins AgentOS 2 Live (car un seul aller-retour) - La solution traditionnelle est plus affectée par le réseau (trois allers-retours cumulés) - Le VAD est stable en environnement calme, un microphone avec réduction de bruit est recommandé en environnement bruyant

Limitations et considérations

Statut de version de prévisualisation technique

AgentOS 2 Live est actuellement une version de prévisualisation technique, à noter pour l'utilisation en production :

1. Coût API : L'API Realtime facture à la durée audio, les conversations longues coûtent cher
2. Limitations de modèle : Actuellement supporte uniquement l'API OpenAI Realtime, ne peut pas utiliser de modèles locaux ou d'autres fournisseurs cloud
3. Support linguistique : Bien que le modèle supporte plusieurs langues, la qualité vocale en chinois est légèrement inférieure à l'anglais
4. Limitations de concurrence : Une instance ne peut gérer qu'une session de conversation, plusieurs utilisateurs nécessitent le déploiement de plusieurs instances
5. Indisponible hors ligne : Dépend entièrement du cloud OpenAI, une panne de réseau rend inopérant

Scénarios applicables

Adapté pour : - Robots de guide intelligent dans les halls d'exposition/magasins - Comptoirs de consultation service client - Assistants vocaux de maison intelligente - Robots de tutorat éducatif

Non adapté pour : - Scénarios nécessitant un fonctionnement hors ligne - Scénarios avec des exigences très élevées de confidentialité des données (audio téléchargé dans le cloud) - Projets à budget limité ne pouvant supporter les coûts API

FAQ

Q1 : L'API OpenAI Realtime est-elle obligatoire ? Peut-on utiliser d'autres modèles ?

Actuellement, le projet supporte uniquement l'API OpenAI Realtime (modelType: 'openai'). Mais comme le protocole de communication est clairement défini dans shared/, il est théoriquement possible d'étendre le support à d'autres modèles temps réel compatibles WebSocket (comme Azure OpenAI, des modèles temps réel open source déployés localement). Cependant, cela nécessite un travail de refonte important.

Q2 : Quelle est la latence concrète ?

Selon nos tests, la latence de première réponse en environnement calme est de 600-1000ms (incluant les allers-retours réseau). C'est 40-50% plus rapide que les solutions ASR→LLM→TTS traditionnelles, mais il reste de la place pour l'optimisation. Si la latence réseau est élevée (comme l'accès transfrontalier), la latence augmente à 1000-1500ms.

Q3 : Comment l'animation de visage de robot est-elle implémentée ?

Via des composants React écoutant en temps réel l'état de la conversation (utilisateur parle, IA parle, réflexion, inactif), changeant différentes animations SVG ou Lottie. Le code est dans les composants UI du répertoire client/, vous pouvez personnaliser le style d'animation selon les besoins de votre marque.

Q4 : Comment ajouter de nouveaux scénarios ?

La manière la plus simple est de modifier le systemPrompt, ou de maintenir plusieurs sessions dans le backend, changeant dynamiquement le prompt selon l'intention de l'utilisateur. Le mécanisme d'appel d'outils supporte également l'extension de flux métier complexes. Les Face Register et Advice 3C intégrés au projet sont de bons modèles de référence.

Q5 : Que faut-il noter pour l'utilisation commerciale ?

Le README indique clairement : Ce projet est uniquement pour la démonstration et les tests. Lors de l'utilisation commerciale, vous devez respecter les politiques d'utilisation d'OpenAI, en particulier : - La synthèse vocale doit divulguer "la voix est générée par l'IA" - Ne pas utiliser pour la fraude, la tromperie ou d'autres utilisations illégales - Assumer les frais d'appel API - Consulter le service juridique pour confirmer la conformité

Conclusion et perspectives

AgentOS 2 Live représente une direction importante pour les agents vocaux : l'interaction temps réel de bout en bout. Il prouve qu'il n'est pas nécessaire d'avoir un pipeline ASR→LLM→TTS complexe pour construire des assistants vocaux à faible latence et naturels.

Valeur centrale : - Simplification architecturale : un modèle remplace trois modules - Réduction de latence : première réponse 40-50% plus rapide - Préservation de l'information : les émotions et le ton de la voix sont entièrement conservés - Efficacité de développement : débogage unifié, pas besoin d'assembler plusieurs flux

Perspectives futures : Avec la maturité des modèles temps réel open source (comme SpeechLlama de Meta, Gemini Realtime de Google), nous pouvons espérer voir : - Solutions vocales temps réel déployées localement (résolvant les problèmes de confidentialité et de coût) - Fusion multimodale (voix + vision + action) - Latence encore plus faible (<300ms) - Expressivité vocale plus riche (émotions, dialectes, multi-rôles)

Si vous cherchez un framework d'assistant vocal temps réel à prise en main rapide, AgentOS 2 Live est un excellent point de départ. Il a déjà résolu pour vous les problèmes les plus complexes d'encodage/décodage audio, de VAD et de cohérence des protocoles frontend/backend. Du clonage du dépôt à la mise en route d'une conversation, généralement moins de 30 minutes.

Liens connexes : - Documentation officielle de l'API OpenAI Realtime - OrionStarAI/end2end_sample GitHub - OpenAI Agents SDK

Tags de cet article : AI Agent, 实时语音, OpenAI, Realtime API, 语音助手, 机器人