긴 실행 시간 에이전트 워크플로우를 위한 A2A 스트리밍 및 비동기 작업

대부분의 AI 에이전트 데모는 여전히 몇 가지 추가 단계를 거친 채팅 완성(chat completion)과 비슷하게 작동합니다. 프롬프트를 보내고 몇 초를 기다린 후, 하나의 응답으로 답변을 받습니다.

실제 에이전트의 작업은 이러한 패턴에 잘 맞지 않는 경우가 많습니다. 연구, 코드 리뷰, 조달 분석, 사건 조사, 다단계 계획 수립 등의 작업은 수분에서 수시간까지 걸릴 수 있으며, 중간에 명확한 설명이 필요하거나 부분적인 결과를 스트리밍하거나, 다른 에이전트로 위임하거나, 단일 텍스트 응답 대신 파일을 생성해야 할 수 있습니다. 이것이 A2A 프로토콜의 비동기(async) 모델이 광범위한 AI 시스템 클러스터 내에서 중요한 이유입니다. A2A는 일회성 HTTP 응답이 아닌, 생명주기를 가진 **Task(작업)**로 장기 실행 작업을 취급합니다. 클라이언트는 Server-Sent Events(SSE)를 통해 연결을 유지하거나, 작업 상태를 폴링(poll)하거나, 연결을 열어서 유지할 수 없을 때 푸시 웹훅을 등록할 수 있습니다.

이 기사에서는 이러한 워크플로우의 운영 설계, 스트리밍과 폴링, 푸시 사용 시점, input_required가 인간 참여(Human-in-the-loop) 흐름에 어떻게 부합하는지, 실패 처리 방법, 그리고 프로덕션 환경에서 어떤 부분을 계측(instrument)해야 하는지 등을 다룹니다. Agent Cards, 메시지,.parts 및 전체 작업 모델에 대해서는 A2A 프로토콜이란 무엇인가? 에이전트 카드와 작업 설명를 참조하세요.

장기 실행 A2A 에이전트 작업이 비동기 설계가 필요한 이유

에이전트 작업이 도구 사용, 위임, 승인, 대형 아티팩트 생성을跨越하는 순간, 동기식 요청/응답 mental model은 빠르게 붕괴됩니다. 에이전트 작업은 내부적으로 여러 MCP 서버를 호출하거나, A2A를 통해 하위 작업을 다른 에이전트로 위임하거나, 인간 승인을 기다리거나, 청크 단위로 대형 아티팩트를 생성하거나, 중간에 실패하여 부분적 복구가 필요하거나, 여러 홉(hop)에 걸쳐 토큰 비용이 누적될 수 있습니다. HTTP API는 타임아웃, 백그라운드 작업, 임기응변식 상태 엔드포인트로 이를 근사할 수 있지만, A2A는 작업 식별자와 상태를 프로토콜 자체에 내장하여 클라이언트와 게이트웨이가 작업을 일관되게 추론할 수 있게 합니다. 비동기 A2A 경계를 추가하기 전에 이러한 레이어들이 프로덕션 어시스턴트 내부에 어떻게 배치되는지 확인하려면 AI 어시스턴트 아키텍처: LLM, 메모리, 도구, 라우팅, 가시성을 참조하세요.

저의 실용적인 편향은 다음과 같습니다: 모든 것에 Task를 생성하지 마세요. 한 줄 요약에는 생명주기가 필요하지 않습니다. 작업이 상태(stateful)를 유지해야 하거나, 감사(audit)가 필요하거나, 장기 실행되거나, 아티팩트를 생성하거나, 중간에 입력이 필요할 가능성이 있을 때 Task를 사용하십시오. 설명서에서 제시된 경험 법칙은 여전히 유효합니다: 단순한 상호작용은 Message를 반환하고, 복잡한 작업은 Task를 반환해야 합니다.

A2A 작업 생명주기와 상태 전환

