Multi-Agent-Systeme: wann sie helfen und wann nicht

Multi-Agent-Systeme sind in der Diskussion deutlich beliebter als in der Praxis. Der Grund: Die meisten Aufgaben, für die man mehrere Agenten einplant, löst ein einzelner Agent mit Werkzeugen zuverlässiger, schneller und billiger.

Was gut funktioniert – und was nicht

FUNKTIONIERT GUT:
  - Arbeitsteilung mit klaren, getrennten Rollen
    (Recherche -> Entwurf -> Pruefung)
  - Parallele, unabhaengige Teilaufgaben
    (20 Dokumente gleichzeitig zusammenfassen)
  - Trennung von Generierung und Pruefung
    (erzeugen und bewerten in zwei Rollen -
     findet deutlich mehr Fehler als ein Durchlauf)
  - Spezialisierung mit unterschiedlichen Werkzeugen
    (einer mit Datenbank, einer mit Websuche)

FUNKTIONIERT SCHLECHT:
  - "Viele Agenten reden so lange, bis eine Loesung
     entsteht"   -> endlose Schleifen, keine Ergebnisgarantie
  - Freie Unterhaltung ohne Struktur
  - Ein Agentengitter, in dem jeder mit jedem spricht
  - Mehrere Agenten mit denselben Werkzeugen
  - Beliebig viele Runden ohne Obergrenze

KOSTEN: Jede Runde ist eine eigene Anfrage mit vollem Kontext.
  Ein Agent    1x
  Drei Agenten 3x je Runde, und die Kontexte wachsen mit
  -> Bei 5 Runden ist man leicht bei 15-30 Modellaufrufen
     fuer eine Aufgabe, die eine Anfrage loest.

Zahlen aus dem Alltag: Fuer Aufgaben, die objektiv pruefbar
sind (Recherche mit belegbarer Antwort, Code mit Tests),
bringt eine zweite Rolle als Pruefer oft 15-30 % mehr
Trefferquote - bei 2-3x Kosten. Fuer offene Aufgaben
("schreibe einen Aufsatz") bringt es meist nur laengere
Antworten.

Die drei sinnvollen Muster

1) ERZEUGEN UND PRUEFEN (das wirksamste Muster)
   Ein Agent erzeugt, ein zweiter prueft mit klaren Kriterien.
   Wichtig: Der Pruefer muss eine ENTSCHEIDUNG treffen
   (annehmen/ablehnen mit Grund), nicht frei reden.

   # Pseudocode
   ergebnis = erzeuger.arbeite(aufgabe)
   for runde in range(3):                        # Obergrenze!
       urteil = pruefer.bewerte(aufgabe, ergebnis)
       if urteil.ok:
           break
       ergebnis = erzeuger.ueberarbeite(aufgabe, urteil.maengel)
   else:
       melde_zur_menschlichen_pruefung(aufgabe, ergebnis)

   # Der Pruefer braucht EIGENE Kriterien, sonst nickt er ab:
   #   - Jede Zahl muss eine Quelle haben
   #   - Jede Behauptung muss im Dokument stehen (RAG)
   #   - Der Code muss die Tests bestehen
   # Ohne pruefbare Kriterien ist die Pruefung wertlos.

2) PARALLELE TEILAUFGABEN (Geschwindigkeit, nicht Qualitaet)
   Gleiche Aufgabe, viele Eingaben. Keine Abstimmung noetig.

   from concurrent.futures import ThreadPoolExecutor

   def verarbeiten(eingabe):
       return extrahiere(mit_agent(eingabe))       # eigener Kontext

   with ThreadPoolExecutor(max_workers=8) as pool:
       ergebnisse = list(pool.map(verarbeiten, dokumente))
   #   Jede Verarbeitung hat ihren EIGENEN Kontext - daher
   #   weniger Fehler als bei einem Agenten, der alles
   #   nacheinander in einen Kontext quetscht.
   #   Obergrenze fuer die Anzahl gleichzeitiger Anfragen!

3) PIPELINE MIT FESTER REIHENFOLGE
   Stufen mit definierten Ein- und Ausgaben.
   Die Stufen sind Funktionen, nicht "Agenten", die reden.

   text      = hole_quelle(url)
   extrakt   = extrahiere_fakten(text)      # Agent 1
   geprueft  = pruefe_gegen_quelle(extrakt, text)   # Agent 2
   bericht   = formuliere(geprueft)         # Agent 3
   #   Jede Stufe: festes Eingabeformat, festes Ausgabeformat
   #   (JSON-Schema!). Damit ist die Kette pruefbar und
   #   ausfallsicher - ein Fehler bricht nicht alles.

Kommunikation: strukturiert, nicht frei

