+180 XP

Multi-Agent-Systeme: Orchestrator, Worker und Handoffs

# Multi-Agent-Systeme: Orchestrator, Worker und Handoffs

Bitten Sie einen einzelnen KI-Agenten, „schreibe mir einen Wettbewerbsbericht zu den drei größten Elektroautoherstellern", und beobachten Sie, wie er ins Schlingern kommt. Er recherchiert Tesla, vergisst den Preisvergleich, fängt zu schreiben an, bevor er die Daten hat, und geht auf halber Strecke das Kontextfenster aus. Das Problem ist der eine Agent, der die ganze Aufgabe im Kopf behalten will.

Jetzt teilen Sie die Aufgabe auf. Ein Agent plant. Drei Agenten recherchieren gleichzeitig je ein Unternehmen. Ein Agent schreibt den finalen Bericht. Plötzlich ist aus dem schweren Problem eine Reihe einfacher Probleme geworden.

Das ist ein Multi-Agent-System: mehrere KI-Agenten, jeder mit einer engen Aufgabe, koordiniert, um eine größere Aufgabe zu erledigen.

Warum die Arbeit überhaupt aufteilen?

Ein einzelner Agent hat reale Grenzen:

  • Kontextlimit. Jeder Agent kann nur eine maximale Textmenge auf einmal berücksichtigen (sein „Kontextfenster"). Stopfen Sie die Rohrecherche zu drei Unternehmen in einen Agenten, fängt er an, Details fallen zu lassen.
  • Fokus. Ein Agent mit einer klaren Aufgabe („finde die Preise für Rivian") macht das besser als einer, der fünf Aufgaben jongliert.
  • Geschwindigkeit. Drei Recherche-Agenten, die gleichzeitig laufen (parallel), sind etwa dreimal schneller fertig als ein Agent, der sie nacheinander abarbeitet.

Kurze Definition: Ein Agent meint hier ein LLM (Large Language Model, die KI hinter Tools wie ChatGPT oder Claude), das in einer Schleife Aktionen ausführen kann, also Tools wie Websuche aufruft und dann anhand der Ergebnisse entscheidet, was als Nächstes zu tun ist.

Das Orchestrator-Worker-Muster

Die zuverlässigste Struktur für Multi-Agent-Arbeit sieht aus wie ein kleines Unternehmen:

  • Orchestrator (die Führungskraft): zerlegt die Aufgabe in Teile, verteilt sie und setzt die Ergebnisse zusammen. Die Detailarbeit macht er nicht selbst.
  • Worker (die Spezialisten): jeder erhält einen klaren Auftrag, erledigt ihn und gibt das Ergebnis zurück.

Hier ist unser Rechercheberich als Organigramm:

                 ┌─────────────────┐
                 │   ORCHESTRATOR  │  plans + delegates
                 └────────┬────────┘
          ┌───────────────┼───────────────┐
          ▼               ▼               ▼
   ┌────────────┐  ┌────────────┐  ┌────────────┐
   │ Researcher │  │ Researcher │  │ Researcher │   run in parallel
   │  (Tesla)   │  │  (Rivian)  │  │   (BYD)    │
   └──────┬─────┘  └──────┬─────┘  └──────┬─────┘
          └───────────────┼───────────────┘
                          ▼
                 ┌─────────────────┐
                 │      WRITER     │  produces final report
                 └─────────────────┘

Achten Sie auf die Form: Alles läuft über den Orchestrator. Die Worker reden nicht miteinander. Sie berichten nach oben. Das ist die wichtigste Designentscheidung dieser Lektion, und wir kommen darauf zurück, warum.

Was jeder Agent tatsächlich bekommt

Der Trick liegt in den Instruktionen. Jeder Worker bekommt einen engen Prompt.

Orchestrator-Prompt (vereinfacht):

> Du bist ein Research Manager. Zerlege die Anfrage des Nutzers in eine Recherche-Aufgabe pro Unternehmen. Schicke jede Aufgabe an einen Researcher. Wenn alle Ergebnisse zurück sind, schicke sie an den Writer. Recherchiere und schreibe nicht selbst.

Researcher-Prompt:

> Du recherchierst genau ein Unternehmen. Finde: aktuelle Preise, Verkaufszahlen 2025 und einen zentralen strategischen Schritt. Gib eine kurze Zusammenfassung in Bullet Points mit Quellen zurück. Vergleiche nicht mit anderen Unternehmen.

Writer-Prompt:

> Du erhältst Recherchezusammenfassungen zu mehreren Unternehmen. Schreibe einen Vergleichsbericht mit 500 Wörtern und einer Empfehlung. Nutze ausschließlich die bereitgestellte Recherche.

Die Aufgabe jedes Agenten ist klein genug, um sie in drei Sätzen zu beschreiben. Das ist das Zeichen für eine gute Aufteilung.

Handoffs: den Staffelstab sauber übergeben

Ein Handoff ist der Moment, in dem ein Agent die Kontrolle (und Informationen) an einen anderen übergibt. Sind die Handoffs richtig gebaut, läuft das System rund. Sind sie falsch, sickern Informationen durch oder verschwinden.

Zwei Dinge reisen in einem Handoff mit:

1. Die Aufgabe: was als Nächstes zu tun ist.

2. Der Kontext: die Informationen, die man dafür braucht.

Der häufige Fehler ist, zu viel oder zu wenig zu übergeben. Leitet der Orchestrator jedem Researcher die gesamte Gesprächshistorie weiter, verschwenden Sie Kontext und verwirren den Worker. Leitet er nichts weiter, rät der Worker.

Die Lösung: Übergeben Sie nur das, was der nächste Agent braucht. Der Writer braucht die drei Recherchezusammenfassungen, nicht die internen Planungsnotizen des Orchestrators.

Hier eine herstellerneutrale Skizze der Orchestrator-Schleife in Python. Das ist pseudocode-artig, zeigt aber die reale Form:

python
def run_report(user_request):
    # 1. Orchestrator plant: eine Aufgabe pro Unternehmen
    companies = orchestrator.plan(user_request)  # -> ["Tesla", "Rivian", "BYD"]

    # 2. Worker laufen parallel, jeder mit einer engen Aufgabe
    results = run_in_parallel([
        researcher.run(f"Research {c}: pricing, 2025 sales, one strategic move")
        for c in companies
    ])

    # 3. Handoff: NUR die Zusammenfassungen an den Writer übergeben
    report = writer.run(
        task="Write a 500-word comparison with a recommendation",
        context=results
    )
    return report

Jeder .run()-Aufruf ist selbst ein Agent, der seine eigene Tool-Call-Schleife durchläuft (Web durchsuchen, Ergebnisse lesen, entscheiden, wiederholen), bevor er zurückkehrt. Dem Orchestrator ist es egal, *wie* ein Researcher die Preise findet. Ihn interessiert nur, dass eine saubere Zusammenfassung zurückkommt.

Jeder große Anbieter liefert Tooling genau für dieses Muster: Das OpenAI Agents SDK hat eingebaute „Handoffs", das Claude Agent SDK unterstützt Subagenten, und Googles ADK (Agent Development Kit) hat sequenzielle und parallele Agententypen. Die Kernidee lässt sich auf alle übertragen. Die exakte Syntax finden Sie in den Deep-Dive-Blöcken zu den Anbietern.

Für eine klare schriftliche Aufarbeitung dieser Muster: Anthropics Guide Building Effective Agents ist kostenlos, herstellerseitig ehrlich und 15 Minuten wert.

How to Build Multi-Agent Systems

Watch on YouTube

Der Failure Mode: Agenten frei reden lassen

Hier die verlockende Idee: Was, wenn wir den Orchestrator weglassen und alle Agenten einfach miteinander reden lassen? Der Tesla-Researcher plaudert mit dem Rivian-Researcher, der Writer springt mit Fragen dazwischen, alle arbeiten zusammen.

In der Praxis bricht dieses „Free-for-all" (manchmal auch fully-connected oder konversationelles Multi-Agent-Setup genannt) schnell zusammen. Die Failure Modes sind immer dieselben:

Chatter-Loops. Zwei Agenten bleiben in Höflichkeit hängen. „Soll ich die Preise mit aufnehmen?" „Ja, und soll ich die Verkaufszahlen mit aufnehmen?" „Gute Idee, und solltest du auch...?" Sie verbrennen Tokens und Geld im Kreis. (Ein Token ist ein Textbaustein, den das Modell verarbeitet; Sie zahlen pro Token.)

Kontextexplosion. Wenn jeder Agent die Nachrichten aller anderen sieht, bläht sich die gemeinsame Konversation auf. Jeder Agent liest jetzt fünfmal mehr Text als nötig, wird langsamer, kostet mehr und verliert den Faden.

Keine einzige Wahrheitsquelle. Wenn drei Agenten alle am Bericht arbeiten, wem gehört die finale Version? Widersprüchliche Änderungen stapeln sich und niemand ist verantwortlich.

Nicht nachvollziehbare Fehler. Wenn in einem Free-for-all etwas schiefgeht, können Sie nicht sagen, welcher Agent es verursacht hat. Mit einem Orchestrator können Sie jeden Handoff prüfen und genau sehen, wo die Preisangabe falsch wurde.

Die Faustregel für 2026: Struktur vor Konversation. Nur der Orchestrator spricht mit allen. Die Worker bleiben in ihrer Spur. Sie verlieren ein wenig „Kreativität" und gewinnen viel Zuverlässigkeit, Kostenkontrolle und Debugbarkeit.

Wann lässt man Agenten *doch* miteinander sprechen? Selten, und nur bei wirklich offenen Aufgaben (etwa einem Brainstorming oder einer Debatte), wo Sie divergente Ideen wollen und eine harte Obergrenze für die Anzahl der Runden haben. Für das Erledigen von Aufgaben gewinnt der Orchestrator.

Wissenscheck

1. Was definiert ein Multi-Agent-System laut der Lektion am besten?

2. Was ist im Orchestrator-Worker-Muster die Hauptrolle des Orchestrators?

3. Warum ist es bei einer Aufgabe wie einem Wettbewerbsbericht wichtig, drei Recherche-Agenten parallel laufen zu lassen?

MEHRFACHAUSWAHL

4. Wählen Sie ALLE richtigen Antworten dazu, warum das Aufteilen der Arbeit auf mehrere Agenten hilft, die Grenzen eines einzelnen Agenten zu überwinden.

Wählen Sie alle richtigen Antworten aus.

MEHRFACHAUSWAHL

5. Wählen Sie ALLE richtigen Antworten, die beschreiben, was ein „Agent" im Sinne dieser Lektion bedeutet.

Wählen Sie alle richtigen Antworten aus.

Ihr eigenes Multi-Agent-System entwerfen

Sie brauchen zum Start keine fünf Agenten. Nutzen Sie diese Checkliste.

1. Kann ein Agent es gut genug erledigen?

Wenn ein einzelner Agent die Aufgabe zuverlässig schafft, hören Sie hier auf. Multi-Agent bringt Kosten und mehr bewegliche Teile. Teilen Sie nur, wenn Sie an eine echte Grenze stoßen: zu viel Kontext, zu viele unterschiedliche Fähigkeiten oder der Bedarf an paralleler Geschwindigkeit.

2. Nach klar trennbaren Aufgaben aufteilen

Gute Aufteilungen haben scharfe Grenzen. „Ein Unternehmen recherchieren" ist trennbar. „Den Bericht gut machen" nicht. Wenn zwei Worker ständig die Informationen des anderen brauchen, sollten sie wahrscheinlich ein Agent sein.

3. Die Form festlegen

  • Sequenziell (A, dann B, dann C): gut für Pipelines wie Recherche → Schreiben → Redigieren.
  • Parallel (A, B, C gleichzeitig, dann zusammenführen): gut für unabhängige Blöcke wie unsere drei Researcher.
  • Orchestrator-Worker: eine Führungsinstanz koordiniert beides. Das ist Ihr Standard.

4. Enge Prompts und explizite Handoffs schreiben

Beantworten Sie für jeden Agenten: Was ist deine eine Aufgabe? Welche Informationen erhältst du? Was genau gibst du zurück? Wenn Sie das nicht in je einem Satz beantworten können, ist die Aufteilung zu unscharf.

5. Eine Abbruchbedingung hinzufügen

Begrenzen Sie die Schleife immer. „Versuche es maximal 3-mal, dann gib zurück, was du hast." Ohne Limits können Agenten endlos kreisen. Diese eine Zeile verhindert die Horrorgeschichten mit entlaufenen Kosten.

Ein kurzer Realitätscheck zu den Kosten

Multi-Agent-Systeme machen mehr Modellaufrufe und kosten deshalb pro Aufgabe mehr als ein einzelner Agent. Das ist der Preis für Zuverlässigkeit und Geschwindigkeit. Für unseren EV-Bericht könnten drei parallele Researcher plus ein Writer plus ein Orchestrator fünf bis acht Modellaufrufe statt einem bedeuten. Wert ist es das für einen Bericht, dem Sie tatsächlich vertrauen. Nicht wert ist es das für „fasse diese E-Mail zusammen".

Wichtigste Erkenntnisse

  • Schwere Aufgaben in enge Jobs aufteilen. Ein Orchestrator plant und delegiert; jeder Worker verantwortet ein klar trennbares Stück. Wenn Sie die Aufgabe eines Agenten nicht in einem Satz beschreiben können, ist die Aufteilung falsch.
  • Alles über den Orchestrator leiten. Lassen Sie Worker nicht frei miteinander reden. Free-for-all-Setups führen zu Chatter-Loops, aufgeblähtem Kontext und Fehlern, die Sie nicht zurückverfolgen können.
  • Handoffs so bauen, dass nur das übergeben wird, was der nächste Agent braucht. Der Writer bekommt die Recherchezusammenfassungen, nicht die Planungsnotizen des Orchestrators.
  • Immer eine Abbruchbedingung einbauen. Begrenzen Sie Retries und Runden, damit kein Agent endlos kreist und Ihr Budget verbrennt.
  • Mit einem Agenten starten, erst bei einer echten Grenze aufteilen. Mehr Agenten heißt mehr Kosten und mehr bewegliche Teile, verdienen Sie sich die Komplexität also.

Verwandte Artikel

Aktuelle Blogartikel, die auf dieser Lektion aufbauen.