Integration externer Agenten mit der Sprachorchestrierung von ElevenLabs Agents

Fortschrittliche Agenten-Orchestratoren sind zunehmend in der Lage, komplexe Aufgaben zu bewältigen und über die gesamte Unternehmenssoftware hinweg zu agieren. Dies erfordert eine sorgfältige Verwaltung von Anwendungs-, Gesprächs- und Systemzuständen. Für andere Modalitäten als Sprache haben sich unter dem Begriff Kontext-Engineering gängige Muster herausgebildet, die darauf abzielen, konsistente Praktiken rund um den System-Prompt eines Agenten während einer Interaktion zu entwickeln. Die Einbindung von Sprache führt nicht nur zu einer zusätzlichen Schicht von Zuständen zur Verwaltung der Sprachinteraktion, sondern ermöglicht idealerweise auch die Wiederverwendung von Artefakten aus früheren Arbeiten an anderen Modalitäten. which aims to build consistent practices around an agent’s system prompt as an interaction progresses. Onboarding voice not only introduces an additional layer of state to manage components of the voice interaction, but ideally also permits the reuse of artifacts from previous work on other modalities. 

In diesem Beitrag skizzieren wir, wie ElevenLabs Agents externe Agenten unterstützen und die Muster, die eine feingranulare Kontrolle über deren Integration ermöglichen. Diese Mechanismen erlauben es Kunden, die erstklassige Sprachorchestrierung von ElevenLabs zu nutzen und gleichzeitig die volle Kontrolle über ihre umfassendere Orchestrierung zu behalten.

Kernkomponenten

ElevenLabs Agents

In seiner einfachsten Form ist ein ElevenLabs Agent über einen Websocket-Client zugänglich. Informationen, die Server- und Client-Ereignisse im Gespräch darstellen, werden als JSON-Objekte an den Agenten gesendet und von ihm empfangen. Wenn der Agent die Benutzersprache transkribiert, löst er gierig eine Generierungsanfrage aus. Wir unterstützen die meisten großen Modellanbieter und ermöglichen es Kunden, ihre eigenen Custom LLM mitzubringen. Wenn ein komplexerer Orchestrator (Agenten) zur Beantwortung von Generierungsanfragen hinter dem Custom LLM eingebracht wird, müssen Kunden sicherstellen, dass er entweder OpenAIs Chat Completions oder Responses API unterstützt. Glücklicherweise wird diese API-Formatierungsspezifikation von den meisten großen Agenten-Bau-Frameworks (CrewAI, LangChain, LangGraph, HayStack, LlamaIndex, ...) problemlos unterstützt.

Sobald integriert, benötigen diese Agenten oft die Fähigkeit, ihren internen und externen Zustand jederzeit zu lesen und zu aktualisieren, unabhängig von dem Sprachorchestrator, hinter dem sie stehen. Eine effektive Verwaltung gewährleistet Konsistenz mit bestehenden textbasierten Agenten.

Zustandsverwaltung

Per Definition sind die Daten, die ein Agent verfolgen muss, um sich effizient in seiner Umgebung zu bewegen, hochgradig aufgabenspezifisch. Für ElevenLabs Agents, die von einem externen Agenten betrieben werden, ist es nützlich, den Zustand über einige gut definierte Kategorien hinweg zu pflegen.

Der interne Zustand steuert die Dynamik des Gesprächs. Beispiele für Elemente, die als Teil des internen Zustands des Agenten verfolgt werden, sind:

• Aktueller Gesprächsfluss, einschließlich Sprachaktivität, Unterbrechungen und Identifizierung des aktiven Sprechers.
• Anwendungsspezifische Erkenntnisse aus der Echtzeit-Transkriptanalyse, wie erkannte Absichten, Entitäten oder Stimmungen.
• Denkprozesse, einschließlich Zwischengedanken, Hypothesen und früherer Versuche, eine Lösung zu generieren.
• Konfigurations- und Betriebsparameter, wie aktive Ziele, Betriebsmodus und temporäre Einschränkungen, die das Verhalten während der Interaktion leiten.

Der externe Zustand hingegen konzentriert sich hauptsächlich auf relevante Systeme und Personen, mit denen der Agent interagiert oder die er beeinflusst. Beispiele für Elemente, die als Teil des externen Zustands des Agenten verfolgt werden, sind:

• Status anderer Benutzer oder Systeme, mit denen er interagiert, wie deren aktuelle Ziele, Verfügbarkeit oder Berechtigungen.
• Werkzeuge und Wissensdatenbanken, zum Beispiel APIs, Datenbanken oder Integrationen, die die Handlungsfähigkeit des Agenten beeinflussen können.
• Laufende Aufgaben und Abhängigkeiten, die externe Akteure oder Systeme betreffen und die nächsten Schritte des Agenten beeinflussen.

