A2A-Streaming und asynchrone Tasks für langläufige Agenten-Workflows

Die meisten AI-Agent-Demos verhalten sich immer noch wie Chat-Vervollständigungen mit zusätzlichen Schritten: Sie senden einen Prompt, warten einige Sekunden und erhalten die Antwort in einer einzigen Reaktion.

Echte Agentenarbeit passt oft nicht in dieses Muster. Forschung, Code-Reviews, Beschaffungsanalysen, Incident-Untersuchungen und mehrstufige Planungen können Minuten oder Stunden dauern. Sie können unterwegs Klärungen benötigen, partielle Ergebnisse streamen, Aufgaben an einen anderen Agenten delegieren und Dateien statt einer einzigen Textantwort produzieren. Genau hier spielt das asynchrone Modell des A2A-Protokolls innerhalb des breiteren AI Systems-Clusters eine Rolle, da A2A langlaufende Arbeit als Task (Aufgabe) mit einem Lebenszyklus behandelt, anstatt als eine einzige HTTP-Antwort. Clients können über Server-Sent Events (SSE) verbunden bleiben, den Task-Status abfragen (pollen) oder Push-Webhooks registrieren, wenn sie keine Verbindung offen halten können.

Dieser Artikel behandelt das operative Design für diese Workflows, einschließlich der Entscheidung, wann man streamt, pollt oder push-Nachrichten verwendet, wie input_required in Human-in-the-Loop-Flows passt, Fehlerbehandlung und was in der Produktion instrumentiert werden sollte. Für Agent Cards, Nachrichten, Parts und das vollständige Task-Modell siehe Was ist das A2A-Protokoll? Agent Cards und Tasks erklärt.

Warum langlaufende A2A-Agenten-Tasks ein asynchrones Design benötigen

Ein synchrones Request/Response-Mentalmodell bricht schnell zusammen, sobald Agentenarbeit Tools, Delegation, Genehmigungen und große Artefakte umfasst. Ein Agenten-Task kann intern mehrere MCP-Server aufrufen, Teilarbeit über A2A an einen anderen Agenten delegieren, auf menschliche Genehmigung warten, große Artefakte inChunks generieren, auf halbem Weg fehlschlagen und eine partielle Wiederherstellung benötigen, sowie Token-Kosten über mehrere Hops hinweg anhäufen. HTTP-APIs können dies mit Timeouts, Hintergrundjobs und ad-hoc-Statusendpunkten approximieren, aber A2A integriert Task-Identität und Status in das Protokoll, sodass Clients und Gateways konsistent über die Arbeit nachdenken können. Wie diese Schichten in einem produktiven Assistenten zusammenpassen, bevor Sie asynchrone A2A-Grenzen hinzufügen, erfahren Sie in AI-Assistenten-Architektur: LLM, Memory, Tools, Routing, Observability.

Meine pragmatische Haltung ist: Erstellen Sie nicht für alles einen Task, denn eine einzeilige Zusammenfassung benötigt keinen Lebenszyklus. Verwenden Sie einen Task, wenn die Arbeit zustandsbehaftet, auditierbar, langlaufend, artefaktproduzierend ist oder unterwegs Eingaben benötigt. Die Daumenregel aus der Einführung gilt weiterhin: Einfache Interaktionen können eine Message zurückgeben, während komplexe Arbeit einen Task zurückgeben sollte.

A2A-Task-Lebenszyklus und Statusübergänge

Ein A2A-Task durchläuft Zustände, die Clients jederzeit abfragen können. Die genaue Benennung variiert je nach Implementierung leicht, aber das Modell ist stabil über alle Server hinweg, die das Protokoll befolgen.

Der Zustand submitted bedeutet, dass der Client Arbeit gesendet und der Agent diese akzeptiert oder in die Warteschlange gestellt hat. In working verarbeitet der Agent aktiv, was Tool-Aufrufe, Delegation oder das Streamen partieller Ausgabe umfassen kann. Der Zustand input_required gibt an, dass der Agent pausiert hat, da er weitere Eingaben, Klärungen oder menschliche Genehmigung benötigt; es handelt sich nicht um einen Fehlerzustand. completed ist ein terminaler Erfolg mit verfügbaren Artefakten; failed ist ein terminaler Fehler, dessen Details und partielle Artefakte von der Implementierung abhängen; canceled bedeutet, dass ein Client, Gateway oder autorisierter Aufrufer den Task gestoppt hat; und rejected bedeutet, dass der Agent den Task aufgrund von Richtlinien, fehlender Fähigkeiten oder Authentifizierung abgelehnt hat.

