Strumieniowanie A2A i zadania asynchroniczne w długotrwałych przepływach pracy agentów

Większość demonstracji agentów AI nadal zachowuje się jak ukończenia czatu z dodatkowymi krokami: wysyłasz prompt, czekasz kilka sekund i otrzymujesz odpowiedź w jednej wiadomości.

Praca prawdziwych agentów często nie pasuje do tego wzorca. Badania, przegląd kodu, analiza zakupów, dochodzenia incydentów oraz wieloetapowe planowanie mogą trwać minuty lub godziny, a w trakcie mogą wymagać wyjaśnień, przesyłania strumieniowego częściowych wyników, delegowania do innego agenta oraz generowania plików zamiast pojedynczej tekstowej odpowiedzi. W tym miejscu asynchroniczny model protokołu A2A nabiera znaczenia w szerszym klastrze Systemy AI, ponieważ A2A traktuje długotrwałą pracę jako Zadanie (Task) z cyklem życia, a nie jako jednorazową odpowiedź HTTP. Klienci mogą pozostać połączeni poprzez Server-Sent Events (SSE), odpytywać stan zadania lub rejestrować webhooki push, gdy nie mogą utrzymać otwartego połączenia.

Ten artykuł omawia projekt operacyjny tych przepływów pracy, w tym kiedy stosować strumieniowanie, odpytywanie lub push, jak input_required pasuje do przepływów z udziałem człowieka (human-in-the-loop), obsługę błędów oraz co należy instrumentować w środowisku produkcyjnym. Aby dowiedzieć się więcej o Kartach Agentów, wiadomościach, częściach i pełnym modelu zadań, zobacz Czym jest protokół A2A? Wyjaśnienie Kart Agentów i Zadań.

Dlaczego długotrwałe zadania agentów A2A wymagają projektowania asynchronicznego

Synchroniczny model mentalny żądania/odpowiedzi szybko się psuje, gdy praca agenta obejmuje narzędzia, delegowanie, zatwierdzenia i duże artefakty. Zadanie agenta może wewnętrznie wywoływać wiele serwerów MCP, delegować prace podrzędne do innego agenta przez A2A, czekać na zatwierdzenie człowieka, generować duże artefakty w częściach, niepowiodąc się w połowie i potrzebując częściowej odzyskiwania, oraz akumulować koszty tokenów przez kilka skoków. API HTTP mogą to przybliżać za pomocą limitów czasu, zadań tła i ad hoc punktów końcowych statusu, ale A2A wbudowuje tożsamość i stan zadania w protokół, aby klienci i bramki mogły konsekwentnie wnioskować o pracy. Aby dowiedzieć się, jak te warstwy pasują do asystenta produkcyjnego przed dodaniem asynchronicznych granic A2A, zobacz Architektura Asystenta AI: LLM, Pamięć, Narzędzia, Routing, Obserwowalność.

Moja praktyczna zasada brzmi: nie twórz Zadania dla wszystkiego, ponieważ jednowierszowe podsumowanie nie potrzebuje cyklu życia. Używaj Zadania, gdy praca jest stanowa, audytowalna, długotrwała, generująca artefakty lub może wymagać danych wejściowych w trakcie działania. Zasada kciuka z przewodnika nadal obowiązuje: proste interakcje mogą zwracać Wiadomość, podczas gdy złożona praca powinna zwracać Zadanie.

Cykl życia Zadania A2A i przejścia stanów

Zadanie A2A przechodzi przez stany, których klienci mogą zapytać w dowolnym momencie. Dokładna nazwa może nieznacznie różnić się w zależności od implementacji, ale model jest stabilny na serwerach zgodnych z protokołem.

Stan submitted (przesłane) oznacza, że klient wysłał pracę, a agent ją zaakceptował lub umieścił w kolejce. W stanie working (w trakcie), agent aktywnie przetwarza, co może obejmować wywołania narzędzi, delegowanie lub strumieniowanie częściowego wyjścia. Stan input_required (wymagane dane wejściowe) wskazuje, że agent został wstrzymany, ponieważ potrzebuje więcej danych, wyjaśnień lub zatwierdzenia człowieka, i nie jest to stan błędu. completed (ukończone) to terminalny sukces z dostępnymi artefaktami; failed (nieudane) to terminalny błąd, którego szczegóły i częściowe artefakty zależą od implementacji; canceled (anulowane) oznacza, że klient, bramka lub autoryzowany wywołujący zatrzymał zadanie; a rejected (odrzucone) oznacza, że agent odrzucił zadanie z powodu polityki, niezgodności możliwości lub uwierzytelniania.