A2A Task는 클라이언트가 언제든지 쿼리할 수 있는 상태를 거칩니다. 정확한 명칭은 구현체에 따라 약간 다를 수 있지만, 프로토콜을 따르는 서버 전반에서 모델은 안정적입니다.

submitted(제출됨) 상태는 클라이언트가 작업을 보내고 에이전트가 이를 수락하거나 큐에 넣었음을 의미합니다. working(작업 중) 상태는 에이전트가 적극적으로 처리 중이며, 도구 호출, 위임 또는 부분 출력 스트리밍을 포함할 수 있습니다. input_required(입력 필요) 상태는 에이전트가 추가 입력, 명확화 또는 인간 승인이 필요하여 일시 중단되었음을 나타내며, 이는 실패 상태가 아닙니다. **completed(완료)**는 아티팩트가 사용 가능한 최종 성공 상태이고, **failed(실패)**는 세부 사항과 부분적 아티팩트가 구현체에 의존하는 최종 오류 상태입니다. **canceled(취소됨)**은 클라이언트, 게이트웨이 또는 권한 있는 호출자가 작업을 중단했음을 의미하며, **rejected(거절됨)**은 정책, 기능 불일치 또는 인증 문제로 에이전트가 작업을 거절했음을 의미합니다.

input_required가 워크플로우를 일시 중단하는 시점 vs 실패하는 시점

input_required를 예외가 아닌 의도적인 일시 중단으로 취급하십시오. 에이전트는 누락된 매개변수, 정책 확인 또는 고위험 작업에 대한 관리자의 승인 등 사용자의 개입 없이 진행할 수 없음을 알려주는 것입니다. 워크플로우는 작업이 failed 또는 rejected에 도달하거나, 호출자가 도착하지 않는 입력을 기다리다가 타임아웃을 초과할 때 실패합니다. 따라서 승인이 무한정 방치되지 않도록 인간 단계에 대한 명시적인 타임아웃을 설계해야 합니다.

에스컬레이션 없이 3일 동안 기다리는 승인은 인내심이 있는 워크플로우가 아니라 고착된(stuck) 워크플로우이며, 고착된 워크플로우는 작업 저장소를 막고 가시성 대시보드를 읽기 어렵게 만듭니다.

A2A 작업 취소 권한

취소 권한은 사건 발생 시 논의하기보다 설계 시 정의되어야 합니다. 일반적으로 클라이언트는 자신이 생성한 작업을 취소할 수 있으며, 게이트웨이는 테넌트, 정책 위반 또는 예산 한도를 대신하여 취소할 수 있습니다. 그리고 상위 에이전트는 프로토콜과 정책이 허용한다면 A2A를 통해 오케스트레이션 중 위임된 작업을 취소할 수 있습니다. 취소한 주체와 이유를 로깅해야 합니다. 다중 에이전트 체인에서는 고아 작업(orphan work)이 예상치 못한 토큰 비용의 일반적인 원인이 되기 때문입니다.

input_required 작업 상태와 인간 참여(Human-in-the-Loop)

input_required는 A2A의 가장 과소평가된 설계 기능 중 하나이며, 많은 팀이 이를 오류 코드로 취급하지만 실제로는 일급 워크플로우 상태입니다. 프로덕션 환경에서는 에이전트가 정지해야 하는 경우가 발생합니다. 예를 들어 모호한 요청에 예산을 소모하거나, 되돌릴 수 없는 작업을 실행하거나, 범위 확인 없이 민감한 데이터에 접근하거나, 명시적인 사용자 의도가 필요한 전문 에이전트로 위임하는 경우 등입니다. 이러한 경우를 input_required로의 의도적인 전환으로 모델링하고, 무엇이 필요한지 설명하는 명확한 메시지를 제공해야 합니다.

위험한 A2A 위임을 위한 승인 흐름

