Jak działa silnik orkiestracji ElevenAgent

ElevenAgents działają dzięki silnikowi orkiestracji o niskich opóźnieniach, stworzonym do rozmów w czasie rzeczywistym i dodającym mniej niż 100 ms narzutu. Architektura łączy najlepsze wyniki badań ElevenLabs z czołowymi LLM-ami od dostawców takich jak OpenAI, Google i Anthropic oraz wybranymi modelami open source hostowanymi przez ElevenLabs. Dzięki użyciu wielu modeli na różnych etapach tworzenia odpowiedzi agent zapewnia rozmowy, które są zarówno bardzo responsywne, jak i świadome kontekstu. Dynamicznie wykorzystując mocne strony każdego modelu, osiągamy niezawodne i skalowalne działanie w wielu zadaniach biznesowych i scenariuszach rozmów, optymalizując równowagę między inteligencją, szybkością i kosztem.

W tym artykule wyjaśniamy, jak te modele współpracują, by zapewnić kluczowe możliwości potrzebne agentom do działania w złożonych środowiskach — a dokładniej: który model widzi jakie tokeny i kiedy. Kluczowe jest tu zarządzanie historią rozmowy na różnych etapach interakcji. Pokażemy, jak i gdzie historia rozmowy jest udostępniana, aby wyjaśnić jej rolę w orkiestracji zarówno niezależnych agentów, jak i workflow z wieloma agentami.

Niezależny agent 

Zaczniemy od niezależnego agenta i jego głównych elementów. Można uznać, że minimalnie użyteczny agent ma system prompt, dostęp do kilku narzędzi i bazy wiedzy. Klienci powinni wybierać niezależnych agentów zamiast workflow, gdy ich zastosowanie rzadko wymaga weryfikacji ścisłej kolejności kroków albo gdy ważne jest uniknięcie silosów wiedzy między agentami. Silosy wiedzy powstają, gdy określone narzędzia, dokumenty lub kontekst historyczny są dostępne dla części podagentów, lecz nie dla innych. Są one nieodłącznym elementem workflow z wieloma agentami i oznaczają kompromis między elastycznością a determinizmem. 

W przypadku niezależnych agentów w ElevenLabs ważne jest zrozumienie, jak:

• Tworzą skuteczne żądania generowania
• Wyszukują i uwzględniają odpowiednie dokumenty
• Generują i wykonują wywołania narzędzi, by wzbogacić odpowiedzi agenta
• Zwracają wyniki do oceny i zbierania danych

Tworzenie kontekstu rozmowy 

Rozmowa między klientem a agentem ElevenLabs to seria tur, z których każda obejmuje wymianę wiadomości między obiema stronami. Ta naprzemienna lista wiadomości agenta i użytkownika stanowi punkt wyjścia do budowania kontekstu rozmowy. W każdej turze bazowy LLM otrzymuje żądania generowania zawierające serię naprzemiennych wiadomości agenta i użytkownika, o jedną wiadomość dłuższą niż w poprzedniej turze. Oczywiście tę serię wiadomości poprzedza pojedyncza wiadomość systemowa zawierająca system prompt agenta.

Orkiestrator ElevenLabs zmniejsza odczuwalne opóźnienie LLM, przewidując, kiedy użytkownik skończył mówić. W niektórych przypadkach może to skutkować wieloma żądaniami generowania LLM z tym samym kontekstem rozmowy w jednej turze.  Chociaż orkiestracja optymalizuje szybkość odpowiedzi agentów, jakość odpowiedzi równie mocno zależy od sposobu dostępu do wiedzy. W miarę rozwoju klienci zwykle zaczynają opierać odpowiedzi agentów na połączeniu własnej dokumentacji i treści publicznych. Od kilku lat standardem jest do tego generowanie wspomagane wyszukiwaniem (RAG). Bazy wiedzy ElevenAgents rozwijają RAG dzięki zoptymalizowanej architekturze wielomodelowej, którą opisaliśmy w poprzednim artykule. Umożliwia to niezawodne wyszukiwanie dokumentów nawet wtedy, gdy ostatnia wiadomość użytkownika jest pytaniem doprecyzowującym, potwierdzeniem wyjaśnienia albo nie zawiera wyraźnego pytania.

