ClawGUI: Otwarty full-stack pipeline dla agentów GUI

Wyobraź sobie, że chcesz mieć model, który naprawdę obsłuży Twój telefon — stuknięcie, swipe, wpisanie tekstu, przejście przez aplikację, zarezerwowanie lotu. Model istnieje. Benchmarki istnieją. Dlaczego więc w 2026 roku wciąż nie możesz po prostu pip install agenta GUI i kazać mu cokolwiek zrobić na fizycznym urządzeniu? Odpowiedź prawie nigdy nie dotyczy samego modelu. Dotyczy infrastruktury wokół niego: środowiska treningowego, harnessa ewaluacyjnego i stacku deployu — każde z nich jest zwykle zamknięte, pofragmentowane, albo jedno i drugie.

ClawGUI to pierwszy otwarty release, który buduje wszystkie trzy i — co kluczowe — zszywa je w jeden pipeline.

Motywacja: trzy luki, jeden sufit

Postęp w agentach GUI nie jest dziś ograniczony przede wszystkim rozmiarem modelu. Jest ograniczony przez trzy bardzo konkretne inżynierskie wąskie gardła:

• Zamknięte stacki RL. Większość publikowanych agentów GUI trenowanych RLem opiera się na infrastrukturze sandbox-only, single-device i niepublikowanej jako open-source. UI-TARS-2 w swoim labie nie odtworzysz, a tym bardziej nie rozszerzysz.
• Dryf ewaluacji. Każdy benchmark (ScreenSpot-Pro, OSWorld-G, AndroidControl, MMBench-GUI, UI-Vision, MobileWorld) wchodzi z własnym skryptem oceniającym. Rozdzielczości, prompt template’y i polityki judge’a różnią się per model, a większość paperów publikuje liczby bez swojej konfiguracji inference. Autorzy ClawGUI odtworzyli wyniki z 11+ modeli na 6 benchmarkach i pokazali, że głównym źródłem nieodtwarzalności są nieudokumentowane wybory promptu i rozdzielczości, nie metodologia.
• Zepsuty deploy. Nawet gdy polityka dobrze się wytrenuje, prawie nigdy nie dociera do telefonu w rękach użytkownika. Brak integracji z chatami, brak personalizowanej pamięci, brak wsparcia dla HarmonyOS czy iOS, brak fallbacku dla aplikacji bez accessibility API.

Każda z tych luk była łatana osobno. Nikt nie załatał wszystkich trzech naraz — do ClawGUI.

Kluczowy pomysł

Pomyśl o agencie GUI jak o robocie, który uczy się obsługiwać smartfon. Żeby mu się to udało, potrzebujesz jednocześnie trzech rzeczy:

1. Siłowni, w której telefon może się crashować, być resetowany, a agent może próbować setki razy — równolegle, na prawdziwym i wirtualnym sprzęcie.
2. Miarki, którą wszyscy mierzą postęp w ten sam sposób, żeby liczby między paperami cokolwiek znaczyły.
3. Kanału dostawy, który wkłada wytrenowanego robota w ręce realnych użytkowników, na platformach, których już używają.

ClawGUI buduje siłownię (ClawGUI-RL), miarkę (ClawGUI-Eval) i kanał dostawy (ClawGUI-Agent). Pipeline jest jednokierunkowy: fix w jednym komponencie propaguje się do pozostałych. Model wytrenowany w ClawGUI-RL jest domyślnie ewaluowany przez ClawGUI-Eval i deployowany przez ClawGUI-Agent bez dodatkowego kleju.

Technicznym sercem jest sposób, w jaki odbywa się trening. W długich zadaniach GUI — “zarezerwuj mi najtańszy lot do Warszawy na piątek” — naiwna polityka dostaje jeden bit feedbacku na samym końcu: udało się czy nie? Przy 30 stuknięciach i swipe’ach to prawie zero gradientu. ClawGUI-RL rozwiązuje to, łącząc dwie rzeczy: Process Reward Model (PRM), który ocenia każdy pojedynczy krok, oraz GiGPO (Group-in-Group Policy Optimization) — estymator advantage, który przydziela zasługi per krok bez uczonej sieci value.

ClawGUI-RL: skalowalny online RL

Zarządzanie środowiskiem