Wann input_required einen Workflow pausiert versus scheitern lässt

Behandeln Sie input_required als eine bewusste Pause, nicht als eine Ausnahme. Der Agent sagt Ihnen, dass er ohne etwas von Ihnen nicht fortfahren kann, ob es sich um einen fehlenden Parameter, eine Richtliniengenehmigung oder die Freigabe eines Managers für eine Hochrisikoaktion handelt. Ein Workflow scheitert, wenn der Task failed oder rejected erreicht, oder wenn ein Aufrufer ein Timeout überschreitet, während er auf Eingaben wartet, die nie eintreffen. Sie sollten daher explizite Timeouts für menschliche Schritte designen, anstatt Genehmigungen unbegrenzt warten zu lassen.

Eine Genehmigung, die drei Tage ohne Eskalation wartet, ist ein steckengebliebener Workflow, kein geduldiger, und steckengebliebene Workflows verstopfen Task-Speicher und machen Observability-Dashboards schwerer lesbar.

Wer einen A2A-Task abbrechen kann

Die Berechtigung zum Abbrechen sollte zum Designzeitpunkt definiert werden, nicht während eines Incidents diskutiert. Der Client kann normalerweise Tasks abbrechen, die er erstellt hat; ein Gateway kann im Namen von Tenants, bei Richtlinienviolationen oder Budgetgrenzen abbrechen; und ein upstream Agent kann delegierte Arbeit abbrechen, wenn er über A2A orchestriert, sofern Protokoll und Richtlinie es erlauben. Protokollieren Sie, wer abgebrochen hat und warum, da in Multi-Agenten-Ketten verwaiste Arbeit eine häufige Quelle für überraschende Token-Rechnungen ist.

Human-in-the-Loop mit input_required-Task-Zuständen

input_required ist eines der am wenigsten genutzten Design-Features von A2A, und viele Teams behandeln es als Fehlercode, obwohl es eigentlich ein erstklassiger Workflow-Zustand ist. In der Produktion werden Sie auf Fälle stoßen, in denen der Agent sollte stoppen, wie zum Beispiel Budget für eine mehrdeutige Anfrage auszugeben, eine irreversible Aktion auszuführen, auf sensible Daten ohne Scope-Bestätigung zuzugreifen oder an einen Spezialisten zu delegieren, der explizite Benutzerabsicht benötigt. Modellieren Sie diese als bewusste Übergänge zu input_required, mit einer klaren Nachricht, die erklärt, was benötigt wird.

Genehmigungsflows für riskante A2A-Delegation

Wenn Agent A an Agent B über A2A delegiert und Agent B input_required für menschliche Genehmigung erreicht, müssen drei Systeme übereinstimmen, was als Nächstes passiert. Der downstream-Agent pausiert und zeigt an, was er benötigt, der Orchestrator oder das Gateway zeigt diese Pause dem Benutzer an, und die Antwort des Benutzers setzt den Task über eine neue Nachricht fort. Der A2A vs MCP-Vergleich erklärt, warum Delegation über Agentengrenzen hinweg ein anderes Problem ist als Tool-Zugriff und warum Genehmigungssemantiken auf der Task-Ebene statt innerhalb eines einzelnen MCP-Aufrufs gehören. Genehmigen Sie nicht stillschweigend automatisch, nur weil die UX unbequem ist, da teure Fehler normalerweise von Komfortkürzungen stammen, nicht von fehlenden Modellen.

UX-Muster für pausierte A2A-Tasks

Blockierende Wartezeit bedeutet, dass die UI einen Spinner oder eine Genehmigungs-Karte anzeigt, bis der Task input_required verlässt, was gut für kurze menschliche Schritte funktioniert. Nicht-blockierende Wartezeit bedeutet, dass der Client die Task-ID aufzeichnet, dem Benutzer erlaubt, anderswo fortzufahren, und Polling oder Push verwendet, um zu benachrichtigen, wenn wieder Eingaben benötigt werden, was für Mobile, E-Mail-verknüpfte Genehmigungen oder Multi-Tab-Assistenten erforderlich ist. Timeout, wenn Menschen langsam sind bedeutet, eine SLA pro Schritt zu definieren und nach N Stunden zu failed zu wechseln oder an eine andere Warteschlange zu eskalieren, da unbegrenzte Wartezeiten Task-Speicher verstopfen und Observability-Dashboards verwirren.

