google/adk-python: Python-Framework für Agenten mit Graph-Laufzeit und Task-API

Welches Problem ADK 2.0 adressiert

Ein Agent, der ein Modell aufruft und eine Antwort zurückgibt, ist schnell geschrieben. Sobald mehrere Agenten zusammenarbeiten, ein Ablauf wiederholbar sein muss und ein Mensch vor einer kritischen Tool-Ausführung bestätigen soll, reicht ein einzelner Prompt nicht mehr. An dieser Stelle setzt ADK an. Das Repository beschreibt das Projekt als code-first Python-Framework zum Bauen, Evaluieren und Deployen von Agenten. Der Anspruch ist nicht, Modellaufrufe zu vereinfachen, sondern Abläufe um sie herum beherrschbar zu machen: Routing, Verzweigung, Schleifen, Wiederholungsversuche, Zustand und verschachtelte Workflows.

Die Zielgruppe sind Entwicklerteams, die Agentenlogik wie Anwendungscode behandeln wollen. Das README nennt als Kernargument Testbarkeit und Versionierung, weil Agent-Definition, Tools und Orchestrierung in Python liegen. Für Teams, die Agenten lieber aus einer Konfigurationsoberfläche heraus zusammenklicken, ist das kein Vorteil, sondern eine zusätzliche Ebene. Umgekehrt gilt: Wer nachvollziehbare, im Git-Repository prüfbare Abläufe braucht, findet hier ein Modell, das dem üblichen Software-Lebenszyklus folgt. Die Topics des Repositories nennen Multi-Agent-Systeme und Agenten-Kollaboration, was die Ausrichtung bestätigt: ADK ist für Systeme gedacht, in denen mehrere spezialisierte Agenten zusammenspielen, nicht für einen einzelnen Chatbot.

Agent und Workflow als zwei getrennte Bausteine

Das Quick Start im README führt zwei Klassen ein. Agent beschreibt Anweisungen, Tools und Verhalten einer einzelnen Einheit. Das Beispiel definiert einen root_agent mit name, model und instruction, wobei das Modell gemini-2.5-flash ist. Workflow orchestriert Agenten und Tasks in einem graphenbasierten Ablauf. Im zweiten Beispiel werden zwei Agenten angelegt, einer erzeugt einen Fruchtnamen, einer nennt einen gesundheitlichen Nutzen. Verbunden werden sie über edges, konkret über das Tupel ("START", generate_fruit_agent, generate_benefit_agent).

Bemerkenswert ist, dass der Workflow selbst als root_agent instanziiert wird. Das deutet darauf hin, dass ein Workflow für die Laufzeit wie ein Agent behandelt wird und sich damit verschachteln lässt, was das README unter nested workflows aufführt. Die Trennung von Agent und Workflow ist die eigentliche Designentscheidung: Ein Agent bleibt eine Einheit mit Instruktion und Tools, der Ablauf dazwischen wird explizit als Graph modelliert. Wer schon einmal versucht hat, Reihenfolge und Verzweigung allein über Prompt-Formulierungen zu steuern, erkennt den Unterschied. Das Modell entscheidet nicht mehr über den Kontrollfluss, der Kontrollfluss steht im Code.

Workflow-Runtime und Task-API im Detail

Die Workflow-Runtime wird im README als graphenbasierte Ausführungsengine beschrieben, mit Unterstützung für Routing, fan-out/fan-in, Schleifen, Retry, State-Management, dynamische Knoten, Human-in-the-Loop und verschachtelte Workflows. Das ist eine Liste von Mechanismen, keine Garantie über deren Reifegrad. Die Dokumentation verlinkt für Human-in-the-Loop auf einen Tool-Confirmation-Flow, der die Ausführung eines Tools an eine ausdrückliche Bestätigung und benutzerdefinierte Eingaben knüpft. Für Agenten, die schreibende Operationen ausführen, ist das der relevanteste Teil des Frameworks, weil er die Entscheidung über eine Aktion aus dem Modell heraus an eine definierte Stelle im Ablauf verlegt.

Die Task-API beschreibt strukturierte Delegation zwischen Agenten. Das README nennt einen Multi-Turn-Task-Modus, einen Single-Turn-Modus mit kontrollierter Ausgabe, gemischte Delegationsmuster, Human-in-the-Loop sowie Task-Agenten als Workflow-Knoten. Der Begriff strukturiert ist hier wichtig: Delegation wird nicht als freier Text zwischen Agenten ausgetauscht, sondern folgt einem definierten Format. Das reduziert Interpretationsspielraum, schränkt aber auch ein, wenn ein Agent eine Rückgabe liefern soll, die das Schema nicht vorsieht. Task-Agenten als Workflow-Knoten verbinden beide Konzepte: Eine Delegation kann selbst Teil des Graphen sein und damit denselben Mechanismen für Retry und Routing unterliegen.

