Multi-Agent-Systeme: Delegation, Isolation, Koordinationskosten

Der Reflex und der tatsächliche Mechanismus

Wenn ein Agent unzuverlässig arbeitet, ist der verbreitete Instinkt, ihn in mehrere zu zerlegen: einen Rechercheur, einen Kritiker, einen Schreiber. Die Begründung lautet Spezialisierung — dieselbe Intuition, die in Organisationen funktioniert.

Der Mechanismus, der bei Agenten tatsächlich wirkt, ist ein anderer und viel unspektakulärer: jeder Unteragent hat sein eigenes Kontextfenster. Fünf Agenten haben fünf Fenster, also fünffachen Arbeitsspeicher — und jeder von ihnen arbeitet in einem kleinen, sauberen Kontext statt in einem großen, vollgelaufenen.

Unteragent — Ein eigener Agentenlauf mit eigenem Kontextfenster, eigenem Systemprompt und eigener Werkzeugmenge, der einen abgegrenzten Teilauftrag bearbeitet und ein Ergebnis in festgelegter Form zurückgibt. Er sieht weder den Verlauf des führenden Agenten noch den anderer Unteragenten.

Der Preis steht in Zahlen fest

Anders als bei den meisten Architekturfragen gibt es hier belastbare Größenordnungen. Sie sollten am Anfang jeder Diskussion stehen, nicht am Ende.

Chat

Die Bezugsgröße: ein Aufruf, eine Antwort.

Einzelagent

Verbraucht typischerweise etwa viermal so viele Tokens wie eine Chat-Interaktion — die Schleife schickt die Historie wiederholt.

Multi-Agent

Verbraucht etwa fünfzehnmal so viele Tokens wie ein Chat. Jeder Unteragent führt seine eigene Schleife mit eigenem Vorspann.

Dem steht ein realer Gewinn gegenüber: In einer internen Rechercheauswertung erreichte ein System aus einem führenden Agenten und mehreren Unteragenten eine Verbesserung von 90,2 Prozent gegenüber einem Einzelagenten mit dem stärkeren Modell.

Dieser Befund ordnet die ganze Debatte neu. Der Gewinn kommt überwiegend daher, dass ein Multi-Agent-System mehr Arbeit hineinsteckt — nicht daraus, dass Rollenverteilung an sich klüger macht. Die richtige Frage lautet deshalb nicht „ist Multi-Agent besser“, sondern: Rechtfertigt die Aufgabe den fünfzehnfachen Einsatz, und gibt es einen billigeren Weg, mehr Arbeit hineinzustecken?

Diese billigeren Wege gehören vor jeder Zerlegung geprüft, weil sie an derselben Stellschraube drehen. Ein höheres Rundenbudget für den Einzelagenten steckt mehr Arbeit in dieselbe Aufgabe, ohne eine Koordinationsschicht zu bauen. Ein stärkeres Modell ist der zweite der drei erklärenden Faktoren und braucht keinerlei Architekturänderung. Eine Reflexionsrunde mit externem Urteil erhöht die Arbeit gezielt an der Stelle, an der die Qualität fehlt.

Erst wenn diese Hebel ausgeschöpft sind und die Aufgabe trotzdem an einer der weiter unten genannten Grenzen scheitert, ist die Zerlegung die naheliegende Antwort. Wer sie vorher wählt, bezahlt fünfzehnfach für einen Effekt, den ein größeres Rundenbudget vierfach geliefert hätte.

Wofür es passt

• Starke Parallelisierbarkeit — die Aufgabe zerfällt in Teile, die gleichzeitig und unabhängig bearbeitet werden können.
• Information über ein Kontextfenster hinaus — der Stoff passt schlicht nicht in einen Lauf, egal wie gut man verdichtet.
• Viele komplexe Werkzeuge — ein einzelner Agent müsste eine unübersichtliche Werkzeugmenge im Auswahlraum halten.
• Breitensuche — Fragen, die mehrere unabhängige Richtungen gleichzeitig verfolgen, statt einer Kette voneinander abhängiger Schritte.