Wyszukiwanie to jednak tylko jeden ze sposobów, w jakie agenci komunikują się z systemami zewnętrznymi.

Podejmowanie działań i pobieranie informacji za pomocą narzędzi

Agenci ElevenLabs mogą wykonywać rzeczywiste działania i pobierać aktualne informacje w trakcie rozmowy dzięki elastycznemu systemowi narzędzi. Wiąże się to z ważną kwestią projektową: każde włączone narzędzie zwiększa rozmiar serializowanego promptu, ponieważ jego nazwa, opis i schemat parametrów są dołączane do system promptu i historii rozmowy. Dodanie większej liczby narzędzi zwiększa też obciążenie modelu, który musi rozumować, by wywołać właściwą sekwencję narzędzi. W Agent Builder opis narzędzia określa, co ono robi i jakie pola zwraca. To informacje, których model językowy używa, by zrozumieć kontekst jego użycia. Po zdefiniowaniu narzędzia konkretne warunki jego wywołania należy umieścić w system prompcie agenta. Na przykład:

• Opis narzędzia lookup_order: „Pobiera dane zamówienia klienta na podstawie identyfikatora zamówienia. Zwraca status zamówienia, kupione produkty, adres dostawy i numer śledzenia.”
• Instrukcja w system prompcie: „Po zweryfikowaniu tożsamości klienta wywołaj narzędzie lookup_order, aby pobrać dane jego zamówienia.”

Ten podział odpowiedzialności sprawia, że definicje narzędzi można ponownie wykorzystywać między agentami, a system prompt każdego agenta może określać dokładny moment wywołania narzędzia. Aby pomóc klientom skutecznie tworzyć te system prompty, udostępniamy więcej wskazówek w naszym Przewodniku po promptach. W tym modelu można definiować głównie następujące typy narzędzi:

• Narzędzia webhook wywołujące zewnętrzne API.
• Narzędzia klienta, które wysyłają żądania narzędzi jako zdarzenia przez websocket rozmowy.
• Narzędzia systemowe do wbudowanych działań, takich jak przekazywanie połączeń.
• Narzędzia MCP, które łączą się z serwerami Model Context Protocol.

Gdy agent zdecyduje się użyć narzędzia, pobiera z rozmowy potrzebne dane i wysyła żądanie jego uruchomienia. Gdy narzędzie zwróci wynik, jest on dodawany do rozmowy, aby model mógł naturalnie odwołać się do niego w kolejnej odpowiedzi. W razie potrzeby wynik narzędzia może też zaktualizować informacje przechowywane przez agenta jako zmienna dynamiczna. Informacje te są przechowywane jako proste pary klucz-wartość, wyodrębnione z odpowiedzi narzędzia za pomocą zdefiniowanych mapowań. Po ustawieniu zmienne mogą wracać do agenta przez jego system prompt, parametry przyszłych narzędzi i warunki workflow. Ta pętla sprzężenia zwrotnego daje agentom formę pamięci roboczej, która rozwija się wraz z interakcjami.

