Streaming A2A et tâches asynchrones pour les flux de travail d'agents de longue durée

La plupart des démonstrations d’agents IA se comportent encore comme des complétions de chat avec des étapes supplémentaires : vous envoyez une invite, attendez quelques secondes et recevez une réponse en une seule fois.

Le travail réel des agents ne correspond souvent pas à ce modèle. La recherche, la révision de code, l’analyse des approvisionnements, l’investigation d’incidents et la planification en plusieurs étapes peuvent s’étendre sur des minutes ou des heures, et ils peuvent nécessiter des clarifications en cours de route, diffuser des résultats partiels, déléguer à un autre agent et produire des fichiers plutôt qu’une simple réponse textuelle. C’est là que le modèle asynchrone du protocole A2A prend de l’importance au sein du cluster Systèmes IA plus large, car A2A traite le travail de longue durée comme une Tâche avec un cycle de vie, plutôt que comme une réponse HTTP ponctuelle. Les clients peuvent rester connectés via les événements envoyés par le serveur (SSE), interroger l’état de la tâche ou enregistrer des webhooks de poussée lorsqu’ils ne peuvent pas maintenir une connexion ouverte.

Cet article couvre la conception opérationnelle de ces flux de travail, y compris quand utiliser la diffusion, l’interrogation ou la poussée, comment input_required s’intègre dans les flux humains dans la boucle, la gestion des erreurs et ce qu’il faut instrumenter en production. Pour les cartes d’agent, les messages, les parties et le modèle de tâche complet, consultez Qu’est-ce que le protocole A2A ? Cartes d’agent et tâches expliquées.

Pourquoi les tâches d’agents A2A de longue durée nécessitent une conception asynchrone

Le modèle mental de requête/réponse synchrone ne tient pas la route dès que le travail des agents s’étend sur des outils, la délégation, les approbations et les grands artefacts. Une tâche d’agent peut appeler plusieurs serveurs MCP en interne, déléguer des sous-tâches à un autre agent via A2A, attendre l’approbation humaine, générer de grands artefacts par morceaux, échouer en cours de route et nécessiter une récupération partielle, et accumuler le coût des jetons sur plusieurs sauts. Les API HTTP peuvent approximer cela avec des délais d’expiration, des tâches en arrière-plan et des points de terminaison d’état ad hoc, mais A2A intègre l’identité et l’état de la tâche dans le protocole afin que les clients et les passerelles puissent raisonner sur le travail de manière cohérente. Pour savoir comment ces couches s’intègrent dans un assistant de production avant d’ajouter des limites A2A asynchrones, consultez Architecture des assistants IA : LLM, mémoire, outils, routage, observabilité.

Mon biais est pratique : ne créez pas une Tâche pour tout, car un résumé d’une ligne n’a pas besoin d’un cycle de vie. Utilisez une Tâche lorsque le travail est étatique, auditable, de longue durée, producteur d’artefacts ou peut nécessiter une entrée en cours de route. La règle empirique de l’explicatif tient toujours : les interactions simples peuvent retourner un Message, tandis que les travaux complexes devraient retourner une Tâche.

Cycle de vie des tâches A2A et transitions d’état

Une tâche A2A passe par des états que les clients peuvent interroger à tout moment. Le nommage exact varie légèrement selon l’implémentation, mais le modèle est stable entre les serveurs qui suivent le protocole.

L’état submitted signifie que le client a envoyé du travail et que l’agent l’a accepté ou mis en file d’attente. Dans l’état working, l’agent traite activement, ce qui peut inclure des appels d’outils, de la délégation ou la diffusion d’une sortie partielle. L’état input_required indique que l’agent a mis en pause car il a besoin de plus d’informations, de clarification ou d’une approbation humaine, et ce n’est pas un état d’échec. completed est un succès terminal avec des artefacts disponibles ; failed est une erreur terminale dont les détails et les artefacts partiels dépendent de l’implémentation ; canceled signifie qu’un client, une passerelle ou un appelant autorisé a arrêté la tâche ; et rejected signifie que l’agent a refusé la tâche en raison de la politique, d’un désalignement de capacités ou d’authentification.

