Guida per gli sviluppatori a Gemini 3.6 Flash

Gemini 3.6 Flash è un modello potente, veloce ed economico della famiglia Gemini 3. Progettato per offrire funzionalità agentiche di livello quasi Pro senza compromettere prestazioni o valore, il modello è ora disponibile a livello generale (GA) per gli sviluppatori che utilizzano l' API Gemini e per le aziende che utilizzano la piattaforma agentica Gemini Enterprise.

Questo documento illustra le novità di 3.6 Flash, come si inserisce nella famiglia di modelli Gemini, come eseguire la migrazione a 3.6 Flash e fornisce una guida rapida per l'utilizzo di 3.6 Flash.

Come si inserisce nella famiglia Gemini?

Gemini 3.6 Flash è il modello agentico principale della famiglia Gemini 3. Colma il divario tra i modelli Pro con ragionamento approfondito e i modelli Flash-Lite con throughput elevato. Rispetto a Gemini 3.5 Flash, 3.6 Flash offre una qualità notevolmente superiore nell'orchestrazione di strumenti in più passaggi, nel refactoring del codice full-stack e nel ragionamento visivo, utilizzando al contempo meno token e turni di ragionamento. Offre funzionalità di livello quasi Pro a velocità e prezzi Flash.

Specifiche e confronti dei modelli

La seguente tabella è un confronto che copre alcune delle specifiche tra 3.6 Flash, 3.5 Flash e 3.1 Pro:

Gemini 3.6 Flash Gemini 3.5 Flash Gemini 3.1 Pro
ID modello gemini-3.6-flash gemini-3.5-flash gemini-3.1-pro-preview
Fase di lancio GA GA Anteprima
Tipi di input Testo, immagine, audio, video Testo, immagine, audio, video Testo, immagine, audio, video
Tipo/i di output Testo Testo Testo
Finestra contestuale 1.048.576 1.048.576 1.048.576
Lunghezza massima del token di output 65.536 65.536 65.536
Aree geografiche supportate Globale, multi-regione Globale, multi-regione, Americhe, Europa, Asia Pacifico Globale
Livelli di ragionamento supportati MINIMAL, LOW, MEDIUM, HIGH
(predefinito: MEDIUM)
MINIMAL, LOW, MEDIUM, HIGH
(predefinito: MEDIUM)
LOW, MEDIUM, HIGH
(predefinito: HIGH)
Scopo principale Agentic Workflows ad alta efficienza, orchestrazione in più passaggi e programmazione full-stack Attività bilanciate, chiamate agli strumenti e ragionamento intermedio Ragionamento approfondito, attività di elevata complessità

Per l'elenco completo delle funzionalità, degli strumenti e delle opzioni di consumo supportati, consulta la pagina del modello 3.6 Flash.

Novità di Gemini 3.6 Flash

3.6 Flash è ottimizzato per l'orchestrazione in più passaggi, il refactoring del codice full-stack e il ragionamento generale con un'efficienza dei token notevolmente migliore rispetto ai modelli precedenti.

Aggiornamenti delle funzionalità e delle prestazioni

Di seguito è riportato l'elenco delle modifiche apportate alle funzionalità e alle prestazioni di 3.6 Flash rispetto ai modelli precedenti:

  • Riduzione dei token e dei turni: consuma meno token e completa i flussi di lavoro in più passaggi in meno passaggi di ragionamento e turni di conversazione rispetto a 3.5 Flash.
  • Generazione di codice migliorata: produce codice più pulito con tassi di errori di compilazione e revisione inferiori negli ambienti di creazione di applicazioni, prototipazione, e agenti IDE.
  • Riduzione della distorsione dell'azione: risolve le attività di diagnostica di sola lettura senza apportare modifiche non richieste allo spazio di lavoro o modificare lo stato prematuramente.
  • Ragionamento multimodale e spaziale: offre prestazioni migliorate nell'interpretazione dei grafici , nella conversione di progetti visivi e nella generazione di layout web multi-elemento.
  • Supporto per l'utilizzo del computer: supportato come strumento integrato per l'automazione dell'interfaccia utente agentica.
  • Preferenza per lo stile dell'interfaccia utente: è più efficace nella creazione di codice funzionale, anche se i valutatori umani hanno notato una preferenza per i modelli precedenti per la presentazione frontend e il layout visivo. Questo problema può essere mitigato fornendo linee guida di progettazione esplicite.

Modifiche dei parametri comportamentali e delle API

