מדריך למפתחים בנושא Gemini 3.6 Flash

‫Gemini 3.6 Flash הוא מודל מהיר, חסכוני ומתקדם ממשפחת Gemini 3. המודל הזה נועד לספק יכולות אג'נטיות שקרובות לאלה של Pro, בלי להתפשר על הביצועים או על הערך. עכשיו הוא זמין לכלל המשתמשים (GA) – למפתחים שמשתמשים ב-Gemini API ולארגונים שמשתמשים ב-Gemini Enterprise Agent Platform.

במסמך הזה נסביר מה חדש ב-‎3.6 Flash, איך הוא משתלב במשפחת מודלי Gemini ואיך עוברים ל-‎3.6 Flash, וניתן מדריך למתחילים לשימוש ב-‎3.6 Flash.

איך הוא משתלב במשפחת Gemini?

‫Gemini 3.6 Flash הוא המודל העיקרי במשפחת Gemini 3 שמבוסס על סוכנים. הוא מגשר על הפער בין מודלים של Pro עם יכולות נימוק מעמיקות לבין מודלים של Flash-Lite עם תפוקה גבוהה. בהשוואה ל-Gemini 3.5 Flash, ‏Gemini 3.6 Flash מספק איכות גבוהה משמעותית בתזמור כלים בכמה שלבים, בשכתוב קוד פול סטאק ובחשיבה חזותית, תוך שימוש בפחות טוקנים וסבבי חשיבה. הוא מציע יכולות שקרובות לרמת Pro, במהירות ובמחיר של Flash.

מפרטים והשוואות של מודלים

בטבלה הבאה מוצגת השוואה של חלק מהמפרטים בין 3.6 Flash,‏ 3.5 Flash ו-3.1 Pro:

‫Gemini 3.6 Flash Gemini 3.5 Flash Gemini 3.1 Pro
מזהה המודל gemini-3.6-flash gemini-3.5-flash gemini-3.1-pro-preview
שלב ההשקה GA GA תצוגה מקדימה
סוגי קלט טקסט, תמונה, אודיו, וידאו טקסט, תמונה, אודיו, וידאו טקסט, תמונה, אודיו, וידאו
סוגי הפלט טקסט טקסט טקסט
חלון ההקשר 1,048,576 1,048,576 1,048,576
האורך המקסימלי של טוקן הפלט 65,536 65,536 65,536
אזורים נתמכים גלובלי, מספר אזורים גלובלי, מספר אזורים, אמריקה, אירופה, אסיה והאוקיינוס השקט עולמי
רמות ההעמקה הנתמכות ‫MINIMAL, LOW, MEDIUM, HIGH
(ברירת מחדל: MEDIUM)
‫MINIMAL, LOW, MEDIUM, HIGH
(ברירת מחדל: MEDIUM)
LOW, MEDIUM, HIGH
(ברירת המחדל: HIGH)
מיקוד ראשי תהליכי עבודה אג'נטיים יעילים, תזמור מרובה שלבים ותכנות פול סטאק משימות מאוזנות, קריאה לכלי וחשיבה בינונית חשיבה מעמיקה, משימות מורכבות מאוד

בדף של מודל ‎3.6 Flash מפורטת הרשימה המלאה של היכולות, הכלים ואפשרויות השימוש הנתמכים.

מה חדש ב-Gemini 3.6 Flash?

‫‎3.6 Flash עבר אופטימיזציה לתזמור בכמה שלבים, ארגון הקוד מחדש של פול סטאק והסקת מסקנות כללית, עם יעילות טוקנים משופרת משמעותית בהשוואה לגרסאות הקודמות.

עדכונים לגבי יכולות וביצועים

