Événements client
Événements client
Comprendre et gérer les événements en temps réel reçus par le client dans les applications conversationnelles.
Les événements client sont des événements système envoyés du serveur au client afin de faciliter la communication en temps réel. Ces événements transmettent l’audio, la transcription, les réponses de l’agent et d’autres informations essentielles à l’application cliente.
Pour en savoir plus sur les événements que vous pouvez envoyer du client au serveur, consultez la documentation sur les événements du client vers le serveur.
Vue d’ensemble
Les événements client sont essentiels pour préserver le caractère temps réel des conversations. Ils fournissent toutes les informations, des métadonnées d’initialisation à l’audio traité et aux réponses de l’agent.
Ces événements font partie du protocole de communication WebSocket et sont automatiquement gérés par nos SDK. Les comprendre est essentiel pour les implémentations avancées et le débogage.
Types d’événements client
conversation_initiation_metadata
- Envoyé automatiquement au démarrage d’une conversation
- Initialise les paramètres et réglages de la conversation
queue_status
- Envoyé uniquement aux appelants placés dans la file d’attente des appels lorsque l’agent a atteint sa limite de requêtes simultanées
waitingest envoyé une fois, aprèsconversation_initiation_metadataet avant tout audio d’attenteadmittedoutimed_outest envoyé une fois à la fin de l’attente.timed_outest suivi d’une fermeture WebSocket avec le code 4300- Toujours envoyé aux appelants en attente. Il n’est pas nécessaire de l’activer dans la configuration
client_eventsde l’agent
Lorsqu’un appelant est en attente, l’audio d’attente arrive sous forme d’événements audio classiques. Utilisez cet événement pour afficher un état d’attente plutôt que de traiter l’audio d’attente comme la parole de l’agent.
ping
- Événement de vérification de l’état nécessitant une réponse immédiate
- Géré automatiquement par le SDK
- Utilisé pour maintenir la connexion WebSocket
audio
- Contient l’audio encodé en base64 pour la lecture
- Inclut un ID d’événement numérique pour le suivi et le séquençage
- Gère le streaming de la sortie vocale
- Inclut des données d’alignement avec des informations de synchronisation au niveau des caractères
Sur les connexions WebRTC, l’événement audio n’est pas envoyé, car l’audio est géré directement par LiveKit.
user_transcript
- Contient les résultats finalisés de la conversion parole-texte
- Représente les énoncés complets de l’utilisateur
- Utilisé pour l’historique de la conversation
agent_response
- Contient le message complet de l’agent
- Envoyé une fois le message terminé. Dans les conversations vocales, il arrive donc généralement après le début du streaming audio du message.
- Utilisé pour l’affichage et l’historique
Pour afficher le texte de l’agent au fur et à mesure de sa génération, utilisez plutôt l’événement agent_chat_response_part décrit ci-dessous, sans attendre cet événement.
agent_response_correction
- Contient la réponse tronquée après une interruption
- Met à jour le message affiché
- Préserve l’exactitude de la conversation
agent_response_metadata
- Contient des métadonnées arbitraires provenant d’une réponse LLM personnalisée
- Envoyé uniquement lors de l’utilisation d’un LLM personnalisé
- Doit être explicitement activé dans la configuration
client_eventsde l’agent
Cet événement est propre aux intégrations LLM personnalisées. Il permet à votre serveur LLM personnalisé de transmettre des métadonnées supplémentaires avec la réponse, que l’application cliente peut exploiter.
client_tool_call
- Représente un appel de fonction que l’agent souhaite faire exécuter par le client
- Contient le nom de l’outil, l’ID de l’appel d’outil et les paramètres
- Nécessite l’exécution côté client de la fonction et l’envoi du résultat au serveur
Si vous utilisez le SDK, des rappels sont fournis pour gérer l’envoi du résultat au serveur.
agent_tool_response
- Indique que l’agent a exécuté une fonction d’outil
- Contient les métadonnées de l’outil et le statut d’exécution
- Offre une visibilité sur l’utilisation des outils par l’agent pendant les conversations
agent_tool_response_full_payload
- Reflète
agent_tool_responseet transmet également le résultat complet de l’outil sous forme de chaîne dansfull_tool_result. - Expose la sortie de l’outil dans le client pour l’affichage ou le traitement en aval.
- Doit être explicitement activé dans la configuration
client_eventsde l’agent.
Cet événement expose le résultat complet de l’outil au client et peut contenir des données sensibles. Activez-le uniquement lorsque le client est digne de confiance pour gérer cette charge utile. Les résultats dépassant 64 Ko sont automatiquement tronqués.
React
JavaScript
vad_score
- Événement de score de détection d’activité vocale
- Indique la probabilité que l’utilisateur parle
- Les valeurs vont de 0 à 1, les valeurs élevées indiquant une plus grande certitude de parole
mcp_tool_call
- Indique que l’agent a exécuté une fonction d’outil MCP
- Contient le nom de l’outil, l’ID de l’appel d’outil et les paramètres
- Appelé avec l’un des quatre états suivants :
loading,awaiting_approval,successetfailure.
agent_chat_response_part
- Transmet en streaming le texte de réponse de l’agent à mesure de sa génération, sous forme de messages
start,deltaetstop - Toujours envoyé en mode texte uniquement ; dans les conversations vocales, il doit être explicitement activé dans la configuration
client_eventsde l’agent - Non envoyé lorsque l’agent ou une procédure active utilise un garde-fou bloquant, qui doit évaluer l’intégralité de la réponse avant qu’une partie ne soit diffusée
response_ididentifie le message diffusé et correspond auresponse_idde l’élémentagent_responsequi le valide ultérieurement
agent_reasoning_response_part
agent_reasoning_response_part transmet en streaming le raisonnement fourni par le modèle lors de conversations en texte uniquement. Activez l’événement dans client_events et activez le résumé du raisonnement pour l’agent. Le serveur envoie des messages start, delta et stop. Il n’envoie pas cet événement lors des conversations vocales ni lorsque l’agent ou une procédure active utilise des garde-fous bloquants.
Cet événement et le rappel SDK correspondant sont expérimentaux. Leur comportement et leur structure peuvent changer dans toute version.
Les événements de début et de fin utilisent une valeur text vide.
agent_response_complete
- Se déclenche lorsque l’agent a terminé sa réponse, y compris les éventuels appels d’outils en attente. Après cet événement, l’agent ne produira de nouvelle sortie que si l’utilisateur fournit une nouvelle entrée ou qu’un délai d’expiration de tour déclenche un nouveau tour.
- Doit être explicitement activé dans la configuration
client_eventsde l’agent
guardrail_triggered
- Se déclenche lorsqu’une violation d’un garde-fou met fin à la conversation. N’est pas envoyé lorsqu’un garde-fou déclenche une nouvelle tentative qui réussit.
- L’événement lui-même constitue le signal, il ne contient aucune charge utile au-delà du champ
type. - Doit être explicitement activé dans la configuration
client_eventsde l’agent.
Flux d’événements
Voici une séquence d’événements typique au cours d’une conversation :
Lorsqu’un agent atteint sa limite de requêtes simultanées et que la mise en file d’attente des appels est activée, le serveur envoie des événements queue_status entre conversation_initiation_metadata et le premier événement audio. L’audio d’attente est transmis sous forme d’événements audio jusqu’à l’admission de l’appelant.
Bonnes pratiques
-
Gestion des erreurs
- Mettez en place une gestion des erreurs adaptée à chaque type d’événement
- Consignez les événements importants à des fins de débogage
- Gérez les interruptions de connexion avec élégance
-
Gestion de l’audio
- Mettez les segments audio en mémoire tampon de manière appropriée
- Mettez en place un nettoyage approprié en cas d’interruption
- Gérez les ressources audio
-
Gestion des connexions
- Répondez rapidement aux événements PING
- Mettez en place une logique de reconnexion
- Surveillez l’état de la connexion
Résolution des problèmes
Problèmes de connexion
- Assurez-vous que la connexion WebSocket est correctement établie
- Vérifiez les réponses PING/PONG
- Vérifiez les identifiants API
Problèmes audio
- Vérifiez le traitement des segments audio
- Vérifiez la compatibilité des formats audio
- Surveillez l’utilisation de la mémoire
Gestion des événements
- Consignez tous les événements à des fins de débogage
- Mettez en place des limites d’erreur
- Vérifiez l’enregistrement des gestionnaires d’événements
Pour des exemples d’implémentation détaillés, consultez notre documentation des SDK.