Wie ein A2A-Gateway input_required behandelt

Wenn Sie ein A2A-Gateway betreiben, entscheiden Sie, ob es input_required-Ereignisse transparent weiterleitet, Pausen von mehreren downstream-Agenten in einer Benutzeraufforderung aggregiert oder durchsetzt, dass bestimmte Skills immer eine Genehmigung benötigen, bevor sie input_required verlassen. Auth und Richtlinien für genehmigte Aktionen gehören in einen dedizierten Sicherheitsartikel; gehen Sie vorerst davon aus, dass jeder fortgesetzte Task dieselbe Benutzeridentität und denselben Scope wie die ursprüngliche Anfrage tragen sollte.

Auswahl zwischen Sync, SSE-Streaming, Polling oder Push-Benachrichtigungen

A2A unterstützt mehrere Interaktionsmodi, und die richtige Wahl hängt von Client-Fähigkeiten und Latenzanforderungen ab, nicht davon, welcher Modus modern klingt.

Lesen Sie zuerst die Agent Card-Fähigkeitsflags

Bevor Sie einen Modus wählen, lesen Sie die Agent Card des Agenten, da Streaming capabilities.streaming: true erfordert und Push-Benachrichtigungsunterstützung separat beworben wird. Clients, die davon ausgehen, dass jeder Agent streamt, brechen bei minimalen Implementierungen, daher ist Verhandlung nicht zeremoniell: Sie verhindert Laufzeitfehler, wenn ein Spezialisten-Agent nur pollbasierte Statusprüfungen unterstützt.

Wann assistant-seitiges Polling um A2A herum verwenden

Ihre Assistenten-Runtime kann A2A-Task-Polling in einen Scheduler-Loop einbetten, anstatt raw-Protokolldetails dem Benutzer auszusetzen. Dieses Muster überschneidet sich mit allgemeinen polling agents, die Hintergrundprozesse sind, die aufwachen, Status prüfen und handeln. Für dauerhafte Planung, Idempotenz und Warteschlangenmuster außerhalb von A2A spezifisch, siehe Polling Agents in AI Assistants: 11 Implementation Patterns. Verwenden Sie Assistant-Polling, wenn Sie viele A2A-Tasks von einer einzigen Control Plane orchestrieren, und verwenden Sie natives A2A-Streaming oder Push, wenn der Client direkt an die Agentengrenze anschließt.

A2A Server-Sent Events (SSE) Streaming

SSE ist A2A’s primärer Echtzeit-Kanal. Der Client ruft SendStreamingMessage auf, öffnet eine HTTP-Verbindung und erhält eine text/event-stream-Antwort, bis der Task einen terminalen oder unterbrochenen Zustand erreicht. Die Payload jedes Ereignisses ist JSON-RPC-geformt, und typische Ergebnistypen umfassen einen Task-Snapshot, ein TaskStatusUpdateEvent für Lebenszyklusübergänge und zwischengeschaltete Agentennachrichten, sowie ein TaskArtifactUpdateEvent für die Lieferung von Artefakt-Chunks mit append und lastChunk-Hinweisen für die Zusammenführung.

Streaming-Fortschrittsupdates und partielle Artefakte

Streaming glänzt, wenn Benutzer sehen sollen, dass Arbeit geschieht, ob das Schrittzähler bedeutet (“3 von 7 Quellen geprüft”), partielle Textgenerierung, inkrementelle Datei-Chunks für große Berichte oder Statusübergänge von working zu input_required ohne Polling. Designen Sie die UI um Ereignistypen herum, nicht um einen einzelnen finalen Blob, denn wenn Sie nur Ausgabe anzeigen, wenn completed ankommt, könnten Sie genauso gut pollen.

SSE-Verbindungsabbrüche und Neuabonnement

Netzwerke brechen ab, Laptops schlafen ein und Load Balancer timeouten SSE-Verbindungen, daher benötigen lange Streams Wiederherstellungslogik statt optimistischer Annahmen. A2A bietet SubscribeToTask, sodass Clients sich zu einem laufenden Task-Stream neu verbinden können, und Ihr Client-SDK sollte taskId lokal persistieren, Stream-Schluss vor dem terminalen Zustand erkennen, mit Backoff neu abonnieren und Ereignisse deduplizieren, wenn der Server überlappende Zustände erneut abspielt. Ohne Neuabonnements-Logik fühlen sich lange Tasks in der Produktion fragil an, auch wenn der Agenten-Backend gesund ist.

