Zdarzenia klienta
Poznaj i obsługuj zdarzenia w czasie rzeczywistym odbierane przez klienta w aplikacjach konwersacyjnych.
Zdarzenia klienta to zdarzenia na poziomie systemu wysyłane z serwera do klienta, które ułatwiają komunikację w czasie rzeczywistym. Dostarczają do aplikacji klienckiej audio, transkrypcje, odpowiedzi agenta i inne kluczowe informacje.
Informacje o zdarzeniach, które możesz wysyłać z klienta do serwera, znajdziesz w dokumentacji zdarzeń klient-serwer.
Omówienie
Zdarzenia klienta są niezbędne do zachowania rozmów w czasie rzeczywistym. Zapewniają wszystko — od metadanych inicjalizacji po przetworzone audio i odpowiedzi agenta.
Te zdarzenia są częścią protokołu komunikacji WebSocket i są automatycznie obsługiwane przez nasze SDK. Ich zrozumienie jest kluczowe przy zaawansowanych wdrożeniach i debugowaniu.
Typy zdarzeń klienta
conversation_initiation_metadata
- Wysyłane automatycznie przy rozpoczęciu rozmowy
- Inicjuje ustawienia i parametry rozmowy
queue_status
- Wysyłane tylko do osób oczekujących w kolejce połączeń, gdy agent osiągnął limit współbieżności
waitingjest wysyłane raz, poconversation_initiation_metadatai przed dźwiękiem oczekiwaniaadmittedlubtimed_outjest wysyłane raz po zakończeniu oczekiwania. Potimed_outWebSocket zostaje zamknięty z kodem 4300- Zawsze wysyłane do osób w kolejce. Nie trzeba włączać go w konfiguracji
client_eventsagenta
Gdy osoba dzwoniąca czeka w kolejce, dźwięk oczekiwania przychodzi jako zwykłe zdarzenia audio. Użyj tego zdarzenia, aby wyświetlić
stan oczekiwania, zamiast traktować dźwięk oczekiwania jak mowę agenta.
ping
- Zdarzenie kontroli stanu, które wymaga natychmiastowej odpowiedzi
- Obsługiwane automatycznie przez SDK
- Służy do utrzymania połączenia WebSocket
audio
- Zawiera dźwięk zakodowany w base64 do odtwarzania
- Zawiera numeryczny identyfikator zdarzenia do śledzenia i ustalania kolejności
- Obsługuje streaming głosu
- Zawiera dane wyrównania z informacjami o czasie na poziomie znaków
W połączeniach WebRTC zdarzenie audio nie jest wysyłane, ponieważ dźwięk obsługuje bezpośrednio LiveKit.
user_transcript
- Zawiera gotowe wyniki zamiany mowy na tekst
- Reprezentuje pełne wypowiedzi użytkownika
- Służy do historii rozmowy
agent_response
- Zawiera pełną wiadomość agenta
- Jest wysyłane po zakończeniu wiadomości, więc w rozmowach głosowych zwykle dociera po rozpoczęciu streamingu dźwięku wiadomości.
- Służy do wyświetlania i historii
Aby wyświetlać tekst agenta w trakcie jego generowania, użyj opisanego niżej zdarzenia agent_chat_response_part,
zamiast czekać na to zdarzenie.
agent_response_correction
- Zawiera skróconą odpowiedź po przerwaniu
- Aktualizuje wyświetlaną wiadomość
- Zachowuje poprawność rozmowy
agent_response_metadata
- Zawiera dowolne metadane z odpowiedzi niestandardowego LLM
- Wysyłane tylko przy użyciu niestandardowego LLM
- Musi być wyraźnie włączone w konfiguracji
client_eventsagenta
To zdarzenie dotyczy integracji z niestandardowym LLM. Pozwala serwerowi niestandardowego LLM przekazać dodatkowe metadane wraz z odpowiedzią, które aplikacja kliencka może wykorzystać.
client_tool_call
- Reprezentuje wywołanie funkcji, którą agent chce wykonać po stronie klienta
- Zawiera nazwę narzędzia, identyfikator wywołania narzędzia i parametry
- Wymaga wykonania funkcji po stronie klienta i odesłania wyniku na serwer
Jeśli używasz SDK, dostępne są callbacki do obsługi odsyłania wyniku na serwer.
agent_tool_response
- Wskazuje, że agent wykonał funkcję narzędzia
- Zawiera metadane narzędzia i status wykonania
- Umożliwia wgląd w użycie narzędzi przez agenta podczas rozmów
agent_tool_response_full_payload
- Odzwierciedla
agent_tool_responsei dodatkowo przesyła pełny wynik narzędzia jako ciąg znaków wfull_tool_result. - Udostępnia wynik narzędzia klientowi do wyświetlenia lub dalszego przetwarzania.
- Musi być wyraźnie włączone w konfiguracji
client_eventsagenta.
To zdarzenie udostępnia klientowi pełny wynik narzędzia i może zawierać poufne dane. Włącz je tylko wtedy, gdy klient jest zaufany i może obsłużyć ten ładunek. Wyniki większe niż 64 KB są automatycznie skracane.
React
JavaScript
vad_score
- Zdarzenie wyniku Voice Activity Detection
- Wskazuje prawdopodobieństwo, że użytkownik mówi
- Wartości mieszczą się w zakresie od 0 do 1, gdzie wyższe wartości oznaczają większą pewność wykrycia mowy
mcp_tool_call
- Wskazuje, że agent wykonał funkcję narzędzia MCP
- Zawiera nazwę narzędzia, identyfikator wywołania narzędzia i parametry
- Jest wywoływane z jednym z czterech stanów:
loading,awaiting_approval,successifailure.
agent_chat_response_part
- Streamuje tekst odpowiedzi agenta podczas generowania jako wiadomości
start,deltaistop - Zawsze wysyłane w trybie tylko tekstowym; w rozmowach głosowych musi być wyraźnie włączone w konfiguracji
client_eventsagenta - Nie jest wysyłane, gdy agent lub aktywna procedura używa blokującego guardraila, który musi ocenić całą odpowiedź, zanim zostanie ona udostępniona
response_ididentyfikuje streamowaną wiadomość i jest zgodne zresponse_idelementuagent_response, który później ją zatwierdza
agent_reasoning_response_part
agent_reasoning_response_part streamuje dostarczane przez model rozumowanie podczas rozmów tylko tekstowych.
Włącz to zdarzenie w client_events oraz podsumowanie
rozumowania dla agenta. Serwer wysyła
wiadomości start, delta i stop. Nie wysyła tego zdarzenia podczas rozmów głosowych ani
gdy agent lub aktywna procedura używa blokujących guardraili.
To zdarzenie i odpowiadający mu callback SDK są eksperymentalne. Ich działanie i struktura mogą zmienić się w dowolnej wersji.
Zdarzenia rozpoczęcia i zakończenia używają pustej wartości text.
agent_response_complete
- Uruchamia się, gdy agent zakończy odpowiedź, w tym wszystkie oczekujące wywołania narzędzi. Po tym zdarzeniu agent wygeneruje kolejny wynik tylko wtedy, gdy użytkownik poda nowe dane wejściowe lub limit czasu tury uruchomi nową turę.
- Musi być wyraźnie włączone w konfiguracji
client_eventsagenta
guardrail_triggered
- Uruchamia się, gdy naruszenie guardraila kończy rozmowę. Nie jest wysyłane, gdy guardrail uruchamia ponowną próbę, która kończy się powodzeniem.
- Samo zdarzenie jest sygnałem — nie zawiera żadnego ładunku poza polem
type. - Musi być wyraźnie włączone w konfiguracji
client_eventsagenta.
Przepływ zdarzeń
Oto typowa sekwencja zdarzeń podczas rozmowy:
Gdy agent osiągnie limit równoczesnych rozmów, a kolejkowanie połączeń jest włączone, serwer wysyła zdarzenia queue_status między conversation_initiation_metadata a pierwszym zdarzeniem audio. Dźwięk oczekiwania jest przesyłany jako zdarzenia audio, dopóki rozmówca nie zostanie dopuszczony.
Dobre praktyki
-
Obsługa błędów
- Zaimplementuj właściwą obsługę błędów dla każdego typu zdarzenia
- Zapisuj ważne zdarzenia w logach na potrzeby debugowania
- Sprawnie obsługuj przerwy w połączeniu
-
Zarządzanie dźwiękiem
- Odpowiednio buforuj fragmenty audio
- Zadbaj o właściwe czyszczenie po przerwaniu
- Zarządzaj zasobami audio
-
Zarządzanie połączeniem
- Szybko odpowiadaj na zdarzenia PING
- Zaimplementuj logikę ponownego łączenia
- Monitoruj stan połączenia
Rozwiązywanie problemów
Problemy z połączeniem
- Upewnij się, że połączenie WebSocket jest poprawne
- Sprawdź odpowiedzi PING/PONG
- Zweryfikuj dane uwierzytelniające API
Problemy z dźwiękiem
- Sprawdź obsługę fragmentów audio
- Zweryfikuj zgodność formatu audio
- Monitoruj użycie pamięci
Obsługa zdarzeń
- Zapisuj wszystkie zdarzenia w logach na potrzeby debugowania
- Zaimplementuj granice błędów
- Sprawdź rejestrację procedur obsługi zdarzeń
Szczegółowe przykłady implementacji znajdziesz w naszej dokumentacji SDK.