LLM-Agenten sind nur verteilte Systeme

Die KI-Community baut Multi-Agenten-Systeme: Teams aus LLMs, die Arbeit aufteilen, miteinander kommunizieren und zusammenarbeiten, um Probleme zu lösen, die kein einzelnes Modell bewältigen kann. Ein 'Researcher'-Agent sammelt Informationen, ein 'Coder'-Agent schreibt die Implementierung, ein 'Reviewer'-Agent prüft die Qualität, ein 'Coordinator'-Agent steuert den Workflow. Das Versprechen klingt verlockend: spezialisierte Agenten, die wie ein gut geführtes Engineering-Team zusammenarbeiten.

Das sollte bekannt vorkommen. Forscher für verteilte Systeme untersuchen seit 40 Jahren, wie sich unabhängige Prozesse koordinieren lassen. Multi-Agenten-LLM-Systeme entdecken gerade Probleme von Grund auf neu, die die Community für verteilte Systeme vor Jahrzehnten gelöst (oder als unlösbar bewiesen) hat. Diese Parallelen zu verstehen, erspart dir, Lösungen neu zu erfinden, und den Bau von Systemen, die auf vorhersehbare, gut verstandene Weise scheitern.

Die Koordinationssteuer

Die erste Lektion aus verteilten Systemen: Koordination kostet Aufwand. Zwei Prozesse, die unabhängig voneinander an getrennten Aufgaben arbeiten, sind doppelt so schnell wie einer. Zwei Prozesse, die an derselben Aufgabe arbeiten und sich abstimmen müssen, sind oft langsamer als einer, weil der Aufwand für Kommunikation und Synchronisation den Vorteil der Parallelität übersteigt.

Multi-Agenten-LLM-Systeme stoßen sofort darauf. Ein 'Researcher'-Agent erstellt einen Bericht. Der 'Coder'-Agent muss den Bericht verstehen, um Code zu schreiben. Der 'Reviewer'-Agent braucht sowohl den Bericht als auch den Code, um sinnvolles Feedback zu geben. Jede Übergabe erfordert, den Kontext in einen Prompt zu serialisieren, den der empfangende Agent parsen und verstehen muss. Das ist genau das Problem des geteilten Zustands aus verteilten Systemen, und es wird schlimmer, je mehr Agenten du hinzufügst.

Single agent vs. multi-agent for a coding task:
Single agent:
1. Understand the problem         (1 LLM call)
2. Research relevant APIs          (2 LLM calls)
3. Write implementation            (1 LLM call)
4. Review and fix                  (1 LLM call)
Total: 5 LLM calls, full context throughout
Multi-agent (researcher + coder + reviewer):
1. Coordinator describes task      (1 LLM call)
2. Researcher reads and plans      (1 LLM call)
3. Researcher does research        (3 LLM calls)
4. Researcher summarizes findings  (1 LLM call)
5. Coder reads summary             (1 LLM call)  ← context lost here
6. Coder writes implementation     (1 LLM call)
7. Reviewer reads code + summary   (1 LLM call)  ← context lost here
8. Reviewer provides feedback      (1 LLM call)
9. Coordinator synthesizes         (1 LLM call)
Total: 11 LLM calls, context degraded at each handoff
More agents = more communication = more cost = worse context.

In verteilten Systemen ist das Amdahls Gesetz, angewendet auf die Kommunikation: Der Geschwindigkeitsgewinn durch Parallelisierung ist durch die sequenzielle Kommunikation begrenzt, die sich nicht parallelisieren lässt. Mehr Agenten für eine Aufgabe hinzuzufügen, die eng abgestimmt werden muss, macht das System langsamer, nicht schneller.

Das Konsensproblem

Wenn mehrere Agenten an derselben Aufgabe arbeiten, müssen sie sich über einige Dinge einig werden. Was sind die Anforderungen? Welchen Ansatz verfolgen wir? Ist diese Implementierung korrekt? In verteilten Systemen ist das das Konsensproblem, und es ist nachweislich schwer. Das FLP-Unmöglichkeitsergebnis zeigt, dass deterministischer Konsens in einem asynchronen System mit auch nur einem fehlerhaften Prozess unmöglich ist.