A2A Push-Benachrichtigungen und Webhooks

Push passt auf Szenarien, in denen SSE ein schlechter Match ist, wie mobile Apps im Hintergrund, Serverless-Handler oder Tasks, die Stunden oder Tage laufen. Der Client liefert eine PushNotificationConfig mit einer url (HTTPS-Webhook auf der Client-Seite), einem optionalen token zur Validierung eingehender POSTs und optionalen authentication-Details, wie der A2A-Server sich beim Webhook authentifiziert. Die Konfiguration kann mit dem initialen SendMessage- oder SendStreamingMessage-Aufruf mitkommen, oder später via CreateTaskPushNotificationConfig für einen bestehenden Task hinzugefügt werden.

Wenn eine signifikante Aktualisierung auftritt, POSTet der A2A-Server an den Webhook und der Client ruft typischerweise GetTask mit der benachrichtigten taskId auf, um den vollständigen aktualisierten Task und Artefakte abzurufen. Push ist ein Signal, kein vollständiger Payload-Transport.

Wann Push eine offene SSE-Verbindung schlägt

Bevorzugen Sie Push, wenn der Client keine SSE aufrechterhalten kann (Mobile, Edge-Funktionen), wenn Updates selten und meilensteinbasiert statt token-basiert sind, oder wenn Sie wollen, dass der Server einen getrennten Workflow-Engine weckt. Bevorzugen Sie SSE, wenn Benutzer den Fortschritt live beobachten, wenn Artefakte in vielen kleinen Chunks gestreamt werden, oder wenn Latenz unter einigen Sekunden wichtig ist.

Korrelieren von Push-Benachrichtigungen mit A2A-Tasks

Jeder Push-Handler sollte die taskId, eine Trace- oder Korrelations-ID von der ursprünglichen Anfrage, den Ereignistyp oder die Statusübergang und einen Zeitstempel von der Benachrichtigung protokollieren, sodass veraltete Ereignisse abgelehnt werden können. Replay-Angriffe und doppelte Lieferungen passieren in der Produktion, daher sind idempotente Handler nicht optional.

Push-Endpunkt-Sicherheitsüberblick

Push bringt SSRF-Risiko auf dem Server mit sich, wenn bösartige Clients interne URLs registrieren, und Identitätsrisiko auf dem Client, wenn gefälschte POSTs am Webhook ankommen. Minderungen umfassen URL-Allowlists, Ownership-Verifizierung, signierte JWTs mit JWKS, Zeitstempelprüfungen und Validierung des Config-Tokens. Das vollständige Threat-Modell, Identitätsschichten und Gateway-Kontrollen leben in A2A and MCP Agent Security: Identity, Delegation, and Audit Trails; behandeln Sie Webhook-Verifizierung, bis Sie es gelesen haben, mit derselben Ernsthaftigkeit wie Payment-Callbacks.

Asynchrone A2A-Workflow-Muster

Fire-and-follow Task-Einreichung

Der Client reicht einen Task ein, erhält sofort eine Task-ID und trennt die Verbindung, pollt später GetTask oder wartet auf Push. Dies ist das Standardmuster für Serverless und Batch-Pipelines, aber Sie sollten die Task-ID in dauerhaften Speicher persistieren, bevor Sie den Benutzer bestätigen, da Serverless-Invoke, die die ID vergessen, die Arbeit verlieren.

Fortsetzen eines Tasks nach input_required

Nach input_required sendet der Benutzer eine neue Nachricht gegen denselben Task und der Agent wechselt zurück zu working. Designen Sie Nachrichten so, dass der Fortsetzungskontext explizit ist, da “Genehmigt: mit Vendor X fortfahren” besser ist als ein nacktes “ja”, wenn Sie auditieren müssen, was sechs Stunden später genehmigt wurde.

Verkettete A2A-Delegation mit Zwischenartefakten

Betrachten Sie einen Forschungsworkflow, bei dem ein Orchestrator Task T1 besitzt und Retrieval, Zusammenfassung und Verifikation an Spezialisten-Agenten delegiert, jeder mit seiner eigenen Task-ID und Artefakten unterwegs.