Installation und der Umgang mit Abhängigkeiten

Die Installation erfolgt über pip install google-adk, vorausgesetzt wird Python 3.10 oder neuer. Für transitive Abhängigkeiten empfiehlt das README ausdrücklich die Verwendung begleitender Constraints-Dateien für Python 3.10 bis 3.14. Der Ablauf ist konkret: curl -o constraints-3.10.txt gefolgt von der URL im Repository, dann pip install google-adk -c constraints-3.10.txt, anschließend das Löschen der Datei. Diese Empfehlung ist ungewöhnlich deutlich formuliert und sagt etwas über das Risiko aus, das die Maintainer bei ungepinnten Abhängigkeiten sehen. Wer in einer Umgebung mit strikter Reproduzierbarkeit arbeitet, sollte den Schritt nicht überspringen.

Optionale Integrationen kommen über pip install "google-adk[extensions]". Für Änderungen, die noch nicht in einer PyPI-Version enthalten sind, nennt das README die Installation direkt aus dem main-Branch über pip install git+https://github.com/google/adk-python.git@main, verbunden mit dem Hinweis, dass dieser Stand experimentelle Änderungen oder Fehler enthalten kann. Der Release-Rhythmus wird mit ungefähr zweiwöchentlich angegeben. Für lokale Tests stehen adk run path/to/my_agent für eine interaktive CLI und adk web path/to/agents_dir für eine Weboberfläche bereit, wobei die Weboberfläche laut README sowohl Verzeichnisse mit mehreren Agenten als auch einen einzelnen Agentenordner akzeptiert.

Modellagnostisch, aber auf Gemini optimiert

Das README bezeichnet ADK als modellagnostisch, deployment-agnostisch und kompatibel mit anderen Frameworks, hält aber gleichzeitig fest, dass das Framework für Gemini optimiert ist. Diese beiden Aussagen stehen nicht im Widerspruch, sie beschreiben unterschiedliche Grade an Unterstützung. Die Beispiele im Quick Start verwenden gemini-2.5-flash. Wer ein anderes Modell einsetzen will, muss laut Selbstbeschreibung nicht auf das Framework verzichten, sollte aber damit rechnen, dass Beispielcode, Tool-Integration und Dokumentation den Google-Pfad zuerst abdecken. Das ist ein praktischer Punkt, kein Ausschlusskriterium.

Beim Deployment nennt das README zwei Wege: Containerisierung und Betrieb auf Cloud Run oder Skalierung mit Vertex AI Agent Engine. Die Formulierung deployment-agnostisch bezieht sich also darauf, dass ADK den Betrieb nicht auf eine einzelne Plattform festnagelt. Das Tool-Ökosystem umfasst vorgefertigte Tools, eigene Funktionen, OpenAPI-Spezifikationen und MCP-Tools. Die Nennung von MCP ist relevant, weil sie den Anschluss an einen Standard erlaubt, der nicht aus dem Google-Umfeld stammt. Gleichzeitig beschreibt das README die Integration als tight integration with the Google ecosystem, was die Erwartung an die Betreuung der einzelnen Wege prägt.

Der Bruch zwischen 1.x und 2.0

Das README enthält einen hervorgehobenen Hinweis auf Breaking Changes von 1.x: betroffen sind die Agent-API, das Event-Modell und das Session-Schema. Die Kompatibilitätsaussage ist präzise und asymmetrisch. Sessions, die von ADK 2.0 erzeugt wurden, können von ADK 1.28 und neuer gelesen werden, wobei zusätzliche Felder ignoriert werden. Ältere 1.x-Versionen können sie nicht verarbeiten. Für Betreiber bedeutet das: Ein Upgrade auf 2.0 ist keine reine Versionserhöhung, sondern eine Änderung an Datenstrukturen, die persistiert werden. Wer Sessions in einer Datenbank hält, muss den Rückweg planen, bevor die erste 2.0-Instanz schreibt.

Die drei genannten Bereiche Agent-API, Event-Modell und Session-Schema sind genau die Stellen, an denen eigenes Tooling ansetzt. Ein Team, das Events auswertet oder Sessions außerhalb des Frameworks liest, wird hier Anpassungen vornehmen müssen. Die Versionsnummern in den Releases stützen die Aussage: Neben 2.8.0 und 2.7.1 erscheint mit v1.39.1 weiterhin eine 1.x-Linie. Das deutet darauf hin, dass beide Zweige parallel gepflegt werden, ohne dass das README dazu eine Aussage über die Dauer trifft. Diese Frage bleibt offen und sollte vor einer langfristigen Festlegung geklärt werden.