에이전트 A가 A2A를 통해 에이전트 B로 위임하고 에이전트 B가 인간 승인을 위해 input_required에 진입할 때, 세 시스템이 다음 조치에 대해 동의해야 합니다. 하위 에이전트는 일시 중단되고 필요한 사항을 노출하며, 오케스트레이터 또는 게이트웨이는 사용자에게 해당 일시 중단을 표면화하고, 사용자의 응답이 새 메시지를 통해 작업을 재개합니다. A2A vs MCP 비교는 에이전트 경계를 넘어선 위임이 도구 접근과 다른 문제이며, 승인 의미론이 단일 MCP 호출 내부가 아닌 작업 레이어에 속해야 하는 이유를 설명합니다. UX가 불편하다고 해서 침묵하며 자동 승인하지 마십시오. 비용이 큰 실수는 종종 누락된 모델보다 편의성 단축키에서 비롯되기 때문입니다.

일시 중단된 A2A 작업을 위한 UX 패턴

**차단 대기(Blocking wait)**는 작업이 input_required에서 벗어나기까지 UI가 로딩 화면이나 승인 카드를 표시하는 것을 의미하며, 짧은 인간 단계에 적합합니다. **비차단 대기(Non-blocking wait)**는 클라이언트가 작업 ID를 기록하고 사용자에게 다른 작업을 계속하게 하며, 입력이 다시 필요할 때 폴링이나 푸시를 사용하여 알림을 보내는 것을 의미하며, 모바일, 이메일 연결 승인 또는 다중 탭 어시스턴트에 필요합니다. 인간이 느릴 때의 타임아웃은 단계별 SLA를 정의하고, N시간 후 failed로 전환하거나 다른 큐로 에스컬레이션하는 것을 의미합니다. 무한대기는 작업 저장소를 막고 가시성 대시보드를 혼란스럽게 만들기 때문입니다.

A2A 게이트웨이가 input_required를 처리하는 방법

A2A 게이트웨이를 운영한다면, 게이트웨이가 input_required 이벤트를 투명하게 전달할지, 여러 하위 에이전트의 일시 중단을 하나의 사용자 프롬프트로 집계할지, 또는 특정 기술이 input_required를 떠날 때 항상 승인이 필요하도록 강제할지 결정해야 합니다. 승인된 작업에 대한 인증 및 정책은 전용 보안 기사에 속하므로, 현재는 재개된 모든 작업이 원래 요청과 동일한 사용자 정체성과 범위를 가져야 한다고 가정하십시오.

동기, SSE 스트리밍, 폴링 또는 푸시 알림 선택

A2A는 여러 상호작용 모드를 지원하며, 올바른 선택은 가장 현대적으로 들리는 모드가 아닌 클라이언트 기능과 지연 시간 요구 사항에 따라 달라집니다.

에이전트 카드 기능 플래그 먼저 읽기

모드를 선택하기 전에 에이전트의 에이전트 카드를 읽어야 합니다. 스트리밍에는 capabilities.streaming: true가 필요하며 푸시 알림 지원은 별도로 광고됩니다. 모든 에이전트가 스트리밍한다고 가정하는 클라이언트는 최소한의 구현체에서 실패하므로, 협상은 형식이 아닙니다. 이는 전문 에이전트가 폴링 기반 상태 확인만 지원할 때 런타임 실패를 방지합니다.

A2A 주변의 어시스턴트 측 폴링 사용 시점

어시스턴트 런타임은 원시 프로토콜 세부 사항을 사용자에게 노출하기보다 스케줄러 루프에서 A2A 작업 폴링을 래핑할 수 있습니다. 이 패턴은 상태를 확인하고 행동하는 배경 프로세스인 일반적인 폴링 에이전트와 겹칩니다. A2A 외의 내구성 스케줄링, 멱등성, 큐 패턴에 대해서는 AI 어시스턴트의 폴링 에이전트: 11가지 구현 패턴를 참조하세요. 단일 제어 평면에서 여러 A2A 작업을 오케스트레이션할 때 어시스턴트 폴링을 사용하고, 클라이언트가 에이전트 경계에 직접 연결될 때 네이티브 A2A 스트리밍이나 푸시를 사용하십시오.

