Transmisión en streaming A2A y tareas asincrónicas para flujos de trabajo de agentes de larga duración

La mayoría de las demostraciones de agentes de IA aún se comportan como completados de chat con pasos adicionales: envías un prompt, esperas unos segundos y recibes una respuesta en una sola salida.

El trabajo real de los agentes a menudo no se ajusta a ese patrón. La investigación, la revisión de código, el análisis de compras, la investigación de incidentes y la planificación en múltiples pasos pueden durar minutos u horas, y pueden necesitar aclaraciones a mitad del proceso, transmitir resultados parciales, delegar en otro agente y producir archivos en lugar de una única respuesta de texto. Ahí es donde importa el modelo asíncrono del protocolo A2A dentro del Sistemas de IA cluster, porque A2A trata el trabajo de larga ejecución como una Tarea con un ciclo de vida en lugar de una respuesta HTTP de un solo disparo. Los clientes pueden mantenerse conectados mediante Server-Sent Events (SSE), consultar el estado de la tarea o registrar webhooks de empuje cuando no pueden mantener una conexión abierta.

Este artículo cubre el diseño operativo para esos flujos de trabajo, incluyendo cuándo transmitir versus consultar versus empujar, cómo encaja input_required en los flujos con intervención humana, manejo de errores y qué instrumentar en producción. Para Agent Cards, mensajes, partes y el modelo completo de tareas, consulta ¿Qué es el Protocolo A2A? Agent Cards y Tareas Explicadas.

Por qué las Tareas de Agentes A2A de Larga Ejecución Necesitan Diseño Asíncrono

El modelo mental de solicitud/respuesta síncrona se desmorona rápidamente una vez que el trabajo del agente abarca herramientas, delegación, aprobaciones y artefactos grandes. Una tarea de agente puede llamar a múltiples servidores MCP internamente, delegar subtrabajo a otro agente a través de A2A, esperar la aprobación humana, generar artefactos grandes en fragmentos, fallar a mitad del proceso y necesitar recuperación parcial, y acumular costos de tokens a lo largo de varios saltos. Las API HTTP pueden aproximar esto con tiempos de espera, trabajos en segundo plano y puntos finales de estado ad hoc, pero A2A integra la identidad y el estado de la tarea en el protocolo para que clientes y gateways puedan razonar sobre el trabajo de manera consistente. Para ver cómo encajan esas capas dentro de un asistente de producción antes de agregar límites A2A asíncronos, consulta Arquitectura de Asistentes de IA: LLM, Memoria, Herramientas, Enrutamiento, Observabilidad.

Mi sesgo es práctico: no crees una Tarea para todo, porque un resumen de una línea no necesita un ciclo de vida. Usa una Tarea cuando el trabajo sea con estado, auditable, de larga ejecución, productor de artefactos o pueda necesitar entrada a mitad del proceso. La regla general del explicador sigue siendo válida: las interacciones simples pueden devolver un Mensaje, mientras que el trabajo complejo debería devolver una Tarea.

Ciclo de Vida de la Tarea A2A y Transiciones de Estado

Una Tarea A2A pasa por estados que los clientes pueden consultar en cualquier momento. El nombre exacto varía ligeramente según la implementación, pero el modelo es estable en los servidores que siguen el protocolo.

El estado submitted significa que el cliente envió trabajo y el agente lo aceptó o colocó en cola. En working, el agente está procesando activamente, lo que puede incluir llamadas a herramientas, delegación o transmisión de salida parcial. El estado input_required indica que el agente se pausó porque necesita más entrada, aclaración o aprobación humana, y no es un estado de error. completed es un éxito terminal con artefactos disponibles; failed es un error terminal cuyos detalles y artefactos parciales dependen de la implementación; canceled significa que un cliente, gateway o llamante autorizado detuvo la tarea; y rejected significa que el agente rechazó la tarea debido a políticas, incompatibilidad de capacidades o autenticación.

Cuando input_required pausa versus falla un flujo de trabajo

Trata input_required como una pausa deliberada, no como una excepción. El agente te está diciendo que no puede proceder sin algo de tu parte, ya sea un parámetro faltante, una confirmación de política o la firma de un gerente en una acción de alto riesgo. Un flujo de trabajo falla cuando la tarea alcanza failed o rejected, o cuando un llamante excede un tiempo de espera esperando una entrada que nunca llega, por lo que debes diseñar tiempos de espera explícitos para los pasos humanos en lugar de dejar que las aprobaciones se queden indefinidamente.