Alle vier Kriterien beschreiben dieselbe Eigenschaft aus verschiedenen Blickwinkeln: Die Aufgabe zerfällt in Teile, die einander nicht brauchen. Sobald ein Teil das Zwischenergebnis eines anderen benötigt, ist die Zerlegung keine Parallelisierung mehr, sondern eine Kette mit zusätzlicher Übergabe.

Wofür es ausdrücklich nicht passt

Die Gegenrichtung ist in derselben Quelle klar benannt und wird selten zitiert: Bereiche, in denen alle Agenten denselben Kontext teilen müssen oder in denen viele Abhängigkeiten zwischen den Agenten bestehen, eignen sich heute nicht für Multi-Agent-Systeme.

Das bemerkenswerteste Beispiel dafür ist die Softwareentwicklung. Die meisten Programmieraufgaben enthalten weniger echt parallelisierbare Teilaufgaben als Recherche — und Sprachmodelle sind noch nicht gut darin, sich in Echtzeit gegenseitig zu koordinieren und zu delegieren. Wer ausgerechnet dort mit Rollenagenten beginnt, wählt den ungünstigsten Anwendungsfall.

Gute Eignung

Fünfzehn Lieferanten unabhängig gegen dieselbe Prüfliste bewerten. Kein Teil braucht ein Ergebnis eines anderen.

Schlechte Eignung

Eine Änderung über mehrere Dateien hinweg umsetzen. Jeder Teil verändert Voraussetzungen der anderen.

Falsche Eignung

Einen unzuverlässigen Einzelagenten in Rollen aufteilen, ohne dass sich an der Abhängigkeitsstruktur etwas ändert.

Es gibt einen einfachen Test, der die Zeile trifft, in die eine Aufgabe gehört: Man schreibt die Teilaufgaben untereinander und zieht für jede einen Pfeil zu jeder anderen, deren Ergebnis sie braucht. Bleibt das Blatt leer, ist Zerlegung möglich. Gibt es wenige Pfeile in eine Richtung, ist es eine Kette mit definierten Übergaben. Gibt es Pfeile in beide Richtungen, ist es eine einzige Aufgabe, die nur größer aussieht als sie ist.

Orchestrator und Worker als Grundform

Beobachtete Größenordnungen: Der führende Agent startet typischerweise drei bis fünf Unteragenten gleichzeitig, und jeder von ihnen ruft mehrere Werkzeuge parallel auf. Bei komplexen Anfragen verkürzte das die Bearbeitungszeit um bis zu 90 Prozent.

Wichtig am hervorgehobenen Schritt: Das Rückgabeformat ist Teil der Architektur, nicht Kosmetik. Der führende Agent sieht vom Lauf eines Unteragenten nur dieses Ergebnis — nicht dessen Kontext, nicht dessen Zwischenschritte, nicht dessen Unsicherheit. Was das Format nicht vorsieht, existiert für die Zusammenführung nicht.

Die Zahl der Unteragenten ist ebenfalls eine Entwurfsentscheidung und keine Laufzeitfrage. Sie dem führenden Agenten zu überlassen klingt flexibel und erzeugt eine Kostengröße, die niemand vorher kennt: Zerlegt er in zwölf statt in vier Teile, kostet der Lauf das Dreifache, ohne dass sich an der Aufgabe etwas geändert hat. Tragfähig ist eine harte Obergrenze in der Ausführungsschicht, ergänzt um eine Regel, was bei mehr Teilbereichen passiert — nacheinander abarbeiten oder ausdrücklich melden, dass der Auftrag zu breit ist.

Der Delegationsvertrag hat vier Bestandteile

Ohne ausreichend genaue Teilaufträge treten drei benannte Fehlformen auf: Agenten verdoppeln Arbeit, lassen Lücken oder finden die nötige Information nicht. Alle drei sind Symptome desselben Mangels — der Auftrag war unterspezifiziert.

• Ziel — was genau soll herauskommen, in einem Satz, überprüfbar formuliert.
• Ausgabeformat — welche Felder in welcher Form. Das ist die einzige Schnittstelle zur Zusammenführung.
• Hinweise zu Werkzeugen und Quellen — welche zu benutzen sind und welche nicht.
• Klare Aufgabengrenzen — was ausdrücklich nicht zu diesem Teilauftrag gehört. Der Punkt, der am häufigsten fehlt und die Verdopplung verursacht.