A2A 서버 전송 이벤트(SSE) 스트리밍

SSE는 A2A의 주요 실시간 채널입니다. 클라이언트는 SendStreamingMessage를 호출하고 HTTP 연결을 열며, 작업이 최종 또는 중단된 상태에 도달할 때까지 text/event-stream 응답을 받습니다. 각 이벤트의 페이로드는 JSON-RPC 형태이며, 일반적인 결과 유형에는 Task 스냅샷, 생명주기 전환 및 중간 에이전트 메시지를 위한 TaskStatusUpdateEvent, 재조립을 위한 append 및 lastChunk 힌트가 있는 청크 단위의 아티팩트 전송을 위한 TaskArtifactUpdateEvent가 포함됩니다.

스트리밍 진행 상황 업데이트 및 부분 아티팩트

사용자가 작업이 이루어지는 것을 볼 수 있을 때 스트리밍이 빛을 발합니다. 이는 단계 카운터(“7개 중 3개 소스 검토”), 부분 텍스트 생성, 대형 리포트의 점진적 파일 청크, 또는 폴링 없이 working에서 input_required로의 상태 전환을 의미할 수 있습니다. 단일 최종 blob이 아닌 이벤트 유형을 중심으로 UI를 설계해야 합니다. completed가 도달했을 때만 출력을 표시한다면 폴링하는 것과 같기 때문입니다.

SSE 연결 끊김 및 재구독

네트워크가 끊기고, 노트북이 절전 모드가 되며, 로드 밸런서가 SSE 연결을 유휴 타임아웃하므로, 긴 스트림은 낙관적인 가정보다 복구 논리가 필요합니다. A2A는 클라이언트가 진행 중인 작업 스트림에 다시 연결할 수 있도록 SubscribeToTask를 제공합니다. 클라이언트 SDK는 로컬에 taskId를 지속 저장하고, 최종 상태 이전에 스트림 종료를 감지하며, 백오프(backoff)로 재구독하고, 서버가 겹치는 상태를 재생할 경우 이벤트를 중복 제거해야 합니다. 재구독 논리가 없으면 에이전트 백엔드가 건강하더라도 프로덕션에서 장기 작업이 취약해집니다.

A2A 푸시 알림 및 웹훅

푸시는 백그라운드 모바일 앱, 서버리스 핸들러, 수시간 또는 수일 동안 실행되는 작업 등 SSE가 적합하지 않은 시나리오에 적합합니다. 클라이언트는 url(클라이언트 측 HTTPS 웹훅), incoming POST 검증용 선택적 token, 그리고 A2A 서버가 웹훅에 인증하는 방법을 위한 선택적 authentication 세부 사항과 함께 PushNotificationConfig를 제공합니다. 구성은 초기 SendMessage 또는 SendStreamingMessage 호출과 함께 전달되거나, 기존 작업에 대해 CreateTaskPushNotificationConfig를 통해 나중에 추가될 수 있습니다.

중요한 업데이트가 발생하면 A2A 서버는 웹훅으로 POST를 보내며, 클라이언트는 일반적으로 알림 받은 taskId로 GetTask를 호출하여 전체 업데이트된 Task와 아티팩트를 가져옵니다. 푸시는 전체 페이로드 전송이 아닌 신호입니다.

열린 SSE 연결보다 푸시가 우월한 시점

클라이언트가 SSE를 유지할 수 없을 때(모바일, 에지 함수), 업데이트가 토큰별이 아닌 드물고 마일스톤 기반일 때, 또는 서버가 연결 끊긴 워크플로우 엔진을 깨우고 싶을 때 푸시를 선호하십시오. 사용자가 진행 상황을 실시간으로 볼 때, 아티팩트가 많은 작은 청크로 스트리밍될 때, 또는 몇 초 미만의 지연 시간이 중요할 때 SSE를 선호하십시오.