Quand input_required met en pause versus fait échouer un flux de travail

Considérez input_required comme une pause délibérée, pas comme une exception. L’agent vous dit qu’il ne peut pas avancer sans quelque chose de votre part, qu’il s’agisse d’un paramètre manquant, d’une confirmation de politique ou d’une signature de gestionnaire pour une action à haut risque. Un flux de travail échoue lorsque la tâche atteint failed ou rejected, ou lorsqu’un appelant dépasse un délai d’expiration en attendant une entrée qui n’arrive jamais, vous devez donc concevoir des délais d’expiration explicites pour les étapes humaines plutôt que de laisser les approbations indéfiniment.

Une approbation qui attend trois jours sans escalade est un flux de travail bloqué, pas un patient, et les flux de travail bloqués encombrent les magasins de tâches tout en rendant les tableaux de bord d’observabilité plus difficiles à lire.

Qui peut annuler une tâche A2A

L’autorité d’annulation doit être définie lors de la conception plutôt que débattue pendant un incident. Le client peut généralement annuler les tâches qu’il a créées ; une passerelle peut annuler au nom des locataires, des violations de politique ou des limites de budget ; et un agent en amont peut annuler le travail délégué lorsqu’il orchestre via A2A si le protocole et la politique le permettent. Journalisez qui a annulé et pourquoi, car dans les chaînes multi-agents, le travail orphelin est une source commune de factures de jetons surprises.

Humain dans la boucle avec les états de tâche input_required

input_required est l’une des fonctionnalités de conception les plus sous-utilisées d’A2A, et de nombreuses équipes le traitent comme un code d’erreur alors qu’il s’agit en réalité d’un état de flux de travail de première classe. En production, vous rencontrerez des cas où l’agent devrait s’arrêter, comme dépenser du budget sur une demande ambiguë, exécuter une action irréversible, accéder à des données sensibles sans confirmation d’étendue, ou déléguer à un spécialiste qui a besoin d’une intention utilisateur explicite. Modélisez-les comme des transitions délibérées vers input_required, avec un message clair expliquant ce qui est nécessaire.

Flux d’approbation pour la délégation A2A risquée

Lorsque l’Agent A délègue à l’Agent B via A2A et que l’Agent B entre dans input_required pour l’approbation humaine, trois systèmes doivent convenir de ce qui se passe ensuite. L’agent en aval met en pause et expose ce dont il a besoin, l’orchestrateur ou la passerelle présente cette pause à l’utilisateur, et la réponse de l’utilisateur reprend la tâche via un nouveau message. La comparaison A2A vs MCP explique pourquoi la délégation au-delà des limites des agents est un problème différent de l’accès aux outils, et pourquoi la sémantique d’approbation appartient à la couche de tâche plutôt qu’à l’intérieur d’un seul appel MCP. N’autorisez pas automatiquement en silence parce que l’UX est inconfortable, car les erreurs coûteuses proviennent généralement de raccourcis de commodité plutôt que de modèles manquants.

Modèles UX pour les tâches A2A en pause

Attente bloquante signifie que l’interface utilisateur affiche un indicateur de progression ou une carte d’approbation jusqu’à ce que la tâche quitte input_required, ce qui fonctionne bien pour les étapes humaines courtes. Attente non bloquante signifie que le client enregistre l’ID de tâche, laisse l’utilisateur continuer ailleurs et utilise l’interrogation ou la poussée pour notifier lorsque l’entrée est à nouveau nécessaire, ce qui est requis pour les mobiles, les approbations liées par e-mail ou les assistants multi-onglets. Délai d’expiration lorsque les humains sont lents signifie définir un SLA par étape et, après N heures, passer à failed ou escalader vers une autre file d’attente, car les attentes illimitées encombrent les magasins de tâches et confondent les tableaux de bord d’observabilité.

Comment une passerelle A2A gère input_required