Choć opisuje to integrację narzędzi z rozumowaniem agenta, można też skonfigurować moment ich wykonania. Narzędzia działają w jednym z trzech trybów, dostosowanych do różnych potrzeb rozmowy. W trybie natychmiastowym narzędzie uruchamia się, gdy tylko LLM o nie poprosi. To ustawienie domyślne dla szybkich wyszukiwań, gdy użytkownicy oczekują niemal natychmiastowej odpowiedzi, np. przy sprawdzaniu statusu zamówienia. W połączeniu z komunikatem przed użyciem narzędzia agent najpierw generuje krótkie potwierdzenie, np. „Już to sprawdzam”, i przekazuje je użytkownikowi, podczas gdy narzędzie działa równolegle, ograniczając ciszę. Dla wolniejszych narzędzi platforma automatycznie wydłuża te komunikaty wypełniające do przewidywanego czasu oczekiwania. Tryb mowy po użyciu narzędzia natomiast opóźnia wykonanie, aż agent skończy mówić. Jest to niezbędne przy działaniach mających skutki w świecie rzeczywistym, takich jak przekazanie połączenia, zakończenie sesji czy wysłanie płatności. Użytkownik słyszy pełny komunikat, np. „Teraz przekieruję cię do działu rozliczeń”, i może przerwać przed wykonaniem działania. Tryb asynchroniczny uruchamia narzędzie całkowicie w tle, bez wstrzymywania rozmowy. Najlepiej sprawdza się w operacjach typu fire-and-forget, takich jak wysłanie e-maila, uruchomienie zewnętrznego workflow czy rejestrowanie danych, gdy agent nie musi odwoływać się do wyniku w odpowiedzi.

Gdy wykonanie i orkiestracja są już skonfigurowane, kolejnym krokiem jest zrozumienie, jak mierzyć skuteczność.

Pomiar skuteczności

Po zakończeniu rozmowy z Agentem klienci mogą chcieć wyodrębnić jej wybrane elementy do dalszej analizy i przechowywania albo ustalić, czy rozmowa zakończyła się sukcesem. Tu przydają się Zbieranie danych i Kryteria oceny. Zbieranie danych pozwala wyodrębniać uporządkowane informacje z transkrypcji rozmowy do dalszej analizy i agregacji. Klienci często eksportują te dane do firmowego lakehouse'u danych na potrzeby raportowania lub workflow wzbogacania danych. Na przykład Agent ds. Rozwoju Sprzedaży może automatycznie wyodrębnić z rozmowy dane potencjalnego klienta, aby utworzyć lub zaktualizować lead w systemie zarządzania relacjami z klientami (CRM). Kryteria oceny z kolei określają, czy rozmowę uznaje się za udaną. Jeśli wszystkie skonfigurowane kryteria są spełnione, rozmowa zostaje oznaczona jako udana; w przeciwnym razie jako nieudana. Dzięki temu rozmowy stale spełniają określone standardy jakości i rzetelności, a ty szybko otrzymujesz informację zwrotną. Po zakończeniu rozmowy i uruchomieniu webhooka po rozmowie agent przetwarza finalną transkrypcję, w tym wykonania narzędzi i metadane, przez LLM wraz ze wszystkimi skonfigurowanymi punktami zbierania danych i kryteriami oceny. Model używa tego połączonego promptu, by ustalić, czy każde kryterium oceny zostało spełnione, oraz wyodrębnić wskazane punkty danych do dalszej analizy. Ponieważ LLM interpretuje te konfiguracje bezpośrednio jako część promptu wejściowego, należy formatować je jasno i konsekwentnie, aby model mógł je poprawnie zrozumieć i zastosować. Dlatego zalecamy poniższe praktyki przy pisaniu opisów Kryteriów oceny i Zbierania danych.

Kryteria oceny

1. Jeden jasny cel na kryterium: jedno zdanie lub krótki punkt jest lepszy niż kilka celów w jednym kryterium. 
2. Obserwowalne i oparte na transkrypcji: sformułuj cel tak, aby na podstawie transkrypcji można było określić sukces lub porażkę (co zostało powiedziane, co zrobił agent, o co poprosił użytkownik). Unikaj celów wymagających zewnętrznego kontekstu, którego LLM nie ma.
3. Jednoznaczne wyniki: sukces/porażka/nieznany: LLM zna już zasadę, że aby oznaczyć wynik jako sukces, cel musi zostać spełniony; aby oznaczyć go jako porażkę, nie może być spełniony; a aby oznaczyć go jako nieznany, nie może dać się tego ustalić na podstawie transkrypcji. Cel powinien więc jasno definiować różnicę między „spełniony” a „niespełniony”; jeśli jest niejednoznaczny, model może wybierać wynik nieznany lub błędną klasyfikację
4. Zachowaj zwięzłość: czasem wiele kryteriów oceny jest wysyłanych razem. Długie kryteria mogą więc wprowadzać szum i powodować halucynacje
5. Język ma znaczenie: każde uzasadnienie podane przez LLM, czy kryterium oceny zostało spełnione, będzie w tym samym języku co opis kryterium — warto o tym pamiętać