בהמשך מופיעה רשימת השינויים ביכולות ובביצועים של גרסה 3.6 Flash לעומת דגמים קודמים:

  • הפחתה במספר הטוקנים והתורות: צורך פחות טוקנים ומשלים תהליכי עבודה בכמה שלבים בפחות שלבי חשיבה ותורות בשיחה בהשוואה ל-‎3.5 Flash.
  • יצירת קוד משופרת: יצירת קוד נקי יותר עם שיעורים נמוכים יותר של כשלים בהידור ושינויים בסביבות של פיתוח אפליקציות, אב טיפוס וסוכני IDE.
  • הטיה מופחתת לפעולה: פותר משימות אבחון לקריאה בלבד בלי לבצע עריכות לא רצויות בסביבת העבודה או לשנות את המצב לפני הזמן.
  • חשיבה מרחבית ומולטי-מודאלית: ביצועים משופרים בפירוש תרשימים, בהמרת שרטוטים חזותיים וביצירת פריסות של אתרים עם כמה רכיבים.
  • תמיכה בשימוש במחשב: נתמכת ככלי מובנה לאוטומציה של ממשק משתמש מבוסס-סוכן.
  • העדפות לגבי סגנון ממשק המשתמש: המודל טוב יותר ביצירת קוד פונקציונלי, אבל בודקים אנושיים ציינו שהם מעדיפים את המודלים הקודמים להצגה של חזית האתר ולפריסה חזותית. כדי לצמצם את הבעיה הזו, אפשר לספק הנחיות עיצוב מפורשות.

שינויים בהתנהגות ובפרמטרים של ה-API

בהמשך מופיעה רשימה של שינויים בהתנהגות ובפרמטרים של API בגרסה 3.6 Flash לעומת דגמים קודמים:

  • תמציתיות השלבים: משתמש בפחות שלבי נימוק בהשוואה ל-3.5 Flash. ההגדרה הזו מפחיתה את זמן האחזור ואת העלות של תהליכי עבודה של כלים ושל ארגון הקוד מחדש, אבל היא יכולה לגרום ליציאות מוקדמות במעקבים מורחבים של שיחות רב-שלביות, שבהן נדרשות שרשראות ארוכות יותר של איטרציות.
  • בדיקה פרוגרמטית מראש: מעדיף להריץ סקריפטים של קוד אבחון (execute_code) כדי לבדוק בעיות לפני שינוי המצב בתדירות גבוהה יותר מאשר ב-‎3.5 Flash. השינוי הזה משפר את הדיוק של האבחון בפעולות מורכבות של ארגון הקוד מחדש בקצה העורפי, אבל לפעמים הוא עלול לגרום להרצת שלבים נוספים של בדיקה ראשונית במשימות פשוטות של קוד אינטרנט וכתיבת סקריפטים בקצה הקדמי, שבהן הגרסה הקודמת הייתה יוצרת קוד ישירות.
  • מאמץ ברירת מחדל: ממשיך את רמת המאמץ הבינונית שמוגדרת כברירת מחדל ב-3.5 Flash.
  • אין שינוי של ברירת המחדל לדגימה: ערכים מותאמים אישית לפרמטרים temperature,‏ top-k או top-p לא נתמכים יותר. הגדרת ערכים מותאמים אישית תתעלם מהם בממשק ה-API. במקום זאת, אפשר להשתמש ב-thinking_level או בסכימות JSON מובנות כדי לשלוט בדטרמיניזם של הפלט.
  • הגבלות על תדירות ועונש על נוכחות: אין יותר תמיכה בערכים מותאמים אישית לפרמטרים האלה. אם תגדירו אותם, תופיע שגיאת API פעילה.
  • אין תמיכה בבקשות API שבהן התפקיד של תור הקלט האחרון הוא "מודל".
  • תורות ריקים בהיסטוריית השיחות נמחקים.
  • מעכשיו, חתימות מחשבה לא תקינות יגרמו לשגיאות.
  • בקשה מחמירה להפעלת פונקציה: FunctionResponse חייב להתאים באופן מחמיר ל-id, ל-name ולמספר ההפעלות של FunctionCall הקודם. מוסיפים את ההוראות ישירות בתוך טקסט התגובה של הפונקציה, ומוודאים שהן מופרדות באמצעות שתי שורות חדשות (\n\n).

מדריך למתחילים

לפני שמתחילים, צריך לבצע אימות ב-Agent Platform באמצעות Application Default Credentials ‏ (ADC) או מפתח API. מידע נוסף זמין במאמר תחילת העבודה עם Gemini Enterprise Agent Platform.

בבלוקי הקוד הבאים, מחליפים את PROJECT_ID במזהה הפרויקט.

התקנה

חשוב לוודא שאתם משתמשים בגרסה העדכנית ביותר של ה-SDK של google-genai:

pip install --upgrade google-genai

בקשה בסיסית

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

מעבר ל-‎3.6 Flash מ-‎3.5 Flash או מ-‎3.1 Pro

