A2A Planner-TaskManager Baseline Readiness 2026-08-02
Cloud A2A, On-device Agent, MR6 DeviceAgent, MR6 SKLauncher2를 하나의 Planner-TaskManager 경계로 검토한 현재 기준선이다.
현재 판정은 candidate-ready다. 선택한 소스와 재현 가능한 검증 결과가
commit 후보로 정리됐다는 뜻이며, 아직 commit, tag, 서비스 배포, 실기기 E2E
완료를 의미하지는 않는다.
한눈에 보는 결론
| 영역 | 현재 결과 | 판정 |
|---|---|---|
| Cloud 관리 테스트 | 737 passed, 49 skipped |
통과 |
| v13 라우터 | 1,181건, strict 81.96%, policy 82.56%, error 0 |
기준선 통과 |
| latest-axis original | 2,734건, strict 80.87%, policy 84.05%, error 0 |
기준선 통과 |
| latest-axis HOLDOUT5 | 1,734건, strict 78.89%, policy 83.45%, error 0 |
기준선 통과 |
| STT guard A/B | 유지 84/145, 제거 63/145 |
guard 유지 |
| 2차 판정 사용량 | 24/24 family·owner 불변, 누락 사용량 계측 보정 | accounting 수정 |
| source hygiene | key/signing/generated package 제외 gate | 통과 |
| 실기기 E2E | 별도 캠페인 필요 | 미완료 |
strict는 workbook의 단일 정답과 비교한 값이고, policy는 최신 정책에서
복수 정답을 허용한 값이다. 과거 holdout에는 특히 SCH, ODL, DEF,
STT_NULL 경계가 현재 정책과 다른 라벨이 있어 두 값을 같이 본다.
이번에 고정한 기준
1. 의미 경계는 행별 rule이 아니라 검증셋으로 관리한다
라우터 변경은 특정 발화나 오타를 외우게 하지 않고 아래 순서로 판단했다.
정답 정책 고정
-> expected/predicted transition 분석
-> 정답지 오류와 router 오류 분리
-> 의미축, cue, prompt, schema 조정
-> focused test
-> full-run
-> holdout
세부 cycle은 A2A Router Axis Tuning Roadmap과 Semantic Boundary Calibration Playbook에서 본다.
2. STT_NULL guard는 더 느슨하게 풀지 않는다
residual_narration_specialist_overreach.no_dominant_interpretation guard를
제거하면 legacy v13 일부는 좋아지지만 최신 검증셋 두 개가 함께 하락했다.
| Dataset | guard 유지 | guard 제거 | 변화 |
|---|---|---|---|
| v13 slice | 8/29 |
18/29 |
+10 |
| latest-axis original | 44/69 |
24/69 |
-20 |
| HOLDOUT5 | 32/47 |
21/47 |
-11 |
| 합계 | 84/145 |
63/145 |
-21 |
따라서 legacy 일부를 맞추기 위해 narration과 STT 붕괴 조각을 specialist로 과승격시키는 방향은 채택하지 않았다. 다음 개선도 문구 목록 추가가 아니라 응답 가능성, target 안정성, recoverability, over-inference risk 같은 의미 evidence를 기준으로 해야 한다.
3. 2차 판정 비용을 실제 사용량에 포함한다
ODL/STT_NULL과 DEF/STT_NULL 경계에서 실행되는 second pass가 selected route에는
반영되지만 planner_usage와 combined_usage에는 빠지는 계측 결함이 있었다.
응답 파싱 실패 여부와 관계없이 시도한 second pass 사용량을 최종 metric에
합산하도록 보정했다.
24건 live sample 결과:
| 항목 | 결과 |
|---|---|
| selected family 불변 | 24/24 |
| owner source 불변 | 24/24 |
| 평균 추가 model call | +1.0 |
| 평균 추가 token | +2,144.67 |
| 관측 평균 지연 증가 | +7,828.8 ms |
지연 값은 live service variance가 섞인 관측치이며 SLA나 결정론적 성능값이 아니다. 이 수정은 semantic behavior 변경이 아니라 비용·지연 계측의 정확성 보정이다.
두 개의 source fingerprint
full-run 결과와 현재 commit 후보를 같은 소스로 오해하지 않도록 fingerprint를 분리했다.
| Fingerprint | 의미 |
|---|---|
baseline_freeze_router_source |
세 개의 complete full-run을 실제 수행한 소스 |
baseline_candidate_router_source |
second-pass accounting 수정까지 포함한 현재 commit 후보 |
두 소스의 차이는 main_router_api.py 한 파일이며, 후속 변경은 24-row semantic
sample과 전체 관리 테스트로 검증했다. 따라서 full-run 점수를 accounting 수정
후 소스의 재실행 결과라고 표현하지 않는다.
회귀 방지선
live model variance를 감안하되 의미 있는 하락은 즉시 실패시키도록 floor를 고정했다.
| Dataset | Baseline | Freeze floor | 허용 폭 |
|---|---|---|---|
| latest-axis original policy | 84.05% |
83.75% |
0.30%p |
| HOLDOUT5 policy | 83.45% |
83.15% |
0.30%p |
| v13 strict | 81.96% |
81.50% |
0.46%p |
| v13 policy | 82.56% |
82.00% |
0.56%p |
부분 CSV, 중복 row, dataset identity 불일치, error row는 완료 증거로 인정하지 않는다.
commit과 보안 경계
Cloud 후보는 리뷰 단위를 두 개로 분리한다.
| Commit | 범위 | 경로 수 |
|---|---|---|
| Runtime contracts | Experience admission/effect, semantic observation, runtime, shim, 관련 테스트·설계 문서 | 29 |
| Benchmark and freeze gate | timeout/resume, readiness gate, compact baseline evidence, 관련 테스트·문서 | 19 |
다음은 source commit에서 제외한다.
- Gemini key,
.env, signing key, keystore와 credential dump lambda_package.zip, APK/AAB와 generated package- device backup과 machine-local 설정
- raw full-run CSV, retry log, absolute path가 담긴 로컬 report
- 선택한 기준선과 무관한 대량 historical artifact
키 값은 문서, staged content, tracked source, 배포 산출물에 포함하지 않는다. 테스트는 로컬 process environment에서 credential을 읽는다.
다음 단계: 실기기 E2E 증거
기준선 commit 이후에는 아래 순서로 physical-device campaign을 수행한다.
| 순서 | 대표 검증 | 필요한 증거 |
|---|---|---|
| 1 | 현재 위치·공기질·배터리 질의 | Device Context 수신값과 자연어 응답 |
| 2 | 이동 -> 청정 -> 스테이션 복귀 | plan, workflow request, 단계 callback |
| 3 | 기기 상태 조건 분기 | 조건 입력, 선택 branch, 미선택 branch |
| 4 | PUI 취소 | cancel event, terminal reason, 다음 step/replan |
| 5 | 바이탈사인 등 장기 외부 앱 | 시작, 사용자 완료·취소, timeout 경계 |
| 6 | 단기·절대시각 schedule | trigger 저장, 실행 시각, callback |
| 7 | 실패·block·replan | reason code, bounded replan decision |
| 8 | Text Console observability | route, step, request, callback, 상태 변화 표시 |
각 시나리오는 최소한 다음 여섯 계층의 증거를 남겨야 한다.
route
-> planner steps
-> device workflow request
-> TaskManager lifecycle callback
-> next step or bounded replan
-> console trace
단순히 TTS가 나왔거나 release APK가 빌드됐다는 사실만으로 E2E 통과로 보지 않는다.
현재 주장 가능한 것과 아직 아닌 것
주장 가능
- 세 개의 지정된 라우터 데이터셋 full-run이 완료됐고 infrastructure error는 0이다.
- 현재 score와 freeze floor가 artifact/config로 고정됐다.
- STT guard는 최신 검증셋을 포함한 A/B 근거로 유지했다.
- second-pass usage accounting은 semantic 결과를 바꾸지 않고 계측을 보정했다.
- Cloud, On-device, MR6 DeviceAgent, SKLauncher2의 관리 테스트와 release build 기준은 통과했다.
아직 주장 불가
- 실기기에서 모든 복합 workflow와 callback/replan이 통과했다.
- 현재 source가 production에 배포됐다.
- live Gemini 지연 관측치가 제품 SLA다.
candidate-ready가 release-ready 또는 field-ready와 같다.