Einen Support-Agenten in Intake-, Knowledge- und Support-Knoten aufteilen

An diesem Punkt kann der LEPA-Support-Agent eine Anfrage routen, die Dokumentation durchsuchen und sich einen Gesprächsverlauf merken. Bleibt die Frage, wie die Arbeit selbst organisiert ist. Statt einer riesigen Funktion, die alles erledigt, verteilen sich die Aufgaben auf ein paar Spezialisten, und LangGraph koordiniert sie.

Stellen Sie sich einen Hausbau vor

"Multi-Agent" klingt nach Science-Fiction. Hilfreicher ist das Bild einer Baustelle, auf der mehrere Gewerke an einem Projekt arbeiten:

Electrician
Plumber
Painter
Inspector

Verschiedene Aufgaben, verschiedene Fähigkeiten, ein Haus. Ein Support-Ablauf lässt sich genauso aufteilen:

Someone understands the request
Someone finds the handbook page
Someone writes the reply

Diese Aufteilung lohnt sich nur, wenn sich die Aufgaben wirklich unterscheiden. Zusätzliche Kästchen auf einer Folie zählen nicht.

Der Graph in diesem Projekt

Der kompilierte Graph läuft so ab:

START
  → intake
  → classify
  → conditional
        ├─ ask_clarification → END
        └─ knowledge → support → END

Intake, Knowledge und Support heißen in der Projektstruktur Agenten, weil jeder genau eine klare Aufgabe hat. Classify und der Rückfrage-Schritt liegen dagegen im Ordner nodes/. Das ist dieselbe Graph-Idee, nur mit etwas anderer Ordnerbenennung. "Multi-Agent" heißt hier: spezialisierte Knoten in einem einzigen kompilierten StateGraph. Es heißt nicht, dass es getrennt deployte Services gibt, und auch nicht, dass Agenten miteinander diskutieren. Die Ordnernamen sind weniger wichtig als die klare Trennung der Zuständigkeiten.

Was die einzelnen Spezialisten tun

Intake

Intake nimmt die letzte Nachricht des Nutzers und liefert eine user_role:

"I'm a teacher — how do I take attendance?"
        ↓
user_role = teacher

Der Knoten durchsucht keine Dokumentation und schreibt nicht die endgültige Antwort. Er bereitet nur den Kontext für das Routing vor.

Classify und der Rückfrage-Zweig

Classify bestimmt das Thema und entscheidet, ob genug bekannt ist, um weiterzumachen:

"help" → ask for the LEPA area
"How do I enter grades?" → continue to knowledge

Diese Verzweigung ist die eigentliche Orchestrierung: dasselbe System, aber ein anderer nächster Spezialist.

Knowledge

Knowledge chattet nie. Der Knoten holt nur Dokumente:

query + issue_category
        ↓
search_knowledge_impl  (keyword Markdown search)
        ↓
retrieved_documents

Im selben Modul gibt es einen @tool-Wrapper namens search_knowledge für spätere Experimente, aber der Graph ruft die eigentliche Implementierung direkt auf.

Support

Support greift nie aufs Dateisystem zu. Der Knoten liest retrieved_documents und erzeugt final_answer, standardmäßig aus einer Vorlage und optional von einem LLM nachgeschliffen, wenn eines konfiguriert ist.

Wie LangGraph die Reihenfolge einhält

Kein Manager-LLM entscheidet frei, wer als Nächstes dran ist. Die Verdrahtung ist explizit:

graph.add_edge(START, "intake")
graph.add_edge("intake", "classify")
graph.add_conditional_edges("classify", route_after_classify, {...})
graph.add_edge("knowledge", "support")

Einfach gesagt ist LangGraph der Kellner und jeder Knoten eine Station in der Küche. Technisch legen Kanten den Standardpfad fest, bedingte Kanten definieren Verzweigungen, die vom State abhängen, und über einen gemeinsamen SupportState reichen die Spezialisten ihre Ergebnisse weiter, ohne sich gegenseitig aufzurufen. Genau diese letzte Eigenschaft ist die entscheidende:

Intake does not call Support.
Knowledge does not call Classify.
They write to state.
The graph decides the next node.

Warum nicht ein einziger Agent?

Eine einzige Funktion wäre möglich gewesen:

def handle(message):
    detect role
    classify
    maybe clarify
    search docs
    write answer

Für eine winzige Demo funktioniert das, aber als Lernsystem verdeckt es die Nahtstellen. Ein aufgeteilter Graph macht einiges leichter:

• Die Klassifizierung testen, ohne die Dokumentensuche einzubeziehen
• Eine falsche Antwort getrennt von einer falschen Route debuggen
• Später einen Schritt austauschen, etwa durch einen LLM-Klassifizierer oder eine bessere Suche, ohne alles neu zu schreiben
• Das System mit einem einfachen Diagramm erklären

Der eigentliche Gewinn des Multi-Agent-Designs ist hier die Klarheit.

Was es nicht ist

Um ehrlich zu sein: Diese Spezialisten sind keine getrennt deployten Services, sie streiten nicht miteinander und sie sind auch keine autonomen Agenten-Firmen. Es sind fokussierte Graph-Knoten mit klaren Verträgen, die LangGraph orchestriert. Um die Idee zu verstehen, reicht das, und es beschreibt ehrlich, was das Projekt tut.

Die Idee in drei Zeilen

Multi-Agent-Orchestrierung im LEPA-Support-Agenten läuft auf Folgendes hinaus:

Specialize the jobs.
Share state.
Let the graph choose the next job.

Intake, Knowledge und Support sind getrennt, weil sie unterschiedliche Aufgaben haben, und LangGraph macht die Übergaben sichtbar. Als Nächstes folgt ein verwandtes Konzept: Human-in-the-Loop. Echte Freigabeschritte gibt es dafür noch nicht, und es ist etwas anderes als Rückfragen zu stellen.