Si vous exécutez une passerelle A2A, décidez si elle transmet les événements input_required de manière transparente, agrège les pauses de plusieurs agents en aval en une seule invite utilisateur, ou impose que certaines compétences nécessitent toujours une approbation avant de quitter input_required. L’authentification et la politique pour les actions approuvées relèvent d’un article de sécurité dédié ; pour l’instant, supposez que chaque tâche reprise devrait porter la même identité et le même périmètre utilisateur que la demande originale.

Choisir entre Sync, diffusion SSE, interrogation ou notifications push

A2A prend en charge plusieurs modes d’interaction, et le bon choix dépend des capacités du client et des besoins de latence plutôt que du mode qui semble le plus moderne.

Lisez d’abord les drapeaux de capacité de la carte Agent

Avant de choisir un mode, lisez la Carte Agent de l’agent, car la diffusion nécessite capabilities.streaming: true et le support des notifications push est annoncé séparément. Les clients qui supposent que chaque agent diffuse vont échouer contre les implémentations minimales, donc la négociation n’est pas cérémonielle : elle empêche les erreurs d’exécution lorsqu’un agent spécialisé ne prend en charge que les vérifications d’état basées sur l’interrogation.

Quand utiliser l’interrogation côté assistant autour de A2A

Votre runtime d’assistant peut envelopper l’interrogation de tâches A2A dans une boucle de planificateur plutôt que d’exposer les détails bruts du protocole à l’utilisateur. Ce modèle se superpose aux agents d’interrogation généraux, qui sont des processus en arrière-plan qui se réveillent, vérifient l’état et agissent. Pour la planification durable, l’idempotence et les modèles de file d’attente en dehors de A2A spécifiquement, consultez Agents d’interrogation dans les assistants IA : 11 modèles d’implémentation. Utilisez l’interrogation de l’assistant lorsque vous orchestrez de nombreuses tâches A2A depuis un plan de contrôle unique, et utilisez la diffusion ou la poussée A2A native lorsque le client se connecte directement à la limite de l’agent.

Diffusion des événements envoyés par le serveur (SSE) A2A

SSE est le canal temps réel principal d’A2A. Le client appelle SendStreamingMessage, ouvre une connexion HTTP et reçoit une réponse text/event-stream jusqu’à ce que la tâche atteigne un état terminal ou interrompu. La charge utile de chaque événement est façonnée en JSON-RPC, et les types de résultats typiques incluent un instantané Task, un TaskStatusUpdateEvent pour les transitions de cycle de vie et les messages intermédiaires de l’agent, et un TaskArtifactUpdateEvent pour la livraison d’artefacts en morceaux avec les indices append et lastChunk pour la réassemblage.

Mises à jour de progression en streaming et artefacts partiels

La diffusion brille lorsque les utilisateurs devraient voir le travail se dérouler, que cela signifie des compteurs d’étapes (“3 sur 7 sources examinées”), la génération de texte partielle, des morceaux de fichiers incrémentiels pour les grands rapports, ou des transitions d’état de working à input_required sans interrogation. Concevez l’interface utilisateur autour des types d’événements plutôt que autour d’un seul bloc final, car si vous n’affichez la sortie que lorsque completed arrive, vous pourriez aussi bien interroger.

Chutes de connexion SSE et réabonnement

Les réseaux tombent, les ordinateurs portables se mettent en veille, et les équilibreurs de charge mettent en veille les connexions SSE, donc les longs flux ont besoin d’une logique de récupération plutôt que d’hypothèses optimistes. A2A fournit SubscribeToTask afin que les clients puissent se reconnecter à un flux de tâche en cours, et votre SDK client devrait persister taskId localement, détecter la fermeture du flux avant l’état terminal, se réabonner avec réessais exponentiels et dédoubler les événements si le serveur rejoue un état chevauchant. Sans logique de réabonnement, les tâches longues semblent fragiles en production même lorsque le backend de l’agent est sain.

Notifications push et webhooks A2A

