Streaming A2A e Tarefas Assíncronas para Fluxos de Trabalho de Agentes de Longa Duração

A maioria das demonstrações de agentes de IA ainda se comporta como conclusões de chat com passos extras: você envia um prompt, aguarda alguns segundos e recebe uma resposta em uma única mensagem.

O trabalho real de agentes frequentemente não se encaixa nesse padrão. Pesquisas, revisões de código, análises de compras, investigações de incidentes e planejamentos em múltiplos passos podem levar minutos ou horas, e podem precisar de esclarecimentos no meio do caminho, transmitir resultados parciais em fluxo (streaming), delegar para outro agente e produzir arquivos em vez de uma única resposta de texto. É aí que o modelo assíncrono do protocolo A2A se torna importante dentro do cluster mais amplo de Sistemas de IA, porque o A2A trata o trabalho de longa duração como uma Tarefa com um ciclo de vida, em vez de uma resposta HTTP de única execução. Os clientes podem permanecer conectados via Server-Sent Events (SSE), consultar o estado da tarefa ou registrar webhooks de push quando não conseguirem manter uma conexão aberta.

Este artigo aborda o design operacional para esses fluxos de trabalho, incluindo quando usar streaming versus polling versus push, como o input_required se encaixa em fluxos com intervenção humana, tratamento de falhas e o que instrumentar em produção. Para Agent Cards, mensagens, partes e o modelo completo de tarefas, consulte O que é o Protocolo A2A? Agent Cards e Tarefas Explicados.

Por que Tarefas de Agentes A2A de Longa Duração Precisam de Design Assíncrono

O modelo mental síncrono de requisição/resposta quebra rapidamente uma vez que o trabalho do agente abrange ferramentas, delegação, aprovações e artefatos grandes. Uma tarefa de agente pode chamar múltiplos servidores MCP internamente, delegar sub-trabalhos para outro agente via A2A, aguardar aprovação humana, gerar artefatos grandes em pedaços, falhar parcialmente e precisar de recuperação parcial, e acumular custo de tokens através de vários saltos (hops). APIs HTTP podem aproximar isso com timeouts, jobs em background e endpoints de status ad hoc, mas o A2A incorpora identidade e estado da tarefa no protocolo, permitindo que clientes e gateways raciocinem sobre o trabalho de forma consistente. Para saber como essas camadas se encaixam dentro de um assistente de produção antes de adicionar limites assíncronos A2A, consulte Arquitetura de Assistente de IA: LLM, Memória, Ferramentas, Roteamento, Observabilidade.

Meu viés é prático: não crie uma Tarefa para tudo, porque um resumo de uma linha não precisa de um ciclo de vida. Use uma Tarefa quando o trabalho for stateful (com estado), auditável, de longa duração, produtor de artefatos ou possa precisar de entrada no meio do processo. A regra geral do guia ainda se aplica: interações simples podem retornar uma Mensagem, enquanto trabalhos complexos devem retornar uma Tarefa.

Ciclo de Vida da Tarefa A2A e Transições de Estado

Uma Tarefa A2A passa por estados que os clientes podem consultar a qualquer momento. A nomenclatura exata varia ligeiramente por implementação, mas o modelo é estável entre servidores que seguem o protocolo.

O estado submitted (enviado) significa que o cliente enviou o trabalho e o agente o aceitou ou colocou em fila. Em working (em andamento), o agente está processando ativamente, o que pode incluir chamadas de ferramentas, delegação ou streaming de saída parcial. O estado input_required (entrada necessária) indica que o agente fez uma pausa porque precisa de mais entrada, esclarecimento ou aprovação humana, e não é um estado de falha. completed (concluído) é o sucesso terminal com artefatos disponíveis; failed (falhou) é um erro terminal cujos detalhes e artefatos parciais dependem da implementação; canceled (cancelado) significa que um cliente, gateway ou chamador autorizado parou a tarefa; e rejected (rejeitado) significa que o agente recusou a tarefa devido a política, incompatibilidade de capacidade ou autenticação.

Quando input_required pausa versus falha um fluxo de trabalho

Trate input_required como uma pausa deliberada, não como uma exceção. O agente está dizendo que não pode prosseguir sem algo de você, seja um parâmetro faltante, uma confirmação de política ou a assinatura de um gerente em uma ação de alto risco. Um fluxo de trabalho falha quando a tarefa atinge failed ou rejected, ou quando um chamador excede um timeout esperando por uma entrada que nunca chega, portanto, você deve projetar timeouts explícitos para etapas humanas em vez de deixar aprovações indefinidamente.