Una aprobación que espera tres días sin escalación es un flujo de trabajo estancado, no uno paciente, y los flujos estancados obstruyen las tiendas de tareas mientras hacen que los tableros de observabilidad sean más difíciles de leer.

Quién puede cancelar una tarea A2A

La autoridad de cancelación debe definirse en el momento del diseño en lugar de debatirse durante un incidente. El cliente generalmente puede cancelar las tareas que creó; un gateway puede cancelar en nombre de inquilinos, violaciones de políticas o límites de presupuesto; y un agente aguas arriba puede cancelar el trabajo delegado cuando orquesta a través de A2A si el protocolo y la política lo permiten. Registra quién canceló y por qué, porque en cadenas multi-agente, el trabajo huérfano es una fuente común de facturas de tokens sorpresivas.

Intervención Humana con Estados de Tarea input_required

input_required es una de las características de diseño de A2A más subutilizadas, y muchos equipos lo tratan como un código de error cuando en realidad es un estado de flujo de trabajo de primera clase. En producción, encontrarás casos donde el agente debería detenerse, como gastar presupuesto en una solicitud ambigua, ejecutar una acción irreversible, acceder a datos sensibles sin confirmación de alcance o delegar en un especialista que necesita intención de usuario explícita. Modela estos como transiciones deliberadas a input_required, con un mensaje claro que explique lo que se necesita.

Flujos de aprobación para delegación A2A arriesgada

Cuando el Agente A delega al Agente B a través de A2A y el Agente B entra en input_required para aprobación humana, tres sistemas necesitan acordar qué sucede a continuación. El agente aguas abajo se pausa y expone lo que necesita, el orquestador o gateway muestra esa pausa al usuario, y la respuesta del usuario reanuda la tarea mediante un nuevo mensaje. La comparación A2A vs MCP explica por qué la delegación a través de los límites del agente es un problema diferente al acceso a herramientas, y por qué la semántica de aprobación pertenece a la capa de tareas en lugar de dentro de una sola llamada MCP. No apruebes silenciosamente de forma automática porque la UX es inconveniente, ya que los errores costosos suelen provenir de atajos de conveniencia en lugar de modelos faltantes.

Patrones de UX para tareas A2A pausadas

Espera bloqueante significa que la UI muestra un spinner o tarjeta de aprobación hasta que la tarea sale de input_required, lo que funciona bien para pasos humanos cortos. Espera no bloqueante significa que el cliente registra el ID de la tarea, permite que el usuario continúe en otro lugar y utiliza polling o push para notificar cuando se necesita entrada nuevamente, lo cual es requerido para móviles, aprobaciones vinculadas por correo electrónico o asistentes multi-pestaña. Tiempo de espera cuando los humanos son lentos significa definir un SLA por paso y, después de N horas, transicionar a failed o escalar a otra cola, porque las esperas ilimitadas obstruyen las tiendas de tareas y confunden los tableros de observabilidad.

Cómo un gateway A2A maneja input_required

Si ejecutas un gateway A2A, decide si reenvía eventos input_required de manera transparente, agrupa pausas de múltiples agentes aguas abajo en un solo prompt de usuario o hace cumplir que ciertas habilidades siempre requieran aprobación antes de salir de input_required. La autenticación y política para acciones aprobadas pertenecen a un artículo de seguridad dedicado; por ahora, asume que cada tarea reanudada debe携带 la misma identidad de usuario y alcance que la solicitud original.

Elegir Síncrono, Streaming SSE, Polling o Notificaciones Push

A2A admite múltiples modos de interacción, y la elección correcta depende de las capacidades del cliente y las necesidades de latencia en lugar de qué modo suena más moderno.

Lee primero las banderas de capacidad de la Agent Card

Antes de elegir un modo, lee la Agent Card del agente, porque el streaming requiere capabilities.streaming: true y el soporte de notificaciones push se anuncia por separado. Los clientes que asumen que cada agente transmite se romperán contra implementaciones mínimas, por lo que la negociación no es ceremonial: previene errores de tiempo de ejecución cuando un agente especialista solo soporta comprobaciones de estado basadas en polling.

Cuándo usar polling del lado del asistente alrededor de A2A

Tu tiempo de ejecución del asistente puede envolver el polling de tareas A2A en un bucle de programador en lugar de exponer detalles crudos del protocolo al usuario. Ese patrón se superpone con agentes de polling generales, que son procesos en segundo plano que se despiertan, verifican el estado y actúan. Para programación duradera, idempotencia y patrones de cola fuera de A2A específicamente, consulta Agentes de Polling en Asistentes de IA: 11 Patrones de Implementación. Usa polling del asistente cuando orquestas muchas tareas A2A desde un plano de control único, y usa streaming o push nativo de A2A cuando el cliente se conecta directamente al límite del agente.

