Integracja zewnętrznych agentów z orkiestracją głosową ElevenLabs Agents

Zaawansowane orkiestratory agentów coraz lepiej radzą sobie ze złożonymi zadaniami i działają w całym ekosystemie narzędzi firmowych. Wymaga to starannego zarządzania stanem aplikacji, rozmowy i systemu. Dla innych modalności niż głos pojawiły się wspólne wzorce, określane mianem inżynierii kontekstu, która ma na celu wypracowanie spójnych praktyk wokół system promptu agenta w miarę rozwoju interakcji. Dodanie głosu nie tylko wprowadza dodatkową warstwę stanu do zarządzania elementami interakcji głosowej, lecz najlepiej także pozwala wykorzystać materiały z wcześniejszej pracy nad innymi modalnościami. 

W tym artykule opisujemy, jak ElevenLabs Agents obsługują zewnętrznych agentów oraz wzorce, które pozwalają precyzyjnie kontrolować ich integrację. Dzięki tym mechanizmom klienci mogą korzystać z najlepszej w swojej klasie orkiestracji głosu ElevenLabs, zachowując pełną kontrolę nad szerszą orkiestracją.

Kluczowe komponenty

ElevenLabs Agents

W najprostszej formie agent ElevenLabs jest dostępny przez klienta WebSocket. Informacje o zdarzeniach serwera i klienta w rozmowie są przesyłane do agenta i od niego jako obiekty JSON. Gdy agent transkrybuje mowę użytkownika, od razu wywołuje żądanie generowania. Obsługujemy większość głównych dostawców modeli i pozwalamy klientom używać własnego Custom LLM. Gdy do obsługi żądań generowania za Custom LLM podłączasz bardziej złożony orkiestrator (agentów), musisz upewnić się, że obsługuje on API Chat Completions lub Responses API od OpenAI. Na szczęście tę specyfikację formatu API łatwo obsługuje większość głównych frameworków do budowy agentów (CrewAI, LangChain, LangGraph, HayStack, LlamaIndex, ...). 

Po integracji agenci często muszą mieć możliwość odczytu i aktualizacji stanu wewnętrznego oraz zewnętrznego w dowolnym momencie, niezależnie od orkiestratora głosu, za którym działają. Skuteczne zarządzanie tym zapewnia spójność z istniejącymi agentami tekstowymi. 

Zarządzanie stanem

Dane, które agent musi śledzić, by sprawnie poruszać się po swoim środowisku, z definicji zależą w dużej mierze od zadania. W przypadku ElevenLabs Agents obsługiwanych przez zewnętrznego agenta warto utrzymywać stan w kilku jasno określonych kategoriach.

Stan wewnętrzny określa dynamikę rozmowy. Elementy śledzone w ramach stanu wewnętrznego agenta obejmują:

• Aktualny przebieg rozmowy, w tym aktywność głosową, przerwania i identyfikację aktywnego rozmówcy.
• Informacje specyficzne dla aplikacji, wynikające z analizy transkrypcji w czasie rzeczywistym, takie jak wykryte intencje, encje lub sentyment.
• Ślad rozumowania, w tym pośrednie przemyślenia, hipotezy i wcześniejsze próby wygenerowania rozwiązania.
• Parametry konfiguracji i działania, takie jak aktywne cele, tryb działania oraz tymczasowe ograniczenia kierujące zachowaniem agenta podczas interakcji.

Stan zewnętrzny skupia się natomiast głównie na istotnych systemach i osobach, z którymi agent wchodzi w interakcje lub na które wpływa. Elementy śledzone w ramach stanu zewnętrznego agenta obejmują:

• Status innych użytkowników lub systemów, z którymi wchodzi w interakcje, np. ich obecne cele, dostępność lub uprawnienia.
• Narzędzia i bazy wiedzy, na przykład API, bazy danych lub integracje, które mogą wpływać na zdolność agenta do działania.
• Trwające zadania i zależności z udziałem zewnętrznych podmiotów lub systemów, które wpływają na kolejne kroki agenta.

