A2A-strömning och asynkrona uppgifter för långvariga agentarbetsflöden

De flesta AI-agentdemonstrationer beter sig fortfarande som chattkompletteringar med extra steg: du skickar en prompt, väntar några sekunder och får ett svar tillbaka i ett enda svar.

Äkta agentarbete passar ofta inte in i den mönster. Forskning, kodgranskning, inköpsanalys, incidentutredning och flerstegsplanering kan pågå i minuter eller timmar, och de kan behöva förtydliganden halvvägs genom, strömma delvisa resultat, delegera till en annan agent och producera filer snarare än ett enda textsvar. Det är där A2A-protokollets asynkrona modell får betydelse inom det bredare klustret AI Systems, eftersom A2A behandlar långvarigt arbete som en Task (uppgift) med en livscykel istället för ett engångs-HTTP-svar. Kunder kan hålla sig anslutna via Server-Sent Events (SSE), polla uppgiftens status eller registrera push-webhooks när de inte kan hålla en ansluten öppen.

Den här artikeln täcker operativ design för dessa arbetsflöden, inklusive när man ska strömma jämfört med att polla eller pusha, hur input_required passar in i human-in-the-loop-flöden, felhantering och vad man ska instrumentera i produktion. För Agent Cards, meddelanden, delar och hela uppgiftsmodellen, se Vad är A2A-protokollet? Agent Cards och uppgifter förklarat.

Varför långvariga A2A-agentuppgifter behöver asynkron design

En synkron begäran/svar-mentalmodell bryter snabbt ner när agentarbetsflöden sträcker sig över verktyg, delegering, godkännanden och stora artefakter. En agentuppgift kan anropa flera MCP-server internt, delegera underarbete till en annan agent via A2A, vänta på mänskligt godkännande, generera stora artefakter i bitar, misslyckas halvvägs genom och behöva partiell återhämtning, samt ackumulera tokenkostnad över flera hopp. HTTP-API:er kan approximera detta med timeout, bakgrundsjobb och ad hoc-statusendpointar, men A2A integrerar uppgiftsidentitet och status i protokollet så att kunder och gateway kan resonera kring arbete konsekvent. För hur dessa lager passar in i en produktionsassistent innan du lägger till asynkrona A2A-gränser, se AI-assistentarkitektur: LLM, minne, verktyg, routing, observabilitet.

Min bias är praktisk: skapa inte en Task för allt, eftersom en enkel sammanfattning inte behöver en livscykel. Använd en Task när arbetet är tillståndsberget, granskbart, långvarigt, artefaktproducerande eller kan behöva input mitt i flykten. Tumregeln från förklaringen gäller fortfarande: enkla interaktioner kan returnera ett Message, medan komplext arbete bör returnera en Task.

A2A uppgiftslivscykel och statövergångar

En A2A Task rör sig genom stater som kunder kan fråga vid varje tillfälle. Exakt namnvarierar något beroende på implementation, men modellen är stabil över servrar som följer protokollet.

Statusen submitted (inlämnad) betyder att kunden skickade arbete och agenten accepterade eller köade det. I working (arbetande) bearbetar agenten aktivt, vilket kan inkludera verktygsanrop, delegering eller strömning av partiell output. Statusen input_required (input krävs) indikerar att agenten pausade eftersom den behöver mer input, förtydligande eller mänskligt godkännande, och det är inte ett felstate. completed (slutförd) är terminal framgång med tillgängliga artefakter; failed (misslyckad) är ett terminalfel vars detaljer och partiella artefakter beror på implementation; canceled (avbruten) betyder att en kund, gateway eller auktoriserad anropande stoppade uppgiften; och rejected (avvisad) betyder att agenten vägrade uppgiften på grund av policy, kapacitetsmismatch eller auth.

När input_required pauserar jämfört med att misslyckas ett arbetsflöde

Behandla input_required som en avsiktlig paus, inte ett undantag. Agenten säger åt dig att den inte kan fortsätta utan något från dig, oavsett om det är en saknad parameter, ett policybekräftelse eller en chefs signatur på en högriskåtgärd. Ett arbetsflöde misslyckas när uppgiften når failed eller rejected, eller när en anropande överskrider en timeout som väntar på input som aldrig kommer, så du bör designa explicita timeouts för mänskliga steg snarare än att låta godkännanden sitta obegränsat.

