Multi-Agentensysteme im Jahr 2026: ReAct, Überwacher, Schwärme, LangGraph und Strands
Ein Leitfaden zu Mehr-Agenten-Steuerflussmustern – sequentiell, parallel, hub-and-spoke, grafisch, ereignisgesteuert, kritisch sowie mit menschlicher Beteiligung – und wie Frameworks wie LangGraph und Strands dazu passen.
Die nächste Phase der generativen KI umfasst nicht nur intelligentere Modelle. Es handelt sich dabei um Systeme, in denen mehrere Agenten reasoningfähig sind, Tools aufrufen können, Aufgaben delegieren, Ergebnisse überprüfen, von Fehlern wiederherstellen und koordinieren. Das ist das Gebiet der Multi-Agenten-Systeme (MAS).
Eine minimale LLM-Anwendung sieht wie ein einfacher Pfad vom Benutzer zum Modell aus:
User
↓
LLM
↓
Response
Ein produktionsreifes Multi-Agenten-Layout ist komplexer:
User
│
▼
┌─────────────┐
│ Orchestrator│
└──────┬──────┘
│
┌───────────┼───────────┐
▼ ▼ ▼
Research Risk Execution
Agent Agent Agent
│ │ │
└───────────┼───────────┘
▼
Verification
│
▼
Action
Es gibt kein einziges Muster. Häufige Strukturen umfassen ReAct-Agenten, sequentielle und parallele Pipelines, supervisorbasierte (Hub-and-Spoke)-Konzepte, Hierarchien, Übergabeprozesse, Schwärme, Trennungen zwischen Planer und Ausführender, grafenbasierte Arbeitsabläufe, ereignisgesteuerte Agenten, Kritiker-/Bewertungszyklen sowie Mechanismen für menschliche Einmischung. Frameworks wie LangGraph, Strands Agents und Amazon Bedrock AgentCore liefern Primitiven für diese Muster. Die folgenden Abschnitte trennen die Konzepte voneinander, damit Teams ungleiche Ansätze nicht als Konkurrenten betrachten.
1. Was ist ein Mehr-Agentensystem?
Ein Mehr-Agentensystem ist eine Zusammenarbeit spezialisierter Agenten zur Erreichung eines größeren Ziels. Anstelle dass ein einziges Modell alles übernimmt:
LLM
├── Research
├── Coding
├── Database
├── Security
├── Decision making
└── Execution
können die Verantwortlichkeiten aufgeteilt werden:
Supervisor
│
┌────────────────┼────────────────┐
▼ ▼ ▼
Research Agent Security Agent Execution Agent
│ │ │
▼ ▼ ▼
Search Security APIs
Tools Tools Tools
Jeder Agent kann eigene Anweisungen, Werkzeuge, Speicher, Kontextfenster, Modellwahl, Richtlinien, Aufgaben und Bewertungskriterien besitzen. Spezialisierung ist ein Hauptgrund, warum man auf Ein-Agenten-Designs verzichtet.
2> Mehr Agenten bedeuten nicht automatisch etwas Besseres
Zusätzliche Agenten erhöhen Kosten und Komplexität. Drei Agenten bedeuten oft drei Anfragen und drei Kontexte:
3 agents
↓
3 × prompts
3 × contexts
3 × tool interfaces
3 × failure surfaces
3 × observability requirements
Unterhaltende Netzwerke verstärken die Ausgaben und erschweren das Debuggen:
Agent A → Agent B
Agent B → Agent C
Agent C → Agent A
Agent A → Agent D
Agent D → Agent B
Ein solides Design fragt danach, welche Verantwortlichkeiten getrennt werden sollten und wie die Steuerung zwischen ihnen fließen muss.
3. ReAct-Agent
ReAct steht für Reason + Act. Der Kreislauf überlegt, wählt ein Werkzeug aus, beobachtet und setzt fort – zum Beispiel bei der Untersuchung ungewöhnlicher CPU-Nutzung in einer Datenbank:
Reason
↓
Call CloudWatch
↓
Observe CPU metrics
↓
Call logs
↓
Observe errors
↓
Reason
↓
Return diagnosis
Stärke: dynamische Auswahl des Werkzeugs, da der nächste Schritt von der letzten Beobachtung abhängt.
Schwäche: lange Schleifen erhöhen die Latenz, die Kosten sowie die Fehlerwahrscheinlichkeit. ReAct ist ein Denkmuster und nicht an sich bereits eine vollständige Multi-Agenten-Topologie.
4. Sequentielle Multi-Agenten-Architektur
Die einfachste Form einer Multi-Agenten-Architektur ist ein Pipeline-Modell:
Document Agent
↓
Extraction Agent
↓
Risk Agent
↓
Decision Agent
Ein bankähnlicher Ablauf könnte wie folgt aussehen:
Bureau Agent
↓
Policy Agent
↓
Risk Agent
↓
Decision Agent
Wann anwenden: Die Reihenfolge ist wichtig, die Ausgaben fließen in die nächste Stufe, der Workflow ist vorhersehbar und Audit-Spuren sind von Bedeutung.
Hauptbeschränkung: Ein Fehler in der Mitte kann die gesamte Abfolge lahmlegen – daher sind Wiederholversuche, Kontrollpunkte sowie Wiederherstellungsmöglichkeiten in der Produktion notwendig.
5. Parallel / Fan-out–Fan-in
Unabhängige Arbeiten müssen nicht nacheinander ausgeführt werden:
Agent A
↓
Agent B
↓
Agent C
Konkurrierende Spezialisten arbeiten gleichzeitig:
Supervisor
│
┌──────────┼──────────┐
▼ ▼ ▼
Agent A Agent B Agent C
│ │ │
└──────────┼──────────┘
▼
Aggregator
Eine Überprüfung der Cloud-Architektur kann Analyseagenten verteilen:
Architecture Request
│
┌──────────────┼──────────────┐
▼ ▼ ▼
Cost Agent Security Agent Performance Agent
│ │ │
└──────────────┼──────────────┘
▼
Architecture Agent
danach werden die Erkenntnisse zusammengefasst.
Vorteil: kürzere Gesamtlaufzeit. Herausforderung: Die Zusammenfassung muss zuverlässig erfolgen.
6. Hub-and-Spoke / Supervisor
Ein zentraler Supervisor leitet Aufgaben an Spezialisten weiter:
Supervisor
│
┌─────────────────┼─────────────────┐
▼ ▼ ▼
Research Coding Finance
Agent Agent Agent
│ │ │
Tools Tools Tools
Bei einer Benutzeranfrage:
User:
"Analyze this AWS account and identify security and
cost problems."
kann der Supervisor wie folgt vorgehen:
Supervisor
│
├──→ Security Agent
│
└──→ FinOps Agent
│
▼
Aggregator
│
▼
Report
Vorteil: zentrale Steuerung. Herausforderung: Der Hub wird zu einem Engpass sowie zu einer kritischen Infrastruktur, wenn jede Entscheidung durch ihn geht:
Agent A ─┐
Agent B ─┼──→ Supervisor
Agent C ─┤
Agent D ─┘
7. Hierarchische Multi-Agenten-Architektur
Falls ein Supervisor nicht ausreicht, fügen Sie weitere Ebenen hinzu:
Global Supervisor
│
┌───────────┴───────────┐
▼ ▼
Engineering Lead Business Lead
│ │
┌────┴────┐ ┌────┴────┐
▼ ▼ ▼ ▼
Coding Testing Finance Risk
Unternehmensclouds verwenden oft mehrere Supervisoren:
Enterprise Agent
│
├── Cloud Supervisor
│ ├── Security Agent
│ ├── FinOps Agent
│ └── Operations Agent
│
└── Application Supervisor
├── Coding Agent
├── Testing Agent
└── Documentation Agent
Die Struktur ähnelt Organigrammen; der Aufwand besteht in größerem Koordinationsaufwand.
8. Architektur auf Basis von Übergaben
Ein Agent überträgt die Verantwortung für das Gespräch an einen anderen:
Agent A
│
│ handoff
▼
Agent B
│
│ handoff
▼
Agent C
In der Kundenbetreuung werden technische Probleme oft weitergeleitet:
Customer Agent
│
│ technical issue
▼
Technical Agent
│
│ billing issue
▼
Billing Agent
Im Gegensatz zu einem dauerhaften Supervisor wird der Empfänger zum aktiven Verantwortlichen – nützlich für Kundenbetreuung, spezialisierte Weiterleitungen, Domänenassistenten und konversationelle Arbeitsabläufe.
9. Schwarmarchitektur
Schwärme vermeiden ein ständiges Zentrum. Die Agenten arbeiten dynamisch zusammen:
Agent A
↙ ↘
Agent B ←→ Agent C
↘ ↙
Agent D
Jeder kann entscheiden, dass ein anderer Peer besser geeignet ist. Mit Flexibilität kommen schwierige Fragen: Wer kontrolliert das System? Ohne Grenzen drohen Schleifen, doppelte Arbeit, ein Übermaß an Kontexten, unvorhersehbare Abläufe sowie hohe Berechnungskosten. Eine starke Zustandsverwaltung und klare Beendigungsbedingungen sind unerlässlich.
10. Architektur von Planer und Ausführender
Trennen Sie Planung von Ausführung:
User Goal
│
▼
Planner
│
┌────────┼────────┐
▼ ▼ ▼
Task 1 Task 2 Task 3
│ │ │
▼ ▼ ▼
Executor Executor Executor
│ │ │
└────────┼────────┘
▼
Result
Für den Auftrag „Diese Anwendung auf AWS migrieren“ könnte ein Planer Schritte festlegen:
1. Analyze application
2. Identify dependencies
3. Design AWS architecture
4. Estimate cost
5. Generate Terraform
6. Validate Terraform
Dann führen die Ausführenden jeweils einen Schritt aus. Dies ist nützlich, wenn komplexe Ziele in explizite Aufgaben zerlegt werden können.
11. graphbasierte Agenten
Framework wie LangGraph eignen sich hier hervorragend. Anstelle einer lockeren Kette:
Agent → Agent → Agent
denken Sie an einen Zustandsgraphen:
START
│
▼
Research
│
┌──────┴──────┐
▼ ▼
Valid Invalid
│ │
▼ ▼
Analysis Research
│
▼
Verification
│
▼
END
Knoten können Agenten, Tools, Funktionen, Validatoren, menschliche Genehmigungen oder Router sein. Der gemeinsame Zustand zusammen mit expliziten Kanten bieten mehr Kontrolle, als wenn ein Modell bei jeder Übergangssituation improvisieren muss.
12. Strands Agents
AWS Strands Agents ist ein SDK für agentenbasierte Tools. Konzeptionell gesehen:
Agent
│
┌───────┼────────┐
▼ ▼ ▼
Tool Tool Tool
│ │ │
▼ ▼ ▼
AWS APIs Databases
Agenten handeln auf der Grundlage von Tools und gehen aus Beobachtungen hervor. Strands können auch innerhalb mehrerer Agentenstrukturen verwendet werden:
Supervisor Agent
│
┌─────┼─────┐
▼ ▼ ▼
AWS SQL Research
Agent Agent Agent
Wichtiger Unterschied: Strands ist ein Framework/SDK; supervisor hingegen ein architektonisches Muster. Beide ergänzen sich, sind aber keine Konkurrenten.
13. LangGraph Agents
LangGraph legt Wert auf explizite, zustandsbasierte Workflows in Form von Graphen:
START
│
▼
Supervisor
│
├──────→ Research Agent
│
├──────→ Data Agent
│
└──────→ Security Agent
│
▼
Validator
│
┌───┴───┐
▼ ▼
Success Retry
│
▼
END
Man definiert den Zustand, Knoten, Kanten, bedingte Routing-Regeln, Kontrollpunkte, Wiederholungsversuche, menschliche Genehmigungen sowie die Persistenz – also jene Kontrolle, die Produktivsysteme benötigen.
14. ereignisgesteuerte Mehr-Agentensysteme
Nicht jeder Ablauf ist synchron. Ereignisse können Agenten aktivieren:
AWS Event
│
▼
EventBridge
│
├────→ Security Agent
│
├────→ FinOps Agent
│
└────→ Operations Agent
Beispiel für Operationen:
CloudWatch Alarm
↓
EventBridge
↓
Incident Agent
↓
RCA Agent
↓
Remediation Agent
↓
Human Approval
↓
AWS API
Nützlich für Cloud-Operationen, Sicherheitsüberwachung, Incidents Response, FinOps und Automatisierung.
15. Kritiker-/Bewertungsarchitektur
Ein Agent erzeugt; ein anderer bewertet:
Generator Agent
│
▼
Generated Result
│
▼
Critic Agent
│
┌──┴──┐
▼ ▼
Pass Fail
│ │
▼ ▼
Done Retry
Beispiel für eine Architekturprüfung:
Architecture Agent
↓
AWS Architecture
↓
AWS Best-Practice Evaluator
↓
Pass?
/ \
Yes No
↓ ↓
Done Revise
Weil die Ausgabe eines Modells nicht automatisch vertrauenswürdig ist, dient der Bewertungskomponente als Qualitätskontrolle.
16. Mehr-Agentensysteme mit menschlicher Beteiligung
Vollständige Autonomie ist bei hochwirksamen Änderungen nicht immer angebracht:
Agent
↓
Analyze
↓
Recommend
↓
Human Approval
↓
Execute
Beispiel für Sicherheitsbehebungen:
Security Agent
↓
Detect vulnerable resource
↓
Remediation Agent
↓
"Delete public access?"
↓
Human Approval
↓
AWS API
KI schlägt vor, was getan werden könnte. Richtlinien in Kombination mit menschlicher Genehmigung entscheiden, was tatsächlich geschehen darf.
17. Die wichtige Taxonomie
Diese Konzepte existieren auf verschiedenen Ebenen:
MULTI-AGENT SYSTEM
│
┌────────────────┼────────────────┐
│ │ │
Architecture Reasoning Framework
Pattern Pattern / Runtime
│ │ │
▼ ▼ ▼
Supervisor ReAct LangGraph
Sequential Plan-Execute Strands
Parallel Critic Bedrock
Hierarchical AgentCore
Handoff
Swarm
Event-driven
Diese Struktur verhindert falsche Vergleiche wie „LangGraph gegen Supervisor gegen ReAct“, als wären es drei konkurrierende Produkte.
18. Wie sie kombiniert werden
Kraft zeigt sich in der Kombination:
User
│
▼
Supervisor
│
┌──────────┼──────────┐
▼ ▼ ▼
Research Risk Execution
Agent Agent Agent
│ │ │
ReAct ReAct ReAct
│ │ │
└──────────┼───────────┘
▼
Critic
│
┌────┴────┐
▼ ▼
Pass Fail
│ │
▼ ▼
End Retry
Ein einziges Design kann Supervisor-Orchestrierung, parallele Ausbreitung, ReAct-Logik, Kritikerbewertungen sowie Wiederholungsversuche miteinander verbinden – und zwar mit LangGraph, Strands, Bedrock, AgentCore, Step Functions oder benutzerdefiniertem Code.
Muster unter Einschränkungen auswählen
Die Budgets für Latenz, Tokens und die Komplexität bei Notfallinterventionen sollten die Topologie bestimmen. Ein sequentieller Pipeline ist leichter zu prüfen, wenn die Aufsichtsbehörden auf die Reihenfolge achten. Ein Fan-out ist nützlich, wenn unabhängige Analysen den größten Teil der Arbeitszeit einnehmen. Supervisor helfen, wenn die Routing-Strategie zentral gehalten werden muss. Graphen sind hilfreich, wenn Kontrollpunkte und menschliche Überprüfungen erforderlich sind. Swarms sowie freie Übergabemethoden erfordern die stärkste Investition in die Überwachbarkeit. Wählen Sie das leichteste Control-Plane, das den Fehlermodi dennoch klar darstellt.
19. Welche Architektur sollten Sie verwenden?
Es gibt keinen universellen Gewinner. Passen Sie den Kontrollfluss zum Problem an. Die richtige Frage lautet nicht „Welches Framework ist am besten?“, sondern „Welches Kontrollflussmuster erfordert dieser Workflow?“
20. Die sich entwickelnde Produktionsarchitektur
Produktionsysteme umgeben Agenten mit Identität, Berechtigungen, Werkzeugen, Zustand, Speicher, Schutzmaßnahmen, Bewertungsmöglichkeiten, Überwachungsfunktionen, Wiederholungsversuchen, Kosteneinschränkungen sowie menschlicher Freigabe. Die Branche wandelt sich von „einem Agenten“ hin zu „einem Agentensystem“.
21. Fazit
Mehr-Agenten-Arbeit bedeutet die Aufteilung von Intelligenz und die Steuerung der Zusammenarbeit – nicht das Erstellen von Agenten um ihrer selbst willen. ReAct denkt und handelt; Überwacher delegieren Aufgaben; Graphen steuern Übergänge; Schwärme dezentralisieren; Planer zerlegen Aufgaben; Kritiker überprüfen; Menschen geben die Freigabe. LangGraph und Strands (unter anderem) bieten Implementierungsprimitiven. Die ingenieurtechnischen Fragen lauten: Welche Agenten existieren, wie arbeiten sie zusammen, was können sie tun, wie werden Entscheidungen überprüft und was passiert bei Fehlern?
Das zu merkende mentale Modell
LLM
↓
Agent
↓
Multi-Agent
↓
Orchestration
↓
Tools + Memory + State
↓
Verification
↓
Observability
↓
Production Agent System
Teams, die diesen Systemüberblick überspringen, skalieren oft die Größe des Modells, während Orchestrierung, Berechtigungen und Bewertung erst an letzter Stelle berücksichtigt werden. Diese Lücken zeigen sich in fehlerhaften Ergebnissen ohne Warnsignale, unkontrollierten Tool-Schleifen oder Agenten, die nicht sicher zurückgesetzt werden können. In Investitionen in Ablaufsteuerung, Überprüfung und menschliche Kontrollmechanismen liegt in der Regel mehr Nutzen als beim einfachen Austausch eines Modells.
Die Zukunft gehört nicht nur intelligenteren Modellen – sie gehört auch besseren Systemen, die auf ihnen basieren.