Środowisko treningowe musi przeżyć w warunkach wrogich. Emulatory Androida dryfują w stan niezdrowy podczas długich runów; realne urządzenia throttlują termicznie albo tracą sieć. Environment Manager w ClawGUI stawia dziesiątki dockerowych emulatorów Androida (przez MobileWorld) za wspólnym interfejsem, z czterofazowym cyklem życia epizodu:

Task Reset → Task Evaluation → Spare Server Rotation → Teardown.

Kolejka spare server rotation to nieoczywisty element. Gdy emulator wywala health-check, jest wymieniany na ciepły spare zamiast restartowany w miejscu. Bez tego jeden zawieszony kontener zabija cały run treningowy.

Dla treningu na realnych urządzeniach environment eksponuje fizyczne Androidy / cloud phones. Reward outcome nie może tu pochodzić z weryfikacji systemowej (system nie wie, czy “zarezerwowano lot”), więc ClawGUI używa MLLM-as-judge.

Design rewardu: outcome + process

Całkowity reward to najprostsza możliwa kombinacja:

$$ R = R_{\text{outcome}} + R_{\text{step}} \tag{1} $$

gdzie:

• $R$ — całkowity reward używany przez estymator advantage
• $R_{\text{outcome}}$ — binarny reward na końcu epizodu (1 za sukces, 0 za porażkę), z weryfikacji systemowej w wirtualnych środowiskach lub z judge’a MLLM na realnych urządzeniach
• $R_{\text{step}}$ — gęsty, per-krokowy score z PRM, oceniający czy dany krok realnie przybliża do celu, przy wejściu (poprzedni screenshot, aktualny screenshot, historia akcji)

Interpretacja: Człon outcome koduje prawdziwy cel. Człon step to lokalny proxy, który daje sygnał gradientu wszędzie wzdłuż trajektorii. Bez niego misclick w kroku 4 i decydujące stuknięcie w kroku 29 dostają identyczne credit — i dlatego RL na poziomie epizodu dławi się na długich horyzontach.

Pętla krokowa:

1. Wykonaj rollout i zbierz krotki $(s_t, a_t, s_{t+1})$.
2. Po każdym kroku zapytaj PRM (w eksperymentach Qwen3.5-72B) z $(s_t, s_{t+1}, a_{0:t})$ i odbierz $R_{\text{step},t}$.
3. Na końcu epizodu policz $R_{\text{outcome}}$.
4. Zbuduj $R_t = R_{\text{outcome}}\cdot \mathbb{1}[t=T] + R_{\text{step},t}$ i podaj do GiGPO.

GiGPO: grupowanie po stanach-kotwicach

Standardowe GRPO daje jeden uniform advantage każdemu krokowi w epizodzie — trajektoria jest “dobra” albo “zła” globalnie. To marnuje sygnał. GiGPO rozbija credit na dwa sumowane komponenty:

$$ A_t^{\text{GiGPO}} = A^{\text{episode}}(\tau) + A^{\text{step}}\bigl(s_t, a_t \mid \mathcal{G}(s_t)\bigr) \tag{2} $$

gdzie:

• $\tau$ — pełna trajektoria
• $A^{\text{episode}}(\tau)$ — makro-advantage: z-score return epizodu w grupie $G$ rolloutów z tego samego taska (standardowe GRPO)
• $\mathcal{G}(s_t)$ — sub-grupa stanu-kotwicy: zbiór wszystkich kroków, z różnych rolloutów w grupie, które dotarły do tego samego stanu pośredniego $s_t$
• $A^{\text{step}}$ — mikro-advantage policzony wewnątrz $\mathcal{G}(s_t)$ z discounted returns

Interpretacja: Na poziomie epizodu zachowujesz pytanie GRPO: “czy ta trajektoria była globalnie lepsza od sąsiadów?”. Na poziomie kroku pytasz ostrzej: wśród wszystkich rolloutów, które przeszły przez dokładnie ten sam stan pośredni, który wybrał lepszy kolejny ruch? To per-step credit assignment bez sieci value i bez dodatkowych rolloutów.

Pełny algorytm:

