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

Wzorce integracji orkiestracji głosowej ElevenLabs z złożonymi i stanowymi agentami

orange mountain on the right side and blue sky on the left

Nowoczesne orkiestratory agentów coraz lepiej radzą sobie z złożonymi zadaniami i działają w ramach narzędzi korporacyjnych. Wymaga to starannego zarządzania stanem aplikacji, rozmowy i systemu. Dla innych niż głosowe modalności pojawiły się wspólne wzorce pod pojęciem inżynieria kontekstu, które mają na celu budowanie spójnych praktyk wokół systemowego promptu agenta w miarę postępu interakcji. Wprowadzenie głosu dodaje dodatkową warstwę stanu do zarządzania komponentami interakcji głosowej, ale idealnie pozwala również na ponowne wykorzystanie artefaktów z wcześniejszych prac nad innymi modalnościami.

W tym poście przedstawiamy, jak ElevenLabs Agents wspierają zewnętrznych agentów i wzorce umożliwiające precyzyjną kontrolę nad ich integracją. Te mechanizmy pozwalają klientom korzystać z najlepszej w swojej klasie orkiestracji głosowej ElevenLabs, zachowując pełną kontrolę nad szerszą orkiestracją.

Główne komponenty

ElevenLabs Agents

W najprostszej formie, ElevenLabs Agent jest dostępny przez klienta Websocket. Informacje reprezentujące zdarzenia serwera i klienta w rozmowie są przesyłane do i od agenta jako obiekty JSON. Gdy agent transkrybuje mowę użytkownika, natychmiast wyzwala żądanie generacji. Wspieramy większość głównych dostawców modeli i pozwalamy klientom na użycie własnego Custom LLM. Przy wprowadzaniu bardziej złożonego orkiestratora (agentów) do odpowiedzi na żądania generacji za Custom LLM, klienci muszą upewnić się, że wspiera on API Chat Completions lub Responses OpenAI. Na szczęście, specyfikacja formatowania tego API jest łatwo wspierana przez większość głównych frameworków do budowy agentów (CrewAI, LangChain, LangGraph, HayStack, LlamaIndex, ...).

Po integracji, ci agenci często wymagają możliwości odczytu i aktualizacji swojego wewnętrznego i zewnętrznego stanu w dowolnym momencie, niezależnie od orkiestratora głosowego, za którym się znajdują. Skuteczne zarządzanie tym zapewnia spójność z istniejącymi agentami tekstowymi.

Zarządzanie stanem

Z definicji, dane, które agent musi śledzić, aby efektywnie poruszać się w swoim środowisku, są wysoce specyficzne dla zadania. Dla ElevenLabs Agents zasilanych przez zewnętrznego agenta, przydatne jest utrzymanie stanu w kilku dobrze zdefiniowanych kategoriach.

Stan wewnętrzny reguluje dynamikę rozmowy. Przykłady elementów śledzonych jako część stanu wewnętrznego agenta obejmują:

  • Aktualny przepływ rozmowy, w tym aktywność głosową, przerwania i identyfikację aktywnego mówcy.
  • Wnioski specyficzne dla aplikacji uzyskane z analizy transkryptu w czasie rzeczywistym, takie jak wykryte intencje, jednostki czy sentyment.
  • Ślad rozumowania, w tym myśli pośrednie, hipotezy i wcześniejsze próby wygenerowania rozwiązania.
  • Parametry konfiguracyjne i operacyjne, takie jak aktywne cele, tryb działania i wszelkie tymczasowe ograniczenia kierujące jego zachowaniem podczas interakcji.

Stan zewnętrzny koncentruje się natomiast na odpowiednich systemach i osobach, z którymi agent wchodzi w interakcje lub na które wpływa. Przykłady elementów śledzonych jako część stanu zewnętrznego agenta obejmują:

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

Przedstawiamy wspólny wzorzec dla niezawodnego utrzymania tych informacji przez cały cykl życia relacji agenta z użytkownikiem.

Komponenty rozwiązania

Przegląd