Kiedy input_required wstrzymuje versus powoduje niepowodzenie przepływu pracy

Traktuj input_required jako celowy pause (przerwa), a nie wyjątek. Agent mówi Ci, że nie może kontynuować bez czegoś od Ciebie, czy to brakującego parametru, potwierdzenia polityki, czy zatwierdzenia menedżera dla akcji wysokiego ryzyka. Przepływ pracy niedziela się, gdy zadanie osiągnie failed lub rejected, lub gdy wywołujący przekroczy limit czasu oczekiwania na dane, które nigdy nie przyjdą, dlatego powinieneś projektować jawnie limity czasu dla kroków ludzkich, zamiast pozwalać zatwierdzeniom wisieć w nieskończoność.

Zatwierdzenie czekające trzy dni bez eskalacji to zablokowany przepływ pracy, a nie cierpliwy, a zablokowane przepływy pracy zatłaczą magazyny zadań, czyniąc tablice obserwowalności trudniejszymi do odczytu.

Kto może anulować zadanie A2A

Uprawnienia do anulowania powinny być zdefiniowane w czasie projektowania, a nie dyskutowane podczas incydentu. Klient zazwyczaj może anulować zadania, które utworzył; bramka może anulować w imieniu najemców, naruszeń polityki lub limitów budżetowych; a agent wyższego poziomu może anulować delegowaną pracę przy orkiestracji przez A2A, jeśli protokół i polityka na to pozwalają. Rejestruj, kto anulował i dlaczego, ponieważ w łańcuchach wieloagentowych sierota praca jest częstym źródłem niespodziewanych rachunków za tokeny.

Human-in-the-Loop ze stanami zadań input_required

input_required jest jedną z najbardziej niedocenianych funkcji projektowych A2A, a wiele zespołów traktuje ją jak kod błędu, podczas gdy w rzeczywistości jest to stan przepływu pracy pierwszego poziomu. W produkcji natkniesz się na przypadki, w których agent powinien zatrzymać, takie jak wydawanie budżetu na niejasne żądanie, wykonywanie nieodwracalnej akcji, dostęp do poufnych danych bez potwierdzenia zakresu lub delegowanie do specjalisty, który potrzebuje jawnego zamiaru użytkownika. Modeluj te przypadki jako celowe przejścia do input_required, z jasną wiadomością wyjaśniającą, co jest potrzebne.

Przepływy zatwierdzania dla ryzykownej delegacji A2A

Gdy Agent A deleguje do Agent B przez A2A, a Agent B wchodzi w input_required dla zatwierdzenia człowieka, trzy systemy muszą się zgodzić, co się stanie dalej. Agent dółowy wstrzymuje i ujawnia, czego potrzebuje, orkiestrator lub bramka przedstawia tę przerwę użytkownikowi, a odpowiedź użytkownika wznowia zadanie poprzez nową wiadomość. Porównanie A2A vs MCP wyjaśnia, dlaczego delegacja między granicami agentów jest innym problemem niż dostęp do narzędzi i dlaczego semantyka zatwierdzania należy do warstwy zadań, a nie do jednego wywołania MCP. Nie zatwierdzaj automatycznie milcząco, ponieważ UX jest niewygodny, ponieważ kosztowne błędy zwykle pochodzą z skrótów wygodnych, a nie z brakujących modeli.

Wzorce UX dla wstrzymanych zadań A2A

Blokuje odczekiwanie oznacza, że UI pokazuje spinner lub kartę zatwierdzenia, dopóki zadanie nie opuści input_required, co dobrze działa dla krótkich kroków ludzkich. Nieblokujące odczekiwanie oznacza, że klient zapisuje ID zadania, pozwala użytkownikowi kontynuować gdzie indziej i używa odpytywania lub push do powiadamiania, gdy ponownie będą potrzebne dane wejściowe, co jest wymagane dla mobilnych, zatwierdzeń powiązanych z emailem lub asystentów wielokartowych. Limit czasu, gdy ludzie są wolni oznacza zdefiniowanie SLA na krok i, po N godzinach, przejście do failed lub eskalację do innej kolejki, ponieważ nieograniczone oczekiwania zatłaczają magazyny zadań i mylą tablice obserwowalności.

