+210 XP

Multi-Agent-Orchestrierung mit dem ADK

# Multi-Agent-Orchestrierung mit dem ADK

Ein einzelner Agent reicht oft nicht: Sobald ein Workflow einen Researcher, einen Writer und einen Reviewer braucht, wird alles in einen einzigen Prompt zu quetschen zu einem brüchigen Durcheinander aus „mach erst das, dann jenes, aber nur wenn ...“-Anweisungen, denen das Modell halbherzig folgt. Das Agent Development Kit (ADK) existiert, um diese Arbeit in Spezialisten aufzuteilen und sie über expliziten Kontrollfluss zu verdrahten.

Sie wissen bereits, was ein Agent ist: ein Modell plus Tools plus eine Loop. In dieser Lektion geht es darum, *mehrere* davon zu einem System zu komponieren, und zu erkennen, wann sich der zusätzliche Apparat auszahlt.

Die drei Orchestrierungs-Primitive

ADK gibt Ihnen Agents als komponierbare Objekte. Ein gewöhnlicher LlmAgent schlussfolgert und ruft Tools auf. ADK liefert aber auch Workflow-Agents: Agents, deren einzige Aufgabe darin besteht, *andere* Agents in einem definierten Muster auszuführen. Drei davon brauchen Sie.

Sequential: Pipeline-Stufen

SequentialAgent führt seine Sub-Agents einen nach dem anderen aus. Der Output fließt über den gemeinsamen Session State nach vorne weiter. Nutzen Sie das, wenn Schritt B wirklich vom Ergebnis von Schritt A abhängt: recherchieren, dann entwerfen, dann redigieren.

Parallel: unabhängige Arbeit aufteilen

ParallelAgent führt seine Sub-Agents gleichzeitig aus. Jeder schreibt in seinen eigenen Key im Session State. Nutzen Sie das, wenn Aufgaben unabhängig sind und Sie wollen, dass sie in der Zeit der langsamsten fertig werden und nicht in der Summe aller. Denken Sie an: drei Dokumente gleichzeitig zusammenfassen oder drei Datenquellen parallel abfragen.

Coordinator: Verteilung nach Entscheidung

Ein Coordinator ist ein normaler LlmAgent, bei dem andere Agents als sub_agents registriert sind. Statt alles auszuführen, *liest der Coordinator die Anfrage und entscheidet*, welcher Spezialist sie bearbeiten soll, und übergibt dann die Kontrolle. Das ist das dynamische Muster: Das Modell routet zur Laufzeit, statt einer festen Reihenfolge zu folgen.

Der entscheidende Unterschied: Sequential und Parallel sind *deterministisch* (Sie haben den Ablauf zur Build-Zeit festgelegt). Ein Coordinator ist *modellgetrieben* (das LLM entscheidet den Ablauf pro Anfrage). Echte Systeme mischen alle drei.

Wann Multi-Agent besser ist als ein einzelner Agent

Aufteilen hat echte Kosten, also begründen Sie es. Ein Multi-Agent-Design gewinnt, wenn:

  • Rollen unterschiedliche Tools oder Instruktionen brauchen. Ein Research-Agent braucht Grounding über Google Search; ein Drafting-Agent braucht einen Styleguide und keinen Web-Zugang. Getrennte Agents halten jeden Prompt kurz und jedes Toolset abgegrenzt.
  • Sie Parallelität wollen. Ein Agent kann nicht wirklich zwei Dinge gleichzeitig tun. Das Aufteilen senkt die Wall-Clock-Zeit.
  • Sie Isolation und Testbarkeit wollen. Sie können den „Reviewer“-Agent allein unit-testen, sein Modell von Gemini Pro auf Flash umstellen und den Rest nie anfassen.
  • Der Kontext voll wird. Selbst mit Geminis langem Kontext leidet die Fokussierung, wenn Recherchenotizen, Stilregeln und Draft-Historie in ein Fenster gestopft werden. Spezialisten halten jeden Kontext schlank.

Es kostet Sie: mehr bewegliche Teile, mehr Stellen, an denen Latenz sich akkumuliert, schwierigeres Debugging (welcher Agent hat den schlechten Output produziert?) und insgesamt mehr Tokens, weil Agents bei der Übergabe den Kontext neu aufbauen. Wenn ein klarer Prompt mit zwei Tools die Arbeit erledigt, nehmen Sie einen Agent. Greifen Sie zur Orchestrierung, wenn die oben genannten Nahtstellen anfangen zu schmerzen.

Ein konkretes Beispiel: Coordinator verteilt an Research und Drafting

Bauen wir die klassische Content-Pipeline. Ein Coordinator erhält ein Thema. Er verteilt parallel an einen Research-Agent (der Grounding über Google Search nutzt) und einen Drafting-Agent, danach fügt eine letzte Stufe die Ergebnisse zusammen.

Hier ist die Aufteilung wirklich parallel: Recherche und ein Outline können gleichzeitig starten, dann kombiniert ein Writer beides. Wir komponieren einen ParallelAgent innerhalb eines SequentialAgent.

