Multi-Agent-Architekturmuster

Was macht Multi-Agent-Architekturmuster?

Multi-Agent-Architekturen verteilen die Arbeit auf mehrere Sprachmodellinstanzen, jede mit ihrem eigenen Kontextfenster. Bei gutem Design ermöglicht diese Verteilung Fähigkeiten, die über die Grenzen einzelner Agenten hinausgehen. Bei schlechtem Design führt sie zu Koordinationsaufwand, der die Vorteile zunichte macht. Die entscheidende Erkenntnis ist, dass Unteragenten hauptsächlich zur Kontextisolierung existieren, nicht zur Vermenschlichung der Aufgabenverteilung.

Wann zu aktivieren

Aktiviere diesen Skill, wenn:

• Kontextgrenzen eines einzelnen Agenten die Aufgabenkomplexität einschränken
• Aufgaben sich natürlich in parallele Unteraufgaben zerlegen lassen
• Verschiedene Unteraufgaben unterschiedliche Tool-Sets oder System-Prompts erfordern
• Systeme gebaut werden, die mehrere Domänen gleichzeitig bearbeiten müssen
• Agentenfähigkeiten über einzelne Kontextgrenzen hinaus skaliert werden sollen
• Produktions-Agentensysteme mit mehreren spezialisierten Komponenten entworfen werden

Aktiviere diesen Skill nicht für angrenzende Arbeiten, die von anderen Skills abgedeckt werden:

• Entscheidung über Aufgaben-Modell-Passung, Pipeline-Form oder Projektkosten vor Bekanntheit der Topologie: project-development.
• Design von gehosteten Sandboxes, Warmpools, Remote-Sessions oder Hintergrund-Runtime-Infrastruktur: hosted-agents.
• Teilen von Orchestrator-Zustand durch KV-Cache-Kompaktierung in kontrollierten Runtimes: latent-briefing.
• Design der Tools, die jeder Agent bereitstellt: tool-design.

Kernkonzepte

Verwende Multi-Agent-Muster, wenn das Kontextfenster eines einzelnen Agenten nicht alle aufgabenrelevanten Informationen aufnehmen kann. Kontextisolierung ist der primäre Vorteil – jeder Agent arbeitet in einem sauberen Kontext ohne angesammeltes Rauschen aus anderen Unteraufgaben, wodurch das Telefonspiel-Problem verhindert wird, bei dem Informationen durch wiederholte Zusammenfassung degradieren.

Wähle aus drei dominierenden Mustern basierend auf Koordinationsanforderungen, nicht auf organisatorischen Metaphern:

• Supervisor/Orchestrator – Verwende für zentrale Steuerung, wenn Aufgaben klar zerlegbar sind und menschliche Aufsicht wichtig ist. Ein einziger Koordinator delegiert an Spezialisten und synthetisiert Ergebnisse.
• Peer-to-Peer/Swarm – Verwende für flexible Erkundung, wenn starre Planung kontraproduktiv ist. Jeder Agent kann die Kontrolle durch explizite Übergabemechanismen an jeden anderen Agenten übertragen.
• Hierarchisch – Verwende für große Projekte mit geschichteter Abstraktion (Strategie, Planung, Ausführung). Jede Schicht arbeitet auf einer anderen Detailstufe mit eigener Kontextstruktur.

Gestalte jedes Multi-Agent-System mit expliziten Koordinationsprotokollen, Konsensmechanismen, die der Unterwürfigkeit widerstehen, und Fehlerbehandlung, die Fehlerfortpflanzungskaskaden verhindert.

Detaillierte Themen

Warum Multi-Agent-Architekturen

Der Kontext-Engpass Greife zu Multi-Agent-Architekturen, wenn der Kontext eines einzelnen Agenten durch angesammelte Historie, abgerufene Dokumente und Tool-Ausgaben so voll wird, dass die Leistung nachlässt. Erkenne drei Degradationssignale: den Lost-in-the-Middle-Effekt (Aufmerksamkeit schwächt für mittleren Kontext), Aufmerksamkeitsknappheit (zu viele konkurrierende Elemente) und Kontextvergiftung (irrelevante Inhalte verdrängen nützliche Inhalte).

