OmniParser — zamiana modelu LLM w agenta obsługującego interfejs graficzny

Agent, który ma obsłużyć program za człowieka, napotyka problem, o którym łatwo zapomnieć: musi najpierw zobaczyć, co jest na ekranie. Model językowy dostaje zrzut ekranu i ma na jego podstawie powiedzieć „kliknij w przycisk Zapisz" — ale żeby to kliknięcie trafiło, ktoś musi zamienić obraz na współrzędne. Bez tej warstwy agent zgaduje, a zgadywanie przy operacjach na cudzym systemie kończy się źle.

OmniParser jest właśnie tą warstwą. Rozkłada zrzut ekranu interfejsu na uporządkowane, opisane elementy — gdzie są ikony, które z nich są klikalne i co prawdopodobnie robią. Dopiero taka struktura pozwala modelowi wskazać działanie, które da się precyzyjnie umiejscowić na ekranie.

Projekt pochodzi z Microsoft Research, ma za sobą publikację naukową i 25 386 gwiazdek. Ma też najbardziej zaplątaną sytuację licencyjną, jaką spotkałem w tej serii — i od tego zacznę, bo to jest rzecz, którą trzeba rozstrzygnąć przed napisaniem pierwszej linii kodu, nie po.

Cztery licencje i jedna sprzeczność

Zacznijmy od tego, co widać na pierwszy rzut oka. README ma odznakę z napisem MIT, odsyłającą do treści tej licencji na stronie Open Source Initiative. Tymczasem plik LICENSE w repozytorium to Creative Commons Attribution 4.0 International — dziewiętnaście kilobajtów tekstu licencji treści, nie oprogramowania. GitHub raportuje dla tego repozytorium właśnie CC BY 4.0. Odznaka i plik mówią więc dwie różne rzeczy, a w razie sporu liczy się plik.

To nie drobiazg formalny. CC BY 4.0 jest licencją permisywną — pozwala na użycie komercyjne, modyfikację i redystrybucję pod warunkiem podania autorstwa. Ale sama organizacja Creative Commons odradza stosowanie swoich licencji do oprogramowania, bo nie odnoszą się one do spraw właściwych dla kodu: nie rozróżniają formy źródłowej od wynikowej i — co istotniejsze — nie udzielają licencji patentowej. Apache 2.0 to robi wprost, MIT jest w tej kwestii milczący ale utrwalony orzecznictwem i praktyką, a CC BY po prostu nie jest do tego przewidziana. Przy projekcie z laboratorium badawczego dużej firmy technologicznej brak jawnego udzielenia patentowego jest tym, o co prawnik zapyta pierwszy.

Drugi poziom to wagi modeli, które mają własną, osobną sekcję w README. Są tam trzy reżimy jednocześnie:

icon_detect_v3 — najnowszy detektor obszarów interaktywnych, oparty na implementacji YOLOv9 na licencji MIT.
Starsze detektory oparte na Ultralytics — zachowują swoją pierwotną licencję AGPL.
Modele opisujące ikony — na licencji MIT.

Widać tu wyraźnie, po co powstała wersja trzecia detektora: żeby wyjść z AGPL. W dziale aktualności README zmiana ta jest datowana na lipiec 2026 i opisana jako dodanie detektora YOLOv9-E.

I tu trzeci poziom, którego nie znajdziesz w żadnej sekcji o licencjach, a który sprawdziłem w pliku zależności. requirements.txt nadal zawiera wpis ultralytics==8.3.70. Biblioteka Ultralytics jest wydana na AGPL-3.0 — potwierdzają to zgodnie metadane jej repozytorium i pakietu na PyPI, wraz z klasyfikatorem „GNU Affero General Public License v3 or later".

Czyli: nawet jeśli użyjesz nowych wag detektora, które celowo uciekły od AGPL, standardowa instalacja zależności wciąga do twojego środowiska bibliotekę na AGPL-3.0. Dla zastosowania badawczego albo wewnętrznego narzędzia to bez znaczenia. Dla produktu udostępnianego klientom przez sieć — a agent obsługujący interfejs graficzny bywa właśnie takim produktem — klauzula sieciowa AGPL jest dokładnie tym, co uruchamia obowiązek udostępnienia źródeł. Zanim wbudujesz to w ofertę handlową, ustal z kimś kompetentnym, czy Ultralytics jest w twoim wdrożeniu faktycznie wykorzystywany, czy tylko zainstalowany, i jakie to ma konsekwencje.

