Ui.Vision — otwarte RPA zgodne z Selenium IDE

Automatyzacja przeglądarki w pracy agencyjnej ma trzy twarze i tylko jedna z nich to testy. Pierwsza: powtarzalne wypełnianie formularza w cudzym panelu, który nie ma API i nie będzie miał. Druga: przeklikanie ścieżki zakupowej przed każdym wdrożeniem, bo tego fragmentu nikt nie objął testami. Trzecia: wyciągnięcie danych z systemu, który eksportu nie przewiduje.

Do drugiej z nich jest Playwright i jest właściwym narzędziem. Do pierwszej i trzeciej bywa przerostem — nie chodzi o test w pipeline'ie, a o przeklikanie czegoś raz albo raz w tygodniu, często przez osobę, która nie otworzy terminala. I właśnie w tę lukę wchodzi kategoria narzędzi zwana RPA.

Ui.Vision (github.com/A9T9/RPA) jest rozszerzeniem do Chrome'a, Edge'a i Firefoksa: rejestrator makr zgodny z Selenium IDE, z warstwą rozpoznawania obrazu i OCR — a od niedawna także z mostem MCP, przez który Claude Code tworzy, edytuje i uruchamia makra w naszej przeglądarce. To ostatnie jest tu najciekawsze i najświeższe, więc dojdziemy do niego po omówieniu fundamentów.

Stan projektu

Dane z API GitHuba na 26 września 2026:

• 2007 gwiazdek i 407 forków, kod w JavaScripcie,
• repozytorium założone 4 sierpnia 2017 — dziewięć lat rozwoju, co przy narzędziu do automatyzacji cudzych interfejsów jest istotne, bo znaczy, że przeżyło kilka generacji zmian w przeglądarkach,
• ostatni push z 9 sierpnia 2026, tylko 7 otwartych zgłoszeń,
• tempo wydań w sierpniu: V10.0.31, V10.0.44, V10.0.56, V10.0.105 — od 31 do 105 w numerze poprawki w ciągu dziewięciu dni. Iteracje są bardzo szybkie,
• rozwijane przez a9t9 software GmbH, z rozszerzeniem publikowanym w sklepach Chrome'a, Firefoksa i Edge'a.

Wsparcie odbywa się na forum użytkowników, monitorowanym — jak zapowiada README — przez aktywnych użytkowników, wsparcie techniczne i deweloperów. Projekt prosi, żeby pytania publiczne zadawać najpierw tam, a nie w trackerze; to wyjaśnia siedem otwartych zgłoszeń przy narzędziu o takim zasięgu.

Licencja i granica open source

Trzeba to postawić wcześnie, bo model jest nietypowy — a jednocześnie opisany w pliku licencji tak klarownie, że warto go streścić dla wszystkich projektów o podobnej konstrukcji.

Ui.Vision jest dwulicencyjny: AGPLv3 albo licencja komercyjna, do wyboru. Cały projekt jest przy tym własnością i pod pełną kontrolą a9t9 software GmbH, która wykonuje przeważającą część prac; wkład z zewnątrz jest rzadki i przyjmowany na licencji dla firmy. To nie jest projekt społecznościowy z komercyjnym sponsorem, a produkt firmy udostępniony na licencji copyleft.

FAQ w pliku licencji rozstrzyga natomiast dokładnie te wątpliwości, które przy AGPL pojawiają się najczęściej:

• Do komercyjnego używania Ui.Vision licencja komercyjna nie jest potrzebna. Cały tekst licencyjny dotyczy kodu źródłowego, nie korzystania z narzędzia — i README powtarza to wprost: darmowe do celów prywatnych i komercyjnych,
• Nie jest też potrzebna do redystrybucji albo dołączenia niezmodyfikowanej wersji do własnego projektu, o ile Ui.Vision pozostaje osobny i niezmieniony. Licencja podaje konkretny przykład: firmy, które pozwalają swoim użytkownikom nagrywać makra uruchamiane potem przez ich komercyjny backend monitorujący — bez żadnej opłaty i bez licencji,
• Jest potrzebna, jeśli chcemy używać albo redystrybuować zmodyfikowaną wersję rdzenia, albo włączyć jego kod (choćby częściowo) do swojego projektu bez publikowania tego projektu na AGPL,
• dla projektów open source na innej licencji autorzy proponują kontakt i „prawdopodobnie da się coś ustalić".