Teile die Arbeit über mehrere Kontextfenster auf, sodass jeder Agent in einem sauberen, auf seine Unteraufgabe fokussierten Kontext arbeitet. Aggregiere Ergebnisse auf einer Koordinationsebene, ohne dass ein einzelner Kontext die volle Last trägt.

Die Token-Ökonomie-Realität Kalkuliere mit wesentlich höheren Token-Kosten. Produktionsdaten zeigen, dass Multi-Agent-Systeme deutlich mehr Token verbrauchen können als Einzel-Agent-Chats (claim-multi-agent-token-multiplier):

Architektur	Token-Multiplikator	Anwendungsfall
Einzel-Agent-Chat	Basislinie	Einfache Abfragen
Einzel-Agent mit Tools	Höher als Basislinie	Tool-verwendende Aufgaben
Multi-Agent-System	Viel höher als Basislinie	Komplexe Recherche/Koordination

Evaluationsforschung zu Browsing-Agenten deutet darauf hin, dass Token-Nutzung, Tool-Aufrufe und Modellwahl die Leistungsvarianz dominieren (claim-evaluation-browsecomp-variance). Dies unterstützt das Messen von Multi-Agent-Setups gegen Einzel-Agent-Basislinien, anstatt anzunehmen, dass zusätzliche Agenten helfen.

Priorisiere die Modellauswahl neben dem Architekturentwurf – die Verbesserung auf bessere Modelle bringt oft größere Leistungssteigerungen als die Verdopplung von Token-Budgets. BrowseComp-Daten zeigen, dass Verbesserungen der Modellqualität häufig rohe Token-Erhöhungen übertreffen. Behandle Modellauswahl und Multi-Agent-Architektur als komplementäre Strategien.

Das Parallelisierungsargument Weise parallelisierbare Unteraufgaben dedizierten Agenten mit frischen Kontexten zu, anstatt sie sequenziell in einem einzigen Agenten zu verarbeiten. Eine Rechercheaufgabe, die Suchen in mehreren unabhängigen Quellen, die Analyse verschiedener Dokumente oder den Vergleich konkurrierender Ansätze erfordert, profitiert von paralleler Ausführung. Die gesamte reale Zeit nähert sich der Dauer der längsten Unteraufgabe anstatt der Summe aller Unteraufgaben.

Das Spezialisierungsargument Konfiguriere jeden Agenten nur mit dem System-Prompt, den Tools und dem Kontext, den er für seine spezifische Unteraufgabe benötigt. Ein Allzweck-Agent muss alle möglichen Konfigurationen im Kontext tragen, was die Aufmerksamkeit verdünnt. Spezialisierte Agenten tragen nur das, was sie brauchen, und arbeiten mit schlankem Kontext, der auf ihre Domäne optimiert ist. Leite von einem Koordinator an spezialisierte Agenten weiter, um Spezialisierung ohne kombinatorische Explosion zu erreichen.

Architekturmuster

Muster 1: Supervisor/Orchestrator Setze einen zentralen Agenten ein, der den globalen Zustand und Verlauf verwaltet, Benutzerziele in Unteraufgaben zerlegt und an geeignete Arbeiter weiterleitet.

Benutzeranfrage -> Supervisor -> [Spezialist, Spezialist, Spezialist] -> Aggregation -> Endausgabe

Wähle dieses Muster, wenn: Aufgaben klar zerlegbar sind, Koordination über Domänen hinweg erforderlich ist oder menschliche Aufsicht wichtig ist.

Erwarte diese Kompromisse: strikte Workflow-Kontrolle und einfachere Human-in-the-Loop-Eingriffe, aber der Supervisor-Kontext wird zum Engpass, Supervisor-Fehler wirken sich auf alle Arbeiter aus, und das Telefonspiel-Problem tritt auf, bei dem Supervisoren Unteragenten-Antworten falsch paraphrasieren.

