Google présente A2UI Express et une voie distincte par modèle de décision
La mise à jour A2UI publiée par Google le 27 octobre porte sur le format produit par un agent avant qu’une interface ne soit affichée. Au lieu de demander au modèle d’écrire directement un message de transport JSON imbriqué, le développeur peut lui faire produire A2UI Express. Un code déterministe du SDK convertit ensuite ce format intermédiaire en messages A2UI ordinaires.
La mise à jour A2UI publiée par Google le 27 octobre porte sur le format produit par un agent avant qu’une interface ne soit affichée. Au lieu de demander au modèle d’écrire directement un message de transport JSON imbriqué, le développeur peut lui faire produire A2UI Express. Un code déterministe du SDK convertit ensuite ce format intermédiaire en messages A2UI ordinaires. Le client annonce toujours un catalogue de composants autorisés et le moteur d’affichage reçoit toujours le protocole habituel. Les consignes de génération et le compilateur découlent du même schéma de catalogue : Express n’ouvre donc pas la voie à des composants arbitraires hors de ce contrat.
Google affirme qu’Express peut utiliser jusqu’à trois fois moins de jetons de texte que Direct JSON pour des écrans comparables et réduire la latence jusqu’à trois fois dans ses essais. L’article décrit une comparaison de quatre syntaxes sur 51 tâches avec Gemini 3.5 Flash, selon que le mode de réflexion est actif ou non. Le mot « jusqu’à » désigne un cas favorable observé, pas une promesse pour tous les écrans, modèles ou réseaux. Le SDK valide la structure obtenue; cela ne suffit pas à certifier que les valeurs affichées, les choix de composants ou les actions proposées sont corrects pour une entreprise. Le temps jusqu’au premier caractère généré n’est pas non plus le temps jusqu’à un écran utilisable.
Le format Express est indiqué comme disponible dans les SDK d’agent A2UI pour Python, TypeScript et Dart. Les SDK Python et TypeScript peuvent transmettre Direct JSON par morceaux, tandis qu’Express est compilé après réception de la réponse entière. Des macros dans le SDK Python peuvent prendre un identifiant de commande et rechercher ses vraies valeurs dans les systèmes de l’application; le modèle n’a alors pas à inventer un prix ou un état de commande. Ces différences influencent le premier affichage, la validation et l’origine des données. Il faudrait mesurer chaque étape sur la tâche réelle avant de conclure qu’un format est meilleur.
Une autre voie apparaît pour les écrans dont la forme est connue à l’avance. Dans l’exemple Apparite, le modèle de décision Jev répond à des questions typées sur la disposition, le code construit l’arbre des composants, puis un petit modèle écrit seulement le texte. Sur un essai de onze demandes, l’arbre est apparu en 92 à 298 millisecondes et les écrans complets en 0,8 à 1,7 seconde. Google évoque un gain pouvant atteindre 80 fois pour ce chemin contraint. L’exemple ne couvre que neuf archétypes d’écrans et douze blocs; son échantillon est petit. Les SDK A2UI n’intègrent pas encore un format d’inférence pour modèle de décision. Attribuer ces 80 fois à Express ou à tout A2UI serait donc une erreur.
Le choix dépend de la liberté nécessaire. Un écran de paramètres à disposition prédéfinie peut convenir à des décisions rapides; une interface qui doit composer librement parmi les éléments approuvés a davantage besoin d’Express. Un format maison peut aussi être converti vers le même transport si ses instructions et son compilateur restent cohérents avec le catalogue. Une équipe devrait comparer validité, qualité des données, temps de réalisation et réaction aux erreurs sur ses propres scénarios. Les chiffres publiés sont des essais du fournisseur et une démonstration limitée, non un classement indépendant. Les « jetons » ici sont des unités de texte généré, pas des actifs financiers.
Sources
FAQ
Que change A2UI Express ?
La mise à jour A2UI publiée par Google le 27 octobre porte sur le format produit par un agent avant qu’une interface ne soit affichée. Au lieu de demander au modèle d’écrire directement un message de transport JSON imbriqué, le développeur peut lui faire produire A2UI Express. Un code déterministe du SDK convertit ensuite ce format intermédiaire en messages A2UI ordinaires. Le client annonce toujours un catalogue de composants autorisés et le moteur d’affichage reçoit toujours le protocole habituel. Les consignes de génération et le compilateur découlent du même schéma de catalogue : Express n’ouvre donc pas la voie à des composants arbitraires hors de ce contrat.
À quelle méthode se rapporte le chiffre allant jusqu’à 80 fois ?
Une autre voie apparaît pour les écrans dont la forme est connue à l’avance. Dans l’exemple Apparite, le modèle de décision Jev répond à des questions typées sur la disposition, le code construit l’arbre des composants, puis un petit modèle écrit seulement le texte. Sur un essai de onze demandes, l’arbre est apparu en 92 à 298 millisecondes et les écrans complets en 0,8 à 1,7 seconde. Google évoque un gain pouvant atteindre 80 fois pour ce chemin contraint. L’exemple ne couvre que neuf archétypes d’écrans et douze blocs; son échantillon est petit. Les SDK A2UI n’intègrent pas encore un format d’inférence pour modèle de décision. Attribuer ces 80 fois à Express ou à tout A2UI serait donc une erreur.
Ces chiffres valent-ils pour toutes les applications A2UI ?
Le choix dépend de la liberté nécessaire. Un écran de paramètres à disposition prédéfinie peut convenir à des décisions rapides; une interface qui doit composer librement parmi les éléments approuvés a davantage besoin d’Express. Un format maison peut aussi être converti vers le même transport si ses instructions et son compilateur restent cohérents avec le catalogue. Une équipe devrait comparer validité, qualité des données, temps de réalisation et réaction aux erreurs sur ses propres scénarios. Les chiffres publiés sont des essais du fournisseur et une démonstration limitée, non un classement indépendant. Les « jetons » ici sont des unités de texte généré, pas des actifs financiers.