Jak bramka A2A obsługuje input_required

Jeśli uruchamiasz bramkę A2A, zdecyduj, czy ona transparentnie przesyła zdarzenia input_required, agreguje przerwy z wielu agentów dółowych do jednego promptu użytkownika, czy wymusza, że pewne umiejętności zawsze wymagają zatwierdzenia przed opuszczeniem input_required. Autoryzacja i polityka dla zatwierdzonych akcji należą do dedykowanego artykułu bezpieczeństwa; na razie załóż, że każde wznowione zadanie powinno przenosić tę samą tożsamość użytkownika i zakres co oryginalne żądanie.

Wybór Sync, Strumieniowania SSE, Odpytywania lub Powiadomień Push

A2A obsługuje wiele trybów interakcji, a właściwy wybór zależy od możliwości klienta i potrzeb opóźnienia, a nie od tego, który tryb brzmi najnowocześniej.

Przeczytaj najpierw flagi możliwości Karty Agentów

Przed wyborem trybu, przeczytaj Kartę Agentów, ponieważ strumieniowanie wymaga capabilities.streaming: true, a wsparcie powiadomień push jest reklamowane osobno. Klienci, którzy zakładają, że każdy agent strumieniuje, zepsują się przeciwko minimalnym implementacjom, więc negocjacja nie jest ceremonią: zapobiega ona awariom w czasie działania, gdy specjalistyczny agent obsługuje tylko odpytywanie statusu.

Kiedy używać odpytywania po stronie asystenta wokół A2A

Twój runtime asystenta może opakowywać odpytywanie zadań A2A w pętli harmonogramu, zamiast wystawiać surowe szczegóły protokołu użytkownikowi. Ten wzorzek nachodzi się z ogólnymi agentami odpytującymi, które są procesami tła, które budzą się, sprawdzają stan i działają. Aby uzyskać trwałe harmonogramowanie, idempotencję i wzorce kolejek poza A2A, zobacz Odpytujące Agenty w Asystentach AI: 11 Wzorów Implementacji. Używaj odpytywania asystenta, gdy orkiestrujesz wiele zadań A2A z pojedynczej płaszczyzny kontrolnej, a używaj natywnego strumieniowania A2A lub push, gdy klient łączy się bezpośrednio z granicą agenta.

Strumieniowanie A2A Server-Sent Events (SSE)

SSE jest głównym kanałem czasu rzeczywistego A2A. Klient wywołuje SendStreamingMessage, otwiera połączenie HTTP i otrzymuje odpowiedź text/event-stream, dopóki zadanie nie osiągnie terminalnego lub przerwane stanu. Ciężar każdego zdarzenia ma kształt JSON-RPC, a typowe typy wyników obejmują migawkę Zadania, TaskStatusUpdateEvent dla przejść cyklu życia i pośrednich wiadomości agenta, oraz TaskArtifactUpdateEvent dla dostawy artefaktów w częściach z podpowiedziami append i lastChunk do złożenia.

Aktualizacje postępu strumieniowego i częściowe artefakty

Strumieniowanie błyszczy, gdy użytkownicy powinni widzieć pracę, czy to liczniki kroków (“3 z 7 źródeł sprawdzonych”), częściowe generowanie tekstu, przyrostowe części plików dla dużych raportów, czy przejścia stanów z working do input_required bez odpytywania. Projektuj UI wokół typów zdarzeń, a nie wokół pojedynczej końcowej bryły, ponieważ jeśli wyświetlasz wyjście tylko wtedy, gdy przyjdzie completed, możesz równie dobrze odpytywać.

Zrzuty połączeń SSE i ponowne subskrybowanie

Siecie padają, laptopy śpią, a load balancery mają limit czasu bezczynności połączeń SSE, więc długie strumienie potrzebują logiki odzyskiwania, a nie optymistycznych założeń. A2A dostarcza SubscribeToTask, aby klienci mogli ponownie połączyć się ze strumieniem zadania w trakcie, a Twój SDK klienta powinien utrzymywać taskId lokalnie, wykrywać zamknięcie strumienia przed stanem terminalnym, ponownie subskrybować z cofaniem (backoff) i usuwać duplikaty zdarzeń, jeśli serwer odtwarza nakładające się stany. Bez logiki ponownego subskrybowania, długie zadania wydają się kruche w produkcji, nawet gdy backend agenta jest zdrowy.

Powiadomienia Push i Webhooki A2A

