Googles Agent Development Kit (ADK) ist das erste große Framework, das sowohl MCP als auch A2A nativ unterstützt, ohne Community-Plugins oder Adapter-Pakete. Über 17.600 GitHub-Stars, 236 Contributors, SDKs in Python, TypeScript, Go und Java, und eine stabile v1.0-Version: ADK hat den Sprung vom Google-I/O-Demo-Projekt zum produktionsreifen Toolkit in weniger als einem Jahr geschafft. Renault, Box und Revionics setzen es bereits produktiv ein.
Der entscheidende Unterschied zu LangGraph, CrewAI und den anderen Frameworks ist nicht nur die Google-Rückendeckung. Es ist eine architektonische Grundentscheidung: Agent-zu-Tool-Kommunikation (MCP) und Agent-zu-Agent-Kommunikation (A2A) gehören ins selbe Framework, statt nachträglich angebaut zu werden. Ob diese Entscheidung aufgeht, hängt vom konkreten Anwendungsfall ab.
Was ADK ist (und was nicht)
ADK ist ein Open-Source-Framework mit Code-First-Ansatz für Einzel- und Multi-Agent-Systeme. Apache-2.0-lizenziert, modell-agnostisch (aber für Gemini optimiert) und überall einsetzbar, vom Laptop bis zu Vertex AI Agent Engine.
Drei Designprinzipien unterscheiden ADK von der Konkurrenz:
Agenten als zusammensetzbare Einheiten. Jeder Agent in ADK funktioniert eigenständig oder als Baustein in einer größeren Hierarchie. Ein übergeordneter Agent delegiert Aufgaben an Unter-Agenten basierend auf deren Beschreibungen. Diese können wiederum eigene Unter-Agenten haben. Agentensysteme werden wie Funktionen komponiert: durch Verschachtelung.
Protokolle als Kernfunktionen. Die MCP-Unterstützung bedeutet, dass jedes MCP-kompatible Tool sofort funktioniert. Die A2A-Unterstützung ermöglicht es Agenten aus verschiedenen Frameworks (oder von verschiedenen Teams), einander zu finden und zusammenzuarbeiten, ohne speziellen Integrationscode. Kein anderes großes Framework liefert beides nativ.
Code statt Konfiguration. Agentenlogik, Tools und Orchestrierung werden in Python (oder TypeScript, Go, Java) definiert, nicht in YAML-Dateien oder visuellen Buildern. Das bedeutet Versionskontrolle, Type Checking, Unit-Tests und Code-Reviews für Agenten-Definitionen.
So sieht ein minimaler ADK-Agent in Python aus:
from google.adk.agents import LlmAgent
agent = LlmAgent(
model="gemini-2.0-flash",
name="research_assistant",
description="Beantwortet Recherchefragen mit Quellenangaben",
instruction="Du bist ein Recherche-Assistent. Gib immer Quellen an.",
tools=[google_search_tool, code_execution_tool]
)
Das ist ein funktionierender Agent. Kein Boilerplate, keine State-Graph-Definitionen, keine YAML-Manifeste. Der Kompromiss: Weniger feingranulare Kontrolle über den Ausführungsfluss als bei LangGraph. Dazu gleich mehr.
Multi-Agent-Architektur: Hierarchien statt flache Teams
CrewAI organisiert Agenten in “Crews” mit Rollen. LangGraph modelliert sie als Knoten in einem State-Graph. ADK nutzt eine Hierarchie, in der übergeordnete Agenten Aufgaben an spezialisierte Unter-Agenten weiterleiten.
Das Routing ist standardmäßig LLM-gesteuert. Wenn ein Nutzer eine Nachricht sendet, liest der übergeordnete Agent die description-Felder seiner Kinder und entscheidet, welcher Unter-Agent die Anfrage bearbeiten soll.
from google.adk.agents import LlmAgent
greeter = LlmAgent(
model="gemini-2.0-flash",
name="greeter",
description="Begrüßungen und Smalltalk"
)
researcher = LlmAgent(
model="gemini-2.0-flash",
name="researcher",
description="Beantwortet Sachfragen mit Websuche",
tools=[google_search_tool]
)
coordinator = LlmAgent(
model="gemini-2.0-flash",
name="coordinator",
description="Leitet Nutzeranfragen an spezialisierte Agenten weiter",
sub_agents=[greeter, researcher]
)
Für deterministische Workflows bietet ADK drei Workflow-Agententypen, die kein LLM für das Routing verwenden:
- SequentialAgent: Führt Unter-Agenten der Reihe nach aus (A, dann B, dann C)
- ParallelAgent: Startet Unter-Agenten gleichzeitig und sammelt Ergebnisse
- LoopAgent: Wiederholt einen Unter-Agenten, bis eine Abbruchbedingung erfüllt ist
Dieser duale Ansatz (LLM-gesteuertes Routing für flexible Aufgaben, deterministische Orchestrierung für vorhersagbare Pipelines) ist ADKs stärkste Architekturentscheidung. LangGraph kann beides, erfordert aber den Aufbau der Routing-Logik von Hand. CrewAI ist hauptsächlich LLM-gesteuert mit begrenzter deterministischer Kontrolle.
Natives MCP: Jedes Tool spricht die gleiche Sprache
Das Model Context Protocol standardisiert, wie Agenten auf externe Tools und Datenquellen zugreifen. ADK behandelt MCP-Server als Plug-and-Play-Komponenten.
Verbindung zu einem MCP-Server in wenigen Zeilen:
from google.adk.tools.mcp import MCPToolset
async with MCPToolset.from_server(
connection_params=StdioServerParameters(
command="npx",
args=["-y", "@modelcontextprotocol/server-github"]
)
) as tools:
agent = LlmAgent(
model="gemini-2.0-flash",
name="github_agent",
tools=tools
)
Dieser Agent hat jetzt vollen Zugriff auf GitHub über den offiziellen MCP-Server: Repos lesen, Issues erstellen, PRs reviewen. Das gleiche Muster funktioniert für die über 2.000 verfügbaren MCP-Server (Stand Februar 2026), von Slack und PostgreSQL bis Jira und Google Drive.
Hier zeigt sich der Wert des protokoll-nativen Ansatzes. Bei LangGraph braucht man ein separates langchain-mcp-adapters-Paket, konfiguriert die Verbindung und wrapped das Ganze in ein LangChain-Tool. Bei CrewAI kam MCP-Support als Community-Plugin. Bei ADK gehört es zum Kern-Framework mit derselben API wie eingebaute Tools.
Natives A2A: Wenn Agenten andere Agenten brauchen
Das Agent-to-Agent-Protokoll löst ein anderes Problem als MCP. Wo MCP Agenten mit Tools verbindet, verbindet A2A Agenten mit anderen Agenten, auch solchen, die mit anderen Frameworks von anderen Teams gebaut wurden.
ADKs A2A-Support ermöglicht:
- Jeden ADK-Agenten als A2A-Server bereitstellen, den andere Agenten (aus LangGraph, CrewAI oder beliebigen anderen Frameworks) finden und aufrufen können
- Externe A2A-Agenten einbinden in die eigene ADK-Anwendung
- Frameworks mischen im selben System: der Orchestrator in ADK, ein spezialisierter Analyse-Agent in LangGraph, ein Datenpipeline-Agent in CrewAI
Für Unternehmen im DACH-Raum, die Agenten verschiedener Anbieter einsetzen, ist A2A-Support keine Spielerei. Es ist der Unterschied zwischen einer Sammlung isolierter Agenten und einem funktionierenden Multi-Agent-System, das den Anforderungen des EU AI Act an Transparenz und Nachvollziehbarkeit gerecht werden kann.
ADK vs. LangGraph vs. CrewAI: Wann welches Framework?
Die drei Frameworks lösen überlappende, aber unterschiedliche Probleme.
Google ADK wählen, wenn:
- Natives MCP und A2A ohne Adapter-Pakete gebraucht wird
- Das Team bereits Google Cloud nutzt (Vertex AI, BigQuery, Cloud Run)
- Multi-Sprachen-Support gewünscht ist (Python, TypeScript, Go, Java)
- Agenten mit Agenten aus anderen Frameworks zusammenarbeiten müssen
- Hierarchie-basierte Orchestrierung dem Graphen-Ansatz vorgezogen wird
LangGraph wählen, wenn:
- Feingranulare Kontrolle über jeden Zustandsübergang nötig ist
- Agent-Workflows komplexe Bedingungen und Wiederholungslogik haben
- Das ausgereifteste Observability-Tooling (LangSmith) gebraucht wird
- Bereits in das LangChain-Ökosystem investiert wurde
CrewAI wählen, wenn:
- Prototyping-Geschwindigkeit wichtiger ist als Architekturkontrolle
- Das Agentensystem natürlich auf Teamrollen abbildbar ist
- Die niedrigste Einstiegshürde gewünscht wird
Ein entscheidender Unterschied: ADKs modell-agnostische Unterstützung geht über Gemini hinaus durch LiteLLM-Integration. Claude, GPT-4, Mistral, Llama und alle von LiteLLM unterstützten Modelle funktionieren. Kein Lock-in bei Google-Modellen, auch wenn Gemini bevorzugt optimiert wird.
Deployment: Vom Laptop bis Vertex AI
ADK bietet vier Deployment-Pfade:
Lokale Entwicklung. adk web startet eine Web-UI, die Agenteninteraktionen, Tool-Aufrufe und Session-State in Echtzeit zeigt. Die CLI unterstützt auch adk run fürs Terminal und adk eval für Evaluierungs-Datensätze.
Cloud Run. Agent mit Dockerfile containerisieren und auf Cloud Run deployen. Google stellt ein Quickstart-Template bereit, das Health-Checks, Skalierung und Session-Management abdeckt.
Vertex AI Agent Engine. Die vollständig verwaltete Option. Agentencode hochladen, Google kümmert sich um Infrastruktur, Skalierung, Monitoring und Integration mit über 100 vorgefertigten Konnektoren (Salesforce, SAP, ServiceNow). Hier landen Enterprise-Teams mit Compliance-Anforderungen.
Docker/Kubernetes. Für Teams, die volle Infrastrukturkontrolle brauchen, laufen ADK-Agenten in Standard-Docker-Containern auf jedem Kubernetes-Cluster, ob GKE, EKS oder On-Premises.
Die Deployment-Flexibilität beseitigt das “Vendor-Lock-in”-Argument. Man kann auf Vertex AI starten und bei geänderten Anforderungen auf selbstgehostetes Kubernetes migrieren.
Eingebaute Evaluation: Agenten testen wie Software
ADK enthält ein Evaluation-Framework, das Agenten-Tests als Kernfunktion behandelt. Man definiert Testfälle als Datensätze und führt sie gegen den Agenten aus, um Antwortqualität, Tool-Nutzung und Multi-Turn-Kohärenz zu messen.
adk eval --agent my_agent --eval_set test_cases.json
Für Teams, die produktive Agentensysteme bauen, wo nicht-deterministische Ausgaben traditionelle Unit-Tests unzureichend machen, erspart eingebauter Evaluation-Support den Aufbau einer separaten Test-Infrastruktur.
Was ADK (noch) nicht gut kann
ADK passt nicht zu jedem Projekt:
Observability hinkt hinterher. LangGraph hat LangSmith. ADK hat Vertex AI Tracing und Cloud Logging, was im Google-Ökosystem gut funktioniert, aber weniger flexibel ist als eine framework-agnostische Lösung. Teams, die Langfuse oder Arize Phoenix nutzen, brauchen Custom-Integration.
Community und Ökosystem sind jünger. LangGraph hat über 24.000 Stars und jahrelange LangChain-Tooling-Geschichte. ADKs 17.600 Stars und wachsende Community sind stark für ein Framework, das erst im April 2025 startete, aber die Zahl an Tutorials, Stack-Overflow-Antworten und Community-Erweiterungen ist noch kleiner.
Session-Management ist Vertex-zentrisch. ADKs Session-Handling funktioniert lokal, aber die produktionsreifen Features (persistente Sessions, Cross-Session-Memory, automatisches State-Management) setzen stark auf Vertex AI Agent Engine. Self-Hosted-Deployments erfordern mehr manuelles Session-Management.
Kein visueller Graph-Editor. LangGraphs Graphen-Modell macht Agent-Workflows visuell inspizierbar. ADKs Hierarchie-Modell ist bei komplexen Multi-Agent-Systemen schwerer zu visualisieren, auch wenn die adk web-UI eine schrittweise Ausführungsverfolgung bietet.
Häufig gestellte Fragen
Was ist Google ADK (Agent Development Kit)?
Google ADK ist ein Open-Source-Framework mit Code-First-Ansatz für den Bau von KI-Agenten und Multi-Agent-Systemen. Es unterstützt Python, TypeScript, Go und Java, bietet native MCP- und A2A-Protokollunterstützung und lässt sich überall einsetzen, vom lokalen Rechner bis zu Vertex AI Agent Engine.
Ist Google ADK kostenlos?
Ja. Google ADK ist Open Source unter der Apache-2.0-Lizenz, ohne Lizenzgebühren oder Abonnements. Installation mit pip install google-adk. Vertex AI Agent Engine (die verwaltete Deployment-Option) hat eigene Preise, aber das Framework selbst ist kostenlos.
Kann Google ADK andere Modelle als Gemini verwenden?
Ja. ADK ist für Gemini optimiert, unterstützt aber jedes Modell über LiteLLM-Integration: Claude, GPT-4, Mistral, Llama und alle von LiteLLM unterstützten Modelle. Es gibt keinen Lock-in bei Google-Modellen.
Wie unterscheidet sich Google ADK von LangGraph?
ADK nutzt Hierarchie-basierte Agentenorchestrierung mit nativer MCP- und A2A-Unterstützung, während LangGraph graphenbasierte Zustandsmaschinen mit feingranularer Kontrolle über den Ausführungsfluss verwendet. ADK ist einfacher zum Starten; LangGraph gibt mehr Kontrolle bei komplexen bedingten Workflows. ADK unterstützt vier Sprachen; LangGraph Python und JavaScript.
Unterstützt Google ADK die MCP- und A2A-Protokolle?
Ja, und das ist ADKs zentrales Unterscheidungsmerkmal. Sowohl MCP (für Agent-zu-Tool-Kommunikation) als auch A2A (für Agent-zu-Agent-Kommunikation) sind in das Kern-Framework eingebaut, nicht über externe Plugins hinzugefügt. Jeder MCP-Server und jeder A2A-kompatible Agent lässt sich sofort integrieren.