Uma aprovação que aguarda três dias sem escalonamento é um fluxo de trabalho travado, não um paciente, e fluxos de trabalho travados obstruem as lojas de tarefas enquanto tornam os painéis de observabilidade mais difíceis de ler.

Quem pode cancelar uma tarefa A2A

A autoridade de cancelamento deve ser definida no momento do design, não debatida durante um incidente. O cliente geralmente pode cancelar tarefas que criou; um gateway pode cancelar em nome de tenants, violações de política ou limites de orçamento; e um agente upstream pode cancelar trabalho delegado ao orquestrar via A2A se o protocolo e a política permitirem. Registre quem cancelou e por quê, porque em cadeias multi-agente, o trabalho órfão é uma fonte comum de cobranças de tokens surpresa.

Intervenção Humana com Estados de Tarefa input_required

input_required é uma das funcionalidades de design mais subutilizadas do A2A, e muitas equipes o tratam como um código de erro quando é, na verdade, um estado de fluxo de trabalho de primeira classe. Em produção, você encontrará casos em que o agente deve parar, como gastar orçamento em uma solicitação ambígua, executar uma ação irreversível, acessar dados sensíveis sem confirmação de escopo ou delegar para um especialista que precisa de intenção explícita do usuário. Modele isso como transições deliberadas para input_required, com uma mensagem clara explicando o que é necessário.

Fluxos de aprovação para delegação A2A arriscada

Quando o Agente A delega para o Agente B via A2A e o Agente B entra em input_required para aprovação humana, três sistemas precisam concordar sobre o que acontece a seguir. O agente downstream pausa e expõe o que precisa, o orquestrador ou gateway expõe essa pausa ao usuário, e a resposta do usuário retoma a tarefa via uma nova mensagem. A comparação A2A vs MCP explica por que a delegação através de limites de agentes é um problema diferente do acesso a ferramentas, e por que as semânticas de aprovação pertencem à camada de tarefa em vez de dentro de uma única chamada MCP. Não aprove silenciosamente por conveniência de UX, já que erros caros geralmente vêm de atalhos de conveniência em vez de modelos ausentes.

Padrões de UX para tarefas A2A pausadas

Aguarde bloqueante significa que a UI mostra um spinner ou cartão de aprovação até que a tarefa saia de input_required, o que funciona bem para etapas humanas curtas. Aguarde não bloqueante significa que o cliente registra o ID da tarefa, permite que o usuário continue em outro lugar e usa polling ou push para notificar quando a entrada for necessária novamente, o que é necessário para mobile, aprovações vinculadas a e-mail ou assistentes multi-aba. Timeout quando humanos são lentos significa definir um SLA por etapa e, após N horas, transicionar para failed ou escalar para outra fila, porque esperas ilimitadas obstruem as lojas de tarefas e confundem os painéis de observabilidade.

Como um gateway A2A lida com input_required

Se você executa um gateway A2A, decida se ele encaminha eventos input_required transparentemente, agrega pausas de múltiplos agentes downstream em um único prompt do usuário ou impõe que certas habilidades sempre requerem aprovação antes de sair de input_required. Autenticação e política para ações aprovadas pertencem a um artigo de segurança dedicado; por enquanto, assuma que toda tarefa retomada deve carregar a mesma identidade e escopo do usuário da solicitação original.

Escolhendo Sync, Streaming SSE, Polling ou Notificações Push

O A2A suporta múltiplos modos de interação, e a escolha certa depende das capacidades do cliente e das necessidades de latência, em vez de qual modo soa mais moderno.

Leia primeiro os flags de capacidade do Agent Card

Antes de escolher um modo, leia o Agent Card do agente, porque o streaming requer capabilities.streaming: true e o suporte a notificações push é anunciado separadamente. Clientes que assumem que todo agente faz streaming quebrarão contra implementações mínimas, portanto, a negociação não é cerimonial: ela previne falhas em tempo de execução quando um agente especialista suporta apenas verificações de status baseadas em polling.

Quando usar polling do lado do assistente ao redor do A2A