Push pasuje do scenariuszy, w których SSE jest słabym dopasowaniem, takich jak aplikacje mobilne w tle, obsługacze serverless lub zadania trwające godziny lub dni. Klient dostarcza PushNotificationConfig z url (webhook HTTPS po stronie klienta), opcjonalnym token do weryfikacji przychodzących POSTów i opcjonalnymi szczegółami authentication dla tego, jak serwer A2A uwierzytelnia się do webhooka. Konfiguracja może podążyć wraz z początkowym wywołaniem SendMessage lub SendStreamingMessage, lub zostać dodana później przez CreateTaskPushNotificationConfig dla istniejącego zadania.

Gdy wystąpi znacząca aktualizacja, serwer A2A POSTuje do webhooka, a klient typowo wywołuje GetTask z powiadomionym taskId, aby pobrać pełne zaktualizowane Zadanie i artefakty. Push to sygnał, a nie pełny transport ładunku.

Kiedy push wygrywa z otwartym połączeniem SSE

Preferuj push, gdy klient nie może utrzymać SSE (mobilne, funkcje krawędziowe), gdy aktualizacje są rzadkie i oparte na kamieniach milowych, a nie token po tokenie, lub gdy chcesz, aby serwer obudził odłączony silnik przepływu pracy. Preferuj SSE, gdy użytkownicy oglądają postęp na żywo, gdy artefakty strumieniują się w wielu małych częściach, lub gdy opóźnienie poniżej kilku sekund ma znaczenie.

Korelowanie powiadomień push z zadaniami A2A

Każdy obsługacz push powinien rejestrować i propagować taskId, ślad lub ID korelacji z oryginalnego żądania, typ zdarzenia lub przejście stanu oraz znacznik czasu z powiadomienia, aby można było odrzucić przeterminowane zdarzenia. Ataki replay i duplikaty dostaw występują w produkcji, więc idempotentne obsługacze nie są opcjonalne.

Przegląd bezpieczeństwa punktów końcowych push

Push wprowadza ryzyko SSRF na serwerze, gdy złośliwi klienci rejestrują wewnętrzne URL-e, i ryzyko podszywania po stronie klienta, gdy fałszywe POST-y przychodzą do webhooka. Mitigacje obejmują listy dozwolonych URL-i, weryfikację własności, podpisane JWT z JWKS, kontrole znaczników czasu i weryfikację tokena konfiguracji. Pełny model zagrożeń, warstwy tożsamości i kontrole bramki znajdują się w Bezpieczeństwo Agentów A2A i MCP: Tożsamość, Delegowanie i Ślady Audytowe; dopóki tego nie przeczytasz, traktuj weryfikację webhooków z tą samą powagą co callbacki płatności.

Wzorce Asynchronicznych Przepływów Pracy A2A

Przesyłanie zadań w trybie “ognie i idź dalej”

Klient przesyła zadanie, natychmiast otrzymuje ID zadania i odłącza się, a później odpytuje GetTask lub czeka na push. Jest to domyślny wzorzec dla potoków serverless i wsadowych, ale powinieneś utrzymywać ID zadania w trwałym magazynie przed potwierdzeniem użytkownikowi, ponieważ wywołania serverless, które zapominają ID, tracą pracę.

Wznawianie zadania po input_required

Po input_required, użytkownik wysyła nową wiadomość przeciwko temu samemu zadaniu, a agent przechodzi z powrotem do working. Projektuj wiadomości tak, aby kontekst wznawiania był jawny, ponieważ “Zatwierdzono: kontynuuj z dostawcą X” wygrywa z gołym “tak”, gdy potrzebujesz audytować, co zostało zatwierdzone sześć godzin później.

Łańcuchowa delegacja A2A z pośrednimi artefaktami

Rozważ przepływ pracy badawczy, gdzie orkiestrator posiada Zadanie T1 i deleguje pobieranie, streszczanie i weryfikację do agentów specjalistów, każdy z własnym ID zadania i artefaktami w drodze.

Każdy skok ma własne ID zadania i maszynę stanów, więc orkiestrator powinien strumieniować lub odpytywać zadania dółowe niezależnie, utrzymywać pośrednie artefakty przed rozpoczęciem następnego skoku i łagodnie niepowiodąć się, jeśli T3 ukończy, ale T4 odrzuci projekt. Wzorce Orkiestracji Wieloagentowej omawia wybór topologii, gdy ci specjaliści działają jako oddzielne usługi, a nie w jednym runtime. Częściowy postęp jest cenny, a nieudana weryfikacja nie powinna usuwać użytecznego projektu bez jasnego powodu.