푸시 알림과 A2A 작업 상관관계 설정

모든 푸시 핸들러는 taskId, 원래 요청의 추적 또는 상관 ID, 이벤트 유형 또는 상태 전환, 그리고 오래된 이벤트를 거부할 수 있는 알림의 타임스탬프를 로깅하고 전파해야 합니다. 재생 공격과 중복 전달은 프로덕션에서 발생하므로 멱등성 핸들러는 선택 사항이 아닙니다.

푸시 엔드포인트 보안 개요

푸시는 악의적인 클라이언트가 내부 URL을 등록할 때 서버에서 SSRF 위험을, 가짜 POST가 웹훅에 도달할 때 클라이언트에서 사칭 위험을 초래합니다. 완화 방법에는 URL 허용 목록, 소유권 검증, JWKS가 있는 서명된 JWT, 타임스탬프 확인, 구성 토큰 검증이 포함됩니다. 전체 위협 모델, 정체성 레이어, 게이트웨이 제어는 A2A 및 MCP 에이전트 보안: 정체성, 위임 및 감사 추적에 있으므로, 이를 읽기 전까지 웹훅 검증을 결제 콜백과同样的 seriously 취급하십시오.

비동기 A2A 워크플로우 패턴

방사 후 추적(Fire-and-follow) 작업 제출

클라이언트는 작업을 제출하고 즉시 작업 ID를 받아 연결을 끊은 후, 나중에 GetTask를 폴링하거나 푸시를 기다립니다. 이는 서버리스 및 배치 파이프라인의 기본 패턴이지만, 서버리스 호출이 ID를 잊으면 작업이 손실되므로 사용자에게 응답하기 전에 작업 ID를 내구성 저장소에 지속 저장해야 합니다.

input_required 후 작업 재개

input_required 후, 사용자는 동일한 작업에 대해 새 메시지를 보내며 에이전트는 working으로 전환됩니다. 재개 컨텍스트가 명시적이도록 메시지를 설계해야 합니다. “승인: 벤더 X로 진행"이 6시간 후 무엇을 승인했는지 감사할 때 단순한 “예"보다 우수합니다.

중간 아티팩트와 함께 체인화된 A2A 위임

오케스트레이터가 작업 T1을 소유하고 검색, 요약, 검증 작업을 전문 에이전트에게 위임하는 연구 워크플로우를 고려해 보십시오. 각 에이전트는 자체 작업 ID와 아티팩트를 가집니다.

각 홉은 자체 작업 ID와 상태 머신을 가지므로, 오케스트레이터는 하위 작업을 독립적으로 스트리밍하거나 폴링하고, 다음 환을 시작하기 전에 중간 아티팩트를 지속 저장하며, T3가 완료되지만 T4가 초안을 거부할 때 우아하게 실패해야 합니다. 다중 에이전트 오케스트레이션 패턴은 이러한 전문가가 단일 런타임이 아닌 별도 서비스로 실행될 때 토폴로지 선택을 다룹니다. 부분적 진행 상황은 가치가 있으며, 실패한 검증은 명확한 이유 없이 사용 가능한 초안을 삭제해서는 안 됩니다.

지연 완성을 위한 내구성 작업 저장소

작업 상태와 아티팩트는 프로세스 재시작을 살아남아야 합니다. 에이전트가 Kubernetes에서 실행된다면, 포드가 작업 중간에 죽는다고 가정하고 작업 기록과 아티팩트 블롭을 에이전트 컨테이너가 독점적으로 소유하지 않는 저장소로 백업해야 합니다.

장기 실행 A2A 워크플로우의 실패 처리

장기 실행 워크플로우는 타임아웃, 재시도, 부분 아티팩트, 안전하지 않은 취소 등을 통해 예측 가능한 방식으로 실패하며, 각각은 클라이언트 코드에서의 임기응변식 처리가 아닌 명시적인 정책이 필요합니다.