Seu runtime de assistente pode envolver o polling de tarefas A2A em um loop de agendador em vez de expor detalhes brutos do protocolo ao usuário. Esse padrão se sobrepõe a agentes de polling gerais, que são processos em background que acordam, verificam o estado e agem. Para agendamento durável, idempotência e padrões de fila fora do A2A especificamente, consulte Agentes de Polling em Assistentes de IA: 11 Padrões de Implementação. Use polling do assistente quando você orquestra muitas tarefas A2A de um único plano de controle, e use streaming ou push nativo do A2A quando o cliente se conecta diretamente ao limite do agente.

Streaming A2A Server-Sent Events (SSE)

SSE é o canal de tempo real principal do A2A. O cliente chama SendStreamingMessage, abre uma conexão HTTP e recebe uma resposta text/event-stream até que a tarefa atinja um estado terminal ou interrompido. O payload de cada evento tem formato JSON-RPC, e os tipos de resultado típicos incluem um snapshot de Task (Tarefa), um TaskStatusUpdateEvent para transições de ciclo de vida e mensagens intermediárias do agente, e um TaskArtifactUpdateEvent para entrega de artefatos em pedaços com dicas append e lastChunk para reassembly (montagem).

Atualizações de progresso de streaming e artefatos parciais

O streaming brilha quando os usuários devem ver o trabalho acontecendo, seja isso contadores de etapas (“3 de 7 fontes revisadas”), geração de texto parcial, pedaços incrementais de arquivos para relatórios grandes, ou transições de estado de working para input_required sem polling. Projete a UI em torno dos tipos de evento em vez de em torno de um blob final único, porque se você só exibir a saída quando completed chegar, poderia tão bem usar polling.

SSE: quedas de conexão e reassinatura

Redes caem, laptops entram em suspensão e load balancers têm timeout de inatividade em conexões SSE, então streams longos precisam de lógica de recuperação em vez de suposições otimistas. O A2A fornece SubscribeToTask para que clientes possam reconectar a um stream de tarefa em progresso, e seu SDK de cliente deve persistir o taskId localmente, detectar o fechamento do stream antes do estado terminal, reassinar com backoff e desduplicar eventos se o servidor reproduzir estados sobrepostos. Sem lógica de reassinatura, tarefas longas parecem frágeis em produção, mesmo quando o backend do agente está saudável.

Notificações Push e Webhooks A2A

Push se encaixa em cenários onde SSE é uma correspondência pobre, como aplicativos mobile em background, handlers serverless ou tarefas que executam por horas ou dias. O cliente fornece um PushNotificationConfig com uma url (webhook HTTPS no lado do cliente), um token opcional para validar POSTs entrantes e detalhes opcionais de authentication para como o servidor A2A autentica no webhook. A configuração pode acompanhar a chamada inicial SendMessage ou SendStreamingMessage, ou ser adicionada depois via CreateTaskPushNotificationConfig para uma tarefa existente.

Quando ocorre uma atualização significativa, o servidor A2A faz POST no webhook e o cliente tipicamente chama GetTask com o taskId notificado para buscar a Tarefa completa atualizada e artefatos. Push é um sinal, não um transporte de payload completo.

Quando o push supera uma conexão SSE aberta

Prefira push quando o cliente não puder manter SSE (mobile, funções de borda), quando as atualizações são infrequentes e baseadas em marcos em vez de token por token, ou quando você quer que o servidor acorde um motor de fluxo de trabalho desconectado. Prefira SSE quando os usuários assistem ao progresso ao vivo, quando artefatos fluem em muitos pedaços pequenos, ou quando a latência abaixo de alguns segundos importa.

Correlacionando notificações push com tarefas A2A

Todo handler de push deve registrar e propagar o taskId, um ID de trace ou correlação da solicitação original, o tipo de evento ou transição de estado, e um timestamp da notificação para que eventos obsoletos possam ser rejeitados. Ataques de replay e entregas duplicadas acontecem em produção, então handlers idempotentes não são opcionais.

Visão geral de segurança do endpoint Push

Push introduz risco de SSRF no servidor quando clientes maliciosos registram URLs internas, e risco de impersonação no cliente quando POSTs falsos chegam ao webhook. Mitigações incluem allowlists de URL, verificação de propriedade, JWTs assinados com JWKS, verificações de timestamp e validação do token de configuração. O modelo de ameaça completo, camadas de identidade e controles de gateway estão em Segurança de Agentes A2A e MCP: Identidade, Delegação e Trilhas de Auditoria; até que você o leia, trate a verificação de webhook com a mesma seriedade que callbacks de pagamento.

