Fake Success 해결을 위한 Mobile Agent Delivery Pipeline 최적화

"My DingTalk Coding Bot Said It Started the Task. Then It Never Sent the Result"

CodeKing2026년 5월 21일8분intermediate

AI 요약

Context

DingTalk를 통해 Claude Code 및 Codex CLI를 제어하는 로컬 AI Gateway인 CliGate 설계 단계에서 발생한 메시지 전달 실패 문제 분석. Assistant Run의 즉각적인 응답에만 의존하여, 실제 작업을 수행하는 Long-running Runtime의 최종 결과물이 사용자에게 전달되지 않는 Delivery Path 단절 현상 발생.

Technical Solution

Assistant Run 상태가 WAITING_RUNTIME이고 관련 Runtime Session ID가 존재할 경우, 채널 응답 완료 전까지 대기하는 shouldDeferBackgroundCallback 로직 도입
단일 세션 기반 작업에서도 Fire-and-forget 방식이 아닌 Runtime Terminal Event 기반의 Callback 구조로 전환하여 결과 전달 보장
Session Webhook의 만료 시간 기반 판단 로직을 최적화 단계로 격하시키고, 실패 시 즉시 App API로 전환하는 Fallback 전략 구현
Registry에서 Raw Provider Template가 아닌 설정값이 주입된 Started Provider Instance를 참조하도록 변경하여 API 인증 누락 방지
'Accepted -> Started -> Waiting -> Completed/Failed -> Delivered'로 이어지는 전체 Lifecycle 기반의 Auditable Delivery Path 설계

실천 포인트

1. 외부 API Webhook의 Expiry Timestamp를 절대적인 신뢰 지표로 사용하지 말고 반드시 Fallback 경로를 설계했는가?

2. 비동기 런타임 작업 시 '작업 시작' 알림과 '작업 완료' 이벤트의 전달 경로가 동일하게 유지되는가?

3. 서비스 Registry에서 객체를 호출할 때 설정값이 누락된 Template와 실제 인스턴스가 엄격히 구분되어 관리되는가?

태그

#Lifecycle Management #Fallback Strategy #Callback #Event-Driven #Mobile Agent

원문 읽기