SK-Intellix DeviceAgent and SoC Category
DeviceAgent/SoC 카테고리는 실제 기기 실행을 담당한다. TaskManager, domain executor, callback, reason code, device planning context가 핵심이다.
이 영역은 Cloud LLM 전용 구현이 아니다. Cloud A2A, MQTT 명령 서버, 앱/리모트 제어, 예약/자동화, 온디바이스 로컬 음성 등 여러 명령 유입원을 하나의 SoC 실행 프레임워크로 받는 구조를 목표로 한다.
업체 구현 진입점
SoC/DeviceAgent 업체가 TaskManager 관련 작업을 보기 시작하는 실제 진입점은 아래 문서다.
| 바로 볼 문서 | 목적 |
|---|---|
| SoC TaskManager Framework | TaskManager 작업의 배경, 구조, 실제 작업내역, 업체 구현 범위, 프레임워크화 방향을 한 번에 확인 |
| Vendor Briefing Path | 업체 설명/회의를 10분 요약, 30분 구조, 60분 구현 딥다이브로 진행하는 진입로 |
| DeviceAgent Layer Transition | 기존 DeviceAgent Layer와 TaskManager 추가 후 Layer를 SVG로 비교 |
| MainApi TaskManager Insertion | 기존 명령이 MainApi.executeMethod(...)로 모이는 위치와 TaskManager hook이 들어가는 위치 확인 |
| DeviceAgent TaskManager Layer Source Map | TaskManager layer별 실제 Java 파일과 업체 구현 작업 범위 확인 |
| DeviceAgent Task Lifecycle Detail | submitTask/submitWorkflow가 validation, policy, executor, event를 거쳐 실행되는 runtime 흐름 확인 |
| Before/After Change Model | 기존 DeviceAgent 구조와 TaskManager layer 추가 후 변화, 이점, 업체 설명 포인트 확인 |
| Source-Level Implementation Guide | 업체가 실제 코드에서 어떤 파일과 method를 구현/연결해야 하는지 확인 |
| Vendor Implementation Workbook | 업체가 구현해야 할 API, source, event, reason, evidence를 체크리스트처럼 확인 |
| Architecture | Cloud/MQTT/App/예약/로컬 음성이 DeviceAgent TaskManager로 들어오는 구조 확인 |
| Implementation Worklog | 현재 소스 기준 어떤 파일/역할이 추가 또는 정리됐는지 확인 |
권장 읽기 순서:
DeviceAgent / SoC Category
-> SoC TaskManager Framework
-> Vendor Briefing Path
-> DeviceAgent Layer Transition
-> MainApi TaskManager Insertion
-> DeviceAgent TaskManager Layer Source Map
-> DeviceAgent Task Lifecycle Detail
-> Background
-> Before/After Change Model
-> Source-Level Implementation Guide
-> Architecture
-> Implementation Worklog
-> Vendor Implementation Workbook
-> Framework Refactor Roadmap
핵심 질문
| 질문 | 봐야 할 문서 |
|---|---|
| 업체가 TaskManager를 그대로 구현하려면 어디서 시작하는가 | SoC TaskManager Framework |
| TaskManager는 어떤 큰 기능인가 | SoC TaskManager Execution Subsystem |
| API 계약은 무엇인가 | DeviceAgent TaskManager API Contract |
| moving/cleaning/map/schedule 도메인은 어떻게 나뉘는가 | DeviceAgent / SoC Domain Map |
| 업체가 구현해야 할 패키지는 무엇인가 | DeviceAgent Vendor Implementation Package |
| 19.comToMe는 DeviceAgent 관점에서 무엇이 필요한가 | 19.comToMe DeviceAgent Contract |
책임 범위
| 포함 | 제외 |
|---|---|
| task/workflow queue | Cloud planner prompt 수정 |
submitTask, submitWorkflow, getTaskStatus |
온디바이스 UI/notification 표현 |
onTaskEvent callback |
family routing benchmark |
reason_code, reason_params |
장기 memory profile 정책 |
DevicePlanningContextProvider snapshot |
업체 문서 편집 자체 |
대표 소스
~/work/1.A1_SoC_new/SoC/a1-packages
apps/DeviceAgent/app/src/main/java/com/sk/airbot/deviceagent/task/TaskManager.java
apps/DeviceAgent/app/src/main/java/com/sk/airbot/deviceagent/task/TaskEventListener.java
apps/DeviceAgent/app/src/main/java/com/sk/airbot/deviceagent/task/TaskReasonContract.java
apps/DeviceAgent/app/src/main/java/com/sk/airbot/deviceagent/task/DevicePlanningContextProvider.java
apps/DeviceAgent/app/src/main/java/com/sk/airbot/deviceagent/task/TaskIngressClassifier.java
현재 중요한 결론
- Cloud/MQTT/App/예약 등 어떤 유입원이든 DeviceAgent는 실행 가능성/상태/실패 이유를 구조화한다.
- 모든 자연어 실패 이유를 상위 서버나 Cloud에 계속 보내는 방식은 유지보수성이 낮다.
- DeviceAgent는
reason_code와reason_params를 제공하고, 각 upstream은 source policy에 따라 replan, retry, ack, report, user notification을 결정한다. get성격의 상태 조회는 workflow plan의 일부일 수 있지만, TaskManager queue에 넣을 task는 주로set/execute성격이다.