Ett godkännande som väntar i tre dagar utan eskalering är ett fastnat arbetsflöde, inte ett tålmodigt, och fastna arbetsflöden stoppar uppgiftsbutiker medan de gör observabilitetsdashboards svårare att läsa.

Vem kan avbryta en A2A-uppgift

Avbrottshörighet bör definieras vid designstadiet snarare än debatteras under en incident. Kunden kan vanligtvis avbryta uppgifter den skapade; en gateway kan avbryta på uppdrag av hyresgäster, policyöverträdelser eller budgetgränser; och en upstream agent kan avbryta delegerat arbete när den orkestrerar över A2A om protokollet och policyn tillåter det. Logga vem som avbröt och varför, eftersom i multi-agent-kedjor är orphan-arbete en vanlig källa till överraskande tokenräkningar.

Human-in-the-loop med input_required uppgiftsstater

input_required är en av A2A:s mest underutnyttjade designfunktioner, och många team behandlar den som ett felkod när den faktiskt är en first-class arbetsflödesstatus. I produktion kommer du att stöta på fall där agenten bör stoppa, såsom att spendera budget på en tvetydig begäran, utföra en oåterkallelig åtgärd, få tillgång till känsliga data utan scopebekräftelse eller delegera till en specialist som behöver explicit användarintent. Modeller dessa som avsiktliga övergångar till input_required, med ett tydligt meddelande som förklarar vad som behövs.

Godkännandeflöden för riskfylld A2A-delegering

När Agent A delegerar till Agent B över A2A och Agent B går in i input_required för mänskligt godkännande, behöver tre system komma överens om vad som händer nästa. Den nedströms agenten pauserar och exponerar vad den behöver, orkestratorn eller gatewayen presenterar denna paus för användaren, och användarens svar återupptar uppgiften via ett nytt meddelande. Jämförelsen A2A vs MCP förklarar varför delegering över agentgränser är ett annat problem än verktygsåtkomst, och varför godkännandesemantik tillhör uppgiftslagret snarare än inuti ett enskilt MCP-anrop. Godkänn inte tyst automatiskt för att UX:n är olämplig, eftersom dyra misstag oftast kommer från bekvämlighetsgenvägar snarare än från saknade modeller.

UX-mönster för pausade A2A-uppgifter

Blockerande väntan betyder att UI:n visar en spinner eller godkännandekort tills uppgiften lämnar input_required, vilket fungerar bra för korta mänskliga steg. Icke-blockerande väntan betyder att kunden sparar uppgifts-ID:t, låter användaren fortsätta annars, och använder polling eller push för att avisera när input behövs igen, vilket krävs för mobil, e-postlänkade godkännanden eller multi-tab-assistenter. Timeout när människor är långsamma betyder att definiera en SLA per steg och, efter N timmar, övergå till failed eller eskalera till en annan kö, eftersom obegränsade väntar stoppar uppgiftsbutiker och förvirrar observabilitetsdashboards.

Hur en A2A-gateway hanterar input_required

Om du kör en A2A-gateway, avgör om den vidarebefordrar input_required-händelser transparent, aggregerar pauser från flera nedströms agenter till ett användarprompt, eller tvingar att vissa färdigheter alltid kräver godkännande innan de lämnar input_required. Auth och policy för godkända åtgärder tillhör en dedikerad säkerhetsartikel; för nu, anta att varje återupptagen uppgift bör bära samma användaridentitet och scope som den ursprungliga begäran.

Välja Sync, SSE-strömning, Polling eller Push-meddelanden

A2A stöder flera interaktionslägen, och rätt val beror på kundkapacitet och latensbehov snarare än på vilket läge låter mest modernt.

Läs Agent Card-funktionsflaggor först

Innan du väljer ett läge, läs agentens Agent Card, eftersom strömning kräver capabilities.streaming: true och push-meddelandestöd annonseras separat. Kunder som antar att varje agent strömmar kommer att gå sönder mot minimala implementationer, så förhandling är inte ceremoniell: den förhindrar runtime-fel när en specialistagent endast stöder poll-baserade statuskontroller.

När man ska använda assistent-sides polling runt A2A

