A2A-streaming en asynchrone taken voor langlopende agent-workflows

De meeste AI-agentdemonstraties gedragen zich nog steeds als chat-completies met extra stappen: je stuurt een prompt, wacht enkele seconden en ontvangt een antwoord in één reactie.

Echt agentwerk past vaak niet in dat patroon. Onderzoek, code reviews, inkoopanalyses, incidentonderzoek en meervoudige planning kunnen minuten of uren duren, halverwege verduidelijking nodig hebben, gedeeltelijke resultaten streamen, taken delegeren aan een andere agent en bestanden produceren in plaats van een enkel tekstantwoord. Daar komt het asynchrone model van het A2A-protocol binnen het bredere AI-systemen cluster om de hoek kijken, omdat A2A langlopend werk behandelt als een Taak met een levenscyclus in plaats van een eenmalige HTTP-reactie. Clients kunnen verbonden blijven via Server-Sent Events (SSE), de taakstatus pollsen of push-webhooks registreren wanneer ze geen verbinding open kunnen houden.

Dit artikel behandelt operationeel ontwerp voor deze workflows, inclusief wanneer je moet streamen versus pollsen versus pushen, hoe input_required past in mens-in-de-loop-flows, foutafhandeling en wat je in productie moet instrumenteren. Voor Agent Cards, berichten, onderdelen en het volledige taakmodel, zie Wat is het A2A-protocol? Agent Cards en Taken uitgelegd.

Waarom langlopende A2A-agenttaken asynchroon ontwerp nodig hebben

Een synchroon request/response-mental model valt snel in duigen zodra agentwerk tools, delegatie, goedkeuringen en grote artefacten omvat. Een agenttaak kan intern meerdere MCP-servers aanroepen, subwerk delegeren aan een andere agent via A2A, wachten op menselijke goedkeuring, grote artefacten in chunks genereren, halverwege falen en gedeeltelijk herstel nodig hebben, en tokenkosten accumuleren over meerdere hops. HTTP-API’s kunnen dit benaderen met time-outs, achtergrondjobs en ad-hoc statusendpoints, maar A2A bakt taakidentiteit en status in het protocol zodat clients en gateways consistent kunnen redeneren over werk. Voor hoe deze lagen passen binnen een productie-assistent voordat je asynchrone A2A-grenzen toevoegt, zie AI-Assistent Architectuur: LLM, Geheugen, Tools, Routing, Observability.

Mijn bias is praktisch: maak geen Taak voor alles, omdat een éénregelsamenvatting geen levenscyclus nodig heeft. Gebruik een Taak wanneer werk stateful is, auditabel, langlopend, artefacten produceert, of input nodig heeft tijdens het proces. De vuistregel uit de uitleg geldt nog steeds: eenvoudige interacties kunnen een Bericht retourneren, terwijl complex werk een Taak moet retourneren.

A2A Taaklevenscyclus en Statusovergangen

Een A2A-Taak beweegt door statussen die clients op elk moment kunnen opvragen. De exacte naamgeving varieert iets per implementatie, maar het model is stabiel over servers die het protocol volgen.

De ingediend status betekent dat de client werk heeft verzonden en de agent het heeft geaccepteerd of in de wachtrij heeft geplaatst. In aanhetwerken verwerkt de agent actief, wat toolaanroepen, delegatie of streaming van gedeeltelijke output kan omvatten. De inputvereist status geeft aan dat de agent is gepauzeerd omdat deze meer input, verduidelijking of menselijke goedkeuring nodig heeft, en het is geen foutstatus. Voltooid is terminale succes met beschikbare artefacten; gefaald is een terminale fout waarvan details en gedeeltelijke artefacten afhankelijk zijn van de implementatie; geannuleerd betekent dat een client, gateway of gemachtigde aanroeper de taak heeft gestopt; en afgewezen betekent dat de agent de taak weigerde vanwege beleid, capaciteitsmismatch of authenticatie.

Wanneer inputvereist een workflow pauzeert versus faalt

Behandel inputvereist als een bewuste pauze, niet als een uitzondering. De agent vertelt je dat deze niet kan doorgaan zonder iets van jou, of het nu een ontbrekende parameter is, een bevestiging van beleid, of een handtekening van een manager op een risicovolle actie. Een workflow faalt wanneer de taak gefaald of afgewezen bereikt, of wanneer een aanroeper een time-out overschrijdt terwijl hij wacht op input die nooit aankomt, dus je moet expliciete time-outs ontwerpen voor menselijke stappen in plaats van goedkeuringen onbepaald te laten wachten.

