← Docs hub

A2A Planner and Routing

Planner는 단순 selector가 아니라, 사용자 발화를 보고 어떤 agent step을 어떤 순서로 수행할지 계획한다.

이 문서의 위치

이 문서는 Planner/Routing의 빠른 개요다. 실제 소스 기준의 상세 판단 파이프라인, preclassifier, reply_object_typer, replyability_judge, second_pass_family_judge, ranked flow 보정, runtime/task orchestration 연결은 A2A Planner Deep Dive에서 본다.

Planner와 의미 축 조정 작업을 외부 연구 프레임으로 설명할 때는 A2A Planner Research Reading List를 같이 본다. 이 문서는 SayCan, LLM-Planner, intent/slot filling, clarification, OOD detection, decision-boundary calibration 자료를 현재 A2A 구조와 매핑한다.

읽는 순서:

1. 이 문서에서 family와 multi-step의 기본 개념을 잡는다.
2. A2A Planner Deep Dive에서 실제 구현 레이어와 소스 위치를 확인한다.
3. Device Task Flow에서 planner step이 온디바이스/DeviceAgent task로 내려가는 과정을 본다.
4. A2A Planner Research Reading List에서 planner/context/축 조정의 외부 논문 근거를 본다.
5. A2A Follow-up Question Strategy에서 missing slot, STT_NULL_SOFT, TaskManager failure 이후 어떤 질문을 던질지 본다.

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 판단

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이 필요하다.

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