La poussée convient aux scénarios où SSE est un mauvais match, tels que les applications mobiles en arrière-plan, les gestionnaires serverless, ou les tâches qui s’exécutent pendant des heures ou des jours. Le client fournit un PushNotificationConfig avec une url (webhook HTTPS côté client), un token optionnel pour valider les POST entrants, et des détails authentication optionnels pour la façon dont le serveur A2A s’authentifie auprès du webhook. La configuration peut accompagner l’appel initial SendMessage ou SendStreamingMessage, ou être ajoutée plus tard via CreateTaskPushNotificationConfig pour une tâche existante.

Lorsqu’une mise à jour significative se produit, le serveur A2A POSTe vers le webhook et le client appelle généralement GetTask avec le taskId notifié pour récupérer la tâche complète mise à jour et les artefacts. La poussée est un signal, pas un transport de charge utile complète.

Quand la poussée bat une connexion SSE ouverte

Privilégiez la poussée lorsque le client ne peut pas maintenir SSE (mobile, fonctions edge), lorsque les mises à jour sont rares et basées sur des jalons plutôt que jeton par jeton, ou lorsque vous voulez que le serveur réveille un moteur de flux de travail déconnecté. Privilégiez SSE lorsque les utilisateurs surveillent la progression en direct, lorsque les artefacts sont diffusés en de nombreux petits morceaux, ou lorsque la latence inférieure à quelques secondes est importante.

Corrélations des notifications push aux tâches A2A

Chaque gestionnaire push devrait journaliser et propager le taskId, un ID de trace ou de corrélation de la demande originale, le type d’événement ou la transition d’état, et un horodatage de la notification afin que les événements périmés puissent être rejetés. Les attaques de rejouement et les livraisons dupliquées se produisent en production, donc les gestionnaires idempotents ne sont pas optionnels.

Aperçu de la sécurité des points de terminaison push

La poussée introduit un risque SSRF sur le serveur lorsque des clients malveillants enregistrent des URL internes, et un risque d’usurpation d’identité sur le client lorsque de faux POST arrivent au webhook. Les atténuations incluent les listes blanches d’URL, la vérification de propriété, les JWT signés avec JWKS, les vérifications d’horodatage et la validation du jeton de configuration. Le modèle de menace complet, les couches d’identité et les contrôles de passerelle se trouvent dans Sécurité des agents A2A et MCP : Identité, délégation et traçabilité ; jusqu’à ce que vous l’ayez lu, traitez la vérification du webhook avec la même sérieux que les rappels de paiement.

Modèles de flux de travail A2A asynchrones

Soumission de tâche en mode “tirer et suivre”

Le client soumet une tâche, reçoit un ID de tâche immédiatement et se déconnecte, puis interroge plus tard GetTask ou attend la poussée. C’est le modèle par défaut pour les pipelines serverless et par lots, mais vous devez persister l’ID de tâche dans un stockage durable avant d’accuser réception à l’utilisateur, car les invocations serverless qui oublient l’ID perdent le travail.

Reprise d’une tâche après input_required

Après input_required, l’utilisateur envoie un nouveau message contre la même tâche et l’agent revient à working. Concevez les messages de sorte que le contexte de reprise soit explicite, car “Approuvé : procéder avec le fournisseur X” bat un simple “oui” lorsque vous devez auditer ce qui a été approuvé six heures plus tard.

Délégation A2A en chaîne avec artefacts intermédiaires

Considérez un flux de travail de recherche où un orchestrateur possède la tâche T1 et délègue la récupération, la résumation et la vérification à des agents spécialisés, chacun avec son propre ID de tâche et des artefacts en cours de route.

Chaque saut a son propre ID de tâche et machine d’état, donc l’orchestrateur devrait diffuser ou interroger les tâches en aval indépendamment, persister les artefacts intermédiaires avant de commencer le saut suivant, et échouer gracieusement si T3 est complété mais T4 rejette le brouillon. Modèles d’orchestration multi-agents couvre le choix de topologie lorsque ces spécialistes s’exécutent comme des services séparés plutôt que dans un seul runtime. La progression partielle est précieuse, et une vérification échouée ne devrait pas supprimer un brouillon utilisable sans raison claire.