Een goedkeuring die drie dagen wacht zonder escalatie is een vastgelopen workflow, geen geduldige, en vastgelopen workflows verstoppen taakopslag en maken observability-dashboards moeilijker leesbaar.

Wie een A2A-taak kan annuleren

Annuleringautoriteit moet worden gedefinieerd tijdens het ontwerp, niet tijdens een incident. De client kan doorgaans taken annuleren die deze heeft gemaakt; een gateway kan namens tenants annuleren bij overtredingen van beleid of budgetlimieten; en een upstream-agent kan gedelegeerd werk annuleren bij orchestratie over A2A als het protocol en beleid het toestaan. Log wie heeft geannuleerd en waarom, omdat in multi-agent-ketens weeswerk een veelvoorkomende bron is van verrassende tokenrekeningen.

Mens-in-de-loop met inputvereist taakstatussen

inputvereist is een van de meest onderbenutte ontwerpfuncties van A2A, en veel teams behandelen het als een foutcode terwijl het eigenlijk een first-class workflowstatus is. In productie zul je gevallen tegenkomen waarin de agent moet stoppen, zoals budget besteden aan een ambigu verzoek, een onherroepelijke actie uitvoeren, toegang krijgen tot gevoelige data zonder scopebevestiging, of delegeren aan een specialist die expliciete gebruikersintentie nodig heeft. Model deze als bewuste overgangen naar inputvereist, met een duidelijk bericht dat uitlegt wat er nodig is.

Goedkeuringsflows voor riskante A2A-delegatie

Wanneer Agent A via A2A delegeert naar Agent B en Agent B inputvereist bereikt voor menselijke goedkeuring, moeten drie systemen het eens zijn over wat er daarna gebeurt. De downstream-agent pauzeert en exposeert wat deze nodig heeft, de orchestrator of gateway presenteert die pauze aan de gebruiker, en het antwoord van de gebruiker hervat de taak via een nieuw bericht. De vergelijking A2A vs MCP legt uit waarom delegatie over agentgrenzen een ander probleem is dan tooltoegang, en waarom goedkeuringssemantiek op de taaklaag moet behoren in plaats van binnen een enkele MCP-aanroep. Goedkeur niet stil automatisch omdat de UX onhandig is, omdat dure fouten meestal komen van gemaksshortcuts in plaats van van ontbrekende modellen.

UX-patronen voor gepauzeerde A2A-taken

Blokkerende wacht betekent dat de UI een spinner of goedkeuringskaart toont tot de taak inputvereist verlaat, wat goed werkt voor korte menselijke stappen. Niet-blokkerende wacht betekent dat de client de taak-ID registreert, de gebruiker ergens anders laat doorgaan, en polling of push gebruikt om te notify wanneer input weer nodig is, wat vereist is voor mobiel, e-mailgekoppelde goedkeuringen of multi-tab-assistents. Time-out wanneer mensen traag zijn betekent het definiëren van een SLA per stap en, na N uur, overgaan naar gefaald of escaleren naar een andere wachtrij, omdat onbegrensde wachttijden taakopslag verstoppen en observability-dashboards verwarren.

Hoe een A2A-gateway inputvereist behandelt

Als je een A2A-gateway draait, beslis dan of deze inputvereist-events transparant doorstuurt, pauzes van meerdere downstream-agents aggregatieert in één gebruikersprompt, of afdwingt dat bepaalde vaardigheden altijd goedkeuring vereisen voordat ze inputvereist verlaten. Auth en beleid voor goedgekeurde acties behoren in een apart beveiligingsartikel; ga nu uit dat elke hervatte taak dezelfde gebruikersidentiteit en scope moet dragen als het oorspronkelijke verzoek.

Kies tussen Sync, SSE-streaming, Polling of Push-meldingen

A2A ondersteunt meerdere interactiemodi, en de juiste keuze hangt af van clientcapaciteiten en latentiebehoeften in plaats van van welke modus het meest modern klinkt.

Lees eerst Agent Card-capaciteitsvlaggen

Voordat je een modus kiest, lees de Agent Card van de agent, omdat streaming capabilities.streaming: true vereist en push-meldingondersteuning apart wordt geadverteerd. Clients die aannemen dat elke agent streamt, zullen breken tegen minimale implementaties, dus onderhandeling is niet ceremonieel: het voorkomt runtime-fouten wanneer een specialistagent alleen poll-gebaseerde statuscontroles ondersteunt.

Wanneer assistant-side polling gebruiken rond A2A

