Was ist Multi-Agent? Architekturmuster, Frameworks und Kosten von KI-Agenten-Teams (2026)

Im Jahr 2026 hat sich die Diskussion rund um KI-Agenten von „einem Super-Agenten, der alles erledigt" zu „einem Team von Agenten mit unterschiedlichen Rollen" verlagert. Das Research-Feature von Anthropic, die Subagenten von Claude Code, Devins Engineering-Team, die parallelen Worker von Cursor — sie alle basieren auf einer Architektur, die mehrere KIs koordiniert.

Dieser Artikel beginnt bei der Definition, was ein Multi-Agenten-System eigentlich ist, und führt dann durch die wichtigsten Architekturmuster, einen Vergleich produktionsreifer Frameworks, reale Beispiele, die Kostenstruktur und schließlich, wann Sie eines einsetzen sollten und wann nicht — alles auf Basis aktueller Quellen. Lassen Sie die Fantasie „einfach Multi nehmen, dann wird es schon schlauer" hinter sich und nehmen Sie eine echte Grundlage für Designentscheidungen mit.

1. Was ist ein Multi-Agenten-System?

Ein Multi-Agenten-System (MAS) ist eine Architektur, in der mehrere KI-Agenten kooperieren, um eine einzelne Aufgabe zu lösen. Jeder Agent verfügt über einen eigenen Prompt, eigene Werkzeuge und einen eigenen Kontext, und sie tauschen Nachrichten und Ergebnisse aus, um ein gemeinsames Ziel zu erreichen.

Die Basis „Single Agent" — behandelt in unserem Artikel zum KI-Agenten — ist eine Entität, die die Schleife „wahrnehmen → schlussfolgern → handeln → beobachten" allein durchläuft. Am klarsten lässt sich ein Multi-Agenten-System so verstehen: nehmen Sie das, und ergänzen Sie Rollenspezialisierung und Parallelität.

Wie es sich von einem Single Agent unterscheidet

2. Warum überhaupt mehrere KIs orchestrieren?

Die Ausgangsposition lautet: „Wenn ein Agent alles schafft, lass ihn in Ruhe." Multi-Agent wird durch drei strukturelle Mauern notwendig, an denen ein einzelner Agent kaum vorbeikommt.

Multi-Agent überwindet diese Mauern mit einem Dreierset: „Kontextisolation × Parallelisierung × Rollenspezialisierung." Anthropics Research-Feature ist das Lehrbuchbeispiel — ein Lead-Researcher plant die Arbeit, mehrere Subagenten untersuchen verschiedene Aspekte parallel, und die Ergebnisse werden aggregiert. Anthropic berichtet, dass dies eine Qualitätsverbesserung von rund 90 % gegenüber der Single-Agent-Version brachte.

3. Fünf zentrale Architekturmuster

Multi-Agent-Designs gibt es in einer Handvoll „Formen". Die Namen unterscheiden sich je nach Framework, aber im Kern laufen sie auf diese fünf Muster hinaus.

3-1. Orchestrator-Worker (das häufigste)

Ein „Dirigent (Orchestrator / Lead-Agent)" zerlegt die Aufgabe und verteilt die Teile parallel an mehrere „Worker (Subagenten)". Jeder Worker läuft in seinem eigenen Kontext und liefert sein Ergebnis an den Orchestrator zurück, der sie zur endgültigen Ausgabe aggregiert.

Eingesetzt von: Anthropic Research, Claude Code Subagenten, das Standard-Setup im OpenAI Agents SDK.

3-2. Handoff (die OpenAI-Swarm-Linie)

Agenten geben einander explizit die Kontrolle mit einem „du bist dran". Konversationsverlauf und Kontext wandern von Hand zu Hand. Strukturell ähnelt es einem Ticket, das zwischen Bearbeitern weitergereicht wird, und passt zu Szenarien wie dem Eskalationsfluss eines Support-Desks.

Eingesetzt von: OpenAI Agents SDK (der Nachfolger des alten Swarm).

3-3. Hierarchisch (Teams aus Teams)

Eine Baumstruktur: unter dem Orchestrator sitzt eine zusätzliche Schicht „mittlerer Manager"-Agenten, und darunter eine Gruppe von Workern. Sie taucht in großen Systemen auf — Cognitions Devin nutzt Berichten zufolge dieses Muster. Kosten und Latenz wachsen mit der Tiefe, daher sind zwei oder drei Schichten die realistische Obergrenze.