python
from google.adk.agents import LlmAgent, ParallelAgent, SequentialAgent
from google.adk.tools import google_search

# Spezialist 1: sammelt fundierte Fakten über Google Search
researcher = LlmAgent(
    name="researcher",
    model="gemini-2.5-flash",
    instruction=(
        "Research the given topic. Return 5-7 concise, cited bullet points "
        "of current, verifiable facts. Do not write prose."
    ),
    tools=[google_search],
    output_key="research_notes",
)

# Spezialist 2: schlägt parallel eine Struktur vor, kein Web-Zugang
outliner = LlmAgent(
    name="outliner",
    model="gemini-2.5-flash",
    instruction=(
        "Propose a tight 4-section outline for an article on the topic. "
        "Headings only, no body text."
    ),
    output_key="outline",
)

# Aufteilung: Recherche und Outline laufen gleichzeitig
gather = ParallelAgent(
    name="gather",
    sub_agents=[researcher, outliner],
)

# Letzte Stufe: liest beide State-Keys und schreibt den Draft
writer = LlmAgent(
    name="writer",
    model="gemini-2.5-pro",
    instruction=(
        "Write a 500-word article. Use the outline in {outline} for "
        "structure and only the facts in {research_notes} for claims. "
        "House style: plain, direct, no hype."
    ),
    output_key="draft",
)

# Coordinator: parallel sammeln, dann schreiben
content_pipeline = SequentialAgent(
    name="content_pipeline",
    sub_agents=[gather, writer],
)

Lesen Sie den Datenfluss, denn dort findet Orchestrierung tatsächlich statt:

  • output_key="research_notes" sagt ADK, den finalen Output des Researchers unter diesem Key in den Session State zu schreiben.
  • Der outliner schreibt nach outline und läuft gleichzeitig innerhalb von gather.
  • Der writer liest beides über die Template-Platzhalter {research_notes} und {outline} in seiner Instruktion. ADK setzt die State-Werte ein, bevor der Prompt gesendet wird.
  • SequentialAgent garantiert, dass gather vollständig abgeschlossen ist, bevor writer startet, sodass beide Keys existieren, wenn der Writer läuft.

Beachten Sie die Modellwahl. Recherche und Outlining gehen an Gemini Flash: schnell, günstig, hohes Volumen. Der finale Draft, wo Qualität am meisten zählt, geht an Gemini Pro. Modellklassen pro Agent zu mischen ist einer der größten praktischen Vorteile von Multi-Agent-Design, und etwas, das ein einzelner Agent nicht leisten kann.

Ausführen

ADK gibt Ihnen eine lokale Dev-Loop. Aus Ihrem Projektverzeichnis:

bash
pip install google-adk
adk web

adk web startet eine Browser-UI, in der Sie Input senden, jeden Sub-Agent beim Feuern beobachten und den Session State Key für Key inspizieren. Wenn der Writer Unsinn produziert, schauen Sie zuerst auf research_notes und outline: Waren die schlecht, liegt der Fehler weiter oben und nicht beim Writer. Diese Nachvollziehbarkeit ist der praktische Gewinn expliziter Orchestrierung.

Coordinator als Router: die dynamische Variante

Das Beispiel oben kodiert den Ablauf fest. Manchmal soll das Modell entscheiden. Sagen wir, einige Anfragen brauchen Recherche und andere sind reine Rewrites. Machen Sie den Coordinator zu einem LlmAgent mit Spezialisten als sub_agents:

python
coordinator = LlmAgent(
    name="coordinator",
    model="gemini-2.5-pro",
    instruction=(
        "You route requests. If the user asks for new content about a "
        "topic, delegate to 'content_pipeline'. If they paste existing "
        "text to improve, delegate to 'editor'. Never answer directly."
    ),
    sub_agents=[content_pipeline, editor],
)

Jetzt liest das LLM die Intention und *transferiert* zum richtigen Sub-Agent. Das heißt in ADK Agent Transfer: Kontrolle (und die Konversation) wandern zum gewählten Sub-Agent, der zurück oder an ein Geschwister-Agent transferieren kann. Mächtig, aber der Tradeoff ist real: Routing ist jetzt eine Modellentscheidung und kann also falsch sein. Für Abläufe mit hohem Risiko bevorzugen Sie deterministische SequentialAgent/ParallelAgent und behalten modellgetriebenes Routing für wirklich verzweigende Intentionen.

Build multi-agent systems with the Agent Development Kit

Watch on YouTube

Wissenscheck

1. Was unterscheidet einen Coordinator grundlegend von einem SequentialAgent oder ParallelAgent?

2. In welchem Szenario ist ein SequentialAgent die passendste Wahl?

3. Warum erledigt ein ParallelAgent eine Reihe von Aufgaben in der Zeit der langsamsten und nicht in der Summe aller?

MEHRFACHAUSWAHL

4. Wählen Sie ALLE Gründe, die die Lektion dafür nennt, einen Workflow in mehrere Agents aufzuteilen statt einen Agent zu nutzen.

Wählen Sie alle richtigen Antworten aus.

MEHRFACHAUSWAHL

