Après la disponibilité générale du 13 octobre 2026, comment valider les arguments de fonction de Gemini 4 Argon à part du JSON final ?

Demander à Argon de chercher un match puis de rendre le vainqueur, le score et les buteurs peut produire d'abord un appel de recherche, puis un JSON. La chaîne de lieu de l'outil et l'objet de score final ne sont pas le même Schema. Le mauvais Schema appelle l'outil avec de mauvais champs, ou range un appel inachevé comme résultat du match.

Ce que dit la fiche après la disponibilité générale

• Identifiant : gemini-4-argon. Note du 13/10/2026, disponibilité générale. Latest update de la fiche : October 2026.
• Fenêtre : contexte 1 048 576. Sortie synchrone par défaut au plus 65 536. Avec long decode, jusqu'à 1 048 576.
• JSON : Function calling et Structured outputs Supported. Type de sortie Text. Cache implicite seulement. Cache explicite non pris en charge.
• Ne pas réutiliser l'ancien canal : Live API, génération d'image et d'audio non prises en charge. La note sur Gemini 3.8 Live ne s'applique pas à cet identifiant.

Une interaction, deux JSON

La page de sortie structurée, mise à jour le 13/10/2026 UTC, place l'objet final dans response_format. L'exemple REST Argon poste vers v1beta/interactions : type text, mime_type application/json, schéma avec winner, final_match_score, scorers. Le SDK lit interaction.output_text. Le guide de migration dit qu'il ne joint que les blocs de texte consécutifs à la fin. Le texte plus tôt, séparé par des pensées, des images, de l'audio ou des appels d'outils, est absent. Le milieu se lit dans steps.

L'exemple pas à pas d'appel de fonction met le modèle à gemini-3.8-flash et poste vers v1beta2/interactions. Au 20/10/2026, les deux pages ne mettent pas le même modèle sur le même chemin. Les champs ci-dessous suivent l'exemple Interactions. Ce n'est pas une forme réservée à Argon.

arguments ne vérifie que l'entrée de l'outil

{
  "type": "function_call",
  "status": "waiting",
  "id": "fc_1",
  "name": "get_weather",
  "arguments": { "location": "Boston, MA" }
}

Quand il faut exécuter un outil, le statut est requires_action. arguments se compare aux parameters de l'outil, pas à response_format.schema. On rend le résultat avec le même id : function_result.call_id vaut fc_1, avec name. En flux, partial_arguments est un fragment de chaîne. Un milieu peut être du JSON invalide. On valide l'objet seulement quand l'étape est complète. La page des modes (15/10/2026 UTC) décrit VALIDATED comme mode par défaut quand des outils intégrés ou une sortie structurée sont aussi activés, et comme garantie du schéma de fonction. Elle ne nomme pas gemini-4-argon. Même si l'API affirme que les arguments collent au schéma, le JSON final reste un contrôle séparé.

Le JSON final attend completed

Après le résultat d'outil, l'interaction suivante de l'exemple a le statut completed. Le texte est dans model_output.content, type text. Le SDK le rassemble en output_text. En sortie structurée, cette chaîne est celle qu'on passe à JSON.parse puis au schema. Pendant requires_action, ce texte n'existe pas. Lire le statut d'abord, puis choisir l'objet.

• Structured Outputs : le format de la réponse finale.
• Function Calling : une tâche au milieu de la conversation. Un tour d'outil peut précéder la réponse finale.

Le sous-ensemble, et où la doc se contredit

Types : string, number, integer, boolean, object, array. Null : {"type":["string","null"]}. Objet : properties, required, additionalProperties (booléen ou schéma). Chaîne : enum, format (date-time, date, time). Nombre : minimum, maximum, enum. Tableau : items, prefixItems, minItems, maxItems. Le schéma officiel du match n'écrit pas additionalProperties. Omis, les champs en plus sont permis par défaut JSON Schema. Pour les refuser, ajouter false au contrat local, plus strict que la requête. La même page dit : JSON syntaxiquement valide, valeurs à vérifier dans l'application. Un schéma très grand ou très profond peut être refusé.

