Gemini · Multi-Agent-Orchestrierung mit dem ADK

Ein Agent reicht oft nicht: Sobald ein Workflow einen Researcher, einen Writer und einen Reviewer braucht, wird das Zusammenpressen in einen einzigen Prompt zu einem fragilen Wirrwarr aus „mach zuerst das, dann das, aber nur wenn …“-Anweisungen, denen das Modell halb folgt. Das Agent Development Kit (ADK) existiert, um diese Arbeit auf Spezialisten zu verteilen und sie über explizites Control Flow 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 zusammenzusetzen und zu wissen, wann sich der zusätzliche Apparat auszahlt**.

Die drei Orchestrierungs-Primitive

ADK gibt Ihnen Agenten als komponierbare Objekte. Ein normaler LlmAgent reasoniert und ruft Tools auf. Aber ADK liefert auch Workflow-Agenten: Agenten, deren einzige Aufgabe darin besteht, *andere* Agenten in einem definierten Muster auszuführen. Drei davon brauchen Sie.

Sequential: PipelinePipelineAlle aktiven Verkaufschancen über die Phasen des Vertriebsprozesses hinweg, zusammen mit ihrem gesamten potenziellen Wert und ihrer Abschlusswahrscheinlichkeit.Vollständige Definition ansehen →-Stufen

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

Parallel: unabhängige Arbeit auffächern

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

Coordinator: Verteilung per Entscheidung

Ein Coordinator ist ein normaler LlmAgent, bei dem andere Agenten 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 LLMLLMEin Large Language Model ist ein KI-System, das auf riesigen Textmengen trainiert wurde, um Sprache vorherzusagen und zu erzeugen. Damit sind Aufgaben wie Schreiben, Zusammenfassen und Beantworten von Fragen möglich.Vollständige Definition ansehen → entscheidet den Ablauf pro Anfrage). Echte Systeme mischen alle drei.

Wann Multi-Agent besser ist als ein einzelner Agent

Aufteilen kostet etwas, 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-Zugriff. Getrennte Agenten halten jeden Prompt kurz und jedes Toolset abgegrenzt.
• Sie Parallelität wollen. Ein Agent kann nicht wirklich zwei Dinge gleichzeitig tun. Auffächern senkt die Wall-Clock-Zeit.
• Sie Isolation und Testbarkeit wollen. Sie kkDie durchschnittliche Zahl neuer Nutzer, die jeder bestehende Nutzer über Empfehlungen generiert. Über 1,0 verstärkt sich das Wachstum selbst und wird exponentiell.Vollständige Definition ansehen →ö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 verschlechtert es den Fokus, wenn Research-Notizen, Stilregeln und Draft-Historie in ein Window gepackt werden. Spezialisten halten jeden Kontext schlank.

Es kostet Sie: mehr bewegliche Teile, mehr Stellen, an denen sich Latenz aufsummiert, schwierigeres Debugging (welcher Agent hat den schlechten Output produziert?) und insgesamt mehr TokensTokensEin Token ist die grundlegende Texteinheit, die Sprachmodelle verarbeiten, oft ein Wortfragment, ein ganzes Wort oder ein Satzzeichen und nicht ein einzelnes Zeichen.Vollständige Definition ansehen →, weil Agenten beim Handoff den Kontext neu aufbauen. Wenn ein klarer Prompt mit zwei Tools die Arbeit erledigt, nehmen Sie einen Agenten. Greifen Sie zur Orchestrierung, wenn die oben genannten Nahtstellen anfangen wehzutun.

Ein konkretes Beispiel: Coordinator fächert auf Research und Drafting auf

Bauen wir die klassische Content-Pipeline. Ein Coordinator erhält ein Thema. ErErDas Verhältnis von Interaktionen (Likes, Kommentare, Shares) zur Reichweite eines Inhalts. Zeigt, wie stark die Zielgruppe reagiert, gemessen an der Zahl der Personen, die den Inhalt gesehen haben.Vollständige Definition ansehen → fächert parallel auf einen Research-Agent (der Grounding über Google Search nutzt) und einen Drafting-Agent auf, dann fügt eine letzte Stufe die Ergebnisse zusammen.

