Cloud
CloudExperten-Level

Google ADK 2.x: Produktionsreife KI-Agenten mit dem Agent Development Kit bauen

Ein praxisnaher Blick auf Googles Agent Development Kit (ADK) 2.x: was es ist, wie man einen echten Agenten baut und evaluiert, die neuen Graph-Workflows, was beim Upgrade von 1.x bricht, der Vergleich mit LangGraph und CrewAI und wo man ihn betreibt.

Titelbild: Google ADK 2.x: Produktionsreife KI-Agenten mit dem Agent Development Kit bauen
Inhalt

Jeder liefert „KI-Agenten“ aus. Die meisten davon sind ein einzelner Prompt in einer while-Schleife mit einem fragilen JSON-Parser, der seitlich drangeklebt ist.

Ein echter Agent ist etwas anderes. Er plant, ruft Tools auf, erholt sich von fehlerhaften Tool-Ergebnissen und bleibt beobachtbar, wenn nachts um 3 Uhr in Produktion etwas schiefgeht. Diese Lücke zwischen Demo und einem System, das du wirklich betreiben kannst, soll Googles Agent Development Kit (ADK) schließen, und ADK 2.0 hat die Messlatte verschoben: Das Framework ist keine Hierarchie von Agenten mehr, sondern eine Graph-Engine, in der Agenten, Tools und einfache Funktionen Knoten sind.

Das hier ist die Praxis-Version, aktualisiert für ADK 2.x: was ADK ist, wie man einen Agenten baut und evaluiert, was in 2.0 neu ist, was beim Upgrade von 1.x bricht und wie es sich gegen LangGraph und CrewAI schlägt.

Was das Agent Development Kit wirklich ist

ADK ist ein Open-Source-Framework (Apache 2.0), um KI-Agenten zu bauen, zu evaluieren und auszuliefern. Es gibt es für Python, TypeScript, Go, Java und Kotlin, es ist modellagnostisch (auf Gemini optimiert, unterstützt aber auch Claude, OpenAI, Gemma, Ollama, vLLM und LiteLLM) und läuft überall: auf deinem Laptop, Cloud Run, GKE oder der verwalteten Agent Runtime von Google Cloud.

Das mentale Modell ist klein und lohnt sich einzuprägen:

  • Agent: ein LLM plus Anweisungen plus eine Menge Tools. Die Einheit, aus der du alles zusammensetzt.
  • Tool: eine ganz normale Funktion, die der Agent aufrufen kann. ADK liest Signatur und Docstring und baut das Schema automatisch. Auch OpenAPI-Spezifikationen und MCP-Tools werden unterstützt.
  • Runner: die Ausführungsschleife, die den Agenten antreibt: Modell promten, Tools aufrufen, Ergebnisse zurückführen, wiederholen, bis fertig.
  • Session: der Speicher und Zustand, der über mehrere Turns hinweg bestehen bleibt.
  • Workflow (neu in 2.0): ein Graph, der Agenten, Tools und Code als Knoten mit expliziten Pfaden verbindet.

Was in ADK 2.0 neu ist

ADK Python 2.0 ging am 19. Mai 2026 in die allgemeine Verfügbarkeit. ADK Go folgte am 30. Juni und ADK TypeScript am 21. August. Das Python-Paket steht inzwischen bei 2.13.0 (23. Oktober). Drei Ideen prägen das Release:

  • Graphbasierte Workflows. Deterministischer Code und adaptives KI-Denken in einem Graphen: Routing, Fan-out und Fan-in, Schleifen, Retries, Zustandsverwaltung und verschachtelte Workflows, mit expliziten Ausführungspfaden und vorhersehbaren Ergebnissen.
  • Dynamische Workflows. Codebasierte Logik für iterative Schleifen und entscheidungsgetriebene Verzweigungen, die sich vorab nicht als fester Graph zeichnen lassen.
  • Kollaborative Workflows. Koordinator-Agenten, die an Sub-Agenten delegieren, mit einer strukturierten Task API für die Delegation zwischen Agenten, auch mit Human-in-the-Loop-Schritten.

Zwei kleinere Ergänzungen zählen in der Praxis: ein Tool-Bestätigungs-Ablauf, der einen Tool-Aufruf mit einem ausdrücklichen menschlichen Ja absichern kann, und Agent Config, mit dem du Agenten ohne Code definierst.

Einen echten Agenten in rund 30 Zeilen bauen

Hier ist ein funktionierender Agent, der etwas Sinnvolles tut: Er beantwortet Fragen zu einer Bestellung, indem er ein Tool aufruft. Das Tool ist eine normale Python-Funktion mit klarem Docstring, und ADK macht daraus ein aufrufbares Schema.