Jeder Hop hat seine eigene Task-ID und seinen eigenen Statusautomaten, daher sollte der Orchestrator downstream-Tasks unabhängig streamen oder pollen, Zwischenartefakte persistieren, bevor er den nächsten Hop startet, und graceful fehlschlagen, wenn T3 abgeschlossen ist, aber T4 den Entwurf ablehnt. Multi-Agent Orchestration Patterns deckt Topologie-Wahl ab, wenn diese Spezialisten als separate Dienste laufen, anstatt in einer Runtime. Partieller Fortschritt ist wertvoll, und eine gescheiterte Verifikation sollte keinen nutzbaren Entwurf ohne klaren Grund löschen.

Dauerhafter Task-Speicher für verzögerte Fertigstellung

Task-Status und Artefakte sollten Prozessrestarts überleben. Wenn Ihr Agent in Kubernetes läuft, gehen Sie davon aus, dass Pods mitten im Task sterben und Task-Records und Artefakt-Blobs an einen Store backed sind, den der Agent-Container nicht exklusiv besitzt.

Fehlerbehandlung für langlaufende A2A-Workflows

Langlaufende Workflows scheitern auf vorhersagbare Weise durch Timeouts, Retries, partielle Artefakte und unsicheres Abbrechen, und jede benötigt eine explizite Richtlinie statt ad-hoc-Handling im Client-Code.

Per-Hop und End-to-End Timeout-Budgets

Setzen Sie Timeouts auf zwei Ebenen: ein per-Hop-Maximum für einen Agenten-Task vor Eskalation oder Abbruch, und ein End-to-End-Maximum für den benutzersichtbaren Workflow. Ein Retrieval-Agent, der hängt, sollte nicht den gesamten Orchestrator blockieren, bis der Browser des Benutzers timeoutt.

Retries und Idempotenz für A2A-Tasks

Retries ohne Idempotenz duplizieren Seiteneffekte wie Doppelzahlungen, doppelte Tickets und wiederholte E-Mails. Verwenden Sie stabile Client-Nachrichten-IDs oder Idempotenz-Schlüssel, wo das Protokoll es erlaubt, und für Business-Mutationen richten Sie sich nach Idempotency in Distributed Systems That Actually Works. Wiederholen Sie nur transiente Fehler wie Netzwerkblips oder 503s, und wiederholen Sie nicht blind rejected oder Richtlinienerfolge, da Sie Kosten amplifizieren und downstream-Agenten nerven werden.

Richtlinien für partielle Artefakt-Wiederherstellung

Wenn ein Task nach dem Erzeugen partieller Artefakte fehlschlägt, definieren Sie, ob Sie partielle Ausgabe dem Benutzer mit einem klaren “unvollständig”-Label aussetzen, Fortsetzen vom letzten guten Checkpoint erlauben oder partielle Ausgabe verwerfen, wenn sie in medizinischen, rechtlichen oder finanziellen Kontexten irreführend sein könnte.

Sicheres Abbrechen über Delegation-Ketten hinweg

Brechen Sie downstream-Tasks ab, wenn ein upstream-Benutzer abbricht, verwenden Sie einen Delegationsgraphen, sodass Abbruch propagiert, und protokollieren Sie abgebrochene Tasks, die bereits Kosten verursacht haben, da Finance-Teams das bemerken.

Observability für asynchrone A2A-Workflows

Sie können Multi-Agenten-Async-Arbeit nicht debuggen, es sei denn, Sie können sie über Grenzen hinweg nachverfolgen, was bedeutet, Identifikatoren auf jedem Hop zu korrelieren, anstatt sich auf unstrukturierte Logs zu verlassen. Minimale Korrelationsfelder umfassen eine trace ID pro benutzerinitiierten Workflow, eine task ID pro Agenten-Task einschließlich delegierter Kinder, eine agent ID für die Agent Card oder den Dienst, der den Hop gehandhabt hat, und eine parent task ID, die Delegation-Ketten verknüpft.

Protokollieren Sie jede Statusübergang mit Zeitstempeln, und protokollieren Sie Artefakt-Erzeugungsereignisse mit Größe und Hash, nicht unbedingt mit vollem Inhalt, wenn PII-Richtlinien gelten. Attribuieren Sie Kosten und Latenz pro Hop, da Multi-Agenten-Workflows Token-Ausgaben verstecken, bis die Rechnung ankommt, und per-Task-Kostenlabels “Welcher Spezialist ist teuer?” beantwortbar machen. Für Metriken, Tracing-Backends und LLM-spezifische Instrumentierungsmuster siehe Observability for LLM Systems und die breitere Observability-Säule, wie diese Signale in einen produktiven Telemetrie-Stack passen. Wenn ein Benutzer fragt “Warum hat der Agent das getan?”, sollte Ihre Antwort ein Trace sein, der Orchestrator, A2A-Hops, MCP-Tool-Aufrufe und alle input_required-Pausen umspannt, anstatt ein Schultern und ein Log-Grep.