Padrões de Fluxo de Trabalho Assíncrono A2A

Envio de tarefa Fire-and-follow

O cliente envia uma tarefa, recebe um ID de tarefa imediatamente e desconecta, depois consulta GetTask mais tarde ou aguarda push. Este é o padrão padrão para pipelines serverless e em lote, mas você deve persistir o ID da tarefa em armazenamento durável antes de confirmar ao usuário, porque invocações serverless que esquecem o ID perdem o trabalho.

Retomando uma tarefa após input_required

Após input_required, o usuário envia uma nova mensagem contra a mesma tarefa e o agente transiciona de volta para working. Projete mensagens para que o contexto de retomada seja explícito, porque “Aprovado: prosseguir com fornecedor X” supera um simples “sim” quando você precisa auditar o que foi aprovado seis horas depois.

Delegação A2A encadeada com artefatos intermediários

Considere um fluxo de trabalho de pesquisa onde um orquestrador possui a Tarefa T1 e delega recuperação, sumarização e verificação para agentes especialistas, cada um com seu próprio ID de tarefa e artefatos ao longo do caminho.

Cada salto tem seu próprio ID de tarefa e máquina de estados, então o orquestrador deve fazer streaming ou polling de tarefas downstream independentemente, persistir artefatos intermediários antes de iniciar o próximo salto, e falhar graciosamente se T3 completar mas T4 rejeitar o rascunho. Padrões de Orquestração Multi-Agentes cobre a escolha de topologia quando esses especialistas rodam como serviços separados em vez de em um único runtime. Progresso parcial é valioso, e uma verificação falha não deve deletar um rascunho utilizável sem um motivo claro.

Armazenamento durável de tarefas para conclusão atrasada

O estado da tarefa e artefatos devem sobreviver a reinícios de processo. Se seu agente roda no Kubernetes, assuma que pods morrem no meio da tarefa e faça backup dos registros de tarefa e blobs de artefato para uma loja que o container do agente não possui exclusivamente.

Tratamento de Falhas para Fluxos de Trabalho A2A de Longa Duração

Fluxos de trabalho de longa duração falham de maneiras previsíveis através de timeouts, retries, artefatos parciais e cancelamento inseguro, e cada um precisa de uma política explícita em vez de tratamento ad hoc no código do cliente.

Orçamentos de timeout por salto e end-to-end

Defina timeouts em dois níveis: um máximo por salto para uma tarefa de agente antes de escalonamento ou cancelamento, e um máximo end-to-end para o fluxo de trabalho visível ao usuário. Um agente de recuperação que fica travado não deve bloquear todo o orquestrador até que o navegador do usuário tenha timeout.

Retries e idempotência para tarefas A2A

Retries sem idempotência duplicam efeitos colaterais como cobranças duplicadas, tickets duplicados e e-mails repetidos. Use IDs de mensagem de cliente estáveis ou chaves de idempotência onde o protocolo permitir, e para mutações de negócio alinhe com Idempotência em Sistemas Distribuídos que Realmente Funciona. Faça retry apenas em falhas transitórias como falhas de rede ou 503s, e não faça retry cegamente em rejected ou falhas de política, porque você amplificará o custo e irritará agentes downstream.

Políticas de recuperação de artefatos parciais

Quando uma tarefa falha após produzir artefatos parciais, defina se você expõe saída parcial ao usuário com um rótulo claro de “incompleto”, permite retomar do último checkpoint bom, ou descarta a saída parcial quando ela poderia enganar em contextos médicos, legais ou financeiros.

Cancelamento seguro através de cadeias de delegação

Cancele tarefas downstream quando um usuário upstream aborta, use um grafo de delegação para que o cancelamento se propague, e registre tarefas canceladas que já incorreram em custo, porque equipes financeiras percebem.

Observabilidade para Fluxos de Trabalho A2A Assíncronos

Você não pode debugar trabalho assíncrono multi-agente a menos que possa rastreá-lo através de limites, o que significa correlacionar identificadores em cada salto em vez de confiar em logs não estruturados. Campos de correlação mínimos incluem um ID de trace por fluxo de trabalho iniciado pelo usuário, um ID de tarefa por tarefa de agente incluindo filhos delegados, um ID de agente para o Agent Card ou serviço que manipulou o salto, e um ID de tarefa pai que liga cadeias de delegação.

