KnowAct-GUIClaw - Know Deeply, Act Perfectly, Personal GUI Assistant with Self-Evolving Memory and Skill

🏷️ 논문 에이전트 LLM 멀티모달

Y. Li, J. Li, B. Hu, M. Zhang, et al., "KnowAct-GUIClaw: Know Deeply, Act Perfectly, Personal GUI Assistant with Self-Evolving Memory and Skill," arXiv:2607.12625, 2026.

저자

논문을 쓴 팀은 하얼빈공업대학교(선전, HITsz)의 Lychee Team입니다. 교신저자는 SLAI 연구실을 이끄는 후바오톈(Baotian Hu) 교수이고, 1저자는 그 아래에서 박사를 마치고 지금은 같은 학교 조교수로 재직 중인 리윈신(Yunxin Li)입니다.

팀이 이 논문을 쓴 직접적인 동기는 OpenClaw 프레임워크의 두 가지 구조적 공백입니다. GUI 조작 능력이 단일 플랫폼에 묶여 있다는 것, 그리고 실행 궤적에서 지식을 스스로 쌓아가는 자기 진화 메커니즘이 없다는 것입니다. 기존 GUI 에이전트들은 매 태스크를 처음부터 다시 풀었습니다.

배경

GUI 에이전트 연구는 빠르게 발전하고 있지만 한 가지 불편한 사실이 있습니다. 지금의 상위권 시스템들은 매우 강한 기반 모델(GPT-5.5, Seed-2.0-Pro)을 쓰고 있음에도 불구하고, 같은 화면 조작 실수를 반복합니다. 이미 익힌 조작법을 다음 태스크에 전달하는 경로가 없기 때문입니다.

또 다른 문제는 정보 손실입니다. 여러 앱을 거치는 긴 태스크에서 "이메일에서 호텔 이름을 뽑아 지도 앱에서 경로를 검색하라"는 식의 요청이 오면, 단일 GUI 에이전트는 중간 결과를 자유형 텍스트로 다음 단계에 넘깁니다. 정보가 흐릿하게 요약되거나 아예 잘못 전달되는 경우가 생깁니다.

KnowAct-GUIClaw는 이 두 문제를 구조적으로 다룹니다. 경험 기억(experience memory)과 상태 검증 기술 라이브러리(skill library)를 갖추고, 앱 간 데이터 전달에 블랙보드(typed blackboard)를 씁니다.

어떻게 만들었나

시스템은 호스트 에이전트와 GUI 실행기(GUIClaw)를 분리합니다. 호스트는 대화 맥락, 워크스페이스 메모리, 사용자 프로필, 외부 도구를 관리하며 무엇을 할지 결정합니다. GUI 실행기는 스크린샷 인식, 액션 정규화, 기기 백엔드를 담당하며 어떻게 화면을 조작할지 결정합니다.

이 두 층 사이의 인터페이스는 공식적입니다. 각 GUI 태스크는 완료 상태, 실행 요약, 최종 화면 상태를 구조화해서 돌려줍니다. 호스트는 이 결과를 받아 다음 단계를 결정하거나 직접 처리합니다.

두 영구 저장소가 모든 단계에 자문 맥락을 제공합니다. 하나는 기억·이력 저장소(메모리, 정책, 세션 이력), 다른 하나는 기술·단축키 저장소(검증된 절차, Android 딥링크)입니다.

knowact-guiclaw-overview.png

실행은 네 단계 루프로 돌아갑니다.

Know(파악). 태스크를 받으면 먼저 관련 기억과 기술 후보를 의미 유사도로 검색합니다. 검색 결과는 강제 적용이 아닌 자문(advisory) 역할을 합니다. 이전 실패에서 뽑은 교훈이 지금 태스크의 앱 선택과 접근 방식을 바꿀 수 있습니다. 호스트는 GUI 실행이 필요 없는 정보 수집 서브태스크를 스스로 처리해 불필요한 위임을 줄입니다.

Route(라우팅). 라우터는 요청을 단일 앱 태스크나 다중 앱 워크플로 중 하나로 분류합니다. 다중 앱이면 각 서브태스크에 입력-출력 명세를 붙인 튜플 \((g_i, h_i, I_i, O_i)\)를 만들고, 블랙보드 \(B\)를 통해 서브태스크 간 데이터를 전달합니다.

\[G(g_i, h_i, B_{i-1}[I_i]) \to \tau_i, \quad E(\tau_i, O_i) \to B[O_i]\]

필요한 입력이 없거나 선언된 출력이 나오지 않으면 워크플로는 열린 추측 대신 닫힌 실패(fail closed)를 반환합니다. 이 규칙이 앱 간 사실 수집이나 비교 태스크에서 정보 위조를 막습니다.

Act(실행). GUIClaw의 액션 공간은 네 집합의 합집합입니다.

\[A = A_{gui} \cup A_{skill} \cup A_{shortcut} \cup A_{ask}\]

\(A_{gui}\)는 탭, 스와이프, 텍스트 입력 같은 기본 조작, \(A_{skill}\)은 과거 궤적에서 뽑은 재사용 기술, \(A_{shortcut}\)은 검증된 Android 딥링크와 인텐트, \(A_{ask}\)는 사용자 개입 요청입니다.

실행 루프는 다음 형태를 따릅니다.

\[p_t \to o_t \to a_t \to e_t \to o_{t+1}\]