כדי לעבור ל-3.6 Flash מ-3.5 Flash או מ-3.1 Pro, פועלים לפי השלבים הבאים:

  1. עדכון מזהה המודל: משנים את מחרוזת המודל בקריאות ל-API ל-gemini-3.6-flash.
  2. התאמת הקוד לכללי ה-API החדשים של משפחת Gemini 3: ‫Gemini 3.6 Flash אוכף באופן מחמיר את כללי הפרמטרים ואת מוסכמות ה-API שנקבעו בכל משפחת Gemini 3:
    • הסרת הטמפרטורה, Top-K ו-Top-P: מסירים את הפרמטרים המותאמים אישית האלה מהמטען הייעודי (payload). המודל לא יציג שגיאה, אבל הוא יתעלם מהם לגמרי. במקום זאת, השתמשו בפרמטר thinking_level או בפלט מובנה של json_schema כדי לשלוט בדטרמיניזם של הפלט.
    • הסרת עונשים על תדירות ונוכחות: צריך להסיר את כל ההגדרות המותאמות אישית של עונשים על תדירות ונוכחות כדי למנוע שגיאות בזמן ריצה בקריאות ל-API.
    • ודאו שהשילוב של הצ'אט לא מנסה למלא מראש את המודל: בדקו את המערכים של היסטוריית ההודעות כדי לוודא שהמטען הייעודי (payload) של ה-API לא מסתיים בתור ריק של המשתמש או של המודל. אם האובייקט האחרון במערך ההיסטוריה הוא תפקיד "model" (‏GenerateContent API) או סוג "model_output" (‏Interactions API), צריך לשנות את מבנה הרצף כדי למנוע שגיאת אימות מחמירה.
    • שימוש ב-thinking_level: צריך להסיר מופעים של הפרמטר thinking_budget שהוצא משימוש ולהשתמש ב-thinking_level במקומו.
    • החלת כללים מחמירים להפעלת פונקציות: FunctionResponse חייב להתאים בדיוק ל-id, ל-name ולמספר הביצועים של FunctionCall הקודם. אם אתם צריכים להוסיף הוראות בתוך השורה, הציבו אותן ישירות בתוך טקסט התגובה של הפונקציה, והפרידו ביניהן באמצעות שני מעברי שורה (\n\n).
  3. התאמה לשינויים בתהליכי העבודה:
    • אם האפליקציה שלכם מסתמכת על לולאות שיחה מרובות, כדאי לבדוק את תהליכי העבודה כדי לוודא שהתמציתיות של השלב החדש במודל לא גורמת ליציאות מוקדמות.
    • אם אתם בונים סוכנים של frontend או סוכנים בסיסיים של סקריפטים, כדאי לעקוב אחרי קריאות מיותרות של execute_code לצורך בדיקה, בגלל ההטיה החדשה של המודל כלפי בדיקה תוכניתית מראש.

פתרונות עקיפים לדרישות הטקסט שלפני הכלי

אם ההנחיה דורשת מהמודל להפיק טקסט מובנה (XLM,‏ YAML,‏ Json וכו') (לדוגמה, <UPDATE>...</UPDATE>) מיד לפני קריאה לפונקציה, יכול להיות שהקריאה לפונקציה תיכשל מדי פעם עם השגיאה Malformed_Function_Call. כדי לפתור את הבעיה, אפשר להשתמש באחד מהפתרונות החלופיים הבאים:

  • (מומלץ) מנחים את המודל להוסיף את ההערות שלו לפני השימוש בכלי בתוך update()בקשה להפעלת פונקציה ייעודית במקום בטקסט גולמי. בקטע הבא מפורטות הוראות להטמעה.
  • מנחים את המודל לכתוב הערות ככותרות Markdown (לדוגמה, # UPDATE, ## PLAN) במקום טקסט מובנה.
  • אל תדרשו מהמודל להפיק טקסט לפני קריאות לפונקציות.

הפתרון המומלץ: להוסיף את ההערות לפונקציה ייעודית

במקום ההוראה המקורית:

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

משתמשים בהוראה המעודכנת הזו:

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

לעדכן את כל ההפניות לפורמט ה-XML הישן של <UPDATE> בבקשת הלקוח. לאחר מכן, מוסיפים את הצהרת הפונקציה המתאימה לפונקציית העדכון:

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

המודל יבצע שתי קריאות באותו השלב: הקריאה update() שמחליפה את ה-XML המובנה, וקריאת הפונקציה בפועל שהוא רוצה לבצע.

מקורות מידע נוספים