Google verwendet KI-Technologie, um Inhalte in Ihre bevorzugte Sprache zu übersetzen. KI-Übersetzungen können Fehler enthalten.

Entwicklerleitfaden für Gemini 3.6 Flash

Gemini 3.6 Flash ist ein schnelles, kostengünstiges und leistungsstarkes Modell der Gemini 3-Familie. Das Modell wurde entwickelt, um agentische Funktionen auf Pro-Niveau zu bieten, ohne Kompromisse bei Leistung oder Preis-Leistungs-Verhältnis einzugehen. Es ist jetzt allgemein verfügbar (GA) für Entwickler, die die Gemini API verwenden, und für Unternehmen, die die Gemini Enterprise Agent Platform nutzen.

In diesem Dokument erfahren Sie, was neu an 3.6 Flash ist, wie es in die Gemini-Modellfamilie passt, wie Sie zu 3.6 Flash migrieren und wie Sie 3.6 Flash schnell verwenden können.

Wie passt es in die Gemini-Familie?

Gemini 3.6 Flash ist das primäre agentische Arbeitstier in der Gemini 3-Familie. Es schließt die Lücke zwischen den Pro-Modellen mit Deep Reasoning und den Flash-Lite-Modellen mit hohem Durchsatz. Im Vergleich zu Gemini 3.5 Flash bietet 3.6 Flash eine deutlich höhere Qualität bei der mehrstufigen Tool-Orchestrierung, dem Full-Stack-Code-Refactoring und dem visuellen Schlussfolgern, während weniger Tokens und Schlussfolgerungsschritte verwendet werden. Es bietet nahezu die Leistung des Pro-Modells mit der Geschwindigkeit und den Kosten von Flash.

Modellspezifikationen und -vergleiche

In der folgenden Tabelle werden einige der Spezifikationen von 3.6 Flash, 3.5 Flash und 3.1 Pro verglichen:

	Gemini 3.6 Flash	Gemini 3.5 Flash	Gemini 3.1 Pro
Modell-ID	`gemini-3.6-flash`	`gemini-3.5-flash`	`gemini-3.1-pro-preview`
Startphase	AV	GA	Vorschau
Eingabetypen	Text, Bild, Audio, Video	Text, Bild, Audio, Video	Text, Bild, Audio, Video
Ausgabetyp(en)	Text	Text	Text
Verlaufszeitraum	1.048.576	1.048.576	1.048.576
Maximale Länge des Ausgabetokens	65.536	65.536	65.536
Unterstützte Regionen	Global, Multiregional	Global, Multiregional, Amerika, Europa, Asien-Pazifik	Global
Unterstützte Denkaufwände	`MINIMAL`, `LOW`, `MEDIUM`, `HIGH` (Standard: `MEDIUM`)	`MINIMAL`, `LOW`, `MEDIUM`, `HIGH` (Standard: `MEDIUM`)	`LOW`, `MEDIUM`, `HIGH` (Standard: `HIGH`)
Schwerpunkt	Hocheffiziente agentische Workflows, mehrstufige Orchestrierung und Full-Stack-Programmierung	Ausgewogene Aufgaben, Toolaufrufe und Zwischenschritte beim Reasoning	Aufgaben mit komplexen logischen Schlussfolgerungen und hoher Komplexität

Eine vollständige Liste der unterstützten Funktionen, Tools und Nutzungsoptionen finden Sie auf der Seite zum 3.6 Flash-Modell.

Was ist neu bei Gemini 3.6 Flash?

3.6 Flash ist für mehrstufige Orchestrierung, Full-Stack-Code-Refaktorierung und allgemeines Reasoning optimiert und bietet eine deutlich bessere Token-Effizienz als seine Vorgänger.

Funktionen und Leistungsupdates

Im Folgenden finden Sie eine Liste der Änderungen bei Funktionen und Leistung für 3.6 Flash im Vergleich zu den Vorgängermodellen:

Reduzierung von Tokens und Turns: Verbraucht weniger Tokens und schließt mehrstufige Workflows in weniger logischen Schritten und Gesprächsrunden ab als 3.5 Flash.
Verbesserte Codegenerierung: Erzeugt saubereren Code mit geringeren Kompilierungsfehler- und Überarbeitungsraten in Umgebungen für die Anwendungsentwicklung, das Prototyping und IDE-Agenten.
Reduzierte Aktionsverzerrung: Löst Diagnoseaufgaben mit Lesezugriff, ohne unerwünschte Änderungen am Arbeitsbereich vorzunehmen oder den Status vorzeitig zu ändern.
Multimodales und räumliches Schlussfolgern: Bietet eine verbesserte Leistung bei der Interpretation von Diagrammen, der visuellen Konvertierung von Entwürfen und der Generierung von Weblayouts mit mehreren Elementen.
Unterstützung für die Computernutzung: Wird als integriertes Tool für die agentische UI-Automatisierung unterstützt.
UI-Stilpräferenz: Besser beim Erstellen von funktionalem Code, obwohl menschliche Bewerter eine Präferenz für frühere Modelle für die Frontend-Präsentation und das visuelle Layout angaben. Dem kann durch die Bereitstellung expliziter Designrichtlinien entgegengewirkt werden.