Opisujemy typowy wzorzec niezawodnego utrzymywania tych informacji przez cały cykl relacji agenta z użytkownikiem.

Komponenty rozwiązania

Przegląd 

W tej sekcji omawiamy komponenty architektury i szczegóły wdrożenia potrzebne do udanej integracji złożonych zewnętrznych agentów. Podstawą tego podejścia jest możliwość przekazywania przez wszystkie usługi dowolnego, ale unikalnego identyfikatora sesji. W przypadku ElevenLabs Agents korzystających z własnych LLM-ów można to zrobić, przekazując wymagany identyfikator jako parametr LLM w obiekcie extra body przekazywanym w ramach nadpisań rozmowy podczas rozpoczęcia połączenia. Dzięki temu identyfikator przepływa przez agenta ElevenLabs od użytkownika aż do zewnętrznego agenta. 

Zwróć uwagę na proxy ze stanem za własnym LLM-em. Ta usługa, która zwykle nie występuje, pozwala mapować pojedyncze żądania generowania na dowolne identyfikatory reprezentujące połączenia z zewnętrznym agentem. Za wdrożenie tej usługi odpowiadają deweloperzy zewnętrznego agenta. W najprostszej formie proxy zarządza połączeniami reprezentowanymi przez unikalne identyfikatory mapowane na rozmowy ElevenLabs lub identyfikatory SID połączeń (w telefonii). Bardziej zaawansowane wersje mogą wprowadzać hierarchię mapowania rozmów na bardziej złożone relacje z klientami, obejmujące wiele interakcji.

W bardziej zaawansowanych konfiguracjach proxy utrzymuje dodatkowe identyfikatory, które wykraczają poza pojedyncze żądanie powiązane z jedną sesją downstream. Zamiast aby każdy identyfikator reprezentował tylko jedną rozmowę lub SID połączenia, proxy może powiązać jeden identyfikator z wieloma związanymi interakcjami. Pozwala to systemowi śledzić ścieżki klienta między kanałami, wykorzystywać kontekst historyczny i koordynować kilka interakcji naraz. Na przykład jedno mapowanie może grupować wiele sesji czatu w sieci, kolejne połączenie głosowe i wewnętrzny workflow wsparcia pod tym samym logicznym identyfikatorem klienta. Proxy może następnie kierować żądania do właściwego identyfikatora według prostych reguł, zachowując jednolity stan za własnym LLM-em. Umożliwia to bardziej elastyczne i trwałe, wieloetapowe interakcje zarządzane przez zewnętrznego agenta.

Przekazywanie wiadomości

Oprócz skutecznego mapowania żądań generowania na encje wyższego rzędu proxy ze stanem może obsługiwać dwukierunkowe przekazywanie wiadomości do zewnętrznych źródeł, takich jak frontend aplikacji lub oddzielna usługa routingu, za pomocą żądań API. W aplikacjach, które tego potrzebują, ElevenLabs Agents nie muszą wiedzieć, że wiadomości są przekazywane do innych usług.  

Na przykład zewnętrzni agenci często potrzebują wglądu w trwającą aktywność głosową, aby określić, czy użytkownik mówi, jak długo i czy powinni podjąć działania z wyprzedzeniem. Te informacje można uzyskać i wykorzystać bezpośrednio, przekazując przetworzone wyniki wykrywania aktywności głosowej (VAD) dostarczane przez ElevenLabs Agents jako zdarzenia klienta odbierane przez WebSocket rozmowy. Po otrzymaniu wyników od ElevenLabs aplikacja kliencka może przekazać zdarzenia klienta VAD do proxy ze stanem zgodnie z wymaganiami aplikacji, dbając o dołączenie do wiadomości dowolnego identyfikatora sesji. Proxy ze stanem musi wdrożyć logikę mapowania żądań, która optymalnie identyfikuje istniejące połączenie dla sesji. 