LLM-Agenten sind für Konsens schlechter geeignet als klassische verteilte Prozesse, weil sie nicht deterministisch arbeiten. Stellst du demselben Agenten zweimal dieselbe Frage, bekommst du womöglich unterschiedliche Antworten. Zwei Agenten, die denselben Code prüfen, können sich uneinig sein, ob er korrekt ist. Ein 'Coordinator'-Agent, der den Streit schlichten soll, könnte im Zweifel einfach eine Münze werfen.

Multi-Agenten-Frameworks lösen das meist, indem sie einen Coordinator-Agenten mit letzter Entscheidungsbefugnis bestimmen (ein zentralisiertes Konsensmodell, einfach, schafft aber einen Single Point of Failure) oder indem sie per Mehrheitsentscheid abstimmen lassen (teuer, du brauchst mindestens drei Agenten pro Entscheidung). Beide Ansätze funktionieren, aber sie lösen ein Problem, das nur deshalb existiert, weil du die Arbeit überhaupt auf mehrere Agenten verteilt hast.

Fehlermuster, die dir bekannt vorkommen sollten

Multi-Agenten-Systeme scheitern auf Arten, die Ingenieure für verteilte Systeme sofort wiedererkennen werden.

• Kaskadierende Ausfälle. Agent A liefert fehlerhafte Ausgaben. Agent B arbeitet auf Basis von A's Ergebnis und produziert noch schlechtere Ausgaben. Agent C, der B's Arbeit prüft, findet den ursprünglichen Fehler nicht, weil er die falschen Annahmen übernommen hat. Das ist das Pendant zur Fehlerausbreitung in verteilten Systemen: Müll rein, Müll raus, mit jeder Stufe verstärkt.
• Deadlocks. Agent A wartet auf die Ausgabe von Agent B, um weitermachen zu können. Agent B wartet auf Feedback von Agent A. Keiner kommt voran. In der Praxis zeigt sich das als Endlosschleifen, in denen Agenten Aufgaben hin- und herreichen, ohne jemals zu einem Ergebnis zu konvergieren.
• Split Brain. Zwei Agenten, die an verwandten Aufgaben arbeiten, entwickeln inkonsistente Vorstellungen vom Problem. Einer geht davon aus, dass die API JSON liefert, der andere erwartet XML. Ihre Ausgaben sind jeweils für sich korrekt, aber untereinander inkompatibel.
• Thundering Herd. Ein Coordinator-Agent verteilt Arbeit gleichzeitig an mehrere Agenten. Alle treffen dieselbe API, erschöpfen dasselbe Rate-Limit oder versuchen, dieselbe Datei zu ändern. Ressourcenkonflikte, mit denen ein einzelner Agent nie konfrontiert wäre.

Wann Multi-Agenten wirklich helfen

Die Parallele zu verteilten Systemen wirkt in beide Richtungen. Verteilte Systeme bringen für bestimmte Probleme echte Vorteile. Multi-Agenten-Systeme auch, wenn sie für Probleme eingesetzt werden, die tatsächlich von einer Zerlegung profitieren.

Peinlich parallele Aufgaben. Wenn du 50 Codebasen auf dasselbe Muster untersuchen musst, sind 50 unabhängig arbeitende Agenten tatsächlich 50-mal schneller. Keine Koordination nötig: Jeder Agent bearbeitet eine separate Eingabe und liefert eine eigenständige Ausgabe. Das ist das MapReduce-Muster, und es funktioniert für LLM-Agenten genauso gut wie für verteilte Datenverarbeitung.

Unterschiedliche Perspektiven. Wenn du drei Agenten mit verschiedenen System-Prompts denselben Code prüfen lässt, können sie Probleme aufdecken, die ein einzelnes Review übersieht. Das ist das Redundanz-Muster, wie mehrere Reviewer bei einem Pull Request. Der Preis sind dreifache Rechenkosten, dafür ist die Abdeckung breiter.

