Wir stellen Eleven v4 vorLernen Sie Eleven v4 kennen, unser bisher ausdrucksstärkstes Modell. Mit 3× Credits im Creator+-Tarif bis zum 12. Oktober

Zum Inhalt springen

Integration externer Agenten mit der Sprachorchestrierung von ElevenLabs Agents

Verfasst von
Nicolas Bernier
Veröffentlicht
Zuletzt aktualisiert

AnhörenArtikel anhören

Orchestratoren für hochmoderne Agenten können zunehmend komplexe Aufgaben bewältigen und mit einer Vielzahl von Unternehmenstools arbeiten. Dafür müssen Anwendungs-, Gesprächs- und Systemzustände sorgfältig verwaltet werden. Für andere Modalitäten als Sprache haben sich unter dem Oberbegriff Context Engineering, gemeinsame Muster entwickelt. Ziel ist es, konsistente Praktiken rund um den System Prompt eines Agenten aufzubauen, während eine Interaktion fortschreitet. Die Integration von Sprache fügt nicht nur eine weitere Zustands­ebene für die Komponenten der Sprachinteraktion hinzu, sondern ermöglicht idealerweise auch die Wiederverwendung von Artefakten aus früheren Arbeiten mit anderen Modalitäten. 

In diesem Beitrag erläutern wir, wie ElevenLabs Agents externe Agenten unterstützen und welche Muster eine detaillierte Kontrolle ihrer Integration ermöglichen. Mit diesen Mechanismen können Kunden die erstklassige Sprachorchestrierung von ElevenLabs nutzen und gleichzeitig die volle Kontrolle über ihre umfassendere Orchestrierung behalten.

Kernkomponenten

ElevenLabs Agents

In seiner einfachsten Form ist ein ElevenLabs Agent über einen WebSocket-Client zugänglich. Informationen zu Server- und Client-Ereignissen im Gespräch werden als JSON-Objekte an den Agenten und von ihm übertragen. Wenn der Agent die Sprache eines Nutzers transkribiert, löst er sofort eine Generierungsanfrage aus. Wir unterstützen die meisten großen Modellanbieter und ermöglichen Kunden, ihr eigenes Custom LLM einzubringen. Wenn Kunden einen komplexeren Orchestrator aus Agenten hinter dem Custom LLM einsetzen, um Generierungsanfragen zu beantworten, müssen sie sicherstellen, dass er entweder OpenAIs Chat Completions API oder Responses API unterstützt. Glücklicherweise wird dieses API-Format von den meisten wichtigen Frameworks zur Agentenentwicklung problemlos unterstützt, darunter CrewAI, LangChain, LangGraph, HayStack und LlamaIndex. 

Nach der Integration müssen diese Agenten ihren internen und externen Zustand oft jederzeit lesen und aktualisieren können – unabhängig vom vorgeschalteten Sprachorchestrator. Eine wirksame Verwaltung gewährleistet Konsistenz mit bestehenden rein textbasierten Agenten. 

Zustandsverwaltung

Die Daten, die ein Agent für die effiziente Navigation in seiner Umgebung verfolgen muss, sind naturgemäß stark aufgabenspezifisch. Für ElevenLabs Agents, die von einem externen Agenten betrieben werden, ist es sinnvoll, den Zustand in einigen klar definierten Kategorien zu verwalten.

Der interne Zustand steuert die Dynamik des Gesprächs. Zu den Elementen, die als Teil des internen Zustands eines Agenten verfolgt werden, gehören:

  • Aktueller Gesprächsverlauf, einschließlich Sprachaktivität, Unterbrechungen und Identifikation des aktiven Sprechers.
  • Anwendungsspezifische Erkenntnisse aus der Echtzeitanalyse von Transkripten, etwa erkannte Intentionen, Entitäten oder Stimmungen.
  • Reasoning-Verlauf, einschließlich Zwischengedanken, Hypothesen und früherer Lösungsversuche.
  • Konfigurations- und Betriebsparameter wie aktive Ziele, Betriebsmodus und temporäre Einschränkungen, die das Verhalten während der Interaktion steuern.

Der externe Zustand konzentriert sich dagegen vor allem auf relevante Systeme und Personen, mit denen der Agent interagiert oder die er beeinflusst. Zu den Elementen, die als Teil des externen Zustands eines Agenten verfolgt werden, gehören:

  • Status anderer Nutzer oder Systeme, mit denen er interagiert, etwa ihre aktuellen Ziele, Verfügbarkeit oder Berechtigungen.
  • Tools und Wissensdatenbanken, zum Beispiel APIs, Datenbanken oder Integrationen, die die Handlungsfähigkeit des Agenten beeinflussen können.
  • Laufende Aufgaben und Abhängigkeiten mit externen Akteuren oder Systemen, die die nächsten Schritte des Agenten beeinflussen.

