← Docs hub

Speaker Identity And TaskManager Integration

이 문서는 화자 컨텍스트가 Cloud A2A Task Manager와 복합명령 실행에 어떻게 연결되는지 정리한다. 핵심은 Task Manager가 “무엇을 실행할지”뿐 아니라 “누가 요청했고, 그 사람이 후속 변경/취소 권한을 갖는지”를 알 수 있어야 한다는 점이다.

1. 현재 Cloud A2A 실행 구조

관련 소스:

gemini/a2a/runtime/orchestrator.py
gemini/a2a/runtime/task_manager.py
gemini/a2a/runtime/session_state.py
gemini/a2a/runtime/workflow_state.py

현재 흐름:

1. route_turn()이 planner 결과를 만든다.
2. should_execute_task_plan()이 multi-step/device task 여부를 판단한다.
3. execute_task_plan()이 step 순서와 dependency를 처리한다.
4. build_device_task_requests()가 온디바이스로 내려갈 task request를 만든다.
5. orchestration.session_state와 device_task_requests가 Lambda 응답에 포함된다.

2. speaker-aware workflow owner

권장 session_state 확장:

{
  "session_state": {
    "active_workflow_id": "wf_001",
    "workflow_owner_speaker_id": "user_001",
    "last_speaker_id": "user_001",
    "speaker_policy": {
      "confirmation_required": false,
      "authority_gate": "pass",
      "reason": "identified_owner"
    }
  }
}

적용 규칙:

3. device_task_requests 확장 후보

현재 task_manager.py는 device intent step을 다음 형태로 만든다.

{
  "task_type": "device_intent_step",
  "token_text": "<sk_48>(action=1)<sk_end>",
  "cloud_workflow_id": "wf_001",
  "cloud_step_id": "s1",
  "execution_target": "device",
  "wait_policy": "submitted",
  "contract_version": "a2a-task-orchestration-v1"
}

speaker-aware 확장:

{
  "task_type": "device_intent_step",
  "token_text": "<sk_48>(action=1)<sk_end>",
  "cloud_workflow_id": "wf_001",
  "cloud_step_id": "s1",
  "speaker_policy": {
    "speaker_id": "user_001",
    "speaker_state": "identified",
    "speaker_confidence": 0.72,
    "authority_gate": "pass",
    "side_effect_allowed": true
  },
  "contract_version": "a2a-task-orchestration-v1"
}

4. side-effect gate

side-effect가 있는 작업:

• 이동
• 청정 실행/중지
• 보안/잠금/프라이버시 설정
• 스케줄 등록/삭제
• 개인 기록 조회/삭제

권장 처리:

5. 복합명령 예시

발화:

거실 청정하고 10분 뒤에 침실로 와

planner output 후보:

{
  "turn_mode": "multi_step",
  "steps": [
    {
      "id": "s1",
      "route": "ODL",
      "token_text": "<sk_clean_living_room>"
    },
    {
      "id": "s2",
      "route": "SCH",
      "purpose": "wait 10 minutes",
      "depends_on": ["s1"]
    },
    {
      "id": "s3",
      "route": "ODL",
      "token_text": "<sk_move_bedroom>",
      "depends_on": ["s2"]
    }
  ]
}

speaker-aware runtime:

1. s1 실행 전 speaker_policy.side_effect_allowed 확인
2. workflow owner speaker 저장
3. s2 대기 중 후속 발화 speaker 확인
4. s3 실행 전 owner/authority 재확인

6. 구현 우선순위

1. speaker_context를 Cloud request에 포함한다.
2. build_session_state()에 last_speaker_id와 workflow_owner_speaker_id를 추가한다.
3. build_device_task_requests()에 speaker_policy를 additive로 붙인다.
4. side-effect task gate를 policy 함수로 분리한다.
5. 복합명령 테스트에 owner mismatch/unknown/multi_speaker 케이스를 추가한다.