---
type: Comparison
title: "Rekursive Sub-Agenten vs. flache Sub-Agenten-Teams (2026): tiefe Verschachtelung oder planbare Orchestrierung?"
description: "Claude Code 2.1.172 erlaubt fünf Verschachtelungsebenen. Rekursive Sub-Agenten vs. flache Teams im Vergleich: Kosten, Nachvollziehbarkeit, Denktiefe, Risiko 2026."
resource: "https://www.contextstudios.ai/de/vergleich/recursive-sub-agents-vs-flat-sub-agent-teams"
category: approach
language: de
timestamp: "2026-06-11T11:06:50.792Z"
---

# Rekursive Sub-Agenten vs. flache Sub-Agenten-Teams (2026): tiefe Verschachtelung oder planbare Orchestrierung?

Mit Claude Code 2.1.172 (Juni 2026) kam die bislang größte Änderung der Agenten-Architektur: Sub-Agenten können nun eigene Sub-Agenten starten, bis zu fünf Ebenen tief. Bis zu dieser Version war die Hierarchie bewusst flach – eine Hauptsitzung delegierte an Worker, und diese Worker konnten sich nicht weiter verschachteln. Das flache Modell wird weiterhin vollständig unterstützt, sodass Teams eine echte architektonische Wahl haben: Agenten in tiefe, selbstorganisierende Bäume verschachteln lassen oder einen einzelnen Orchestrator beibehalten, der an einen flachen Pool von Spezialisten verteilt. Der Zielkonflikt heißt Leistungsfähigkeit gegen Kontrolle. Rekursive Sub-Agenten können offene Probleme beliebig tief zerlegen, treiben aber die Token-Kosten in die Höhe und erschweren die Nachvollziehbarkeit. Flache Teams sind planbar, gut debugbar und günstiger, begrenzen jedoch, wie tief sich ein einzelner Gedankengang selbst organisieren kann. Dieser Vergleich bewertet beide Ansätze nach Zerlegungstiefe, Kosten, Nachvollziehbarkeit, Denkstärke, Eskalationsrisiko, Parallelität, Spezialisierung und Produktionsreife.

## Comparison Factors

| Factor | Rekursive Sub-Agenten | Flache Sub-Agenten-Teams | Winner |
|--------|------|------|--------|
| Zerlegungstiefe der Aufgabe | Sub-Agenten starten eigene Sub-Agenten bis zu 5 Ebenen tief und zerlegen offene Probleme beliebig tief | Auf eine Ebene begrenzt – ein einzelner Orchestrator verteilt an Worker, die sich nicht verschachteln können | a |
| Token-Kosten & Budget-Planbarkeit | Kontext wird auf jeder Ebene vererbt und verstärkt den etwa 15-fachen Multi-Agenten-Token-Faktor | Planbare, begrenzte Ausgaben – jeder Worker läuft einmal unter dem Orchestrator | b |
| Nachvollziehbarkeit & Debugging | Tiefe Bäume werden zu undurchsichtigen Ketten; schwer zu erkennen, welche Ebene ein Ergebnis verursacht hat | Klarer, flacher Knotengraph mit offensichtlichen Prüf- und Eingriffspunkten | b |
| Schwierigstes mehrstufiges Denken | Glänzt, wenn eine Teilaufgabe sich mitten in der Ausführung weiter zerlegen muss | Stark bei paralleler Arbeit, doch ein einzelner Worker kann sich nicht tiefer selbst organisieren | a |
| Eskalations- & Schadensradius-Risiko | Braucht ausdrückliche Abbruchgrenzen, sonst kann ein Zweig in Schleifen geraten und Budget verbrennen | Von Natur aus begrenzt – keine rekursive Explosion, die Hierarchie bleibt planbar | b |
| Paralleler Durchsatz | Verteilt in die Tiefe; viele Zweige laufen, doch der Koordinationsaufwand wächst | Verteilt in die Breite; unabhängige Worker laufen sauber und gleichzeitig | tie |
| Spezialisierung & Modellwahl pro Knoten | Jeder verschachtelte Knoten kann ein anderes Modell wählen (Haiku/Sonnet/Opus), passend zur Teilaufgabe | Worker wählen je Rolle, doch die Spezialisierung ist eine Ebene breit, nicht tief | a |
| Produktionsreife & Planbarkeit | Neu in 2.1.172 – mächtig, aber in Produktion weniger erprobt | Der dokumentierte, bewusst gewählte Standard; planbar und schwer zu brechen | b |

## Key Statistics

- Anthropics eigenes Multi-Agenten-Forschungssystem verbraucht etwa 15-mal mehr Token als ein Einzelagenten-Chat – der zentrale Kostenfaktor, sobald Sub-Agenten verzweigen oder verschachteln
- Dieselbe Multi-Agenten-Architektur erzielte in Anthropics interner Forschungsaufgaben-Auswertung 90,2 % bessere Ergebnisse als ein Einzelagent – der Mehrwert, der die Token-Kosten rechtfertigen kann
- Claude Code 2.1.172 (Juni 2026) erlaubt Sub-Agenten, eigene Sub-Agenten bis zu 5 Ebenen tief zu starten; vor dieser Version war Verschachtelung gesperrt und die Hierarchie bewusst flach
- Bei Anthropics angegebenem Durchschnitt von etwa 13 $ pro Entwickler und Tag kann der Betrieb von 5 gleichzeitigen Agenten die Tagesausgaben über etwa 50 $ treiben, und 10 parallele Agenten verbrauchen das Plan-Kontingent 10-mal schneller
- Praktiker berichten von Sub-Agenten, die schon beim Start über 25.000 Token verbrauchen, bevor sie echte Arbeit leisten – ein fester Kontext-Overhead, der sich mit jeder verschachtelten Ebene vervielfacht
- Vor 2.1.172 dokumentierte Claude Code Sub-Agenten als strikt nicht verschachtelbar – die flache Hierarchie war Absicht, um das System planbar zu halten, und etabliert flache Teams als Stabilitäts-Basislinie