Din assistentruntime kan linda A2A-uppgiftspolling i en schemalägningsloop snarare än att exponera råa protokoll detaljer för användaren. Det mönster överlappar med allmänna polling agents, som är bakgrundprocesser som vaknar upp, kontrollerar status och agerar. För hållbar schemaläggning, idempotens och kömönster utanför A2A specifikt, se Polling Agents i AI-assistenter: 11 implementeringsmönster. Använd assistentpolling när du orkestrerar många A2A-uppgifter från en enda kontrollplan, och använd native A2A-strömning eller push när kunden ansluter direkt till agentgränsen.

A2A Server-Sent Events (SSE) strömning

SSE är A2A:s primära realtidskanal. Kunden anropar SendStreamingMessage, öppnar en HTTP-anslutning och får ett text/event-stream-svar tills uppgiften når en terminal eller avbruten status. Varje händelse payload är JSON-RPC-formad, och typiska resultattyper inkluderar en Task-snapshot, en TaskStatusUpdateEvent för livscykelövergångar och mellanliggande agentmeddelanden, och en TaskArtifactUpdateEvent för chunkad artefaktleverans med append och lastChunk-hints för sammanställning.

Strömning av förloppsupdate och partiella artefakter

Strömning skiner när användare bör se arbete som händer, oavsett om det betyder stegräkare (“3 av 7 källor granskade”), partiell textgenerering, inkrementella filchunkar för stora rapporter eller statövergångar från working till input_required utan polling. Designa UI runt händelsetyper snarare än runt en enda final blob, eftersom om du bara visar output när completed anländer kan du lika gärna polla.

SSE-anslutningsavbrott och omregistrering

Nätverk faller, laptopar somnar, och lastbalanserare idle-timeout SSE-anslutningar, så långa strömmar behöver återhämtningslogik snarare än optimistiska antaganden. A2A tillhandahåller SubscribeToTask så att kunder kan återansluta till en pågående uppgiftsström, och din kund SDK bör persistera taskId lokalt, upptäcka strömmstängning innan terminalstatus, omregistrera med backoff och deduplicera händelser om servern spelar in överlappande status. Utan omregistreringslogik känns långa uppgifter sköra i produktion även när agentbakänden är frisk.

A2A push-meddelanden och webhooks

Push passar scenarier där SSE är en dålig match, såsom mobilappar i bakgrunden, serverless-handlare eller uppgifter som körs i timmar eller dagar. Kunden tillhandahåller en PushNotificationConfig med en url (HTTPS-webhook på kundsidan), en valfri token för att validera inkommande POST:er, och valfri authentication-detalj för hur A2A-servern autentiserar mot webhooken. Konfigurationen kan åka med den ursprungliga SendMessage eller SendStreamingMessage-anropet, eller läggas till senare via CreateTaskPushNotificationConfig för en befintlig uppgift.

När en betydande update inträffar, POST:ar A2A-servern till webhooken och kunden anropar typiskt GetTask med det notifierade taskId för att hämta hela uppdaterade Task och artefakter. Push är en signal, inte en full payload-transport.

När push slår en öppen SSE-anslutning

Föredra push när kunden inte kan underhålla SSE (mobil, edge-funktioner), när updates är ovanliga och milestenbaserade snarare än token-för-token, eller när du vill att servern ska väcka en frånkopplad arbetsflödesmotor. Föredra SSE när användare ser förlopp live, när artefakter strömmas i många små chunkar, eller när latens under några sekunder betyder något.

Korrelering av push-meddelanden till A2A-uppgifter

Varje push-handlare bör logga och propagera taskId, en trace eller korrelations-ID från den ursprungliga begäran, händelsetyp eller statövergång, och en tidsstämpel från meddelandet så att utdaterade händelser kan avvisas. Replay-attacker och dubbla leveranser händer i produktion, så idempotenta handlare är inte valfria.

Push-endpoint säkerhetsöversikt

Push introducerar SSRF-risk på servern när maliciösa kunder registrerar interna URL:er, och impersonationsrisk på kunden när falska POST:er kommer till webhooken. Miltigationer inkluderar URL-allowlists, ägarverifiering, signerade JWT:er med JWKS, tidsstämpelskontroller och validering av config-token. Den fulla hotmodellen, identitetslager och gateway-kontroller lever i A2A och MCP Agent Security: Identity, Delegation, and Audit Trails; tills du har läst det, behandla webhook-verifiering med samma allvar som betalningscallbacks.