Podsumowując cztery poziomy: repozytorium na CC BY 4.0 (przy odznace mówiącej MIT), nowy detektor z rodowodem MIT, starsze detektory na AGPL, biblioteka zależna na AGPL-3.0. To nie dyskwalifikuje projektu — to znaczy, że decyzję licencyjną trzeba podjąć świadomie, a nie odziedziczyć przez pip install.

Stan projektu

Trzeba to powiedzieć uczciwie: tempo prac jest wolne. Na gałęzi master ostatnie commity pochodzą z 18 i 20 lipca 2026 i dotyczą właśnie nowego detektora YOLOv9-E. Wcześniejsza aktywność to wrzesień 2025. W ciągu ostatniego roku doszły więc do gałęzi głównej zasadniczo dwie zmiany.

Czy to dyskwalifikuje? Zastosowałem tu ten sam test, którym mierzę inne pozycje w tej serii: czy bezczynność uderza w sedno wartości projektu. OmniParser to artefakt badawczy plus wagi modeli — jego wartością są modele i sama metoda rozkładania interfejsu, a te nie psują się z upływem miesięcy tak, jak psuje się zbiór „najnowszych przepisów". Do tego jedyna świeża zmiana była merytoryczna i rozwiązywała realny problem licencyjny. To projekt wolny, ale nie martwy.

Z osiągnięć wartych odnotowania: wersja druga uzyskała 39,5% na benchmarku ScreenSpot Pro, model był najlepszy na Windows Agent Arena we wrześniu 2024, a w październiku 2024 był modelem numer jeden w rankingu popularności na Hugging Face. Repozytorium: microsoft/OmniParser.

Instalacja i jedna niewygodna rzecz

Środowisko stawia się na condzie z Pythonem 3.12:

conda create -n "omni" python==3.12
conda activate omni
pip install -r requirements.txt

Potem trzeba pobrać wagi — i tutaj instrukcja robi coś, co warto zauważyć. Dokumentacja mówi wprost: dopóki pull request numer 37 na Hugging Face nie zostanie scalony, najnowszy detektor pobiera się z tego właśnie, niescalonego pull requesta:

huggingface-cli download microsoft/OmniParser-v2.0 icon_detect_v3/model.pt \
  --revision refs/pr/37 --local-dir weights

To stan tymczasowy trwający od lipca 2026. Rewizja wskazująca na pull requesta może się zmienić albo zniknąć, a wtedy instrukcja przestanie działać. Praktyczna rada: jeśli to wdrażasz, pobierz plik raz, policz jego sumę kontrolną i trzymaj go w swoim własnym magazynie artefaktów, zamiast polegać przy każdym budowaniu na gałęzi cudzego, otwartego pull requesta. Po scaleniu wagi będą pobierane automatycznie przy pierwszym użyciu.

Do tego drobiazg dla osób na Windowsie: biblioteka OCR używana w projekcie to Paddle, która wymaga zainstalowanego pakietu redystrybucyjnego C++. Bez niego dostaniesz błąd o nieznalezionym module libpaddle, którego treść nijak nie wskazuje przyczyny.

Jak to działa w kodzie

Potok najłatwiej zrozumieć, czytając dostarczone demo. Składa się z trzech etapów i każdy używa innego modelu.

Najpierw OCR: funkcja check_ocr_box wyciąga z obrazu tekst wraz z ramkami. Dostępne są dwa silniki — EasyOCR z progiem pewności tekstu 0,9 oraz PaddleOCR, przy czym w demo ten drugi jest domyślnie włączony. Potem detektor ikon, czyli model YOLO wczytywany przez get_yolo_model, znajduje obszary interaktywne, których OCR nie widzi, bo nie są tekstem. Na końcu model opisujący — domyślnie Florence-2, z zakomentowanym wariantem BLIP-2 — nadaje wykrytym ikonom opis funkcji.