Registre toda transição de estado com timestamps, e registre eventos de criação de artefato com tamanho e hash em vez de necessariamente conteúdo completo quando políticas de PII se aplicam. Atribua custo e latência por salto, porque fluxos de trabalho multi-agentes escondem o gasto de tokens até que a conta chegue e rótulos de custo por tarefa tornam “qual especialista é caro?” respondível. Para métricas, backends de tracing e padrões de instrumentação específicos de LLM, consulte Observabilidade para Sistemas de LLM e o pilar mais amplo de Observabilidade para como esses sinais se encaixam em uma stack de telemetria de produção. Quando um usuário pergunta “por que o agente fez isso?”, sua resposta deve ser um trace abrangendo orquestrador, saltos A2A, chamadas de ferramentas MCP e qualquer pausa input_required, em vez de um ombro e um grep de log.

Checklist de Produção para Streaming e Tarefas Assíncronas A2A

Antes de entregar caminhos A2A de longa duração para produção, verifique as seguintes áreas.

Agent Card e capacidades

• capabilities.streaming reflete o suporte real a SSE
• Suporte a notificações push documentado se implementado
• Habilidades que requerem aprovação humana documentam comportamento esperado de input_required

Modos de Cliente

• Cliente SSE lida com reassinatura via SubscribeToTask
• Intervalo de polling faz backoff sob carga
• Webhook Push verifica autenticidade e rejeita eventos obsoletos

Durabilidade

• Estado da tarefa sobrevive a reinícios do processo do agente
• Artefatos armazenados fora do filesystem efêmero do container
• Artefatos intermediários disponíveis para recuperação parcial

Falha e política

• Orçamentos de timeout por salto e end-to-end definidos
• Retries idempotentes para operações mutantes
• Cancelamento se propaga através de arestas de delegação

Observabilidade

• ID de trace + ID de tarefa + ID de agente em cada salto
• Transições de estado registradas
• Atribuição de custo por tarefa ou por agente

Testes de carga

• SSE através do seu proxy reverso (buffering quebra streams)
• Tarefas longas concorrentes sem vazamentos de memória em conexões abertas
• Tratamento de inundação de Push sem sobrecarga de webhook

Conclusão

O valor do A2A se mostra mais claramente quando o trabalho não se encaixa em uma única chamada de API síncrona, porque streaming, tarefas assíncronas, notificações push e estados de tarefa explícitos são como o protocolo lida com cargas de trabalho reais de agentes, como pesquisa, delegação, aprovações e artefatos grandes, sem fingir que tudo completa em uma única viagem de ida e volta HTTP. Comece com o modo mais simples que funcione, adicione SSE quando os usuários precisarem de progresso ao vivo, adicione push quando as conexões não puderem permanecer abertas, trate input_required como uma ferramenta de design de primeira classe em vez de uma falha, e instrumente cada salto para que fluxos de trabalho assíncronos multi-agentes não ultrapassem sua capacidade de explicá-los.

Perguntas Frequentes

Quando você deve usar streaming A2A em vez de polling? Use streaming quando o cliente puder manter uma conexão HTTP aberta e você precisar de atualizações de progresso de baixa latência ou artefatos incrementais. Use polling quando as conexões forem instáveis, os clientes forem orientados a lote, ou você só precisar de verificações de status periódicas em tarefas de longa duração.

O que input_required significa em uma tarefa A2A? É um estado de pausa onde o agente precisa de mais informações ou aprovação humana. Projete UX e timeouts em torno dele explicitamente em vez de tratá-lo como um erro.

Como as notificações push A2A funcionam? Registre um PushNotificationConfig com um webhook HTTPS. O servidor faz POST em atualizações significativas; o cliente chama GetTask para recuperar o estado completo e artefatos.

Como você deve fazer retry em tarefas A2A falhas? Faça retry em falhas transitórias com chaves de idempotência, respeite orçamentos de timeout e não faça retry cegamente em estados terminais como rejeitados ou falhas de política.

O que você deve registrar para fluxos de trabalho A2A de longa duração? Correlacione ID de trace, ID de tarefa e ID de agente através dos saltos. Registre transições de estado, artefatos, delegação, aprovações e custo por etapa para que você possa reconstruir o fluxo de trabalho completo.

Fontes

• Protocolo A2A – Streaming e Operações Assíncronas: https://a2a-protocol.org/latest/topics/streaming-and-async/
• Protocolo A2A – Visão geral da especificação: https://a2a-protocol.org/latest/specification/