Je assistant-runtime kan A2A-taakpolling omhullen in een scheduler-loop in plaats van ruwe protocoldetails aan de gebruiker te exposuren. Dat patroon overlapt met algemene polling-agents, die achtergrondprocessen zijn die wakker worden, status controleren en handelen. Voor duurzame scheduling, idempotentie en wachtrijpatronen buiten A2A specifiek, zie Polling Agents in AI-Assistents: 11 Implementatiepatronen. Gebruik assistant-polling wanneer je veel A2A-taken orchestreert vanuit een enkel controlepaneel, en gebruik native A2A-streaming of push wanneer de client direct verbinding maakt met de agentgrens.

A2A Server-Sent Events (SSE) Streaming

SSE is het primaire realtime-kanaal van A2A. De client roept SendStreamingMessage aan, opent een HTTP-verbinding en ontvangt een text/event-stream-reactie tot de taak een terminale of onderbroken status bereikt. Elke event-payload is JSON-RPC-vormig, en typische resultaattypes omvatten een Taak-snapshot, een TaskStatusUpdateEvent voor levenscyclusovergangen en tussentijdse agentberichten, en een TaskArtifactUpdateEvent voor chunked artefactlevering met append en lastChunk hints voor reconstructie.

Streaming voortgangupdates en gedeeltelijke artefacten

Streaming blinkt uit wanneer gebruikers werk moeten zien gebeuren, of het nu stapcounters zijn (“3 van 7 bronnen beoordeeld”), gedeeltelijke tekstgeneratie, incrementele bestandchunks voor grote rapporten, of statusovergangen van aanhetwerken naar inputvereist zonder polling. Ontwerp UI rond eventtypes in plaats van rond een enkele finale blob, want als je alleen output toont wanneer voltooid aankomt, kun je net zo goed pollsen.

SSE-verbindingen die vallen en herabonnement

Netwerken vallen, laptops slapen en loadbalancers idle-time-out SSE-verbindingen, dus lange streams hebben herstellogica nodig in plaats van optimistische aannames. A2A biedt SubscribeToTask zodat clients kunnen herconnecteren met een lopende taakstream, en je client-SDK moet taskId lokaal persistent maken, streamsluiting voor terminale status detecteren, herabonneren met backoff, en events de-dupliceren als de server overlappende status replayt. Zonder herabonnementslogica voelen lange taken fragiel aan in productie, zelfs wanneer de agentbackend gezond is.

A2A Push-meldingen en Webhooks

Push past bij scenario’s waar SSE een slechte match is, zoals mobiele apps op de achtergrond, serverless-handlers, of taken die uren of dagen duren. De client levert een PushNotificationConfig met een url (HTTPS-webhook aan de clientkant), een optionele token voor het valideren van inkomende POSTs, en optionele authentication-details voor hoe de A2A-server authenticatie uitvoert bij de webhook. Configuratie kan meereizen met de initiële SendMessage of SendStreamingMessage-aanroep, of later worden toegevoegd via CreateTaskPushNotificationConfig voor een bestaande taak.

Wanneer een significante update plaatsvindt, POST de A2A-server naar de webhook en de client roept typisch GetTask aan met de gemelde taskId om de volledige bijgewerkte Taak en artefacten op te halen. Push is een signaal, geen volledige payloadtransport.

Wanneer push wint van een open SSE-verbinding

Voorkeur push wanneer de client geen SSE kan handhaven (mobiel, edge-functies), wanneer updates zeldzaam zijn en mijlpuntgebaseerd in plaats van token-per-token, of wanneer je wilt dat de server een gescheiden workflow-engine wakker maakt. Voorkeur SSE wanneer gebruikers live voortgang bekijken, wanneer artefacten streamen in veel kleine chunks, of wanneer latentie onder een paar seconden belangrijk is.

Push-meldingen correleren met A2A-taken

Elke push-handler moet loggen en propagatie van de taskId, een trace- of correlatie-ID van het oorspronkelijke verzoek, het eventtype of statusovergang, en een timestamp van de melding zodat verouderde events kunnen worden afgewezen. Replay-aanvallen en dubbele leveringen gebeuren in productie, dus idempotente handlers zijn niet optioneel.

Push-endpoint beveiligingsoverzicht

Push introduceert SSRF-risico op de server wanneer kwaadwillende clients interne URLs registreren, en impersonatie-risico op de client wanneer valse POSTs aankomen bij de webhook. Mitigaties omvatten URL-toestemmingen, eigenaarsverificatie, signed JWTs met JWKS, timestampcontroles en validatie van de config-token. Het volledige threatmodel, identiteitslagen en gatewaycontroles staan in A2A en MCP Agent Beveiliging: Identiteit, Delegatie en Audit Trails; tot je dat hebt gelezen, behandel webhookverificatie met dezelfde ernst als betalingscallbacks.