환별 및 종단 간 타임아웃 예산

두 수준에서 타임아웃을 설정하십시오: 에스컬레이션 또는 취소 전 하나의 에이전트 작업에 대한 환별(per-hop) 최대값과, 사용자 가시적 워크플로우에 대한 종단 간(end-to-end) 최대값. 멈춰 있는 검색 에이전트는 사용자의 브라우저가 타임아웃될 때까지 전체 오케스트레이터를 블록해서는 안 됩니다.

A2A 작업을 위한 재시도 및 멱등성

멱등성 없이 재시도하면 이중 청구, 중복 티켓, 반복 이메일과 같은 부수 효과가 중복됩니다. 프로토콜이 허용하는 곳에 안정적인 클라이언트 메시지 ID 또는 멱등성 키를 사용하고, 비즈니스 변경 사항의 경우 실제로 작동하는 분산 시스템의 멱등성과 일치하십시오. 네트워크 일시 중단 또는 503과 같은 일시적 실패만 재시도하고, rejected 또는 정책 실패를 맹목적으로 재시도하지 마십시오. 그러면 비용이 증폭되고 하위 에이전트가 번거로워집니다.

부분 아티팩트 복구 정책

작업이 부분 아티팩트를 생성한 후 실패할 때, “불완전” 레이블과 함께 부분 출력을 사용자에게 공개할지, 마지막 좋은 체크포인트에서 재개를 허용할지, 의료, 법률, 금융 맥락에서 오인할 수 있을 때 부분 출력을 버릴지 정의하십시오.

위임 체인 전반의 안전한 취소

상위 사용자가 중단할 때 하위 작업을 취소하고, 취소가 전파되도록 위임 그래프를 사용하며, 이미 비용이 발생한 취소된 작업을 로깅하십시오. 재무 팀은 이를 알아차립니다.

비동기 A2A 워크플로우를 위한 가시성(Observability)

경계를 가로지르는 추적이 가능하지 않으면 다중 에이전트 비동기 작업을 디버깅할 수 없으며, 이는 구조화되지 않은 로그에 의존하기보다 각 환에서 식별자를 상관관계 설정하는 것을 의미합니다. 최소 상관관계 필드에는 사용자 시작한 워크플로우별 추적 ID(trace ID), 위임된 자식을 포함한 에이전트 작업별 작업 ID(task ID), 환을 처리한 에이전트 카드 또는 서비스의 에이전트 ID(agent ID), 위임 체인을 연결하는 **부모 작업 ID(parent task ID)**가 포함됩니다.

타임스탬프와 함께 모든 상태 전환을 로깅하고, PII 정책이 적용될 때 전체 콘텐츠가 아닌 크기와 해시로 아티팩트 생성 이벤트를 로깅하십시오. 환별 비용과 지연 시간을 속성화해야 합니다. 다중 에이전트 워크플로우는 청구서가 도착할 때까지 토큰 지출을 숨기며, 작업별 비용 레이블은 “어떤 전문가가 비싼가?“라는 질문에 답할 수 있게 합니다. 지표, 추적 백엔드, LLM 전용 계측 패턴에 대해서는 LLM 시스템의 가시성 및 이러한 신호가 프로덕션 텔레메트리 스택에 어떻게 부합하는지에 대한 더 넓은 가시성 기둥을 참조하십시오. 사용자가 “에이전트가 왜 그렇게 했는가?“라고 물을 때, 답변은 오케스트레이터, A2A 환, MCP 도구 호출 및 모든 input_required 일시 중단을 포함하는 추적이 되어야 하며, 어깨를 으쓱하고 로그를 grep하는 것이 되어서는 안 됩니다.

A2A 스트리밍 및 비동기 작업을 위한 프로덕션 체크리스트

장기 실행 A2A 경로를 프로덕션에 출시하기 전에 다음 영역을 확인하십시오.

에이전트 카드 및 기능