Asynkrona A2A-arbetsflödesmönster

Fire-and-follow uppgiftsinlämning

Kunden lämnar in en uppgift, får ett uppgifts-ID omedelbart och kopplar från, pollar sedan GetTask eller väntar på push. Detta är standardmönstret för serverless och batch-pipelines, men du bör persistera uppgifts-ID:t i hållbar lagring innan du bekräftas för användaren, eftersom serverless-inokationer som glömmer ID:t förlorar arbetet.

Återupptagande av en uppgift efter input_required

Efter input_required skickar användaren ett nytt meddelande mot samma uppgift och agenten övergår tillbaka till working. Designa meddelanden så att återupptagningskontexten är explicit, eftersom “Godkänd: fortsätt med leverantör X” slår ett blotta “ja” när du behöver granska vad som godkänds sex timmar senare.

Kedjade A2A-delegering med mellanliggande artefakter

Tänk på ett forskningsarbetsflöde där en orkestrator äger Uppgift T1 och delegerar hämtning, sammanfattning och verifiering till specialistagenter, var och en med sitt eget uppgifts-ID och artefakter på vägen.

Varje hopp har sitt eget uppgifts-ID och statmaskin, så orkestratorn bör strömma eller polla nedströms uppgifter oberoende, persistera mellanliggande artefakter innan nästa hopp startar, och misslyckas elegant om T3 slutförs men T4 avvisar utkastet. Multi-Agent Orkestrationsmönster täcker topologival när dessa specialister körs som separata tjänster snarare än i en runtime. Partiell framgång är värdefull, och ett misslyckad verifiering bör inte radera ett användbart utkast utan en tydlig anledning.

Hållbar uppgiftslagring för fördröjd slutförande

Uppgiftsstatus och artefakter bör överleva processomstart. Om din agent körs i Kubernetes, anta att pods dör mitt i uppgiften och backupa uppgiftsregister och artefaktblobs till en butik som agentcontainern inte äger exklusivt.

Felhantering för långvariga A2A-arbetsflöden

Långvariga arbetsflöden misslyckas på förutsägbara sätt genom timeouts, retryer, partiella artefakter och osäker avbrott, och varje behöver en explicit policy snarare än ad hoc-hantering i kundkoden.

Per-hop och end-to-end timeout-budgetar

Ställ in timeouts på två nivåer: en per-hop maximum för en agentuppgift innan eskalering eller avbrott, och en end-to-end maximum för det användarsynliga arbetsflödet. En hämtagent som hänger bör inte blockera hela orkestratorn tills användarens webbläsare timeout.

Retry och idempotens för A2A-uppgifter

Retry utan idempotens duplicerar side effekter såsom dubbla laddningar, dubbla biljetter och upprepade e-postmeddelanden. Använd stabila kundmeddelande-ID:er eller idempotensnycklar där protokollet tillåter, och för affärs mutationer, aligna med Idempotens i distribuerade system som faktiskt fungerar. Retry endast transienta fel som nätverksblips eller 503:er, och retry inte rejected eller policy-fel blindt eftersom du kommer att förstärka kostnad och irritera nedströms agenter.

Policyer för partiell artefaktåterhämtning

När en uppgift misslyckas efter att ha producerat partiella artefakter, definiera om du exponerar partiell output för användaren med en tydlig “ofullständig”-etikett, tillåter återupptagning från senaste goda checkpoint, eller kassera partiell output när den kan vilseleda i medicinska, juridiska eller finansiella sammanhang.

Säker avbrott över delegeringskedjor

Avbryt nedströms uppgifter när en upstream-användare avbryter, använd en delegeringsgraf så att avbrott propageras, och logga avbrutna uppgifter som redan har pådragit kostnad eftersom finanslagren märker det.

Observabilitet för asynkrona A2A-arbetsflöden

Du kan inte debugga multi-agent asynkront arbete om du inte kan spåra det över gränser, vilket betyder att korrelera identifierare på varje hopp snarare än att lita på ostrukturerade loggar. Minsta korrelationsfält inkluderar en trace ID per användare-initierat arbetsflöde, en task ID per agentuppgift inklusive delegerade barn, en agent ID för Agent Card eller tjänsten som hanterade hoppen, och en parent task ID som länkar delegeringskedjor.