Das Telefonspiel-Problem und seine Lösung Erwarte, dass Supervisor-Architekturen zunächst etwa 50% schlechter abschneiden als optimierte Versionen aufgrund des Telefonspiel-Problems (LangGraph-Benchmarks). Supervisoren paraphrasieren Unteragenten-Antworten und verlieren mit jeder Weitergabe an Genauigkeit.

Behebe dies durch die Implementierung eines forward_message-Tools, das es Unteragenten ermöglicht, Antworten direkt an Benutzer zu übergeben:

def forward_message(message: str, to_user: bool = True):
    """
    Leite Unteragenten-Antwort direkt an Benutzer weiter, ohne Supervisor-Synthese.

    Verwende, wenn:
    - Unteragenten-Antwort endgültig und vollständig ist
    - Supervisor-Synthese wichtige Details verlieren würde
    - Antwortformat exakt erhalten bleiben muss
    """
    if to_user:
        return {"type": "direct_response", "content": message}
    return {"type": "supervisor_input", "content": message}

Bevorzuge Swarm-Architekturen gegenüber Supervisoren, wenn Unteragenten direkt an Benutzer antworten können, da dies Übersetzungsfehler vollständig eliminiert.

Muster 2: Peer-to-Peer/Swarm Entferne die zentrale Steuerung und erlaube Agenten die direkte Kommunikation basierend auf vordefinierten Protokollen. Jeder Agent kann die Kontrolle durch explizite Übergabemechanismen an jeden anderen Agenten übertragen.

def transfer_to_agent_b():
    return agent_b  # Übergabe über Funktionsrückgabe

agent_a = Agent(
    name="Agent A",
    functions=[transfer_to_agent_b]
)

Wähle dieses Muster, wenn: Aufgaben flexible Erkundung erfordern, starre Planung kontraproduktiv ist oder Anforderungen dynamisch entstehen und sich nicht vorab zerlegen lassen.

Erwarte diese Kompromisse: kein einzelner Ausfallpunkt und effektive Breitenskalierung, aber die Koordinationskomplexität steigt mit der Anzahl der Agenten, das Abweichungsrisiko wächst ohne zentralen Zustandsverwalter, und robuste Konvergenzbedingungen werden essenziell.

Definiere explizite Übergabeprotokolle mit Zustandsweitergabe. Stelle sicher, dass Agenten ihre Kontextanforderungen an empfangende Agenten kommunizieren.

Muster 3: Hierarchisch Organisiere Agenten in Abstraktionsebenen: Strategie (Zieldefinition), Planung (Aufgabenzerlegung) und Ausführung (atomare Aufgaben).

Strategieebene (Zieldefinition) -> Planungsebene (Aufgabenzerlegung) -> Ausführungsebene (atomare Aufgaben)

Wähle dieses Muster, wenn: Projekte eine klare hierarchische Struktur haben, Workflows Managementebenen umfassen oder Aufgaben sowohl hochrangige Planung als auch detaillierte Ausführung erfordern.

Erwarte diese Kompromisse: klare Trennung von Verantwortlichkeiten und Unterstützung für verschiedene Kontextstrukturen auf verschiedenen Ebenen, aber Koordinationsaufwand zwischen den Ebenen, mögliche Strategie-Ausführungs-Missausrichtung und komplexe Fehlerfortpflanzungspfade.

Kontextisolierung als Entwurfsprinzip

Behandle die Kontextisolierung als den primären Zweck von Multi-Agent-Architekturen. Jeder Unteragent sollte in einem sauberen, auf seine Teilaufgabe fokussierten Kontextfenster arbeiten, ohne angesammelten Kontext aus anderen Teilaufgaben zu tragen.

Isolierungsmechanismen Wähle den richtigen Isolierungsmechanismus für jede Teilaufgabe:

