Eine Multi-Agenten-Architektur in der Praxis

KI-Chatbots in Webshops, Teil 2

Im ersten Teil dieser Serie haben wir beleuchtet, warum viele Chatbot-Lösungen im E-Commerce an den Bedürfnissen der Nutzer scheitern. Ohne echte Verschmelzung mit der Produkt- und Markenwelt des Anbieters und seiner Produkte sowie tiefer technischer Integration in die Website können sie den vielschichtigen Prozess einer Fachberatung nicht abbilden. Das Ergebnis: frustrierende Dialoge und verlorene Kunden.

Heute gehen wir einen Schritt weiter und tauchen in die technische Umsetzung einer besseren Lösung ein: ein Multi-Agenten-System, das auf dem OpenAI Agents SDK aufbaut. Anhand eines Chatbots in einem Webshop für Kaffeemaschinen und -zubehör zeigen wir, wie wir durch die Aufteilung von Verantwortlichkeiten und eine enge Frontend-Backend-Kommunikation eine deutlich intelligentere und hilfreichere Beratungserfahrung schaffen.

Abbildung 1 zeigt den Gesamtprozess unseres Systems, von der Nutzerinteraktion im Frontend über die Agenten-Orchestrierung bis hin zur Antwort-Auslieferung per Streaming. In den folgenden Abschnitten gehen wir auf die einzelnen Bausteine im Detail ein.

Abbildung 1: Architektur

Die Architektur: Ein Team von Spezialisten

Statt eines einzigen, riesigen System-Prompts, der versucht, alle Eventualitäten abzubilden, setzen wir auf ein Team von spezialisierten Agenten. Jeder Agent hat eine klar definierte Aufgabe, eigene Anweisungen und eigene Tools. Je nach Agent lassen sich unterschiedliche Sprachmodelle einsetzen – von klein und schnell für einfache Klassifikationen bis hin zu großen, leistungsstarken Modellen für komplexe Reasoning-Aufgaben. Ein zentraler Orchestrator steuert diese Agenten, sammelt ihre Ergebnisse und formuliert daraus die finale Antwort an den Nutzer.

Die Idee dahinter ist einfach: Ein komplexes Problem lässt sich einfacher lösen, wenn man es in kleinere, überschaubare Teilprobleme zerlegt. Jeder Agent ist ein Experte für sein Gebiet.

Schauen wir uns die Agenten und ihre Rollen genauer an.

1. Die Gatekeeper: Eingangskontrolle

Bevor das System in die inhaltliche Beratung einsteigt, läuft jede Nutzereingabe durch eine Gatekeeper-Phase. Diese prüft parallel, ob die Anfrage grundsätzlich bearbeitet werden darf und ob direkt ein bestimmter Verarbeitungszweig sinnvoll ist.

Beispiel Guardrail-Agent: Der Guardrail-Agent bewertet, ob eine Anfrage zulässig und thematisch passend ist. Er filtert unangemessene Inhalte, Beleidigungen oder komplett fachfremde Fragen (z. B. „Was ist die Hauptstadt von Simbabwe?“). Fällt die Prüfung negativ aus, wird der Prozess früh beendet und eine freundliche Abweisung formuliert.

Daneben gibt es weitere Gatekeeper, z. B. einen Reco-Intent-Agent, der erkennt, ob der Nutzer jetzt eine Produktempfehlung möchte – und damit den Empfehlungsprozess direkt anstoßen kann.

2. Die Analysten: Verstehen & Strukturieren

Hat die Anfrage die Gatekeeper passiert, startet ein Set von Analysten-Agenten, die die Konversation aus unterschiedlichen Perspektiven auswerten. Sie laufen typischerweise parallel, um die Latenz niedrig zu halten. Ziel ist, aus freiem Text strukturierte Signale abzuleiten: Filter, Anforderungen, Wissensfragen, Widersprüche, nächste sinnvolle Rückfrage usw.

Beispiel Filter-Agent: Der Filter-Agent extrahiert explizite Filterkriterien aus der Nutzereingabe – etwa Preis („max. 2.000 €“), Hersteller („Bitte nur Jura“) oder Kategorie („Ich suche einen Vollautomaten“). Über dedizierte Tools kann er den Session State so aktualisieren, dass diese Filter unmittelbar in der Webshop-Oberfläche gesetzt werden. Der Nutzer sieht das Ergebnis sofort in der Produktliste.

Ergänzend dazu existieren weitere Analysten (z. B. für Anforderungen, Rückfragen, Wissensantworten, Produktmerkmale oder Widerspruchserkennung), die je nach Kontext hinzugeschaltet werden.

3. Die Ausführer (Action-Agents): Aktionen & Ergebnisse