Granica open source jest natomiast opisana w osobnym pliku i warto ją znać przed planowaniem wdrożenia. Repozytorium zawiera kompletne, gotowe do uruchomienia rozszerzenie rdzenia. Nie zawiera kodu źródłowego XModules — binarnych, wieloplatformowych modułów desktopowych, instalowanych osobno i komunikujących się z rozszerzeniem przez native messaging.

Podział jest więc czysty i łatwy do zapamiętania: automatyzacja przeglądarki jest otwarta, automatyzacja pulpitu wymaga zamkniętych modułów. Nie ma tu funkcji okrojonych ani limitów w wersji darmowej — jest granica technologiczna między tym, co dzieje się w karcie przeglądarki, a tym, co wychodzi na system.

Trzy warstwy wejścia

To jest najbardziej użyteczna wiedza z całego wpisu i rzecz, którą Ui.Vision nazywa wyraźniej niż jakiekolwiek inne narzędzie w tej kategorii. Każdy, kto automatyzował cudzy panel, zderzył się z tym problemem — tu ma on nazwę i trzy poziomy rozwiązania.

1. uiv.page.* — zdarzenia syntetyczne. Wysyłane przez content script, najszybsza forma wprowadzania danych. Nie wymaga wcześniejszego kliknięcia w pole, więc wypełnienie formularza to jedno wywołanie:

uiv.page.fill('id=email', 'user@example.com');

Wada jest jedna i znana: część witryn ignoruje zdarzenia syntetyczne — bo sprawdza, czy zdarzenie pochodzi od użytkownika.

2. uiv.browser.* — zaufane wejście przez Chrome DevTools Protocol. Prawdziwe, pośredniczone przez przeglądarkę kliknięcia i naciśnięcia klawiszy. Działa tam, gdzie warstwa syntetyczna zawodzi: aplikacje rysowane na canvasie i widżety weryfikujące pochodzenie zdarzeń. Nie wymaga XModule — ale nie jest dostępna w Firefoksie, gdzie trzeba użyć warstwy strony albo pulpitu.

3. uiv.desktop.* — prawdziwe wejście systemowe. Jedyna warstwa wychodząca poza przeglądarkę: okna dialogowe systemu, okna innych aplikacji, natywne elementy interfejsu. Wymaga XModule, czyli tego zamkniętego, instalowanego osobno modułu; systemowy prompt narzędzia informuje w linii środowiska, czy jest zainstalowany.

Zalecana kolejność jest przy tym jasno zapisana i warto ją przyjąć jako regułę: zacznij od warstwy strony dla formularzy, przejdź do warstwy przeglądarki, gdy syntetyczne kliknięcia nie działają, a warstwy pulpitu używaj wyłącznie do celów faktycznie leżących poza przeglądarką. Eskalacja, nie wybór na starcie.

Cztery sposoby celowania w element

Selektor DOM działa, dopóki strona ma stabilne atrybuty. Gdy ich nie ma — a w cudzych panelach zwykle nie ma — Ui.Vision daje trzy warstwy wizualne.

