Client-Ereignisse
Client-Ereignisse
Echtzeitereignisse verstehen und verarbeiten, die der Client während konversationeller Anwendungen empfängt.
Client-Ereignisse sind Ereignisse auf Systemebene, die vom Server an den Client gesendet werden und die Echtzeitkommunikation ermöglichen. Diese Ereignisse übermitteln Audio, Transkriptionen, Agentenantworten und weitere wichtige Informationen an die Client-Anwendung.
Informationen zu Ereignissen, die Sie vom Client an den Server senden können, finden Sie in der Dokumentation zu Client-zu-Server-Ereignissen.
Überblick
Client-Ereignisse sind entscheidend, um den Echtzeitcharakter von Gesprächen aufrechtzuerhalten. Sie liefern alles von Initialisierungsmetadaten bis hin zu verarbeitetem Audio und Agentenantworten.
Diese Ereignisse sind Teil des WebSocket-Kommunikationsprotokolls und werden automatisch von unseren SDKs verarbeitet. Ihr Verständnis ist entscheidend für erweiterte Implementierungen und das Debugging.
Client-Ereignistypen
conversation_initiation_metadata
- Wird beim Start einer Unterhaltung automatisch gesendet
- Initialisiert Unterhaltungseinstellungen und -parameter
queue_status
- Wird nur an Anrufer in der Anrufwarteschlange gesendet, während der Agent sein Parallelitätslimit erreicht hat
waitingwird einmal gesendet, nachconversation_initiation_metadataund vor Wartemusikadmittedodertimed_outwird einmal gesendet, wenn die Wartezeit endet. Auftimed_outfolgt das Schließen des WebSockets mit Code 4300- Wird immer an wartende Anrufer gesendet. Es muss nicht in der
client_events-Konfiguration des Agents aktiviert werden
Während ein Anrufer wartet, wird Wartemusik als reguläres audio-Ereignis empfangen. Verwenden Sie dieses Ereignis,
um einen Wartestatus anzuzeigen, statt die Wartemusik als Agentensprache zu behandeln.
ping
- Zustandsprüfungsereignis, das eine sofortige Antwort erfordert
- Wird automatisch vom SDK verarbeitet
- Dient zur Aufrechterhaltung der WebSocket-Verbindung
audio
- Enthält Base64-codiertes Audio zur Wiedergabe
- Enthält eine numerische Ereignis-ID zur Nachverfolgung und Sequenzierung
- Verarbeitet das Streaming der Sprachausgabe
- Enthält Ausrichtungsdaten mit Timing-Informationen auf Zeichenebene
Bei WebRTC-Verbindungen wird das audio-Ereignis nicht gesendet, da Audio direkt von LiveKit verarbeitet wird.
user_transcript
- Enthält abgeschlossene Speech-to-Text-Ergebnisse
- Stellt vollständige Äußerungen des Nutzers dar
- Dient dem Unterhaltungsverlauf
agent_response
- Enthält die vollständige Agentennachricht
- Wird gesendet, sobald die Nachricht abgeschlossen ist. In Sprachunterhaltungen trifft es daher meist ein, nachdem das Audio der Nachricht bereits gestreamt wird.
- Dient zur Anzeige und für den Verlauf
Um den Text des Agents während seiner Generierung anzuzeigen, verwenden Sie das unten beschriebene Ereignis agent_chat_response_part,
statt auf dieses Ereignis zu warten.
agent_response_correction
- Enthält die gekürzte Antwort nach einer Unterbrechung
- Aktualisiert die angezeigte Nachricht
- Erhält die Genauigkeit der Unterhaltung
agent_response_metadata
- Enthält beliebige Metadaten aus einer benutzerdefinierten LLM-Antwort
- Wird nur bei Verwendung eines benutzerdefinierten LLM gesendet
- Muss ausdrücklich in der
client_events-Konfiguration des Agents aktiviert werden
Dieses Ereignis gilt speziell für benutzerdefinierte LLM-Integrationen. Es ermöglicht Ihrem benutzerdefinierten LLM-Server, zusätzliche Metadaten zusammen mit der Antwort zu übergeben, die von der Client-Anwendung genutzt werden können.
client_tool_call
- Stellt einen Funktionsaufruf dar, den der Agent vom Client ausführen lassen möchte
- Enthält Toolname, Tool-Call-ID und Parameter
- Erfordert die clientseitige Ausführung der Funktion und das Zurücksenden des Ergebnisses an den Server
Wenn Sie das SDK verwenden, stehen Callbacks zur Verfügung, um das Ergebnis an den Server zurückzusenden.
agent_tool_response
- Gibt an, wann der Agent eine Tool-Funktion ausgeführt hat
- Enthält Tool-Metadaten und Ausführungsstatus
- Ermöglicht Einblick in die Tool-Nutzung des Agents während Unterhaltungen
agent_tool_response_full_payload
- Entspricht
agent_tool_responseund streamt zusätzlich die vollständige Ergebnis-Payload des Tools als String infull_tool_result. - Stellt die Tool-Ausgabe im Client zur Anzeige oder Weiterverarbeitung bereit.
- Muss ausdrücklich in der
client_events-Konfiguration des Agents aktiviert werden.
Dieses Ereignis legt das vollständige Tool-Ergebnis im Client offen und kann sensible Daten enthalten. Aktivieren Sie es nur, wenn der Client die Payload vertrauenswürdig verarbeiten kann. Ergebnisse über 64 KB werden automatisch gekürzt.
React
JavaScript
vad_score
- Ereignis mit Voice-Activity-Detection-Score
- Gibt die Wahrscheinlichkeit an, dass der Nutzer spricht
- Werte reichen von 0 bis 1, wobei höhere Werte eine höhere Sprechsicherheit anzeigen
mcp_tool_call
- Gibt an, wann der Agent eine MCP-Tool-Funktion ausgeführt hat
- Enthält Toolname, Tool-Call-ID und Parameter
- Wird mit einem von vier Status aufgerufen:
loading,awaiting_approval,successundfailure.
agent_chat_response_part
- Streamt den Antworttext des Agents während seiner Generierung als Nachrichten
start,deltaundstop - Wird im reinen Textmodus immer gesendet. In Sprachunterhaltungen muss es ausdrücklich in der
client_events-Konfiguration des Agents aktiviert werden - Wird nicht gesendet, während der Agent oder eine aktive Prozedur eine blockierende Guardrail verwendet, die die gesamte Antwort bewerten muss, bevor ein Teil davon freigegeben wird
response_ididentifiziert die gestreamte Nachricht und entspricht derresponse_idvonagent_response, die sie später bestätigt
agent_reasoning_response_part
agent_reasoning_response_part streamt vom Modell bereitgestellte Begründungen während reiner Textunterhaltungen.
Aktivieren Sie das Ereignis in client_events und die Zusammenfassung der
Begründung für den Agenten. Der Server sendet
start-, delta- und stop-Nachrichten. Während Sprachunterhaltungen oder
wenn der Agent oder eine aktive Prozedur blockierende Guardrails verwendet, wird dieses Ereignis nicht gesendet.
Dieses Ereignis und der entsprechende SDK-Callback sind experimentell. Ihr Verhalten und ihre Struktur können sich in jeder Version ändern.
Start- und Stopp-Ereignisse verwenden einen leeren text-Wert.
agent_response_complete
- Wird ausgelöst, wenn der Agent seine Antwort einschließlich ausstehender Tool-Aufrufe abgeschlossen hat. Nach diesem Ereignis erzeugt der Agent nur weitere Ausgaben, wenn der Nutzer neue Eingaben bereitstellt oder ein Turn-Timeout einen neuen Turn auslöst.
- Muss ausdrücklich in der
client_events-Konfiguration des Agents aktiviert werden
guardrail_triggered
- Wird ausgelöst, wenn eine Verletzung einer Guardrail die Unterhaltung beendet. Wird nicht gesendet, wenn eine Guardrail einen erfolgreichen Wiederholungsversuch auslöst.
- Das Ereignis selbst ist das Signal – es enthält keine Payload außer dem Feld
type. - Muss ausdrücklich in der
client_events-Konfiguration des Agents aktiviert werden.
Ereignisablauf
Hier ist eine typische Ereignisabfolge während einer Unterhaltung:
Wenn ein Agent sein Parallelitätslimit erreicht hat und Warteschlangen für Anrufe aktiviert ist, sendet der Server zwischen conversation_initiation_metadata und dem ersten audio-Ereignis queue_status-Ereignisse. Wartemusik wird als audio-Ereignisse bereitgestellt, bis der Anrufer zugelassen wird.
Best Practices
-
Fehlerbehandlung
- Implementieren Sie eine korrekte Fehlerbehandlung für jeden Ereignistyp.
- Protokollieren Sie wichtige Ereignisse zur Fehlerbehebung.
- Behandeln Sie Verbindungsunterbrechungen zuverlässig.
-
Audioverwaltung
- Puffern Sie Audio-Chunks angemessen.
- Implementieren Sie eine korrekte Bereinigung bei Unterbrechungen.
- Verwalten Sie Audioressourcen korrekt.
-
Verbindungsverwaltung
- Reagieren Sie zeitnah auf PING-Ereignisse.
- Implementieren Sie eine Logik für Wiederverbindungen.
- Überwachen Sie den Verbindungsstatus.
Fehlerbehebung
Verbindungsprobleme
- Stellen Sie eine korrekte WebSocket-Verbindung sicher.
- Prüfen Sie PING/PONG-Antworten.
- Überprüfen Sie die API-Anmeldedaten.
Audioprobleme
- Prüfen Sie die Verarbeitung von Audio-Chunks.
- Überprüfen Sie die Kompatibilität des Audioformats.
- Überwachen Sie die Speichernutzung.
Ereignisbehandlung
- Protokollieren Sie alle Ereignisse zur Fehlerbehebung.
- Implementieren Sie Fehlergrenzen.
- Prüfen Sie die Registrierung der Ereignishandler.
Detaillierte Implementierungsbeispiele finden Sie in unserer SDK- Dokumentation.