Spezialisten-Agenten, ein Schlüsselwort-Router und die Funktion interrupt(): Ein LangGraph-Coach

Ein einziger Assistenten-Auftrag, der zwei unverwandte Bereiche abdecken soll, erledigt diese in der Regel schlecht. Dieser Artikel stellt stattdessen einen Fitness- und Ernährungsberater als kleines LangGraph-System vor: zwei spezialisierte Agenten, ein deterministischer Router, der entscheidet, wer antwortet, einen gemeinsamen Zustand, der Einschränkungen über die Übergabe hinweg speichert, sowie einen menschlichen Kontrollpunkt, der das System nach jeder Antwort pausiert. Am Ende werden Sie wissen, wie jedes Element funktioniert, warum das System so gestaltet ist und wie man diese Struktur für jedes Paar von Spezialisten wiederverwenden kann.

Das Szenario und das Testgespräch

Das Zielprodukt ist ein Assistent in einer Fitness-App, der bei Training und Ernährung hilft. Die Konzeption wird anhand eines dreiteiligen Gesprächs überprüft: eine Anfrage nach einem Trainingsplan, eine Nachfrage zu Ernährungsthemen sowie eine diätetische Einschränkung, die die Essensempfehlungen ändern muss:

Scenario: A fitness app wants an assistant that helps with workouts and nutrition.

Test conversation flow (3 turns):
"Build muscle, lose fat — suggest a workout plan"
"What should I eat to support this workout plan?"
"I'm vegetarian, adjust the meal suggestion"

Jede der folgenden Gestaltungsentscheidungen dient dazu, zu gewährleisten, dass diese drei Interaktionsschritte korrekt und vorhersehbar ablaufen.

Warum ein allgemeiner Chatbot nicht ausreicht

Fragt man einen universellen Chatbot nach einem Trainingsplan und anschließend nach einer passenden Ernährungsstrategie, sind die Antworten in der Regel oberflächlich. Das Modell muss alle Anforderungen innerhalb eines einzigen Systembefehls verarbeiten, wodurch Ratschläge an Spezifität verlieren und Ernährungstipps vereinfacht werden. Diese Schwäche entsteht, wenn drei unterschiedliche Anforderungen gleichzeitig in denselben Befehl eingehen:

• Trennung der Bereiche. Die Planung von Trainingsprogrammen und die Ernährungsplanung gehören zu unterschiedlichen Fachgebieten, weshalb Ratschläge aus einem Bereich nicht in den anderen übergehen oder diesen widersprechen sollten.
• Aufrechterhaltung des Kontexts über mehrere Interaktionsschritte hinweg. Eine zuvor genannte Einschränkung, beispielsweise eine Knieverletzung, die bereits vor drei Nachrichten erwähnt wurde, muss weiterhin Einfluss auf später erstellte Ernährungs- oder Trainingspläne haben.

Menschliche Kontrolle beibehalten. Das System sollte nicht vollständig autonom laufen; es benötigt einen bewussten Punkt, an dem eine Person zustimmen, Details hinzufügen oder die Richtung ändern kann, bevor etwas anderes erzeugt wird.

Anstatt einer einzigen Anweisung drei Aufgaben zu übertragen, bietet die Architektur für jede Anforderung ein eigenes Mechanismus: Spezialisten zur Trennung der Bereiche, einen gemeinsamen Zustand für den Kontext sowie einen menschlichen Knoten zur Überwachung.

Die fünf Bausteine

Das System besteht aus fünf Teilen, von denen jeder eine einzige Aufgabe hat:

• Workout Advisor: Ein Agent, der für Übungspläne, Trainingsaufteilungen sowie Anpassungen bei Verletzungen zuständig ist.
• Nutrition Advisor: Ein Agent, der für Ernährungspläne, Makronährstoffe sowie diätetische Einschränkungen wie vegetarische, vegane oder allergiebedingte Ernährungsweisen verantwortlich ist.
• Router: Ein leichtgewichtiger Entscheidungsschritt, der die neueste Benachrichtigung des Nutzers prüft und auswählt, welcher Berater als Nächstes antwortet.
• Menschlicher Knoten: Eine bewusste Pause, während der das Diagramm auf die Person wartet, anstatt weitere Ausgaben zu erzeugen.
• Gemeinsamer Zustand: Eine einzige, autoritative Aufzeichnung des bisherigen Dialogs sowie Angaben dazu, welcher Berater zuletzt geantwortet hat.