• uiv.$ — zwykłe selektory DOM, pierwsza i najtańsza droga,
• uiv.findImage() — rozpoznawanie obrazu na wyrenderowanej stronie. Wymaga zapisanego obrazu wzorcowego. Właściwe dla przycisków i kontrolek, które nie mają ani stabilnych atrybutów, ani czytelnego tekstu,
• uiv.ocr.findText() — OCR odnajdujący tekst w dowolnym miejscu wyrenderowanej strony, ze znakami wieloznacznymi ? i * stosowanymi per słowo. Dokumentacja podkreśla, że jest to pełnoprawny sposób celowania we cokolwiek z etykietą, przyciski włącznie. Zalecenie praktyczne: najpierw uiv.ocr.read(), żeby sprawdzić, czy tekst jest w ogóle odczytywalny,
• uiv.ai.find() — deleguje znalezienie celu do skonfigurowanego modelu, zwracając współrzędne w pikselach.

Przy tym ostatnim dokumentacja robi rzecz, którą trzeba pochwalić osobno, bo jest dokładnie odwrotna do tego, czego można się spodziewać od narzędzia sprzedającego funkcje AI. uiv.ai.find() nie czeka automatycznie i nie ponawia, a każde wywołanie jest płatne. Zalecenie brzmi: zostaw to dla celów, które faktycznie pojawiają się tylko w trakcie przebiegu albo zmieniają między uruchomieniami — bo wpisywanie tego do zapisanych makr dla celów statycznych marnuje wywołania modelu i grozi pomyłką o kilka pikseli przy powtarzalnych układach.

Trudno o lepszy przykład uczciwej dokumentacji: producent narzędzia mówi wprost, żeby jego najbardziej marketingowej funkcji używać najrzadziej.

Makra jako JavaScript, nie tabela komend

Klasyczna tabela komend Selenium IDE nadal działa, ale makra można dziś pisać jako nowoczesny JavaScript przez API uiv.*: finderów DOM i wizualnych, trzech warstw wejścia, zrzutów ekranu, kart, plików CSV i pobrań.

Kluczowa właściwość tego API jest jednak inna i to ona decyduje o jakości pracy: każde wywołanie samo czeka na element i rzuca prawdziwy wyjątek JavaScriptu przy niepowodzeniu — więc try/catch po prostu działa.

try {
  await uiv.page.fill('id=email', 'user@example.com');
  await uiv.browser.click(await uiv.ocr.findText('Zatwierdź'));
} catch (e) {
  await uiv.screenshot('blad-checkout');
  throw e;
}

To jest różnica jakościowa wobec tabeli komend, w której obsługa błędu jest osobnym mechanizmem, a „poczekaj na element" — osobną komendą, o której trzeba pamiętać.

Dla zespołów z zaległym dorobkiem w Selenium IDE jest przy tym przygotowana droga migracji, a nie przepisywanie od zera: plik uiv-commands.md w repozytorium mapuje każdą klasyczną komendę tabeli na odpowiednik uiv.* — albo na most uiv.run('command', 'target', 'value') tam, gdzie natywnej metody jeszcze nie ma. Import i eksport formatu Selenium IDE działa w obie strony.

Most MCP: Claude Code steruje przeglądarką

Najświeższa część projektu i najciekawsza dla naszych czytelników. Most pozwala Claude Code i innym klientom MCP budować, edytować i uruchamiać makra Ui.Vision, korzystając z tych samych narzędzi, których używa wbudowany czat w panelu bocznym.

Architektura jest prosta i ma w sobie jeden ładny detal techniczny:

Claude Code ── MCP (stdio) ──► uivision-mcp-bridge.js ◄── WebSocket (127.0.0.1) ── rozszerzenie Ui.Vision

Most jest punktem spotkania: Claude Code uruchamia go jako serwer MCP, a panel boczny rozszerzenia sam dzwoni do jego lokalnego serwera WebSocket — bo rozszerzenia przeglądarki nie mogą przyjmować połączeń wchodzących. Wywołania narzędzi są przekazywane do rozszerzenia i wykonywane tam.