In der Umsetzung ist ein Teilauftrag deshalb kein Prompt-Satz, sondern ein Datensatz mit benannten Feldern: ein objective, ein output_schema, eine Liste allowed_tools und ein Feld out_of_scope. Ein Auftrag als Fließtext lädt dazu ein, genau das Feld wegzulassen, das im Fehlerfall gefehlt hat.

Kontext-Isolation ist Gewinn und Verlust zugleich

Die getrennten Fenster sind der Grund, warum das Muster funktioniert — und gleichzeitig der Grund für seine typischen Fehler. Ein Unteragent weiß nichts von den anderen: nicht, was sie gefunden haben, nicht, welche Annahme sie widerlegt haben, nicht, dass sie gescheitert sind.

Gewinn

Jeder Lauf bleibt klein und scharf. Kein Context Rot, keine Vermischung fremder Zwischenstände, keine gegenseitige Ablenkung.

Verlust

Erkenntnisse werden nicht geteilt. Was Agent zwei widerlegt hat, glaubt Agent vier weiterhin — und die Zusammenführung sieht zwei widersprüchliche Aussagen ohne Herkunft.

Zwischenweg

Ein gemeinsamer, vom führenden Agenten gepflegter Befundstand, den Unteragenten lesen dürfen. Kostet eine Runde je Zugriff und begrenzt die Parallelität.

Die dritte Zeile ist verlockend und untergräbt den Mechanismus: Je mehr geteilter Kontext, desto weniger Isolation — und damit weniger von dem, wofür man bezahlt hat. Wer feststellt, dass die Unteragenten viel voneinander wissen müssen, hat die Bestätigung, dass die Aufgabe nicht zerlegbar war.

Parallelität, wo sie echt ist

Zeitgewinn entsteht nur bei echter Unabhängigkeit. Zwei Prüfungen, die dieselbe Datenquelle lesen, sind parallel. Zwei Schritte, von denen einer den Zustand verändert, den der andere liest, sind es nicht — auch wenn sie technisch gleichzeitig starten.

• Lesend und unabhängig — der Regelfall für Parallelität. Hier zahlt sich das Muster unmittelbar aus.
• Schreibend auf getrennte Ziele — vertretbar, wenn die Ziele wirklich getrennt sind und keine gemeinsame Grenze teilen, etwa ein Kontingent.
• Schreibend auf dasselbe Ziel — keine Parallelität, sondern eine Wettlaufsituation. Gehört serialisiert, und zwar im Code, nicht per Absprache im Prompt.
• Gegen ein System mit Verbindungslimit — die Zahl gleichzeitiger Unteragenten ist dann eine Kapazitätsentscheidung des schwächsten Glieds, nicht des Orchestrators.

Fehler pflanzen sich fort, und Neustarts sind teuer

Ein Merkmal agentischer Systeme verschärft sich im Verbund: Was in klassischer Software ein kleines Problem wäre, kann einen Agenten vollständig entgleisen lassen — ein einzelner fehlgeschlagener Schritt führt dazu, dass er eine gänzlich andere Bahn einschlägt.

Die naheliegende Antwort — von vorn beginnen — ist im Multi-Agent-Fall besonders unattraktiv: Neustarts sind teuer und für Nutzende frustrierend. Bei fünfzehnfachem Tokenverbrauch bedeutet ein Neustart, den gesamten Einsatz erneut zu bezahlen, obwohl vier von fünf Unteragenten sauber geliefert haben.

Die Zusammenführung ist der schwierigste Teil

Der führende Agent steht am Ende vor einer Aufgabe, die niemand gern beschreibt: Er soll Ergebnisse bewerten, deren Zustandekommen er nicht gesehen hat. Er kennt weder die Quellenlage noch die Sicherheit, mit der ein Unteragent seine Aussage getroffen hat.