Änderungen am Verhalten und an API-Parametern

Im Folgenden finden Sie eine Liste der Änderungen am Verhalten und an den API-Parametern für 3.6 Flash im Vergleich zu den Vorgängermodellen:

Prägnanz der Schritte: Verwendet weniger Schritte als 3.5 Flash. Dies reduziert zwar die Latenz und die Kosten für Code-Refaktorierung und Tool-Workflows, kann aber bei erweiterten Multi-Turn-Konversations-Follow-ups, bei denen längere Iterationsketten erforderlich sind, zu vorzeitigen Abbrüchen führen.
Vorabprüfung per Programm: Bevorzugt das Ausführen von Diagnosecodeskripts (execute_code), um Probleme zu prüfen, bevor der Status geändert wird, häufiger als 3.5 Flash. Dies verbessert zwar die Diagnosegenauigkeit bei komplexem Backend-Refactoring, kann aber gelegentlich dazu führen, dass bei einfachen Frontend-Web- und Scripting-Aufgaben zusätzliche explorative Prüfschritte ausgeführt werden, bei denen die vorherige Version Code direkt generiert hätte.
Standardaufwand: Übernimmt den mittleren Standardaufwand, der in 3.5 Flash eingeführt wurde.
Keine Sampling-Überschreibungen: Benutzerdefinierte Werte für die Parameter temperature, top-k oder top-p werden nicht mehr unterstützt. Benutzerdefinierte Werte werden in der API-Oberfläche ignoriert. Verwenden Sie stattdessen thinking_level oder strukturierte JSON-Schemas, um den Determinismus der Ausgabe zu steuern.
Einschränkungen für Häufigkeits- und Präsenzstrafen: Benutzerdefinierte Werte für diese Parameter werden nicht mehr unterstützt. Wenn Sie sie festlegen, wird jetzt ein aktiver API-Fehler ausgegeben.
API-Anfragen, bei denen die letzte Eingaberunde die Rolle „Model“ hat, werden nicht unterstützt.
Leere Turns im Unterhaltungsverlauf werden gelöscht.
Ungültige Gedankensignaturen führen jetzt zu Fehlern.
Strikte Funktionsaufrufe: FunctionResponse muss genau mit id, name und der Ausführungsanzahl des vorherigen FunctionCall übereinstimmen. Hängen Sie Inline-Anweisungen direkt im Antworttext der Funktion an, getrennt durch zwei Zeilenumbrüche (\n\n).

Kurzanleitung

Bevor Sie beginnen, müssen Sie sich bei der Agent Platform mit Standardanmeldedaten für Anwendungen (Application Default Credentials, ADC) oder einem API-Schlüssel authentifizieren. Weitere Informationen finden Sie unter Erste Schritte mit der Gemini Enterprise Agent Platform.

Ersetzen Sie in den folgenden Codeblöcken PROJECT_ID durch Ihre Projekt-ID.

Installation

Achten Sie darauf, dass Sie das neueste google-genai SDK verwenden:

pip install --upgrade google-genai

Einfache Anfrage

Python

from google import genai

client = genai.Client(enterprise=True, project="PROJECT_ID", location="global")

response = client.models.generate_content(
  model="gemini-3.6-flash",
  contents="How does AI work?",
)
print(response.text)

REST

curl -X POST \
-H "Authorization: Bearer $(gcloud auth print-access-token)" \
-H "Content-Type: application/json" \
https://aiplatform.googleapis.com/v1/projects/PROJECT_ID/locations/global/publishers/google/models/gemini-3.6-flash:generateContent \
-d '{
  "contents": {
    "role": "USER",
    "parts": { "text": "Why is the sky blue?" },
  },
}'

Von 3.5 Flash oder 3.1 Pro zu 3.6 Flash migrieren

So migrieren Sie von 3.5 Flash oder 3.1 Pro zu 3.6 Flash:

Modell-ID aktualisieren: Ändern Sie den Modellstring in Ihren API-Aufrufen in gemini-3.6-flash.
Code an die neuen API-Regeln der Gemini 3-Familie anpassen: Gemini 3.6 Flash setzt die Parameterregeln und API-Konventionen der Gemini 3-Familie strikt durch:
- Temperatur, Top‑K und Top‑P entfernen: Entfernen Sie diese benutzerdefinierten Parameter aus Ihrer Nutzlast. Es wird zwar kein Fehler ausgegeben, aber das Modell ignoriert sie vollständig. Verwenden Sie stattdessen den Parameter thinking_level oder strukturierte Ausgaben vom Typ json_schema, um den Determinismus der Ausgabe zu steuern.
- Strafen für Häufigkeit und Vorhandensein entfernen: Entfernen Sie alle benutzerdefinierten Konfigurationen für Strafen für Häufigkeit oder Vorhandensein, um zu verhindern, dass Ihre API-Aufrufe Laufzeitfehler auslösen.
- Achten Sie darauf, dass Ihre Chatintegration nicht versucht, das Modell vorab auszufüllen: Prüfen Sie Ihre Nachrichtenverlaufsarrays, um sicherzustellen, dass Ihre API-Nutzlast nicht mit einem leeren Nutzer- oder Modellturn endet. Wenn das letzte Objekt in Ihrem Verlaufsarray eine „model“-Rolle (GenerateContent API) oder ein „model_output“-Typ (Interactions API) ist, strukturieren Sie die Sequenz um, um einen strengen Validierungsfehler zu vermeiden.
- thinking_level verwenden: Entfernen Sie Instanzen des verworfenen Parameters thinking_budget und verwenden Sie stattdessen thinking_level.
- Strikte Konventionen für Funktionsaufrufe erzwingen: Die FunctionResponse müssen genau mit den id, name und der Ausführungsanzahl der vorherigen FunctionCall übereinstimmen. Wenn Sie Inline-Anweisungen anhängen müssen, platzieren Sie sie direkt im Antworttext der Funktion, getrennt durch zwei Zeilenumbrüche (\n\n).
Workflow-Änderungen berücksichtigen:
- Wenn Ihre Anwendung auf Multi-Turn-Konversationsschleifen basiert, testen Sie Ihre Workflows, um sicherzustellen, dass die neue Schrittprägnanz des Modells nicht zu vorzeitigen Abbrüchen führt.
- Wenn Sie Frontend- oder einfache Scripting-Agenten erstellen, sollten Sie auf unnötige explorative execute_code-Aufrufe achten, die durch die neue Tendenz des Modells zur vorab durchgeführten programmatischen Prüfung entstehen.

Problemumgehungen für Textanforderungen vor dem Tool

Wenn Ihr Prompt erfordert, dass das Modell strukturierten Text (XLM, YAML, Json usw.) (z. B. <UPDATE>...</UPDATE>) unmittelbar vor einem Toolaufruf ausgibt, kann der Toolaufruf gelegentlich mit dem Fehler Malformed_Function_Call fehlschlagen. Sie können eine der folgenden Behelfslösungen verwenden, um dieses Problem zu beheben:

(Empfohlen) Weisen Sie das Modell an, seine Notizen vor dem Toolaufruf in einem dedizierten update()-Funktionsaufruf statt in unformatiertem Text zu speichern. Eine detaillierte Implementierungsanleitung finden Sie im nächsten Abschnitt.
Weisen Sie das Modell an, Notizen als Markdown-Überschriften (z. B. # UPDATE, ## PLAN) anstelle von strukturiertem Text zu schreiben.
Das Modell muss vor Toolaufrufen keinen Text ausgeben.

Empfohlene Lösung: Arbeitsnotizen in einen dedizierten Funktionsaufruf einbinden

Anstelle der ursprünglichen Anleitung:

Before calling a tool, in every response you MUST first output a single
`<UPDATE>` part as specified, don't skip this part or any of required sub-tags
within `<UPDATE>`.

Verwenden Sie diese aktualisierte Anleitung:

Before calling any other tool, in every response you MUST first call `update`
with all required parameters (previous_step, plan, next_step, external).

Aktualisieren Sie alle Verweise auf das alte <UPDATE>-XML-Format in der Kundenanfrage. Fügen Sie dann die entsprechende Funktionsdeklaration für die Aktualisierungsfunktion hinzu:

{
  "name": "update",
  "description": "Update working notes (previous step analysis, plan, next step, external note).",
  "parameters": {
    "type": "OBJECT",
    "properties": {
      "previous_step": {
        "type": "STRING",
        "description": "Key findings and outcomes since the previous step."
      },
      "plan": {
        "type": "STRING",
        "description": "The current status of the plan."
      },
      "next_step": {
        "type": "STRING",
        "description": "Brief explanation of the immediate next action according to the plan."
      },
      "external": {
        "type": "STRING",
        "description": "A short, plain-language note shown to the User about what you are ABOUT TO DO next."
      }
    },
    "required": [
      "previous_step",
      "plan",
      "next_step",
      "external"
    ]
  }
}

Das Modell führt im selben Schritt zwei Aufrufe aus: den update()-Aufruf, der das strukturierte XML ersetzt, und den eigentlichen Funktionsaufruf, den es ausführen möchte.

Entwicklerleitfaden für Gemini 3.6 Flash Mit Sammlungen den Überblick behalten Sie können Inhalte basierend auf Ihren Einstellungen speichern und kategorisieren.