Es handelt sich um ein hierarchisches oder orchestrierendes Muster. Ein Koordinator delegiert Aufgaben an spezialisierte Unteragenten, anstatt dass ein einziger Agent versucht, alle Rollen gleichzeitig zu übernehmen.

Die Regel, die die Übergaben vorhersehbar hält

Eine strukturelle Regel sorgt dafür, dass das gesamte Design vertrauenswürdig ist: ein Berater übergibt die Kontrolle niemals direkt an den anderen Berater. Jeder Ausgabevorgang eines Agenten geht über den menschlichen Knoten und anschließend über den Router. Zwei Agenten können daher niemals stillschweigend die Kontrolle hin- und hergeben, und jede Übertragung ist sowohl sichtbar als auch unterbrechbar.

Wie eine Nachricht durch das Graphen gelangt

Man folgt einer einzigen Benachrichtigung des Nutzers. Zunächst gelangt sie zum menschlichen Knoten, von dort wird sie an den Router weitergeleitet. Der Router liest den Nachrichtentext und wendet sich, falls der Text allein nicht ausreicht, auf das Feld last_active_agent im gemeinsamen Zustand zurück, um zwischen dem Trainingsberater und dem Ernährungsberater zu entscheiden. Der ausgewählte Berater kann anschließend sein eigenes Tools in seinem Domänenbereich aufrufen und gibt danach die Kontrolle wieder an den menschlichen Knoten zurück. Dieser pausiert erneut und wartet auf die nächste Nachricht. Der Kreislauf besteht somit stets aus menschlichem Knoten, Router, Berater, optionaler Tools und wiederum menschlichem Knoten.

Das Modell: ein öffentlich verfügbares LLM auf Groq

Sowohl die Berater nutzen das öffentlich verfügbare Modell openai/gpt-oss-120b, das von Groq bereitgestellt wird, und es ist mit temperature=0 konfiguriert:

• Warum dieses Modell: Es verfügt über eine zuverlässige Möglichkeit, native Tools aufzurufen, von der der toolsbasierte Arbeitsablauf abhängt.

Warum Temperatur 0: Dadurch werden die Ausgaben so reproduzierbar wie möglich, sodass das Diagramm den vorgesehenen Regeln folgt anstatt von Lauf zu Lauf zu variieren. Das ist wichtig, wenn jemand denselben Dialog wiederholt testet oder bewertet. In der Praxis garantiert selbst eine Temperatur von 0 bei gehosteten Modellen keinen strengen Determinismus, weshalb Tests eher auf Routing und Struktur als auf genaue Formulierungen geprüft werden sollten.

Warum Groq: Seine LPU-Inferenzhardware hält die Latenz niedrig, was von Vorteil ist, wenn ein Benutzerinput mehrere Schritte auslöst (Menschennode, Router, Berater, Tool, Menschennode), bevor eine Antwort erscheint.

Nichts im Diagramm hängt speziell von Groq ab. Jedes Chat-Modell, das Tools aufrufen kann – beispielsweise Google Gemini oder Anthropic Claude – funktioniert, sofern die entsprechende API-Schlüssel (wie GEMINI_API_KEY oder ANTHROPIC_API_KEY) bereitgestellt wird und der Modell-Wrapper auf diesen Anbieter verweist. Die Verfügbarkeit von Modellen auf gehosteten Plattformen ändert sich im Laufe der Zeit, daher sollte der Modell-Identifikator mit dem aktuellen Katalog des Anbieters abgeglichen werden.

Gemeinsamer Zustand: Wo die Erinnerung tatsächlich gespeichert ist

Jeder Knoten liest von und schreibt in ein typisiertes Zustandsobjekt namens MultiAgentState, das zwei Felder enthält:

• messages: Der vollständige laufende Dialog, der von LangGraphs MessagesState übernommen wurde; dieses liefert außerdem den Reduktor, der neue Nachrichten hinzufügt anstatt die Liste zu überschreiben.

