Ein Multi-Agenten-System (Multi-Agent System, MAS) ist ein Aufbau, bei dem mehrere KI-Agenten Rollen aufteilen und parallel arbeiten, um gemeinsam eine Aufgabe zu erledigen. Ein koordinierender Agent teilt die Arbeit auf, ausführende Agenten (Subagenten) recherchieren oder schreiben jeweils in ihrem eigenen Kontext, und der Koordinator führt die Ergebnisse zusammen.
Mehr Agenten machen ein System aber nicht von selbst klüger. In einem Experiment von Google Research und anderen mit sechs Aufgabentypen schnitten Multi-Agenten-Aufbauten bei aufteilbarer Arbeit um bis zu rund 81 % besser ab als ein einzelner Agent, bei Arbeit, die Schritt für Schritt vorangehen muss, um bis zu 70 % schlechter. Dieser Artikel erklärt die Definition und die fünf Muster und nutzt dann dieses Experiment sowie veröffentlichtes Material von Anthropic, Cognition und anderen, damit Sie beurteilen können, bei welcher Arbeit der Ansatz hilft und wo er schadet.
Multi-Agent = ein Team, das Rollen aufteilt und parallel arbeitet
— statt einer einzigen KI alles aufzutragen, teilt ein kleines Expertenteam die Arbeit auf
Jeder hat sein eigenes Kontextfenster, alle arbeiten parallel.
Der Koordinator prüft die Ergebnisse, bevor er sie zusammenführt – in Experimenten machte es einen großen Unterschied für die Fehlerausbreitung, ob es einen solchen prüfenden Koordinator gab.
Inhaltsverzeichnis
- 1. Was ist ein Multi-Agenten-System?
- 2. Warum mehrere KIs zusammenarbeiten lassen?
- 3. Die fünf Muster
- 4. Was Experimente zeigen: wo es hilft und wo es schadet
- 5. Wie echte Produkte es einsetzen
- 6. Kosten: etwa 15-mal so viele Tokens wie ein Chat
- 7. Entscheidungstabelle: einsetzen oder nicht?
- 8. Kernpunkte des Designs und typische Fehlerarten
- 9. Wie jedes Muster in den wichtigsten SDKs aussieht
- Zusammenfassung
- FAQ
1. Was ist ein Multi-Agenten-System?
Ein Multi-Agenten-System (Multi-Agent System, MAS) ist ein Aufbau, bei dem mehrere KI-Agenten zusammenarbeiten, um eine Aufgabe zu lösen. Jeder Agent hat eigene Anweisungen (Prompt), eigene Werkzeuge und einen eigenen Kontext; das Gesamtziel erreichen sie, indem sie Ergebnisse austauschen.
Der Grundbaustein, ein einzelner Agent, durchläuft allein die Schleife „denken → Werkzeug nutzen → Ergebnis ansehen“, wie in Was ist ein KI-Agent erklärt. Am treffendsten versteht man ein Multi-Agenten-System als diese Schleife plus Rollenverteilung und Parallelität.
Der Unterschied zum einzelnen Agenten
| Aspekt | Einzelner Agent | Multi-Agent |
|---|---|---|
| Aufbau | Eine KI durchläuft die Schleife | Mehrere KIs arbeiten zusammen |
| Kontext | Alles in einem Fenster | Nach Rollen getrennt (fremde Informationen vermischen sich nicht) |
| Parallelität | Meist ein Schritt nach dem anderen | Ausführende können gleichzeitig vorankommen |
| Fehlerausbreitung | Eigene Fehler häufen sich an | Ohne Prüfer landet der Fehler eines Ausführenden direkt im Endergebnis |
| Kosten | Niedriger (etwa 4-mal ein Chat) | Höher (etwa 15-mal ein Chat) |
| Stark bei | Schrittweiser Arbeit, bei der jeder Schritt vom vorigen abhängt | Recherche, Vergleich und Prüfung, die sich in unabhängige Teile zerlegen lassen |
Die Token-Faktoren sind die Zahlen, die Anthropic für seine eigene Recherchefunktion veröffentlicht hat (How we built our multi-agent research system, 13. Juni 2025). Mehr dazu in Abschnitt 6.
2. Warum mehrere KIs zusammenarbeiten lassen?
Der Ausgangspunkt lautet: „Wenn ein Agent alles schafft, nimm einen.“ Ein Multi-Agenten-System braucht man, wenn man an drei Wände stößt, die ein einzelner Agent aufgrund seiner Bauweise nur schwer überwindet.
Drei Wände, die ein einzelner Agent schwer überwindet
Als Beispiel für die Wirkung berichtet Anthropic, dass bei der Recherchefunktion (Research) von Claude ein Aufbau mit Claude Opus 4 als Koordinator und Claude Sonnet 4 als Ausführenden in der internen Recherche-Bewertung um 90,2 % besser abschnitt als Opus 4 allein (dieselbe Quelle). Im selben Beitrag heißt es, dass die Menge der verbrauchten Tokens allein 80 % der Leistungsstreuung erklärte (bei BrowseComp, einer Recherche-Bewertung). Die Stärke eines Multi-Agenten-Systems liegt also vor allem darin, getrennte Kontexte nebeneinander laufen zu lassen und so mehr zu lesen, als in einen einzelnen Agenten passt.
3. Die fünf Muster
Multi-Agenten-Systeme haben einige typische Formen. Jedes Produkt benennt sie anders, im Kern lassen sie sich aber auf die folgenden fünf zurückführen. Wo passend, ist auch die entsprechende Kategorie aus dem Experiment in Abschnitt 4 (unabhängig, zentral, dezentral, hybrid) angegeben.
3-1. Orchestrator und Ausführende (am weitesten verbreitet)
Ein Koordinator (Orchestrator) teilt die Arbeit auf und verteilt sie an mehrere Ausführende (Subagenten). Jeder Ausführende arbeitet in einem eigenen Kontext und gibt sein Ergebnis an den Koordinator zurück. In den Begriffen des Experiments ist das der zentrale Aufbau. Nach diesem Muster arbeiten die Recherchefunktion von Anthropic, die Subagenten von Claude Code und die Möglichkeit im OpenAI Agents SDK, „einen Agenten als Werkzeug aufzurufen“ (Agent.as_tool()).
3-2. Übergabe (Handoff: ein Staffellauf der Zuständigen)
Agenten übergeben sich die Gesprächsführung und sagen sinngemäß: „Ab hier übernimmst du.“ Laut Dokumentation des OpenAI Agents SDK wird der Spezialist, der die Übergabe erhält, für den Rest des Durchgangs zum aktiven Agenten. Das passt zu Empfangsaufgaben, etwa um eine Anfrage vom Empfang an die Abrechnung oder den technischen Support weiterzuleiten. Swarm, der experimentelle Vorgänger dieses SDK, weist in seinem Repository inzwischen darauf hin, dass es durch das Agents SDK ersetzt wurde; neue Projekte sollten daher das Agents SDK verwenden.
3-3. Hierarchie (ein Team aus Teams)
Ein Baum, in dem unter dem Hauptkoordinator Zwischenkoordinatoren stehen und darunter die Ausführenden. In Claude Code können Subagenten eigene Subagenten starten, standardmäßig bis zu drei Ebenen tief (offizielle Dokumentation), und auch Cursor erlaubt seit Version 2.5 im Februar 2026, dass Ausführende weitere Ausführende starten. Jede zusätzliche Ebene kostet Tokens und Wartezeit, legen Sie also eine Tiefengrenze fest.
3-4. Peer-to-Peer (Debatte und Konsens)
Kein Koordinator: Mehrere Agenten bringen gleichberechtigt ihre Sicht ein und wiederholen das, bis sie sich einigen. In den Begriffen des Experiments ist das der dezentrale Aufbau. Forschung zu Multi-Agent Debate berichtet von besserer Faktentreue und besserem Schlussfolgern. Er schneidet oft gut bei Arbeit ab, die mehrere Blickwinkel gegeneinander abwägen muss, etwa bei der Web-Recherche (Abschnitt 4).
3-5. Pipeline (feste Reihenfolge)
Die Agenten laufen in einer festen Reihenfolge, etwa „Recherche → Strukturierung → Prüfung → Ausgabe“. Weil ein Programm und nicht die KI entscheidet, welcher Agent als Nächstes läuft, sind die Ergebnisse stabil und Fehlerstellen leicht zu finden. Das OpenAI Agents SDK stellt „Chaining“ (die Ausgabe des einen wird zur Eingabe des nächsten) und „Evaluator-Schleifen“ (ein erzeugender und ein bewertender Agent wechseln sich ab) als im Code gebaute Muster vor.
Die fünf Muster auf einen Blick
4. Was Experimente zeigen: wo es hilft und wo es schadet
Welches Muster gewinnt, kehrt sich je nach Art der Arbeit um. In Zahlen gefasst hat das der Fachartikel Towards a Science of Scaling Agent Systems von Forschenden von Google Research, Google DeepMind und weiteren Einrichtungen (neueste Fassung April 2026). Mit drei Modellfamilien – GPT, Gemini und Claude – vergleicht er fünf Aufbauten (einen Einzelagenten und vier Multi-Agenten-Aufbauten) über sechs Aufgabentypen und 260 Kombinationen (vorgestellt im Google-Research-Blog im Januar 2026; die dort genannten 180 Konfigurationen beziehen sich auf die erste Fassung).
Quelle: Abschnitt 4.2 des Fachartikels. Beim Code-Korrigieren und bei der Planung schnitten alle getesteten Multi-Agenten-Aufbauten schlechter ab als ein Einzelagent; gezeigt ist jeweils der mit dem geringsten Verlust (Code korrigieren −2,1 % bis −14,9 %, Planung −39,1 % bis −70,0 %).
Drei Dinge fallen auf.
- Deutlich lohnt es sich nur bei aufteilbarer Arbeit: In der Finanzanalyse lassen sich Umsatz, Kosten und Märkte getrennt recherchieren und am Ende zusammenführen, daher übertraf der zentrale Aufbau einen Einzelagenten um rund 81 %.
- Bei reihenfolgeabhängiger Arbeit geht es nach hinten los: In der Planungsaufgabe, bei der jeder Zug den nächsten bestimmt, schnitt jeder Aufbau schlechter ab als ein Einzelagent. Teilt man die Arbeit auf, laufen die Annahmen der Ausführenden auseinander, und Aufwand geht in die Abstimmung.
- Auch das Code-Korrigieren wurde nicht besser: Anthropic schreibt ebenfalls, dass die meisten Programmieraufgaben weniger wirklich parallelisierbare Teile haben als Recherche (dessen Beitrag), was zu diesem Ergebnis passt.
Ein prüfender Koordinator bremst die Fehlerausbreitung
Derselbe Fachartikel hat gemessen, wie stark sich Fehler der Ausführenden bis ins Endergebnis ausbreiten (als Faktor, Einzelagent = 1).
Unabhängig (weder Austausch noch Prüfung)
17,2×
Die Ergebnisse werden nur nebeneinandergestellt, Fehler bleiben also drin
Dezentral (Debatte unter Gleichen)
7,8×
Die Debatte behebt manche Fehler, aber niemand ist für die Prüfung zuständig
Hybrid
5,1×
Koordinator plus etwas Austausch unter den Ausführenden
Zentral (Koordinator prüft)
4,4×
Der Koordinator prüft die Ergebnisse, bevor er sie zusammenführt
Quelle: Tabelle 5 des Fachartikels (Error Amp). In derselben Tabelle lag die Zahl der Durchgänge pro Aufgabe beim Einzelagenten im Mittel bei 7,2, beim zentralen Aufbau bei 27,7 und beim hybriden bei 44,3.
„Löst ein einzelner Agent schon 45 % oder mehr, schaden zusätzliche Agenten eher.“ Der Fachartikel berichtet, dass bei Aufgaben, in denen die Genauigkeit eines Einzelagenten bereits über etwa 45 % liegt, zusätzliche Agenten das Ergebnis tendenziell verschlechtern. Das Experiment stützt diese Reihenfolge: zuerst mit einem Agenten messen und erst nach Blick auf diese Zahl entscheiden, ob man weitere hinzunimmt.
5. Wie echte Produkte es einsetzen
Die Recherchefunktion von Anthropic: Zahl der Ausführenden je nach Schwierigkeit
Research von Claude ist ein Lehrbuchfall für Orchestrator und Ausführende: Der Koordinator zerlegt die Frage, die Ausführenden recherchieren parallel, und der Koordinator führt die Ergebnisse zusammen. Am nützlichsten am veröffentlichten Design ist, dass der Prompt festlegt, wie viele Ausführende je nach Schwierigkeit der Frage einzusetzen sind (dessen Beitrag).
| Art der Frage | Zahl der Ausführenden | Werkzeugaufrufe |
|---|---|---|
| Einfache Faktenprüfung | 1 (nur der Koordinator) | 3–10 |
| Direkter Vergleich | 2–4 | Je 10–15 |
| Komplexe Recherche | Teils mehr als 10 | Jeder Ausführende mit klar abgegrenzter Zuständigkeit |
Laut Anthropic machten frühe Versionen vor diesen Regeln Fehler wie den Start von 50 Ausführenden für eine einfache Frage. Wer ein eigenes System baut, kommt am schnellsten voran, wenn er diese Tabelle unverändert als Regel für den Arbeitsumfang in den Prompt übernimmt. Außerdem verkürzte der Wechsel zu parallelen Aufrufen der Suche und anderer Werkzeuge die Recherchezeit bei komplexen Fragen um bis zu 90 %.
Subagenten in Claude Code und Codex
In Claude Code lassen sich Recherche, Reviews und ähnliche Aufgaben an Subagenten abgeben. Jeder Subagent arbeitet in seinem eigenen Kontext und gibt nur eine Zusammenfassung an den Hauptagenten zurück, sodass der Hauptkontext nicht vollläuft. Standardmäßig können bis zu 20 gleichzeitig laufen, bei bis zu drei Verschachtelungsebenen. Wie sich das von „Agententeams“ unterscheidet, in denen sich die Ausführenden unterwegs austauschen, steht in Subagenten vs. Agententeams in Claude Code; wie man parallele Arbeit im Vergleich zu Codex anfordert, in Parallele Subagenten in Codex und Claude Code.
Devin (Cognition): von „nicht bauen“ zu „koordinieren“
Im Juni 2025 veröffentlichte Cognition „Don’t Build Multi-Agents“ und argumentierte, dass parallele Ausführende, die die Entscheidungen der anderen nicht kennen, widersprüchliche Ergebnisse liefern. Die zwei Grundsätze lauten: „Kontext teilen, und zwar den gesamten Arbeitsverlauf des Agenten, nicht nur einzelne Nachrichten“ und „Handlungen enthalten implizite Entscheidungen, und widersprüchliche Entscheidungen führen zu schlechten Ergebnissen“.
Im März 2026 brachte dasselbe Unternehmen eine Funktion heraus, bei der Devin eine große Aufgabe zerlegt und an mehrere parallel arbeitende Devins delegiert, jeder in seiner eigenen virtuellen Maschine. Der Haupt-Devin verfolgt den Fortschritt, löst Konflikte und fasst die Ergebnisse zusammen. Die Parallelität wurde also nicht aufgegeben; man entschied sich für einen Aufbau, in dem der Hauptagent die Widersprüche zwischen den Ausführenden übernimmt – passend zu Abschnitt 4 über den prüfenden Koordinator.
Cursor: weiterarbeiten, ohne auf Ausführende zu warten
Mit Version 2.5 (17. Februar 2026) machte Cursor Subagenten asynchron, sodass der Hauptagent ohne Warten weiterarbeiten kann. Ausführende können auch eigene Ausführende starten. Anthropic schreibt ebenfalls, dass synchrone Ausführung, bei der der Koordinator auf das Ende der Ausführenden wartet, Engpässe erzeugt; den Hauptagenten nicht warten zu lassen, ist damit zu einer gemeinsamen Aufgabe aller Anbieter geworden.
6. Kosten: etwa 15-mal so viele Tokens wie ein Chat
Anthropic schreibt, dass Agenten etwa 4-mal so viele Tokens verbrauchen wie ein Chat und Multi-Agenten-Systeme etwa 15-mal so viele (dessen Beitrag). Auf den eigenen Einsatz übertragen sieht die Schätzung so aus.
Beispielrechnung (Faktoren aus der Recherchefunktion von Anthropic; je nach Arbeit verschieden)
Eine Frage, die als Chat 10.000 Tokens kostet → mit einem Agenten etwa 40.000, mit einem Multi-Agenten-System etwa 150.000 Tokens.
Bei 100 Anfragen pro Tag: Chat 1 Million, ein Agent 4 Millionen, Multi-Agent 15 Millionen Tokens. Mit dem Preis pro Token aus der offiziellen Preisliste des verwendeten Modells multiplizieren.
Nicht nur die Tokens wachsen
Harte Grenzen und Richtwerte getrennt festlegen
Wenn Ausführende weitere Ausführende starten und etwas in eine Schleife gerät, steigen die Kosten rasant. Beim Bauen mit Claude gibt es zwei Arten von Grenzen, die unterschiedlich wirken.
| Grenze | Wo einstellen | Stoppt sie den Lauf? |
|---|---|---|
| Ausgabenobergrenze | max_budget_usd im Claude Agent SDK (maxBudgetUsd in TypeScript) | Ja (keine neuen Ausführenden, die Abfrage endet) |
| Verschachtelungstiefe | Umgebungsvariable CLAUDE_CODE_MAX_SUBAGENT_SPAWN_DEPTH (Standard 3, mit 1 keine Verschachtelung) | Ja (Ausführende auf der untersten Ebene erledigen die Arbeit selbst) |
| Gleichzeitige Ausführende | Umgebungsvariable CLAUDE_CODE_MAX_CONCURRENT_SUBAGENTS (Standard 20) | Ja (über die Grenze hinaus werden keine Ausführenden gestartet) |
| Aufgabenbudget | task_budget in der Claude API (Beta, mindestens 20.000 Tokens) | Nein (ein Richtwert, nach dem das Modell sein Tempo einteilt) |
Quellen: Subagents in the Agent SDK und Task budgets (geprüft am 12. November 2026). Die drei harten Grenzen gelten ab TypeScript SDK v0.3.219 und Python SDK v0.2.127; in älteren Versionen fehlen manche oder haben andere Standardwerte. Die Dokumentation beschreibt das Aufgabenbudget als Richtwert, nicht als erzwungene Grenze; kombinieren Sie es mit einer Ausgabenobergrenze oder max_tokens, wenn ein Lauf sicher stoppen muss.
7. Entscheidungstabelle: einsetzen oder nicht?
Fasst man alles zusammen, entscheiden fünf Fragen die meisten Fälle. Beantworten Sie sie von oben nach unten; landet auch nur eine auf der Seite „Einzelagent“, beginnen Sie mit einem einzelnen Agenten.
| Frage | Spricht für Multi-Agent | Spricht für Einzelagent | Grundlage |
|---|---|---|---|
| Lässt sich die Arbeit in unabhängige Teile zerlegen? | Ja (nach Unternehmen, Dokument, Blickwinkel) | Jeder Schritt hängt vom vorigen Ergebnis ab | Finanzanalyse +80,8 %, Planung −39,1 % bis −70,0 % |
| Wie gut ist ein Einzelagent schon? | Geringe Genauigkeit mit einem Agenten | Ein Agent löst bereits etwa 45 % oder mehr | Der Fachartikel von Google Research u. a. |
| Müssen die Ausführenden denselben Kontext teilen? | Die Informationen jedes Ausführenden reichen | Ohne gemeinsamen Kontext widersprechen sich die Ergebnisse (das meiste Programmieren) | Anthropic, Cognition |
| Passt alles in einen Kontext? | Zu viel Material, der Kontext eines Agenten läuft über | Passt in den Kontext eines Agenten | Die Token-Menge erklärte 80 % der Leistungsstreuung |
| Ist das Ergebnis 15-mal so viele Tokens wert? | Hoher Wert pro Anfrage (Recherche-, Prüf- und Vergleichsberichte) | Routinearbeit in großer Menge, Empfang mit Sofortantwort | Die ~15-fach von Anthropic |
Auch Anthropic rät in seinem Leitfaden zum Bau von Agenten, die einfachste mögliche Lösung zu suchen und Komplexität nur bei Bedarf hinzuzufügen. Die ersten Schritte und minimale Codebeispiele stehen in So bauen Sie ein Multi-Agenten-System, wie man den ersten Einzelagenten baut, in So bauen Sie einen KI-Agenten.
8. Kernpunkte des Designs und typische Fehlerarten
① Geben Sie jedem Ausführenden Ziel, Ausgabeformat, Werkzeuge und Grenzen
Anthropic schreibt, dass Ausführende bei vagen Anweisungen die Aufgabe missverstehen, dieselben Suchen wie andere wiederholen oder benötigte Informationen übersehen. Nennen Sie jedem Ausführenden (1) das Ziel, (2) das Rückgabeformat, (3) die erlaubten Werkzeuge und Quellen und (4) die Grenzen der Aufgabe. Ein Subagent im Claude Agent SDK erhält das Gespräch des Hauptagenten nicht; übergeben wird nur der Prompt, mit dem Sie ihn aufrufen (offizielle Dokumentation). Schreiben Sie Dateipfade und bereits getroffene Entscheidungen deshalb direkt in diesen Prompt.
② Sagen Sie, wie tief gegraben werden soll
Ausführende können schlecht selbst entscheiden, wie weit sie recherchieren sollen. Schreiben Sie Umfangsregeln wie die Tabelle in Abschnitt 5 und stellen Sie auch die Denktiefe ein. Der effort-Wert von Claude lässt sich pro Ausführendem festlegen, und Agentendefinitionen im Agent SDK erlauben Werte von low bis max. Einfache Ausführende leicht und prüfende tief einzustellen, hält die Kosten im Rahmen.
③ Machen Sie das Prüfen zur Aufgabe des Koordinators
Wie Abschnitt 4 zeigte, breitete der zentrale Aufbau – bei dem der Koordinator die Ergebnisse vor dem Zusammenführen prüft – Fehler weit weniger aus als der unabhängige ohne Prüfung (4,4× gegenüber 17,2×). Nehmen Sie in die Anweisungen des Koordinators einen Schritt auf, Widersprüche zwischen den Ergebnissen der Ausführenden zu suchen und Belege zu prüfen, bevor sie übernommen werden.
④ Kennen Sie die Fehlerarten
Forschende der University of California, Berkeley, und weiterer Einrichtungen haben Fehler anhand von mehr als 1.600 Ausführungsprotokollen aus sieben Multi-Agenten-Systemen in 3 Kategorien und 14 Arten eingeteilt (Why Do Multi-Agent LLM Systems Fail?). Das eignet sich als Checkliste bei der Überprüfung eines Designs.
| Kategorie | Was passiert | Gegenmittel |
|---|---|---|
| Designprobleme | Agenten ignorieren Rollen- oder Aufgabenanweisungen, wiederholen dieselben Schritte oder wissen nicht, wann sie aufhören sollen | Rollen, Umfang und Abbruchbedingungen in die Prompts schreiben |
| Fehlabstimmung zwischen Agenten | Annahmen widersprechen sich, nötige Informationen werden nicht weitergegeben, Beiträge anderer Agenten werden ignoriert | Den gesamten Verlauf teilen; der Koordinator löst Widersprüche |
| Mangelnde Prüfung | Vorzeitiges Beenden, keine oder nur oberflächliche Prüfung | Einen Prüfer bestimmen (den Koordinator oder einen eigenen Ausführenden) |
⑤ Protokollierung von Anfang an aufbauen
Wer nicht sieht, was ein Multi-Agenten-System tut, kann es nicht reparieren. Protokollieren Sie vom ersten Tag an Ein- und Ausgaben jedes Ausführenden, Zeitbedarf, Tokens und aufgerufene Werkzeuge. Zur Bewertung schreibt Anthropic, man habe mit etwa 20 Anfragen begonnen, die die reale Nutzung abbildeten, und sie von einer KI anhand eines Bewertungsrasters benoten lassen. Die Veränderung an einer kleinen Zahl von Anfragen zu beobachten, statt auf ein großes Bewertungssystem zu warten, ist der praktikable Weg.
9. Wie jedes Muster in den wichtigsten SDKs aussieht
Dasselbe Muster heißt in jedem SDK anders. Für die Auswahl (Tempo beim Prototyping, Reife für den Produktivbetrieb, Token-Verbrauch) siehe KI-Agenten-Frameworks im Vergleich; hier zeigen wir nur, welcher Baustein welchem Muster aus Abschnitt 3 entspricht.
| SDK | Orchestrator und Ausführende | Übergabe / Pipeline |
|---|---|---|
| Claude Agent SDK | Ausführende werden in agents definiert und mit dem Werkzeug Agent aufgerufen (früher Task) | Kein eigener Baustein; die Pipeline entsteht, indem der eigene Code die Agenten der Reihe nach aufruft |
| OpenAI Agents SDK | Ausführende werden mit Agent.as_tool() als Werkzeuge aufgerufen | Die Führung wird per Handoff übergeben; Chaining und Parallelläufe werden im Code gebaut |
| LangGraph | Verzweigung von einem Koordinatorknoten zu Ausführendenknoten | Reihenfolge, Verzweigungen und Schleifen werden als Graph aus Knoten und Kanten geschrieben |
| Strands Agents (AWS) | Ausführende werden mit Agents as Tools als Werkzeuge aufgerufen | In Swarm reichen sich Ausführende die Arbeit weiter; mit Graph oder Workflow wird die Reihenfolge festgelegt |
| Microsoft Agent Framework | Bringt Muster zur Multi-Agenten-Orchestrierung als fertige Bausteine mit | Die Reihenfolge wird als Workflow festgelegt |
Microsoft hat das AutoGen-Repository archiviert und liefert keine Fehlerbehebungen oder Sicherheitskorrekturen mehr (geprüft am 12. November 2026). Für neue Projekte wird der Nachfolger Microsoft Agent Framework empfohlen. Minimale Codebeispiele für jedes SDK finden Sie in So bauen Sie ein Multi-Agenten-System.
Zusammenfassung
- Ein Multi-Agenten-System verteilt Rollen auf mehrere KIs, die parallel arbeiten, um eine Aufgabe zu erledigen. Es überwindet die Wände eines Einzelagenten: überlaufender Kontext, fehlende Parallelität und dass derselbe macht und prüft.
- Die fünf Muster sind Orchestrator und Ausführende, Übergabe, Hierarchie, Peer-to-Peer und Pipeline. Am weitesten verbreitet ist Orchestrator und Ausführende.
- Ob es hilft, hängt von der Arbeit ab. Bei einer aufteilbaren Finanzanalyse lag es +80,8 % über einem Einzelagenten, bei reihenfolgeabhängiger Planung 39,1 % bis 70,0 % darunter, und auch das Code-Korrigieren wurde nicht besser.
- Mit einem prüfenden Koordinator sank die Fehlerausbreitung von 17,2× (unabhängig) auf 4,4×.
- Tokens liegen bei etwa dem 15-Fachen eines Chats (etwa 4-fach bei einem Agenten). Legen Sie Ausgaben, Tiefe und Gleichzeitigkeit als Grenzen fest, die einen Lauf wirklich stoppen.
- Reihenfolge der Entscheidung: zuerst mit einem Agenten bauen und messen. Nur aufteilbare Teile, bei denen ein Agent nachweislich nicht reicht, an Ausführende abgeben.
FAQ
Q1. Ist ein Multi-Agenten-System immer besser als ein kluger Einzelagent?
Nein. Die Recherchefunktion von Anthropic war 90,2 % besser als ein Einzelagent, aber bei Recherche, die sich in unabhängige Teile zerlegen ließ. Im Experiment von Google Research und anderen schnitt bei der reihenfolgeabhängigen Planungsaufgabe jeder Multi-Agenten-Aufbau schlechter ab als ein Einzelagent. Entscheidend ist, ob sich die Arbeit aufteilen lässt.
Q2. Hilft Multi-Agent beim Programmieren?
Mehrere Ausführende Teile derselben Korrektur schreiben zu lassen, hilft meist nicht. Im Experiment lag beim Code-Korrigieren (SWE-bench Verified) jeder Multi-Agenten-Aufbau unter einem Einzelagenten, um −2,1 % bis −14,9 %. Dagegen ist es ein typischer Einsatz der Subagenten von Claude Code, unabhängige Arbeiten wie Recherche, Reviews oder Testläufe an Ausführende abzugeben, damit der Hauptkontext frei bleibt.
Q3. Kann man schrittweise vom Einzelagenten zum Multi-Agenten-System übergehen?
Ja. Bauen Sie zuerst mit einem Agenten und messen Sie Genauigkeit, Tokens und Zeit; sobald sichtbar wird, wo der Kontext überläuft oder was parallel laufen könnte, geben Sie nur diese Teile an Ausführende ab. Wer von Anfang an alles als Multi-Agent entwirft, kann nicht messen, was tatsächlich hilft.
Q4. Gibt es ein Standard-Kommunikationsprotokoll zwischen Agenten?
Für die Anbindung von Agenten an Werkzeuge und Daten ist MCP (Model Context Protocol) zum De-facto-Standard geworden. Es entstand bei Anthropic, wurde im Dezember 2025 an die Agentic AI Foundation der Linux Foundation übergeben und wird von OpenAI, Microsoft, AWS und anderen übernommen. Für die Kommunikation zwischen Agenten gibt es das von Google initiierte A2A (Agent2Agent), das ebenfalls zur Linux Foundation gewechselt ist. IBMs ACP (Agent Communication Protocol) ist im August 2025 in A2A aufgegangen.
Q5. Verhindert ein Aufgabenbudget ausufernde Kosten?
Allein nicht. Das Aufgabenbudget der Claude API ist ein Richtwert, nach dem das Modell sein Tempo einteilt, und die Dokumentation sagt ausdrücklich, dass es nicht erzwungen wird. Um einen Lauf sicher zu stoppen, legen Sie die Ausgabenobergrenze des Agent SDK (max_budget_usd) sowie Grenzen für Verschachtelungstiefe und gleichzeitige Ausführende fest (Tabelle in Abschnitt 6).
Q6. Sind „Subagenten“ und „Multi-Agent“ verschiedene Dinge?
Subagenten sind die Ausführenden im Muster Orchestrator und Ausführende innerhalb eines Multi-Agenten-Systems. Im Claude Agent SDK bleibt der Hauptagent ein einzelner und ruft Ausführende mit dem Werkzeug Agent nur bei Bedarf auf. Aufbauten, in denen sich Ausführende unterwegs direkt austauschen (etwa Agententeams in Claude Code), liegen näher am Peer-to-Peer- oder am hybriden Muster.