Di seguito è riportato l'elenco delle modifiche apportate ai parametri comportamentali e delle API di 3.6 Flash rispetto ai modelli precedenti:

  • Concisione dei passaggi: utilizza meno passaggi di ragionamento rispetto a 3.5 Flash. Sebbene ciò riduca la latenza e il costo del refactoring del codice e dei flussi di lavoro degli strumenti, può causare uscite anticipate nei follow-up conversazionali estesi in più turni in cui sono necessarie catene di iterazione più lunghe.
  • Ispezione programmatica anticipata: preferisce eseguire script di codice di diagnostica (execute_code) per ispezionare i problemi prima di modificare lo stato più frequentemente rispetto a 3.5 Flash. Sebbene ciò migliori l'accuratezza della diagnostica nel refactoring backend complesso, a volte può comportare l'esecuzione di passaggi di ispezione esplorativa aggiuntivi in semplici attività di scripting e web frontend in cui la versione precedente generava il codice direttamente.
  • Impegno predefinito: mantiene il livello di impegno predefinito medio introdotto in 3.5 Flash.
  • Nessuna sostituzione del campionamento: i valori personalizzati per temperature, top-k, o top-p parametri non sono più supportati. L'impostazione di valori personalizzati verrà ignorata nella superficie dell'API. Utilizza invece thinking_level o schemi JSON strutturati per controllare il determinismo dell'output.
  • Restrizioni relative alle penalità di frequenza e presenza: i valori personalizzati per questi parametri non sono più supportati. L'impostazione di questi parametri genererà un errore API attivo.
  • Le richieste API in cui l'ultimo turno di input ha il ruolo "Modello" non sono supportate.
  • I turni vuoti nella cronologia delle conversazioni vengono eliminati.
  • Le firme di pensiero non valide ora generano errori.
  • Chiamata di funzione rigorosa: FunctionResponse deve corrispondere rigorosamente a id, name e al conteggio di esecuzione della FunctionCall precedente. Aggiungi le istruzioni in linea direttamente all'interno del testo della risposta della funzione, separate da due nuove righe (\n\n).

Guida rapida

Prima di iniziare, devi eseguire l'autenticazione ad Agent Platform utilizzando le credenziali predefinite dell'applicazione (ADC) o una chiave API. Per ulteriori informazioni, consulta la pagina Inizia a utilizzare la piattaforma agentica Gemini Enterprise.

Nei seguenti blocchi di codice, sostituisci PROJECT_ID con il tuo ID progetto.

Installazione

Assicurati di utilizzare l'SDK google-genai più recente:

pip install --upgrade google-genai

Richiesta di base

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?" },
  },
}'

Eseguire la migrazione a 3.6 Flash da 3.5 Flash o 3.1 Pro

Per eseguire la migrazione a 3.6 Flash da 3.5 Flash o 3.1 Pro, segui questi passaggi:

  1. Aggiorna l'ID modello: modifica la stringa del modello nelle chiamate API in gemini-3.6-flash.
  2. Adatta il codice alle nuove regole API della famiglia Gemini 3: Gemini 3.6 Flash applica rigorosamente le regole dei parametri e le convenzioni API stabilite nella famiglia Gemini 3:
    • Rimuovi temperatura, Top-K e Top-P: rimuovi questi parametri personalizzati dal payload. Sebbene non generino un errore, il modello li ignorerà completamente. Utilizza invece il parametro thinking_level o gli output strutturati json_schema per controllare il determinismo dell'output.
    • Rimuovi le penalità di frequenza e presenza: rimuovi eventuali configurazioni personalizzate per le penalità di frequenza o presenza per evitare che le chiamate API generino errori di runtime.
    • Assicurati che l'integrazione della chat non tenti di precompilare il modello: esamina gli array della cronologia dei messaggi per assicurarti che il payload dell'API non termini con un turno utente o un turno modello vuoto. Se l'ultimo oggetto nell'array della cronologia è un ruolo "model" (API GenerateContent) o un tipo "model_output" (API Interactions), ristruttura la sequenza per evitare di attivare un errore di convalida rigorosa.
    • Utilizza thinking_level: rimuovi le istanze del parametro thinking_budget ritirato e utilizza invece thinking_level.
    • Applica le convenzioni di chiamata di funzione rigorose: FunctionResponse deve corrispondere rigorosamente a id, name e al conteggio di esecuzione della precedente FunctionCall. Se devi aggiungere istruzioni in linea, inseriscile direttamente all'interno del testo della risposta della funzione, separate da due nuove righe (\n\n).
  3. Tieni conto delle modifiche del flusso di lavoro:
    • Se la tua applicazione si basa su loop conversazionali in più turni, testa i flussi di lavoro per assicurarti che la nuova concisione dei passaggi del modello non attivi uscite premature.
    • Se crei agenti di scripting di base o frontend, monitora le chiamate execute_code esplorative non necessarie a causa della nuova distorsione del modello verso l'ispezione programmatica anticipata.

Soluzioni alternative per i requisiti di testo pre-strumento

Se il prompt richiede al modello di generare testo strutturato (XLM, YAML, JSON, e così via) (ad esempio, <UPDATE>...</UPDATE>) immediatamente prima di effettuare una chiamata allo strumento, la chiamata allo strumento potrebbe occasionalmente non riuscire con un errore Malformed_Function_Call. Per risolvere il problema, puoi utilizzare una delle seguenti soluzioni:

  • (Consigliato) Chiedi al modello di inserire le note pre-strumento all'interno di una chiamata di funzione update() dedicata anziché nel testo non elaborato. Per istruzioni dettagliate sull'implementazione, consulta la sezione successiva.
  • Chiedi al modello di scrivere le note come intestazioni Markdown (ad esempio, # UPDATE, ## PLAN) anziché come testo strutturato.
  • Non richiedere al modello di generare testo prima delle chiamate agli strumenti.

Soluzione consigliata: racchiudi le note di lavoro in una chiamata di funzione dedicata

Invece dell'istruzione originale:

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>`.

Utilizza questa istruzione aggiornata:

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

Aggiorna tutti i riferimenti al vecchio formato XML <UPDATE> nella richiesta del cliente. Poi aggiungi la dichiarazione di funzione corrispondente per la funzione di aggiornamento:

{
  "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"
    ]
  }
}

Il modello effettuerà due chiamate nello stesso passaggio: la chiamata update() che sostituisce l'XML strutturato e la chiamata di funzione effettiva che vuole effettuare.

Risorse aggiuntive