Zbieranie danych

1. Opisz dokładnie, co wyodrębnić: opis jest głównym sygnałem dla LLM. Określ, co oznacza pole, w jakiej sytuacji należy je ustawić i co zrobić, gdy nie ma pewności (np. „Pozostaw null, jeśli klient nigdy nie podał preferowanej daty”).
2. Dopasuj do oczekiwanego typu: wartość podana przez LLM zawsze będzie zgodna z typem danych przypisanym do punktu zbierania danych (np. boolean, string, integer). Opis powinien być z nim zgodny. Przykładowo dla integer możesz użyć „Wyodrębnij liczbę zamówionych produktów”, a dla boolean: „Tak/nie: czy klient zgodził się na ofertę”.
3. Używaj enumów, gdy to możliwe: dla typu string, jeśli zbiór wartości jest stały, użyj enum w schemacie; ogranicza to model i zmniejsza liczbę nieprawidłowych wyników.
4. Jeden cel wyodrębniania na element: nie łącz w opisie jednego elementu kilku niezwiązanych faktów; podziel je na osobne elementy, aby każde wywołanie miało jeden jasny cel wyodrębniania.
5. Opisy powinny być krótkie: opisy mogą mieć kilka zdań — nie potrzeba długich akapitów. Transkrypcja jest już w wiadomości użytkownika, więc wystarczą schemat i krótki opis.

Obecnie LLM używany na etapie oceny i wyodrębniania jest na stałe ustawiony na model o niskich opóźnieniach, aby zapewnić szybkie przetwarzanie. Wkrótce planujemy wprowadzić opcje dające klientom większą elastyczność. 

Przejdźmy teraz do zastosowań wymagających uporządkowanej orkiestracji, determinizmu lub specjalizacji między wieloma rolami w rozmowie, gdzie klienci mogą użyć Workflows.

Workflows

Workflows udostępniają wizualny interfejs do projektowania złożonych przebiegów rozmów. Tworzą obiekt logiczny używany przez orkiestrator do zarządzania wieloma podagentami, narzędziami i przekazaniami w ramach identyfikatora niezależnego agenta. Workflows wprowadzają dodatkowe elementy, które trzeba uwzględnić poza opisanymi już dla niezależnych agentów, w tym sposób, w jaki:

• Współdziałają system prompty i cele rozmów podagentów.
• Określane jest przejście przez różne punkty przejścia na grafie.

Wyspecjalizowane cele rozmów

Workflows wykorzystują funkcje niezależnych agentów, by zachować spójne zachowanie przez całą interakcję. Obejmuje to wspólne elementy, takie jak bazowy system prompt, główne narzędzia i globalne bazy wiedzy, które powinny być zawsze dostępne niezależnie od aktywnej części workflow. Nadrzędny system prompt zazwyczaj określa globalny kontekst rozmowy, oczekiwany ton, ograniczenia bezpieczeństwa oraz instrukcje dotyczące marki lub produktu.

Na tej wspólnej bazie Workflows wprowadzają wyspecjalizowanych podagentów działających w grafie skierowanym. Każdy podagent ma wąsko określony cel i rozszerza konfigurację bazową o dodatkowe instrukcje promptu, narzędzia i źródła wiedzy istotne wyłącznie dla jego roli. Zamiast redefiniować całą konfigurację rozmowy, podagenci nakładają swoją intencję na agenta bazowego przez składanie promptów i selektywne rozszerzanie kontekstu. Historia rozmowy jest zachowywana między przejściami podagentów dla ciągłości, ale każdy podagent działa z celowo ograniczonym widokiem systemu. Bazy wiedzy i narzędzia są udostępniane selektywnie, tworząc wyraźne silosy, które zapobiegają przenikaniu między odpowiedzialnościami. Aby wzmocnić tę izolację, obiekt orkiestratora jest przy każdym przejściu budowany na nowo, jak dla niezależnego agenta. Dzięki temu stan promptu, konfiguracja i dostępne możliwości aktywnego podagenta pozostają w pełni deterministyczne. Taka architektura pozwala Workflows zachować globalną spójność przy jednoczesnym wspieraniu lokalnej specjalizacji, zapewniając przewidywalne zachowanie, wyraźny podział odpowiedzialności i precyzyjną kontrolę nad stosowaniem kontekstu, wiedzy i działań na każdym etapie interakcji.