Produktions-Checkliste für A2A-Streaming und asynchrone Tasks

Bevor Sie langlaufende A2A-Pfade in die Produktion bringen, verifizieren Sie die folgenden Bereiche.

Agent Card und Fähigkeiten

• capabilities.streaming spiegelt tatsächliche SSE-Unterstützung wider
• Push-Benachrichtigungsunterstützung dokumentiert, wenn implementiert
• Skills, die menschliche Genehmigung erfordern, dokumentieren erwartetes input_required-Verhalten

Client-Modi

• SSE-Client handhabt Neuabonnement via SubscribeToTask
• Poll-Intervall backt unter Last ab
• Push-Webhook verifiziert Authentizität und lehnt veraltete Ereignisse ab

Dauerhaftigkeit

• Task-Status überlebt Agenten-Prozess-Neustarts
• Artefakte außerhalb des ephemeren Container-Dateisystems gespeichert
• Zwischenartefakte verfügbar für partielle Wiederherstellung

Fehler und Richtlinien

• Per-Hop und End-to-End Timeout-Budgets definiert
• Retries idempotent für mutierende Operationen
• Abbruch propagiert über Delegation-Kanten hinweg

Observability

• trace ID + task ID + agent ID auf jedem Hop
• Statusübergänge protokolliert
• Kostenattributierung pro Task oder pro Agent

Lasttests

• SSE durch Ihren Reverse-Proxy (Puffern bricht Streams)
• Konkurrierende lange Tasks ohne Memory-Leaks auf offenen Verbindungen
• Push-Flut-Handling ohne Webhook-Überlastung

Fazit

Der Wert von A2A zeigt sich am klarsten, wenn Arbeit nicht in einen einzelnen synchronen API-Aufruff passt, denn Streaming, asynchrone Tasks, Push-Benachrichtigungen und explizite Task-Zustände sind, wie das Protokoll echte Agenten-Workloads wie Forschung, Delegation, Genehmigungen und große Artefakte handhabt, ohne zu tun, als ob alles in einer HTTP-Roundtrip abgeschlossen wird. Beginnen Sie mit dem einfachsten Modus, der funktioniert, fügen Sie SSE hinzu, wenn Benutzer Live-Fortschritt benötigen, fügen Sie Push hinzu, wenn Verbindungen nicht offen bleiben können, behandeln Sie input_required als ein erstklassiges Design-Tool statt als einen Fehler, und instrumentieren Sie jeden Hop, sodass Multi-Agenten-Async-Workflows Ihre Fähigkeit, sie zu erklären, nicht überholen.

Häufig gestellte Fragen

Wann sollten Sie A2A-Streaming statt Polling verwenden? Verwenden Sie Streaming, wenn der Client eine offene HTTP-Verbindung halten kann und Sie Low-Latency-Fortschrittsupdates oder inkrementelle Artefakte benötigen. Verwenden Sie Polling, wenn Verbindungen unzuverlässig sind, Clients batch-orientiert sind oder Sie nur periodische Statusprüfungen auf langlaufenden Tasks benötigen.

Was bedeutet input_required in einem A2A-Task? Es ist ein Pause-Zustand, in dem der Agent mehr Informationen oder menschliche Genehmigung benötigt. Designen Sie UX und Timeouts explizit darum herum, anstatt es als Fehler zu behandeln.

Wie funktionieren A2A Push-Benachrichtigungen? Registrieren Sie eine PushNotificationConfig mit einem HTTPS-Webhook. Der Server POSTet bei signifikanten Updates; der Client ruft GetTask auf, um vollständigen Status und Artefakte abzurufen.

Wie sollten Sie gescheiterte A2A-Tasks wiederholen? Wiederholen Sie transiente Fehler mit Idempotenz-Schlüsseln, respektieren Sie Timeout-Budgets und wiederholen Sie nicht blind terminale Zustände wie rejected oder Richtlinienerfolge.

Was sollten Sie für langlaufende A2A-Workflows protokollieren? Korrelatieren Sie trace ID, task ID und agent ID über Hops hinweg. Protokollieren Sie Statusübergänge, Artefakte, Delegation, Genehmigungen und pro-Schritt-Kosten, sodass Sie den vollständigen Workflow rekonstruieren können.

Quellen

• 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/