Ten wzorzec można rozszerzyć na dowolne zdarzenie od klienta, pod warunkiem że da się je wyrazić jako blok JSON. Warto jednak udostępniać także zdarzenia pochodzące od samego agenta. Typowym przykładem jest cykl życia wywołań narzędzi lub zapytań do bazy wiedzy, które reprezentują operacje na systemach zewnętrznych. Mechanizmy te są podstawą agentów, których firmy tworzą obecnie.

Podczas integracji zewnętrznych agentów przez własny LLM funkcje ElevenLabs, takie jak wywoływanie narzędzi i generowanie wspomagane wyszukiwaniem (RAG), są często pomijane na rzecz własnej implementacji zewnętrznego agenta. W rezultacie odpowiedzialność za te komponenty spoczywa w całości na dostawcy zewnętrznego agenta. Aplikacje nadal korzystają na wglądzie w aktywność narzędzi, ponieważ mogą pokazywać postępy agenta i odpowiednio aktualizować doświadczenie użytkownika końcowego.

Aby zapewnić ten wgląd, zewnętrzny agent wysyła wiadomości przy każdym wywołaniu narzędzia — zarówno dla żądań, jak i odpowiedzi. Proxy ze stanem przekazuje te wiadomości do aplikacji klienckich, które obsługują je przez dedykowaną kolejkę wiadomości. Odzwierciedla to mechanizmy stosowane przez zdarzenia klienta ElevenLabs Agents i pozwala aplikacjom śledzić, kiedy agent odczytuje dane z systemu zewnętrznego lub je modyfikuje.

Korzystanie z tych kluczowych komponentów i dwukierunkowe przekazywanie wiadomości między proxy a aplikacją kliencką pozwala klientom integrować zewnętrznych agentów w ElevenLabs Agents, by korzystać wyłącznie z oferowanej orkiestracji głosu, zachowując kontrolę nad wszystkimi elementami orkiestracji LLM. 

Powiązanie ze stanem

Skuteczna obsługa złożonych zewnętrznych agentów wymaga jasnego podziału odpowiedzialności między proxy a agenta, szczególnie w kwestii zarządzania stanem. W tym modelu proxy odpowiada za utrzymywanie tabeli istotnych interakcji, pogrupowanych zgodnie z potrzebami aplikacji, oraz za kierowanie wiadomości między sobą a agentem za pomocą logiki pozostającej bezstanową. Z kolei zewnętrzny agent powinien obsługiwać i przechowywać wszystkie istotne informacje wewnętrzne i zewnętrzne, które składają się na ogólny stan.

Choć złagodzenie tego podziału może jeszcze bardziej ograniczyć konieczność przerabiania istniejącego rozwiązania, utrzymanie ścisłej granicy zwykle daje bardziej niezawodne i skalowalne rezultaty w miarę rozbudowy zestawu zadań agenta.

Co dalej

W miarę jak organizacje dojrzewają w wykorzystywaniu agentów głosowych i niegłosowych, spodziewamy się, że wzorce dotyczące informacji potrzebnych tym agentom się ukształtują. Pozwoli nam to uprościć rozwój i odpowiedzialność za usługi opisane w tym artykule. W międzyczasie nadal tworzymy rozwiązania dla potrzeb, które już się pojawiły. Nasz zespół Forward Deployed Engineering ściśle współpracuje z klientami, by przekuwać te nowe potrzeby w konkretne możliwości produktu i zapewniać, że nasze rozwiązania rozwijają się w zgodzie z wdrożeniami w rzeczywistych warunkach.

Jeśli już pracujesz z agentem i chcesz dodać głos dzięki ElevenLabs Agents , zachowując kontrolę nad orkiestracją LLM, wypróbuj to podejście i daj nam znać, co o nim myślisz!