FALSCHE VARIANTE: Freie Unterhaltung
  agent_a: "Ich denke, wir sollten zuerst..."
  agent_b: "Das klingt sinnvoll, aber vielleicht..."
  agent_a: "Stimmt, lass uns..."
  -> Kein Ende, kein Ergebnis, hohe Kosten.

RICHTIGE VARIANTE: Feste Nachrichtenformate
  # Eine Nachricht hat IMMER diese Form:
  {
    "von":      "recherche",
    "aufgabe":  "Recherchiere X",
    "status":   "erledigt",          # oder "blockiert", "unklar"
    "ergebnis": "...",
    "quellen":  ["https://...", "https://..."],
    "unsicher": ["Punkt, bei dem ich unsicher bin"]
  }
  # Vorteile:
  #   - Maschinell pruefbar (JSON-Schema)
  #   - Status "blockiert" beendet die Schleife sauber
  #   - "unsicher" macht Zweifel sichtbar statt sie zu verstecken
  #   - Kein endloses Gerede

# Uebergeben wird nur, was gebraucht wird
#   FALSCH: den ganzen Verlauf aller Agenten mitschleppen
#           -> Kontext waechst, Kosten steigen, Qualitaet sinkt
#   RICHTIG: nur das Ergebnis plus die Aufgabe

# Ein Zustandsbuendel (geteilter Speicher) statt Unterhaltung
#   Alle Agenten lesen/schreiben in eine gemeinsame Struktur
#   (Datei, Datenbank, Objektspeicher) und reden nicht
#   miteinander. Damit ist jeder Schritt nachvollziehbar,
#   wiederholbar und einzeln pruefbar.

Wann ein einzelner Agent besser ist

Ein einzelner Agent mit Werkzeugen ist die richtige Wahl, wenn:
  - Die Aufgabe in einer Sitzung loesbar ist
  - Wenige Schritte noetig sind (unter 5-10)
  - Keine echte Rollenteilung existiert
  - Die Kosten eine Rolle spielen
  - Zuverlaessigkeit wichtiger ist als Anmutung

Ein Werkzeugsatz und eine klare Anweisung schlagen die
meisten Multi-Agenten-Entwuerfe. Die Regel lautet:
  ERSTE LAGE: ein Agent mit Werkzeugen
  ZWEITE LAGE: ein Agent plus Pruefer
  DRITTE LAGE: Pipeline mit festen Stufen
  Erst dann: sich unterhaltende Agenten - und nur mit
  Rundengrenze, Kostenbudget und pruefbaren Kriterien.

# Die häufigste Aufgabe, die man mit einem Agenten loest,
# ist eine Abfolge von Aufrufen. Wer das erst mit sechs
# Agenten versucht, hat den einfachen Weg uebersehen.

Prüfliste

Ist die Rundenzahl begrenzt (jede Schleife hat ein Ende)?
Gibt es eine Obergrenze für die Kosten (Budget, Aufrufzahl)?
Haben die Agenten eine echte Rollenteilung (nicht dieselbe Aufgabe)?
Sind die Nachrichtenformate fest und maschinell prüfbar (JSON-Schema)?
Gibt es einen sauberen Zustand „blockiert“ und einen Übergang an einen Menschen?
Wird nur das Nötige weitergegeben (kein voller Verlauf)?
Kann jede Stufe einzeln getestet werden?
Ist geprüft, ob ein einzelner Agent dasselbe Ergebnis liefert?
Sind Kosten und Dauer je Aufgabe gemessen?

Häufige Fehler

Agenten reden lassen. Ohne feste Formate und Rundengrenze kein Ergebnis, keine Nachvollziehbarkeit, hohe Kosten.
Keine Rundengrenze. Zwei Agenten können sich in einer Schleife gegenseitig bestätigen, bis das Budget weg ist.
Prüfer ohne Kriterien. Ein Prüfer, der „klingt gut“ sagt, verbessert nichts. Prüfbare Kriterien sind Pflicht.
Prüfer mit demselben Modell und Prompt. Er hat dieselben blinden Flecken. Ein anderer Blickwinkel (anderes Modell, andere Kriterien, Werkzeuge) findet mehr.
Kontext aufblähen. Wenn jeder Agent den ganzen Verlauf sieht, wachsen Kosten quadratisch und die Qualität sinkt.
Kein Ausweg bei Blockade. Ohne Zustand „blockiert“ läuft das System ewig oder liefert Unsinn.
Kosten nicht gemessen. 20 Modellaufrufe je Aufgabe fallen erst auf, wenn die Rechnung kommt.
Einfachen Weg übersehen. Oft löst ein Werkzeugsatz mit klarer Anweisung das Problem in einer Anfrage.

KI: LLM & Agenten