Gemini-API in Python: Derselbe zustandslose Schleifenmechanismus mit Modellrollen und Chat-Objekten.
Gemini über das google-genai SDK in Python aufrufen: Inhalt und Komponenten, system_instruction, Tokenverwendung sowie ein Chat-Objekt, das die Historie auf der Client-Seite verfolgt.
Quellen: Part 4 — Call the Gemini API in Python (user / model, same loop)
Nach OpenAI und Claude ist Googles Gemini der dritte Anbieter, der dasselbe Muster zeigt: ein stateless Endpoint, eine nach Rolle gekennzeichnete Konversation sowie die vollständige Historie bei jedem Aufruf. Gemini weist zudem eine angenehme Besonderheit in seiner Benennung auf.
Neubenennungen statt Neugestaltung
Die Struktur der Konversation bei Gemini entspricht der von OpenAI und Claude – abgesehen von zwei Neubenennungen. Die Rolle des Assistenten wird als model bezeichnet. Diese Bezeichnung ist wohl ehrlicher, da „Assistent“ auf eine bestimmte Persönlichkeit hindeutet, während model lediglich ausdrückt, dass der Text von einem Modell stammt. Es nimmt denselben Platz in der Liste ein. Der Systemprompt wird zu system_instruction, der in einem Config-Objekt übergeben wird und nicht in der Nachrichtenliste. Das ist die Idee von Claudes „System an der Seite“ auf einer weiteren Ebene umgesetzt.
Die Liste der Nachrichten wird über contents bereitgestellt. Jeder Eintrag enthält parts, da Gemini Texte, Bilder und Audio nativ verarbeiten kann. Bei Chats mit reinem Text wird nichts davon angezeigt: Eingaben sind Strings, und als Ausgabe kommt resp.text.
Eine Warnung bezüglich Bibliotheken vor dem Code: Google hat im Laufe der Jahre mehrere Python-Pakete veröffentlicht, und ältere Tutorials sind voller veralteter Importe wie google-generativeai sowie Wrapper aus der Bard-Ära. Das aktuelle offizielle SDK ist google-genai, das mit from google import genai importiert wird – und dieses wird hier verwendet.
Einrichtung und ein einziger Turn
Installieren Sie es mit pip install google-genai, erstellen Sie einen Schlüssel in Google AI Studio und exportieren Sie ihn als GEMINI_API_KEY. Der Client holt den Schlüssel aus der Umgebung ab, sodass er niemals im Code erscheint.
# current official SDK: pip install google-genai
from google import genai
from google.genai import types
client = genai.Client() # key from env
resp = client.models.generate_content(
model="gemini-2.5-flash",
contents="Why does Gemini name the reply "
"role 'model', not 'assistant'?",
config=types.GenerateContentConfig(
system_instruction="Be concise.",
temperature=0,
),
)
print(resp.text)
Zum Vergleich zu den beiden vorherigen Anbietern ist messages nun contents, und ein einzelner Turnus kann eine einfache Zeichenkette sein. Die Systemanweisung wird in GenerateContentConfig übernommen. Die Temperatur ist wieder ein normales Konfigurationsfeld, das im aktuellen Claude SDK entfernt wurde. Die Antwort ist einfach resp.text, und die Tokenzahlen finden sich in resp.usage_metadata als prompt_token_count und candidates_token_count – dieselben Werte nur mit Googles eigenen Bezeichnungen. Protokollieren Sie sie stets.
Ein verwalteter Historiezyklus
Es ist möglich, Ihre eigene ask()-Funktion direkt zu portieren: Speichern Sie die Werte von user und model in einer Liste, fügen Sie jeden Austausch hinzu und übergeben Sie jedes Mal erneut contents=. Das funktioniert. Dennoch bietet das SDK eine Bequemlichkeit, die die OpenAI- und Anthropic-Klienten von vornherein nicht bieten: ein Chat-Objekt, das das Hinzufügen übernimmt.
chat = client.chats.create(
model="gemini-2.5-flash",
config=types.GenerateContentConfig(
system_instruction="Be concise.",
),
)
r1 = chat.send_message(
"Define a context window."
)
print(r1.text)
r2 = chat.send_message(
"Now for a five-year-old."
)
print(r2.text)
for turn in chat.get_history():
part = turn.parts[0].text[:40]
print(turn.role, "->", part)
Die Nachfrage wird im Kontext beantwortet, da das Chat-Objekt den vorherigen Austausch stillschweigend wiedergegeben hat – genau wie es eine manuell implementierte Funktion tun würde. Wenn man am Ende über get_history() läuft, sieht man abwechselnde Schritte von user und model, dieselbe Liste also, die bei der letzten Anfrage gesendet wurde. Auf Serverseite wird nichts gespeichert. Das Chat-Objekt speichert die Eingaben auf der Client-Seite, wodurch sich die Eingabetoken bei jedem Schritt weiter ansammeln und lange Chats mehr pro Aufruf kosten.
Eines hat sich nicht geändert: Der Dienst hinter dem SDK erinnert sich zwischen den Anfragen an nichts.
Bequemlichkeit hat ihren Preis, und das wird später bei Frameworks wichtig. Eine verwaltete Historie bedeutet weniger Code und weniger Fehler – zumindest bis zum Moment, in dem Sie alte Einträge entfernen, zusammenfassen oder abgerufene Dokumente in die Mitte eines Gesprächs einfügen müssen. Dann möchten Sie wieder die einfache Liste haben. LangChain befindet sich auf derselben Stufe dieser Skala, aber auf einem höheren Niveau. Seien Sie mit sowohl der manuell geführten Liste als auch dem verwalteten Objekt vertraut – keines von beiden kann Sie einschränken.
Das Beispiel ausführen
pip install -r requirements.txt
export GEMINI_API_KEY="AIza..."
python examples/part04_gemini.py
Die Skript behandelt nacheinander drei Aspekte: eine einzelne Anfrage, die manuelle Schleife zur Überprüfung der Äquivalenz sowie das verwaltete Chat-Interface mit angezeigter Historie. Die Token-Zahlen werden nach jeder Aufrufung protokolliert. Wenn keine Schlüssel eingestellt sind, stoppt das Skript umgehend mit einer klaren Meldung. Da die Aufrufe live erfolgen und berechnet werden, sollte es nicht in CI ausgeführt werden.
Drei Anbieter, ein Format
Eine kurze Vergleich aller drei. OpenAI betrachtet system als Nachricht und überlässt die Historie dem Benutzer. Claude macht system zu einem separaten Parameter, verlangt max_tokens und lässt ebenfalls die Historie dem Benutzer über. Gemini fügt system_instruction in die Konfiguration ein, benennt den Assistenten model und speichert die Historie, sofern dies erlaubt wird. Alle drei arbeiten mit derselben stateless Schleife: Die gesamte Konversation wird gesendet, eine Antwort empfangen, diese hinzugefügt und der Vorgang wiederholt.
Deshalb können Mehr-Anbieter-Frameworks schlank bleiben, und deshalb muss der Wechsel des Anbieters nicht beängstigend sein. Die Migration besteht lediglich aus einer Umbenennungsübersicht, nicht aus einem Neuschreiben.