Pipeline, Fan-out, Orchestrator und Kritikergremium: welches Multi-Agenten-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 Schritte selbst 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 vorherige Ausgabe 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 läuft, 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 Leitagenten, der Subagenten koordiniert, die parallel mit eigenen Kontextfenstern arbeiten, und hält fest, dass sich solche Systeme 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änenspezifischen Prompts und Tools) und Eskalation (Beiziehen eines leistungsfähigeren Modells für schwierige Teilaufgaben).

Warum es wichtig ist

Jedes Muster vervielfacht Aufrufe und Tokens und fügt eine Schicht hinzu (den Orchestrator, den Aggregator, die Gremiumsleitung), die auf eine Weise falsch liegen kann, die bei einem einzelnen Worker nicht vorkommt. Die Form anhand der Struktur der Aufgabe zu wählen, sorgt dafür, dass sich die Vervielfachung auch lohnt.

So wird es angewendet

• Pipeline: Die Schritte sind im Voraus bekannt, und jeder liefert ein prüfbares Zwischenergebnis (extrahieren, validieren, übersetzen). Die Prüfungen als Code zwischen die Schritte legen.
• 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 ist schwer zu verifizieren, aber leicht zu vergleichen (Klassifikation, Kennzeichnung); 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 die Delegationsvorgabe investieren; der zitierte Recherche-Beitrag führt doppelte Arbeit und Lücken auf dünne Aufgabenbeschreibungen zurück.
• Kritikergremium: Das Ergebnis muss mehrere unterschiedliche Kriterien erfüllen (Sicherheit, Stil, Korrektheit); jedem Kritiker ein Kriterium und eine feste Bewertungsvorlage geben und die Zusammenführung per Code erledigen lassen.
• Mit einem Agenten und einem guten Prompt beginnen; ein Muster erst hinzufügen, wenn ein gemessener Fehlschlag (Kontextüberlauf, lückenhafte Abdeckung, einseitige Prüfung) darauf hindeutet.

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 selbst erledigen. Kostenrechnung, die nur den letzten Aufruf zählt.