Auf Basis der Analyse entscheidet der Orchestrator, ob und welche Aktionen ausgeführt werden, z. B. Empfehlungen erzeugen, den Warenkorb ändern oder eine Konsistenzprüfung durchführen. Diese Agenten greifen in der Regel auf Tools und Datenquellen zu und liefern konkrete Resultate.

Beispiel Reco-Agent: Wenn genügend Anforderungen vorliegen, erzeugt der Reco-Agent Empfehlungen mithilfe von Retrieval-Augmented Generation (RAG): Die gesammelten Anforderungen werden als Suchanfrage gegen eine Vektordatenbank mit Produktinformationen gestellt. Die relevantesten Treffer dienen als Kontext, aus dem der Agent eine Empfehlung formuliert, die auf echten Produktdaten basiert.

Daneben gibt es weitere Action-Agents – etwa einen Cart-Checker-Agent, der nach dem Hinzufügen zum Warenkorb prüft, ob die ausgewählten Produkte zusammenpassen.

Der Dirigent: Der Orchestrator

Das Herzstück des Systems ist der Orchestrator. Er agiert selbst wie ein Agent und steuert den gesamten Ablauf. Vereinfacht dargestellt passiert Folgendes:

• Gatekeeper-Phase, Analyse-Phase und Entscheidungslogik: Der Orchestrator verzahnt die oben beschriebenen Bausteine zu einem Ablauf: Er prüft eingehende Anfragen, lässt die passenden Analysten parallel arbeiten und leitet daraus ab, ob bereits eine Empfehlung sinnvoll ist oder ob dazu noch Informationen fehlen.
• Aggregation: Die Ausgaben aller zuvor gelaufenen Agenten werden zu einem einzigen, klaren Eingabe-Prompt zusammengeführt. Das übernimmt eine zentrale Aggregationsfunktion.
• Finale Antwort: Ein finaler Response-Agent erhält diesen aggregierten Input und formuliert daraus die Antwort an den Nutzer. Dieser Agent hat nur eine Aufgabe: die von den Spezialisten gelieferten Informationen zu einer flüssigen, gut strukturierten und freundlichen Antwort zusammenzufügen. Sein Instruktions-Prompt enthält dabei sehr strenge Regeln. So darf er z.B. keine Informationen erfinden oder hinzufügen, die nicht von einem der Sub-Agenten geliefert wurden.

Die Magie hinter den Kulissen: Frontend-Backend-Kommunikation

Ein moderner E-Commerce-Berater ist mehr als nur ein Chatfenster. Nutzer interagieren mit der gesamten Weboberfläche: Sie klicken auf Filter, legen Produkte in den Warenkorb oder sehen sich Detailseiten an. Ein wirklich intelligenter Chatbot muss diese Aktionen wahrnehmen und kontextbezogen darauf reagieren können.

Genau hier liegt die Stärke unserer Architektur, die auf einem FastAPI-Backend und Server-Sent Events (SSE) basiert.

Wenn Nutzer nicht nur tippen, sondern auch klicken

Der klassische Fall ist offensichtlich: Der Nutzer schreibt eine Nachricht, das Frontend sendet sie an den Server, der Orchestrator läuft los und die Antwort wird Token für Token zurückgestreamt.

Spannender wird es, wenn der Nutzer gar nicht tippt, sondern mit der Oberfläche interagiert, indem er z.B. einen Hersteller-Filter setzt, den Preisregler verschiebt oder auf „In den Warenkorb“ klickt. Jede dieser Aktionen löst im Hintergrund einen Aufruf an einen dedizierten API-Endpunkt aus.

Schauen wir uns das am Beispiel des Hersteller-Filters an: Klickt der Nutzer auf „Jura“ passiert Folgendes:

• Session-Zustand wird modifiziert: Der gewählte Hersteller wird im Session State als aktiver Filter gespeichert.
• Ein System-Ereignis wird erzeugt: In die Chat-Historie wird eine System-Nachricht eingefügt, etwa: „FrontendEvent: Der User hat per Klick den Hersteller ‚Jura‘ zum Filter hinzugefügt“
• Der Orchestrator wird gestartet: Ab hier läuft derselbe Prozess wie bei einer getippten Nachricht. Die Agenten können auf die neue Information reagieren, und der Chatbot könnte daraufhin antworten: „Verstanden, ich filtere die Ergebnisse für Sie nach Jura. Haben Sie weitere Wünsche?”

Der entscheidende Trick ist, dass UI-Interaktionen wie eine normale Konversation behandelt werden. Indem wir ein FrontendEvent als System-Nachricht in den Verlauf einfügen, informieren wir das LLM darüber, was außerhalb des Chatfensters passiert ist.