프롬프트 \(p_t\)에 서브태스크, 블랙보드, 정책 메모리, 사용 가능한 기술이 포함됩니다. 기술을 쓰기 전에 상태 계약(state contract)을 검증하고, 불일치하면 복구 서브목표를 실행하거나 보통 조작으로 돌아갑니다.

Reflect(반성). 태스크가 끝나면 실행 궤적을 요약하고 기술과 경험 기억을 갱신합니다. 새 기술 추출과 기존 기술 수리(repair)를 분리합니다. 기존 기술이 실패한 궤적이 있으면 수리가 먼저이고, 재사용 가능한 새로운 행동이 있을 때만 신규 추출을 합니다.

결과

MobileWorld (117개 GUI-Only 태스크)

모델 / 설정

SR (pass@1, %)

Seed-2.0-Pro

63.2

GPT-5.5

62.4

Gemini-3.1-Pro-Preview

58.1

Claude-Opus-4.7

56.4

Kimi-K2.6 (기반 모델만)

55.6

Gemini-3-Pro + UI-Ins-7B

55.6

GPT-5 + UI-Ins-7B

54.0

GUI-Owl-1.5-32B

43.9

Qwen3.5-35B-A3B (기반 모델만)

24.8

본 연구: 35B + 호스트 + 기억

34.5

본 연구: 35B + 호스트 + 기억 + 기술

37.9

본 연구: 35B + Kimi 파생 기억 + 기술

41.0

본 연구: Kimi-K2.6 + 호스트 + 기억

61.5

본 연구: Kimi-K2.6 + 호스트 + 기억 + 기술

64.1

기반 모델 24.8에서 시작한 Qwen3.5-35B는 호스트와 경험 기억만 붙여도 34.5로 올라갑니다. 기술을 추가하면 37.9, Kimi-K2.6 궤적에서 뽑은 기억과 기술로 교체하면 41.0에 도달합니다. 기억과 기술이 모델 계열을 넘어 이전될 수 있음을 보여줍니다.

Kimi-K2.6를 호스트와 실행기로 쓰면 64.1로 리더보드 최상위를 차지합니다. GPT-5.5(62.4), Seed-2.0-Pro(63.2)를 모두 웃돕니다.

어블레이션: 효율 비교

설정

SR (%)

GUI 스텝

총 토큰

호스트 토큰

35B 기반 모델만 (A)

24.8

26.7

281,266

-

35B + 호스트 + 기억 (B)

34.5

26.8

279,211

65,224

35B + 기술 추가 (C)

37.9

25.1

278,289

63,792

397B 기반 모델만 (D)

40.7

26.1

254,459

-

397B + 호스트 + 기억 (E)

43.3

26.8

273,352

10,096

397B + 기술 추가 (F)

46.2

23.7

260,516

10,982

기술을 추가하면 SR이 오르고 GUI 스텝과 총 토큰이 줄어듭니다. 기술이 반복 탐색을 건너뛰어 더 짧은 궤적으로 같은 일을 완료하기 때문입니다.

397B 호스트가 직접 처리할 수 있는 정보 조회 서브태스크를 GUI에 위임하지 않으면(F), GUI 태스크 호출 횟수가 2.5에서 1.7로 줄고 총 토큰도 감소합니다. 정확도와 비용 모두에서 최선의 구성입니다.

AndroidDaily (Android 기기, 194 해결 가능 태스크)

모델

Filter

Query

Analyze

Atomic

Comp.

전체

UI-TARS-1.5

57.6

66.0

36.7

61.4

13.6

56.6

Step-GUI-8B

52.5

63.8

33.0

59.1

14.0

52.5

KnowAct-GUIClaw (Resolved)

80.6

76.9

77.1

81.3

62.5

78.6

분석(Analyze)과 복합(Comp.) 태스크에서 마진이 가장 크게 납니다. 명시적 서브태스크 분해와 블랙보드 정보 전달이 반복적인 화면 탐색을 줄이기 때문입니다.

크로스플랫폼 체크

플랫폼

태스크 수

성공률

HarmonyOS

63

76.2%

Windows

30

70.0%

회고

논문 스스로 몇 가지 실패 패턴을 분석합니다.

HarmonyOS에서는 UI 제어 정밀도 문제가 뚜렷합니다. 분 입력 필드가 관성 휠 피커(inertial wheel picker)로 구현된 알람 설정에서 25분을 정확히 맞추지 못하고 스텝 예산을 소진했습니다. TaoBao 태스크에서는 결제 확인 버튼을 누른 화면을 이미 결제 페이지로 착각해 제어를 사용자에게 돌려주지 않았습니다.

Windows에서는 세 가지 병목이 있었습니다. 텍스트 레이블 없이 시각 아이콘으로만 구성된 이모지 패널에서 "웃는 이모지"를 정확히 선택하지 못했고, 짧게 뜨는 토스트 알림을 즉시 클릭하는 시간 민감한 조작에 실패했으며, 뷰포트 밖 대상에 대한 조작이 불안정했습니다.

저자들이 지목한 주요 미해결 과제는 호스트-서브에이전트 간 순차 파이프라인 핸드오프입니다. 지식 검색, 외부 도구 호출, GUI 액션을 하나의 결정 사이클 안에서 함께 저울질하는 통합 플래너로 나아가는 것이 다음 목표라고 명시합니다.

정리