## Choose Rekursive Sub-Agenten When

- Ihre Probleme sind tief und offen, sodass ein Worker mitten in der Aufgabe wirklich eigene Helfer starten muss
- Sie lösen die schwersten mehrstufigen Refactorings oder Recherchen, bei denen Denktiefe wichtiger ist als Breite
- Antwortqualität entscheidet, und Sie können sich den etwa 15-fachen Token-Faktor leisten
- Sie haben harte Tiefenlimits, Token-Budgets und Abbruchgrenzen eingerichtet, um ausufernde Rekursion einzudämmen

## Choose Flache Sub-Agenten-Teams When

- Sie betreiben Produktionsabläufe, bei denen planbare Kosten und Latenz am wichtigsten sind
- Sie brauchen klare Nachvollziehbarkeit und einfache Eingriffspunkte bei jedem Schritt
- Ihre Aufgaben lassen sich natürlich in unabhängige, klar umrissene Teilaufgaben parallelisieren
- Sie wollen den erprobten Standard, der schwer zu brechen und leicht zu debuggen ist

## Verdict

Es gibt keinen universellen Sieger – die Achse heißt Leistungsgrenze gegen operative Kontrolle. Rekursive Sub-Agenten sind die stärkere Wahl für die schwersten, offensten Aufgaben, bei denen ein Worker wirklich eigene Helfer starten muss und Denktiefe wichtiger ist als Breite. Doch sie erben auf jeder Ebene Kontext, verstärken den ohnehin etwa 15-fachen Token-Faktor von Multi-Agenten-Systemen und machen die Ausführung zu einer undurchsichtigen Kette, die schwer zu debuggen und ohne strikte Grenzen anfällig für Endlosschleifen ist. Flache Sub-Agenten-Teams bleiben aus gutem Grund der Produktionsstandard: planbare Kosten, klare Nachvollziehbarkeit, einfaches menschliches Eingreifen und eine Hierarchie, die schwer zu brechen ist. Das pragmatische Muster, das Context Studios bevorzugt: flache Teams als Standard beibehalten, jeden Knoten an das günstigste geeignete Modell leiten und Rekursion nur bei den wenigen Aufgaben einsetzen, deren Qualitätsgrenze – Anthropic maß 90,2 % bessere Ergebnisse von Multi-Agenten gegenüber Einzelagenten – die Kosten und den Verlust an Transparenz rechtfertigt.

## FAQ

**Q: Was hat sich in Claude Code 2.1.172 für Sub-Agenten geändert?**
A: Vor 2.1.172 konnten Sub-Agenten keine eigenen Sub-Agenten starten; die Hierarchie war bewusst flach (Hauptsitzung zu Workern), um das Verhalten planbar zu halten. Claude Code 2.1.172 (Juni 2026) erlaubt Sub-Agenten, Sub-Agenten bis zu 5 Ebenen tief zu starten, und ermöglicht so erstmals rekursive Orchestrierung. Flache Teams funktionieren weiterhin und bleiben für die meisten Produktionslasten die sicherere Wahl.

**Q: Sind rekursive Sub-Agenten teurer als flache Teams?**
A: In der Regel ja. Anthropics eigenes Multi-Agenten-Forschungssystem verbraucht etwa 15-mal mehr Token als ein Einzelagenten-Chat, und Rekursion verstärkt das, weil jede Ebene Kontext und Start-Overhead erbt – Praktiker berichten von über 25.000 Token vor jeder echten Arbeit. Flache Teams sind planbarer. Rekursion lohnt sich nur, wenn der Qualitätsgewinn (Anthropic maß 90,2 % bessere Ergebnisse) die Kosten rechtfertigt.

**Q: Wann sollte ich ein flaches Sub-Agenten-Team statt Verschachtelung nutzen?**
A: Nutzen Sie flache Teams, wenn sich Aufgaben sauber in unabhängige Teilaufgaben aufteilen, wenn Sie planbare Kosten und Latenz brauchen und wenn Nachvollziehbarkeit und menschliches Eingreifen zählen. Flach ist der dokumentierte, erprobte Standard; Verschachtelung bringt Leistung, aber auch Undurchsichtigkeit und Eskalationsrisiko – setzen Sie sie nur dort ein, wo wirklich Tiefe nötig ist.

**Q: Wie kontrolliere ich die Kosten rekursiver Sub-Agenten?**
A: Setzen Sie harte Tiefenlimits (2.1.172 begrenzt auf 5 Ebenen) und Token-Budgets, leiten Sie jeden Knoten an das günstigste geeignete Modell (Haiku für Lesevorgänge, Sonnet für Umsetzung, Opus für schweres Denken) und fügen Sie ausdrückliche Abbruchgrenzen hinzu, damit ein Zweig nicht in Schleifen gerät. Reservieren Sie tiefe Rekursion für die wenigen Aufgaben, die sie wirklich brauchen.