Algorithm: GiGPO z rewardami PRM
1. Dla każdego taska odpal G rolloutów (w paperze G = 8).
2. Zbierz łączny reward per krok R_t z równania (1).
3. Episode-level: znormalizuj zwroty epizodów w grupie -> A^episode.
4. Zgrupuj krotki krokowe ze wszystkich G rolloutów po stanie-kotwicy s_t.
5. W każdym bucketcie policz advantage znormalizowane po discounted returns -> A^step.
6. Ustaw A_t = A^episode + A^step i zrób update polityki (backbone: verl / verl-agent).

Bez dodatkowego critica, bez dodatkowych rolloutów, bez zmiany architektury polityki.

ClawGUI-Eval: Infer → Judge → Metric

Harness ewaluacyjny stoi na jednej obserwacji: inference i judging powinny być rozdzielone. Dzisiejszy de facto standard to monolityczny skrypt eval per benchmark; jeśli judge ma buga albo chcesz spróbować innej reguły oceniania, musisz odpalić inference każdego modelu od nowa, na każdym GPU. ClawGUI-Eval rozbija to na trzy etapy:

• Infer. Lokalnie (HuggingFace Transformers, multi-GPU przez multiprocessing, checkpointing na poziomie shardów) albo przez dowolne OpenAI-compatible API. Kluczowo: zapisuje surowe predykcje na dysk.
• Judge. Scoring specyficzny dla benchmarka: point-in-box dla klasycznego groundingu, polygon + refusal-aware dla OSWorld-G, multi-action matching dla AndroidControl.
• Metric. Agregacja z breakdownami per platforma / typ elementu / kategoria zadania.

Ponieważ Infer jest oddzielone od Judge, społeczność może dokładać nowe judge’y bez ponownego inference. ClawGUI-Eval publikuje archiwa surowych predykcji do re-judgeu.

Z tym pipeline’em autorzy zmierzyli 95.8% reprodukcji wyników oficjalnych na 48 komórkach (model × benchmark): 46 komórek odtworzonych w tolerancji $\pm 2%$ lub wyżej. Dwie komórki porażki dotyczyły modeli, których oficjalne configi ewaluacji nigdy nie zostały publicznie opisane — empiryczna walidacja tezy, że to nieudokumentowana konfiguracja, a nie metodologia, psuje reprodukowalność.

Ciekawy efekt uboczny: zamknięte frontier-modele (Gemini, Seed) wymagały paradygmatu “Zoom” — kafelków crop 25% lub 50% — żeby odtworzyć ich publikowane wyniki na ScreenSpot-Pro. Standardowe inference zaniża te systemy, bo były oceniane w innym reżimie wejścia.

ClawGUI-Agent: hybrydowe CLI-GUI z pamięcią

Deploy ma dwie dyskretne decyzje projektowe warte nazwania:

• Kontrola hybrydowa CLI + GUI. Czyste CLI jest szybkie i precyzyjne, ale nie pokrywa wszystkich aplikacji. Czyste GUI pokrywa wszystko, ale jest wolne dla zadań z API. ClawGUI-Agent decyduje per krok, którego kanału użyć, z fallbackiem do GUI gdy CLI nie ma zastosowania.
• Pamięć personalizowana. Store oparty na vector embeddings z top-k retrieval i merge’owaniem duplikatów, dzięki czemu agent pamięta preferencje użytkownika między sesjami (lotnisko domowe, ulubiona kuchnia) bez wycieku stanu między użytkownikami.

ClawGUI-Agent działa na Androidzie, HarmonyOS i iOS, i jest wystawiony przez 12+ platform chatowych (Feishu, DingTalk, Telegram, Discord, Slack, QQ, …). Co więcej, sam ClawGUI-Eval jest wystawiony jako skill wywoływany językiem naturalnym — możesz dosłownie napisać na Slacku “zewaluuj UI-TARS-7B na ScreenSpot-Pro”.

Eksperymenty

ClawGUI-2B — model 2B fine-tunowany end-to-end w ClawGUI-RL startując z MAI-UI-2B — to nagłówkowy wynik.

Model 2B, wytrenowany we właściwym pipeline, bije 32B i 72B konkurentów na realnych zadaniach mobilnych GUI.

Ablacja: co daje gęsty reward?