• Vollständige Kontextdelegation – Teile den gesamten Kontext des Planers mit dem Unteragenten. Verwende für komplexe Aufgaben, bei denen der Unteragent ein vollständiges Verständnis benötigt. Der Unteragent hat seine eigenen Tools und Anweisungen, erhält aber den vollständigen Kontext für seine Entscheidungen. Hinweis: Dies untergräbt teilweise den Zweck der Kontextisolierung.
• Anweisungsweitergabe – Erstelle Anweisungen über Funktionsaufrufe; der Unteragent erhält nur das, was er benötigt. Verwende für einfache, klar definierte Unteraufgaben. Erhält die Isolierung, schränkt aber die Flexibilität des Unteragenten ein.
• Dateisystem-Speicher – Agenten lesen und schreiben in persistenten Speicher. Verwende für komplexe Aufgaben, die einen gemeinsamen Zustand erfordern. Das Dateisystem dient als Koordinationsmechanismus und vermeidet Kontextaufblähung durch gemeinsame Zustandsweitergabe. Führt zu Latenz- und Konsistenzherausforderungen, skaliert aber besser als Nachrichtenaustausch.

Wähle basierend auf Aufgabenkomplexität, Koordinationsanforderungen und akzeptabler Latenz. Standardmäßig Anweisungsweitergabe und eskaliere zu Dateisystem-Speicher, wenn gemeinsamer Zustand benötigt wird. Vermeide vollständige Kontextdelegation, es sei denn, die Unteraufgabe erfordert dies tatsächlich.

Konsens und Koordination

Das Abstimmungsproblem Vermeide einfache Mehrheitsabstimmungen – sie behandeln Halluzinationen von schwachen Modellen als gleichwertig mit Argumentation von starken Modellen. Ohne Eingreifen verfallen Multi-Agent-Diskussionen in Konsens über falsche Prämissen aufgrund einer inhärenten Neigung zur Zustimmung.

Gewichtete Abstimmung Gewichte Agentenstimmen nach Konfidenz oder Fachwissen. Agenten mit höherer Konfidenz oder Domänenexpertise sollten mehr Gewicht bei endgültigen Entscheidungen haben.

Debattenprotokolle Strukturiere Agenten so, dass sie die Ergebnisse der anderen über mehrere Runden kritisieren. Adversariale Kritik führt oft zu höherer Genauigkeit bei komplexen Überlegungen als kollaborativer Konsens. Schütze vor unterwürfiger Konvergenz, bei der Agenten zustimmen, um angenehm zu sein, anstatt korrekt.

Auslöserbasierte Intervention Überwache Multi-Agent-Interaktionen auf Verhaltensindikatoren. Aktiviere Stillstandsauslöser, wenn Diskussionen keine Fortschritte machen. Erkenne Unterwürfigkeitsauslöser, wenn Agenten Antworten der anderen nachahmen, ohne eigene Argumentation.

Framework-Überlegungen

Verschiedene Frameworks implementieren diese Muster mit unterschiedlichen Philosophien. LangGraph verwendet graphbasierte Zustandsmaschinen mit expliziten Knoten und Kanten. AutoGen verwendet gesprächs-/ereignisgesteuerte Muster mit GroupChat. CrewAI verwendet rollenbasierte Prozessabläufe mit hierarchischen Crew-Strukturen.

Praktische Anleitung

Fehlermodi und Abhilfen

Fehler: Supervisor-Engpass Der Supervisor sammelt Kontext von allen Arbeitern an und wird anfällig für Sättigung und Degradation.

Begrenze dies, indem du die Ausgabeschemas der Arbeiter einschränkst, sodass Arbeiter nur destillierte Zusammenfassungen zurückgeben. Verwende Checkpointing, um den Supervisor-Zustand zu persistieren, ohne die gesamte Historie im Kontext zu tragen.

Fehler: Koordinationsaufwand Agentenkommunikation verbraucht Tokens und führt zu Latenz. Komplexe Koordination kann die Vorteile der Parallelisierung zunichte machen.

Minimiere die Kommunikation durch klare Übergabeprotokolle. Sammle Ergebnisse wo möglich stapelweise. Verwende asynchrone Kommunikationsmuster. Messe, ob die Multi-Agent-Koordination tatsächlich Zeit spart im Vergleich zu einem einzelnen Agenten mit längerem Kontext.

Fehler: Abweichung Agenten, die ohne zentrale Koordination unterschiedliche Ziele verfolgen, driften von den beabsichtigten Zielen ab.