Transmisión en Streaming de Eventos Enviados por Servidor (SSE) de A2A

SSE es el canal de tiempo real principal de A2A. El cliente llama a SendStreamingMessage, abre una conexión HTTP y recibe una respuesta text/event-stream hasta que la tarea alcance un estado terminal o interrumpido. La carga útil de cada evento tiene forma JSON-RPC, y los tipos de resultado típicos incluyen una instantánea de Task, un TaskStatusUpdateEvent para transiciones de ciclo de vida y mensajes intermedios del agente, y un TaskArtifactUpdateEvent para entrega de artefactos fragmentados con pistas append y lastChunk para reensamblaje.

Actualizaciones de progreso de streaming y artefactos parciales

El streaming brilla cuando los usuarios deberían ver el trabajo sucediendo, ya sea que eso signifique contadores de pasos (“3 de 7 fuentes revisadas”), generación de texto parcial, fragmentos de archivos incrementales para informes grandes o transiciones de estado de working a input_required sin polling. Diseña la UI alrededor de tipos de eventos en lugar de alrededor de un solo blob final, porque si solo muestras la salida cuando llega completed, podrías tan bien hacer polling.

Caídas de conexión SSE y resuscripción

Las redes caen, las laptops entran en suspensión y los equilibradores de carga cierran por inactividad las conexiones SSE, por lo que los streams largos necesitan lógica de recuperación en lugar de suposiciones optimistas. A2A proporciona SubscribeToTask para que los clientes puedan reconectar a un stream de tarea en progreso, y tu SDK de cliente debe persistir taskId localmente, detectar el cierre del stream antes del estado terminal, resuscribirse con retroceso y desduplicar eventos si el servidor reproduce estado superpuesto. Sin lógica de resuscripción, las tareas largas se sienten frágiles en producción incluso cuando el backend del agente es saludable.

Notificaciones Push y Webhooks de A2A

Push encaja en escenarios donde SSE es una mala combinación, como aplicaciones móviles en segundo plano, manejadores serverless o tareas que se ejecutan durante horas o días. El cliente proporciona un PushNotificationConfig con una url (webhook HTTPS en el lado del cliente), un token opcional para validar POSTs entrantes y detalles authentication opcionales para cómo el servidor A2A se autentica con el webhook. La configuración puede viajar junto con la llamada inicial SendMessage o SendStreamingMessage, o agregarse posteriormente mediante CreateTaskPushNotificationConfig para una tarea existente.

Cuando ocurre una actualización significativa, el servidor A2A realiza POST al webhook y el cliente típicamente llama a GetTask con el taskId notificado para obtener la Tarea actualizada completa y los artefactos. Push es una señal, no un transporte de carga completa.

Cuándo push gana a una conexión SSE abierta

Prefiere push cuando el cliente no puede mantener SSE (móvil, funciones de borde), cuando las actualizaciones son infrecuentes y basadas en hitos en lugar de token por token, o cuando quieres que el servidor despierte un motor de flujo de trabajo desconectado. Prefiere SSE cuando los usuarios observan el progreso en vivo, cuando los artefactos se transmiten en muchos fragmentos pequeños o cuando la latencia por debajo de unos segundos importa.

Correlación de notificaciones push con tareas A2A

Cada manejador push debe registrar y propagar el taskId, un ID de traza o correlación de la solicitud original, el tipo de evento o transición de estado y una marca de tiempo de la notificación para que los eventos obsoletos puedan ser rechazados. Los ataques de reproducción y las entregas duplicadas ocurren en producción, por lo que los manejadores idempotentes no son opcionales.

Resumen de seguridad del endpoint Push

Push introduce riesgo de SSRF en el servidor cuando clientes maliciosos registran URLs internas, y riesgo de suplantación en el cliente cuando POSTs falsos llegan al webhook. Las mitigaciones incluyen listas blancas de URLs, verificación de propiedad, JWTs firmados con JWKS, comprobaciones de marca de tiempo y validación del token de configuración. El modelo de amenazas completo, capas de identidad y controles de gateway viven en Seguridad de Agentes A2A y MCP: Identidad, Delegación y Huellas de Auditoría; hasta que lo hayas leído, trata la verificación de webhooks con la misma seriedad que las devoluciones de pago.

Patrones de Flujo de Trabajo Asíncrono A2A