Wszystko spina funkcja get_som_labeled_img, która zwraca trzy rzeczy: obraz z narysowanymi, ponumerowanymi znacznikami, mapę współrzędnych oraz listę rozpoznanych elementów. Skrót „som" w nazwie to Set-of-Mark i wyjaśnia całą metodę: modelowi wizyjnemu pokazujesz zrzut z ponumerowanymi obszarami, on odpowiada „kliknij czternaście", a ty odwzorowujesz numer na współrzędne z mapy. Model nie musi więc podawać pikseli — a to właśnie podawanie pikseli jest tym, w czym modele językowe są zawodne.

Parametry, które warto znać, bo od nich zależy jakość wyniku, są w demo wystawione jako suwaki wraz z wartościami domyślnymi:

box_threshold, domyślnie 0,05 — progowa pewność, poniżej której ramka jest odrzucana. To wartość bardzo liberalna, nastawiona na to, by nie przeoczyć elementu, kosztem fałszywych trafień.
iou_threshold, domyślnie 0,1 — próg nakładania się ramek, powyżej którego duplikaty są usuwane.
imgsz, domyślnie 640, z możliwością podniesienia do 1920 — rozmiar obrazu podawanego detektorowi ikon. To najważniejszy parametr przy ekranach o wysokiej rozdzielczości: przy 640 małe ikony w gęstym interfejsie po prostu znikają w skalowaniu.

Jeśli więc pierwsze uruchomienie na waszym oprogramowaniu wypada słabo, kolejność prób jest taka: najpierw podnieś imgsz, potem pobaw się progami, a dopiero na końcu podejrzewaj model.

Dwie rzeczy w samym pliku demo warto przy okazji odnotować. Urządzenie jest w nim ustawione na stałe jako torch.device('cuda'), mimo że dokumentacja OmniTool mówi wprost, iż parser potrafi działać na procesorze — bez karty graficznej to demo wymaga więc zmiany jednej linii. A wywołanie kończące plik to demo.launch(share=True, ...), czyli uruchomienie demo tworzy publiczny, tymczasowy odnośnik do twojej instancji przez usługę tunelującą Gradio. Adres serwera jest owszem ustawiony na pętlę lokalną, ale przy share=True tunel i tak powstaje. Jeśli podajesz temu narzędziu zrzuty ze swojego prawdziwego stanowiska pracy, tę flagę wyłącz przed pierwszym uruchomieniem.

OmniTool — cały komputer dla agenta

Obok samego parsera w repozytorium siedzi OmniTool: gotowe stanowisko, na którym agent obsługuje maszynę wirtualną z Windowsem 11. Składa się z trzech elementów: serwera FastAPI z OmniParserem, kontenera Docker z maszyną wirtualną Windows 11 (nazwanego OmniBox) oraz interfejsu Gradio, w którym wpisuje się polecenia i obserwuje rozumowanie oraz wykonanie.

Obsługiwane modele wizyjne to według dokumentacji OpenAI, DeepSeek R1, Qwen 2.5VL oraz Anthropic Computer Use. Autorzy podają też zalecaną topologię: OmniBox i Gradio na maszynie z procesorem, a serwer parsera na maszynie z układem graficznym — sam parser działa na procesorze, ale wtedy wolno.

Wymagania są konkretne i warto je znać przed rozpoczęciem. Trzeba mieć około 30 GB wolnego miejsca: obraz instalacyjny to około 6 GB, kontener 400 MB, a katalog stanu maszyny 20 GB. Pierwsze utworzenie trwa od 20 do 90 minut, zwykle około godziny. Podglądać można przez przeglądarkę, przez wbudowany klient NoVNC.

Jest też ograniczenie platformowe: maszyna wirtualna zależy od KVM, więc szybko zadziała wyłącznie na Windowsie i Linuksie. Na macOS ta część odpada w praktyce.

Windows w kontenerze — i licencja, która wygasa

Ta sekcja jest osobno, bo w polskiej firmie to będzie pierwsze pytanie od osoby odpowiedzialnej za zgodność.

OmniBox nie dowozi Windowsa. Instrukcja każe wejść do Centrum Oceny Microsoftu, zaakceptować regulamin i pobrać obraz Windows 11 Enterprise Evaluation — wersji próbnej na 90 dni, po czym zmienić jego nazwę na custom.iso i wrzucić do odpowiedniego katalogu.

