Supervisor-Pattern (Hierarchisches Multi-Agenten-System)

1. Konzeptüberblick und systemisches Problem

Bei der Entwicklung von Multi-Agent-Systemen stoßen Ingenieure häufig auf Koordinationsprobleme. Wenn Agenten einfach Nachrichten in einen gemeinsamen Chat-Verlauf (Group Chat) posten:

• Verlust des Zielfokus: Agenten beginnen, die Beiträge ihrer Kollegen zu kommentieren, und vergessen dabei die ursprüngliche Nutzeranfrage.
• Unkontrolliertes Kontextwachstum: Jeder Agent sieht den vollständigen Nachrichtenverlauf aller anderen Agenten, was zu quadratischem Token-Verbrauch und einer Degradation der Attention-Mechanismen führt.
• Fehlende Deterministik: Es ist nicht garantierbar, dass eine Aufgabe tatsächlich gelöst wurde, anstatt nur im Gespräch unterzugehen.

Das Supervisor Pattern implementiert eine klassische ingenieurtechnische Hierarchie: Ein zentraler Orchestrator (Supervisor) interagiert mit dem Nutzer, erstellt einen Ausführungsplan, zerlegt ihn in isolierte Tasks, weist diese den spezialisierten Agenten (Specialist Workers) zu und aggregiert das finale Ergebnis.

2. Architektonische Taxonomie und mentales Modell

                       ┌─────────────────────────┐
                       │       USER PROMPT       │
                       └────────────┬────────────┘
                                    │
                                    ▼
                       ┌─────────────────────────┐
                       │    SUPERVISOR AGENT     │
                       │  (State, Plan & Router) │
                       └───┬────────┬────────┬───┘
                           │        │        │
           ┌───────────────┘        │        └───────────────┐
           │ Task A                 │ Task B                 │ Task C
           ▼                        ▼                        ▼
┌────────────────────┐   ┌────────────────────┐   ┌────────────────────┐
│   RESEARCH AGENT   │   │    CODER AGENT     │   │     QA AGENT       │
│ (Search, Docs, RAG)│   │ (AST, Git, Patch)  │   │(Evals, Tests, Lint)│
└──────────┬─────────┘   └──────────┬─────────┘   └──────────┬─────────┘
           │                        │                        │
           └───────────────┐        │        ┌───────────────┘
                           ▼        ▼        ▼
                       ┌─────────────────────────┐
                       │   AGGREGATED ARTIFACT   │
                       └─────────────────────────┘

1. State Machine / Router: Der Supervisor enthält eine endliche Zustandsmaschine. Nach jedem Schritt evaluiert er: Abgeschlossen? -> Antwort an den Nutzer zurückgeben, oder Nächster Schritt erforderlich? -> Entsprechenden Worker aufrufen.
2. Task Encapsulation: Jeder Worker erhält ausschließlich die benötigten Eingabedaten und seinen eigenen Tooling Scope. Beispielsweise hat ein Coder Agent keinen Zugriff auf Google-Suche, während ein Research Agent keine Berechtigung zur Modifikation des Dateisystems besitzt.

3. Technischer Pipeline und interne Mechanik

Algorithmus des Supervisors:

1. Analyse der eingehenden Aufgabe: Das Supervisor-Modell wird mit einem System-Prompt aufgerufen, der die Kompetenzen jedes Workers beschreibt, sowie mit einem Schema für Entscheidungsfindung (Function Calling / Structured Output).
2. Generierung der Routing-Entscheidung:

   {
     "next_worker": "coder_agent",
     "task_description": "Implement authentication middleware in src/auth.ts using Better Auth",
     "expected_artifacts": ["src/auth.ts"]
   }
   

3. Isolierte Worker-Ausführung: Der Orchestrator initialisiert den Worker-Kontext, startet dessen autonomen Loop und wartet auf die Rückgabe des Ergebnisses.
4. Qualitätskontrolle (Evaluation Gate): Nach Erhalt des Ergebnisses kann der Supervisor dieses entweder freigeben, an einen QA-Agenten zum Testen weiterleiten oder es zur Korrektur an den Worker zurückgeben (Self-Correction Loop).

4. Praktische Engineering-Szenarien im Production-Umfeld

01. Autonome Implementierung komplexer Funktionalität

Der Nutzer fragt: „Füge dem Projekt einen PDF-Berichtsexport mit Diagrammen hinzu.“ Der Supervisor ruft auf:

1. Research Worker – Findet eine geeignete Bibliothek und prüft die Lizenz.
2. Backend Worker – Erstellt den API Endpoint und den Berichtsgenerator.
3. Frontend Worker – Fügt einen Button in die UI und einen Ladeindikator hinzu.
4. Tester Worker – Führt Playwright-Tests aus.

02. Triage und Behebung von Security-Incidents

Der Supervisor reagiert auf einen Alert in Sentry, übergibt den Stack Trace an einen Diagnose-Agenten, validiert den vorgeschlagenen Hotfix durch einen Test-Agenten und erstellt einen Pull Request.

5. Fallstricke, typische Fehler und Sicherheit

• Deadlock Loops (Endlosschleife zwischen Supervisor und Worker): Der Supervisor ist der Meinung, die Aufgabe sei nicht vollständig gelöst, und gibt sie an den Worker zurück. Der Worker liefert denselben Code erneut. Lösung: Setze max_iterations = 5 und werfe bei Überschreitung einen Fehler an den Menschen.
• Context Bleed (Kontaminierung des Supervisor-Kontexts): Wenn ein Worker 10.000 Zeilen Code zurückgibt, füllt sich der Supervisor-Kontext schnell über. Worker sollten Code im Dateisystem speichern und lediglich Status sowie Diff zurückliefern.
• Single Point of Failure: [Hinweis: Im Originaltext nicht explizit als Bullet ausgeführt, aber implizit durch die Architektur gegeben; hier bleibt der Fokus auf den genannten Punkten.]