Trwały magazyn zadań dla opóźnionego ukończenia

Stan zadania i artefakty powinny przetrwać restarty procesów. Jeśli Twój agent działa w Kubernetes, załóż, że kontenery umierają w trakcie zadania i kopie zapasowe rekordów zadań oraz blobów artefaktów do magazynu, którego kontener agenta nie posiada wyłącznie.

Obsługa Błędów dla Długotrwałych Asynchronicznych Przepływów Pracy A2A

Długotrwałe przepływy pracy nie powiodą się w przewidywalny sposób przez limity czasu, ponowe próby, częściowe artefakty i niebezpieczne anulowanie, a każdy potrzebuje jawnej polityki, a nie ad hoc obsługi w kodzie klienta.

Budżety limitów czasu na skok i end-to-end

Ustaw limity czasu na dwóch poziomach: maksymalny na skok dla jednego zadania agenta przed eskalacją lub anulowaniem, oraz maksymalny end-to-end dla widocznego dla użytkownika przepływu pracy. Agent pobierania, który zawiesi się, nie powinien blokować całego orkiestratora, dopóki przeglądarka użytkownika nie wygaśnie.

Ponowe próby i idempotencja dla zadań A2A

Ponowe próby bez idempotencji duplikują skutki uboczne, takie jak podwójne opłaty, duplikaty biletów i powtarzające się e-maile. Używaj stabilnych ID wiadomości klienta lub kluczy idempotencji, gdzie protokół pozwala, a dla mutacji biznesowych zgodz się z Idempotencja w Systemach Dystrybuowanych, która Naprawdę Działa. Ponawiaj tylko przejściowe błędy, takie jak zakłócenia sieciowe lub 503, i nie ponawiaj ślepo odrzuconych lub błędów polityki, ponieważ powielisz koszt i irytujesz agentów dółowych.

Polityki odzyskiwania częściowych artefaktów

Gdy zadanie nie powiedzie się po wygenerowaniu częściowych artefaktów, zdefiniuj, czy ujawniasz częściowe wyjście użytkownikowi z jasną etykietą “niekompletna”, pozwalasz wznowić od ostatniego dobrego punktu kontrolnego, czy odrzucasz częściowe wyjście, gdy mogłoby mylić w kontekstach medycznych, prawnych lub finansowych.

Bezpieczne anulowanie przez łańcuchy delegacji

Anuluj zadania dółowe, gdy użytkownik wyższego poziomu przerywa, użyj grafu delegacji, aby anulowanie się propagowało, i rejestruj anulowane zadania, które już poniosły koszt, ponieważ zespoły finansowe to zauważą.

Obserwowalność dla Asynchronicznych Przepływów Pracy A2A

Nie możesz debugować asynchronicznej pracy wieloagentowej, chyba że możesz ją śledzić przez granice, co oznacza korelowanie identyfikatorów na każdym skoku, zamiast polegać na nieustrukturalizowanych logach. Minimalne pola korelacji obejmują ID śledzenia (trace ID) na przepływ pracy inicjowany przez użytkownika, ID zadania na zadanie agenta, w tym dzieci delegowane, ID agenta dla Karty Agentów lub usługi, która obsłużyła skok, oraz ID rodzica zadania, który łączy łańcuchy delegacji.

Rejestruj każde przejście stanu ze znacznikami czasu i rejestruj zdarzenia tworzenia artefaktów z rozmiarem i hashem, a nie koniecznie pełną zawartością, gdy obowiązują polityki PII. Atrybutuj koszt i opóźnienie na skok, ponieważ przepływy pracy wieloagentowe ukrywają wydatki tokenów, dopóki rachunek nie przyjdzie, a etykiety kosztu na zadanie czynią pytanie “który specjalista jest drogi?” odpowiadane. Aby uzyskać metryki, backi śledzenia i wzorce instrumentacji specyficzne dla LLM, zobacz Obserwowalność dla Systemów LLM i szerszy filar Obserwowalność, aby dowiedzieć się, jak te sygnały pasują do stosu telemetrii produkcyjnej. Gdy użytkownik pyta “dlaczego agent to zrobił?”, Twoja odpowiedź powinna być śladem obejmującym orkiestratora, skoki A2A, wywołania narzędzi MCP i wszelkie przerwy input_required, a nie skurcz i grep logów.

