Eventi client
Gli eventi client sono eventi a livello di sistema inviati dal server al client che facilitano la comunicazione in tempo reale. Questi eventi forniscono audio, trascrizioni, risposte dell’agente e altre informazioni critiche all’applicazione client.
Per informazioni sugli eventi che puoi inviare dal client al server, consulta la documentazione sugli eventi dal client al server.
Panoramica
Gli eventi client sono essenziali per mantenere le conversazioni in tempo reale. Forniscono ogni elemento, dai metadati di inizializzazione all’audio elaborato e alle risposte dell’agente.
Questi eventi fanno parte del protocollo di comunicazione WebSocket e vengono gestiti automaticamente dai nostri SDK. Comprenderli è fondamentale per implementazioni avanzate e debug.
Tipi di eventi client
conversation_initiation_metadata
- Inviato automaticamente all’avvio di una conversazione
- Inizializza le impostazioni e i parametri della conversazione
queue_status
- Inviato soltanto ai chiamanti in attesa nella coda delle chiamate mentre l’agente ha raggiunto il limite di concorrenza
waitingviene inviato una volta, dopoconversation_initiation_metadatae prima di qualsiasi audio di attesaadmittedotimed_outviene inviato una volta al termine dell’attesa. Dopotimed_out, il WebSocket viene chiuso con il codice 4300- Viene sempre inviato ai chiamanti in coda. Non deve essere abilitato nella configurazione
client_eventsdell’agente
Mentre un chiamante è in coda, l’audio di attesa arriva come normali eventi audio. Usa questo evento per mostrare uno
stato di attesa invece di trattare l’audio di attesa come voce dell’agente.
ping
- Evento di controllo dello stato che richiede una risposta immediata
- Gestito automaticamente dall’SDK
- Utilizzato per mantenere la connessione WebSocket
audio
- Contiene audio codificato in base64 per la riproduzione
- Include un ID evento numerico per il monitoraggio e l’ordinamento
- Gestisce lo streaming dell’output vocale
- Include dati di allineamento con informazioni temporali a livello di carattere
Nelle connessioni WebRTC, l’evento audio non viene inviato perché l’audio viene gestito direttamente da LiveKit.
user_transcript
- Contiene risultati definitivi della conversione da voce a testo
- Rappresenta enunciati completi dell’utente
- Utilizzato per la cronologia della conversazione
agent_response
- Contiene il messaggio completo dell’agente
- Viene inviato quando il messaggio è terminato, quindi nelle conversazioni vocali di solito arriva dopo che l’audio del messaggio ha già iniziato lo streaming.
- Utilizzato per la visualizzazione e la cronologia
Per visualizzare il testo dell’agente mentre viene generato, usa l’evento agent_chat_response_part
descritto di seguito anziché attendere questo evento.
agent_response_correction
- Contiene la risposta troncata dopo un’interruzione
- Aggiorna il messaggio visualizzato
- Mantiene l’accuratezza della conversazione
agent_response_metadata
- Contiene metadati arbitrari da una risposta LLM personalizzata
- Inviato solo quando usi un LLM personalizzato
- Deve essere abilitato esplicitamente nella configurazione
client_eventsdell’agente
Questo evento è specifico delle integrazioni LLM personalizzate. Permette al tuo server LLM personalizzato di trasmettere metadati aggiuntivi insieme alla risposta, che possono essere utilizzati dall’applicazione client.
client_tool_call
- Rappresenta una chiamata di funzione che l’agente vuole far eseguire al client
- Contiene il nome dello strumento, l’ID della chiamata dello strumento e i parametri
- Richiede l’esecuzione lato client della funzione e l’invio del risultato al server
Se usi l’SDK, sono disponibili callback per gestire l’invio del risultato al server.
agent_tool_response
- Indica quando l’agente ha eseguito una funzione di uno strumento
- Contiene i metadati dello strumento e lo stato di esecuzione
- Offre visibilità sull’uso degli strumenti dell’agente durante le conversazioni
agent_tool_response_full_payload
- Rispecchia
agent_tool_responsee trasmette inoltre il payload completo del risultato dello strumento come stringa infull_tool_result. - Espone l’output dello strumento nel client per la visualizzazione o l’elaborazione a valle.
- Deve essere abilitato esplicitamente nella configurazione
client_eventsdell’agente.
Questo evento espone al client il risultato completo dello strumento e potrebbe contenere dati sensibili. Abilitalo solo quando il client è affidabile per gestire il payload. I risultati superiori a 64 KB vengono automaticamente troncati.
React
JavaScript
vad_score
- Evento relativo al punteggio di rilevamento dell’attività vocale
- Indica la probabilità che l’utente stia parlando
- I valori vanno da 0 a 1, dove valori più alti indicano una maggiore confidenza nella presenza di parlato
mcp_tool_call
- Indica quando l’agente ha eseguito una funzione di uno strumento MCP
- Contiene il nome dello strumento, l’ID della chiamata dello strumento e i parametri
- Viene chiamato con uno di quattro stati:
loading,awaiting_approval,successefailure.
agent_chat_response_part
- Trasmette in streaming il testo della risposta dell’agente mentre viene generato, come messaggi
start,deltaestop - Viene sempre inviato nella modalità solo testo; nelle conversazioni vocali deve essere abilitato esplicitamente nella configurazione
client_eventsdell’agente - Non viene inviato mentre l’agente o una procedura attiva usa un guardrail bloccante, che deve valutare l’intera risposta prima che una sua parte venga rilasciata
response_ididentifica il messaggio in streaming e corrisponde alresponse_iddiagent_responseche lo conferma in seguito
agent_reasoning_response_part
agent_reasoning_response_part trasmette in streaming il ragionamento fornito dal modello durante le conversazioni solo testo.
Abilita l’evento in client_events e attiva il riepilogo del
ragionamento per l’agente. Il server invia
messaggi start, delta e stop. Non invia questo evento durante le conversazioni vocali né
mentre l’agente o una procedura attiva usa guardrail bloccanti.
Questo evento e il callback SDK corrispondente sono sperimentali. Il loro comportamento e la loro struttura potrebbero cambiare in qualsiasi versione.
Gli eventi di inizio e fine usano un valore text vuoto.
agent_response_complete
- Si attiva quando l’agente ha completato la sua risposta, incluse eventuali chiamate di strumenti in sospeso. Dopo questo evento, l’agente produrrà ulteriori output solo se l’utente fornisce un nuovo input o se un timeout del turno attiva un nuovo turno.
- Deve essere abilitato esplicitamente nella configurazione
client_eventsdell’agente
guardrail_triggered
- Si attiva quando una violazione di un guardrail termina la conversazione. Non viene inviato quando un guardrail attiva un nuovo tentativo che riesce.
- L’evento stesso è il segnale: non contiene payload oltre al campo
type. - Deve essere abilitato esplicitamente nella configurazione
client_eventsdell’agente.
Flusso degli eventi
Ecco una tipica sequenza di eventi durante una conversazione:
Quando un agente ha raggiunto il limite di concorrenza e l’accodamento delle chiamate è abilitato, il server invia eventi queue_status tra conversation_initiation_metadata e il primo evento audio. L’audio di attesa viene inviato come eventi audio finché il chiamante non viene ammesso.
Best practice
-
Gestione degli errori
- Implementa una corretta gestione degli errori per ogni tipo di evento
- Registra gli eventi importanti per il debug
- Gestisci correttamente le interruzioni della connessione
-
Gestione dell’audio
- Memorizza nel buffer i chunk audio in modo appropriato
- Implementa una corretta pulizia in caso di interruzione
- Gestisci le risorse audio
-
Gestione della connessione
- Rispondi tempestivamente agli eventi PING
- Implementa la logica di riconnessione
- Monitora lo stato della connessione
Risoluzione dei problemi
Problemi di connessione
- Assicurati che la connessione WebSocket sia configurata correttamente
- Controlla le risposte PING/PONG
- Verifica le credenziali API
Problemi audio
- Controlla la gestione dei chunk audio
- Verifica la compatibilità del formato audio
- Monitora l’utilizzo della memoria
Gestione degli eventi
- Registra tutti gli eventi per il debug
- Implementa gli error boundary
- Controlla la registrazione degli event handler
Per esempi di implementazione dettagliati, consulta la documentazione SDK.