← Docs hub
SK-Intellix A2A Category
A2A는 SK-Intellix 내부의 Cloud 판단/계획 카테고리다. 사용자 발화를 route family, multi-step plan, device task request, agent handoff로 바꾸는 계층을 다룬다.
권장 읽기 순서
| 단계 |
문서 |
읽는 목적 |
| 0 · Orientation |
A2A Knowledge Hub, Executive Summary |
전체 범위와 현재 결론 |
| 1 · Why / Product |
Product PRD, Before/After Impact |
도입 이유와 제품 효과 |
| 2 · Architecture |
System Overview, Planner Deep Dive |
owner, skill, step, dependency 구조 |
| 2 · 중심 설계 |
A2A 지식 그래프·RAG 연동 설계 |
현재 구현, 네 처리 경로, 지식 그래프·RAG·계획 수립기의 책임과 단계별 도입 기준 |
| 2 · 확장 설계 |
Experience Goal × Knowledge Graph |
다층 context가 Goal 형성·계획·Task lifecycle에 기여하는 장기 확장 |
| 2 · Architecture |
Experience Goal Category |
여러 task 뒤에도 상위 사용자 결과를 보존하는 확장 |
| 3 · Contract / Data |
Contract Matrix, Device Task Flow |
Cloud·On-device·DeviceAgent 계약 |
| 3 · Contract / Data |
Device Source Freshness Contract |
planner context의 최신성·출처 경계 |
| 4 · Implementation |
Source Map, Scenario Walkthroughs |
실제 소스와 대표 실행 흐름 |
| 4 · Implementation |
Capability Composition Catalog |
자연어를 범용 capability 조합으로 연결하는 방식 |
| 5 · Validation |
Semantic Boundary Calibration, Benchmark |
family 경계와 성능 증거 |
| 5 · Validation |
Baseline Readiness, Token Ledger |
최신 기준선·실기기·비용 |
| 6 · Operations / Roadmap |
Next Action Board, Research Reading List |
다음 gate와 외부 연구 |
이 배열은 Domain Reading Order의 공통 7단계를 A2A에
적용한 것이다. 발표용 서사, 구현용 계약, 최신 검증 결과를 한 표에서 섞지 않는다.
핵심 질문
| 질문 |
봐야 할 문서 |
| A2A를 제품/플랫폼 관점에서 왜 해야 하는가 |
A2A Product PRD, A2A Before/After Impact Analysis, A2A Adoption Benefits and Roadmap |
| 모델이 강해질수록 Harness·Loop·Graph를 어떻게 줄이거나 유지해야 하는가 |
모델 진화 시대의 SKIX Agent Engineering 전략 |
| 로보틱스 제어에서 LLM, Action runtime과 local controller를 어떻게 분리하는가 |
로보틱스 제어에서 SKIX Harness 구조의 타당성 |
| 발표 자료는 어떤 순서로 구성해야 하는가 |
A2A Presentation Deck Outline |
| 전체 A2A 흐름은 무엇인가 |
A2A Hub, System Overview |
| Speech-LLM 환경에서 context-aware 판단은 어떻게 이어지는가 |
Speech-LLM Context-Aware A2A Architecture |
| 지식 그래프와 RAG를 A2A에 넣되 모든 요청의 지연과 토큰을 늘리지 않으려면 어떻게 하는가 |
A2A 지식 그래프·RAG 연동 설계 |
| 화자 인식과 개인 기억, 제품 지식, Experience Goal, TaskManager를 어떻게 한 구조로 연결하는가 |
Experience Goal × Knowledge Graph |
| Planner가 route family를 어떻게 고르는가 |
Planner and Routing |
| DEF/STT_NULL, ODL/SCH 같은 축 경계는 어떻게 튜닝하는가 |
Semantic Boundary Calibration Playbook, Benchmark and Router Evolution |
| 고정청정 스케줄 1차 마일스톤은 어떻게 UX/slot/API로 닫는가 |
Schedule Milestone PRD and UX Spec |
| TaskManager와 device context를 쓰면 어떤 제품/사양이 가능해지는가 |
TaskManager Device Context Planning Spec |
| 복합명령은 어떤 plan으로 표현되는가 |
Device Task Flow, Scenario Walkthroughs |
| Cloud와 다른 계층의 payload 경계는 무엇인가 |
Contract Matrix |
| 업체에게는 무엇을 한 장으로 전달해야 하는가 |
A2A Vendor One-Pager, Vendor Handoff |
| A2A 성공 여부는 무엇으로 판단하는가 |
A2A Success Criteria, Validation Guide |
| 실제 소스는 어디인가 |
Source Map |
| 성능/benchmark는 어디서 보는가 |
Benchmark and Router Evolution |
책임 범위
| 포함 |
제외 |
| route family 판단 |
실제 모터/센서 제어 |
| multi-step plan 생성 |
DeviceAgent 내부 queue 구현 |
input_from, depends_on, wait_policy 설계 |
callback transport의 네이티브 구현 |
| Cloud runtime orchestration |
장기 메모리 DB migration |
| replan 필요 조건 판단 |
업체 테스트 evidence 제출 |
현재 중요한 결론
- A2A는 selector가 아니라 planner다.
- 하지만 모든 task event마다 LLM을 다시 돌리지 않는다.
- 정상
QUEUED, RUNNING, PROGRESS, COMPLETED, WORKFLOW_COMPLETED는 로컬 실행 흐름으로 처리한다.
FAILED, BLOCKED, PAUSED, NEEDS_USER_INPUT처럼 판단이 필요한 이벤트만 Cloud replan 후보가 된다.
- A2A가 세운 plan이 실제 기기 실행으로 이어지려면 On-device Bridge와 DeviceAgent TaskManager 계약이 맞아야 한다.
- Speech/STT, voice context, memory, device context, Agent/Skill, 복합제어는 별도 기능이 아니라 한 turn supervision loop 안에서 연결되어야 한다.
다음에 읽을 카테고리