Im vorigen Kapitel haben wir behandelt, wie man einem einzelnen Agenten über MCP externe Werkzeuge anbindet. Bis hierher läuft ein autonomer Agent mit „Kopf, Werkzeugen, Gedächtnis und Schleife“. Wird die Arbeit jedoch größer, scheitert ein Entwurf, der alles in einen einzigen packt, irgendwann. In diesem Kapitel ordnen wir das „Multi-Agenten-Design“, das eine Aufgabe rollengeteilt mit mehreren Agenten löst, und die Denkweise ihres Zusammenspiels (A2A: Agent-to-Agent) auf konzeptioneller, framework-unabhängiger Ebene.
Das Ziel: beurteilen können, „wann und wie das Aufteilen stark macht“
Wenn einer nicht mehr ausreicht
Ein einzelner Agent ist einfach, gut überschaubar und leicht nachzuverfolgen – gerade deshalb ist es richtig, zuerst mit einem zu bauen. Das Problem entsteht, wenn man ihm nacheinander immer neue Rollen aufbürdet. Packt man „recherchieren, schreiben, prüfen, übersetzen und auch veröffentlichen …“ in einen einzigen Prompt, beginnt die Genauigkeit ab einem bestimmten Punkt plötzlich zu sinken.
Die Ursachen sind im Wesentlichen drei. ① Die Anweisung wird lang und vage (je mehr „dies und das“ man schreibt, desto ratloser wird das Modell, was Vorrang hat). ② Der Kontext bläht sich auf (auch belanglose Informationen werden mitgetragen, und die eigentliche Anweisung verdünnt sich). ③ Zu viele Werkzeuge (je mehr Auswahl, desto leichter greift es zum falschen Werkzeug). Ein überladener Einzelagent ist gleichsam ein „Arbeitsplatz, an dem eine Person mehrere Ämter zugleich hat und im Chaos versinkt“.
💡 Ein Perspektivwechsel. Statt einen einzelnen immer klüger zu machen, wechselt man zur Idee: „mehrere kleine Agenten, die je auf eine Rolle konzentriert sind, zusammenarbeiten lassen“. Das ist der Ausgangspunkt des Multi-Agenten-Designs. Nach derselben Logik, mit der man in einer menschlichen Organisation Arbeit teilt, gilt: Je enger und klarer die Zuständigkeit jedes Einzelnen, desto stabiler das Ganze.
Doch – Aufteilen macht nicht zwangsläufig alles besser. An der Arbeitsteilung haftet stets ein Abstimmungsaufwand. Deshalb ist das eigentliche Thema dieses Kapitels nicht nur „wie man aufteilt“, sondern vor allem, zu erkennen, „ob man überhaupt aufteilen sollte“. Sehen wir uns zuerst die drei typischen Formen an und gehen dann zu diesem Beurteilungsmaßstab.
Die drei Grundmuster
Multi-Agenten-Aufbauten lassen sich unzählige zeichnen, aber die in der Praxis immer wiederkehrenden Grundgerüste lassen sich auf drei verdichten. Kombiniert man diese drei, lässt sich fast jeder Aufbau erklären. Erfassen wir jeweils Rolle, Eignung und Nichteignung.
Der Eltern (Orchestrator) stellt den Gesamtplan auf, verteilt Aufgaben an die Kinder (Worker) zur Ausführung und fügt die Ergebnisse zusammen. Die Kinder kennen einander nicht, sie schauen nur auf den Eltern. Die Stärke: zentralistisch und gut steuerbar.
Passt, wenn: sich Aufgaben teilen und parallel laufen lassen sollen.
Arbeitsschritte aneinanderreihen und die Ausgabe des vorigen Agenten der Reihe nach als Eingabe des nächsten übergeben. Zum Beispiel „Recherche → Schreiben → Korrektur“. Da jede Stufe nur einen Schritt trägt, ist die Zuständigkeit klar und die Prüfung leicht.
Passt, wenn: der Ablauf linear und die Stufen festgelegt sind.
Wie „Recherche-Beauftragter“, „Code-Beauftragter“, „Review-Beauftragter“ Fachagenten mit je eigenem Spezialgebiet bereitstellen und je nach Lage gezielt abrufen. Da sich Anweisung und Werkzeuge je Einzelnem eingrenzen lassen, steigt die Spezialisierung.
Passt, wenn: die geforderten Fähigkeiten je Bereich stark verschieden sind.
Diese drei schließen einander nicht aus. Tatsächliche Systeme werden oft zu einer verschachtelten Struktur, etwa „ein Orchestrator bündelt Worker vom Experten-Typ, und einer davon ist eine Pipeline“. Leichter handhabbar ist der Aufbau, zuerst das äußerste Gerüst festzulegen und nur an nötigen Stellen im Inneren ein anderes Muster zu verwenden.
📊 Im Zweifel mit ① beginnen. Am universellsten der drei ist Orchestrator + Worker. Weil der Eltern zentral Planung und Zusammenführung hält, ist es gut steuerbar und die Grundform vieler Multi-Agenten-Aufbauten. Zur Einordnung der Muster insgesamt hilft Was sind Multi-Agenten, zur Auffassung als System Was ist ein Multi-Agenten-System.
Wann man aufteilt – und wann nicht
Kennt man die Muster, will man unwillkürlich alles aufteilen. Doch an der Arbeitsteilung hängt stets ein „Abstimmungsaufwand“ – der Aufwand, zwischen Agenten Informationen zu übergeben, zu verzahnen und aufeinander zu warten. Nur wenn der Gewinn aus dem Aufteilen diesen Abstimmungsaufwand übersteigt, sind Multi-Agenten die richtige Wahl. Stellen wir zunächst beide Seiten nebeneinander.
- Parallelisierbar: unabhängige Teilaufgaben gleichzeitig laufen lassen und Zeit sparen
- Spezialisierung nötig: Anweisung und Werkzeuge je Bereich eingrenzen erhöht die Genauigkeit
- Weite Exploration: mehrere Blickwinkel oder Kandidaten arbeitsteilig erkunden
- Kontext trennen wollen: den Kontext je Rolle trennen und Vermischung verhindern
- Eigentlich einfach: eine Aufgabe, die einer schafft, unnötig verkomplizieren
- Kosten steigen: je mehr Agenten, desto mehr stapeln sich LLM-Aufrufe und Tokens
- Schwere Abstimmung: der Aufwand fürs Übergeben und Aufeinanderwarten frisst den Gewinn der Arbeitsteilung auf
- Starke sequenzielle Abhängigkeit: hängt stark vom vorigen Ergebnis ab, kaum Spielraum für Parallelität
⚠️ Erst fragen: „Reicht einer?“ Multi-Agenten sind mächtig, aber nichts, was man als Erstes wählt. Die eiserne Regel ist, die Stufen zu steigern: ein Agent → den Prompt verbessern → ein Werkzeug ergänzen → reicht das immer noch nicht, aufteilen. Fügen Sie Komplexität erst hinzu, wenn Sie geprüft haben, „ob der eine Agent jetzt wirklich am Limit ist“. Aufteilen geht auch später noch.
Als praktischer Richtwert: Stellen Sie sich vor, „ob diese Rolle, wenn man sie einem menschlichen Kollegen erklärt, natürlich in eine Stellenbeschreibung für eine Person passt“. Lässt sie sich mit einem Titel beschreiben, reicht noch ein Agent. In dem Moment, in dem Sie „das ist die Person für Recherche, das die fürs Schreiben“ zu verschiedenen Personen machen wollen, ist es Zeit, das Aufteilen zu erwägen. Das Gesamtbild der Beurteilung finden Sie ergänzend in Wie man ein Multi-Agenten-System baut.
Zusammenspiel zwischen Agenten (A2A)
Hat man sich fürs Aufteilen entschieden, ist die nächste Entwurfsfrage: „Wie tauschen die Agenten untereinander Informationen aus?“ In einem menschlichen Team entspricht das dem Festlegen des Übergabe-Formats und der Berichtsregeln. Ist das vage, verzahnt sich das Ganze nicht, so fähig die Einzelnen auch sein mögen. Beim Zusammenspiel sind im Wesentlichen zwei Punkte zu beachten.
Was in welchem Format übergeben wird, festlegen. Macht man „Aufgabenanweisung, nötige Eingabe, erwartetes Ausgabeformat“ zu einer expliziten Vereinbarung, zögert die empfangende Seite nicht. Eine strukturierte Übergabe ist stabiler als das bloße Hinwerfen von Freitext.
Der Schritt, mehrere Ausgaben zu einer zu vereinen. Wer die Endverantwortung fürs Zusammenführen trägt, festlegen. Auch die Priorität bei widersprüchlichen Ergebnissen und die Art des Zusammenfassens (verdichten, abgleichen, Mehrheitsentscheid) gehören in den Entwurf.
Die Bewegung, diese Denkweise – „Agenten teilen sich Rollen und arbeiten koordiniert zusammen“ – stärker zu standardisieren, ist A2A (Agent-to-Agent). War MCP aus dem vorigen Kapitel die Vereinbarung, die „Agent ↔ Werkzeug/Daten“ verbindet, so ist A2A die Vereinbarung, die „Agent ↔ Agent“ verbindet – fassen Sie es als gemeinsame Umgangsform auf, um zu erfahren, was der Gegenüber-Agent kann, ihm eine Aufgabe aufzutragen und das Ergebnis zu empfangen.
💡 MCP und A2A im Gegensatz merken. Grob gesagt: MCP = einem Agenten eine „Hand“ anbinden, A2A = Agenten untereinander „verbinden“. Ersteres ist Werkzeug- und Datenanbindung, Letzteres die Umgangsform der Kooperation. Es genügt zunächst, sie als Konzept zu erfassen; konkrete Protokolle streifen wir auch in den folgenden Kapiteln. Genaueres in Was ist das A2A-Protokoll. Im Vergleich mit MCP und Werkzeuganbindung aus dem vorigen Kapitel wird der Unterschied deutlich.
Wichtig ist nicht, den Namen des Protokolls zu kennen, sondern die Entwurfshaltung, „dass Zusammenspiel eine explizite Vereinbarung braucht“. Wer welche Aufgabe hält, mit welcher Eingabe es beginnt, was zurückkommt, und an wen es bei einem Fehler zurückgeht – diese Vereinbarung vorab festzulegen, ist das Fundament eines Systems, das auch bei wachsender Größe nicht zerbricht.
Kontext und Kosten managen
Das größte praktische Risiko bei Multi-Agenten ist die Aufblähung von Kontext und Kosten. Je mehr Agenten und je mehr sie einander Informationen übergeben, desto dicker wird der Kontext, den jeder Agent trägt, und desto höher stapeln sich Zahl der LLM-Aufrufe und Token-Menge. Lässt man es laufen, entsteht leicht ein langsames, teures und instabiles System. Nehmen wir die Zügel schon im Entwurf in die Hand.
Den Kindern nur das für die Aufgabe Nötige übergeben. Nicht den ganzen Verlauf durchreichen. Belangloser Kontext senkt auch die Genauigkeit.
Lange Ergebnisse erst auf das Wesentliche verdichten und dann weitergeben. Die Idee, statt Rohlog „Schlussfolgerung und Beleg“ zu überreichen.
Der Zahl gleichzeitig laufender Kinder eine Obergrenze setzen. Unbegrenzt vermehrt zerbricht es an Kosten und Rate-Limits.
Beim Eltern mit schwerem Schlussfolgern und bei Kindern mit einfacher Arbeit die Modellgröße gezielt unterscheiden. Nicht alles auf das Spitzenmodell.
Besonders „übergebene Info eingrenzen“ ist eine wirkungsstarke Entwurfsentscheidung. Beim Orchestrator-plus-Worker-Typ gilt: Der Eltern hält das Gesamtbild, den Kindern übergibt man nur die herausgeschnittene Aufgabe und die minimale Eingabe. Je kleiner man den Kontext der Kinder hält, desto höher die Genauigkeit und desto niedriger die Kosten. Fassen Sie das als die auf mehrere Agenten erweiterte Denkweise des Context Engineering auf, das wir bis zum vorigen Kapitel gestreift haben.
⚠️ Kosten wirken als „Anzahl × Schrittzahl“. Ein zusätzlicher Agent stapelt dessen Aufrufe um die Rundenzahl der Schleife auf. Achtung: Je mehr Agenten, desto stärker bläht sich der Verlust pro Agent im Ganzen um ein Vielfaches auf. Legen Sie die Obergrenze für Parallelität und die Schritt-Obergrenze jedes Agenten (den Stopppunkt) von Anfang an fest. Das Messen, „wie viel verbraucht wird“, führt zur Beobachtbarkeit des nächsten Kapitels.
Stolpersteine und wie man sie im Entwurf verhindert
Multi-Agenten haben eigene Fehler, die es beim Einzelnen nicht gab. Alle verhindert man grundsätzlich vorab im Entwurf, nicht dem Zufall der Laufzeit überlassen. Merken wir uns drei typische und ihre Gegenmaßnahmen.
Mehrere Agenten machen dieselbe Arbeit doppelt, oder es ist unklar, „wer zuständig ist“, und keiner macht sie.
Verhindern: Die Zuständigkeit jedes Agenten überschneidungsfrei und lückenlos zuschneiden, sodass sich die Grenze in einem Satz aussprechen lässt.
A schiebt B, B schiebt A … sie schieben sich die Arbeit gegenseitig zu, es endet nie oder wiederholt denselben Austausch.
Verhindern: Stets eine Abbruchbedingung und eine Obergrenze für Hin-und-Her sowie Schrittzahl setzen. Hält die Zentrale (der Eltern) die Endentscheidung, läuft es seltener Amok.
Das Scheitern oder die falsche Ausgabe eines Agenten fließt unverändert weiter und stoppt das Ganze oder baut ein falsches Ergebnis auf.
Verhindern: Vor der Übergabe die Ausgabe validieren und einen Fallback für den Fehlerfall festlegen (erneut versuchen, Alternative, Eskalation an einen Menschen).
Die gemeinsame Lehre der drei: „Grenze, Abbruchbedingung, Validierung“ vor dem Schreiben von Code festlegen. Wer was übernimmt (Grenze), wann angehalten wird (Abbruchbedingung), und was vor der Übergabe geprüft wird (Validierung). Webt man diese drei in den Entwurf, lässt sich der Großteil der Multi-Agenten-eigenen Probleme im Vorfeld verhindern.
📊 „Was man nicht sieht, kann man nicht reparieren.“ Diese Fehler bemerkt man erst, wenn man nachträglich nachvollziehen kann, welcher Agent was getan hat. Sind mehrere Agenten im Spiel, wird „wo was passiert ist“ noch schwerer sichtbar als beim Einzelnen – gerade deshalb wird die Evaluierung und Beobachtbarkeit des nächsten Kapitels bei Multi-Agenten umso wichtiger.
- Überlädt man einen Einzelnen, sinkt die Genauigkeit. Lösen mit der Zusammenarbeit kleiner, eng rollengeteilter Agenten.
- Die Grundmuster sind drei – Orchestrator + Worker, Pipeline, Rollenteilung. Sie lassen sich verschachteln.
- Aufgeteilt wird, wenn Parallelität, Spezialisierung oder weite Exploration nötig sind. Ist es einfach, bleibt es bei einem. Erst fragen: „Reicht einer?“
- Zusammenspiel über eine explizite Vereinbarung (A2A = Umgangsform, die Agenten verbindet). Kontext und Kosten eingrenzen und managen.
- Die eigenen Fallstricke (Überlappung, Hin-und-Herschieben, verkettetes Scheitern) durch Grenze, Abbruchbedingung, Validierung vorab im Entwurf verhindern.
Sind mehrere Agenten am Laufen, braucht es als Nächstes, „zu messen, ob es wirklich gut läuft, und das Verhalten sichtbar zu machen“. In Kapitel 5 „Evaluierung und Beobachtbarkeit“ gehen wir zu Methoden über, die Qualität von Agenten zu messen und die inneren Vorgänge nachverfolgbar zu machen.