Genkit: Googles Agenten-Framework zwischen vier SDKs und einem Firebase-Vertrag
Open-source framework for building agentic apps in JavaScript, Go, Dart, and Python, built and used in production by Google
Auf einen Blick
- Was ist das?
- Genkit bündelt Modellaufrufe, Tool-Calling, RAG und Flows hinter einer einheitlichen API, mit SDKs für TypeScript, Go, Python und Dart. Der Reiz liegt in der Sprachvielfalt, der Haken in den sehr unterschiedlichen Reifegraden und in der Bindung an die Google-Toolchain.
- Für wen ist es gedacht?
- Wer bereits in der Google-Welt arbeitet und Agentenlogik in TypeScript oder Go schreibt, bekommt mit Genkit eine Struktur, die Deployment und Tracing mitliefert. Wer Python oder Dart einsetzen will, sollte zuerst den Reifegrad des jeweiligen SDK gegen die eigene Roadmap prüfen, statt von der Sprachliste auf Feature-Parität zu schließen.
- 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. Das Repository hat innerhalb des letzten Tages neue Commits erhalten.
- In welcher Sprache ist es geschrieben?
- Hauptsächlich TypeScript, 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
Was Genkit löst, und für wen
Die meisten Teams, die eine KI-Funktion in eine bestehende Anwendung einbauen, schreiben zuerst denselben Code dreimal: einmal für den Modellaufruf, einmal für das Parsen der Antwort, einmal für die Fehlerbehandlung, wenn das Modell nicht das liefert, was der Prompt versprochen hat. Genkit setzt genau dort an. Das README beschreibt einen einheitlichen Aufruf über mehrere Anbieter hinweg und nennt Google, OpenAI, Anthropic und Ollama als Beispiele. Der Nutzen ist nicht, dass ein Modell besser antwortet, sondern dass der umgebende Code nicht bei jedem Anbieterwechsel neu entsteht.
Die Zielgruppe lässt sich aus der Aufzählung der Fähigkeiten ablesen: Chatbots, Automatisierungen, Empfehlungssysteme. Das sind Anwendungen mit Serveranteil, mehreren Schritten und dem Bedarf, Zwischenergebnisse zu prüfen. Ein einzelner Prompt in einem Skript braucht kein Framework dieser Größe. Sobald aber Tool-Aufrufe, Retrieval und strukturierte Ausgaben zusammenkommen, wird die Verdrahtung zum eigentlichen Aufwand, und hier positioniert sich Genkit.
Bemerkenswert ist die Herkunft. Das Projekt wird laut README von Googles Firebase gebaut und produktiv genutzt. Das erklärt, warum Deployment-Ziele wie Cloud Functions for Firebase und Cloud Run prominent genannt werden. Es erklärt auch, warum die Sprache TypeScript ist, obwohl vier SDKs angeboten werden: Die JS-Variante ist das Referenz-SDK, an dem sich die anderen orientieren.
Der Aufbau: ein Objekt, Plugins, Provider
Das README zeigt den Einstieg in wenigen Zeilen. Aus dem Paket genkit wird die Funktion genkit importiert, aus @genkit-ai/google-genai der Provider googleAI. Beim Aufruf von genkit() wird eine Plugin-Liste übergeben, hier googleAI(). Danach läuft alles über das zurückgegebene Objekt ai: ai.generate() bekommt ein Modell, das über googleAI.model('gemini-flash-latest') referenziert wird, und einen Prompt.
Das ist mehr als Syntax. Der Provider ist die einzige Stelle, an der ein konkreter Anbieter auftaucht. Das Modell wird nicht als String, sondern als vom Provider erzeugtes Objekt übergeben. Wer den Anbieter wechselt, tauscht das Plugin und die Modellreferenz, nicht die Aufrufstruktur. Die Dokumentation verweist für weitere Provider auf eigene Plugin-Seiten, etwa für OpenAI und Ollama.
Die Fähigkeitsliste nennt, was auf diesem Fundament aufsetzt: Text- und Bildgenerierung, typisierte strukturierte Ausgaben, Tool-Calling, Prompt-Templating, persistierte Chat-Schnittstellen, Flows und RAG. Flows sind dabei der Teil, der über einen einzelnen Aufruf hinausgeht. Die Dokumentation verlinkt sie unter /docs/flows und beschreibt damit Workflows, die mehrere Schritte zusammenfassen. Für Agenten ist das die relevante Ebene, weil ein Agent genau aus einer Kette von Modellaufrufen und Werkzeugausführungen besteht.
Auffällig ist, was das README nicht zeigt. Es gibt kein Beispiel für einen Flow, keines für Tool-Definitionen und keines für die RAG-Pipeline. Diese Details liegen ausschließlich in der verlinkten Dokumentation. Wer nur das Repository öffnet, sieht die Oberfläche, nicht die Mechanik.
Vom Klon zum laufenden Flow
Der README skizziert einen vierstufigen Pfad. Zuerst Sprache und Anbieter wählen und einen API-Schlüssel besorgen, wobei ausdrücklich vermerkt ist, dass manche Anbieter wie Vertex AI einen anderen Authentifizierungsweg nutzen. Dann SDK, Anbieterpaket und die Genkit CLI installieren, die Pakete importieren und Genkit mit dem Schlüssel initialisieren. Danach die eigentliche Funktion schreiben und mit CLI und Developer UI testen. Zuletzt deployen und im Firebase-Konsolen-Dashboard beobachten.
Die CLI ist damit kein Zusatzwerkzeug, sondern Teil des vorgesehenen Arbeitsablaufs. Das README beschreibt sie zusammen mit der Developer UI als lokale Umgebung, in der sich Prompts und Flows gegen einzelne Eingaben oder ganze Datensätze testen lassen. Man kann Ausgaben verschiedener Modelle vergleichen und Ausführungen über Traces nachvollziehen. Für die Fehlersuche an mehrstufigen Ketten ist das der praktischste Teil des Angebots, weil ein Trace zeigt, welcher Schritt welche Antwort erhalten hat.
Was das README offenlässt, sind die konkreten Kommandos. Es nennt keine Installationsbefehle, keine CLI-Aufrufe, keine Konfigurationsschlüssel. Die stehen auf genkit.dev, nicht im Repository-Text. Wer die Einrichtung plant, muss also mit der Dokumentationsseite arbeiten und nicht mit dem README allein. Das ist eine bewusste Trennung, aber sie macht den Repository-Text als Einstiegsquelle unvollständig.
Vier SDKs, vier Reifegrade
Das README ist an dieser Stelle ungewöhnlich deutlich. JavaScript und TypeScript gelten als produktionsreif mit vollem Funktionsumfang, Go ebenso. Python trägt das Label Beta und wird als breit unterstützt beschrieben, aber noch nicht ganz produktionsreif. Dart ist Preview, in früher Entwicklung mit Kernfunktionalität.
Für die Entscheidung ist das der wichtigste Absatz des ganzen Dokuments. Ein Team, das wegen einer Python-Codebasis zu Genkit greift, bekommt nicht dieselbe Oberfläche wie ein TypeScript-Team, sondern eine, die sich noch bewegt. Die Release-Historie stützt diese Einschätzung: Die jüngsten Einträge umfassen py/v0.11.0 und go/v1.13.1. Die Versionsnummern liegen weit auseinander, und die Null vor der Eins im Python-SDK ist kein Zufall, sondern eine Aussage über API-Stabilität.
Wer plattformübergreifend plant, sollte die Reifegrade als Vertrag lesen und nicht als Momentaufnahme. Ein Wechsel von Preview auf produktionsreif ist ein Ereignis, auf das man wartet, nicht eines, das man einplant. Für Dart gilt das umso mehr: Kernfunktionalität bedeutet, dass Randfälle und weniger genutzte Fähigkeiten fehlen können.
Wo Genkit die falsche Wahl ist
Die erste Grenze ist die Sprache. Wenn das Team in Rust, Java oder C# arbeitet und keine Bereitschaft besteht, einen Dienst in einer der vier unterstützten Sprachen danebenzustellen, ist Genkit schlicht nicht verfügbar. Das ist keine Frage der Qualität, sondern der Abdeckung.
Die zweite Grenze ist die Bindung an die Google-Oberfläche. Das README betont zwar, dass Deployment mit oder ohne Google-Dienste möglich ist, und nennt Drittanbieter-Plattformen. Die Produktionsbeobachtung wird jedoch als Dashboard in der Firebase-Konsole beschrieben. Wer bereits eine eigene Telemetrie- und Tracing-Infrastruktur betreibt, bekommt hier einen zweiten Ort, an dem dieselben Daten liegen. Ob sich die Observability-Ausgabe in bestehende Systeme einspeisen lässt, geht aus dem README nicht hervor. Das ist eine offene Frage, die man vor der Einführung klären sollte.
Die dritte Grenze ist die Größe. Genkit bringt Plugins, CLI, Developer UI, Flow-Konzepte und Client-SDKs mit. Für einen einzelnen Aufruf gegen ein Modell ist das mehr Struktur, als die Aufgabe verlangt. Der Aufwand, sich in die Flow- und Plugin-Konzepte einzuarbeiten, amortisiert sich erst, wenn mehrere Modelle, mehrere Schritte oder mehrere Ausgabeformate im Spiel sind.
Schließlich die Frage der Reife in Python und Dart. Die Beta- und Preview-Kennzeichnung ist kein Formfehler, sondern ein Hinweis darauf, dass sich APIs zwischen Versionen ändern können. Wer dort baut, plant ein Upgrade ein, bevor die erste Zeile Produktionscode steht.
Der Vergleich mit direkt verdrahteten SDKs
Die naheliegende Alternative ist, die Anbieter-SDKs direkt zu verwenden, also das OpenAI- oder Google-SDK ohne Zwischenschicht. Der Unterschied liegt nicht in der Funktionalität der Modellaufrufe, sondern in allem danach. Ein direktes SDK liefert eine Antwort. Genkit liefert zusätzlich eine Struktur für Tool-Aufrufe, für die Validierung strukturierter Ausgaben, für die Verkettung mehrerer Schritte und für die Auswertung über Traces.
Konkret heißt das: Wer strukturierte Ausgaben braucht, schreibt gegen ein direktes SDK entweder einen JSON-Parser mit Wiederholungsversuch oder akzeptiert gelegentlich unbrauchbare Antworten. Genkit beschreibt typisierte, strukturierte Datengenerierung als eigene Fähigkeit, verlinkt unter /docs/models#structured-output. Wer Tool-Calling braucht, definiert bei einem direkten SDK das Schema selbst und ruft die Funktion selbst auf. Genkit führt Tool-Calling als eigenen Dokumentationsbereich.
Eine zweite Alternative sind Frameworks, die auf eine einzige Sprache zugeschnitten sind und dafür tiefer in deren Ökosystem reichen. Deren Vorteil ist, dass sie keine Abstraktion über vier Sprachen tragen müssen. Der Preis ist, dass ein Sprachwechsel im Team einen Wechsel des Frameworks bedeutet. Genkit tauscht diese Bindung gegen eine geringere Tiefe pro Sprache. Welche Seite schwerer wiegt, hängt davon ab, ob das Team polyglott arbeitet.
Wartung, Versionen und Lizenz
Das Repository wird aktiv gepflegt, der letzte Push liegt laut Metadaten bei September 2026, und die Releases folgen in kurzen Abständen, sowohl für Go als auch für Python. Für die Wartung bedeutet das zweierlei. Erstens ist mit regelmäßigen Updates zu rechnen, was gut ist. Zweitens sind Upgrades ein wiederkehrender Posten, und bei einem Python-SDK in der Nuller-Version können sie Schnittstellen betreffen.
Die Versionsnummern der SDKs laufen getrennt voneinander, py/ und go/ als Präfixe. Es gibt also keine gemeinsame Framework-Version, an der sich alle Sprachen orientieren. Wer mehrere Sprachen einsetzt, muss mehrere Upgrade-Zyklen verfolgen. Das ist ein realer Betriebsaufwand, der in keiner Fähigkeitsliste auftaucht.
Die Lizenz ist Apache-2.0. Das ist eine permissive Lizenz, die kommerzielle Nutzung, Änderung und Weitergabe erlaubt und eine ausdrückliche Patentgewährung enthält. Wer das Projekt verändert und weitergibt, muss die Lizenzbedingungen und Hinweise mitführen. Für eine rechtliche Bewertung der eigenen Nutzung ist das Repository nicht die richtige Quelle, und diese Einschätzung ersetzt keine Rechtsberatung.
Was sich nicht aus dem Material ableiten lässt, ist der Aufwand für ein Upgrade konkret. Ob ein Sprung von py/v0.11.0 auf die nächste Version Anpassungen erfordert, steht in den Release Notes, nicht im README. Wer Python einsetzt, sollte dort nachsehen, bevor er den Versionsbereich in seiner Abhängigkeitsdatei festlegt.
Die Entscheidung
Genkit ist ein Framework für Teams, die Agentenlogik serverseitig betreiben und dabei in TypeScript oder Go arbeiten. Diese beiden SDKs sind laut README produktionsreif mit vollem Funktionsumfang, und für sie ist die Kombination aus einheitlicher Anbieter-API, lokaler Developer UI mit Traces und einem vorgezeichneten Deployment-Pfad stimmig. Wer ohnehin auf Cloud Run oder Firebase deployt, bekommt die Beobachtung ohne zusätzliche Bauteile.
Für Python-Teams ist die Lage anders. Beta bedeutet, dass die Fähigkeiten breit sind, die Stabilität aber nicht garantiert ist. Wer hier einsteigt, sollte den Versionsbereich bewusst wählen und die Release Notes als Pflichtlektüre behandeln. Für Dart gilt das stärker, Preview mit Kernfunktionalität heißt, dass man den Umfang der eigenen Anforderungen vorher gegen die Dokumentation hält.
Und wer einen Anbieterwechsel als zentrale Anforderung hat, sollte nicht die Liste der unterstützten Anbieter prüfen, sondern die Plugin-Dokumentation des Zielanbieters, bevor der erste Commit entsteht. Die Abstraktion hilft nur so weit, wie das Plugin für den Zielanbieter die benötigten Fähigkeiten tatsächlich abdeckt.
Redaktionelles Fazit
Wer bereits in der Google-Welt arbeitet und Agentenlogik in TypeScript oder Go schreibt, bekommt mit Genkit eine Struktur, die Deployment und Tracing mitliefert. Wer Python oder Dart einsetzen will, sollte zuerst den Reifegrad des jeweiligen SDK gegen die eigene Roadmap prüfen, statt von der Sprachliste auf Feature-Parität zu schließen. Und wer einen Anbieterwechsel als Kernanforderung hat, sollte vor dem ersten Commit die Plugin-Dokumentation des Zielanbieters lesen, nicht die des aktuellen.
Community-Notizen