Frameworks wie LangChain haben die Entwicklung von KI-Agenten grundlegend vereinfacht. Mit wenigen Zeilen Code lassen sich Agenten erstellen, die Tools aufrufen, ein Gedächtnis pflegen und dynamisch mit Nutzern interagieren. Der Prototyp steht schnell – doch der Weg in die Produktion offenbart Schwächen, die im Laborbetrieb unsichtbar bleiben.
Warum synchrone Architekturen an ihre Grenzen stoßen
In einer typischen LangChain-Anwendung ruft der Agent synchron die OpenAI-API auf. Das bedeutet: Während ein LLM-Aufruf läuft, ist der gesamte Prozess blockiert. Bei wenigen Anfragen pro Minute fällt das kaum auf. Doch in einem produktiven Umfeld – etwa einem Kundenservice-Bot, der hunderte gleichzeitige Gespräche führt – wird diese Architektur schnell zum Engpass.
Die Konsequenzen sind gravierend: Hohe Latenzzeiten verschlechtern die Nutzererfahrung, Ressourcenkonflikte führen zu instabilem Verhalten, und fehlende Fehlerbehandlung kann im schlimmsten Fall zum Totalausfall des Systems führen. Hinzu kommen die Rate Limits der LLM-Anbieter, die bei synchroner Verarbeitung schnell erreicht werden.
Das Architekturmuster: Entkopplung durch Message Queues
Die Lösung liegt in einem bewährten Muster aus der Microservice-Architektur: der Entkopplung von Produzent und Konsument über eine Message Queue. Statt dass ein Agent direkt die OpenAI-API aufruft, schiebt er seinen Request in eine Redis-basierte Warteschlange. Ein separater Worker-Service nimmt die Anfrage entgegen, führt den tatsächlichen LLM-Aufruf durch und liefert das Ergebnis über einen dedizierten Antwortkanal zurück.
Dieses Muster bringt vier entscheidende Vorteile mit sich:
- Asynchrone Verarbeitung: Der Agent blockiert nicht mehr während des LLM-Aufrufs und kann sofort die nächste Anfrage entgegennehmen. Das verbessert den Durchsatz erheblich.
- Horizontale Skalierung: Mehrere Worker-Instanzen können parallel arbeiten. Steigt die Last, werden einfach weitere Worker hinzugefügt – ohne die Agenten-Logik ändern zu müssen.
- Fehlertoleranz: Fehlgeschlagene Aufrufe können automatisch wiederholt oder in eine Dead Letter Queue verschoben werden. Das System bleibt stabil, auch wenn einzelne LLM-Aufrufe scheitern.
- Rate-Limit-Management: Verschiedene API-Keys können auf verschiedene Worker verteilt werden, was den verfügbaren Durchsatz bei LLM-Anbietern vervielfacht.
Die drei Kernkomponenten der Architektur
Die technische Umsetzung besteht aus drei klar abgegrenzten Komponenten, die jeweils unabhängig entwickelt, deployt und skaliert werden können.
1. Custom Chat Model als LLM-Adapter
Das Herzstück der Integration ist ein eigenes Chat-Model, das die Standard-LLM-Klasse von LangChain ersetzt. Dieses Model implementiert dieselbe Schnittstelle – unterstützt also alle Nachrichtentypen (System, Human, AI, Tool), Tool-Calling und die gesamte Agent-Logik. Der entscheidende Unterschied: Statt direkt die OpenAI-API aufzurufen, serialisiert es die Nachrichten und schiebt sie in die Redis-Queue.
Für den Agenten selbst ändert sich dadurch nichts. Er arbeitet mit demselben Interface wie zuvor – nur dass die LLM-Aufrufe nun über die Queue laufen statt direkt über HTTP.
2. Redis als leichtgewichtiger Message Broker
Redis eignet sich hervorragend als Message Broker für diesen Anwendungsfall. Es ist schnell, einfach zu betreiben und unterstützt sowohl einfache Queue-Operationen (RPUSH/BLPOP) als auch Pub/Sub-Patterns. Jeder Request erhält eine eindeutige ID, über die die Antwort des Workers eindeutig zugeordnet wird.
In der Praxis hat sich gezeigt, dass Redis bei typischen LLM-Workloads – also eher wenigen, dafür langlebigen Requests – extrem zuverlässig und performant arbeitet. Die Latenz, die durch die Queue entsteht, ist im Vergleich zur LLM-Antwortzeit vernachlässigbar.
3. LLM Worker Service
Der Worker ist ein eigenständiger Microservice, der auf der Redis-Queue lauscht und die tatsächlichen API-Aufrufe an OpenAI (oder einen anderen LLM-Anbieter) durchführt. Er kann unabhängig skaliert, deployt und überwacht werden. Das ermöglicht unter anderem:
- Getrennte Deployment-Zyklen für Agenten-Logik und LLM-Integration
- Dediziertes Monitoring und Alerting für LLM-Kosten und Latenz
- Einfaches A/B-Testing verschiedener Modelle oder Konfigurationen
- Graceful Degradation bei Ausfällen des LLM-Anbieters
Verteiltes Gedächtnis als nächster Schritt
Wer die Architektur konsequent zu Ende denkt, stößt auf eine weitere Herausforderung: das Konversationsgedächtnis. In einer einzelnen Instanz speichert LangChain den Gesprächsverlauf im Arbeitsspeicher. Das funktioniert – aber nur, solange es genau eine Instanz gibt.
Sobald mehrere Agenten-Instanzen laufen – etwa in verschiedenen Kubernetes-Pods oder als horizontal skalierte Container – muss das Gedächtnis extern und geteilt sein. Auch hier bietet sich Redis an: Ein Redis-basiertes Memory-Backend, das LangChains BaseMemory implementiert, ermöglicht es allen Instanzen, auf denselben Gesprächsverlauf zuzugreifen.
Damit wird der Agent vollständig zustandslos. Er kann jederzeit durch eine andere Instanz ersetzt werden, ohne dass der Kontext verloren geht. Das ist die Grundvoraussetzung für echte horizontale Skalierbarkeit.
Praxiserfahrungen und Empfehlungen
Aus der praktischen Umsetzung dieser Architektur in Produktionsumgebungen lassen sich einige wichtige Erkenntnisse ableiten:
- Timeouts großzügig dimensionieren: LLM-Aufrufe können je nach Modell und Komplexität zwischen 2 und 60 Sekunden dauern. Die Queue-Timeouts müssen entsprechend konfiguriert werden.
- Idempotenz sicherstellen: Bei Retry-Mechanismen muss gewährleistet sein, dass ein erneut ausgeführter Request keine unerwünschten Nebeneffekte hat.
- Monitoring von Anfang an: Queue-Tiefe, Worker-Auslastung und Antwortzeiten sollten von Beginn an überwacht werden, um Engpässe frühzeitig zu erkennen.
- Graceful Shutdown: Worker sollten laufende LLM-Aufrufe abschließen, bevor sie heruntergefahren werden.
Fazit
Wer KI-Agenten produktiv betreiben will, braucht mehr als ein funktionierendes Prompt-Setup. Die synchrone Architektur, die im Prototyp so einfach und elegant wirkt, wird unter Last zum Risikofaktor. Die Entkopplung von Agenten-Logik und LLM-Ausführung über Message Queues schafft die nötige Skalierbarkeit, Fehlertoleranz und operative Kontrolle.
Das Beste daran: Die gesamte Flexibilität des LangChain-Frameworks bleibt erhalten. Tools, Memory, Agents – alles funktioniert wie gewohnt. Nur unter der Haube hat sich die Architektur grundlegend verändert: von einem fragilen Monolithen zu einem robusten, skalierbaren System, das den Anforderungen einer Produktionsumgebung gewachsen ist.