Stockage de tâche durable pour l’achèvement différé

L’état de la tâche et les artefacts doivent survivre aux redémarrages de processus. Si votre agent s’exécute dans Kubernetes, supposez que les pods meurent en cours de tâche et faites remonter les enregistrements de tâche et les blobs d’artefacts vers un magasin que le conteneur d’agent ne possède pas exclusivement.

Gestion des erreurs pour les flux de travail A2A de longue durée

Les flux de travail de longue durée échouent de manière prévisible via des délais d’expiration, des tentatives, des artefacts partiels et une annulation non sécurisée, et chacun a besoin d’une politique explicite plutôt que d’une gestion ad hoc dans le code client.

Budgets de délai d’expiration par saut et bout-en-bout

Définissez des délais d’expiration à deux niveaux : un maximum par saut pour une tâche d’agent unique avant l’escalade ou l’annulation, et un maximum bout-en-bout pour le flux de travail visible par l’utilisateur. Un agent de récupération qui bloque ne devrait pas bloquer l’orchestrateur entier jusqu’à ce que le navigateur de l’utilisateur expire.

Tentatives et idempotence pour les tâches A2A

Les tentatives sans idempotence dupliquent les effets secondaires tels que les doubles facturations, les tickets dupliqués et les e-mails répétés. Utilisez des IDs de message client stables ou des clés d’idempotence là où le protocole le permet, et pour les mutations commerciales, alignez-vous avec L’idempotence dans les systèmes distribués qui fonctionne vraiment. Réessayez uniquement les échecs transitoires comme les perturbations réseau ou les 503, et ne réessayez pas les échecs rejected ou de politique aveuglément car vous amplifierez le coût et ennuierez les agents en aval.

Politiques de récupération des artefacts partiels

Lorsqu’une tâche échoue après avoir produit des artefacts partiels, définissez si vous exposez la sortie partielle à l’utilisateur avec une étiquette claire “incomplet”, permettez la reprise depuis le dernier bon point de contrôle, ou jetez la sortie partielle lorsqu’elle pourrait tromper dans des contextes médicaux, juridiques ou financiers.

Annulation sécurisée à travers les chaînes de délégation

Annulez les tâches en aval lorsque l’utilisateur en amont abandonne, utilisez un graphe de délégation pour que l’annulation se propage, et journalisez les tâches annulées qui ont déjà entraîné des coûts car les équipes financières remarquent.

Observabilité pour les flux de travail A2A asynchrones

Vous ne pouvez pas déboguer le travail asynchrone multi-agent à moins de pouvoir le tracer à travers les limites, ce qui signifie corréler les identifiants à chaque saut plutôt que de vous fier à des journaux non structurés. Les champs de corrélation minimum incluent un ID de trace par flux de travail initié par l’utilisateur, un ID de tâche par tâche d’agent y compris les enfants délégués, un ID d’agent pour la Carte Agent ou le service qui a géré le saut, et un ID de tâche parent qui lie les chaînes de délégation.

Journalisez chaque transition d’état avec des horodatages, et journalisez les événements de création d’artefact avec la taille et le hash plutôt que nécessairement le contenu complet lorsque les politiques PII s’appliquent. Attribuez le coût et la latence par saut, car les flux de travail multi-agents masquent la dépense de jetons jusqu’à ce que la facture arrive et les étiquettes de coût par tâche rendent “quel spécialiste est cher ?” répondable. Pour les métriques, les backends de traçage et les modèles d’instrumentation spécifiques aux LLM, consultez Observabilité pour les systèmes LLM et le pilier plus large Observabilité pour savoir comment ces signaux s’intègrent dans une pile de télémétrie de production. Lorsqu’un utilisateur demande “pourquoi l’agent a-t-il fait cela ?”, votre réponse devrait être une trace couvrant l’orchestrateur, les sauts A2A, les appels d’outils MCP et toutes les pauses input_required plutôt qu’un haussement d’épaules et un grep de journal.