Lista Kontrolna Produkcyjna dla Strumieniowania A2A i Asynchronicznych Zadań

Przed wysłaniem długotrwałych ścieżek A2A do produkcji, zweryfikuj następujące obszary.

Karta Agentów i możliwości

• capabilities.streaming odzwierciedla rzeczywiste wsparcie SSE
• Wsparcie powiadomień push udokumentowane, jeśli zaimplementowane
• Umiejętności wymagające zatwierdzenia człowieka dokumentują oczekiwane zachowanie input_required

Tryby klienta

• Klient SSE obsługuje ponowne subskrybowanie przez SubscribeToTask
• Interwał odpytywania cofa się pod obciążeniem
• Webhook push weryfikuje autentyczność i odrzuca przeterminowane zdarzenia

Trwałość

• Stan zadania przetrzymuje restarty procesu agenta
• Artefakty przechowywane poza efemerycznym systemem plików kontenera
• Pośrednie artefakty dostępne dla częściowego odzyskiwania

Błędy i polityka

• Budżety limitów czasu na skok i end-to-end zdefiniowane
• Ponowe próby idempotentne dla operacji mutujących
• Anulowanie propaguje się przez krawędzie delegacji

Obserwowalność

• ID śledzenia + ID zadania + ID agenta na każdym skoku
• Przejścia stanów rejestrowane
• Atrybucja kosztu na zadanie lub na agenta

Testy obciążeniowe

• SSE przez Twój reverse proxy (buforowanie psuje strumienie)
• Konkurencyjne długie zadania bez wycieków pamięci na otwartych połączeniach
• Obsługa powodzi push bez przeciążenia webhooka

Wniosek

Wartość A2A pojawia się najbardziej wyraźnie, gdy praca nie pasuje do pojedynczego synchronicznego wywołania API, ponieważ strumieniowanie, asynchroniczne zadania, powiadomienia push i jawne stany zadań są tym, jak protokół obsługuje rzeczywiste obciążenia agentów, takie jak badania, delegowanie, zatwierdzenia i duże artefakty, bez udawania, że wszystko kończy się w jednej rundzie HTTP. Zacznij od najprostszej metody, która działa, dodaj SSE, gdy użytkownicy potrzebują postępu na żywo, dodaj push, gdy połączenia nie mogą pozostać otwarte, traktuj input_required jako narzędzie projektowe pierwszego poziomu, a nie awarię, i instrumentuj każdy skok, aby asynchroniczne przepływy pracy wieloagentowe nie wyprzedziły Twojej zdolności do ich wyjaśnienia.

Często Zadawane Pytania

Kiedy należy używać strumieniowania A2A zamiast odpytywania? Używaj strumieniowania, gdy klient może utrzymać otwarte połączenie HTTP i potrzebujesz aktualizacji postępu o niskim opóźnieniu lub przyrostowych artefaktów. Używaj odpytywania, gdy połączenia są niezawodne, klienci są zorientowani na wsady, lub potrzebujesz tylko okresowych kontroli statusu długotrwałych zadań.

Co oznacza input_required w zadaniu A2A? Jest to stan pauzy, w którym agent potrzebuje więcej informacji lub zatwierdzenia człowieka. Projektuj UX i limity czasu wokół niego jawnie, zamiast traktować go jak błąd.

Jak działają powiadomienia push A2A? Zarejestruj PushNotificationConfig z webhookiem HTTPS. Serwer POSTuje przy znaczących aktualizacjach; klient wywołuje GetTask, aby pobrać pełny stan i artefakty.

Jak należy ponawiać nieudane zadania A2A? Ponawiaj przejściowe błędy z kluczami idempotencji, szanuj budżety limitów czasu i nie ponawiaj ślepo stanów terminalnych, takich jak odrzucone lub błędy polityki.

Co należy rejestrować dla długotrwałych przepływów pracy A2A? Koreluj ID śledzenia, ID zadania i ID agenta przez skoki. Rejestruj przejścia stanów, artefakty, delegację, zatwierdzenia i koszt na krok, abyś mógł odtworzyć pełny przepływ pracy.

Źródła

• Protokół A2A – Strumieniowanie i Operacje Asynchroniczne: https://a2a-protocol.org/latest/topics/streaming-and-async/
• Protokół A2A – Przegląd specyfikacji: https://a2a-protocol.org/latest/specification/