Asynchrone A2A Workflowpatronen

Fire-and-follow taakinleiding

De client leidt een taak in, ontvangt direct een taak-ID en disconnect, en pollst later GetTask of wacht op push. Dit is het standaardpatroon voor serverless en batchpipelines, maar je moet de taak-ID in duurzame opslag persistent maken voordat je de gebruiker acknowledge, omdat serverless-invocaties die de ID vergeten het werk verliezen.

Taak hervatten na inputvereist

Na inputvereist stuurt de gebruiker een nieuw bericht tegen dezelfde taak en de agent overgaat terug naar aanhetwerken. Ontwerp berichten zodat hervattingcontext expliciet is, want “Goedgekeurd: doorgaan met leverancier X” wint van een kale “ja” wanneer je moet auditen wat zes uur later is goedgekeurd.

Gekoppelde A2A-delegatie met tussenliggende artefacten

Overweeg een researchworkflow waar een orchestrator Taak T1 bezit en retrieval, samenvatting en verificatie delegeert aan specialistagents, elk met zijn eigen taak-ID en artefacten onderweg.

Elke hop heeft zijn eigen taak-ID en statemachine, dus de orchestrator moet downstream-taken onafhankelijk streamen of pollsen, tussenliggende artefacten persistent maken voordat de volgende hop begint, en graceful falen als T3 voltooit maar T4 het concept afwijst. Multi-Agent Orchestratiepatronen behandelt topologiekeuze wanneer die specialisten als aparte services draaien in plaats van in één runtime. Gedeeltelijke voortgang is waardevol, en een gefaalde verificatie moet geen bruikbaar concept verwijderen zonder duidelijke reden.

Duurzame taakopslag voor vertraagde voltooiing

Taakstatus en artefacten moeten procesherstarts overleven. Als je agent draait in Kubernetes, ga er dan van uit dat pods sterven midden in een taak en back-up taakrecords en artefact-blobs naar een store die de agentcontainer niet exclusief bezit.

Foutafhandeling voor langlopende A2A-workflows

Langlopende workflows falen op voorspelbare manieren door time-outs, retries, gedeeltelijke artefacten en onveilige annulering, en elk heeft een expliciet beleid nodig in plaats van ad-hoc afhandeling in clientcode.

Per-hop en end-to-end timeoutbudgetten

Stel time-outs in op twee niveaus: een per-hop maximum voor één agenttaak voor escalatie of annulering, en een end-to-end maximum voor de gebruikerszichtbare workflow. Een retrieval-agent die hangt, moet de hele orchestrator niet blokkeren tot de browser van de gebruiker time-out geeft.

Retries en idempotentie voor A2A-taken

Retries zonder idempotentie dupliceren side-effecten zoals dubbele belastingen, dubbele tickets en herhaalde e-mails. Gebruik stabiele clientbericht-IDs of idempotentiesleutels waar het protocol het toestaat, en voor business-mutaties lijn je af op Idempotentie in Gedispatche Systemen Dat Echt Werkt. Retry alleen transiënte fouten zoals netwerkblips of 503s, en retry niet afgewezen of beleidsovertredingen blindelings omdat je kosten verhoogt en downstream-agents irritert.

Gedeeltelijke artefactherstelbeleid

Wanneer een taak faalt na het produceren van gedeeltelijke artefacten, definieer dan of je gedeeltelijke output aan de gebruiker exposeert met een duidelijke “onvolledig”-label, hervatting toestaat vanaf het laatste goede checkpoint, of gedeeltelijke output verwijdert wanneer deze kan misleiden in medische, juridische of financiële contexten.

Veilige annulering over delegatieketens

Annuleer downstream-taken wanneer een upstream-gebruiker abort, gebruik een delegatiegraaf zodat annulering propageert, en log geannuleerde taken die al kosten hebben veroorzaakt omdat financiele teams dat merken.

Observability voor Asynchrone A2A-workflows

Je kunt multi-agent asynchroon werk niet debuggen tenzij je het kunt traceren over grenzen, wat betekent dat je identifiers op elke hop moet correleren in plaats van te vertrouwen op gestructureerde logs. Minimum correlatievelden omvatten een trace-ID per gebruiker-initiëerde workflow, een taak-ID per agenttaak inclusief gedelegeerde kinderen, een agent-ID voor de Agent Card of service die de hop heeft afgehandeld, en een parent taak-ID die delegatieketens koppelt.