Streaming mit Server-Sent Events (SSE)

Die gesamte Kommunikation läuft über Server-Sent Events. Eine einzige, langlebige HTTP-Verbindung wird genutzt, um Daten vom Server zum Client zu pushen. Das ermöglicht uns, verschiedene Arten von Informationen in Echtzeit zu senden.

Konkret streamen wir zwei Typen von Events:

• Message-Events: Enthalten die Chat-Antwort des Orchestrators, die Token für Token an den Client gesendet wird.
• State-Events: Enthalten den aktualisierten Session-Zustand – zum Beispiel neu gesetzte Filter oder die Liste der empfohlenen Produkte, die der Reco-Agent im Hintergrund ermittelt hat.

Das Frontend kann so nicht nur die Chat-Nachricht live anzeigen, sondern auch auf Zustandsänderungen reagieren und etwa die Produktliste in Echtzeit aktualisieren.

Diese enge Verzahnung von UI-Interaktionen und Konversationslogik macht den Chatbot zu einem integralen Bestandteil der gesamten User Experience.

Lessons Learned

Beim Aufbau unseres Multi-Agenten-Systems haben wir einige Erkenntnisse gewonnen, die wir gerne teilen möchten:

• Prompts sind der kritischste Code: Die System-Prompts der einzelnen Agenten brauchen genauso viel Iteration und Testing wie klassischer Programmcode. Kleine Formulierungsänderungen können das Verhalten eines Agenten drastisch verändern.
• Parallelisierung zahlt sich aus – aber nicht überall: Die parallele Ausführung der Analysten-Agenten hat die Antwortzeit deutlich gesenkt. Allerdings gibt es Abhängigkeiten (z. B. braucht der Reco Agent die Ergebnisse der Filter- und Requirements-Agenten), die eine rein parallele Architektur unmöglich machen. Der Schlüssel liegt in einer bewussten Aufteilung in unabhängige und abhängige Phasen.
• Weniger ist oft mehr: Nicht jeder Agent muss bei jeder Anfrage laufen. Die kontextabhängige Aktivierung von Agenten (z. B. den Cart-Agent nur aufrufen, wenn der Nutzer über seinen Warenkorb spricht) spart Kosten und reduziert Rauschen im aggregierten Ergebnis.
• Frontend-Events sind mächtig, aber tricky: Die Idee, UI-Interaktionen als System-Nachrichten in den Chat-Verlauf zu injizieren, funktioniert hervorragend. Aber die Formulierung dieser Events muss sorgfältig gewählt werden, damit das LLM sie korrekt interpretiert und nicht als echte Nutzereingabe behandelt.
• Evaluierung bleibt die größte Herausforderung: Bei so vielen Agenten ist es schwierig zu messen, welcher Agent für ein gutes oder schlechtes Gesamtergebnis verantwortlich ist. Hier systematische Teststrategien zu entwickeln – von isolierten Agenten-Tests bis hin zu End-to-End-Szenarien – ist eine der spannendsten offenen Aufgaben.

Fazit: Komplexität beherrschen durch Spezialisierung

Der hier vorgestellte Multi-Agenten-Ansatz ist zwar komplexer in der Einrichtung als ein monolithischer Chatbot, bietet aber entscheidende Vorteile. Das Prinzip kennen wir aus der Zusammenarbeit von Menschen: Ein Team aus Spezialisten erzielt in der Regel bessere Ergebnisse als einzelne Generalisten, weil sich Perspektiven und Stärken ergänzen und Aufgaben klar verteilt sind.

Genau diese Logik übertragen wir auf den Chatbot: Spezialisierung sorgt für präzisere und verlässlichere Ergebnisse, Wartbarkeit entsteht durch klar abgegrenzte Verantwortlichkeiten (z. B. muss bei Änderungen an der Warenkorb-Prüfung nur der Cart-Checker-Agent angepasst werden), Modellflexibilität erlaubt pro Agent die passende Modellwahl bis hin zu lokalen Modellen für sensible Daten, und Kontrolle und Sicherheit steigen durch Guardrails sowie strenge Regeln für den finalen Antwort-Agenten.

Diese Architektur ermöglicht es uns, einen digitalen Berater zu schaffen, der seinem menschlichen Vorbild in nichts nachsteht – und den Nutzern endlich die hilfreiche Beratungserfahrung bietet, die sie im Online-Handel verdienen.

Neugierig geworden? Bei CID bauen wir genau solche Lösungen – maßgeschneidert auf Ihre Produkte, Prozesse und Zielgruppen. Sprechen Sie uns an. Wir freuen uns auf Ihr Projekt!