Google ADK v2.0.0a1, veröffentlicht am 18. März 2026, bringt eine graphbasierte Workflow-Runtime, die das Bauen deterministischer Agent-Pipelines grundlegend verändert. Die neue Workflow-Klasse erlaubt Execution Graphs mit bedingtem Routing, parallelem Fan-Out/Fan-In, Schleifen, Retry-Mechanismen und Human-in-the-Loop-Schritten. Wer sich bisher für LangGraph entschieden hat, weil ADK keine feingranulare Workflow-Steuerung bot, sollte diese Entscheidung neu bewerten.
Das ist kein kleines Update. ADK v1.x bot drei starre Workflow-Typen: SequentialAgent, ParallelAgent und LoopAgent. Brauchbar, aber einschränkend. V2 ersetzt alle drei durch eine einzige, komposierbare Graph-Abstraktion, die alles von simplen Pipelines bis zu komplexem bedingtem Branching mit verschachtelten Sub-Workflows abdeckt.
Die Workflow-Klasse: Graphen statt nur Sequenzen
Der Kern von ADK v2 ist die Workflow-Klasse. Man definiert Nodes (Agents, Funktionen oder Tools) und verbindet sie mit Edges, die den Execution Graph beschreiben. Eine einfache sequenzielle Pipeline sieht so aus:
from google.adk.workflow import Workflow
root_agent = Workflow(
name="root_agent",
edges=[
("START", city_generator_agent, lookup_time_function,
city_report_agent, completed_message_function)
],
)
Das ähnelt dem alten SequentialAgent, und für einfache Fälle funktioniert es genauso. Der Unterschied zeigt sich beim bedingten Routing. Statt dass ein LLM entscheidet, welcher Agent als nächstes läuft, definiert man explizite Routen im Code:
def router(node_input: str):
return Event(route="RUN_TASK_C")
root_agent = Workflow(
name="routing_workflow",
edges=[
("START", task_A_node, router),
(router, {
"RUN_TASK_B": task_B_node,
"RUN_TASK_C": task_C_node,
}),
],
)
Die Router-Funktion gibt ein Event mit einem Route-Wert zurück. Die Workflow-Klasse matcht diesen Wert gegen das Dictionary der nachgelagerten Nodes und führt den richtigen aus. Kein LLM-Inference für die Routing-Entscheidung nötig, was schnellere Ausführung und deterministisches Verhalten bedeutet.
Das ist dasselbe Muster, das LangGraph mit Conditional Edges verwendet, aber die API ist wohl sauberer. Wo LangGraph erfordert, einen StateGraph zu definieren, Nodes hinzuzufügen, Edges mit Bedingungen zu ergänzen und zu kompilieren, macht ADK das in einer einzigen edges-Deklaration.
Fan-Out/Fan-In: Das JoinNode-Pattern
Parallele Ausführung in ADK v1 bedeutete ParallelAgent, der alle Sub-Agents startete und wartete, bis alle fertig waren. V2 bringt JoinNode für echte Fan-Out/Fan-In-Muster innerhalb eines Graphen:
from google.adk.workflow import JoinNode, Workflow
my_join_node = JoinNode(name="my_join_node")
root_agent = Workflow(
name="parallel_workflow",
edges=[
("START", parallel_task_A, my_join_node),
("START", parallel_task_B, my_join_node),
("START", parallel_task_C, my_join_node),
(my_join_node, final_task_D),
],
)
Drei Tasks starten von START, laufen parallel, und JoinNode wartet auf alle, bevor final_task_D ausgeführt wird. Das lässt sich mit bedingtem Routing kombinieren: Fan-Out zu drei Analyse-Agents, Ergebnisse zusammenführen, basierend auf den Findings an unterschiedliche Prozessoren routen.
Eine Einschränkung: Alle parallelen Nodes müssen Event-Output produzieren, sonst hängt der Workflow. Und man kann nicht mehrere interaktive Chat-Sessions parallel innerhalb einer Agent-Session laufen lassen. Für Batch-Verarbeitung und Analyse-Pipelines ist dieses Pattern aber genau das, was ADK v1 gefehlt hat.
Dynamische Workflows: Wenn Graphen nicht reichen
Statische Graph-Definitionen decken die meisten Fälle ab. Manchmal muss der Ausführungsfluss aber zur Laufzeit bestimmt werden. ADK v2 bietet dafür dynamische Workflows mit dem @node-Decorator und ctx.run_node():
from google.adk.workflow import node, Workflow, Context
@node(rerun_on_resume=True)
async def editorial_workflow(ctx: Context, user_request: str):
raw_draft = await ctx.run_node(draft_agent, user_request)
formatted_text = await ctx.run_node(format_function_node, raw_draft)
return formatted_text
root_agent = Workflow(
name="root_agent",
edges=[("START", editorial_workflow)]
)
Der Hauptunterschied zu statischen Graphen: Man nutzt Standard-Python-Kontrollfluss. Schleifen werden while-Schleifen. Bedingungen werden if-Statements. Parallele Ausführung nutzt asyncio.gather(). Das ist näher an einem normalen async Python-Programm, was weniger Framework-spezifisches Lernen erfordert.
ADK v2 fügt dynamischen Workflows auch automatisches Checkpointing hinzu. Wenn ein Workflow pausiert (etwa für Human Input) und später fortgesetzt wird, werden abgeschlossene Nodes automatisch übersprungen. Man muss keine Resume-Logik selbst bauen.
Ein konkretes Beispiel für eine iterative Verfeinerungsschleife:
@node
async def code_workflow(ctx: Context):
code = await ctx.run_node(coder_agent)
check_resp = await ctx.run_node(compile_lint_check, code)
while check_resp.findings:
yield Event(state={"code": code, "findings": check_resp.findings})
code = await ctx.run_node(fixer_agent)
check_resp = await ctx.run_node(compile_lint_check, code)
return code
Code schreiben, prüfen, Probleme fixen, wiederholen. Die while-Schleife läuft, bis der Linter zufrieden ist. Versucht man das in einer statischen Graph-Definition auszudrücken, weiß man die Flexibilität zu schätzen.
Task-API: Strukturierte Agent-Delegation
Das zweite große Feature in v2 ist die Task-API, die formalisiert, wie Agents Arbeit an Sub-Agents delegieren. ADK v1 nutzte LLM-gesteuertes Routing, bei dem ein Parent-Agent die Beschreibungen seiner Children las und entschied, wer was übernimmt. V2 ergänzt drei explizite Delegations-Modi:
Chat-Modus (Standard): Der Sub-Agent bekommt volle User-Interaktion und muss die Kontrolle explizit an den Parent zurückgeben. So funktionierte ADK v1 bereits.
Task-Modus: Der Sub-Agent kann Rückfragen stellen, kehrt aber automatisch zum Parent zurück, wenn die Aufgabe erledigt ist. Task-Mode-Agents arbeiten in isolierten Session-Branches und sehen nur ihre eigenen Events.
Single-Turn-Modus: Der Sub-Agent verarbeitet einen Input, produziert einen Output und kehrt zurück. Keine User-Interaktion möglich. Dieser Modus unterstützt parallele Ausführung, weil mehrere Single-Turn-Agents gleichzeitig laufen können, ohne sich gegenseitig zu stören.
from google.adk.workflow.agents.llm_agent import Agent
weather_agent = Agent(
name="weather_checker",
mode="single_turn",
tools=[get_weather, user_info, geocode_address],
)
flight_agent = Agent(
name="flight_booker",
mode="task",
tools=[search_flights, book_flight],
)
root = Agent(
name="travel_planner",
sub_agents=[weather_agent, flight_agent],
)
Der praktische Nutzen: Man kann eine Wetter-Abfrage und eine Hotel-Suche parallel laufen lassen (beide Single-Turn), dann an einen Flugbuchungs-Agent (Task-Modus) übergeben, der den User nach Datumspräferenzen fragen kann. In ADK v1 musste der Orchestrator das alles sequenziell über LLM-gesteuertes Routing abwickeln.
Eine Einschränkung: Task-Mode-Agents müssen Leaf-Agents ohne eigene Sub-Agents sein. Verschachtelte Task-Delegation ist nicht möglich. Für komplexe Hierarchien nutzt man stattdessen einen Workflow mit verschachtelten Sub-Workflows.
ADK v2 vs. LangGraph: Wer führt jetzt?
Unsere bestehende ADK-Übersicht listete “kein visueller Graph-Editor” und “weniger feingranulare Kontrolle über den Ausführungsfluss” als ADK-Schwächen gegenüber LangGraph. Das v2 Alpha adressiert die Kontrollfluss-Lücke direkt. So vergleichen sie sich jetzt:
Wo ADK v2 mit LangGraph gleichzieht:
- Graphbasierte Workflow-Definition mit bedingtem Routing
- Parallele Fan-Out/Fan-In-Ausführungsmuster
- Human-in-the-Loop mit Workflow-Pause/Resume
- State-Management über Workflow-Nodes hinweg
- Schleifen- und Retry-Mechanismen
Wo ADK v2 LangGraph wohl übertrifft:
- Dynamische Workflows mit nativem Python async/await statt graph-spezifischer DSL
- Eingebautes Checkpointing, das fertige Nodes beim Resume überspringt
- Task-API bietet strukturierte Delegations-Modi (Chat/Task/Single-Turn), die LangGraph nativ nicht hat
- Natives MCP- und A2A-Support weiterhin von keinem anderen Framework erreicht
- Vier Sprach-SDKs (Python, TypeScript, Go, Java) vs. LangGraphs zwei (Python, JavaScript)
Wo LangGraph weiterhin führt:
- Produktionsreife. LangGraph läuft seit über zwei Jahren in Produktion im großen Maßstab. ADK v2 ist ein Alpha-Release.
- Observability über LangSmith bleibt das umfassendste Agent-Debugging-Tool im Ökosystem
- Größere Community mit mehr Tutorials, Beispielen und Stack-Overflow-Antworten
- Framework-agnostisch by Design. ADK lehnt sich für Produktions-Deployment immer noch an das Google-Ökosystem an, auch wenn es überall läuft
Die ehrliche Einschätzung: Wer heute ein neues Projekt startet und graphbasierte Agent-Workflows will, sollte ADK v2 neben LangGraph evaluieren. Wer Agents bereits in Produktion betreibt, für den bleibt LangGraph die sicherere Wahl, bis ADK v2 einen Stable-Release bekommt.
Migration von ADK v1: Was sich ändert
Wer bereits ADK v1 nutzt, kann inkrementell migrieren. V2 ist ein Alpha-Release (pip install google-adk==2.0.0a1), und die bestehenden v1-Agent-Typen (LlmAgent, SequentialAgent, ParallelAgent, LoopAgent) funktionieren weiterhin. Man muss nicht alles auf einmal umschreiben.
Die praktische Migrationsstrategie:
- Bestehende Agents beibehalten. Die
LlmAgent-Definitionen mit MCP-Tools und A2A-Verbindungen ändern sich nicht. SequentialAgentdurchWorkflow-Edges ersetzen, wenn Pipelines bedingtes Routing oder Fan-Out brauchen.ParallelAgentdurchJoinNode-Patterns ersetzen, wenn man Ergebnisse paralleler Branches kombinieren muss, bevor es weitergeht.- Task-API-Modi zu Sub-Agents hinzufügen, die aktuell auf LLM-gesteuertes Routing für strukturierte Delegation setzen.
- Dynamische Workflows nutzen für iterative Prozesse, die mit dem alten
LoopAgentumständlich waren.
Da es sich um einen Alpha-Release handelt, sind Breaking Changes vor dem stabilen v2.0.0 zu erwarten. Die Dependency-Version pinnen und gründlich testen. Für Produktionssysteme bei v1.27.x bleiben (dem neuesten Stable-Release, Stand März 2026) und mit v2 in Entwicklungsumgebungen experimentieren.
Was das für die Framework-Landschaft bedeutet
Dass Google eine graphbasierte Workflow-Runtime liefert, ist ein Statement: Der Hierarchy-only-Ansatz war eine bewusste Design-Entscheidung, keine Einschränkung. ADK v1 setzte darauf, dass die meisten Agent-Systeme besser als Hierarchien statt als Graphen modelliert werden. ADK v2 sagt: “Aber wir geben euch Graphen dazu, für wenn ihr sie braucht.”
Das erhöht den Druck auf jedes andere Framework. LangGraphs Hauptdifferenzierung war Workflow-Kontrolle, und ADK v2 verengt diese Lücke, während es seine eigenen Vorteile behält (natives MCP/A2A, vier Sprach-SDKs, Vertex-AI-Integration). CrewAI und das OpenAI Agents SDK haben vergleichbare graphbasierte Workflow-Primitiven nach wie vor nicht.
Für Teams, die 2026 ein Framework wählen, wird die Entscheidungsmatrix komplizierter. ADK v2 ist das erste Framework, das alle drei Orchestrierungsstile glaubhaft abdeckt: LLM-gesteuertes Routing (für flexible Aufgaben), graphbasierte Workflows (für deterministische Pipelines) und dynamische Workflows (für zur Laufzeit bestimmte Ausführung). Ob diese Breite sich in Produktionstiefe übersetzt, muss sich erst noch beweisen.
Häufig gestellte Fragen
Was ist neu in Google ADK v2.0 Alpha?
ADK v2.0.0a1 bringt zwei große Features: eine graphbasierte Workflow-Runtime mit Routing, Fan-Out/Fan-In, Schleifen, Retry und Human-in-the-Loop-Support sowie eine Task-API für strukturierte Agent-zu-Agent-Delegation mit Chat-, Task- und Single-Turn-Modi.
Wie vergleicht sich Google ADK v2 mit LangGraph?
ADK v2 zieht bei graphbasierter Workflow-Kontrolle mit bedingtem Routing und paralleler Ausführung mit LangGraph gleich. ADK bietet zusätzlich natives MCP/A2A-Support und dynamische Workflows mit nativem Python async/await. LangGraph führt weiterhin bei Produktionsreife, Observability über LangSmith und Community-Größe.
Kann ich ADK v2.0 Alpha in Produktion einsetzen?
ADK v2.0.0a1 ist ein Alpha-Release und wird nicht für den Produktionseinsatz empfohlen. Vor dem stabilen v2.0.0 sind Breaking Changes zu erwarten. Für Produktionssysteme bei ADK v1.27.x bleiben und mit v2 in Entwicklungsumgebungen experimentieren.
Wie migriere ich von ADK v1 zu v2?
Die Migration ist inkrementell. Bestehende LlmAgent-Definitionen funktionieren in v2 weiter. Man kann schrittweise SequentialAgent durch Workflow-Edges ersetzen, ParallelAgent durch JoinNode-Patterns und Task-API-Modi zu Sub-Agents hinzufügen. Installation des Alpha mit pip install google-adk==2.0.0a1.
Was ist die ADK Workflow-Klasse?
Die Workflow-Klasse ist ADK v2s graphbasierte Execution Engine. Man definiert Nodes (Agents, Funktionen oder Tools) und verbindet sie mit Edges zu Execution Graphs. Sie unterstützt sequenzielle Routen, bedingtes Branching über Route-Werte und paralleles Fan-Out/Fan-In über JoinNode.