Zestaw narzędzi: create_macro, set_macro, run_macro, get_page, screenshot, pomocniki do obrazów wzorcowych, a do porządkowania — list_macros, open_macro i delete_macro, przy czym usuwanie jest ograniczone do folderu „AI Generated". Jest też get_authoring_guide, czyli referencja API uiv.*, którą klienci MCP czytają, zanim napiszą pierwsze makro; makra w formie skryptu JavaScript są formą preferowaną.

Zabezpieczenia, które warto skopiować

Ta część zasługuje na wyróżnienie, bo rozwiązuje problem, który w większości integracji agentowych jest zignorowany: skąd użytkownik ma wiedzieć, że agent właśnie coś robi, i jak zapobiec działaniu na czymś innym, niż użytkownik ma przed oczami.

• Podczas wykonywania wywołań przez most panel boczny pokazuje banner „Claude (MCP) is controlling Ui.Vision". Sterowanie nie jest ciche,
• run_macro i set_macro odmawiają działania, jeśli edytor nie pokazuje już makra, które sesja ostatnio otworzyła. Agent nie uruchomi ani nie zmieni po cichu makra, na które użytkownik w międzyczasie się przełączył w panelu.

Drugi z tych mechanizmów jest szczególnie wart uwagi, bo chroni przed klasą błędów, o której przy pracy z agentami mało kto myśli: rozjazdem między tym, co agent uważa za kontekst, i tym, co człowiek widzi na ekranie. Zamiast pytać o zgodę raz, narzędzie weryfikuje kontekst przy każdym działaniu.

Instalacja mostu i pułapka wspólna dla wszystkich klientów MCP

Instalator uruchamia się raz i robi więcej, niż zwykle robią instalatory serwerów MCP:

npx uivision-mcp-bridge --setup

Wpisuje wpis serwera uivision do każdego klienta MCP znalezionego na maszynie — Claude Code (~/.claude.json), Claude Desktop, Cursora, Windsurfa i VS Code — a potem wypisuje token do sparowania. Trzy rzeczy w tym zachowaniu są zrobione dobrze i warto ich oczekiwać od innych narzędzi: istniejąca konfiguracja jest scalana, nie nadpisywana, przed zmianą powstaje kopia .uivision-backup, a plik, który nie jest poprawnym JSON-em, jest raportowany i pozostawiony w spokoju.

Uzasadnienie istnienia takiego instalatora jest praktyczne i mówi coś o stanie ekosystemu: claude mcp add wymaga narzędzia claude na ścieżce, a tego nie ma w aplikacji desktopowej, w rozszerzeniu VS Code, w Cursorze ani w Windsurfie. Dla klienta, którego instalator nie zna, wpis dodaje się ręcznie (VS Code zagnieżdża go pod "servers", nie "mcpServers"):

{ "mcpServers": { "uivision": { "command": "npx", "args": ["-y", "uivision-mcp-bridge"] } } }

A teraz pułapka, którą warto znać niezależnie od Ui.Vision, bo dotyczy każdego serwera MCP. Klienci MCP wczytują listę serwerów przy starcie. Po zarejestrowaniu nowego trzeba więc całkowicie zamknąć klienta i otworzyć go ponownie — nowa sesja ani nowa karta nie wystarczą — a potem sprawdzić komendą /mcp, czy serwer jest na liście. I rzecz, na której traci się kwadrans: jeśli klient działał w trakcie zapisywania konfiguracji, trzeba powtórzyć instalację, bo część klientów przepisuje własną konfigurację przy wyjściu i skasowałaby świeży wpis.

Parowanie kończy się w panelu: Settings → AI → MCP bridge (Claude Code), włączenie, wklejenie tokenu, domyślny port 50888, przycisk Test. Token leży w ~/.uivision_mcp_token, a instalator wypisuje go ponownie na żądanie. Jest tu jeszcze jeden sprytny detal: dopóki rozszerzenie jest niesparowane, każdy wynik narzędzia mostu nosi wartość tokenu — więc można po prostu poprosić agenta, żeby go pokazał w czacie, bez czytania plików z dysku.