Definiere klare Zielgrenzen für jeden Agenten. Implementiere Konvergenzprüfungen, die den Fortschritt in Richtung gemeinsamer Ziele verifizieren. Setze Time-to-Live-Grenzen für die Agentenausführung, um unbegrenzte Erkundung zu verhindern.

Fehler: Fehlerfortpflanzung Fehler in der Ausgabe eines Agenten pflanzen sich auf nachgelagerte Agenten fort, die diese Ausgabe konsumieren, und verstärken sich zu immer falscheren Ergebnissen.

Validiere Agentenausgaben, bevor sie an Verbraucher weitergegeben werden. Implementiere Wiederholungslogik mit Schutzschaltern. Verwende idempotente Operationen, wo möglich. Erwäge das Hinzufügen eines Verifizierungsagenten, der kritische Ausgaben gegenprüft, bevor sie in die Pipeline gelangen.

Beispiele

Beispiel 1: Forschungs-Team-Architektur

Supervisor
├── Forscher (Websuche, Dokumentenabruf)
├── Analyst (Datenanalyse, Statistik)
├── Faktenprüfer (Verifikation, Validierung)
└── Autor (Berichtserstellung, Formatierung)

Beispiel 2: Übergabeprotokoll

def handle_customer_request(request):
    if request.type == "billing":
        return transfer_to(billing_agent)
    elif request.type == "technical":
        return transfer_to(technical_agent)
    elif request.type == "sales":
        return transfer_to(sales_agent)
    else:
        return handle_general(request)

Richtlinien

1. Entwerfe mit Kontextisolierung als primärem Vorteil von Multi-Agent-Systemen
2. Wähle das Architekturmuster basierend auf Koordinationsanforderungen, nicht auf organisatorischen Metaphern
3. Implementiere explizite Übergabeprotokolle mit Zustandsweitergabe
4. Verwende gewichtete Abstimmungen oder Debattenprotokolle für Konsens
5. Überwache auf Supervisor-Engpässe und implementiere Checkpointing
6. Validiere Ausgaben, bevor sie zwischen Agenten übergeben werden
7. Setze Time-to-Live-Grenzen, um Endlosschleifen zu verhindern
8. Teste Fehlerszenarien explizit

Fallstricke

1. Supervisor-Engpass – Der Supervisor wird zum Engpass. Verwende direkte Weiterleitung mit forward_message.
2. Token-Kosten – Multi-Agent-Systeme verbrauchen deutlich mehr Tokens als Einzel-Agent-Systeme. Messe gegen die Basislinie.
3. Unterwürfige Konvergenz – Agenten stimmen zu, anstatt zu argumentieren. Verwende adversariale Debattenprotokolle.
4. Teufelskreis aus Zustand und Kontext – Systeme, die darauf ausgelegt sind, den Zustand vollständig in Nachrichten zu halten, erzeugen Kontextaufblähung. Verwende bei Bedarf dateibasierten Speicher.
5. Falsche Metapher – Das Zuweisen menschlicher Rollen zu Agenten führt zu übermäßig komplexen, nicht hilfreichen Verhaltensweisen. Gestalte für Kontextisolierung, nicht für Rollenspiele.

Literaturhinweise

• claim-multi-agent-token-multiplier: Tokennutzung in Multi-Agent-Architekturen
• claim-evaluation-browsecomp-variance: Dominanzfaktoren der Leistungsvarianz
• claim-handoff-agent-design: Entwurf expliziter Übergabeprotokolle
• LangGraph-Benchmarks: Supervisor-Leistungsvergleich
• BrowseComp-Daten: Modellqualität vs. Token-Menge

Verwandte Skills

• project-development: Entscheidung über Aufgaben-Modell-Passung, Pipeline-Form und Projektkosten
• hosted-agents: Design von gehosteten Sandboxes, Warmpools, Remote-Sessions und Hintergrund-Runtime-Infrastruktur
• latent-briefing: Teilen von Orchestrator-Zustand durch KV-Cache-Kompaktierung in kontrollierten Runtimes
• tool-design: Design der Tools, die jeder Agent bereitstellt