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:
pip install google-adkadk web path/to/agents_dir # Web-UI mit Tracesadk run path/to/support_agent # interaktive CLIWenn 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.
adk eval support_agent support_agent/order.evalset.json \ --config_file_path support_agent/eval_config.jsonDeployment 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.
adk deploy docker --with_ui support_agentadk deploy cloud_run --with_ui support_agentFü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.
| 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:
- Events haben neue Felder. Events tragen
node_infoundoutput. Ein eigenerBaseSessionService, 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. - Eigene Ausführungs-Overrides werden umgangen.
BaseAgentist jetzt eine Unterklasse vonBaseNode, und die Workflow-Engine ignoriert überschriebene_run_async_impl()odergenerate_content(). Verlege eigene Telemetrie- oder Zustandslogik in Before-Agent- und After-Agent-Callbacks. - Hänge keine Events selbst an. Manuelles Anhängen an
context.session.eventsoderenqueue_eventzerstört den Determinismus. Gib Events stattdessen aus deinem Knoten oder Agenten per yield zurück. - Hör auf, Exceptions in Tools zu verschlucken. Ein breites
except Exception:versteckt Fehler vor den neuen automatischen Retries (zum BeispielRetryConfig(max_attempts=3)), und werBaseExceptionfängt, fängt auchNodeInterruptedErrorab, 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
- ADK: adk.dev, ADK-2.0-Leitfaden und Migrationshinweise, adk-python-Releases
- Deployment: Agent-Runtime-Doku
- Modelle: Gemini-API-Modelle







Aus der Community
Diskussion auf Mastodon & Bluesky
Antworten auf diesen Artikel aus dem offenen Netz, live geladen. Keine Werbung, keine Tracking-Skripte.
Antworte dort — es erscheint hier automatisch.