Envío de tarea disparar-y-seguir

El cliente envía una tarea, recibe un ID de tarea inmediatamente y se desconecta, luego consulta GetTask más tarde o espera por push. Este es el patrón predeterminado para pipelines serverless y por lotes, pero deberías persistir el ID de tarea en almacenamiento duradero antes de reconocer al usuario, porque las invocaciones serverless que olvidan el ID pierden el trabajo.

Reanudación de una tarea después de input_required

Después de input_required, el usuario envía un nuevo mensaje contra la misma tarea y el agente transiciona de vuelta a working. Diseña mensajes para que el contexto de reanudación sea explícito, porque “Aprobado: proceder con el proveedor X” supera un simple “sí” cuando necesitas auditar qué fue aprobado seis horas después.

Delegación A2A encadenada con artefactos intermedios

Considera un flujo de trabajo de investigación donde un orquestador posee la Tarea T1 y delega recuperación, resumen y verificación a agentes especialistas, cada uno con su propio ID de tarea y artefactos en el camino.

Cada salto tiene su propio ID de tarea y máquina de estados, por lo que el orquestador debería transmitir o consultar tareas aguas abajo de forma independiente, persistir artefactos intermedios antes de comenzar el siguiente salto y fallar de manera elegante si T3 completa pero T4 rechaza el borrador. Patrones de Orquestación Multi-Agente cubre la elección de topología cuando esos especialistas se ejecutan como servicios separados en lugar de en un solo tiempo de ejecución. El progreso parcial es valioso, y una verificación fallida no debería eliminar un borrador usable sin una razón clara.

Almacenamiento de tareas duraderas para finalización diferida

El estado de la tarea y los artefactos deberían sobrevivir a los reinicios del proceso. Si tu agente se ejecuta en Kubernetes, asume que los pods mueren a mitad de la tarea y respalda registros de tareas y blobs de artefactos a una tienda que el contenedor del agente no posea exclusivamente.

Manejo de Errores para Flujos de Trabajo A2A de Larga Ejecución

Los flujos de trabajo de larga ejecución fallan de maneras predecibles a través de tiempos de espera, reintentos, artefactos parciales y cancelación insegura, y cada uno necesita una política explícita en lugar de manejo ad hoc en el código del cliente.

Presupuestos de tiempo de espera por salto y de extremo a extremo

Establece tiempos de espera en dos niveles: un máximo por salto para una tarea de agente antes de la escalación o cancelación, y un máximo de extremo a extremo para el flujo de trabajo visible por el usuario. Un agente de recuperación que se atasca no debería bloquear a todo el orquestador hasta que el navegador del usuario se quede sin tiempo.

Reintentos e idempotencia para tareas A2A

Los reintentos sin idempotencia duplican efectos secundarios como cargos dobles, tickets duplicados y correos electrónicos repetidos. Usa IDs de mensaje de cliente estables o claves de idempotencia donde el protocolo lo permita, y para mutaciones de negocio alinéate con Idempotencia en Sistemas Distribuidos que Realmente Funciona. Reinicia solo fallas transitorias como fallos de red o 503s, y no reinicies rejected o fallas de política ciegamente porque amplificarás el costo y molestarás a los agentes aguas abajo.

Políticas de recuperación de artefactos parciales

Cuando una tarea falla después de producir artefactos parciales, define si expones la salida parcial al usuario con una etiqueta clara de “incompleto”, permites reanudar desde el último buen punto de control o descartas la salida parcial cuando podría ser engañosa en contextos médicos, legales o financieros.

Cancelación segura a través de cadenas de delegación

Cancela tareas aguas abajo cuando un usuario aguas arriba aborta, usa un gráfico de delegación para que la cancelación se propague y registra tareas canceladas que ya incurrieron en costo porque los equipos de finanzas lo notarán.

Observabilidad para Flujos de Trabajo Asíncronos A2A

No puedes depurar trabajo asíncrono multi-agente a menos que puedas trazarlo a través de los límites, lo que significa correlacionar identificadores en cada salto en lugar de confiar en registros no estructurados. Los campos de correlación mínimos incluyen un ID de traza por flujo de trabajo iniciado por el usuario, un ID de tarea por tarea de agente incluyendo hijos delegados, un ID de agente para la Agent Card o servicio que manejó el salto, y un ID de tarea padre que enlace cadenas de delegación.