last_active_agent: Es wird auf "workout_advisor" oder "nutrition_advisor" gesetzt; der Router greift darauf zurück, wenn er nicht erkennen kann, zu welchem Domain eine Nachfrage wie „Erzählen Sie mehr“ gehört.

Dieser Zustand erklärt, warum eine in einer Runde festgelegte Einschränkung auch in späteren Runden weiterhin gilt, selbst wenn eine andere Node die Antwort generiert. Dem Modell wird nichts zusammengefasst oder erneut erklärt. Jeder Berater erhält einfach immer dieselbe gesammelte messages-Liste, sobald er ausgeführt wird, und ein Checkpointer bewahrt den Zustand zwischen den Runden desselben Konversationsstrangs.

Die entscheidende Gestaltungsentscheidung besteht darin, dass das Gedächtnis zentralisiert ist und nicht pro Agent eingeschränkt wird. Wenn jeder Berater seine eigene private Historie hätte, würde der Ernährungsberater niemals von einem Ziel erfahren, das der Benutzer dem Trainingsberater mitgeteilt hat.

Ein einziges spezialisiertes Werkzeug pro Berater

Jeder Agent darf genau ein Werkzeug aufrufen, und dieses Werkzeug gehört zu seinem jeweiligen Bereich. In dieser Version basieren die Werkzeuge auf Regeln und erkennen Schlüsselwörter, wodurch das Verhalten vorhersehbar und leicht nachvollziehbar bleibt. In der Produktion können sie durch echte Fitness- oder Ernährungs-APIs ersetzt werden, oder das Modell kann die Antwort vollständig selbst erzeugen. Da der Rest des Graphen nur von der Schnittstelle des Werkzeugs abhängt, erfordert ein Wechsel der Implementierung keine weiteren Änderungen.

Jeder Berater auf seinem Gebiet halten

Ein spezielles Werkzeug reicht nicht aus, um einen Agenten auf dem Thema zu halten; das Modell muss auch wissen, worauf es nicht antworten darf. Jeder Systemprompt legt daher eine klare Grenze fest:

• Dem Workout-Berater wird mitgeteilt, keine Ernährungs- oder Mahlzeitenberatung zu geben, da der Graph solche Anfragen an den Ernährungs-Berater senden wird.

Dem Ernährungsrat wurde aufgetragen, keine Trainingspläne zu erstellen, da dies zur Aufgabe des Trainingsberaters gehört.

Der Grundsatz dahinter ist, dass das Modell sich nicht selbst leitet. Durch Grenzbedingungen wird jeder Agent dazu gebracht, abzuwarten anstatt außerhalb seines Fachwissens zu improvisieren, und das Diagramm – nicht die große Sprachmodelle – trifft explizit jede Leitentscheidung.

Ein Router, der auf Schlüsselwörtern beruht, nicht auf einem weiteren Aufruf eines großen Sprachmodells

Sobald die Berater eingeschränkt sind, muss der Router lediglich den nächsten Sprecher auswählen, und zwar mithilfe einfacher Schlüsselwortabgleiche:

• Wörter wie Gym, Reps, Kardio oder Muskel leiten an den Trainingsberater weiter.
• Wörter wie Diät, Futter, essen, Eiweiß oder vegetarisch leiten an den Ernährungsrat weiter.
• Alles, was weder in einer der Listen vorkommt, wird an den Berater weitergeleitet, der in last_active_agent gespeichert ist.

Eine deterministische Routierung ist vorhersehbar und leicht testbar: Dasselbe Nachrichtenmuster führt immer zum gleichen Weiterleitungsweg, und man kann den Router ohne Aufruf eines Modells unit-testen. Der Nachteil ist jedoch die Anfälligkeit. Schlüsselwortlisten übersehen Synonyme, und eine Nachricht, die beide Bereiche erwähnt (zum Beispiel eine Frage zum Essen vor dem Training), benötigt eine explizite Entscheidungsregel. Wenn die Formulierungen zu vielfältig für Schlüsselwörter sind, ist ein einfacher Klassifizierungsprozess eine sinnvolle Verbesserung – doch dadurch geht etwas von der Vorhersehbarkeit verloren.

Mensch im Prozess mit Unterbrechung und Befehl