• Belege statt Behauptungen — jedes Teilergebnis führt seine Quelle mit, sonst ist keine Bewertung möglich.
• Sicherheit ausdrücklich — ein Feld dafür, wie belastbar ein Befund ist, statt einer gleichmäßig selbstbewussten Formulierung.
• Widersprüche als Ergebnis — zwei sich widersprechende Teilergebnisse werden benannt, nicht zu einem Mittelwert geglättet.
• Nichtgefundenes — als eigenes Feld, sonst ist eine Lücke von einem negativen Befund nicht unterscheidbar.

Die dritte Zeile ist die, die im Betrieb den Unterschied macht. Ein führender Agent, der widersprüchliche Teilergebnisse zu einer glatten Aussage verschmilzt, verwandelt genau das Signal, das ein Mensch gebraucht hätte, in eine überzeugend klingende Antwort.

Die Zusammenführung ist außerdem eine Kostenstelle, die in Überschlagsrechnungen regelmäßig fehlt. Fünf Teilergebnisse müssen vollständig in den Kontext des führenden Agenten, und zwar in seiner Schleife, die die Historie mitschleppt. Wer die Rückgaben nicht begrenzt, hat die Kontextgrenze nur verschoben: Der Engpass sitzt dann nicht mehr im Unteragenten, sondern in der Zusammenführung — an der Stelle, an der ein Abbruch am teuersten ist, weil alle Teilarbeit schon bezahlt wurde.

Bewerten, was man nicht nachvollziehen kann

Die Evaluation solcher Systeme folgt einer Reihenfolge, die der Intuition widerspricht: Man beginnt klein. Wenige, gut gewählte Anfragen machen die Wirkung einer Änderung deutlicher sichtbar als eine große Testmenge, in der Effekte sich gegenseitig überdecken.

Für die Bewertung selbst hat sich eine schlichte Form bewährt: ein einziger Prompt, der eine Punktzahl zwischen 0,0 und 1,0 und ein Bestanden-oder-nicht ausgibt. Diese Form erwies sich als am beständigsten und am nächsten an menschlichen Urteilen — bemerkenswert, weil aufwendigere Bewertungsschemata naheliegen.

Und ein Befund, den keine automatische Auswertung geliefert hätte: Menschliche Tester stellten fest, dass frühe Agenten durchgängig suchmaschinenoptimierte Inhaltsfarmen gegenüber verlässlichen, aber schlechter platzierten Quellen bevorzugten. Menschen finden Randfälle, die Auswertungen übersehen — das ist kein Übergangszustand, sondern eine dauerhafte Arbeitsteilung.

Für Multi-Agent-Systeme kommt eine zweite Messgröße hinzu, die bei Einzelagenten oft fehlen darf: die Kosten je Lauf als gleichrangiges Bewertungskriterium neben der Qualität. Weil der Tokenverbrauch den größten Teil der Leistungsunterschiede erklärt, ist eine Qualitätsverbesserung ohne Kostenangabe keine Aussage — sie könnte schlicht daher kommen, dass die neue Fassung mehr ausgibt.

Was der Check prüft

• Die Bestandteile eines Delegationsauftrags in die Reihenfolge bringen, in der sie voneinander abhängen.
• Echte Unabhängigkeit von scheinbarer Parallelität unterscheiden.
• Den fünfzehnfachen Einsatz gegen den erwarteten Gewinn rechnen — und den billigeren Weg prüfen.
• Einen unterspezifizierten Teilauftrag um die fehlende Grenze ergänzen.
• Erkennen, wann geteilter Kontext den Mechanismus untergräbt, für den man bezahlt.
• Eine Teilauftragsdefinition lesen und das Feld finden, dessen Fehlen Lücken unsichtbar macht.
• Einen Teilfehlschlag so behandeln, dass nicht der ganze Lauf erneut bezahlt wird.
• Widersprüchliche Teilergebnisse als Ergebnis behandeln statt sie zu glätten.
• Benennen, wann ein Workflow oder ein Einzelagent die bessere Wahl bleibt.

Der gemeinsame Nenner: Multi-Agent ist eine teure Architektur mit einem eng umrissenen Anwendungsbereich. Wer sie einsetzt, sollte benennen können, welches der vier Eignungskriterien in seinem Fall erfüllt ist — und was er tut, wenn keines davon zutrifft.