Liste de contrôle de production pour la diffusion et les tâches asynchrones A2A

Avant de livrer les chemins A2A de longue durée en production, vérifiez les domaines suivants.

Carte Agent et capacités

• capabilities.streaming reflète le support SSE réel
• Support des notifications push documenté si implémenté
• Les compétences nécessitant une approbation humaine documentent le comportement input_required attendu

Modes client

• Le client SSE gère le réabonnement via SubscribeToTask
• L’intervalle d’interrogation rétrocede sous charge
• Le webhook push vérifie l’authenticité et rejette les événements périmés

Durabilité

• L’état de la tâche survit aux redémarrages du processus de l’agent
• Artefacts stockés en dehors du système de fichiers conteneur éphémère
• Artefacts intermédiaires disponibles pour la récupération partielle

Échec et politique

• Budgets de délai d’expiration par saut et bout-en-bout définis
• Tentatives idempotentes pour les opérations mutantes
• L’annulation se propage à travers les arêtes de délégation

Observabilité

• ID de trace + ID de tâche + ID d’agent à chaque saut
• Transitions d’état journalisées
• Attribution des coûts par tâche ou par agent

Tests de charge

• SSE à travers votre proxy inverse (la mise en mémoire tampon brise les flux)
• Tâches longues concurrentes sans fuites de mémoire sur les connexions ouvertes
• Gestion des inondations de poussée sans surcharge du webhook

Conclusion

La valeur d’A2A apparaît le plus clairement lorsque le travail ne correspond pas à un seul appel d’API synchrone, car la diffusion, les tâches asynchrones, les notifications push et les états de tâche explicites sont la façon dont le protocole gère les charges de travail réelles des agents telles que la recherche, la délégation, les approbations et les grands artefacts sans prétendre que tout se complète en une seule ronde HTTP. Commencez par le mode le plus simple qui fonctionne, ajoutez SSE lorsque les utilisateurs ont besoin d’une progression en direct, ajoutez la poussée lorsque les connexions ne peuvent pas rester ouvertes, traitez input_required comme un outil de conception de première classe plutôt qu’une défaillance, et instrumentez chaque saut afin que les flux de travail asynchrones multi-agents ne dépassent pas votre capacité à les expliquer.

Foire aux questions

Quand devriez-vous utiliser la diffusion A2A au lieu de l’interrogation ? Utilisez la diffusion lorsque le client peut maintenir une connexion HTTP ouverte et que vous avez besoin de mises à jour de progression à faible latence ou d’artefacts incrémentiels. Utilisez l’interrogation lorsque les connexions sont peu fiables, les clients sont orientés vers les lots, ou que vous n’avez besoin que de vérifications d’état périodiques sur des tâches de longue durée.

Que signifie input_required dans une tâche A2A ? C’est un état de pause où l’agent a besoin de plus d’informations ou d’une approbation humaine. Concevez l’UX et les délais d’expiration autour de cela explicitement plutôt que de le traiter comme une erreur.

Comment fonctionnent les notifications push A2A ? Enregistrez un PushNotificationConfig avec un webhook HTTPS. Le serveur POSTe sur les mises à jour significatives ; le client appelle GetTask pour récupérer l’état complet et les artefacts.

Comment devriez-vous réessayer les tâches A2A échouées ? Réessayez les échecs transitoires avec des clés d’idempotence, respectez les budgets de délai d’expiration et ne réessayez pas aveuglément les états terminaux comme rejeté ou échecs de politique.

Que devriez-vous journaliser pour les flux de travail A2A de longue durée ? Corrélez l’ID de trace, l’ID de tâche et l’ID d’agent à travers les sauts. Journalisez les transitions d’état, les artefacts, la délégation, les approbations et le coût par étape afin que vous puissiez reconstruire le flux de travail complet.

Sources

• Protocole A2A – Diffusion et opérations asynchrones : https://a2a-protocol.org/latest/topics/streaming-and-async/
• Protocole A2A – Aperçu de la spécification : https://a2a-protocol.org/latest/specification/