5. Wählen Sie ALLE Aussagen, die ADK-Orchestrierungs-Primitive korrekt beschreiben.

Wählen Sie alle richtigen Antworten aus.

Tools, Grounding und wo das läuft

Zwei Dinge machen diese Agents nützlich statt akademisch.

Grounding mit Google Search. Das google_search-Tool liefert dem Researcher live, belegte Ergebnisse statt veralteter Trainingsdaten. Das ist der Unterschied zwischen „Fakten zum Trainings-Cutoff des Modells“ und „Fakten von heute Morgen“. Begrenzen Sie es auf den Agent, der es braucht: Ihr Drafting-Agent soll keine Quellen still erfinden, geben Sie ihm also gar kein Search-Tool und zwingen Sie ihn, sich auf den State zu verlassen.

Sub-Agents können auch Tools sein. Über sub_agents hinaus (die die Kontrolle übergeben) erlaubt ADK, einen Agent per AgentTool als aufrufbares Tool zu verpacken. Der Unterschied zählt: Ein Sub-Agent übernimmt den Turn, während ein Agent-als-Tool ein Ergebnis an den Aufrufer zurückgibt, wie jede Funktion. Nutzen Sie AgentTool, wenn der Coordinator die Führung behalten und einen Spezialisten mitten im Reasoning nur „konsultieren“ soll; nutzen Sie sub_agents, wenn Sie eine klare Übergabe wollen.

Wo es deployt wird. Sie prototypen lokal mit adk web oder adk run. Für die Produktion deployt dieselbe Agent-Definition auf Vertex AI Agent Engine, Googles managed Runtime, die Sessions, Skalierung und Tracing übernimmt, sodass Sie die Orchestrierungs-Loop nicht auf Ihrem eigenen Server betreiben. Sie können es auch containerisieren und auf Cloud Run laufen lassen. Der Punkt: Der Code oben ändert sich zwischen Ihrem Laptop und der Produktion nicht. Sie konfigurieren Credentials und Ziel, nicht Architektur.

Praktische Guardrails

Einige Dinge, die eine Demo von etwas unterscheiden, das Sie ausliefern würden:

  • Benennen und beschreiben Sie jeden Agent klar. Wenn ein Coordinator per Modellentscheidung routet, nutzt er name und description jedes Sub-Agents zur Auswahl. Vage Beschreibungen führen zu Fehlrouting. Schreiben Sie sie, als würden Sie Tool-Dokumentation für das Modell schreiben, denn genau das sind sie.
  • Halten Sie State-Keys explizit und wenige. Jeder output_key ist ein Vertrag zwischen einem Produzenten und einem Konsumenten. Weniger, gut benannte Keys bedeuten weniger stille Mismatches.
  • Achten Sie auf Token-Kosten an den Nahtstellen. Jede Übergabe kann Kontext erneut abspielen. Wenn Ihre parallelen Zweige groß sind, multipliziert sich das. Schicken Sie umfangreiche Recherche an Flash, reservieren Sie Pro für den Synthese-Schritt und kürzen Sie, was jeder Agent nach unten weitergibt.
  • Testen Sie Agents zuerst isoliert. Lassen Sie den Researcher allein mit einem festen Thema laufen, bis sein Output zuverlässig ist. Erst dann verdrahten Sie ihn in die Pipeline. Ein Fünf-Agenten-System end-to-end zu debuggen ist elend; einen Agent zu debuggen ist leicht.
  • Scheitern Sie laut. Entscheiden Sie, was der Writer tut, wenn research_notes leer zurückkommt. Eine Produktionsinstruktion sollte sagen „wenn keine Recherche vorliegt, stoppe und melde das“, und nicht still halluzinieren.

Wichtigste Erkenntnisse

  • Nutzen Sie `SequentialAgent` für abhängige Stufen, `ParallelAgent` für unabhängige Arbeit und einen `LlmAgent`-Coordinator für Routing zur Laufzeit. Deterministischer Ablauf ist zuverlässiger; sparen Sie modellgetriebenes Routing für wirklich verzweigende Intentionen auf.
  • State-Keys sind die Verdrahtung. output_key schreibt in den Session State und {placeholder} liest ihn zurück. Halten Sie Keys wenige, benannt und behandeln Sie sie als Verträge zwischen Agents.
  • Mischen Sie Modellklassen pro Agent. Schicken Sie Recherche und Outlining mit hohem Volumen an Gemini Flash, reservieren Sie Gemini Pro für den qualitätskritischen Synthese-Schritt. Diese Wahl pro Agent ist ein Kerngrund, überhaupt aufzuteilen.
  • Begrenzen Sie Tools auf den Agent, der sie braucht. Geben Sie Grounding über Google Search nur dem Researcher; verweigern Sie es dem Drafter, damit er keine Quellen erfinden kann.
  • Prototypen mit `adk web`, denselben Code auf Vertex AI Agent Engine deployen. Teilen Sie nur dann in mehrere Agents auf, wenn Rollen, Tools, Parallelität oder Kontextdruck die zusätzliche Debugging-Fläche rechtfertigen.