Logga varje statövergång med tidsstämplar, och logga artefaktskapande händelser med storlek och hash snarare än nödvändigtvis fullt innehåll när PII-policyer gäller. Attribuera kostnad och latens per hopp, eftersom multi-agent-arbetsflöden döljer tokenutgifter tills räkningen kommer och per-uppgift kostnadsetiketter gör “vilken specialist är dyr?” besvarbar. För metrics, tracing backends och LLM-specifika instrumenteringsmönster, se Observabilitet för LLM-system och den bredare Observabilitet pelare för hur dessa signaler passar in i en produktions telemetristack. När en användare frågar “varför gjorde agenten det?”, bör ditt svar vara en trace som sträcker sig över orkestrator, A2A-hopp, MCP-verktygsanrop och alla input_required-pauser snarare än axelpressning och en logg grep.

Produktionschecklista för A2A-strömning och asynkrona uppgifter

Innan du skickar långvariga A2A-vägar till produktion, verifiera följande områden.

Agent Card och kapaciteter

• capabilities.streaming speglar faktisk SSE-stöd
• Push-meddelandestöd dokumenterat om implementerat
• Färdigheter som kräver mänskligt godkännande dokumenterar förväntad input_required-beteende

Kundlägen

• SSE-kund hanterar omregistrering via SubscribeToTask
• Pollintervall backar av under last
• Push-webhook verifierar autenticitet och avvisar utdaterade händelser

Hållbarhet

• Uppgiftsstatus överlever agentprocessomstarter
• Artefakter lagras utanför efemer container-filsystem
• Mellanliggande artefakter tillgängliga för partiell återhämtning

Fel och policy

• Per-hop och end-to-end timeout-budgetar definierade
• Retryer idempotenta för muterande operationer
• Avbrott propageras över delegeringskanter

Observabilitet

• trace ID + task ID + agent ID på varje hopp
• Statövergångar loggade
• Kostnadsattributering per uppgift eller per agent

Lasttestning

• SSE genom din reverse proxy (buffering bryter strömmar)
• Samtida långa uppgifter utan minnesläckor på öppna anslutningar
• Push-flodhantering utan webhook-overload

Slutsats

A2A:s värde visar sig tydligast när arbete inte passar en enda synkron API-anrop, eftersom strömning, asynkrona uppgifter, push-meddelanden och explicita uppgiftsstater är hur protokollet hanterar äkta agentlast såsom forskning, delegering, godkännanden och stora artefakter utan att låtsas att allt slutförs i en HTTP-round trip. Börja med det enklaste läget som fungerar, lägg till SSE när användare behöver live-förlopp, lägg till push när anslutningar inte kan hållas öppna, behandla input_required som ett first-class designverktyg snarare än ett fel, och instrumentera varje hopp så att multi-agent asynkrona arbetsflöden inte springer ifrån din förmåga att förklara dem.

Vanliga frågor

När ska man använda A2A-strömning istället för polling? Använd strömning när kunden kan hålla en öppen HTTP-anslutning och du behöver låg-latens förloppsupdate eller inkrementella artefakter. Använd polling när anslutningar är opålitliga, kunder är batch-orienterade, eller du bara behöver periodiska statuskontroller på långvariga uppgifter.

Vad betyder input_required i en A2A-uppgift? Det är en pausstatus där agenten behöver mer information eller mänskligt godkännande. Designa UX och timeouts explicit runt det snarare än att behandla det som ett fel.

Hur fungerar A2A push-meddelanden? Registrera en PushNotificationConfig med en HTTPS-webhook. Servern POST:ar vid betydande updates; kunden anropar GetTask för att hämta full status och artefakter.

Hur ska man retry misslyckade A2A-uppgifter? Retry transienta fel med idempotensnycklar, respektera timeout-budgetar och retry inte terminala stater som rejected eller policy-fel blindt.

Vad ska man logga för långvariga A2A-arbetsflöden? Korrelatera trace ID, task ID och agent ID över hopp. Logga statövergångar, artefakter, delegering, godkännanden och per-steg kostnad så att du kan rekonstruera hela arbetsflödet.

Källor

• A2A Protocol – Streaming and Asynchronous Operations: https://a2a-protocol.org/latest/topics/streaming-and-async/
• A2A Protocol – Specification overview: https://a2a-protocol.org/latest/specification/