Prompt systemowy jako kod generowany ze źródła

Obserwacja, którą zbieram przez kilka ostatnich wpisów tej serii, dostaje tu najciekawszą realizację. Ui.Vision publikuje swój systemowy prompt AI — pełną referencję API uiv.* plus przepisy automatyzacji — jako stronę dokumentacji, i pozwala go nadpisać w ustawieniach (Settings → AI → System Prompt). Ten sam materiał jest dostępny jako jeden plik tekstowy llms-full.txt, do wrzucenia dowolnemu asystentowi.

Najważniejsze jest jednak to, jak ta strona powstaje: jest generowana ze źródła prawdy w kodzie (src/services/ai/macro_agent/service.ts) komendą npm run gen:ai-prompt-page, uruchamianą przy wydaniu, żeby nie rozjechała się z tym, co model faktycznie dostaje.

To jest piąty projekt w tej serii, który wersjonuje instrukcje dla modelu razem z kodem — po Prowlerze, szablonie storefrontu Saleora, ToolJecie i Open SaaS. Ale pierwszy, który generuje dokumentację promptu z kodu, żeby uniemożliwić jej rozjazd. Sam mechanizm jest wart skopiowania w każdym projekcie, w którym instrukcje dla asystenta są jednocześnie dokumentacją dla ludzi: jedno źródło, jedna komenda przy wydaniu, zero rozbieżności.

Gdzie to ma sens w naszej pracy

Trzy zastosowania i jedno wyraźne rozgraniczenie.

• Zadania w cudzych panelach bez API — jednorazowe migracje, cykliczne raporty, wprowadzanie danych. Tam, gdzie Playwright w CI jest przerostem, a uruchamiać ma to osoba, która nie otworzy terminala. Makro w rozszerzeniu, przycisk, koniec,
• Cele, których nie da się dopiąć selektorem — canvas, wykresy, podglądy PDF, aplikacje renderujące własny interfejs. OCR i rozpoznawanie obrazu robią tu to, czego selektor nie umie, a warstwa uiv.browser.* dostarcza kliknięcia, które takie aplikacje przyjmą,
• Automatyzacja pisana przez agenta — Claude Code tworzący i uruchamiający makra w otwartej przeglądarce, z podglądem w panelu i z opisanymi wyżej barierami. Przy zadaniu „przejdź przez ten panel i sprawdź piętnaście rzeczy" to jest realna oszczędność.

Czego Ui.Vision nie zastępuje: Playwrighta w CI. Do testów end-to-end w pipeline'ie chcemy kodu w repozytorium, przeglądarek bez interfejsu, przebiegów bez rozszerzenia i wyniku w formie, którą rozumie CI. Ui.Vision jest narzędziem do pracy przy przeglądarce, nie w pipeline'ie — i te dwie rzeczy dobrze się dopełniają, zamiast konkurować.

Pułapki

• Warstwa uiv.browser.* nie działa w Firefoksie — tam zostają zdarzenia syntetyczne albo warstwa pulpitu,
• uiv.desktop.* wymaga zamkniętych XModules, instalowanych osobno i komunikujących się przez native messaging. Automatyzacja poza przeglądarką nie jest częścią kodu otwartego,
• uiv.ai.find() jest płatne per wywołanie, nie czeka i nie ponawia. Do celów statycznych używaj selektorów, obrazów albo OCR,
• OCR wymaga wcześniejszego sprawdzenia uiv.ocr.read() — inaczej trafiamy w tekst, którego silnik nie odczytuje,
• Zdarzenia syntetyczne bywają ignorowane i to jest najczęstsza przyczyna makra, które „nic nie robi",
• Modyfikacja rdzenia i redystrybucja bez publikacji na AGPL wymaga licencji komercyjnej. Samo używanie, także komercyjne, jest darmowe,
• Projekt jest kontrolowany przez jedną firmę, a wkład zewnętrzny jest rzadki i przyjmowany na jej licencji,
• Klienci MCP wczytują serwery przy starcie — po rejestracji trzeba pełnego restartu, a przy kliencie działającym w trakcie instalacji powtórzenia jej,
• Numery wersji zmieniają się bardzo szybko (od 10.0.31 do 10.0.105 w dziewięć dni). Przy makrach, które mają działać niezmiennie, warto pilnować, na czym są testowane.