W tej sekcji omawiamy komponenty architektury i szczegóły implementacji potrzebne do pomyślnej integracji złożonych zewnętrznych agentów. W centrum tego podejścia znajduje się możliwość proxy dla dowolnego, ale unikalnego identyfikatora reprezentującego sesję we wszystkich usługach. Dla ElevenLabs Agents używających custom LLM, można to zrobić po prostu przekazując wymagany identyfikator jako parametr LLM w dodatkowym obiekcie przekazywanym jako część nadpisywania rozmowy podczas inicjacji połączenia. Dzięki temu identyfikator może przepływać przez ElevenLabs Agent od użytkownika do zewnętrznego agenta.

diagram describing the flow from user to elevenlabs websocket to custom llm to stateful proxy to external agent

Zauważ stanowy proxy za custom LLM. Ta usługa, która zazwyczaj nie jest obecna, pozwala nam mapować indywidualne żądania generacji na dowolne identyfikatory reprezentujące połączenia z zewnętrznym agentem. Właścicielem implementacji tej usługi są deweloperzy zewnętrznego agenta. W najprostszej formie, proxy zarządza połączeniami reprezentowanymi przez unikalne identyfikatory mapujące na rozmowy ElevenLabs lub SID-y połączeń (dla telefonii). Natomiast bardziej zaawansowane wersje mogą wprowadzać hierarchię w mapowaniu rozmów na bardziej złożone relacje z klientami obejmujące wiele interakcji.

Comparison of mapping ids for one to one versus one to many cases. In the case of one to many, there is a hierarchy grouping multiple conversations ids together.

W tych bardziej zaawansowanych konfiguracjach, proxy utrzymuje dodatkowe identyfikatory, które wykraczają poza pojedyncze żądanie związane z jedną sesją downstream. Zamiast każdego identyfikatora reprezentującego tylko jedną rozmowę lub SID połączenia, proxy może powiązać pojedynczy identyfikator z wieloma powiązanymi interakcjami. Pozwala to systemowi śledzić podróże klientów, które przemieszczają się między kanałami, ponownie wykorzystywać kontekst historyczny i koordynować kilka interakcji jednocześnie. Na przykład, jedno mapowanie może grupować wiele sesji czatu internetowego, późniejsze połączenie głosowe i wewnętrzny przepływ pracy wsparcia pod tym samym logicznym identyfikatorem klienta. Proxy może wtedy kierować żądania do właściwego identyfikatora na podstawie prostych zasad, zachowując jednolity stan za custom LLM. To umożliwia bardziej elastyczne i trwałe interakcje wieloetapowe zarządzane przez zewnętrznego agenta.

Przekazywanie wiadomości

Poza pomyślnym mapowaniem żądań generacji na wyższe jednostki, stanowy proxy może wspierać dwukierunkowe przekazywanie wiadomości do zewnętrznych źródeł, takich jak frontend aplikacji lub osobna usługa routera przez żądania API. W aplikacjach, gdzie jest to konieczne, ElevenLabs Agents nie muszą być świadome, że wiadomości są przekazywane do innych usług.

Na przykład, często jest przydatne, aby zewnętrzni agenci mieli wgląd w bieżącą aktywność głosową, aby mogli określić, czy użytkownik mówi, jak długo i czy powinni podjąć jakiekolwiek działania z wyprzedzeniem. Te informacje można bezpośrednio uzyskać i podjąć działania, przekazując przetworzone wyniki wykrywania aktywności głosowej (VAD) dostarczane przez ElevenLabs Agents jako zdarzenia klienta odbierane przez websocket rozmowy. Otrzymując wyniki od ElevenLabs, aplikacja kliencka może przekazywać zdarzenia klienta VAD do stanowego proxy na podstawie wymagań aplikacji, zapewniając, że zawiera arbitralny identyfikator sesji w wiadomości. Konieczne jest, aby stanowy proxy zaimplementował logikę mapowania żądań, która optymalnie identyfikuje istniejące połączenie dla sesji.