Wir skizzieren ein gängiges Muster zur zuverlässigen Pflege dieser Informationen während des gesamten Lebenszyklus der Beziehung eines Agenten zu einem Benutzer.

Lösungskomponenten

Überblick

In diesem Abschnitt behandeln wir die Architekturkomponenten und Implementierungsdetails, die erforderlich sind, um komplexe externe Agenten erfolgreich zu integrieren. Im Kern dieses Ansatzes steht die Fähigkeit, einen beliebigen, aber eindeutigen Bezeichner zu proxyen, der eine Sitzung über alle Dienste hinweg repräsentiert. Für ElevenLabs Agents, die benutzerdefinierte LLMs verwenden, kann dies einfach durch Übermittlung des erforderlichen Bezeichners als LLM-Parameter innerhalb des zusätzlichen Body-Objekts erfolgen, das als Teil der Gesprächsüberschreibungen während der Anrufinitiierung übergeben wird. Dadurch kann der Bezeichner vom Benutzer über den ElevenLabs Agent bis zum externen Agenten fließen.

Beachten Sie den zustandsbehafteten Proxy hinter dem benutzerdefinierten LLM. Dieser Dienst, der normalerweise nicht vorhanden ist, ermöglicht es uns, einzelne Generierungsanfragen mit beliebigen Bezeichnern zu verknüpfen, die Verbindungen mit dem externen Agenten darstellen. Die Implementierung dieses Dienstes liegt in den Händen der Entwickler des externen Agenten. In seiner einfachsten Form verwaltet der Proxy Verbindungen, die durch eindeutige Bezeichner repräsentiert werden und auf ElevenLabs-Gespräche oder Anruf-SIDs (für Telefonie) abbilden. Fortgeschrittenere Versionen können Hierarchien in der Zuordnung von Gesprächen zu komplexeren Kundenbeziehungen einführen, die mehrere Interaktionen umfassen.

In diesen fortgeschritteneren Konfigurationen verwaltet der Proxy zusätzliche Bezeichner, die über eine einzelne Anfrage hinausgehen, die an eine einzelne nachgelagerte Sitzung gebunden ist. Anstatt dass jeder Bezeichner nur ein Gespräch oder eine Anruf-SID repräsentiert, kann der Proxy einen einzelnen Bezeichner mit mehreren verwandten Interaktionen verknüpfen. Dies ermöglicht es dem System, Kundenreisen zu verfolgen, die über verschiedene Kanäle verlaufen, historischen Kontext wiederzuverwenden und mehrere Interaktionen gleichzeitig zu koordinieren. Beispielsweise kann eine einzelne Zuordnung mehrere Web-Chat-Sitzungen, einen nachfolgenden Sprachanruf und einen internen Support-Workflow unter demselben logischen Kundenbezeichner gruppieren. Der Proxy kann dann Anfragen basierend auf einfachen Regeln an den richtigen Bezeichner weiterleiten und dabei einen einheitlichen Zustand hinter dem benutzerdefinierten LLM bewahren. Dies ermöglicht flexiblere und persistentere mehrstufige Interaktionen, die vom externen Agenten verwaltet werden.

Nachrichtenübermittlung

Über die erfolgreiche Zuordnung von Generierungsanfragen zu höherwertigen Entitäten hinaus kann der zustandsbehaftete Proxy die bidirektionale Nachrichtenübermittlung an externe Quellen wie das Anwendungs-Frontend oder einen separaten Router-Dienst über API-Anfragen unterstützen. In Anwendungen, in denen dies erforderlich ist, müssen ElevenLabs Agents nicht wissen, dass Nachrichten an andere Dienste übermittelt werden.

Es ist beispielsweise oft nützlich, dass externe Agenten Einblick in laufende Sprachaktivitäten haben, um festzustellen, ob der Benutzer spricht, wie lange und ob er präventiv Maßnahmen ergreifen sollte. Diese Erkenntnisse können direkt abgeleitet und umgesetzt werden, indem verarbeitete Sprachaktivitätserkennungswerte (VAD) von ElevenLabs Agents als Client-Ereignisse über den Gesprächs-Websocket empfangen werden. Beim Empfang von Werten von ElevenLabs kann die Client-Anwendung VAD-Client-Ereignisse basierend auf den Anwendungsanforderungen an den zustandsbehafteten Proxy weiterleiten und sicherstellen, dass der willkürliche Sitzungsbezeichner in der Nachricht enthalten ist. Es ist notwendig, dass der zustandsbehaftete Proxy eine Anforderungszuordnungslogik implementiert, die die bestehende Verbindung für die Sitzung optimal identifiziert.

