google/adk-go: Go-Toolkit für Agenten mit Code-First-Anspruch
An open-source, code-first Go toolkit for building, evaluating, and deploying sophisticated AI agents with flexibility and control.
Auf einen Blick
- Was ist das?
- Das Agent Development Kit für Go definiert Agenten, Tools und Orchestrierung direkt als Go-Code. Wer cloud-native Agenten in Go baut, findet hier eine modulare Basis. Wer fertige No-Code-Oberflächen sucht, ist falsch.
- Für wen ist es gedacht?
- Für Go-Teams mit Cloud-native-Anforderungen und Gemini- oder Vertex-AI-Nähe ist adk-go eine naheliegende Wahl, weil Agentenlogik als versionierbarer Go-Code vorliegt. Wer eine stabile v1-API ohne Bruchstellen braucht oder Python-Ökosysteme vorzieht, sollte vorher die Versionshinweise prüfen: Das Modul liegt unter google.golang.org/adk/v2, parallel existiert v1.6.1.
- Darf ich es kommerziell nutzen?
- Ja. Apache-2.0 ist eine freizügige Lizenz: Sie dürfen darauf aufbauende Software nutzen, verändern und verkaufen, solange Sie die Urheberrechts- und Lizenzhinweise beibehalten.
- Wird es noch gepflegt?
- Ja. Die letzten Commits kamen vor 1 Tag.
- In welcher Sprache ist es geschrieben?
- Hauptsächlich Go, laut der Sprachstatistik von GitHub.
Die Antworten beruhen auf den GitHub-Daten des Projekts (zuletzt abgeglichen am 15. September 2026) und auf unserer Analyse. Sie sind keine Rechtsberatung.
TIEFGEHENDE OPEN-SOURCE-ANALYSE
Welches Problem adk-go löst und für wen
Ein Agent, der mehrere Werkzeuge aufruft, Zwischenergebnisse weiterreicht und bei Bedarf an einen zweiten Agenten delegiert, ist im Kern ein Kontrollflussproblem. Genau dort setzt adk-go an. Das Repository beschreibt sich als code-first Go-Toolkit zum Bauen, Evaluieren und Deployen von Agenten. Agentenlogik, Tools und Orchestrierung liegen in Go vor, nicht in Konfigurationsdateien oder einer grafischen Oberfläche.
Die Zielgruppe benennt das README selbst: Entwickler, die cloud-native Agentenanwendungen bauen und dabei Go für Nebenläufigkeit und Laufzeitverhalten nutzen wollen. Das schließt Teams ein, die bereits Go-Dienste betreiben und keinen zweiten Sprach-Stack für Agenten einführen möchten. Es schließt Teams aus, die einen visuellen Builder oder eine reine Prompt-Verwaltung suchen. Wer Agenten ausschließlich über YAML definiert, findet hier keinen Anknüpfungspunkt.
Der Aufbau: Agenten als komponierbare Go-Objekte
Das README nennt zwei tragende Eigenschaften: modulare Multi-Agent-Systeme und einen Tool-Ökosystem aus vorgefertigten Tools, eigenen Funktionen und bestehenden Integrationen. Mehrere spezialisierte Agenten werden also zu einer größeren Anwendung komponiert, statt einen monolithischen Agenten mit vielen Tools zu bauen. Das ist die Architekturentscheidung, die den Rest prägt: Ein Agent bleibt klein genug, um testbar zu sein, und die Komposition übernimmt die Rolle, die in anderen Frameworks eine zentrale Prompt-Datei spielt.
Das Modul ist als google.golang.org/adk/v2 versioniert, was auf die übliche Go-Major-Versionierung hindeutet. Ein API-Bruch zwischen v1 und v2 ist damit ausdrücklich vorgesehen. Die Themenliste des Repositories verweist auf a2a, mcp, gemini und vertex-ai. Daraus lässt sich ableiten, dass Agent-zu-Agent-Kommunikation und das Model Context Protocol als Integrationspfade vorgesehen sind, doch die bereitgestellten Materialien erläutern die konkrete Verdrahtung nicht. Wer diese beiden Punkte als Auswahlkriterium nutzt, muss die Dokumentation selbst prüfen.
Die Modell-Anbindung ist laut README auf Gemini optimiert, aber nicht darauf festgelegt. Das Toolkit bezeichnet sich als modell- und deployment-agnostisch und kompatibel mit anderen Frameworks. Diese Aussage stammt aus der Projektbeschreibung und ist nicht durch Beispiele im vorliegenden Material belegt.
Installation und der erste Einstiegspunkt
Die Installation ist ein einzelner Go-Befehl:
go get google.golang.org/adk/v2
Damit ist die Abhängigkeit im Modul eingetragen. Ein Konfigurationsschlüssel oder eine globale Einstellung ist im README nicht dokumentiert. Der Einstieg läuft über Go-Code, was zur code-first Positionierung passt.
Für die Arbeit mit einem Coding-Agenten verweist das Projekt auf zwei maschinenlesbare Indexdateien: adk.dev/llms.txt als Verzeichnis und adk.dev/llms-full.txt als einzelne Datei mit der gesamten Dokumentation, generiert aus dem Repository adk-docs. Beide enthalten laut README die Go-API-Referenz und Beispiele. Das README liefert dazu einen konkreten Prompt als Vorlage:
Plan and implement an agent that reviews customer issues and generates a report. Use the ADK Go framework, referring to https://adk.dev/llms-full.txt for sample code.
Wer am Repository selbst arbeiten will statt es zu nutzen, wird auf AGENTS.md verwiesen. Das ist ein sinnvoller Hinweis, denn die Anforderungen an einen Beitragenden unterscheiden sich von denen an einen Nutzer der Bibliothek.
Lizenz und der Sonderfall internal/httprr
Das Projekt steht unter Apache-2.0. Das ist eine permissive Lizenz mit ausdrücklicher Patentgewährung, die kommerzielle Nutzung, Änderung und Weitergabe erlaubt, solange Lizenz- und Urheberrechtshinweise erhalten bleiben. Für die Einbettung in ein proprietäres Produkt ist das der übliche, unkomplizierte Fall.
Es gibt eine Ausnahme, die im README ausdrücklich benannt wird: das Verzeichnis internal/httprr hat eine eigene LICENSE-Datei. Wer den Code in diesem Verzeichnis übernimmt oder anpasst, muss diese separate Datei lesen. Das ist kein Nebensatz, denn internal-Pakete werden in Go nicht als öffentliche API behandelt, und eine abweichende Lizenz innerhalb eines ansonsten einheitlich lizenzierten Repositories ist genau die Stelle, an der eine automatisierte Lizenzprüfung im CI falsch positiv anschlägt. Eine rechtliche Bewertung kann hier nicht erfolgen; die Lizenztexte selbst sind maßgeblich.
Zwei Versionslinien parallel: v1.6.1 und v2.3.0
Die Release-Liste zeigt ein Muster, das man kennen sollte, bevor man adk-go in ein bestehendes Produkt zieht. Innerhalb weniger Wochen erscheinen v2.3.0, v1.6.0 und v1.6.1. Es laufen also mindestens zwei Versionslinien nebeneinander: die v2-Linie, auf die der Installationsbefehl zeigt, und eine v1-Linie, die weiterhin Patch-Releases erhält.
Für ein junges Toolkit ist das nicht ungewöhnlich, aber es hat Konsequenzen. Ein Team, das heute auf v2 geht, muss damit rechnen, dass sich die API weiter bewegt. Ein Team, das auf v1.6.1 bleibt, bekommt Korrekturen, verpasst aber die v2-Entwicklung. Die Entscheidung ist nicht technisch neutral, denn sie bestimmt, wie viel Anpassungsarbeit bei jedem Upgrade anfällt. Wer die Versionshinweise nicht liest, wird den Unterschied zwischen v1 und v2 erst beim Kompilieren bemerken.
Ein weiteres Signal: das Repository hat einen Nightly-Check als GitHub Action. Das deutet auf laufende automatisierte Prüfungen hin, ersetzt aber keine Aussage über Stabilität der öffentlichen API.
Grenzen und der Fall, in dem adk-go das falsche Werkzeug ist
Die offensichtlichste Einschränkung liefert das Material selbst. Die Dokumentation erläutert weder die konkrete Verdrahtung von MCP noch die von a2a, obwohl beide als Themen geführt werden. Wer diese Integrationen als Kernanforderung hat, muss den Umfang in der verlinkten Dokumentation prüfen, statt sich auf die Themenliste zu verlassen.
Die zweite Einschränkung ist die Modell-Anbindung. Das README nennt Gemini als optimiertes Ziel und behauptet gleichzeitig Modell-Agnostizität. Zwischen diesen beiden Aussagen liegt eine Spannung, die das Material nicht auflöst. Wer einen anderen Anbieter als primäres Modell einsetzt, sollte vor der Adoption verifizieren, wie viel Aufwand die Anbindung tatsächlich kostet.
Der dritte Punkt ist struktureller Natur. Code-first bedeutet, dass jede Änderung an Agentenverhalten ein Code-Review, ein Testlauf und ein Deployment ist. Für Teams, die Prompts täglich ohne Release anpassen wollen, ist das die falsche Betriebsform. Der Vorteil, Versionierung und Testbarkeit, wird zum Nachteil, wenn schnelle Iteration ohne Build-Pipeline gefordert ist. Hier ist adk-go nicht die bessere oder schlechtere Wahl, sondern schlicht die falsche.
Alternative: Python ADK und die Frage der Sprachgrenze
Die naheliegendste Alternative ist das Python ADK aus demselben Projektverbund, das im README direkt verlinkt ist. Der Unterschied liegt nicht im Funktionsumfang, sondern im Betriebsmodell. Python-ADK richtet sich an Teams, die im Python-Ökosystem arbeiten, wo ein großer Teil der Modell- und Datenwerkzeuge zu Hause ist. adk-go richtet sich an Teams, die Go bereits im Produktivbetrieb haben.
Die eigentliche Abwägung ist damit die Sprachgrenze. Ein Agent, der in Go geschrieben ist, lässt sich in einen bestehenden Go-Dienst als Bibliothek einbetten, mit denselben Build-Werkzeugen, demselben Deployment und demselben Nebenläufigkeitsmodell. Ein Python-Agent daneben bedeutet einen zweiten Prozess, eine zweite Abhängigkeitskette und eine Schnittstelle dazwischen. Umgekehrt gilt: Wenn das Team kein Go schreibt, ist der Einstieg in adk-go teurer als der in eine Sprache, die es schon beherrscht. Die Entscheidung fällt also nicht über die Bibliothek, sondern über die vorhandene Codebasis.
Im selben Verbund existieren laut README außerdem Java-, Kotlin- und TypeScript-Versionen sowie ADK Web. Für Teams mit JVM- oder Node-Backends ist eine dieser Varianten möglicherweise die konsistentere Wahl als ein Go-Dienst, der nur für Agenten existiert.
Wartung, Upgrades und was vor der Adoption zu prüfen ist
Die Wartungslast liegt bei adk-go primär in der Versionsverfolgung. Zwei parallele Linien, ein Modulpfad mit /v2 und ein Installationsbefehl, der bereits auf v2 zeigt, bedeuten, dass ein Upgrade nicht allein durch go get erledigt ist. Wer den Modulpfad ändert, muss Importe anpassen und die Kompilierung neu durchlaufen lassen. Das ist mechanische Arbeit, aber sie fällt gebündelt an.
Hinzu kommt die Lizenzpflege. Apache-2.0 verlangt, dass Hinweise erhalten bleiben. Bei einer Bibliothek, die als Abhängigkeit eingebunden wird, ist das unkritisch. Sobald Code kopiert oder internal/httprr übernommen wird, ändert sich die Lage, und die separate LICENSE-Datei dieses Verzeichnisses muss mitgeführt werden. Eine automatisierte Lizenzprüfung im Build sollte auf diesen Pfad gesondert konfiguriert werden, sonst entsteht entweder ein falscher Alarm oder eine übersehene Ausnahme.
Vor der Adoption sind drei Dinge konkret zu verifizieren. Erstens: die Beispiele unter github.com/google/adk-go/tree/main/examples gegen die eigene Anforderung legen, insbesondere wenn MCP oder a2a gebraucht werden. Zweitens: die Versionshinweise zu v1.6.1 und v2.3.0 lesen, um den Umfang der API-Änderungen einzuschätzen. Drittens: adk.dev/llms-full.txt als Kontextquelle für einen Coding-Agenten nutzen, um die tatsächlich verfügbare Go-API zu sichten, bevor Architekturentscheidungen fallen. Ob das Toolkit für einen konkreten Anwendungsfall passt, lässt sich aus dem vorliegenden Material nicht abschließend beurteilen.
Redaktionelles Fazit
Für Go-Teams mit Cloud-native-Anforderungen und Gemini- oder Vertex-AI-Nähe ist adk-go eine naheliegende Wahl, weil Agentenlogik als versionierbarer Go-Code vorliegt. Wer eine stabile v1-API ohne Bruchstellen braucht oder Python-Ökosysteme vorzieht, sollte vorher die Versionshinweise prüfen: Das Modul liegt unter google.golang.org/adk/v2, parallel existiert v1.6.1. Vor dem Adoptionsentscheid lohnt ein Blick in die Beispiele unter github.com/google/adk-go/tree/main/examples und in adk.dev/llms-full.txt, um den Umfang der Go-API gegen die eigene Anforderung zu legen.
Community-Notizen