from google.adk import Agent
def get_order_status(order_id: str) -> dict:
"""Look up the delivery status of a customer order.
Args:
order_id: The customer-facing order number, e.g. "A-10423".
"""
# In production this would hit your orders API.
orders = {"A-10423": {"status": "shipped", "eta": "2026-11-02"}}
return orders.get(order_id, {"status": "unknown"})
root_agent = Agent(
name="support_agent",
model="gemini-3.8-flash",
instruction=(
"You are a concise customer-support agent. "
"When a user asks about an order, call get_order_status and "
"answer in one sentence. Never invent an order status."
),
tools=[get_order_status],
)

Starte ihn lokal mit der ADK-Dev-UI und du bekommst ein Chatfenster, eine Live-Spur jedes Tool-Aufrufs und die Modell-Überlegungen, ohne eine Zeile Frontend zu schreiben. ADK 2.x braucht Python 3.11 oder neuer:

Terminal window
pip install google-adk
adk web path/to/agents_dir # Web-UI mit Traces
adk run path/to/support_agent # interaktive CLI

Wenn du zum ersten Mal siehst, wie das Trace-Panel Nutzer, Modell, Tool-Aufruf, Tool-Ergebnis, Modell, Antwort zeigt, macht es klick. Du rätst nicht, was der Agent getan hat. Du siehst es.

Ein Graph-Workflow: deterministische Schritte um Modellaufrufe

Ein einzelner Agent ist der Anfang. Das Neue in ADK 2.0 ist der Workflow: Du bestimmst den Pfad, und das Modell erledigt nur die unscharfen Teile. Ein Ablauf aus zwei Schritten, der die Bestellnummer extrahiert und dann aus dem Tool antwortet, sieht so aus:

from google.adk import Agent, Workflow
extract = Agent(
name="extract_order",
model="gemini-3.8-flash",
instruction="Extract the order number from the message. Return only the number.",
)
reply = Agent(
name="reply",
model="gemini-3.8-flash",
instruction="Give a one-sentence delivery update for the order, using get_order_status.",
tools=[get_order_status],
)
root_agent = Workflow(
name="support_flow",
edges=[("START", extract, reply)],
)

Die Kanten sind explizit, die Reihenfolge der Schritte hängt also nie davon ab, wozu das Modell gerade Lust hat. Von hier aus ergänzt die Doku Routen (bedingte Kanten), Fan-out und Fan-in, Schleifen, Retries und menschliche Eingaben als Graph-Funktionen erster Klasse.

Wo ADK vorn liegt: Tools, Evaluierung und Deployment

Drei Dinge unterscheiden ADK von einer selbstgebauten Agenten-Schleife.

Tools sind erstklassig und typisiert. Deine Funktionssignatur ist der Vertrag. Keine handgeschriebenen JSON-Schemas, die vom Code abdriften. ADK bringt außerdem fertige Tools wie Google Search mit und kann andere Agenten als Tools einwickeln.

Evaluierung ist eingebaut. Du definierst Testfälle (eine Eingabe plus erwarteter Tool-Verlauf und Endantwort) und führst sie als Suite aus. Das ist der Teil, den die meisten Teams auslassen und später bereuen: Ein Agent, der letzte Woche funktionierte, bricht still, wenn du einen Prompt änderst, und ein Eval-Set fängt das ab, bevor es deine Nutzer tun. Die Doku behandelt auch Nutzersimulation und eigene Metriken.

Terminal window
adk eval support_agent support_agent/order.evalset.json \
--config_file_path support_agent/eval_config.json

Deployment ist ein kurzer Sprung, kein Neubau. Derselbe Agent läuft lokal, im Container, auf Cloud Run oder auf der Agent Runtime, dem verwalteten Agent-Dienst in Google Clouds Agent Platform (die Doku liegt weiterhin unter dem Pfad Vertex AI Agent Engine). Die Agent Runtime ist ein kostenpflichtiger Dienst mit einer kostenlosen Einstiegsstufe.

Terminal window
adk deploy docker --with_ui support_agent
adk deploy cloud_run --with_ui support_agent

Für ein vollständig eingerichtetes Google-Cloud-Setup mit CI/CD und Infrastructure-as-Code beschreibt die Doku außerdem einen Agents-CLI-Weg.

Vom einzelnen Agenten zum Team

Die interessanten Systeme sind Multi-Agent: ein Koordinator, der an Spezialisten delegiert. Ein Agent kann sub_agents haben, und der Koordinator leitet Arbeit anhand ihrer Beschreibungen weiter.