Spezialisierung mit sauberen Schnittstellen. Ein Übersetzungs-Agent, der Text entgegennimmt und übersetzten Text zurückgibt, hat eine saubere Schnittstelle. Ein Zusammenfassungs-Agent, der ein Dokument entgegennimmt und eine Zusammenfassung zurückgibt, ebenso. Diese zu kombinieren, erst übersetzen und dann zusammenfassen, funktioniert gut, weil die Schnittstelle dazwischen einfach ist. Das Pendant aus verteilten Systemen: Microservices mit klar definierten APIs funktionieren besser als Microservices mit geschwätzigen, komplexen Schnittstellen.

Lektionen aus verteilten Systemen

Wenn du Multi-Agenten-LLM-Systeme baust, gilt das jahrzehntealte Wissen aus verteilten Systemen direkt.

1. Lieber wenige, leistungsfähigere Agenten als viele spezialisierte. So wie ein gut entworfener Monolith eine schlecht entworfene Microservice-Architektur schlägt, übertrifft ein einzelner fähiger Agent mit gutem Prompting bei den meisten Aufgaben ein Team aus engen Spezialisten. Füge Agenten nur hinzu, wenn du belegt hast, dass ein einzelner Agent die Last nicht bewältigt.
2. Definiere klare Schnittstellen zwischen Agenten. Ein- und Ausgabe jedes Agenten sollten klar definiert sein. Vage Übergaben ('finde heraus, was der Researcher herausgefunden hat, und implementiere es') führen zu Kontextverlust und Missverständnissen. Strukturierte Datenverträge zwischen Agenten funktionieren besser als Freitext.
3. Mach Agenten idempotent. Scheitert ein Agent mittendrin, solltest du ihn mit derselben Eingabe neu starten und ein korrektes Ergebnis erhalten können. Dafür brauchst du Agenten ohne versteckten Zustand, die keine Seiteneffekte auslösen, bevor sie bestätigt haben, dass ihre Ausgabe stimmt.
4. Baue Observability ein. Protokolliere jede Nachricht zwischen Agenten, jede Entscheidung und jeden Fehler. Wenn ein Multi-Agenten-System falsche Ergebnisse liefert, musst du den Fehler bis zu dem Agenten zurückverfolgen können, der die falsche Entscheidung getroffen hat, und bis zu dem Grund dafür. Ohne Observability ist Debugging Raterei.
5. Plane für Teilausfälle. Jeder Agent kann ausfallen, Müll produzieren oder ein Timeout haben. Das System sollte damit sauber umgehen: erneut versuchen, auf einen einfacheren Ansatz zurückfallen oder einen Menschen fragen. Geh niemals davon aus, dass alle Agenten erfolgreich arbeiten.

Die unbequeme Wahrheit

Die meisten Multi-Agenten-LLM-Systeme würden mit einem einzelnen Agenten und einem guten Prompt besser funktionieren. Der Koordinationsaufwand, der Kontextverlust und die Fehlermuster von Multi-Agenten-Architekturen überwiegen bei Aufgaben, die ein einzelnes Modell bewältigen kann, fast immer den Nutzen. Mit der Weiterentwicklung der KI-Werkzeuge wächst die Versuchung, aufwendige Multi-Agenten-Systeme zu bauen, aber die Lektion aus verteilten Systemen ist eindeutig: Verteile nicht, was nicht verteilt werden muss.

Die Ausnahmen sind real: peinlich parallele Aufgaben, echte Spezialisierung mit sauberen Schnittstellen und Probleme, die das Kontextfenster eines einzelnen Modells sprengen. Für alles andere wird ein einzelner Agent mit gut strukturiertem Prompt, guten Werkzeugen und einer durchdachten Retry-Strategie ein Agententeam übertreffen. Das ist architektonisch weniger spannend, funktioniert aber besser. Das beste verteilte System ist das, das du nicht bauen musstest.