A2A Planner and Routing
Planner는 단순 selector가 아니라, 사용자 발화를 보고 어떤 agent step을 어떤 순서로 수행할지 계획한다.
Planner의 입력
recognized_text
voice_context
device_context
memory_snapshot
preclassifier_hints
capability_registry
ranked_top_flows
핵심 원칙은 현재 발화가 1순위이고, history, memory, device context는 보조 증거라는 점이다.
Planner의 출력
turn_mode
selected_routes
owner_selection
steps
missing_slots
stt_null_*
복합명령에서 중요한 step 필드:
id
route
purpose
execution_target
depends_on
input_from
wait_policy
token_text
Family 판단
| Family | 의미 |
|---|---|
ODL |
즉시 실행 가능한 기기 동작 또는 현재 live/local state 조회 |
SCH |
알람, 타이머, 리마인더, 예약, 스케줄 workflow |
DQR |
기기/제품/assistant 설명, 사용법, troubleshooting |
FRG |
외부/public/freshness-aware lookup, 추천, 검색 |
DEF |
일반 대화, wording/style/meta help, 생활 조언 |
UNS |
실행 의도는 있으나 지원 불가한 기능 |
STT_NULL |
STT가 깨져 자연스러운 첫 응답 방향이 없는 상태 |
Multi-step 판단
Planner가 multi-step을 만들어야 하는 경우:
- 하나의 발화에 독립 또는 순차적인 여러 작업이 있다.
- 앞 step 결과를 뒤 step이 의미적으로 써야 한다.
- 물리적 기기 실행 순서가 중요하다.
- Cloud-only step과 device step이 섞여 있다.
예:
교통이 안 좋은 곳을 알아보고, 오늘 그곳 정보를 알려줘
가능한 plan:
step_1 FRG: 보통 교통체증이 심한 지역 검색
step_2 FRG: step_1 결과 지역의 오늘 정보 검색
step_3 DEF: 사용자에게 요약 답변
depends_on과 input_from
두 필드는 다르다.
| 필드 | 의미 |
|---|---|
depends_on |
실행 순서 또는 완료 대기 |
input_from |
이전 step 결과를 의미적으로 입력으로 사용 |
기기 이동 후 청정은 물리 순서가 중요하므로 depends_on이 필요하다. 검색 결과를 바탕으로 다시 검색하는 경우는 input_from이 필요하다.
STT_NULL과 multi-step
multi-step 후보가 명확한 경우에는 전체 발화를 STT_NULL로 닫으면 안 된다. STT_NULL은 자연스러운 첫 응답 방향이 실패했을 때만 선택한다.
관련 소스
gemini/a2a/planner/main_router_api.py
gemini/a2a/planner/assets/main_router.system_prompt.txt
gemini/a2a/planner/assets/main_router.response_schema.json