Jednym z kluczowych mechanizmów umożliwiających tę kontrolę jest sposób zarządzania przejściami między podagentami.

Sterowanie przejściami workflow za pomocą warunków LLM

Workflows przechodzą przez graf skierowany podagentów, a przejścia między węzłami są kontrolowane przez jawne warunki. Warunki te określają, kiedy kontrola ma przejść z jednego podagenta do drugiego, i pozwalają workflow reagować na dane wejściowe użytkownika, wyniki narzędzi oraz zmienne dynamiczne. Warunki grafu mogą być deterministyczne lub oceniane przez LLM. Warunki deterministyczne, takie jak przejścia bezwarunkowe, kontrole oparte na wyrażeniach zmiennych dynamicznych czy warunki wyników narzędzi, dają silne gwarancje dotyczące przepływu sterowania i dobrze sprawdzają się przy wymuszaniu ścisłego postępu workflow. Warunki oparte na LLM umożliwiają natomiast semantyczną ocenę kryteriów w języku naturalnym, np. wykrywanie intencji użytkownika lub rozpoznawanie, że podano określone informacje.

Co ważne, warunki LLM są oceniane poza system promptem aktywnego agenta i nie wpływają na jego zachowanie podczas generowania. Zamiast tego orkiestrator ocenia je równolegle względem bieżącego stanu rozmowy. Ten podział sprawia, że logika przejść nie zanieczyszcza promptu agenta ani nie wpływa na generowanie odpowiedzi, a jednocześnie pozwala workflow korzystać z rozumowania LLM do elastycznego przechodzenia po grafie. Łącząc warunki deterministyczne i oceniane przez LLM, workflow mogą zapewnić zarówno przewidywalność, jak i zdolność adaptacji: używają przejść deterministycznych tam, gdzie kluczowa jest poprawność, a opartych na LLM tam, gdzie potrzebna jest interpretacja semantyczna.

Gdy rozmowa przechodzi do nowego etapu, system aktywuje wersję agenta dopasowaną specjalnie do tego kroku. Każdy etap działa z własnymi, ukierunkowanymi instrukcjami i ma dostęp tylko do wiedzy oraz narzędzi związanych z jego zadaniem. Na przykład etap obsługi zwrotów może odwoływać się do zasad zwrotów bez przejmowania niepowiązanego kontekstu z onboardingu czy selekcji zgłoszeń. Przejściami między etapami zarządzają jawne warunki przejścia. Określają one, kiedy odpowiedzialność powinna się zmienić, i pozwalają, by decyzje o przekierowaniu zapadały naturalnie w toku rozmowy. Aby zachować ciągłość, doświadczenie użytkownika pozostaje płynne między przejściami: każdy etap dziedziczy istotny kontekst rozmowy bez ujawniania mechaniki przekazania. Zabezpieczenia monitorują też przejścia, aby zapobiec nieproduktywnym cyklom przekierowań i utrzymać stabilność workflow oraz skupienie na celu.

Bezpieczeństwo i ochrona

W przypadkach wymagających silniejszych mechanizmów bezpieczeństwa i ochrony klienci mogą korzystać z dodatkowych elementów orkiestratora. 

Guardraile