3-4. Peer-to-Peer (Debatte und Konsens)

Kein Orchestrator — mehrere Agenten diskutieren als Gleichgestellte und iterieren, bis sie einen Konsens erreichen. Erforscht als Multi-Agent Debate und Berichten zufolge verbessert es Faktentreue und Robustheit der Schlussfolgerungen. Die Implementierung ist nicht trivial, daher ist die praktische Verbreitung noch gering.

3-5. Pipeline (die Workflow-Form)

Jeder Agent läuft in einer festen Reihenfolge wie „recherchieren → strukturieren → verifizieren → ausgeben". Das ist LangGraphs Heimspiel mit seinem graphbasierten Modell. Es opfert dynamische Entscheidungsfindung, belohnt Sie aber mit Reproduzierbarkeit und einfacherem Debugging — und ist in der Produktion oft die stabilste Form.

4. Die wichtigsten Frameworks im Vergleich

Bis 2026 hat sich die Multi-Agent-Entwicklung um vier Frameworks konsolidiert (der Long-Tail kleiner Frameworks ist ausgedünnt).

In der Produktion sind Claude Agent SDK, OpenAI Agents SDK, LangGraph und Strands die großen Vier. CrewAI und AutoGen eignen sich gut zum Lernen und für PoCs, aber Enterprise-Produktionseinsätze konzentrieren sich auf die ersten vier.

5. Was tatsächlich in Produktion läuft

Anthropic Research (innerhalb von Claude.ai)

Das Research-Feature von Claude.ai ist ein Lehrbuch-Orchestrator-Worker. Der Lead-Researcher zerlegt die Frage des Nutzers, mehrere Subagenten untersuchen verschiedene Aspekte parallel (Unternehmensinformationen, Zeitachsen, technische Details usw.), und die Ergebnisse werden zu einem Bericht aggregiert. Anthropic hat die Details in seinem Engineering-Blog veröffentlicht und meldet eine Genauigkeitsverbesserung von rund 90 % gegenüber der Single-Agent-Version.

Claude Code Subagenten

In Claude Code können Sie länger laufende Aufgaben an Subagenten mit unterschiedlichen Rollen übergeben. Beispiel: der Haupt-Claude legt den Plan fest, ein Recherche-Subagent liest mehrere Dateien parallel, und ein Implementierungs-Subagent schreibt den Patch. Jeder Subagent hat sein eigenes Kontextfenster, sodass er den Hauptkontext nicht überfüllt.

Devin (Cognition)

Cognitions autonomer Engineer Devin nutzt Berichten zufolge eine hierarchische Multi-Agent-Struktur. Unterhalb eines elternartigen Projektmanager-Agenten laufen Spezialistenteams parallel pro Domäne. Diese Tiefe wird benötigt, um komplexe PRs und Migrationsarbeiten end-to-end zu erledigen.

Cursors parallele Worker

Ein kürzliches Cursor-Update hat die Fähigkeit gestärkt, Änderungen, die mehrere Dateien betreffen, auf parallele Subagenten aufzuteilen. Statt dass ein Agent Dateien nacheinander bearbeitet, arbeiten separate Agenten Seite an Seite an unterschiedlichen Bereichen.

6. Kosten und Trade-offs — die 15-fache Token-Realität

Bevor Sie sich auf „Multi heißt schlauer" einlassen, müssen Sie die Kostenstruktur verstehen. Anthropics eigener Bericht besagt, dass ein Multi-Agenten-System rund 15-mal mehr Tokens verbrennt als eine standardmäßige Chat-Sitzung.

Multi-Agent rechtfertigt sich nur für „Aufgaben, bei denen der Wert des Ergebnisses die Kosten wert ist". In Anthropics Worten: der vorgesehene Anwendungsfall sind „komplexe Recherche-Aufgaben, bei denen der Output-Wert hoch im Verhältnis zu den Kosten ist."

7. Wann einsetzen, wann nicht

Fälle, die nach Multi-Agent rufen

• Parallelrecherche: „untersuche zehn Websites gleichzeitig und berichte", „triff mehrere APIs parallel an und führe sie zusammen" — alles, wo Parallelität direkten Mehrwert schafft
• Lang laufende autonome Aufgaben: Workloads, die das Kontextfenster einer einzelnen Sitzung sprengen. Ohne Rollentrennung tötet Kontextverunreinigung die Genauigkeit
• Heterogene Spezialisierung: Wenn ein Agent sowohl „Code schreiben" als auch „Code reviewen" macht, wird sein kritischer Blick stumpf. Eine Rollentrennung hebt die Qualität direkt an
• Einmalige Aufgaben mit hohem Geschäftswert: Audit-Berichte, strategische Analysen, komplexe technische Untersuchungen — Outputs, die die Kosten rechtfertigen