Log elke statusovergang met timestamps, en log artefactcreatie-events met grootte en hash in plaats van noodzakelijkerwijs volledige inhoud wanneer PII-beleid van toepassing is. Attribueer kosten en latentie per hop, omdat multi-agent-workflows tokenbesteding verbergen tot de rekening arriveert en per-taak kostenlabels “welke specialist is duur?” beantwoordbaar maken. Voor metrics, tracing-backends en LLM-specifieke instrumentatiepatronen, zie Observability voor LLM-systemen en de bredere Observability pijler voor hoe die signalen passen in een productie-telemetry stack. Wanneer een gebruiker vraagt “waarom deed de agent dat?”, moet je antwoord een trace zijn die orchestrator, A2A-hops, MCP-tool-aanroepen en elke inputvereist-pauze bespannen in plaats van een schouderophalen en een log grep.

Productiechecklist voor A2A-streaming en Asynchrone Taken

Voordat je langlopende A2A-paden naar productie stuurt, verifieer de volgende gebieden.

Agent Card en capaciteiten

• capabilities.streaming weerspiegelt daadwerkelijke SSE-ondersteuning
• Push-meldingondersteuning gedocumenteerd indien geïmplementeerd
• Vaardigheden die menselijke goedkeuring vereisen documenteren verwacht inputvereist-gedrag

Clientmodi

• SSE-client handhaaft herabonnement via SubscribeToTask
• Poll-interval backt-off onder load
• Push-webhook verifieert authenticiteit en wijst verouderde events af

Duurzaamheid

• Taakstatus overleeft agentprocesherstarts
• Artefacten opgeslagen buiten ephemeral container-bestandssysteem
• Tussenliggende artefacten beschikbaar voor gedeeltelijk herstel

Fouten en beleid

• Per-hop en end-to-end timeoutbudgetten gedefinieerd
• Retries idempotent voor muterende operaties
• Annulering propageert over delegatie-edges

Observability

• trace-ID + taak-ID + agent-ID op elke hop
• Statusovergangen gelogd
• Kostenattributie per taak of per agent

Loadtesting

• SSE via je reverse proxy (buffering breekt streams)
• Concurrente lange taken zonder geheugenlekken op open verbindingen
• Push-floodafhandeling zonder webhook-overload

Conclusie

De waarde van A2A komt het duidelijkst naar voren wanneer werk niet past in een enkele synchrone API-aanroep, omdat streaming, asynchrone taken, push-meldingen en expliciete taakstatussen zijn hoe het protocol echte agentworkloads zoals onderzoek, delegatie, goedkeuringen en grote artefacten handhaaft zonder te doen alsof alles in één HTTP-roundtrip voltooit. Begin met de eenvoudigste modus die werkt, voeg SSE toe wanneer gebruikers live voortgang nodig hebben, voeg push toe wanneer verbindingen niet open kunnen blijven, behandel inputvereist als een first-class ontwerptool in plaats van een fout, en instrumenteer elke hop zodat multi-agent asynchrone workflows je vermogen om ze uit te leggen niet voorbijlopen.

Veelgestelde Vragen

Wanneer moet je A2A-streaming gebruiken in plaats van polling? Gebruik streaming wanneer de client een open HTTP-verbinding kan handhaven en je low-latency voortgangupdates of incrementele artefacten nodig hebt. Gebruik polling wanneer verbindingen onbetrouwbaar zijn, clients batch-georiënteerd zijn, of je alleen periodieke statuscontroles nodig hebt op langlopende taken.

Wat betekent inputvereist in een A2A-taak? Het is een pauzestatus waarbij de agent meer informatie of menselijke goedkeuring nodig heeft. Ontwerp UX en time-outs expliciet rond dit in plaats van het te behandelen als een fout.

Hoe werken A2A push-meldingen? Registreer een PushNotificationConfig met een HTTPS-webhook. De server POST bij significante updates; de client roept GetTask aan om volledige status en artefacten op te halen.

Hoe moet je gefaalde A2A-taken retryen? Retry transiënte fouten met idempotentiesleutels, respecteer timeoutbudgetten en retry niet blindelings terminale statussen zoals afgewezen of beleidsovertredingen.

Wat moet je loggen voor langlopende A2A-workflows? Correleer trace-ID, taak-ID en agent-ID over hops. Log statusovergangen, artefacten, delegatie, goedkeuringen en per-stap kosten zodat je de volledige workflow kunt reconstrueren.

Bronnen

• A2A Protocol – Streaming en Asynchrone Operaties: https://a2a-protocol.org/latest/topics/streaming-and-async/
• A2A Protocol – Specificatieoverzicht: https://a2a-protocol.org/latest/specification/