Agenci ElevenLabs wdrażają guardraile bezpieczeństwa przez konfigurowalny system moderacji i alignmentu, który w czasie rzeczywistym ocenia wiadomości użytkownika i agenta. Treści przychodzące są klasyfikowane w wielu kategoriach ryzyka, w tym treści seksualnych, przemocy, nękania, mowy nienawiści i samookaleczeń; dla każdej można niezależnie skonfigurować progi. Gdy guardrail zostanie uruchomiony, rozmowa jest natychmiast kończona, a klient otrzymuje jasny powód niepowodzenia. Dzięki temu niebezpieczne interakcje są blokowane wcześnie i konsekwentnie, bez polegania wyłącznie na mechanizmach ograniczających w prompcie. Guardraile działają poza logiką promptu agenta i stanowią niezawodną warstwę egzekwowania, której nie da się obejść zachowaniem modelu ani danymi wejściowymi użytkownika. Takie podejście pozwala klientom dostosować czułość zabezpieczeń do swojej dziedziny, przy zachowaniu deterministycznego egzekwowania w czasie działania.

Zgodne z wymogami zarządzanie danymi

Rozmówcy mogą czasem udostępniać agentowi wrażliwe informacje objęte ścisłymi wymogami przechowywania i przetwarzania, np. dane medyczne wymagające obsługi zgodnej z HIPAA. Aby wspierać takie zastosowania, oferujemy Zero Retention Mode (ZRM) na poziomie Agenta lub Workspace. Po włączeniu wszystkie dane rozmowy są przetwarzane wyłącznie w pamięci i nigdy nie są zapisywane w trwałej pamięci masowej. Po zakończeniu rozmowy i przetwarzania ElevenLabs nie przechowuje żadnych informacji. W rezultacie transkrypcje, nagrania audio i wyniki analiz nie są dostępne w panelu Agents Dashboard; zasada ta dotyczy zarówno systemów dostępnych dla klientów, jak i wewnętrznych logów. Choć dane nie są przechowywane, są przetwarzane podczas rozmowy, a wszystkie skonfigurowane webhooki po rozmowie otrzymają wyniki. Dzięki temu klienci mogą w razie potrzeby przechowywać transkrypcje lub wyniki analiz we własnych systemach. 

Gdy ZRM jest aktywny, zapewniamy też, że podmioty przetwarzające dane nie zachowują ich, ograniczając dostępne LLM-y do dostawców, którzy w umowach zobowiązują się nie trenować na danych klientów ani ich nie przechowywać. Obecnie obejmuje to modele Google Gemini i Anthropic Claude. Klienci, którzy chcą użyć innego LLM w ZRM, mogą podpisać własną umowę z tym dostawcą i skonfigurować go jako niestandardowy LLM za pomocą kluczy API objętych tą umową. Ponieważ wykracza to poza naszą standardową granicę zaufania w obsłudze danych, przed włączeniem tej opcji nasz zespół Safety musi ręcznie sprawdzić i zatwierdzić dane zastosowanie. ZRM zapewnia, że ElevenLabs i podmioty przetwarzające dane nie przechowują danych rozmów, ale klienci nadal odpowiadają za zgodność z obowiązującymi wymogami retencji i przepisami wszystkich zewnętrznych narzędzi lub webhooków używanych przez ich Agenta.

Co dalej

W tym artykule pokazaliśmy, jak Agenci ElevenLabs zarządzają kontekstem rozmowy, narzędziami, oceną i uporządkowanymi workflow, aby zapewniać niezawodne doświadczenia w czasie rzeczywistym na dużą skalę. W miarę jak klienci wdrażają agentów w coraz bardziej złożonych środowiskach, stale zwiększamy elastyczność naszego silnika orkiestracji — od konfigurowalnych modeli oceny i rozbudowanych mechanizmów przejść po lepszy wgląd w składanie promptów i wykorzystanie tokenów na poszczególnych etapach.

Nasz zespół Forward Deployed Engineering ściśle współpracuje z klientami, aby te możliwości rozwijały się w zgodzie z wdrożeniami w rzeczywistych warunkach. Kolejna generacja Agentów zapewni jeszcze większą przejrzystość, determinizm i zdolność adaptacji, bez utraty niskich opóźnień, które umożliwiają rozmowy w czasie rzeczywistym.