Wie Subagenten und Mehr-Agentensysteme die Arbeit sowie die Kosten-Token aufteilen.
Subagenten gegen Mehr-Agentensysteme: Das Orchestrator-Arbeiter-Design, vier Topologien, was jede in Tokens kostet, sowie die Fälle, in denen ein einzelner Agent besser abschneidet.
Quellen: Subagents vs. Multi-Agent Systems: The Complete Guide to How AI Agents Actually Work Together
Warum ein einzelner Agent an seine Grenzen stößt
Jeder, der bereits gesehen hat, wie Claude Code, LangGraph oder Claudes Forschungsfunktion funktionieren, kennt den Moment, in dem der Assistent aufhört, selbstständig zu antworten, und um Hilfe bittet. Ein Hilfsprogramm zum Suchen in Dateien taucht auf, durchsucht alles und kehrt mit Ergebnissen zurück. Eine Forschungsfrage konsultiert in der Zeit, die ein Mensch braucht, um zwei Tabs zu öffnen, leise Dutzende von Quellen. Das Modell ist nicht plötzlich intelligenter geworden – ein kleines Team erledigt die Arbeit.
Im Folgenden wird anschaulich erklärt, wie diese Teamarbeit zustande kommt, wobei Subagenten, Mehr-Agenten-Systeme, ihre zugrunde liegende Architektur sowie die damit verbundenen Kosten behandelt werden.
Ein einzelner Agent, also ein Modell, das mit Tools in einer Schleife läuft, ist durchaus fähig. Er kann Dateien lesen, im Internet surfen, Code schreiben und über mehrere Schritte hinweg logisch denken. Allerdings sind drei Grenzen in der Konzeption bereits vorgesehen:
- Ein Kontextfenster. Alles, was der Agent liest, denkt und tut, wird im selben Raum zusammengefasst. Bei einer langen Erkundungsaufgabe verdrängt die Ausgabe der Tools letztendlich die ursprüngliche Frage aus dem Fokus.
- Eine Ausführungslinie. Die Arbeit erfolgt sequenziell. Fünfzig Suchvorgänge à zwei Sekunden dauern länger als neunzig Sekunden, bevor mit dem Schreiben begonnen werden kann.
- Eine Perspektive. Ein einziger Prompt prägt jede Entscheidung, wodurch es für den Agenten schwierig ist, gleichzeitig zwei gegensätzliche Ansätze zu verfolgen oder seine eigenen Blindstellen zu erkennen.
Subagenten und Mehr-Agentensysteme sind zwei Lösungsansätze dafür, die oft kombiniert werden. Der Rest erläutert, was each ist, wie sie zusammengesetzt werden und wann sich die Investition lohnt.
Was ein Subagent ist
Ein Subagent ist ein auf einen engen Bereich beschränkter Helfer, der innerhalb einer Sitzung gestartet wird. Er erledigt eine einzige, fokussierte Aufgabe in einem eigenen Kontextfenster und berichtet anschließend zurück.
Claude Code ist eine gute Veranschaulichung. Wenn die Haupt-Programmier-Sitzung einen unbekannten Teil einer Codebasis verstehen muss, kann sie die Erkundung an einen Subagent weitergeben und so die Hauptkonversation entlasten. Der Subagent:
- startet mit einem neuen, sauberen Kontextfenster
- bietet in der Regel nur eine kleinere, eingeschränkte Auswahl an Werkzeugen
- führt seinen eigenen eng gefassten Ablauf aus Lesen, Suchen und Schlussfolgern
- sendet eine Zusammenfassung an die übergeordnete Sitzung und behält die Transkriptdatei für sich
Der Wert hier ist Isolation, nicht zusätzliche Intelligenz. Das Hauptgespräch sieht niemals die fünfzig Dateien, die der Assistent geöffnet hat, sondern nur die drei wichtigen Sätze – dadurch bleibt der Hauptthread über eine lange Sitzung hinweg präzise und wird nicht mit Unnötigem überflutet.
Mehrere Eigenschaften definieren dieses Muster, wie es Tools wie Claude Code umsetzen:
- Subagenten existieren innerhalb einer Sitzung. Sie dienen dazu, Aufgaben zu delegieren, und sind keine separaten laufenden Prozesse.
- Im Allgemeinen können sie keine eigenen Subagenten starten, was die Hierarchie flach hält und leicht verständlich macht.
- Die Definition eines Subagenten wird einmal geschrieben und wiederverwendet. Geben Sie einem Überprüfungs-Subagenten einen festen Systemprompt sowie eine kurze Liste an Tools – er verhält sich bei jeder Aufrufung identisch.
Was ein Mehr-Agentensystem ist
Ein Mehr-Agentensystem hat eine andere Struktur. Mehrere unabhängige Agenten, jeder mit seinem eigenen Kontext, seinen eigenen Werkzeugen und manchmal auch seinem eigenen Modell, verfolgen ein gemeinsames Ziel – in der Regel in einem längeren oder komplizierteren Prozess als bei der Delegation in einer einzigen Sitzung.
Die Forschungsfunktion von Anthropic ist das bekannteste öffentliche Beispiel. Eine allgemeine Frage wird nicht direkt beantwortet. Stattdessen entwirft ein Leitagent einen Ansatz und erzeugt mehrere Unteragenten, wobei jeder von ihnen im selben Moment einen anderen Aspekt untersucht. Ihre Ergebnisse werden zusammengeführt, auf Richtigkeit der Zitate überprüft und als einzige Antwort zurückgegeben.
Insgesamt bilden ein Leitagent, parallele Spezialisten sowie ein abschließender Syntheseschritt das Muster, das heute von den meisten produktionstechnischen Multi-Agenten-Systemen verwendet wird, und genau dieses Design wird im weiteren Verlauf dieses Artikels untersucht.
Wo sich die beiden Konzepte unterscheiden
Im Internet werden diese Begriffe oft austauschbar verwendet, was zu Verwirrung führt. Der tatsächliche Unterschied wird hier dargestellt.
Der kürzeste Weg, sich daran zu erinnern: Ein Subagent ist eine Technik, die innerhalb eines Agents verwendet wird, während ein Multi-Agenten-System eine Architektur ist, die um mehrere Agents herum konzipiert ist. In der Praxis werden viele Multi-Agenten-Systeme auf der Grundlage des Subagenten-Musters erstellt. Ein Leitagent, der Subagenten einsetzt, ist gleichzeitig beides.
Die Orchestrator- und Worker-Architektur
Fast jedes produktive Mehr-Agenten-System, einschließlich von Anthropics Research-Funktion, LangGraphs Supervisor-Muster und Claudes Code-Subagenten-Modell, ist eine Variante eines Designs: Orchestrator und Arbeiter.
Jeder Komponente obliegt eine spezifische Aufgabe:
- Leitagent (Orchestrator). Er liest die Anfrage, entwickelt eine Strategie und beurteilt, wie viel Aufwand die Aufgabe erfordert. Diese Beurteilung ist wichtiger, als es scheint. Frühe Versionen dieser Systeme starteten manchmal fünfzig Subagenten für eine Frage, für die nur einer nötig war.
- Speicher oder Zwischenspeicher. Der Plan wird außerhalb des Gesprächs festgehalten. Lange Laufzeiten der Agenten können das Kontextfenster des Modells überschreiten; falls dies mitten im Vorgang geschieht, muss der Plan über die Trunkierung hinaus bestehen bleiben und nicht zusammen mit ihr verschwinden.
Das Diagramm verwendet zwei Arten von Pfeilen. Die soliden Pfeile führen Aufgaben nach unten, während die gestrichelten Pfeile konzentrierte Ergebnisse nach oben führen. Die Asymmetrie ist beabsichtigt: Die Unteragenten liefern ein verdichtetes Ergebnis und nicht ihre gesamte Arbeitshistorie, wodurch der Kontext des leitenden Agenten nicht übermäßig anwächst.
Der Workflow von Frage zu Antwort
Wenn man von den Komponenten abstrahiert, ist dies die Reihenfolge der Ereignisse von der von einem Benutzer eingegebenen Frage bis zur fertigen Antwort.
Mehrere Schritte verdienen besondere Aufmerksamkeit:
- Schritt 2 (zuerst nachdenken, dann planen) ist wichtiger, als es auf den ersten Blick scheint. Hier entscheidet das System, wie viel Aufwand die Anfrage erfordert: Eine schnelle Überprüfung könnte einen Agenten und einige Toolaufrufe benötigen, während eine umfassende Frage zehn oder mehr Unteragenten mit klar definierten Aufgaben erfordern kann.
- Schritt 7 (Wiederholung) unterscheidet ein agiles System von einem starren Ablauf. Nichts ist vorprogrammiert, da der führende Agent die Ergebnisse prüft und entscheidet, ob er antwortet oder weiter sucht. Genau bei dieser Entscheidung gehen die Dinge am häufigsten schief. Ein Agent, der zu zögerlich ist, wiederholt die Schritte, liefert dürftige Antworten, während ein zu eifriger Agent Zeit und Ressourcen verschwendet, indem er nach Quellen sucht, die nicht existieren.
- Schritte 8 und 9, wobei die Zitierung eine eigene Phase darstellt, existieren deshalb, weil ein Agent, der aufgefordert wird, eine Antwort zu verfassen und gleichzeitig seine eigenen Quellen zu bewerten, oft zuversichtliche Behauptungen aufstellt, die nicht haltbar sind. Eine unabhängige zweite Überprüfung erkennt das.
Vier Möglichkeiten, mehrere Agenten zu organisieren
Orchestrator und Worker bilden die übliche Struktur, sind aber nicht die einzige. Je nachdem, wie eine Aufgabe tatsächlich aufgeteilt wird, eignet sich eine von vier allgemeinen Topologien besser als die anderen.
Wenn unklar ist, welche Variante gewählt werden soll, folgen Entwicklerteams in der Regel einer Faustregel: Wählen Sie für alles, was in die Produktion geht, eine Hierarchie mit einem Supervisor – bei explorativen oder forschenden Arbeiten, bei denen der Datenfluss im Voraus nicht festgelegt werden kann, bleiben Netzwerk- oder Mesh-Strukturen am besten. Mesh-Designs sehen in Diagrammen elegant aus, sind aber in der Regel am schwierigsten zu debuggen.
Warum das funktioniert: Tokenökonomie
Es ist hilfreich, genau zu erklären, warum Mehr-Agentensysteme bei bestimmten Aufgaben besser abschneiden als Ein-Agentensysteme – denn die Antwort lautet nicht einfach „mehr Agenten bedeuten mehr Intelligenz.“
In den internen Bewertungen von Anthropic übertraf eine Konfiguration mit Claude Opus 4 als Leitagent und Claude Sonnet 4 als Unteragenten einen einzelnen Claude Opus 4-Agenten um 90,2 Prozent in einem internen Forschungs-Benchmark. Bei der Analyse der Gründe lag die Ursache größtenteils in der Kapazität. In einem Benchmark für komplexe Suchaufgaben machte allein die Token-Nutzung etwa 80 Prozent der Leistungsunterschiede aus, während die Anzahl der Tool-Aufrufe sowie die Wahl des Modells den Rest erklärten.
Kurz gesagt resultiert der Vorteil bei breit angelegten, informationsintensiven Aufgaben hauptsächlich aus der Kapazität. Durch die Verteilung der Aufgabe auf separate Kontextfenster erhält das System weitaus mehr Raum für das logische Denken als ein einziges Fenster, und jeder Unteragent komprimiert das Gelesene in einen kurzen Bericht.
Die Kapazität ist nicht kostenlos. Produktionsdaten deuten darauf hin, dass agierende Workflows etwa viermal so viele Tokens verbrauchen wie ein gewöhnlicher Chataustausch, und mehragentige Workflows sogar etwa fünfzehnmal so viele. Dieser Multiplikator sollte darüber entscheiden, ob die Architektur überhaupt sinnvoll ist – was zum nächsten Punkt führt.
Wann ein mehragentiges System das falsche Werkzeug ist
Die meisten Schriften zur Agentenarchitektur überspringen diesen Teil, und gerade er schützt sowohl die Zeit als auch den Token-Budget.
Die Aufgabe muss in wirklich unabhängige Teile aufgeteilt werden. Wenn die Unteraufgaben stark voneinander abhängen, führt ihre Verteilung auf verschiedene Agenten zu zusätzlichem Koordinationsaufwand ohne echten Parallelismus. Getrennte Forschungsfragen lassen sich gut aufteilen, während die Erstellung einer kohärenten Funktion in der Regel nicht möglich ist.
Programmierung ist das deutlichste Gegenbeispiel. Anthropics eigene Darstellung ist unverblümt: Die meisten Programmieraufgaben weisen weniger parallelisierbare Teilaufgaben auf als Forschungsarbeiten, und die heutigen Agenten sind noch nicht in der Lage, in Echtzeit Arbeit zu koordinieren und untereinander weiterzuleiten. Auch externe Benchmarks bestätigen dies. Eine wissenschaftliche Bewertung ergab, dass mehrere-Agenten-Programmierumgebungen 4-mal bis mehr als 200-mal so viele Tokens verbrauchen wie ein vergleichbarer einzelner Agent, und eine separate Branchenanalyse zeigte, dass mehrere-Agenten-Systeme bei streng sequenziellen Aufgaben 39 bis 70 Prozent schlechter abschneiden als ein einzelner Agent.
Fehler breiten sich aus. Eine falsche Annahme bei einem Agenten bleibt ein einzelner Fehler. In einem koordinierten System kann er sich durch die Weitergabe an andere Agenten ausbreiten und an Größe gewinnen. Eine Analyse schätzte bei zentraler Orchestrierung eine Verstärkung um etwa das Vierfache, und es wird noch schlimmer, wenn die Agenten unkoordiniert eigenständig arbeiten.
Der Nutzen muss die Kosten decken. Mit einem Multiplikator von fast 15x eignen sich mehrere Agenten für arbeitsintensive, hochkomplexe Aufgaben wie tiefgehende Forschung, mehrdomänige Analyse und umfangreiche Überarbeitungen. Für alles, was ein gut instruierter einzelner Agent mit geeigneten Werkzeugen in einem Durchgang erledigen kann, sind sie überflüssig.
Es gibt einen schnellen Test: Wenn man nicht angeben kann, welche Aufgaben jeweils einem Agenten zugeordnet werden sollten und welche nicht, liegt die Lösung wahrscheinlich in einem leistungsstärkeren einzelnen Agenten statt in zusätzlichen.
Lektionen aus der Entwicklung
Anthropics Rückschau auf sein Forschungssystem zählt zu den aufrichtigsten öffentlichen Darstellungen darüber, was schiefgeht, wenn eine funktionierende Demo zu einer produktiven Mehr-Agenten-Struktur wird. Die am meisten übertragbaren Lektionen im Überblick:
- Die Anweisungen sind das wichtigste Hebelwerkzeug. Da jede Agentur durch Anweisungen gesteuert wird, hatten kleine Änderungen in der Formulierung der Aufgabenverteilung durch den Orchesterer einen überproportionalen Einfluss darauf, ob die Unteragenturen ihre Arbeit wiederholten oder Lücken hinterließen.
- Laxe Delegation führt zu Doppelarbeit. Eine Anweisung wie „Forschen Sie über den Halbleitermangel“ klingt klar, ist es aber nicht. In frühen Systemen untersuchten mehrere Unteragenturen denselben Aspekt, da niemand markiert hatte, wo eine Aufgabe endete. Eine gute Anweisung gibt das Ziel, das erwartete Ausgabeformat sowie die Grenzen des Aufgabengebiets jeder Agentur an.
Eine minimale Skizze des Musters
Was folgt, ist ein vereinfachter, framework-unabhängiger Überblick über Orchestrator und Worker. Wiederholversuche, Streaming und persistente Speicher werden weggelassen, damit die Struktur der Logik leicht erkennbar ist – sie dient außerdem als Pseudocode für die Portierung in LangGraph, das Claude Agent SDK oder einen reinen API-Zyklus.
def run_research(query: str) -> str:
# 1. Lead agent plans
plan = lead_agent.think_and_plan(query)
memory.save("plan", plan) # survives context truncation
findings = []
subtasks = plan.subtasks # explicit objective + boundaries per subtask
# 2. Spawn subagents in parallel, not sequentially
results = run_in_parallel([
subagent.execute(task=subtask, tools=subtask.allowed_tools)
for subtask in subtasks
])
findings.extend(results)
# 3. Lead agent decides: enough evidence, or loop again?
while not lead_agent.has_sufficient_evidence(findings):
new_subtasks = lead_agent.refine_plan(findings)
more_results = run_in_parallel([
subagent.execute(task=t, tools=t.allowed_tools)
for t in new_subtasks
])
findings.extend(more_results)
# 4. Synthesize, then verify citations in a separate pass
draft = lead_agent.synthesize(findings)
cited_answer = citation_agent.attach_citations(draft, findings)
return cited_answer
Zwei Aspekte verdienen besondere Aufmerksamkeit, und keiner taucht in den Beispielen für Spielzeuge auf. Erstens ist run_in_parallel: Wenn die Subagenten nacheinander aufgerufen werden, geht der größte Teil der Geschwindigkeitssteigerung verloren. Zweitens ist der explizite while-Schleifen, der neu plant, denn eine feste Anzahl von Durchgängen der Subagenten kann sich nicht anpassen, wenn der erste Durchlauf mehr Fragen als Antworten hinterlässt.
Prüfungen vor der Veröffentlichung
Bevor Sie einen Subagenten oder ein Mehr-Agenten-Workflow veröffentlichen, überprüfen Sie folgende Punkte:
- Jeder Subagent hat ein klares Ziel, ein Ausgabeformat und klare Aufgabengrenzen – und nicht nur eine einzeilige Anweisung.
- Subagenten laufen parallel, sofern sie tatsächlich unabhängig voneinander sind.
- Der Plan wird gespeichert, und nicht nur im Gespräch behalten, falls der Kontext gekürzt wird.
Verwandte Literatur
- Wenn zwei Agenten einen besiegen: Ein LangGraph-Code-Review-Copilot, der in beiden Varianten erstellt werden kann — Erstellen Sie einen Code-Reviewer als einzelnen Agenten sowie erneut als Analyzer zusammen mit Risk Reviewer in LangGraph und lernen Sie anschließend die drei Fälle, in denen mehrere Agenten die Kosten rechtfertigen.
- Praktische Hinweise: Wie man zu einem der Top-1%-Hermes-Agenten-Nutzer wird: Das vollständige Handbuch — Detaillierte Anleitung zu den Praktischen Hinweisen: Wie man zu einem der Top-1%-Hermes-Agenten-Nutzer wird: Das vollständige Handbuch, einschließlich Verträgen, Überprüfungen sowie Code-Blöcken für Teams, die dieses Muster einsetzen.