Wo ADK die falsche Wahl ist und was Alternativen anders machen

ADK ist ein Framework, kein Dienst. Es gibt keine gehostete Plattform, die einem die Orchestrierung abnimmt, und das README beschreibt den Betrieb als Containerisierung oder Deployment auf Cloud Run beziehungsweise Vertex AI Agent Engine. Wer einen einzelnen Assistenten mit wenigen Tools baut und keine Verzweigungen, Wiederholungsversuche oder Zustandsverwaltung braucht, trägt mit dem Graphenmodell und der Task-API mehr Konzepte ein, als die Aufgabe verlangt. In diesem Fall ist ein direkter Aufruf der Modell-API mit einer dünnen Tool-Schicht die einfachere Lösung.

Als Alternative im gleichen Feld nennt das README die Kompatibilität mit anderen Frameworks, ohne eines zu benennen. Ein Vergleich lohnt sich daher entlang der Mechanismen, nicht der Namen. LangChain und LangGraph verfolgen einen ähnlichen Graphenansatz, unterscheiden sich aber in der Bindung: LangGraph modelliert den Ablauf ebenfalls als Graph, ist jedoch nicht auf ein Modell oder einen Cloud-Anbieter hin optimiert, während ADK laut eigener Beschreibung für Gemini optimiert ist und die Deployment-Pfade auf Google-Dienste verweisen. Für Teams, die bereits auf Vertex AI setzen, ist das ein Vorteil. Für Teams, die bewusst anbieterunabhängig bleiben wollen, ist es ein Kriterium gegen ADK. Eine zweite Alternative ist der Verzicht auf ein Framework zugunsten einer eigenen Zustandsmaschine, was bei sehr kleinen Abläufen weniger Abhängigkeiten bedeutet, aber Evaluierung und Tool-Confirmation selbst implementieren muss.

Wartung, Lizenz und Upgrade-Kosten

Der Release-Rhythmus liegt laut README bei ungefähr zwei Wochen. Diese Kadenz ist ein Kostenfaktor: Wer regelmäßig aktualisiert, muss Breaking Changes einplanen, wie sie zwischen 1.x und 2.0 dokumentiert sind. Wer selten aktualisiert, sammelt Änderungen an und steht irgendwann vor einem größeren Sprung. Die Constraints-Dateien für Python 3.10 bis 3.14 sind das Werkzeug, das das Projekt für reproduzierbare Installationen bereitstellt, und sie sollten in jedem Fall in den eigenen Build einfließen.

Lizenziert ist das Projekt unter Apache-2.0, wie Badge und Lizenzdatei im Repository ausweisen. Diese Lizenz erlaubt die Nutzung, Veränderung und Weitergabe, auch in kommerziellen Produkten, und verlangt unter anderem die Beibehaltung von Copyright- und Lizenzhinweisen sowie eine Kennzeichnung geänderter Dateien. Das ist eine allgemeine Einordnung, keine Rechtsberatung. Wer ADK in ein Produkt einbettet, sollte die konkreten Pflichten aus der LICENSE-Datei im Repository mit der eigenen Rechtsabteilung klären, insbesondere wenn eigene Patches am Framework entstehen.

Der Wechsel zwischen Sprachen ist ein weiterer Punkt für die Planung. Das README verweist auf ADK Java, ADK Kotlin, ADK Go und ADK Typescript. Ob diese Portierungen denselben Funktionsumfang und dieselbe Versionslinie haben, geht aus dem Material nicht hervor. Wer heute in Python startet und später auf eine andere Sprache wechseln will, sollte diesen Punkt prüfen, statt ihn anzunehmen.

Redaktionelles Fazit

Wer Agenten als versionierten Python-Code mit deterministischen Abläufen, Human-in-the-Loop und Multi-Agent-Hierarchien bauen will, findet in ADK 2.0 die passenden Bausteine. Wer eine stabile 1.x-Installation produktiv betreibt, sollte vor dem Upgrade die Hinweise zu Agent-API, Event-Modell und Session-Schema aus dem README prüfen und die eigene Session-Persistenz gegen die Aussage testen, dass 2.0-Sessions von ADK 1.28+ gelesen werden können, ältere 1.x-Versionen sie aber nicht verarbeiten. Vor der Adoption ist außerdem zu klären, ob der bi-weekly Release-Kadenz ein eigener Upgrade-Pfad entgegensteht und ob die Agent-Config ohne Code für die geplanten Agenten ausreicht oder ob die Python-API gebraucht wird.

Offizielle Quellen

1. google/adk-python on GitHub
2. License: Apache-2.0
3. Project website
4. README
5. Releases