Código y agentesGoogle Developers

A2UI 1.0: comprueba el soporte de los renderizadores antes de migrar

Google anunció la primera versión estable del protocolo A2UI el 11 de noviembre. Para los desarrolladores, el siguiente paso útil es comprobar la integración versión por versión: que el protocolo sea estable no significa que todos los renderizadores o entornos anfitriones hayan completado su actualización.

Un pequeño robot de taller verde musgo encaja componentes de interfaz de color lavanda en un marco de latón, junto a bandejas de componentes ordenadas.
Ilustración conceptual.

Qué ha cambiado

A2UI permite que un agente describa una interfaz que una aplicación renderiza mediante componentes registrados. El modelo puede componer una pantalla con un vocabulario aprobado, mientras la aplicación conserva sus propios controles y su lenguaje visual. Esto resulta útil cuando una conversación necesita opciones, formularios o un resultado estructurado además de texto.

El anuncio de Google del 11 de noviembre presenta la primera versión estable del protocolo, con llamadas a funciones bidireccionales y metadatos de accesibilidad. Considera esta versión un contrato que debes evaluar. Un hito del protocolo no demuestra por sí solo que una integración sea rápida, accesible o segura en tu aplicación; esos resultados requieren evidencia a nivel de aplicación.

Comprueba toda la cadena de compatibilidad

Empieza por el cliente que realmente distribuyes. El proyecto enumera renderizadores para React, Angular, Lit, Flutter y SwiftUI. El anuncio indica que Jetpack Compose y la integración de agentes registrados de Gemini siguen en la versión 0.9.1, con actualizaciones pendientes; Lynx admite la versión 0.9. Deja constancia de esa diferencia en lugar de asumir que ver el nombre de un framework en una página de presentación significa que es compatible con 1.0.

Crea una fila de inventario para cada cliente desplegado: entorno anfitrión, paquete del renderizador, protocolo, catálogo y SDK del agente. Fija las versiones que pruebes. Si un entorno existente sigue utilizando un protocolo anterior, mantén disponible su ruta compatible y dirige cada conexión según la versión admitida. Un conjunto de clientes con versiones distintas necesita un plan de actualización, no una única fecha de lanzamiento para todos.

Trata el catálogo como una API

La guía de migración documenta cambios incompatibles en los catálogos. Revisa sus reglas con un catálogo pequeño y representativo antes de modificar todas las pantallas. En particular, sustituir globalmente path por @path es incorrecto: la guía distingue los enlaces dinámicos de otros campos path. Revisa el significado de cada campo y conserva ejemplos de los mensajes que utiliza tu aplicación antes y después del cambio.

Que un componente o una función esté registrado establece un límite. Tener permiso para realizar una operación de negocio establece otro. Por ejemplo, un control de confirmación renderizado debería seguir comunicándose con un servidor que compruebe el usuario autenticado, la operación solicitada y el estado actual del recurso. Incluye esa autorización de forma explícita en la revisión de la implementación; no la des por hecha porque la interfaz se haya renderizado correctamente.

Realiza una prueba pequeña y observable

Elige un flujo de trabajo reversible y describe sus estados esperados antes de conectar un modelo. Una primera prueba útil podría recoger una preferencia y mostrar una vista previa, dejando cualquier acción con consecuencias detrás del proceso de confirmación que ya tenga la aplicación. Limita el conjunto de componentes para que alguien pueda revisar todas las interacciones disponibles.

Codorc recomienda las siguientes comprobaciones. Son criterios de aceptación propuestos, no pruebas que hayamos realizado con A2UI:

  • Reproduce un conjunto fijo de mensajes válidos y comprueba el estado renderizado, no solo si el análisis de los mensajes se completa sin errores.
  • Envía un componente desconocido, una función no registrada y una llamada procedente de un emisor no autorizado. Confirma que todos fallen sin ejecutar una operación de negocio.
  • Interrumpe la transmisión a mitad de un formulario, vuelve a conectar y comprueba si los valores introducidos y las acciones pendientes siguen siendo comprensibles.
  • Recorre todos los controles con el teclado. Comprueba el foco después de las actualizaciones, los nombres accesibles y los anuncios mediante un lector de pantalla.
  • Compara la misma tarea en cada idioma admitido y con el ancho de un teléfono pequeño. Busca etiquetas recortadas, alteraciones del sentido al cambiar el orden y errores de validación que resulten difíciles de utilizar.
  • Registra el tiempo hasta disponer de una interfaz utilizable, las tareas completadas, los reintentos y el esfuerzo de revisión frente al flujo existente. Define qué condición activará la reversión antes de invitar a más usuarios.

Elígelo por la interacción que necesitas

El inicio rápido oficial es un ejemplo para aprender, no una plantilla de producción. Úsalo para entender cómo se conectan el agente, el catálogo, el transporte y el renderizador, y después revisa qué partes debe aportar tu propia aplicación.

Merece la pena evaluar A2UI cuando un agente necesita combinar de distintas maneras controles conocidos dentro de tu sistema de diseño. Para una tarea fija y bien comprendida, un formulario convencional puede seguir siendo más fácil de probar y mantener. Decide según la interacción y las opciones de despliegue compatibles, y amplía el uso solo cuando la prueba te proporcione evidencia.

La fecha del suceso corresponde al anuncio original. La fecha de publicación indica cuándo apareció el artículo en Codorc.

Continúa leyendo

Todas las historias