Pipeline, Fan-out, Orchestrator und Kritiker-Panel: Welches Multi-Agent-Muster zu welcher Aufgabe passt

Worum es geht

Anthropics Engineering-Leitfaden zum Bau von Agenten unterscheidet Workflows, bei denen Code die Abfolge der Modellaufrufe festlegt, von Agenten, bei denen das Modell seine eigenen Schritte steuert, und nennt fünf Workflow-Muster; vier davon kombinieren mehrere Aufrufe (das fünfte, Routing, leitet eine Eingabe auf einen einzelnen spezialisierten Pfad). Prompt Chaining: eine Pipeline, in der jeder Aufruf die Ausgabe des vorherigen verarbeitet, mit programmatischen Prüfungen zwischen den Schritten. Parallelisierung in zwei Varianten: Sectioning, bei dem unabhängige Teilaufgaben gleichzeitig laufen, und Voting, bei dem dieselbe Aufgabe mehrfach ausgeführt wird, um unterschiedliche Ausgaben zu erhalten. Orchestrator-Worker: Ein zentrales Modell zerlegt die Aufgabe zur Laufzeit, delegiert und fasst die Ergebnisse zusammen. Evaluator-Optimizer: Ein Aufruf erzeugt, ein anderer bewertet in einer Schleife. Ein separater Anthropic-Engineering-Beitrag zu seinem Recherchesystem beschreibt ein Orchestrator-Worker-Muster mit einem Lead Agent, der Subagenten koordiniert, die parallel mit eigenen Kontextfenstern arbeiten, und hält fest, dass solche Systeme sich für Breadth-first-Anfragen eignen, die mehrere unabhängige Richtungen gleichzeitig verfolgen. Die Dokumentation zu Managed Agents nennt drei Muster, die sich bewähren: Parallelisierung, Spezialisierung (Routing an Agenten mit domänenfokussierten Prompts und Werkzeugen) und Eskalation (Hinzuziehen eines leistungsfähigeren Modells für schwierige Teilaufgaben).

Warum es wichtig ist

Jedes Muster vervielfacht Aufrufe und Tokens und fügt eine zusätzliche Ebene hinzu (den Orchestrator, den Aggregator, die leitende Instanz des Panels), die auf eine Weise falschliegen kann, wie es kein einzelner Worker kann. Wird die Form nach der Struktur der Aufgabe gewählt, bleibt die Vervielfachung dort, wo sie tatsächlich etwas bringt.

So wird es angewendet

• Pipeline: Die Schritte sind im Voraus bekannt, und jeder liefert eine prüfbare Zwischenausgabe (extrahieren, validieren, übersetzen). Die Prüfungen gehören als Code zwischen die Schritte.
• Fan-out per Sectioning: Die Teilfragen sind unabhängig, und ihre Antworten lassen sich durch Aneinanderreihen oder eine einfache Regel zusammenführen (eine Datei oder eine Quelle pro Worker). Das Ausgabeformat zuerst festlegen, damit das Zusammenführen mechanisch bleibt.
• Fan-out per Voting: Die Korrektheit lässt sich schwer verifizieren, aber leicht vergleichen (Klassifizierung, Markierung); eine ungerade Anzahl verwenden und Uneinigkeit als Signal festhalten, nicht als Rauschen.
• Orchestrator-Worker: Die Zerlegung hängt davon ab, was unterwegs gefunden wird (Recherche, Debugging in einer unbekannten Codebasis). In den Delegationsauftrag investieren; der zitierte Recherchebeitrag führt doppelte Arbeit und Lücken auf dünne Aufgabenbeschreibungen zurück.
• Kritiker-Panel: Die Ausgabe muss mehrere unterschiedliche Kriterien erfüllen (Sicherheit, Stil, Korrektheit); jeder kritisierenden Instanz ein Kriterium und eine feste Bewertungsvorlage geben und die Zusammenführung per Code erledigen lassen.
• Mit einem einzelnen Agenten und einem guten Prompt beginnen; ein Muster erst hinzufügen, wenn ein gemessenes Versagen (Kontextüberlauf, fehlende Abdeckung, einseitige Prüfung) darauf hinweist.

Stolpersteine

Worker, die sich einen Kontext teilen und dadurch auch einen Fehler teilen. Zusammenführung durch einen Modellaufruf, der das Ergebnis eines Workers stillschweigend verwirft. Orchestratoren, die die Arbeit der Worker noch einmal erledigen. Kostenrechnung, die nur den letzten Aufruf zählt.