To rozwiązanie sensowne dla eksperymentu i całkowicie legalne w ramach warunków, na które się zgadzasz. Ale ma dwie konsekwencje. Pierwsza jest oczywista: po dziewięćdziesięciu dniach próba się kończy. Stanowisko, które miało być stałym elementem waszego procesu — na przykład do testów regresyjnych interfejsu — będzie wymagało własnej, opłaconej licencji Windowsa, a nie odnawiania wersji próbnej. Druga jest subtelniejsza: warunki wersji ewaluacyjnej służą ocenie produktu, więc oparcie na nich stałego procesu produkcyjnego to nie jest to, do czego ta licencja jest przeznaczona. Jeśli OmniTool ma u was zostać, przewidźcie licencję w budżecie od początku.

Warto też wiedzieć, że proces tworzenia maszyny instaluje w niej długą listę aplikacji — jeśli zależy ci na szybkości, dokumentacja wskazuje konkretny zakres linii w skrypcie instalacyjnym do zakomentowania, żeby dostać wariant minimalny.

Bezpieczeństwo

Tu trzeba połączyć trzy rzeczy, z których dwie autorzy mówią sami, a jedną widać w historii zmian.

Po pierwsze, w historii commitów z września 2025 są zmiany o wymownych opisach: 0.0.0.0 -> 127.0.0.1 oraz „bind to default qemu address". Wcześniejsze wersje wystawiały usługi na wszystkie interfejsy sieciowe. To zostało naprawione, ale mówi coś o wieku i pochodzeniu tego kodu — a przy uruchamianiu takiego stanowiska warto samodzielnie sprawdzić, co faktycznie nasłuchuje i na czym, zamiast założyć, że domyślne wiązania są bezpieczne.

Po drugie, i to jest ryzyko wpisane w samą naturę tego narzędzia: agent obsługujący interfejs graficzny czyta treść ekranu i na jej podstawie działa. Treść ekranu może pochodzić od kogoś obcego — ze strony internetowej, z wiadomości, z dokumentu. Wstrzyknięcie instrukcji w to, co agent widzi, jest tu wektorem strukturalnym, nie teoretycznym. Dokumentacja projektu podaje własną odpowiedź na to i jest ona rozsądna: zalecamy pozostawienie człowieka w pętli, aby zminimalizować ryzyko. Autorzy wspominają też, że dla OmniTool przeprowadzili analizę modelu zagrożeń narzędziem Microsoft Threat Modeling Tool.

Po trzecie, sekcja o ryzykach zawiera jedną rzecz, która zasługuje na uznanie. Model opisujący ikony był trenowany z użyciem danych z zakresu odpowiedzialnej sztucznej inteligencji tak, by unikał wnioskowania o cechach wrażliwych — pochodzeniu, wyznaniu i podobnych — osób, które przypadkiem znajdą się na obrazkach ikon. Autorzy zachęcają też, by nie stosować parsera do zrzutów zawierających treści szkodliwe albo przemocowe. To nieczęsty widok: projekt, który sam wskazuje, co jego model mógłby zrobić źle, i opisuje, jak temu zaradzono.

Zrzuty ekranu to dane

Ostatnia rzecz do przemyślenia przed wdrożeniem w firmie. Zrzut ekranu roboczego stanowiska zawiera to, co jest na tym stanowisku: nazwiska klientów w systemie CRM, treść wiadomości, numery spraw, czasem dane wrażliwe. Jeśli parser działa lokalnie, dane pozostają u was. Ale model wizyjny, który na podstawie tej struktury decyduje o działaniu, w typowej konfiguracji jest zdalny — a to znaczy, że zrzuty albo ich opisy opuszczają waszą infrastrukturę.

To decyzja do podjęcia świadomie, tak samo jak przy każdym narzędziu wysyłającym treść do zewnętrznego dostawcy: albo model działa u was, albo przepływ danych musi być pogodzony z tym, co obiecaliście klientom. Przy testach na maszynie wirtualnej z syntetycznymi danymi problem nie istnieje; przy agencie puszczonym na prawdziwe stanowisko pracy istnieje w pełni.

