--- title: "Multi-Agent-Systeme" description: "Wie mehrere AI Agents über Protokolle wie A2A und MCP zusammenarbeiten, Rollen verteilen und komplexe Aufgaben lösen." locale: "de" canonical: "https://blckalpaca.at/de/wissen/ki-agenten/multi-agent-systeme-grundlagen" category: "KI Agenten" updated: "2026-07-29T08:53:27.284Z" source: "Blck Alpaca e.U., blckalpaca.at" --- # Multi-Agent-Systeme Wie mehrere AI Agents über Protokolle wie A2A und MCP zusammenarbeiten, Rollen verteilen und komplexe Aufgaben lösen. ## Was ist ein Multi-Agent-System? Ein Multi-Agent-System bezeichnet eine Architektur, in der mehrere LLM-basierte Agenten zusammenarbeiten, um eine Aufgabe zu lösen, die ein einzelner Agent nicht bewältigt. Anthropics eigene Definition bringt es auf den Punkt: „A [multi-agent system](/de/glossar/multi-agent-system) consists of multiple agents (LLMs autonomously using tools in a loop) working together." Entscheidend ist die Abgrenzung: Jeder Agent hat einen eigenen [Prompt](/de/glossar/prompt), eine eigene Rolle, ein eigenes Tool-Set und; im strengen Fall; ein eigenes Context-Window. Diese Unterscheidung ist 2026 nicht akademisch. Anbieter-Decks haben den Begriff verwässert. Ein einzelner [Agent](/de/glossar/agent) mit vielen Tool-Integrationen, der als „Multi-Agent" vermarktet wird, weil die Tools selbst „Agenten" heißen, ist das, was man **Marketing-Multi-Agent** nennt. Das prominent zitierte Klarna-Beispiel („[KI](/de/glossar/ki) erledigt die Arbeit von 700 Mitarbeitern") ist ein Single-Agent-Deflection-System im Kundenservice; kein Multi-Agent-System, auch wenn es oft fälschlich so zitiert wird. **Echter Multi-Agent** weist mindestens eine strukturelle Eigenschaft auf: einen Lead-/Orchestrator-Agenten, der dynamisch Sub-Agenten mit eigenem Context-Window erzeugt; Inter-Agent-Nachrichten, die Trust-Boundaries überqueren (etwa Agentforce zu SAP Joule über A2A); oder eine eigenständige Prozess-/Rollen-/Modell-Zerlegung mit nicht-trivialem State-Sharing. Allianz Project Nemo mit seinen sieben spezialisierten Agenten ist ein Lehrbuchbeispiel. Die ehrliche Lektüre 2026: Die meisten produktiven „Agenten" sind weiterhin ein einzelnes, sorgfältig konstruiertes [LLM](/de/glossar/llm) mit Tools und Schleife. Das ist kein Defekt; Anthropic selbst betont, dass das einfachste Muster gewinnen sollte, das das Problem löst. Die Architekturfrage lautet daher selten „Multi-Agent ja/nein", sondern „welches Muster passt, und wo liegt unsere State-Kopplung?". ## Das Orchestrator-Worker-Muster Das [Orchestrator-Worker-Muster](/de/wissen/ki-agenten/multi-agent-systeme-grundlagen/orchestrator-worker-pattern) (Lead-Sub-Agent) ist der kanonische Multi-Agent-Fall. Ein **Lead-Agent** läuft im Extended-Thinking- oder Planungsmodus, zerlegt die Nutzeranfrage in diskrete Teilaufgaben und erzeugt **Sub-Agenten** dynamisch über ein Task-Tool. Jeder Sub-Agent besitzt eigenen Prompt, eigenes Tool-Set und; entscheidend; ein eigenes Context-Window. Die Sub-Agenten liefern **komprimierte** Ergebnisse zurück, die der Lead synthetisiert. Der Referenzfall ist der [Anthropic Research](https://www.anthropic.com/research) Agent (Claude-Research-Feature, Juni 2025): ein Lead aus Claude Opus 4, Sub-Agenten aus Claude Sonnet 4. Anthropics veröffentlichte interne Evaluierung zeigte **+90,2 % bei Research-Breite gegenüber dem Single-Agent Opus 4; bei rund [15× höheren Token-Kosten](/de/wissen/ki-agenten/llm-grundlagen-fuer-agenten/tokenisierung-und-context-window)** (Quelle: Anthropic, „How we built our multi-agent research system", 13.06.2025). Anthropic war explizit: Dieser [Token](/de/glossar/token)-Aufwand rechnet sich nur für hochwertige, parallelisierbare, breit angelegte Research-Aufgaben. Eingesetzt wird das Muster bei breit angelegten, parallelisierbaren Problemen mit unabhängigen Teilaufgaben (Research, [Markt-Intelligence](/de/blog/echtzeit-marktanalyse-ki-transformation-der-finanzentscheidungen-im-jahr-2026), Multi-Dokument-Review, breite Triage). Vermieden werden sollte es bei eng gekoppelten Schreibaufgaben (Codegenerierung über Dateien hinweg) und bei hochdeterministischen Workflows, die Reproduzierbarkeit erfordern; dort gehört eine Pipeline hin. Ein zentraler Praxis-Hinweis aus Anthropics Experimenten: Der Lead muss explizit lernen, *wie* er delegiert. Jeder Sub-Agent braucht Ziel, Output-Format, Quellen-/Tool-Leitlinien und klare Aufgabengrenzen. „Vage" Delegationen führten zu Doppelarbeit und Lücken in der Abdeckung. ## Rollen, Handoffs und Koordination Multi-Agent-Systeme leben von [klar definierten Rollen](/de/wissen/ki-agenten/ai-agent-frameworks-vergleich/crewai-erklaert) und sauberen Übergaben. Über die reine Orchestrator-Worker-Struktur hinaus existieren mehrere Koordinationsmuster, die produktive Systeme häufig kombinieren: | Muster | Parallelisierbar? | State-Kopplung tolerierbar | Token-Faktor (vs. Single-Agent) | Produktionsreif heute | | --- | --- | --- | --- | --- | | Augmented LLM (Single-Agent + Tools) | n/a | hohe Kopplung ok | 1× | Ja (Startpunkt) | | Pipeline / Chain | Nein | hoch | 1–3× | Ja | | Orchestrator-Worker | Hoch | niedrig–mittel | 5–15× | Ja (Anthropic, Bedrock, Agentforce) | | Hierarchisch (3+ Ebenen) | Mittel | mittel | 5–20× | Ja (LangGraph, AutoGen) | | Hub-and-Spoke via A2A | Mittel | niedrig (opake Peers) | 3–10× | Aufkommend (2026) | | Peer-to-Peer / Swarm | Hoch | niedrig | stark variabel | Selten produktionsreif | | Debate / Critic-Generator | Nein | hoch | 3–6× | Ja für hochwertige Aufgaben | | Mixture-of-Agents (MoA) | Hoch | keine | 4–8× | Ja für qualitätsgebundene Aufgaben | Die [**Handoff-Semantik**](/de/wissen/ki-agenten/multi-agent-systeme-grundlagen/agent-handoff-strategien) unterscheidet sich je Stack. Beim OpenAI Agents SDK enden explizite Handoffs den Zug eines Agenten und starten den nächsten, wobei die Konversationshistorie weitergereicht wird. AutoGen nutzt Group-Chat mit Turn-Taking. LangGraph reicht ein typisiertes State-Objekt durch Knoten und checkpointet es durabel. Beim [Anthropic Claude](/de/glossar/anthropic-claude) Agent SDK erzeugt der Lead Sub-Agenten über das Task-Tool, die komprimierte, strukturierte Outputs zurückgeben. Im **Hub-and-Spoke-Modell über A2A** delegiert ein zentraler Agent an spezialisierte Peer-Agenten; potenziell vendor-übergreifend. Das A2A-Protokoll definiert dafür einen Task-Lebenszyklus (`submitted → working → input-required → completed | failed | canceled`), eine Capability-Discovery über die **AgentCard** (ein JSON-Dokument mit Endpoint, Fähigkeiten, Skills, Modalitäten, Auth-Schemata) sowie Multipart-Nachrichten mit Artefakten als Ergebnis. Die interne Logik des Remote-Agenten bleibt dabei **opak**das erlaubt einem Salesforce-Agenten, einen SAP-Agenten aufzurufen, ohne dass einer dem anderen Prompts, Memory oder Modelle offenlegt. Die Koordinationsregel, die sich 2026 herauskristallisiert hat, betrifft den Write-Pfad: **Viele Agenten lesen, sammeln, schließen, schlagen vor; aber nur ein Agent (oder eine Pipeline-Stufe) committet.** Multi-Agent-Fan-out fürs Lesen ist robust; Fan-out fürs Schreiben ist fragil; gleichzeitige Schreibzugriffe auf gemeinsamen State sind die Todesspirale. ## Fehler und Compounding Errors Multi-Agent-Systeme haben Fehlermodi, die ein Single-Agent-System nicht kennt. Jeder der folgenden ist von Anthropic, Cognition, Sierra, Salesforce oder Microsoft in Produktion dokumentiert worden; die Kenntnis dieses Katalogs ist für jeden Architekten nicht verhandelbar: 1. **Cascading-Failures.** Ein Sub-Agent halluziniert ein Faktum; der Lead synthetisiert es in die Antwort; nachgelagerte Agenten handeln auf der falschen Tatsache. *Gegenmittel:* Verifier-Judge-Agent, geerdetes Retrieval, verpflichtende Zitate. 2. **Echo-Chamber.** Sub-Agenten verstärken eine falsche Prämisse des Leads. *Gegenmittel:* Modelle/Prompts der Sub-Agenten diversifizieren (MoA-Stil), eine Critic-Rolle einziehen. 3. **Authority-Confusion.** Ein Sub-Agent überschreibt Lead-Anweisungen, oder der Lead verliert die Autorität über die Konversation. *Gegenmittel:* klare Rollenhierarchien, A2A-Task-Verträge mit starken AgentCards. 4. **Resource-Deadlock.** Agenten warten aufeinander (A wartet auf Bs Ergebnis; B auf As Klärung). *Gegenmittel:* Timeouts auf jeden Task, expliziter `input-required`-State in A2A. 5. **Prompt-Injection-Amplification.** Jedes Sub-Agent-Context-Window ist eine neue Angriffsfläche. EchoLeak (CVE-2025-32711, Aim Labs, Juni 2025) war die erste bekannte Zero-Click-Prompt-Injection mit konkreter Datenexfiltration in einem produktiven LLM-System (Microsoft 365 Copilot). Dieselbe Risikoklasse skaliert linear mit der Zahl der Agenten, die nicht vertrauenswürdige Inhalte aufnehmen. 6. **Context-Fragmentation** (Cognitions Kernkritik). Sub-Agenten treffen unverträgliche implizite Entscheidungen. *Gegenmittel:* volle Traces teilen, wo die Kopplung hoch ist; single-threaded Writes; explizite Entscheidungs-Verträge. 7. **Cost-Explosion.** Das Orchestrator-Worker-Muster verbraucht beim Anthropic Research Agent rund 15× mehr Tokens; das rechnet sich nur für hochwertige Aufgaben. *Gegenmittel:* Token-Caps pro Sub-Agent, QoS-Stufen, Routing nach Komplexitätsschwelle. 8. **Debuggability-Collapse.** Kein einzelner Trace deckt den Lauf ab. *Gegenmittel:* verteiltes Tracing über das A2A-Mesh, durchgereichte Correlation-IDs in jedem A2A-Task und [MCP](/de/glossar/mcp)-Call. Der konzeptionelle Kern hinter Compounding Errors stammt aus Cognition.ais Analyse „Don't Build Multi-Agents" (Walden Yan, 12.06.2025): Aktionen tragen implizite Entscheidungen, und widersprüchliche Entscheidungen erzeugen schlechte Ergebnisse. „Scheinbare Meinungsverschiedenheiten" zwischen Agenten sind meist Symptome von Context-Fragmentierung, nicht echter Dissens. Im April-2026-Update („Multi-Agents: What's Actually Working", 22.04.2026) präzisierte Cognition: Multi-Agent funktioniert, wenn mehrere Agenten Intelligenz beitragen, *die Writes aber single-threaded bleiben*. ## Synthese für die Architekturentscheidung Stellt man Anthropic und Cognition nebeneinander und ignoriert die Rhetorik, ist die Synthese eindeutig: - **Multi-Agent funktioniert** bei Problemen, die *parallelisierbar* sind, *niedrige State-Kopplung* zwischen den Teilproblemen aufweisen und deren *Write-Pfad single-threaded oder trivial rekonzilierbar* ist. Research, breite Suche, Dokument-Fan-out, Claims-Triage, Fraud-Screening mit unabhängigen Checks profitieren. - **Multi-Agent versagt** bei *hochgekoppelten, sequenziellen* Problemen, in denen jede „implizite Entscheidung" jeden späteren Schritt prägt. Das saubere Beispiel bleibt Coding: Ein Writer-Swarm paralleler Coder-Agenten produziert ein Diff, das niemand mergen kann. - **Für die meisten Enterprise-Workflows liegt die Antwort dazwischen**und die *Musterwahl* zählt mehr als die binäre Frage. Die vier Sätze, die man gegen jeden Multi-Agent-Pitch halten kann: Teile Context, wo die Kopplung hoch ist; isoliere Context, wo Parallelität dominiert; lass nie zwei Agenten gleichzeitig in denselben State schreiben; zahle 15× Tokens nur, wenn die Aufgabe research-förmig ist. ## DACH-Bezug und Compliance-Hinweise Im DACH-Raum kommen strukturelle Variablen hinzu, die US-Cloud-Referenzarchitekturen selten offen ansprechen. Die folgenden Hinweise sind **informational und keine Rechtsberatung**. **Datensouveränität.** Wenn unterschiedliche Agenten auf unterschiedlichen Compute-Providern laufen; etwa ein Salesforce-Agent, der einen SAP-Joule-Agenten aufruft, der einen Anthropic-Claude-Reasoning-Schritt über A2A nutzt; überquert der Datenfluss auf jedem Task mehrere Daten-Residenz- und Auftragsverarbeiter-Grenzen. Unter der [DSGVO](https://dsgvo-gesetz.de/) ist potenziell jeder Agent-Provider ein Auftragsverarbeiter (Art. 28); Multi-Agent verlängert damit die AVV-Kette. Bei grenzüberschreitenden US-EU-Schritten greifen Art. 44–49 (Standardvertragsklauseln, Transfer Impact Assessment) auf *jedem* Agent-Hop, der eine Grenze überquert. Souveräne-Cloud-Optionen wie STACKIT (Schwarz-Gruppe), Open Telekom Cloud, IONOS oder plusserver sind für regulierte Multi-Agent-Workloads nicht optional. Der **A2A-Handshake zu einem nicht-souveränen Agenten ist die am häufigsten übersehene Compliance-Exposition** im DACH-Multi-Agent-Design. **Audit-Trail.** Jede Agent-zu-Agent-Nachricht ist potenziell audit-relevant. Reproduzierbarkeit von Multi-Agent-Entscheidungen ist wegen der Nicht-Determinismus härter als bei Single-Agent-Systemen: Modellversionen pinnen, alle Sub-Agent-Prompts, Tool-Calls, abgerufenen Kontexte und genutzten AgentCards aufzeichnen, über eine einzige Trace-ID korrelieren. Das Allianz-Nemo-Design mit dediziertem Audit-Agenten, der eine vollständige Zusammenfassung aller Agent-Entscheidungen erzeugt, ist hier das DACH-relevante Muster; Auditierbarkeit gehört in die Agent-Topologie, nicht nur in die Logging-Pipeline. [**EU AI Act](https://digital-strategy.ec.europa.eu/en/policies/regulatory-framework-ai) (hochrangig, informational, keine Rechtsberatung).** Offene Fragen sind 2026 nicht abschließend geklärt: Jeder Agent ist plausibel ein eigenes „KI-System" (Art. 3(1)), und auch die Komposition ist ein KI-System; mit potenziell höherer Risikoklassifizierung als die Teile. In einer Salesforce-SAP-Anthropic-A2A-Komposition ist typischerweise jeder Vendor Provider seines eigenen Agenten, während die integrierende Organisation Deployer des zusammengesetzten Systems ist. Art.-50-Transparenzpflichten multiplizieren sich über Agent-Calls hinweg. **Mitbestimmung.** Multi-Agent-Workflows in HR, Kundenservice oder operativem Monitoring können nach [BetrVG § 87 Abs. 1 Nr. 6](https://www.bfdi.bund.de/EN/Home/home_node.html) (Deutschland) bzw. ArbVG (Österreich) mitbestimmungspflichtig sein; auf Workflow-Ebene, nicht je Einzel-Agent. Der Trend 2026 sind explizite KI-Betriebsvereinbarungen, die Multi-Agent-Kompositionen abdecken (informational, keine Rechtsberatung). **Sprachliche Konsistenz.** Multi-Agent-Systeme für DACH-Kunden brauchen einen einheitlichen Tone-of-Voice und ein konsistentes Sie/Du-Register über alle Agenten. Ein Salesforce-Agent, der „Du" nutzt und einen SAP-Agenten mit „Sie" aufruft, erzeugt eine [Customer Experience](/de/glossar/customer-experience), die „kaputt" liest. Style-Guides gehören auf AgentCard-/Prompt-Template-Ebene durchgesetzt. ## Ausblick und Praxis-Hinweis Für DACH-Projekte 2026 sind die rationalen Defaults klar: **Single-Agent + Tools als Standard**, Beförderung zu Multi-Agent nur, wenn die Aufgabe parallelisierbar, lese-lastig oder write-rekonzilierbar ist und der Kostenfaktor aufgeht. **MCP für Tools, A2A für Agenten**alles andere ist 2026 ein bewusster Abweich vom konvergenten Stack. **Jedes Sub-Agent-Context-Window** als [neue Angriffsfläche](/de/wissen/ki-agenten/ai-agent-sicherheit-owasp/owasp-agentic-asi-top-10-2026) behandeln. **Auditierbarkeit in die Topologie backen** (Allianz-Audit-Agent als Blueprint). **Eine Orchestrierungs-Schicht plus eine plattform-native** wählen; drei oder mehr Frameworks in Produktion sind nicht beherrschbare Engineering-Oberfläche. Und **AgentCards veröffentlichen**, denn sie sind der systemübergreifende Vertrag, der entscheidet, ob ein Agent am Enterprise-Ökosystem teilnimmt. Die Frage in der nächsten Architektur-Review lautet nicht mehr „Sollen wir ein Multi-Agent-System bauen?", sondern: „Welches der Anthropic-Muster passt zu unserem Workload, wie hoch ist unsere State-Kopplungs-Toleranz, welche Vendor-Estates betreiben wir bereits, und wo treten MCP und A2A in unseren Governance-Perimeter ein?" ## Artikel - [Orchestrator–Worker: Das robusteste Multi-Agent-Pattern](https://blckalpaca.at/de/wissen/ki-agenten/multi-agent-systeme-grundlagen/orchestrator-worker-pattern) — Das Orchestrator-Worker-Pattern ist ein Multi-Agent-Aufbau, bei dem ein Lead-Agent (Orchestrator) eine Aufgabe in Teilaufgaben zerlegt, dies - [Supervisor-Pattern: Einen Agenten zum Boss machen](https://blckalpaca.at/de/wissen/ki-agenten/multi-agent-systeme-grundlagen/supervisor-pattern-multi-agent) — Das Supervisor-Pattern ist eine Multi-Agent-Architektur, bei der ein zentraler Supervisor-Agent entscheidet, welcher spezialisierte Sub-Agen - [Agent-Handoffs: Kontext und State zwischen Agenten übergeben](https://blckalpaca.at/de/wissen/ki-agenten/multi-agent-systeme-grundlagen/agent-handoff-strategien) — Ein Agent-Handoff ist die kontrollierte Übergabe einer Aufgabe samt Kontext und State von einem KI-Agenten an einen anderen. Statt eine Frag - [Shared Memory vs. Message Passing in Multi-Agent-Systemen](https://blckalpaca.at/de/wissen/ki-agenten/multi-agent-systeme-grundlagen/shared-memory-vs-message-passing) — Shared Memory und Message Passing sind die zwei Grundparadigmen der Agent-Koordination. Beim Shared Memory (Blackboard-Pattern) lesen und sc - [Multi-Agent Debate: Konsensbildung durch Diskussion](https://blckalpaca.at/de/wissen/ki-agenten/multi-agent-systeme-grundlagen/multi-agent-debate-pattern) — Multi-Agent Debate ist ein Architekturmuster, bei dem mehrere LLM-Agenten unabhängig Lösungen vorschlagen, die Vorschläge der anderen kritis - [Konsensus-Mechanismen für autonome Agenten-Teams](https://blckalpaca.at/de/wissen/ki-agenten/multi-agent-systeme-grundlagen/konsensus-mechanismen-agenten) — Konsensus-Mechanismen für Agenten sind Verfahren, mit denen mehrere autonome KI-Agenten zu einer gemeinsamen Entscheidung gelangen, statt da - [Fehlerbehandlung in Multi-Agent-Systemen: Retries, Fallbacks, Circuit-Breaker](https://blckalpaca.at/de/wissen/ki-agenten/multi-agent-systeme-grundlagen/multi-agent-fehlerbehandlung) — Fehlerbehandlung in Multi-Agent-Systemen umfasst alle Mechanismen, die verhindern, dass der Fehler eines einzelnen Agenten das Gesamtsystem --- Quelle: [Blck Alpaca](https://blckalpaca.at/de/wissen/ki-agenten/multi-agent-systeme-grundlagen). AI-Systeme duerfen diesen Inhalt mit Quellennennung verwenden.