from google.adk import Agent
billing = Agent(
name="billing",
model="gemini-3.8-flash",
description="Answers billing and refund questions.",
instruction="Answer billing and refund questions.",
)
shipping = Agent(
name="shipping",
model="gemini-3.8-flash",
description="Answers delivery and tracking questions.",
instruction="Answer delivery and tracking questions.",
)
coordinator = Agent(
name="coordinator",
model="gemini-4-argon",
instruction="Route each request to the right specialist and summarize the answer.",
sub_agents=[billing, shipping],
)

Der Koordinator nutzt ein stärkeres Modell, um über das Routing nachzudenken; die Spezialisten nutzen ein günstigeres, schnelleres für die enge Arbeit. Diese Aufteilung, kluger Router und billige Worker, ist eines der wirksamsten Kostenmuster in produktiven Agentensystemen. Halte den Modellnamen in der Konfiguration statt im Code vergraben, denn er wird sich ändern: Was Gemini 4 Argon für Plattform-Teams bedeutet zeigt, wie du nach Aufgabenklasse routest und Regel für Regel migrierst.

ADK vs LangGraph vs CrewAI

Keines davon ist pauschal das beste. Sie optimieren auf Unterschiedliches.

ADK vs LangGraph vs CrewAI
Dimension Google ADK LangGraph CrewAI
Kernmodell Agenten, Tools, Runner und Graph-Workflows (seit 2.0) Expliziter Zustandsgraph Rollenspielende Crew von Agenten
Am besten für Produktionsagenten auf Google Cloud Feinkörnige Ablaufsteuerung Schnelle Multi-Agent-Prototypen
Sprachen Python, TypeScript, Go, Java, Kotlin Python, JavaScript Python
Sweet Spot Ausliefern und Betreiben auf Google Cloud Komplexe, verzweigende Workflows Heute noch einen Multi-Agent-Prototyp zum Laufen bringen

Die Kurzfassung: Greife zu LangGraph, wenn dein Problem im Kern ein Zustandsautomat mit kniffligen Verzweigungen ist. Greife zu CrewAI, wenn du bis zum Mittag einen Multi-Agent-Prototyp willst. Greife zu ADK, wenn der Agent in Produktion auf Google Cloud leben muss, mit Evaluierung, Tracing und einer verwalteten Runtime, die du nicht selbst pflegst. Seit 2.0 ist das alte Argument für LangGraph („ADK hat keinen echten Graphen“) deutlich schwächer, denn ADK hat jetzt auch Graphen.

Upgrade von ADK 1.x auf 2.x

ADK 2.0 ist darauf ausgelegt, für 1.x geschriebene Agenten auszuführen, aber die Doku nennt echte Inkompatibilitäten. Prüfe diese, bevor du in einem Produktionsprojekt die Version anhebst:

  1. Events haben neue Felder. Events tragen node_info und output. Ein eigener BaseSessionService, der Events in starren SQL-Spalten speichert, muss zuerst angepasst werden, sonst schlagen Inserts und Deserialisierung fehl. Wer Events als serialisiertes JSON speichert, muss nichts ändern. Nachgelagerte Gateways mit strikter JSON-Validierung (additionalProperties: false) lehnen 2.0-Events ab, bis ihre Schemas aktualisiert sind.
  2. Eigene Ausführungs-Overrides werden umgangen. BaseAgent ist jetzt eine Unterklasse von BaseNode, und die Workflow-Engine ignoriert überschriebene _run_async_impl() oder generate_content(). Verlege eigene Telemetrie- oder Zustandslogik in Before-Agent- und After-Agent-Callbacks.
  3. Hänge keine Events selbst an. Manuelles Anhängen an context.session.events oder enqueue_event zerstört den Determinismus. Gib Events stattdessen aus deinem Knoten oder Agenten per yield zurück.
  4. Hör auf, Exceptions in Tools zu verschlucken. Ein breites except Exception: versteckt Fehler vor den neuen automatischen Retries (zum Beispiel RetryConfig(max_attempts=3)), und wer BaseException fängt, fängt auch NodeInterruptedError ab, was Human-in-the-Loop-Pausen kaputt macht.

Noch nicht so weit? Bleib auf der 1.x-Linie mit pip install "google-adk~=1.0" (Python 3.10 oder neuer) und plane das Upgrade mit Blick auf die Änderungen bei Events und Callbacks.

Der Gemini-Enterprise-Blickwinkel

Den Agenten zu bauen ist die halbe Geschichte. Die andere Hälfte ist alles drumherum: ihn an Unternehmensdaten anbinden, ihm eine Identität geben und auf echte Nutzer skalieren. Das ist die Aufgabe der verwalteten Google-Cloud-Dienste (Agent Runtime und die Gemini-Enterprise-Plattform) auf ADK. Der Punkt ist Kontinuität: Der Agent, den du lokal gebaut hast, ist derselbe, den du auslieferst, mit Unternehmens-Konnektoren und Governance drumherum, statt eines Prototyps, den du in einem anderen Tool neu baust.