Pułapki w jednym miejscu

Odznaka w README mówi MIT, plik LICENSE to CC BY 4.0. Liczy się plik. CC BY nie udziela licencji patentowej i nie jest przewidziana do oprogramowania.
requirements.txt instaluje ultralytics==8.3.70, czyli bibliotekę na AGPL-3.0 — niezależnie od tego, których wag użyjesz.
Starsze wagi detektora zachowują licencję AGPL. Tylko icon_detect_v3 ma rodowód MIT.
Najnowsze wagi pobiera się z niescalonego pull requesta. Zapisz plik u siebie z sumą kontrolną, nie polegaj na cudzej gałęzi.
Windows dla OmniBox to wersja próbna na 90 dni. Stały proces wymaga własnej licencji.
Maszyna wirtualna wymaga KVM — szybko działa tylko na Windowsie i Linuksie.
30 GB miejsca i do 90 minut na pierwsze uruchomienie OmniBoksa.
Wcześniejsze wersje wiązały usługi na 0.0.0.0. Sprawdź samodzielnie, co nasłuchuje.
Wstrzyknięcie instrukcji przez treść ekranu jest wektorem strukturalnym. Zalecenie autorów — człowiek w pętli — nie jest kurtuazją.
Dostarczone demo startuje z share=True — tworzy publiczny tunel do twojej instancji. Wyłącz, zanim podasz mu prawdziwe zrzuty ekranu.
Demo ma zaszyte cuda, choć parser działa też na procesorze — bez karty trzeba zmienić jedną linię.
Domyślny imgsz to 640. Przy ekranach o wysokiej rozdzielczości małe ikony gubią się w skalowaniu — podnieś ten parametr przed obwinianiem modelu.
Na Windowsie Paddle wymaga pakietu redystrybucyjnego C++, inaczej błąd o module libpaddle.
Około dwóch commitów na gałęzi głównej w ciągu roku. Nie licz na szybką reakcję na zgłoszenie.

Podsumowanie

OmniParser rozwiązuje konkretny, trudny problem: zamienia obraz interfejsu w strukturę, na której model językowy może oprzeć precyzyjne działanie. Jako artefakt badawczy z publikacją, wagami i gotowym stanowiskiem testowym jest jednym z najlepszych punktów wyjścia, jeśli chcecie sprawdzić, czy agenty obsługujące interfejs graficzny mają u was sens.

Struktura zamiast obrazu — wykrywanie obszarów interaktywnych wraz z opisem funkcji ikony i informacją, czy element jest klikalny.
Gotowe stanowisko OmniTool — parser, maszyna z Windowsem 11 w kontenerze i interfejs do obserwowania działania agenta.
Niezależność od dostawcy modelu — obsługa modeli OpenAI, DeepSeeka, Qwena i Anthropic bez zmian w kodzie.
Zmierzone wyniki — 39,5% na ScreenSpot Pro i pierwsze miejsce na Windows Agent Arena, zamiast samych zapewnień.
Uczciwa sekcja o ryzykach — z opisem, jak trenowano model, by nie wnioskował o cechach wrażliwych osób widocznych na ikonach.
Detektor przeniesiony na rodowód MIT — świadome wyjście od AGPL w wersji trzeciej, nawet jeśli zależności jeszcze za tym nie nadążyły.

Licencyjnie jest to najbardziej wymagająca pozycja, jaką dotąd w tej serii opisywaliśmy, i nie da się jej streścić jednym zdaniem. Repozytorium jest wydane na CC BY 4.0 — permisywnie, ale bez udzielenia patentowego i wbrew zaleceniom samej organizacji Creative Commons co do stosowania jej licencji do kodu. Odznaka w README mówi MIT i jest z tym w sprzeczności. Nowy detektor ma rodowód MIT, starsze detektory pozostają na AGPL, a lista zależności nadal instaluje bibliotekę na AGPL-3.0. Do badań i narzędzi wewnętrznych to układ całkowicie do przyjęcia. Do produktu sprzedawanego klientom — wymaga rozmowy z prawnikiem, odbytej przed pierwszym wdrożeniem, a nie po nim.