LLM Wiki

← Docs hub

A2A Device Task Flow

이 문서는 Cloud plan이 온디바이스와 DeviceAgent TaskManager를 거쳐 실제 기기 task로 실행되는 흐름을 설명한다.

A2A Device Task Flow Diagram

Runtime Path

Cloud device_intent_step
-> ForegroundService.executeCloudDeviceTaskRequests
-> CloudIntentWorkflowRunner
-> DeviceIntentExecutor
-> FunctionCallHandler
-> ManagedTaskDeviceCommandSink
-> DeviceCommunicator.submitManagedTask
-> DeviceAgent TaskManager
-> onTaskEvent
-> ForegroundService.handleCloudIntentNativeTaskEvent
-> Cloud task_event

Cloud에서 내려오는 입력

task_type = device_intent_step
token_text = <sk_100>(position=거실)<sk_end>
cloud_workflow_id = workflow id
cloud_step_id = step id
cloud_plan_id = planner selected_flow_id 또는 task_plan_id
cloud_output_key = step output key
depends_on = 이전 step id 목록
wait_policy = submitted | completed | event

Local Workflow 상태

상태 의미
PENDING 바로 실행 가능한 step
WAITING_DEPENDENCY 선행 step 완료 대기
RUNNING DeviceAgent native task로 제출됨
COMPLETED native task 정상 완료
FAILED 실패/차단/취소/타임아웃/사용자 입력 필요

의존성이 있는 step은 선행 step이 COMPLETED가 되기 전까지 실행하지 않는다.

예시: 이동 후 청정

발화:

거실로 가서 공기청정하고 안방으로 이동해줘

Cloud plan:

step_1 ODL move(position=거실)
step_2 ODL clean(position=거실), depends_on=step_1
step_3 ODL move(position=안방), depends_on=step_2

온디바이스 workflow:

step_1 <sk_100>(position=거실)<sk_end>
step_2 <sk_4>(position=거실)<sk_end>
step_3 <sk_100>(position=안방)<sk_end>

Cloud가 다시 판단하지 않는 이벤트

이 이벤트들은 상태 표시, audit evidence, 다음 local step unlock에 쓰인다.

Cloud replan 후보 이벤트

이 경우에도 무조건 LLM을 돌리는 것은 아니다. requires_cloud_decision=true이거나 policy상 재판단이 필요한 경우에만 planner/replan으로 들어간다.

get과 set의 차이

상태 조회성 get은 보통 TaskManager task보다 planning context 또는 workflow input으로 쓰는 편이 맞다. 반면 실제 실행성 set/do 명령은 TaskManager task로 등록한다.

관련 소스

ForegroundService.kt
CloudIntentWorkflowRunner.kt
DeviceIntentExecutor.kt
DeviceCommandSink.kt
ManagedDeviceTask.kt
TaskManager.java
TaskEventListener.java

다음에 볼 페이지