• Fiche modèle : les deux sont Supported.
• Sortie structurée : la phrase d'aperçu dit seulement Gemini 3. Les exemples de la section mettent model à gemini-4-argon.
• Page des appels (15/10/2026) : combinaison seulement Gemini 3. Argon n'est pas nommé.
• Page des outils (14/10/2026) : Gemini 4 et Gemini 3 peuvent combiner outils intégrés et outils personnalisés.

Tant que les phrases ne coïncident pas, traiter la combinaison comme un aperçu et valider les deux JSON localement. thought_signature est obligatoire pour un historique Gemini 3 modifié à la main. La fiche Argon ne le dit pas. Ne pas copier la règle de Gemini 3 sur gemini-4-argon.

Vérifier dans la boîte à outils

Les deux schémas sont locaux. Ce n'est pas un response_format à envoyer. La page du sous-ensemble ne liste pas const. Ne pas coller le premier schéma tel quel dans la requête.

{
  "call_schema": {"type":"object","properties":{"type":{"const":"function_call"},"id":{"type":"string","minLength":1},"name":{"const":"get_weather"},"arguments":{"type":"object","properties":{"location":{"type":"string"}},"required":["location"],"additionalProperties":false}},"required":["type","id","name","arguments"],"additionalProperties":true},
  "final_schema": {"type":"object","properties":{"winner":{"type":"string"},"final_match_score":{"type":"string"},"scorers":{"type":"array","items":{"type":"string"}}},"required":["winner","final_match_score","scorers"],"additionalProperties":false},
  "ok_call": {"type":"function_call","status":"waiting","id":"fc_1","name":"get_weather","arguments":{"location":"Boston, MA"}},
  "ok_final": {"winner":"Example FC","final_match_score":"2-1","scorers":["A. Example"]},
  "extra_field": {"winner":"Example FC","final_match_score":"2-1","scorers":["A. Example"],"note":"not in the contract"},
  "partial": {"type":"arguments","partial_arguments":"{\"location\":"}
}

1. Coller les quatre exemples dans le formatage JSON. La chaîne de partial.partial_arguments ne se parse pas seule.
2. Avec JSON → Schema, partir de ok_final, puis ajouter required et additionalProperties: false.
3. Dans la validation de Schema, ok_call passe call_schema. ok_final et partial échouent.
4. ok_final passe final_schema. extra_field et ok_call échouent. L'objet final va à la sortie structurée, les arguments aux appels de fonction.

Questions fréquentes

Si output_text est déjà du JSON, faut-il encore le valider localement ?

Oui. La promesse est la syntaxe. L'exemple officiel ne ferme pas les champs en plus.

Peut-on lire le JSON final tant que le statut est requires_action ?

Non. Exécuter d'abord arguments et renvoyer un function_result avec call_id. Lire output_text quand le statut est completed.

Un partial_arguments de flux peut-il passer un Schema ?

Non. C'est un fragment. Attendre que arguments soit un objet.

La doc traite-t-elle la sortie structurée plus l'appel de fonction comme généralement disponible ?

Au 20/10/2026, non. La fiche dit Supported. Certains paragraphes disent seulement Gemini 3, la page des outils dit Gemini 4 et 3, les exemples utilisent gemini-4-argon. Traiter cela comme un aperçu et valider les deux localement.

Est-ce la même note que celle sur la date de Gemini 4 ?

Non. C'était la prévision d'avant le lancement : quand sort Gemini 4. Cette note ne couvre que les deux JSON après la disponibilité générale.

En bref

Au 20/10/2026, gemini-4-argon est en disponibilité générale depuis le 13/10/2026. Appel de fonction et sortie structurée sont pris en charge, pas la Live API. L'entrée d'outil est function_call.arguments. Le JSON final est output_text après completed. Ne pas passer partial_arguments dans un Schema. La doc de la combinaison n'est pas encore une seule phrase : garder les deux contrats locaux. Ensuite, refuser ok_call comme résultat de match, puis choisir v1beta ou v1beta2.

Outils liés

Articles liés