Hier ist das Auffächern wirklich parallel: Research und ein Outline können gleichzeitig starten, dann kombiniert ein Writer sie. Wir komponieren einen `ParallelAgent` innerhalb eines `SequentialAgent`.

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

# Spezialist 1: sammelt gegroundete 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-Zugriff
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",
)

# Auffächern: Research 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. Research 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. Modell-Tiers pro Agent zu mischen ist einer der größten praktischen Gewinne des Multi-Agent-Designs und etwas, das ein einzelner Agent nicht kann.

Ausführen

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

pip install google-adk
adk web

adk web startet eine Browser-UI, in der Sie Input senden, jeden Sub-Agenten 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, nicht beim Writer. Diese Nachvollziehbarkeit ist der praktische Ertrag expliziter Orchestrierung.

Coordinator als Router: die dynamische Variante

Das Beispiel oben verdrahtet den Ablauf fest. Manchmal wollen Sie, dass das Modell entscheidet. Sagen wir, manche Anfragen brauchen Research und andere sind reine Rewrites. Machen Sie den Coordinator zu einem `LlmAgent` mit Spezialisten als `sub_agents`:

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* an den richtigen Sub-Agenten. Das heißt in ADK Agent Transfer: Kontrolle (und die Konversation) gehen an den gewählten Sub-Agenten über, der zurück oder an ein Geschwister transferieren kann. Mächtig, aber der Tradeoff ist real: Routing ist nun eine Modellentscheidung und kann falsch sein. Für Flows mit hohem Risiko bevorzugen Sie deterministische SequentialAgent/ParallelAgent und behalten modellgetriebenes Routing für wirklich verzweigende Intentionen.

Tools, Grounding und wo das läuft

Zwei Dinge machen diese Agenten nützlich statt akademisch.

Grounding mit Google Search. Das google_search-Tool liefert dem Researcher live, zitierte 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 Agenten, der es braucht: Ihr Drafting-Agent soll keine Zitate still erfinden, geben Sie ihm also gar kein Search-Tool und zwingen Sie ihn, sich auf den State zu verlassen.

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

Wo es deployt wird. Sie prototypen lokal mit adk web oder adk run. Für 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 GuardrailsGuardrailsRegeln und Kontrollen, die ein KI-System in sicheren, rechtskonformen und markengerechten Grenzen halten und unerwünschte Ausgaben blockieren.Vollständige Definition ansehen →

Ein paar Dinge, die eine Demo von etwas Auslieferbarem unterscheiden:

• Benennen und beschreiben Sie jeden Agenten klar. Wenn ein Coordinator per Modellentscheidung routet, nutzt er name und description jedes Sub-Agenten 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 Producer und einem Consumer. Weniger, gut benannte Keys bedeuten weniger stille Mismatches.
• Achten Sie an den Nahtstellen auf Token-Kosten. Jeder Handoff kann Kontext erneut abspielen. Sind Ihre parallelen Branches groß, multiplizieren sie sich. Schicken Sie umfangreichen Research an Flash, reservieren Sie Pro für den Synthese-Schritt und kürzen Sie, was jeder Agent weitergibt.
• Testen Sie Agenten zuerst isoliert. Lassen Sie den Researcher allein mit einem festen Thema laufen, bis sein Output verlässlich ist. Erst dann verdrahten Sie ihn in die Pipeline. Ein Fünf-Agenten-System end-to-end zu debuggen ist elend; einen Agenten zu debuggen ist leicht.
• Scheitern Sie laut. Entscheiden Sie, was der Writer tut, wenn research_notes leer zurückkommt. Eine Produktions-Instruktion sollte sagen „wenn kein Research vorliegt, stoppe und melde das“, 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 verlässlicher; halten Sie modellgetriebenes Routing für wirklich verzweigende Intentionen zurück.
• 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 Agenten.
• Mischen Sie Modell-Tiers pro Agent. Schicken Sie Research 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 Agenten, der sie braucht. Geben Sie Grounding über Google Search nur dem Researcher; verweigern Sie es dem Drafter, damit er keine Zitate erfinden kann.
• Prototypen mit `adk web`, denselben Code auf Vertex AI Agent Engine deployen. Teilen Sie nur dann in mehrere Agenten auf, wenn Rollen, Tools, Parallelität oder Kontextdruck die zusätzliche Debugging-Fläche rechtfertigen.