Dieses Muster kann erweitert werden, um jedes Ereignis vom Client zu berücksichtigen, vorausgesetzt, es kann als JSON-Block ausgedrückt werden. Es ist jedoch auch nützlich, Ereignisse offenzulegen, die vom Agenten selbst stammen. Ein häufiges Beispiel betrifft den Lebenszyklus von Werkzeugaufrufen oder Wissensdatenbankabfragen, die Operationen auf externen Systemen darstellen. Diese Mechanismen sind grundlegend für die Agenten, die Unternehmen heute entwickeln.

Bei der Integration externer Agenten über ein benutzerdefiniertes LLM werden die Tool-Calling- und Retrieval-Augmented-Generation (RAG)-Funktionen von ElevenLabs oft zugunsten der eigenen Implementierung des externen Agenten umgangen. Infolgedessen liegt die Verantwortung für diese Komponenten vollständig beim externen Agentenanbieter. Anwendungen profitieren dennoch von der Sichtbarkeit der Werkzeugaktivität, da sie es ihnen ermöglicht, den Fortschritt des Agenten anzuzeigen und die Endbenutzererfahrung entsprechend zu aktualisieren.

Um diese Sichtbarkeit zu gewährleisten, sendet der externe Agent Nachrichten, wann immer Werkzeuge aufgerufen werden, sowohl für Anfragen als auch für Antworten. Diese Nachrichten werden vom zustandsbehafteten Proxy an Client-Anwendungen weitergeleitet, die sie über eine dedizierte Nachrichtenwarteschlange verarbeiten. Dies spiegelt die Mechanismen wider, die von den Client-Ereignissen von ElevenLabs Agents verwendet werden, und stellt sicher, dass Anwendungen verfolgen können, wann der Agent auf ein externes System zugreift oder es ändert.

Durch die Verwendung dieser Kernkomponenten und die Ermöglichung der bidirektionalen Nachrichtenübermittlung zwischen dem Proxy und der Client-Anwendung können Kunden externe Agenten innerhalb von ElevenLabs Agents integrieren, um ausschließlich die von ihnen bereitgestellte Sprachorchestrierung zu nutzen und gleichzeitig die Kontrolle über alle Teile der LLM-Orchestrierung zu behalten.

Verknüpfung mit dem Zustand

Die effektive Unterstützung komplexer externer Agenten erfordert eine klare Aufgabenteilung zwischen dem Proxy und dem Agenten, insbesondere wenn es um die Zustandsverwaltung geht. In diesem Modell ist der Proxy dafür verantwortlich, eine Tabelle relevanter Interaktionen zu pflegen, die nach den Bedürfnissen der Anwendung gruppiert sind, und Nachrichten zwischen sich und dem Agenten mit einer Logik zu routen, die zustandslos bleibt. Der externe Agent sollte hingegen alle wesentlichen internen und externen Informationen handhaben und speichern, die zum Gesamtzustand beitragen.

Obwohl die Lockerung dieser Trennung die Nacharbeit einer bestehenden Lösung weiter reduzieren kann, führt die Aufrechterhaltung einer strikten Grenze im Allgemeinen zu robusteren und skalierbareren Ergebnissen, wenn der Aufgabenbereich des Agenten wächst.

Ausblick

Während Organisationen in ihrer Nutzung von sprach- und nicht sprachfähigen Agenten reifen, erwarten wir, dass sich Muster für die von diesen Agenten benötigten Informationen herauskristallisieren, was es uns ermöglicht, die Entwicklung und den Besitz der in diesem Beitrag beschriebenen Dienste zu vereinfachen. In der Zwischenzeit bauen wir weiterhin für die Anforderungen, die bereits aufgetaucht sind. Unser Forward Deployed Engineering Team arbeitet eng mit Kunden zusammen, um diese aufkommenden Bedürfnisse in konkrete Produktfähigkeiten zu übersetzen und sicherzustellen, dass sich unsere Lösungen im Gleichschritt mit realen Implementierungen weiterentwickeln.

Wenn Sie bereits mit einem bestehenden Agenten arbeiten und Sprache mit ElevenLabs Agents aktivieren möchten, während Sie die Kontrolle über Ihre LLM-Orchestrierung behalten, probieren Sie diesen Ansatz aus und lassen Sie uns wissen, was Sie denken!