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 modalności innych niż głos wypracowano wspólne wzorce, określane mianem inżynierii kontekstu, której celem jest tworzenie spójnych praktyk wokół system promptu agenta w miarę rozwoju interakcji. Włączenie głosu nie tylko dodaje kolejną warstwę stanu do zarządzania elementami interakcji głosowej, ale też pozwala wykorzystać efekty wcześniejszej pracy z innymi modalnościami. 

W tym artykule pokazujemy, jak ElevenLabs Agents wspierają zewnętrznych agentów i jakie wzorce zapewniają precyzyjną kontrolę nad 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 elementy

ElevenLabs Agents

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

Po integracji agenci często muszą móc w dowolnym momencie odczytywać i aktualizować swój stan wewnętrzny oraz zewnętrzny, niezależnie od orkiestratora głosu, za którym działają. Skuteczne zarządzanie tym zapewnia spójność z obecnymi agentami tekstowymi. 

Zarządzanie stanem

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

Stan wewnętrzny odpowiada za dynamikę rozmowy. Elementy śledzone w ramach wewnętrznego stanu agenta to między innymi:

• Bieżący przebieg rozmowy, w tym aktywność głosowa, przerwania i identyfikacja aktywnego rozmówcy.
• Informacje specyficzne dla aplikacji, uzyskane 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 pracy i tymczasowe ograniczenia kierujące zachowaniem podczas interakcji.

Stan zewnętrzny koncentruje 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 zewnętrznego stanu agenta to między innymi:

• Status innych użytkowników lub systemów, z którymi współpracuje, np. ich bieżące 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 obejmujące zewnętrzne podmioty lub systemy, które wpływają na kolejne kroki agenta.

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

Elementy rozwiązania

Przegląd 

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

Zwróć uwagę na proxy stanowe za własnym LLM. 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 SID-y połączeń (w telefonii). Bardziej zaawansowane wersje mogą wprowadzać hierarchię w mapowaniu 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ą docelową. Zamiast przypisywać każdy identyfikator tylko do jednej rozmowy lub SID-u połączenia, proxy może powiązać jeden identyfikator z wieloma powiązanymi interakcjami. Pozwala to systemowi śledzić ścieżki klientów między kanałami, wykorzystywać kontekst historyczny i koordynować kilka interakcji naraz. Na przykład jedno mapowanie może grupować wiele sesji czatu internetowego, kolejne połączenie głosowe i wewnętrzny workflow wsparcia pod jednym 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. Umożliwia to bardziej elastyczne i trwałe, wieloetapowe interakcje zarządzane przez zewnętrznego agenta.

Przekazywanie wiadomości

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

Na przykład zewnętrznym agentom często przydaje się wgląd w bieżącą aktywność głosową, aby mogły określić, czy użytkownik mówi, jak długo i czy powinny podjąć działanie z wyprzedzeniem. Te informacje można bezpośrednio uzyskać i wykorzystać, 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 stanowego zgodnie z wymaganiami aplikacji, pamiętając o uwzględnieniu w wiadomości dowolnego identyfikatora sesji. Proxy stanowe 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, o ile da się je wyrazić jako blok JSON. Warto jednak udostępniać też 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. Te mechanizmy są podstawą agentów tworzonych dziś przez firmy.

Przy 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 efekcie odpowiedzialność za te elementy w całości spoczywa na dostawcy zewnętrznego agenta. Aplikacje nadal korzystają jednak na wglądzie w aktywność narzędzi, ponieważ pozwala on 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 stanowe przekazuje je do aplikacji klienckich, które obsługują je przez dedykowaną kolejkę wiadomości. Odzwierciedla to mechanizmy stosowane w zdarzeniach klienta ElevenLabs Agents i pozwala aplikacjom śledzić, kiedy agent odczytuje dane z systemu zewnętrznego lub je modyfikuje.

Korzystanie z tych kluczowych elementów i umożliwienie dwukierunkowego przekazywania wiadomości między proxy a aplikacją kliencką pozwala klientom integrować zewnętrznych agentów z ElevenLabs Agents wyłącznie na potrzeby orkiestracji głosu, przy zachowaniu kontroli nad wszystkimi elementami orkiestracji LLM. 

Powrót do kwestii stanu

Skuteczne wsparcie 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, grupowanych zgodnie z potrzebami aplikacji, oraz za kierowanie wiadomości między sobą a agentem przy użyciu logiki bezstanowej. Z kolei zewnętrzny agent powinien obsługiwać i przechowywać wszystkie istotne informacje wewnętrzne i zewnętrzne, które składają się na całkowity stan.

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

Co dalej

Wraz z dojrzewaniem organizacji w korzystaniu z agentów obsługujących głos i inne modalności, spodziewamy się, że wzorce dotyczące informacji potrzebnych tym agentom staną się bardziej wyraźne. Pozwoli nam to uprościć tworzenie i utrzymanie usług opisanych w tym artykule. Tymczasem nadal rozwijamy rozwiązania pod kątem wymagań, które już się pojawiły. Nasz zespół Forward Deployed Engineering blisko współpracuje z klientami, by przekuwać te nowe potrzeby w konkretne możliwości produktu i zapewniać rozwój naszych rozwiązań w zgodzie z wdrożeniami w rzeczywistych warunkach.

Jeśli już pracujesz z istniejącym 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!