Ten wzorzec można rozszerzyć, aby uwzględnić dowolne zdarzenie od klienta, pod warunkiem, że można je wyrazić jako blok JSON. Jednakże, przydatne jest również eksponowanie zdarzeń, które pochodzą od samego agenta. Powszechnym przykładem jest cykl życia wywołań narzędzi lub zapytań do bazy wiedzy, które reprezentują operacje na zewnętrznych systemach. Te mechanizmy są fundamentalne dla agentów, które przedsiębiorstwa budują dzisiaj.

Podczas integracji zewnętrznych agentów przez custom LLM, funkcje wywoływania narzędzi i generacji wzbogaconej o odzyskiwanie (RAG) ElevenLabs są często pomijane na rzecz własnej implementacji zewnętrznego agenta. W rezultacie, właścicielem tych komponentów jest całkowicie dostawca zewnętrznego agenta. Aplikacje nadal korzystają z wglądu w aktywność narzędzi, ponieważ umożliwia to im przedstawienie postępów agenta i aktualizację doświadczenia końcowego użytkownika.

Aby zapewnić tę widoczność, zewnętrzny agent emituje wiadomości za każdym razem, gdy narzędzia są wywoływane, zarówno dla żądań, jak i odpowiedzi. Te wiadomości są przekazywane przez stanowy proxy do aplikacji klienckich, które obsługują je przez dedykowaną kolejkę wiadomości. To odzwierciedla mechanizmy używane przez zdarzenia klienta ElevenLabs Agents i zapewnia, że aplikacje mogą śledzić, kiedy agent odczytuje lub modyfikuje zewnętrzny system.

Diagram showing the message passing flow between some frontend application and the stateful proxy bypassing the elevenlabs agent.

Tak więc, używając tych głównych komponentów i umożliwiając dwukierunkowe przekazywanie wiadomości między proxy a aplikacją kliencką, klienci mogą integrować zewnętrznych agentów w ramach ElevenLabs Agents, aby ściśle korzystać z oferowanej orkiestracji głosowej, zachowując jednocześnie kontrolę nad wszystkimi częściami orkiestracji LLM.

Łączenie z powrotem do stanu

Skuteczne wspieranie złożonych zewnętrznych agentów wymaga jasnego podziału obowiązków między proxy a agentem, zwłaszcza jeśli chodzi o zarządzanie stanem. W tym modelu, proxy jest odpowiedzialne za utrzymanie tabeli odpowiednich interakcji, pogrupowanych zgodnie z potrzebami aplikacji, oraz za kierowanie wiadomości między sobą a agentem przy użyciu logiki, która pozostaje bezstanowa. Z kolei zewnętrzny agent powinien obsługiwać i przechowywać wszystkie istotne wewnętrzne i zewnętrzne informacje, które przyczyniają się do ogólnego stanu.

Chociaż złagodzenie tego podziału może dodatkowo zmniejszyć ponowne prace nad istniejącym rozwiązaniem, utrzymanie ścisłej granicy zazwyczaj prowadzi do bardziej solidnych i skalowalnych wyników, gdy zestaw zadań agenta rośnie.

Patrząc w przyszłość

W miarę jak organizacje dojrzewają w przyjmowaniu agentów z obsługą głosu i bez głosu, spodziewamy się, że wzorce dotyczące informacji wymaganych przez tych agentów się skrystalizują, co pozwoli nam uprościć rozwój i posiadanie usług opisanych w tym poście. Tymczasem nadal budujemy dla wymagań, które już się pojawiły. Nasz zespół Forward Deployed Engineering ściśle współpracuje z klientami, aby przetłumaczyć te pojawiające się potrzeby na konkretne możliwości produktowe i zapewnić, że nasze rozwiązania rozwijają się w zgodzie z rzeczywistymi wdrożeniami.

Jeśli już pracujesz z istniejącym agentem i chcesz włączyć głos z ElevenLabs Agents zachowując kontrolę nad swoją orkiestracją LLM, wypróbuj to podejście i daj nam znać, co myślisz!

Przeglądaj artykuły zespołu ElevenLabs

ElevenLabs

Twórz z najwyższą jakością dźwięku AI