Wir beschreiben ein gängiges Muster, um diese Informationen während des gesamten Lebenszyklus der Beziehung eines Agenten zu einem Nutzer zuverlässig zu verwalten.

Lösungskomponenten

Überblick 

In diesem Abschnitt behandeln wir die Architekturkomponenten und Implementierungsdetails, die für die erfolgreiche Integration komplexer externer Agenten erforderlich sind. Im Kern dieses Ansatzes steht die Fähigkeit, eine beliebige, aber eindeutige Kennung für eine Sitzung über alle Dienste hinweg weiterzuleiten. Bei ElevenLabs Agents mit Custom LLMs kann dies einfach erfolgen, indem die erforderliche Kennung als LLM-Parameter im Extra-Body-Objekt übergeben wird, das Teil der Conversation Overrides beim Start des Anrufs ist. So kann die Kennung vom Nutzer durch den ElevenLabs Agent bis zum externen Agenten fließen. 

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

Beachten Sie den zustandsbehafteten Proxy hinter dem Custom LLM. Dieser normalerweise nicht vorhandene Dienst ermöglicht es, einzelne Generierungsanfragen beliebigen Kennungen zuzuordnen, die Verbindungen mit dem externen Agenten darstellen. Die Implementierung dieses Dienstes liegt in der Verantwortung der Entwickler des externen Agenten. In seiner einfachsten Form verwaltet der Proxy Verbindungen, die durch eindeutige Kennungen für ElevenLabs-Gespräche oder Call-SIDs im Telefonsystem dargestellt werden. Erweiterte Versionen können dagegen eine Hierarchie bei der Zuordnung von Gesprächen zu komplexeren Kundenbeziehungen einführen, die mehrere Interaktionen umfassen.

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.

In diesen erweiterten Konfigurationen verwaltet der Proxy zusätzliche Kennungen, die über eine einzelne Anfrage hinausgehen, die an eine einzelne nachgelagerte Sitzung gebunden ist. Statt dass jede Kennung nur ein Gespräch oder eine Call-SID repräsentiert, kann der Proxy eine Kennung mehreren zusammenhängenden Interaktionen zuordnen. So kann das System kanalübergreifende Customer Journeys verfolgen, historische Kontexte wiederverwenden und mehrere Interaktionen gleichzeitig koordinieren. Beispielsweise kann eine einzelne Zuordnung mehrere Webchat-Sitzungen, einen anschließenden Sprachanruf und einen internen Support-Workflow unter derselben logischen Kundenkennung zusammenfassen. Der Proxy kann Anfragen dann anhand einfacher Regeln an die richtige Kennung weiterleiten und dabei einen einheitlichen Zustand hinter dem Custom LLM bewahren. Das ermöglicht flexiblere und dauerhafte mehrstufige Interaktionen, die vom externen Agenten verwaltet werden.

Nachrichtenübermittlung

Über die erfolgreiche Zuordnung von Generierungsanfragen zu übergeordneten Entitäten hinaus kann der zustandsbehaftete Proxy über API-Anfragen die bidirektionale Nachrichtenübermittlung mit externen Quellen wie dem Anwendungs-Frontend oder einem separaten Router-Service unterstützen. In Anwendungen, in denen dies erforderlich ist, müssen ElevenLabs Agents nicht wissen, dass Nachrichten an andere Dienste weitergegeben werden.  

Externe Agenten benötigen beispielsweise häufig Einblick in die laufende Sprachaktivität. So können sie feststellen, ob und wie lange ein Nutzer spricht und ob sie vorab Maßnahmen ergreifen sollten. Diese Erkenntnisse können direkt gewonnen und umgesetzt werden, indem verarbeitete Werte der Sprachaktivitätserkennung (VAD) von ElevenLabs Agents als Client-Ereignisse über den Gesprächs-WebSocket übermittelt werden. Wenn die Client-Anwendung Werte von ElevenLabs erhält, kann sie VAD-Client-Ereignisse entsprechend den Anforderungen der Anwendung an den zustandsbehafteten Proxy weiterleiten. Dabei muss sie sicherstellen, dass die beliebige Sitzungskennung in der Nachricht enthalten ist. Der zustandsbehaftete Proxy muss eine Logik für die Anfragezuordnung implementieren, die die bestehende Verbindung für die Sitzung optimal identifiziert. 