• capabilities.streaming이 실제 SSE 지원을 반영함
• 구현된 경우 푸시 알림 지원 문서화됨
• 인간 승인이 필요한 기술이 예상되는 input_required 동작을 문서화함

클라이언트 모드

• SSE 클라이언트가 SubscribeToTask를 통해 재구독 처리함
• 폴링 간격이 부하 하에서 백오프함
• 푸시 웹훅이 진위성을 검증하고 오래된 이벤트를 거부함

내구성

• 작업 상태가 에이전트 프로세스 재시작을 살아남음
• 아티팩트가 임시 컨테이너 파일 시스템 외부에 저장됨
• 부분 복구를 위한 중간 아티팩트 사용 가능

실패 및 정책

• 환별 및 종단 간 타임아웃 예산 정의됨
• 변경 작업에 대한 재시도가 멱등적임
• 취소가 위임 경계를 가로지름

가시성

• 각 환에 추적 ID + 작업 ID + 에이전트 ID
• 상태 전환 로깅됨
• 작업별 또는 에이전트별 비용 귀속

부하 테스트

• 리버스 프록시를 통한 SSE (버퍼링이 스트림을 끊음)
• 열린 연결에서 메모리 누출 없이 동시 장기 작업
• 웹훅 과부하 없이 푸시 홍수 처리

결론

A2A의 가치는 작업이 단일 동기식 API 호출에 맞지 않을 때 가장 명확하게 드러납니다. 스트리밍, 비동기 작업, 푸시 알림, 명시적 작업 상태는 연구, 위임, 승인, 대형 아티팩트와 같은 실제 에이전트 워크로드가 모든 것이 하나의 HTTP 라운드 트립으로 완료된다고 가장하지 않고 처리하는 방법입니다. 작동하는 가장 단순한 모드로 시작하고, 사용자가 실시간 진행 상황을 필요로 할 때 SSE를 추가하고, 연결을 열어서 유지할 수 없을 때 푸시를 추가하며, input_required를 실패가 아닌 일급 설계 도구로 취급하고, 다중 에이전트 비동기 워크플로우가 설명 능력을 능가하지 않도록 각 환을 계측하십시오.

자주 묻는 질문

언제 폴링 대신 A2A 스트리밍을 사용해야 합니까? 클라이언트가 열린 HTTP 연결을 유지할 수 있고 낮은 지연 시간의 진행 상황 업데이트 또는 점진적 아티팩트가 필요할 때 스트리밍을 사용하십시오. 연결이 신뢰할 수 없거나, 클라이언트가 배치 중심이거나, 장기 실행 작업에 대한 주기적 상태 확인만 필요할 때 폴링을 사용하십시오.

A2A 작업에서 input_required는 무엇을 의미합니까? 에이전트가 더 많은 정보 또는 인간 승인이 필요한 일시 중단 상태입니다. 이를 오류로 취급하기보다 UX와 타임아웃을 명시적으로 설계해야 합니다.

A2A 푸시 알림은 어떻게 작동합니까? HTTPS 웹훅과 함께 PushNotificationConfig를 등록하십시오. 서버는 중요한 업데이트 시 POST를 보내며, 클라이언트는 GetTask를 호출하여 전체 상태와 아티팩트를 가져옵니다.

실패한 A2A 작업은 어떻게 재시도해야 합니까? 멱등성 키와 함께 일시적 실패를 재시도하고, 타임아웃 예산을 존중하며, 거절됨 또는 정책 실패와 같은 최종 상태를 맹목적으로 재시도하지 마십시오.

장기 실행 A2A 워크플로우에는 무엇을 로깅해야 합니까? 환 전반에 추적 ID, 작업 ID, 에이전트 ID의 상관관계를 설정하십시오. 상태 전환, 아티팩트, 위임, 승인 및 단계별 비용을 로깅하여 전체 워크플로우를 재구성할 수 있게 하십시오.

출처

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