Multi-Agenten-Systeme: wann mehrere sich lohnen

Wer einmal gesehen hat, wie ein Agent drei Helfer startet, will danach alles so lösen. Die Diagramme sind verführerisch: ein Planer, ein Rechercheur, ein Schreiber, ein Kritiker. In der Praxis scheitern die meisten dieser Aufbauten – nicht am Modell, sondern an den Übergaben und an der Rechnung.

Die Vorgabe ist ein Agent

Ein einzelner Agent mit guten Werkzeugen, einer Regeldatei und einem klaren Auftrag löst die große Mehrheit der Aufgaben. Er hat den ganzen Zusammenhang im Kopf, und es gibt nichts zu koordinieren.

Mehrere Agenten kosten:

• Kontingent. Jeder Helfer liest seinen Kontext neu ein. Ein Lauf mit fünf Agenten verbraucht leicht das Mehrfache.
• Verlust an den Übergaben. Der Helfer weiß nur, was im Auftrag stand. Der Auftraggeber weiß nur, was in der Zusammenfassung steht.
• Fehlersuche. Bei einem falschen Ergebnis musst du herausfinden, welcher Agent an welcher Stelle falsch abgebogen ist.

Drei Gründe, die tragen

1. Kontext. Die Aufgabe verlangt, mehr zu lesen, als in ein Arbeitsgedächtnis passt – ein großes Codeprojekt, hundert Dokumente. Helfer lesen Teile und liefern Zusammenfassungen zurück.

2. Breite. Die Aufgabe zerfällt in unabhängige Teilfragen, die gleichzeitig beantwortet werden können: acht Wettbewerber, zwölf Quellen, fünf Varianten.

3. Unabhängigkeit. Du brauchst ein Urteil, das nicht von der Entstehung beeinflusst ist. Ein Agent, der einen Text geschrieben hat, findet seine eigenen Fehler schlecht. Ein zweiter mit frischem Kontext findet sie besser.

Kein Grund ist: Rollen um der Rollen willen. Ein „Projektleiter-Agent“, der Aufgaben an einen „Entwickler-Agenten“ weiterreicht, fügt eine Übergabe hinzu und sonst nichts.

Die Diagnosefrage

Bevor du einen zweiten Agenten baust, frag: Woran scheitert der erste?

Drei Muster

Orchestrator und Helfer. Ein Hauptagent zerlegt die Aufgabe, verteilt Teile an Helfer und setzt die Ergebnisse zusammen. Geeignet für Kontext und Breite. Die Helfer lesen und berichten – das Schreiben bleibt beim Hauptagenten.

Pipeline mit Prüfpunkten. Feste Stufen nacheinander: sammeln, auswerten, entwerfen. Zwischen den Stufen steht eine Prüfung, die entscheidet, ob es weitergeht. Geeignet für wiederkehrende Abläufe, bei denen ein früher Fehler alles Folgende wertlos macht.

Macher und Prüfer. Einer erzeugt, einer prüft – mit frischem Kontext und dem ausdrücklichen Auftrag, Fehler zu finden. Der Prüfer bekommt den Auftrag und das Ergebnis, nicht die Begründung des Machers. Sonst bestätigt er sie.

Die Übergabe schreiben

Ein Helfer startet ohne dein Gespräch, ohne die Vorgeschichte, ohne das, was der Hauptagent schon ausgeschlossen hat. Der Auftrag an ihn muss deshalb für sich stehen:

Ziel:        Was am Ende vorliegen soll – und wofür.
Bekannt:     Was schon geprüft oder ausgeschlossen ist.
Umfang:      Welche Dateien oder Quellen, was ausdrücklich nicht.
Rückgabe:    In welcher Form, mit welchen Belegen.

Und auf dem Rückweg gilt: Was ein Helfer meldet, ist ein Bericht, kein Beweis. Der Hauptagent prüft die tragenden Aussagen, bevor er darauf aufbaut – so wie du die Quellen einer Recherche öffnest.

Zwei Regeln für den Betrieb

Je Ressource ein Schreiber. Dateien, Datensätze, Tickets: Nie schreiben zwei Agenten gleichzeitig in dasselbe. Lesen dürfen beliebig viele.

Obergrenze für die Auffächerung. Ein Orchestrator, der nach eigenem Ermessen Helfer startet, kann in Minuten ein Monatsbudget verbrauchen. Leg fest, wie viele Helfer ein Lauf höchstens starten darf, und miss, was ein Lauf kostet – das ist die nächste Station.

Die ehrliche Probe

Nimm deinen Testsatz und lass ihn einmal mit einem Agenten und einmal mit dem Mehr-Agenten-Aufbau laufen. Vergleiche Trefferquote, Kosten und Dauer. Ist der Aufbau nicht deutlich besser, ist er nur teurer.