Fälle, in denen Sie es nicht tun sollten

• Klare, sequenzielle Aufgaben: „behebe diesen Code", „fasse dieses Dokument zusammen" — Arbeit, die ein einzelner Agent normalerweise erledigt
• Latenzempfindliche Dienste: erste Chatbot-Antworten, Kundensupport — überall dort, wo schnelle Reaktion gefragt ist
• Kostensensitive Batch-Jobs: hochvolumige, repetitive Arbeit. Multi-Agent multipliziert die Stückkosten mit dem Multiplikator und die Rechnung kippt
• Teams ohne ausreichende Debugging- und Ops-Kapazität: Komplexität wächst exponentiell mit Multi-Agent. Wenn Ihr Team das nicht stemmen kann, beginnen Sie mit Single

Das Branchen-Mantra lautet „Beginnen Sie mit einem Agenten, fügen Sie weitere nur hinzu, wenn Sie einen klaren Grund haben." Das ist 2026 der Konsens unter Produktionsingenieuren.

8. Best Practices für das Design

Wenn Sie sich für Multi-Agent entschieden haben, hier die Stellen, an denen Designer stolpern — überwiegend destilliert aus Anthropics veröffentlichtem Material.

1. Übergeben Sie Subagenten ein explizites „Ziel, Ausgabeformat, Werkzeuge und Grenzen"

Die meisten Subagenten-Fehler haben die Form „vage Anweisungen führten dazu, dass er in eine andere Aufgabe abdriftete" oder „Outputs hatten kein gemeinsames Format und konnten nicht aggregiert werden". Anthropics Empfehlung: Geben Sie jedem Subagenten (1) ein klares Ziel, (2) das erwartete Ausgabeformat, (3) die Werkzeuge und Informationsquellen, die er nutzen darf, und (4) die Grenzen seiner Aufgabe.

2. Machen Sie das „Anstrengungsniveau" explizit

Subagenten sind schlecht darin, eigenständig zu entscheiden, „wie tief sie gehen". Backen Sie die Anstrengungsstufe in den Prompt — „One-Hop-Untersuchung", „erschöpfende Verifikation", „nur aus bekannten Informationen schließen". Claude Opus 4.7s xhigh und task budgets (beta) sind genau die offizielle Antwort auf dieses Problem.

3. Geben Sie dem Orchestrator den Job „Aggregation und Konfliktlösung"

Subagenten-Ergebnisse können einander widersprechen (z. B. denselben Sachverhalt aus verschiedenen Blickwinkeln berichten). Die Hälfte der Aufgabe des Orchestrators besteht darin, „die Widersprüche aufzulösen und zu einer einzigen kohärenten Antwort zu konsolidieren". Sparen Sie an der Aggregationslogik, und der Gewinn von Multi verschwindet.

4. Bauen Sie zuerst Observability auf

Multi-Agenten-Systeme kollabieren in dem Moment, in dem Sie nicht mehr erkennen können, was vor sich geht. Loggen Sie von Tag eins an Input/Output, Laufzeit, Tokenverbrauch und Tool-Aufrufe jedes Subagenten. LangGraph und Strands sind mit Blick auf Observability entworfen, und das ist einer der Gründe, warum sie in der Produktion gewinnen.

5. Beginnen Sie mit Single, splitten Sie nur an den Engpässen

Designen Sie nicht von Anfang an als Multi. Bringen Sie es zuerst als Single Agent zum Laufen, und schneiden Sie einen Subagenten erst an den Stellen heraus, die Sie klar als Mauer identifiziert haben. Gleiche Denkweise wie beim Refactoring — das reicht.

Zusammenfassung