Dieses Muster lässt sich auf jedes Ereignis vom Client erweitern, sofern es als JSON-Block ausgedrückt werden kann. Es ist jedoch auch sinnvoll, Ereignisse offenzulegen, die vom Agenten selbst ausgehen. Ein häufiges Beispiel ist der Lebenszyklus von Tool-Aufrufen oder Wissensdatenbankabfragen, die Vorgänge in externen Systemen darstellen. Diese Mechanismen sind grundlegend für die Agenten, die Unternehmen heute entwickeln.

Bei der Integration externer Agenten über ein Custom LLM werden die Funktionen von ElevenLabs für Tool Calling und Retrieval Augmented Generation (RAG) oft zugunsten der eigenen Implementierung des externen Agenten umgangen. Dadurch liegt die Verantwortung für diese Komponenten vollständig beim Anbieter des externen Agenten. Anwendungen profitieren dennoch von Einblick in die Tool-Aktivität, da sie so den Fortschritt des Agenten anzeigen und die Endnutzererfahrung entsprechend aktualisieren können.

Um diesen Einblick zu ermöglichen, sendet der externe Agent bei jedem Tool-Aufruf Nachrichten – sowohl für Anfragen als auch für Antworten. Der zustandsbehaftete Proxy leitet diese Nachrichten an Client-Anwendungen weiter, die sie über eine dedizierte Nachrichtenwarteschlange verarbeiten. Dies entspricht den Mechanismen der Client-Ereignisse von ElevenLabs Agents und stellt sicher, dass Anwendungen nachvollziehen können, wann der Agent ein externes System liest oder verändert.

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

Durch die Nutzung dieser Kernkomponenten und die bidirektionale Nachrichtenübermittlung zwischen Proxy und Client-Anwendung können Kunden externe Agenten in ElevenLabs Agents integrieren und dabei ausschließlich dessen Sprachorchestrierung nutzen, während sie die Kontrolle über alle Teile der LLM-Orchestrierung behalten. 

Bezug zum Zustand

Die effektive Unterstützung komplexer externer Agenten erfordert eine klare Aufgabentrennung zwischen Proxy und Agent, insbesondere bei der Zustandsverwaltung. In diesem Modell verwaltet der Proxy eine Tabelle relevanter Interaktionen, die nach den Anforderungen der Anwendung gruppiert sind, und leitet Nachrichten zwischen sich und dem Agenten mit zustandsloser Logik weiter. Der externe Agent sollte wiederum alle wesentlichen internen und externen Informationen verarbeiten und speichern, die zum Gesamtzustand beitragen.

Eine weniger strikte Trennung kann zwar den Überarbeitungsaufwand einer bestehenden Lösung weiter reduzieren, doch eine klare Grenze führt in der Regel zu robusteren und besser skalierbaren Ergebnissen, wenn der Aufgabenbereich des Agenten wächst.

Ausblick

Mit der zunehmenden Nutzung sprach- und nicht sprachfähiger Agenten durch Unternehmen werden sich die Muster für die Informationen, die diese Agenten benötigen, voraussichtlich herauskristallisieren. So können wir die Entwicklung und Verantwortung für die in diesem Beitrag beschriebenen Dienste vereinfachen. In der Zwischenzeit entwickeln wir weiter für die Anforderungen, die bereits entstanden sind. Unser Forward Deployed Engineering Team arbeitet eng mit Kunden zusammen, um diese neuen Anforderungen in konkrete Produktfunktionen zu übersetzen und sicherzustellen, dass sich unsere Lösungen parallel zu realen Implementierungen weiterentwickeln.

Wenn Sie bereits mit einem bestehenden Agenten arbeiten und Sprache mit ElevenLabs Agents ermöglichen möchten, ohne die Kontrolle über Ihre LLM-Orchestrierung abzugeben, probieren Sie diesen Ansatz aus und teilen Sie uns Ihre Meinung mit. 

Verfasst von

bald man with a beard smiling

Nicolas Bernier

Forward Deployed Engineer

Nicolas arbeitet im Forward Deployed Engineering-Team bei ElevenLabs und kooperiert mit Kunden, um ihre Agenten in die Produktion zu bringen. Zuvor war er vier Jahre bei AWS tätig, wo er sich auf regulierte Branchen und den öffentlichen Sektor konzentrierte.

Ähnliche Artikel

Erstellen Sie mit hochwertiger KI-Audio