A2A Executive Summary
이 문서는 SK-Intellix A2A 작업의 현재 결론을 회의/공유용으로 빠르게 읽기 위한 요약이다. 전체 설계의 세부 근거는 각 링크 문서에 있고, 이 페이지는 “지금 무엇이 정해졌고, 누가 무엇을 해야 하며, 완료로 보려면 어떤 증거가 필요한가”에 집중한다.
1. 한 줄 결론
Cloud A2A는 사용자의 발화를 이해해 무엇을 어떤 순서로 할지 계획하고, 온디바이스 Bridge와 DeviceAgent/SoC는 그 계획을 기기에서 안전하게 실행하고 상태를 보고한다.
가장 중요한 운영 원칙은 아래다.
- 정상 task 진행마다 Cloud LLM을 다시 돌리지 않는다.
- Cloud replan은 실패, 차단, 일시중단, 사용자 결정 필요 이벤트에만 제한한다.
- 기기 실행 조건과 안전 판단은 DeviceAgent/SoC의 기존 domain logic을 우회하지 않는다.
- 모든 device task/event는
cloud_workflow_id,cloud_step_id,cloud_output_key같은 trace field를 유지한다. - 실패/차단은 자연어 reason이 아니라
reason_code,reason_params,requires_cloud_decision으로 구조화한다.
2. 현재 구조
User / STT
-> Cloud A2A Planner
-> Cloud Runtime / Orchestrator
-> On-device Bridge
-> DeviceAgent TaskManager
-> SoC native domain modules
-> Task event / reason callback
| 레이어 | 현재 역할 |
|---|---|
| Cloud Planner | route family, turn_mode, multi-step plan, device/cloud step 분리 |
| Cloud Runtime | planner 결과를 agent 실행 또는 device_task_requests로 변환 |
| On-device Bridge | Cloud request 수신, device intent workflow 실행, DeviceAgent 연결 |
| DeviceAgent TaskManager | queue, workflow, task state, callback, reason contract 관리 |
| SoC Domain Modules | moving, cleaning, map, schedule, interaction 등 실제 조건 판단과 실행 |
3. 확정된 설계 판단
| 판단 | 이유 |
|---|---|
| Planner는 selector가 아니라 planner다 | 단일 agent 선택뿐 아니라 multi-step, dependency, cloud/device 혼합 plan을 만들어야 한다. |
get 성격은 planning context 또는 상태조회로 처리한다 |
상태조회까지 무조건 task queue에 넣으면 불필요하게 무거워진다. |
set 성격의 장기 실행은 TaskManager로 관리한다 |
이동/청정/스케줄/복합명령은 queue, timeout, cancel, callback이 필요하다. |
| 정상 event는 Cloud LLM replan 대상이 아니다 | 토큰/지연 비용을 줄이고 로컬 workflow를 안정화하기 위함이다. |
FAILED/BLOCKED/PAUSED는 reason contract가 있어야 한다 |
Cloud가 재질문/대체 plan/중단을 안정적으로 판단하기 위해 필요하다. |
token_text는 임의 생성하지 않는다 |
Cloud가 지원되지 않는 device token을 만들어 unsafe execution으로 이어지는 것을 막기 위함이다. |
| 19.comToMe는 단일 명령이 아니라 장기 workflow다 | DoA, Vision, AMR, FollowMe, speaker/location gate가 순서대로 엮인다. |
4. 현재 문서화 상태
| 영역 | 상태 |
|---|---|
| 전체 구조 | System Overview, Visual Map, Architecture Diagrams에 정리됨 |
| 역할별 읽기 경로 | Role-Based Reader Paths에 정리됨 |
| Planner/Router | Planner and Routing, Benchmark and Router Evolution에 정리됨 |
| 계약/실행 | Contract Matrix, Device Task Flow에 정리됨 |
| 소스 근거 | Source Map, Evidence Index에 정리됨 |
| 업체 전달 | Vendor Handoff, Vendor Implementation Package, Vendor API Acceptance Checklist에 정리됨 |
| 19.comToMe | 19.comToMe A2A Workflow Example, 19.comToMe DeviceAgent Contract에 정리됨 |
| 검증/공백 | Validation Guide, Status and Gap Audit, Next Action Board에 정리됨 |
| Memory/개인화 | Memory and Personalization, Memory DB and Sync Contract에 설계 정리됨 |
5. 지금 남은 핵심 리스크
| 리스크 | 영향 | 필요한 증거 |
|---|---|---|
| 실기기 E2E 미검증 | 설계와 실제 DeviceAgent callback이 다를 수 있음 | ADB/logcat, artifact validator PASS |
| 업체 callback payload 미확정 | Cloud replan 판단이 안정적으로 동작하지 않을 수 있음 | reason_code, reason_params, trace field가 포함된 fixture |
| 최신 benchmark artifact 미고정 | 현재 prompt 기준 성능을 재현하기 어려움 | prompt snapshot, full-run result, family별 실패 샘플 |
| Memory 구현 미착수 | 이전 맥락/개인화 기반 추론이 설계 수준에 머무름 | DB migration, repository, sync worker, deletion/privacy test |
| 19.comToMe 실제 method 미확정 | Cloud/On-device/DeviceAgent 간 이름과 payload가 어긋날 수 있음 | comeToMe method, stage gate, callback/reason mapping 확정 |
6. 다음 액션 우선순위
| 우선순위 | 액션 | 담당 |
|---|---|---|
| P0 | ADB 실기기 복합명령 E2E 수집 | QA / On-device / DeviceAgent |
| P0 | DeviceAgent 업체 open question closure | 기술 리드 / 업체 |
| P1 | 최신 router benchmark artifact 고정 | Cloud A2A |
| P1 | DeviceAgent API 인수 기준과 실제 구현물 대조 | DeviceAgent 업체 / QA |
| P1 | 19.comToMe 실제 계약 확정 | Cloud / On-device / DeviceAgent 업체 |
| P2 | Memory DB schema와 sync worker 구현 | Cloud / Memory 담당 |
| P2 | full AOSP/partition/HAL/SELinux 상세 분석 | DeviceAgent / SoC |
7. 회의에서 바로 확인할 질문
| 질문 | 닫히면 업데이트할 문서 |
|---|---|
| DeviceAgent TaskManager API method 이름은 현재 문서와 동일한가 | DeviceAgent TaskManager API Contract |
| 정상 event와 판단 필요 event의 callback 구분은 확정됐는가 | Contract Matrix, Validation Guide |
reason_code enum과 reason_params 필드는 업체 구현에서 제공 가능한가 |
Vendor Open Questions |
getDevicePlanningContext의 freshness 기준은 몇 초인가 |
DeviceAgent TaskManager API Contract |
19.comToMe의 comeToMe method와 stage gate는 실제 구현 가능한가 |
19.comToMe DeviceAgent Contract |
| 실기기 E2E를 언제 어떤 command set으로 돌릴 것인가 | Validation Guide, Vendor Test Evidence Template |
8. 완료 판정 기준
이 작업을 제품 통합 완료로 보려면 아래가 필요하다.
- Cloud planner output과 runtime
device_task_requests가 fixture로 보존되어 있다. - On-device Bridge가
device_intent_stepworkflow를 순차 실행한다는 테스트가 있다. - DeviceAgent TaskManager가
submitTask,submitWorkflow, callback, reason contract를 실제로 제공한다. - 실기기 logcat에서 trace field가 end-to-end로 확인된다.
- 실패/차단 event에서
requires_cloud_decision이 의도대로 동작한다. - 최신 benchmark full-run 결과가 prompt snapshot과 함께 보존되어 있다.
HTML 문서 생성, 일부 unit test, 설계 합의만으로는 제품 통합 완료로 보지 않는다.