Podsumowanie

Ui.Vision jest dojrzałym narzędziem w kategorii, w której dojrzałość jest rzadka — dziewięć lat rozwoju, aktywne wydania i wyjątkowo uczciwa dokumentacja. Co z tego wynika:

• Otwarte jest rozszerzenie przeglądarki, zamknięte są moduły desktopowe. Podział jest technologiczny, nie funkcjonalny — nie ma tu okrojonej wersji darmowej,
• Do komercyjnego używania nie potrzebujesz licencji komercyjnej, także przy dołączaniu niezmodyfikowanej wersji do własnego produktu. Potrzebujesz jej przy modyfikacjach dystrybuowanych bez AGPL,
• Naucz się trzech warstw wejścia i kolejności eskalacji — strona, potem przeglądarka przez CDP, a pulpit tylko dla celów poza przeglądarką. To jest wiedza przydatna także poza tym narzędziem,
• Pisz makra jako JavaScript z API uiv.* — auto-czekanie i prawdziwe wyjątki sprawiają, że try/catch i zrzut ekranu przy błędzie są jedną linijką,
• Zaległe makra Selenium IDE migruj przez uiv-commands.md, nie przepisuj od zera,
• Model do wyszukiwania celów używaj oszczędnie — dokumentacja producenta mówi to samo i podaje powody,
• Most MCP daje Claude Code sterowanie przeglądarką, z bannerem informującym o sterowaniu i weryfikacją, czy edytor pokazuje wciąż to samo makro. Te dwa mechanizmy warto traktować jako wzorzec dla własnych integracji agentowych,
• Po dodaniu serwera MCP zamknij klienta całkowicie i otwórz ponownie — a jeśli działał w trakcie instalacji, powtórz ją,
• Prompt systemowy generowany ze źródła w kodzie to najlepsza realizacja wzorca „instrukcje dla modelu jako część projektu", jaką widzieliśmy w tej serii,
• To nie jest zamiennik Playwrighta w CI — te narzędzia się dopełniają.

Licencja: Ui.Vision RPA jest dwulicencyjny — AGPLv3 albo licencja komercyjna — a prawa należą do a9t9 software GmbH. AGPLv3 to najsilniejszy copyleft w powszechnym użyciu, ale w tym przypadku jego praktyczne skutki są węższe, niż sugeruje reputacja tej licencji, i sam plik licencyjny wykłada to wprost. Korzystanie z narzędzia, również w środowisku komercyjnym i w dowolnej skali, nie rodzi żadnych zobowiązań — AGPL nie stawia warunków używaniu programu, a makra, które w nim napiszemy, są naszymi danymi, nie dziełem pochodnym. Redystrybucja niezmodyfikowanej wersji obok własnego produktu również jest darmowa, o ile Ui.Vision pozostaje osobny i nietknięty; licencja podaje na to konkretny, przyjazny przykład komercyjny. Obowiązki pojawiają się dopiero przy modyfikowaniu rdzenia albo włączaniu jego kodu do własnego projektu: wtedy albo publikujemy całość na AGPLv3, albo kupujemy licencję komercyjną. Dla agencji budującej automatyzacje dla klientów oznacza to zielone światło bez zastrzeżeń — granica leży tam, gdzie zaczynamy sprzedawać zmieniony Ui.Vision jako część własnego, zamkniętego produktu. Osobno warto pamiętać, że XModules nie są objęte licencją open source i mają własne warunki, więc automatyzacja wychodząca poza przeglądarkę jest odrębną decyzją także licencyjną.