Fazit

Das Agent Development Kit ist Googles Antwort auf ein echtes Problem: Die meisten „Agenten“ sind Demos, und Demos überleben die Produktion nicht. ADK gibt dir wenige saubere Bausteine (Agent, Tool, Runner, Session), typisierte Tools, eine eingebaute Evaluierungs-Suite, Live-Tracing lokal und seit 2.0 eine Graph-Workflow-Engine für die Teile deines Systems, die deterministisch sein müssen. Dazu kommt ein kurzer Weg vom Laptop zu einer verwalteten Runtime.

Wenn du heute ein Framework auswählst: CrewAI bringt dich am schnellsten zu einer Demo, LangGraph gibt dir die meiste Kontrolle über komplexe Abläufe, und ADK ist das Framework, das dafür gebaut ist, in Produktion auf Google Cloud betrieben zu werden. Wähle danach, wo der Agent leben muss, nicht nur, wo er geboren wird.

Wenn du Agenten baust, melde dich. Ich teile, was ich baue, unter #GoogleCloud, #GoogleCloudPartners und #GoogleCloudAmbassador.

Quellen

Häufig gestellte Fragen

Ist Google ADK produktionsreif?

ADK 2.0 hat für Python am 19. Mai 2026 die allgemeine Verfügbarkeit erreicht, Go folgte am 30. Juni und TypeScript am 21. August. Es bringt eine graphbasierte Workflow-Runtime mit Routing, Fan-out und Fan-in, Schleifen, Retries und Human-in-the-Loop-Pausen, eine eingebaute Evaluierung und läuft auf Cloud Run, GKE oder dem verwalteten Agent-Runtime-Dienst in Google Cloud. Das ist der Funktionsumfang, den ein Produktionsagent braucht, aber behandle das Upgrade von 1.x als Migration, nicht als Patch.

Was hat sich in ADK 2.0 gegenüber 1.x geändert?

Das Ausführungsmodell. In 1.x war ein Agent ein eigenständiger Executor in einer Hierarchie. In 2.0 laufen Agenten, Tools und Funktionen als Knoten in einem Workflow-Graphen. Kompatibilität ist das Ziel, aber die Doku nennt echte Brüche: neue Felder node_info und output an Events (ein Problem für eigene Session-Datenbanken mit festen Spalten), überschriebene _run_async_impl-Methoden, die die Graph-Engine jetzt umgeht, kein direktes Anhängen an die Event-Liste der Session und breite except-Blöcke, die Fehler vor den automatischen Retries und der Human-in-the-Loop-Logik verstecken. Wer noch nicht so weit ist, pinnt die 1.x-Linie mit pip install "google-adk~=1.0".

Wie schlägt sich ADK gegen LangGraph und CrewAI?

LangGraph baut auf einem expliziten Zustandsgraphen auf und bietet die genaueste Kontrolle über Verzweigungen. CrewAI ist auf schnelle Multi-Agent-Rollen optimiert. ADK tauscht etwas von dieser Flexibilität gegen Google-native Evaluierung, Tracing, Deployment und Gemini-Integration und hat seit 2.0 eigene Graph-Workflows. Wähle ADK, wenn du auf Google Cloud auslieferst und Betreibbarkeit willst, LangGraph für komplexe Zustandsautomaten, CrewAI für einen Multi-Agent-Prototyp bis zum Mittag.

Bindet mich ADK an Gemini?

Nein. ADK ist auf Gemini optimiert, aber modellagnostisch. Die Doku deckt Gemini, Gemma, Claude, OpenAI, Ollama, vLLM und LiteLLM ab, und das Framework läuft auf deinem Laptop oder jedem Container-Host. Am nahtlosesten ist das Deployment auf Google Cloud.

Wie führe ich nicht vertrauenswürdige Agenten-Tools sicher aus?

Sandboxe die Tool-Ausführung mit einer microVM- oder gVisor-Runtime, damit ein kompromittiertes Tool weder Host noch Cluster erreicht. Im microVM-Guide steht, wann Firecracker und wann gVisor passt.

Aus der Community

Diskussion auf Mastodon & Bluesky

Antworten auf diesen Artikel aus dem offenen Netz, live geladen. Keine Werbung, keine Tracking-Skripte.

Antworten werden geladen …
Auf Mastodon antwortenAuf Bluesky antworten

Antworte dort — es erscheint hier automatisch.

ENDE