To +2.6 SR absolutnie lub +17.9% relatywnie z przejścia na gęsty sygnał krokowy z grupowaniem po stanach-kotwicach. Dla długoterminowego treningu agenta to duży efekt — i uzyskany bez uczonej sieci value.

Gdzie ClawGUI wciąż przegrywa

Dla kontekstu, frameworki agentic łączące zamkniętego plannera z dedykowanym modułem groundingu osiągają na tym samym benchmarku znacznie wyższe liczby:

To inny reżim — zamknięci plannerzy plus wyspecjalizowane moduły groundingu — i porównanie nie jest jabłko-do-jabłka. Sensowne odczytanie: mała, otwarta polityka end-to-end wciąż ma długi pas startowy zanim dogoni dużego, zamkniętego plannera, ale infrastrukturalna parytet właśnie została osiągnięta.

Dlaczego to działa — infrastruktura jest wąskim gardłem

Cicha teza tego papera brzmi tak: ostatnie postępy w agentach GUI były gated nie przez pomysły, lecz przez hydraulikę. Trzy konkretne kawałki hydrauliki dominują:

1. Niezawodność środowiska. Sama rotacja spare serverów to różnica między runem, który się kończy, a runem, który po cichu staje w nocy.
2. Gęstość rewardu. Sam outcome RL nie działa na horyzoncie 30+ kroków; judge-jako-PRM to tani sposób wstrzyknięcia gradientu wszędzie.
3. Higiena ewaluacji. Większość nieodtwarzalności to nie problem modelowania, lecz nieudokumentowane rozdzielczości i prompty. Rozdzielenie Infer od Judge czyni to audytowalnym.

Implicytne twierdzenie papera — że model 2B w czystym pipeline może pobić 72B w bałaganie — jest twierdzeniem infrastrukturalnym, nie modelingowym.

Ograniczenia

Na plus autorom, ograniczenia są wyłożone uczciwie:

• Absolutny SR wciąż niski. 17.1% to daleko od użyteczności dla każdego, i dużo niżej niż górne granice frameworków agentic (55.6%).
• Rewardy na realnych urządzeniach są szumne. Bez weryfikacji systemowej outcome reward na fizycznych telefonach pochodzi z MLLM judge, który może się mylić.
• Koszt PRM. Qwen3.5-72B jako step judge jest drogi przy inference i może ograniczać throughput rolloutów.
• Łagodne kryterium reprodukcji. Tolerancja $\pm 2%$ w liczbie 95.8% absorbuje drobny dryf konfiguracji i nie gwarantuje bit-exact reprodukcji.
• Szerokość ewaluacji. Walidacja end-to-end jest raportowana na 117 taskach MobileWorld GUI-Only; szersze liczby end-to-end (desktop, HarmonyOS) jeszcze nie są dostępne.

Podsumowanie

1. Agenty GUI to problem full-stack: trening, ewaluacja i deploy muszą być otwarte i połączone. ClawGUI to pierwszy release, który otwiera wszystkie trzy naraz.
2. Gęsty sygnał krokowy jest niezbędny dla long-horizon agent RL. Process Reward Model plus GiGPO daje per-step credit bez uczonego critica i jest warty +17.9% relatywnego SR na MobileWorld.
3. 95.8% raportowanych liczb GUI-benchmark jest odtwarzalne, gdy konfiguracje inference są pinowane per model — pozostała luka to nieudokumentowane prompty i rozdzielczości, nie metodologia.
4. Dobrze zinżynierowana polityka 2B potrafi bić nietrenowane modele 72B na realnych taskach mobilnych. Liczba parametrów nie jest obecnym wąskim gardłem — infrastruktura jest.
5. Frameworki agentic z zamkniętymi plannerami wciąż wygrywają w absolutnym SR. Otwarte polityki end-to-end mają miejsce do wzrostu — ale mają już w czym rosnąć.

Z mojej perspektywy najważniejsza linia papera to ta, której nigdy nie napisano wprost: wąskim gardłem agentów GUI była inżynieria, nie nauka. ClawGUI to wąskie gardło przesuwa — i tym samym prawdopodobnie otwiera falę badań małych zespołów, która wcześniej była niemożliwa.

Źródła i materiały:

• 📄 Paper: ClawGUI: A Unified Framework for Training, Evaluating, and Deploying GUI Agents