• Multi-Agent ist eine Architektur, in der „mehrere KIs mit aufgeteilten Rollen parallel arbeiten". Sie überwindet die drei Single-Agent-Mauern Kontextverunreinigung, fehlende Parallelität und Rollenvermischung
• Die Kernmuster sind fünf: Orchestrator-Worker, Handoff, hierarchisch, Peer-to-Peer und Pipeline. Orchestrator-Worker ist mit Abstand das häufigste
• Die wichtigsten Frameworks haben sich auf eine Big Four konsolidiert: Claude Agent SDK, OpenAI Agents SDK, LangGraph und Strands
• Die Kosten liegen beim 2- bis 15-fachen. Die Latenz steigt um 30 bis 50 %. Leichtfertig danach zu greifen ist wirtschaftlich falsch
• Entscheidungsregel: Wenn Parallelität, Spezialisierung oder lang laufende Arbeit harte Anforderungen sind, gehen Sie auf Multi. Sonst genügt Single
• Designregel: Beginnen Sie mit Single, splitten Sie nur an den Engpässen, sobald Sie sie sehen

FAQ

Q1. Ist Multi-Agent immer besser als ein „schlauerer Single Agent"?

Nein. Anthropics Research erzielte eine Genauigkeitsverbesserung von ~90 %, aber das war innerhalb seines Sweet Spots „komplexe Parallelrecherche". Für klare, sequenzielle Aufgaben ist ein einzelner Agent schneller, günstiger und mindestens ebenso gut. Es kommt auf die Art der Aufgabe an.

Q2. Wenn ich selbst ein Multi-Agenten-System bauen will, mit welchem Framework sollte ich beginnen?

Hängt vom Anwendungsfall ab. Sie nutzen Claude? Beginnen Sie mit dem Claude Agent SDK (offiziell, mit Subagenten + Hooks). OpenAI-zentriert? Agents SDK. Müssen Sie komplexe Verzweigungslogik abbilden? LangGraph. Produktionsbetrieb auf AWS? Strands. Zum Lernen ist CrewAI gut, um die Konzepte zu erfassen.

Q3. Kann man von Single zu Multi schrittweise migrieren?

Ja, und die meisten Produktionssysteme machen genau das. Bauen Sie das MVP als Single Agent, und schneiden Sie Subagenten erst dort heraus, wo Sie tatsächlich an Kontextfenster-Limits, Latenzprobleme oder Spezialisierungsbedarfe gestoßen sind. Das gesamte System von Anfang an als Multi zu designen, ist nicht empfohlen.

Q4. Gibt es ein Standard-Kommunikationsprotokoll zwischen Agenten?

Stand 2026 wird MCP (Model Context Protocol) zum De-facto-Standard. Es entstand bei Anthropic und wird inzwischen von OpenAI, Microsoft, AWS und anderen übernommen. Es wird sowohl zwischen Agenten als auch zwischen Agenten und Werkzeugen weit verbreitet als gemeinsame Schnittstelle eingesetzt. Es gibt auch einen Standardisierungsvorschlag namens ACP (Agent Communication Protocol), aber Implementierungen sind noch wenige.

Q5. Was ist der häufigste Multi-Agent-Fehlermodus?

(1) Mangelnde Observability (man kann nicht erkennen, was passiert), (2) Subagenten-Anweisungen sind zu vage, um die Ergebnisse zu aggregieren, und (3) Kostenexplosion. Insbesondere (3): Ein Subagent gerät in eine Schleife, hämmert die ganze Nacht auf die API ein, und die Cloud-Rechnung springt über Nacht um eine Größenordnung — solche Unfälle sind erstaunlich häufig. Setzen Sie immer Task Budgets (Kosten- und Zeitobergrenzen).

Q6. Ist Multi-Agent ein Weg in Richtung AGI (allgemeine KI)?

Forscher sind geteilter Meinung. Ein Lager argumentiert „Rollenspezialisierung und Koordination sind das Wesen der Intelligenz"; das andere hält dagegen „die Skalierung eines einzelnen Modells ist das Wesen — Multi-Agent ist nur ein technischer Workaround". Beides ist plausibel. Pragmatisch ist die sicherste Sichtweise, Multi-Agent als „einen Weg zu betrachten, die Bandbreite heute realisierbarer KI-Aufgaben zu erweitern."

Q7. Gibt es eine Mitteloption zwischen Single und Multi?

Ja. „Single Agent + Subagenten als Werkzeuge". Das Task-Werkzeug des Claude Agent SDK ist genau das — der Hauptteil bleibt ein Single Agent, kann aber bei Bedarf disponible Subagenten hochfahren. Ohne die volle Komplexität von Multi-Agent stößt es einige Single-Agent-Grenzen weiter hinaus. Es ist als gemäßigter Mittelweg beliebt.