Zum Inhalt springen
Alle Beiträge
·2 Min. Lesezeit

Orchestrierung vs. Emergenz: Wann Multi-Agenten-Systeme scheitern

Agentic SystemsMulti-Agent ArchitectureSystem Design

Wir haben Mycellium (ein orchestratorfreies Multi-Agenten-System) über ein Semester an der TUM gebaut. Davor hatte ich Zeit in orchestrierten Systemen bei Allianz und BCG verbracht. Beide scheitern. Nur auf unterschiedliche Weise.

Die Standardarchitektur ist Orchestrierung: Ein Koordinator zerlegt die Aufgabe, verteilt die Arbeit, sammelt die Ergebnisse ein und entscheidet, was wahr ist. Das ist klar, das ist nachvollziehbar, und es ist auch von Natur aus ein Engpass. Der Koordinator muss klug genug sein, um das gesamte Problem im Voraus korrekt zu zerlegen. Geht das schief, erbt jeder nachgelagerte Agent den Fehler — und das mit vollem Selbstvertrauen.

Emergente Systeme drehen das um. Agenten organisieren sich selbst, konvergieren über so etwas wie Konsens auf eine Antwort, und kein einzelner Knoten "hat das Sagen". Das klingt besser — bis zu dem Moment, in dem etwas schiefgeht. Ein defekter Orchestrator lässt sich immerhin leicht befragen: Man kann auf den Schritt zeigen, der fehlgeschlagen ist. Ein emergentes System, das still auf eine falsche Antwort konvergiert, ist deutlich schwerer zu debuggen, weil es keine einzelne Entscheidung gibt, auf die man zurückverfolgen kann.

Die Unterscheidung, auf die es in der Praxis wirklich ankommt

Orchestrierung einsetzen, wenn die Aufgabe eine natürliche Hierarchie hat (erst Schritt 1, dann 2, dann 3) und jeder Schritt unabhängig verifizierbar ist. Datenvalidierungs-Pipelines, Content-Moderation-Workflows, alles, bei dem die Form der Lösung im Voraus bekannt ist.

Emergenz einsetzen, wenn sich das Problem zwar zerlegen lässt, die richtige Zerlegung aber im Voraus nicht bekannt ist: offene Forschungsaufgaben oder kreative Probleme, bei denen Agenten tatsächlich in Threads abschweifen sollen, die man nicht vorhergesehen hat.

Worüber niemand spricht

Beide Architekturen scheitern ohne ernsthafte Investition in Observability. Orchestrierung liefert Logs quasi umsonst. Emergenz liefert nichts umsonst: Das Replay muss man sich selbst bauen. Wir haben für Mycellium ein Schritt-für-Schritt-Replay-Tool gebaut, noch bevor die Architektur selbst produktionsreif war, und am Ende war dieses Tool wichtiger als das Design, das es untersuchte.

Die Lektion, die ich mit zu BCG genommen habe: aufhören, Orchestrierung gegen Emergenz zu diskutieren, als wäre es eine philosophische Grundsatzfrage. Das System bauen und dann ernsthaft Aufwand in seine Nachvollziehbarkeit investieren. Ein transparenter Orchestrator schlägt ein undurchsichtiges emergentes System jedes Mal — nicht weil Orchestrierung besser ist, sondern weil man nichts vertrauen kann, was man nicht sehen kann.

Mehr Details zum Mycellium-Projekt: Mycellium: Orchestratorfreies Multi-Agenten-Schwarmsystem

Mohamed Nejjar , M.Sc.-Student der Informatik (ML) an der TUM und Werkstudent bei BCG Platinion. Publizierter Forscher, 200+ Zitationen in der LLM-Forschung.

Arbeiten Sie an einem ähnlichen Problem oder haben Sie Gedanken zu diesem Beitrag?

Diese Website kann datenschutzfreundliche Analysen nutzen, um die Qualität der Inhalte zu verbessern. Es werden keine Werbe-Cookies verwendet.

Sie können dies jederzeit auf der Datenschutzseite ändern. Weitere Informationen finden Sie in der Datenschutzerklärung.