Die wichtigste Gestaltungsentscheidung ist nicht der Router, sondern der menschliche Knoten. Nach jedem Zug des Beraters stoppt das Diagramm absichtlich. Es errät nicht die nächste Frage des Benutzers oder setzt die Generierung fort. Zwei LangGraph-Primitiven realisieren diese Pause:

• interrupt(...) stoppt die Ausführung genau an der Stelle, an der sie aufgerufen wird, und gibt die Kontrolle zusammen mit dem übergebenen Wert an den Aufrufer zurück.
• Command(resume=...) setzt das pausierte Diagramm fort und liefert die Eingabe des Menschen als Rückgabewert der interrupt-Aufruf innerhalb desselben Knotens.

Unterbrechungen setzen auf Checkpointing: Das Diagramm muss seinen Zustand bei der Pause speichern, damit es später fortgesetzt werden kann – deshalb benötigt das kompilierte Diagramm einen Checkpointer sowie eine Thread-ID.

Für einen Assistenten für Fitness und Ernährung ist diese Pause mehr als nur eine Benutzeroberflächenbequemlichkeit. Es handelt sich um den Moment, in dem der Nutzer vor Fortsetzung des Gesprächs eine sicherheitsrelevante Einschränkung hinzufügen kann – wie zum Beispiel eine Verletzung, Allergie oder Ernährungseinschränkung – anstatt dass das System bereits Ratschläge gibt, die diese ignoriern.

Durch die drei Schritte gehen

Schritt 1: Start des Gesprächs

Der Nutzer nennt zwei Ziele – Muskelaufbau und Fettverlust – und bittet um einen Trainingsplan. Ein neues Gespräch beginnt immer beim Workout Advisor. Dieser erfasst die Begriffe „Muskeln“ und „Fett“, ruft sein Tool auf und gibt einen strukturierten Trainingsplan zurück – beispielsweise eine viertägige Aufteilung auf Oberkörper/Unterkörper mit 8 bis 12 Wiederholungen in 3 bis 4 Sätzen, kombiniert mit drei Krafttrainings- und zwei Kardiotrainings-Tagen.

Schritt 2: Übertragung an den Ernährungsberater

Danach möchte der Benutzer wissen, welche Lebensmittel zu diesem Plan passen. Der menschliche Knoten leitet die Nachricht weiter, der Router erkennt „essen“ und die Ausführung wird an den Ernährungsberater übergeben. Dieser gibt einen täglichen Plan mit etwa 2.500 kcal zurück, der sich auf mageres Eiweiß und komplexe Kohlenhydrate konzentriert, wobei die Mahlzeiten alle drei bis vier Stunden eingenommen werden.

Schritt 3: Anwendung einer Einschränkung aus dem gemeinsamen Zustand

Zum Schluss erwähnt der Nutzer, dass er Vegetarier ist, und bittet darum, den Essensvorschlag anzupassen und einen Snack hinzuzufügen. Die Nachricht geht erneut an den Ernährungsratgeber, und hier stimmen zwei Mechanismen überein: „Vegetarier“ ist an sich ein Ernährungsschlüsselwort, und last_active_agent weist weiterhin auf Ernährung hin, sodass auch eine vageere Nachfrage wie „Anpassung dazu plus Snack“ an denselben Ort gelangt. Der Ratgeber liest die gesamte Historie erneut durch, berücksichtigt weiterhin das im ersten Schritt gesetzte Ziel, fügt die vegetarische Einschränkung hinzu und erstellt einen fleischfreien Muskelaufbauplan, der auf Tofu, Paneer und Linsen basiert, sowie Snacks wie Edamame und Hummusbecher. Niemand musste das Ziel erneut formulieren, denn es war bereits im System enthalten.

Diese Schrittfolge ist die Folge eines zentralisierten Staates. Ein anderer Knoten als der, der das ursprüngliche Ziel erhalten hat, erzeugt die Antwort, verfügt jedoch über den vollen Kontext.

Zusammensetzung der Zustandsmaschine

Strukturell ergibt sich ein kleiner Zustandsgraph mit drei Knoten (die beiden Berater und der menschliche Knoten) sowie dem Router als bedingter Logikschalter zwischen ihnen und einem festgelegten Eingangspunkt:

• Jeder neue Thread beginnt beim Workout-Berater. Dieser Standard spiegelt das Produkt wider: Menschen, die eine Fitness-App öffnen, fragen in der Regel zuerst nach Training und erst danach nach Ernährung.
• Nach dieser ersten Antwort entscheiden der menschliche Knoten und der Router über jeden weiteren Schritt.

Der Graph wird mit einem MemorySaver-Checkpointer erstellt, und jede Konversation wird durch einen thread_id identifiziert. Wenn der Aufrufer denselben thread_id erneut verwendet, stellt der Graph die Nachrichten sowie den last_active_agent automatisch wieder her; der Aufrufer muss die Historie nicht erneut übergeben.

MemorySaver speichert Checkpoints im Prozessspeicher, was für ein Notebook ideal ist, aber bei Neustart alles verloren geht. Eine in Produktion eingesetzte Version sollte einen persistenten Checkpointer unter Verwendung einer Datenbank verwenden.

Die vollständige funktionsfähige Umsetzung ist als begleitendes Notebook verfügbar. Weitere Möglichkeiten zur Strukturierung von Routing- und Genehmigungsprozessen finden Sie unter fünf LangGraph-Mustern, die Routing, Fan-Out, Kritik und Genehmigung abdecken.

Wiederverwendung des Musters außerhalb des Fitnessbereichs

Nichts hier ist speziell auf Workouts oder Mahlzeiten beschränkt. Die gleichen drei Komponenten – spezialisierte Agenten, ein durch gemeinsamen Zustand gesteuerter Router sowie eine menschliche Kontrollstelle mit Unterbrechen- und Fortsetzungsmechanismus – eignen sich für jedes System, das über:

• mehr als ein spezifisches Fachgebiet verfügt, das in einem Gespräch benötigt werden kann,

Die Notwendigkeit, den Prozess mittendrin zu unterbrechen, damit eine Person etwas einträgt oder bestätigt – sei es aus Gründen der Konformität, Sicherheit oder Personalisierung.

Ein in einem Teil des Gesprächs etablierter Kontext, der später einen anderen Spezialisten korrekt beeinflussen muss.

Ersetzt man die beiden Berater durch ein anderes Paar von Fachleuten, bleibt die Struktur des Graphen unverändert. Nur die Tools, Anfragen und Router-Schlüsselwörter ändern sich.

Entwurfsprinzipien

• Orchestrierung statt Monolithen. Nutzen Sie den Graphen, um getrennte Expertisebereiche durchzusetzen, anstatt sich auf einen einzigen Agenten zu verlassen, der alles erledigt.
• Zentralisierung des Zustands. Ein MultiAgentState, der von einem Checkpointer gespeichert wird, sorgt dafür, dass Übergaben reibungslos ablaufen und Einschränkungen bestehen bleiben.

Kontrolle ist entscheidend. Vermeiden Sie in der Produktion vollständig autonome Schleifen; verwenden Sie interrupt(), um an den wichtigen Stellen eine menschliche Einmischung zu gewährleisten.

Kernpunkte

• Teilen Sie die Arbeit nach Domänen auf und überlassen Sie die Routenentscheidung der deterministischen Graphenalgebra statt dem Modell.
• Bewahren Sie einen gemeinsamen messages-Historienverlauf sowie last_active_agent auf, damit frühzeitig gesetzte Einschränkungen die später von einem anderen Agenten erzeugten Antworten beeinflussen.
• Betrachten Sie interrupt() und Command(resume=...) als Mechanismen, mit denen eine Person Sicherheitsbeschränkungen vor der nächsten Antwort hinzufügen kann, und denken Sie daran, dass dafür ein Checkpointer sowie eine Thread-ID erforderlich sind.
• Halten Sie die Tools hinter einer stabilen Schnittstelle begrenzt, damit die regelbasierte Logik später ohne Berührung des Graphen zu einer echten API oder vollständigen Modelllogik werden kann.
• Der schnellste Weg, das Muster zu internalisieren, besteht darin, zwei gut definierte Spezialisten aus Ihren Reihen auszuwählen und ein vollständig funktionsfähiges Graph zu erstellen; die Topologie bleibt unverändert, während Anfragen und Tools die Teile sind, die Sie anpassen.