Registra cada transición de estado con marcas de tiempo, y registra eventos de creación de artefactos con tamaño y hash en lugar de necesariamente contenido completo cuando las políticas de PII se aplican. Atribuye costo y latencia por salto, porque los flujos de trabajo multi-agente ocultan el gasto de tokens hasta que llega la factura y las etiquetas de costo por tarea hacen que “¿qué especialista es caro?” sea respondible. Para métricas, backends de traza y patrones de instrumentación específicos de LLM, consulta Observabilidad para Sistemas LLM y el pilar más amplio Observabilidad para ver cómo esas señales encajan en una pila de telemetría de producción. Cuando un usuario pregunta “¿por qué el agente hizo eso?”, tu respuesta debería ser una traza que abarque el orquestador, saltos A2A, llamadas de herramientas MCP y cualquier pausa input_required en lugar de un encogimiento de hombros y un grep de registros.

Lista de Verificación de Producción para Streaming y Tareas Asíncronas A2A

Antes de enviar caminos A2A de larga ejecución a producción, verifica las siguientes áreas.

Agent Card y capacidades

• capabilities.streaming refleja el soporte SSE real
• Soporte de notificación push documentado si está implementado
• Habilidades que requieren aprobación humana documentan el comportamiento esperado input_required

Modos de cliente

• Cliente SSE maneja resuscripción vía SubscribeToTask
• Intervalo de polling hace retroceso bajo carga
• Webhook push verifica autenticidad y rechaza eventos obsoletos

Durabilidad

• El estado de la tarea sobrevive a los reinicios del proceso del agente
• Artefactos almacenados fuera del sistema de archivos efímero del contenedor
• Artefactos intermedios disponibles para recuperación parcial

Error y política

• Presupuestos de tiempo de espera por salto y de extremo a extremo definidos
• Reintentos idempotentes para operaciones mutantes
• Cancelación se propaga a través de los bordes de delegación

Observabilidad

• ID de traza + ID de tarea + ID de agente en cada salto
• Transiciones de estado registradas
• Atribución de costo por tarea o por agente

Pruebas de carga

• SSE a través de tu proxy inverso (el búfer rompe los streams)
• Tareas largas concurrentes sin fugas de memoria en conexiones abiertas
• Manejo de inundación push sin sobrecarga de webhook

Conclusión

El valor de A2A se muestra más claramente cuando el trabajo no encaja en una llamada de API síncrona única, porque el streaming, las tareas asíncronas, las notificaciones push y los estados de tarea explícitos son cómo el protocolo maneja cargas de trabajo de agentes reales como investigación, delegación, aprobaciones y artefactos grandes sin pretender que todo se completa en un solo viaje de ida y vuelta HTTP. Comienza con el modo más simple que funcione, agrega SSE cuando los usuarios necesitan progreso en vivo, agrega push cuando las conexiones no pueden mantenerse abiertas, trata input_required como una herramienta de diseño de primera clase en lugar de una falla, e instrumenta cada salto para que los flujos de trabajo asíncronos multi-agentes no superen tu capacidad para explicarlos.

Preguntas Frecuentes

¿Cuándo deberías usar streaming A2A en lugar de polling? Usa streaming cuando el cliente puede mantener una conexión HTTP abierta y necesitas actualizaciones de progreso de baja latencia o artefactos incrementales. Usa polling cuando las conexiones son poco confiables, los clientes son orientados a lotes o solo necesitas comprobaciones de estado periódicas en tareas de larga ejecución.

¿Qué significa input_required en una tarea A2A? Es un estado de pausa donde el agente necesita más información o aprobación humana. Diseña UX y tiempos de espera explícitamente alrededor de esto en lugar de tratarlo como un error.

¿Cómo funcionan las notificaciones push de A2A? Registra un PushNotificationConfig con un webhook HTTPS. El servidor realiza POST en actualizaciones significativas; el cliente llama a GetTask para recuperar el estado completo y los artefactos.

¿Cómo deberías reiniciar tareas A2A fallidas? Reinicia fallas transitorias con claves de idempotencia, respeta los presupuestos de tiempo de espera y no reinicies ciegamente estados terminales como rejected o fallas de política.

¿Qué deberías registrar para flujos de trabajo A2A de larga ejecución? Correlaciona ID de traza, ID de tarea y ID de agente a través de los saltos. Registra transiciones de estado, artefactos, delegación, aprobaciones y costo por paso para que puedas reconstruir el flujo de trabajo completo.

Fuentes

• Protocolo A2A – Transmisión y Operaciones Asíncronas: https://a2a-protocol.org/latest/topics/streaming-and-async/
• Protocolo A2A – Descripción general de la especificación: https://a2a-protocol.org/latest/specification/