Überlege sorgfältig, wie und wo Entscheidungen in deinem Agentensystem getroffen werden.
Wenn mehr Entscheidungen einem LLM überlassen werden, kann das System möglicherweise mehr Aufgaben bewältigen. Das kann jedoch zulasten von Geschwindigkeit, Zuverlässigkeit und Robustheit gehen.
Versuche, möglichst viele Entscheidungsprozesse aus dem LLM in expliziten Softwarecode zu verlagern. Das gilt besonders für risikoreiche Abläufe und den Produktivbetrieb.
Beim Entwurf eines LLM-basierten Agentensystems ist eine der wichtigsten Entscheidungen, in welchem Umfang ein LLM-Modell oder explizite Software die Entscheidungslogik übernimmt.
Diese Entscheidung lässt sich als Spektrum zwischen den folgenden Ansätzen verstehen:
Routerbasierte Architekturen legen Reihenfolge und Logik ausdrücklich im Code fest. Das macht eng umrissene Aufgaben testbar, vorhersehbar und robust. Sie werden auch als „Workflow-Agenten“ bezeichnet.
Orchestrator-Agenten nutzen große Sprachmodelle (LLMs), um Abläufe anhand natürlichsprachlicher Prompts dynamisch festzulegen. Sie eignen sich für offene Interaktionen, bei denen vordefinierte Logik nicht ausreicht oder unmöglich ist.
Für risikoreiche Produktivabläufe empfehlen wir in der Regel mehr routerbasierte Funktionen. Orchestratoren sollten Anwendungen vorbehalten bleiben, die flexible, vielseitige Gespräche erfordern.
Routerbasierte Architekturen
Routerbasierte Agentensysteme:
Sie definieren den Entscheidungsablauf ausdrücklich durch Code beziehungsweise Software und nutzen ein LLM, um die passende Route durch diese Software zu bestimmen.
Sie ähneln klassischen Softwaresystemen, da ihre klaren, vorhersehbaren Pfade zu konsistenteren Ergebnissen führen.
Sie eignen sich ideal für klar definierbare Aufgaben.
Das folgende vereinfachte Beispiel zeigt einen Buchungs-Agenten für einen Airline-Chatbot, der den „Routeransatz“ nutzt. Das LLM ordnet die Absicht hinter einer Frage einer von drei Möglichkeiten zu. Letztlich weist jedoch unsere Software dieser Absicht eine vorgefertigte Textantwort zu. Da das LLM stark eingeschränkt ist, erleben Nutzende ein konsistenteres Verhalten.
Orchestrator-Architekturen
Im Gegensatz zum Routersystem zeichnen sich Orchestrator-Agentensysteme durch Folgendes aus:
Sie definieren logische Abläufe durch natürlichsprachliche Prompts statt durch Software. Hinweis: Im Vergleich zu einer Programmiersprache ist natürliche Sprache grundsätzlich mehrdeutig und flexibel. Das hat Vor- und Nachteile, auf die wir später eingehen. Wir verstehen das als „Absicht statt Anweisung“.
Sie können mehrere Verarbeitungsoptionen bereitstellen, wobei das LLM Reihenfolge und Methode der Ausführung bestimmt.
Sie können dynamisch neue Logikpfade erzeugen, die sich nur schwer ausdrücklich in Software definieren lassen.
Diese Mehrdeutigkeit kann zu uneinheitlichen Ergebnissen führen. Wenn es funktioniert, kann es jedoch „magisch“ wirken.
Das folgende Beispiel wendet einen Orchestratoransatz auf dasselbe vereinfachte Airline-Szenario an. Statt die Software über die passende Antwort entscheiden zu lassen, wird die Entscheidung an die LLM-Ebene delegiert. Hier kommt ein Multi-Agenten-System zum Einsatz: Ein zentraler Orchestrator-Agent ordnet die Anfrage ein und übergibt sie an einen Agenten, der speziell für Flugänderungen entwickelt wurde und schließlich die Antwort ausgibt.
In diesem Beispiel übernimmt die LLM-Ebene die Rollen von Klassifikator, Router und Verfasser der Antwort. Im Routerbeispiel diente sie nur als Klassifikator, während die Software den Rest übernahm.
Wo immer möglich, empfehlen wir routerbasierte Ansätze, da sie folgende Vorteile bieten:
Geschwindigkeit und Effizienz: Lokale Berechnungen sind schneller als Orchestratoren, die von externen APIs abhängen. Zudem ist es deutlich günstiger, „IF/ELSE“-Logik in Python auszuführen, als einen LLM-Anbieter dafür zu bezahlen, sie durch ein Modell mit 400 Milliarden Parametern zu schicken.
Testbarkeit und Vorhersehbarkeit: Etablierte Softwarepraktiken erleichtern Fehlersuche, Tests und Wartung erheblich.
Transparenz und Zuverlässigkeit: Weniger Verhaltensabweichungen erleichtern die Fehlersuche. Außerdem wird ein größerer Teil des Anwendungsablaufs durch transparente, versionskontrollierte Software abgebildet und nicht durch die undurchsichtigen, nicht interpretierbaren Gewichte eines LLM.
Routeransätze können jedoch starr und unflexibel sein und bei offeneren Problemstellungen an ihre Grenzen stoßen. Ein Chatbot, der stets exakt dieselben Antworten gibt, kann auf Nutzende langweilig oder unbeweglich wirken.
Orchestrator-Architekturen bieten leistungsstarke Funktionen:
Planung: Sie können Antworten dynamisch planen.
Werkzeugauswahl und Übergabe an Agenten: Sie wählen geeignete Werkzeuge aus oder delegieren Aufgaben an Agenten.
Iterative Kombination von Ergebnissen: Sie überarbeiten und kombinieren Ergebnisse auf neue Weise.
Ermitteln des Abschlusses: Sie stellen fest, wann genügend Informationen für eine abschließende Antwort vorliegen.
Frameworks wie Pydantic-AI oder das Agents SDK von OpenAI ermöglichen eine unkomplizierte und schnelle Implementierung der Orchestrierung. Damit eignet sich der Ansatz gut für Demos oder Machbarkeitsnachweise.
Dieser Ansatz hat jedoch folgende Nachteile:
Es gibt keine Garantie dafür, dass die Planungsschritte des LLM und die daraus folgenden Aktionen korrekt oder angemessen sind. Das Routersystem hat dasselbe Problem. Da es stärker eingeschränkt ist, verhält es sich jedoch vorhersehbarer.
Für einfache, klar definierte Aufgaben benötigen wir wahrscheinlich nicht den gesamten Funktionsumfang eines Multi-Agenten-Systems. In unserem Beispiel mit dem Airline-Agenten gibt es vermutlich nur eine begrenzte Zahl von Anfragetypen, die Personen über ein Supportsystem einer Fluggesellschaft tatsächlich bearbeiten möchten.
Da mehr Logik im LLM enthalten ist, können böswillige Akteure das System wesentlich leichter per Jailbreak umgehen oder ausnutzen.
Der Ansatz verlagert Entscheidungen in das LLM und erschwert dadurch das Verständnis des Systems. Monitoring-Tools wie Langfuse oder Braintrust können dabei teilweise helfen.
Hinweis: Die Fähigkeiten von Modellen entwickeln sich zwar schnell, doch die folgenden Grundsätze werden sich voraussichtlich in naher Zukunft nicht ändern.
Bestimme den Umfang deines Problems.
Kannst du die gewünschte Entscheidungslogik leicht in einem Diagramm darstellen?
Kannst du Fehler oder unerwartetes Verhalten in deiner Anwendung nicht tolerieren?
Wenn du eine dieser Fragen mit „Ja“ beantwortest, sind Routerfunktionen wahrscheinlich besser geeignet.
Wir empfehlen, Routeransätze so lange wie möglich zu nutzen. Grundsätzlich gilt: Wenn sich ein Teil deines Systems in Code ausdrücken lässt, setze ihn in Code um. Nutze LLMs also nicht häufiger als nötig.
Wenn diese Ansätze an ihre Grenzen stoßen, lassen sich einige Vorteile offener Orchestratoren in eingeschränkter Form nachbilden. Zum Beispiel:
Werkzeugauswahl und Übergabe an Agenten: Lässt sich einfach durch bedingte Verzweigungen oder LLM-Klassifikatoren umsetzen.
Ermitteln des Abschlusses: Einfache LLM-Klassifikatoren können prüfen, ob eine Antwort vollständig ist, bevor sie ausgegeben wird.
„Planung“ und die „iterative Kombination von Ergebnissen“ sind in einem starren Routersystem allerdings deutlich schwieriger umzusetzen. Wenn eine Aufgabe diese Funktionen erfordert, ermittelt etwa durch einen LLM-Klassifikator oder eine andere Logik, empfehlen wir deshalb einen weniger eingeschränkten Orchestrator-Zweig im System.
Die Wahl zwischen Router- und Orchestrator-Architektur sollte berücksichtigen, wie klar und komplex deine Anwendung ist und welche Form der Interaktion sie erfordert. Routerbasierte Ansätze bieten derzeit Zuverlässigkeit, Effizienz und einfache Tests für klar definierte Aufgaben. Orchestratoren bieten mehr Flexibilität für vielseitigere, dialogorientierte Interaktionen.
Mit der Weiterentwicklung von LLMs kann sich das Verhältnis zwischen diesen Ansätzen verändern. Für den Produktivbetrieb bevorzugen wir routerbasierte oder hybride Architekturen. Orchestratoren setzen wir bei offenen Problemen ein, die eine dynamische, menschenähnliche Interaktion erfordern.