Narzędzia RPA open source warte rozważenia i miejsca, w których można je uruchomić

Kilka narzędzi z typowej krótkiej listy RPA open source nie może działać na serwerze Linux bez środowiska graficznego. Automatyzują interfejsy aplikacji desktopowych i wymagają sesji graficznej, podczas gdy taki serwer nie ma sesji pulpitu, którą mogłyby kontrolować. Ta jedna cecha dzieli kategorię na dwie części i rozstrzyga, gdzie może działać Twój bot.

Komercyjne licencjonowanie RPA jest powodem większości poszukiwań najlepszych narzędzi RPA open source. Ponownie sprawdziłem poniższe informacje o licencjach, aktywności i pakietach 5 października 2026 r., a każde stwierdzenie dotyczące statusu odsyła do dokumentacji, z której pochodzi.

Najważniejsze wnioski

• Zacznij od wymagań dotyczących sesji, a nie od listy funkcji. Oculix, OpenRPA i taskt stawiają na GUI i wymagają sesji graficznej do lokalnej pracy na pulpicie. RPA Framework nie potrzebuje jej do pracy z przeglądarką, plikami i danymi. W TagUI i UI.Vision zależy to od używanego trybu.
• RPA Framework publikował wydania w lutym, marcu, maju, czerwcu, sierpniu i październiku 2026 r., co stanowi najbardziej regularną historię wydań zweryfikowaną w tym artykule.
• TagUI ma licencję Apache-2.0 i nadal przyjmuje wkład społeczności, ale AI Singapore zaprzestało jego utrzymania i wsparcia. Jego wrapper dla Pythona nie miał nowego wydania od lipca 2023 r.
• Automagica i OpenBots nie powinny znaleźć się na aktualnej krótkiej liście. Automagica przestała być dostępna na AGPL3, gdy Netcall przejął firmę w październiku 2020 r., a OpenBots nie ma utrzymywanego publicznego repozytorium produktu RPA.
• Jeśli łączone systemy udostępniają już API lub webhooki, potrzebujesz automatyzacji przepływów pracy, a nie RPA. Inna kategoria, inne narzędzia, znacznie krótszy czas tworzenia.

Czego ten artykuł nie obejmuje

Trzy powiązane zagadnienia pozostają poza zakresem, każde z własnego powodu.

• Platformy komercyjne z bezpłatnymi wariantami. UiPath Community Edition i bezpłatny plan Power Automate wymagają innej decyzji niż ta omawiana tutaj.
• Instalacja i konfiguracja. Żaden z poniższych fragmentów nie jest instrukcją konfiguracji i przy żadnym narzędziu nie podajemy polecenia do uruchomienia w terminalu.
• Agenci AI obsługujący komputer. Jedno z narzędzi na liście oferuje integrację z takim agentem i poświęcamy jej jedno zdanie, a nie porównanie.

Narzędzia RPA open source, które są nadal utrzymywane

Sześć poniższych projektów spełnia przyjęte tutaj kryterium: faktycznie otwarte oprogramowanie RPA z publiczną aktywnością od połowy 2025 r. Bezpłatne narzędzia RPA, które przestano utrzymywać, nadal są bezpłatne, więc największej uwagi wymaga poniżej kolumna z datą, nie z licencją. Pozostałe kolumny wskazują, co każde narzędzie automatyzuje i czego wymaga od maszyny, na której działa.

rpaframework to zbiór bibliotek, a nie aplikacja. Piszesz w Pythonie lub Robot Framework i importujesz potrzebne elementy, co oznacza trudniejszy start niż nagranie makra, ale znacznie łatwiejsze utrzymanie. Repozytorium opisuje go jako zoptymalizowany pod Control Room, komercyjny produkt do orkiestracji, który Robocorp zbudowało wokół niego. Członek zespołu Sema4.ai w wątku r/rpa opisuje Robocorp jako część Sema4.ai i jasno wyznacza granicę. Biblioteka ma licencję Apache-2.0, platforma nie. Własność się zmieniła, granica nie. Leżący u podstaw Robot Framework również ma licencję Apache-2.0 i nie jest osobną pozycją na krótkiej liście.

Rozszerzenie przeglądarki UI.Vision jest otwartym rdzeniem. Automatyzacja pulpitu to osobny plik do pobrania, lokalna aplikacja o nazwie XModules, która zapewnia rozszerzeniu rozpoznawanie obrazu i tekstu, aby mogło klikać elementy poza przeglądarką. Licencja jest podwójna (AGPLv3 lub umowa komercyjna). Jeśli modyfikujesz otwarty rdzeń i nie chcesz przestrzegać wymogów AGPLv3 dotyczących udostępniania źródeł, alternatywą jest licencja komercyjna.

taskt jest kłopotliwą pozycją. Jego gałąź deweloperska otrzymała commit w lipcu 2025 r., a ostatnie wydanie z tagiem, v3.5.0.0, ukazało się w maju 2020 r. Commity i wydania są różnymi sygnałami, a tak długi okres bez wersjonowanego buildu nie oznacza, że istniejący build przestał działać.

SikuliX potrzebuje własnego przypisu, ponieważ nazwa faktycznie stała się określeniem starszej linii. Pierwotne repozytorium zostało zarchiwizowane w marcu 2026 r., a kopia oculix-org kieruje obecnych użytkowników do Oculix, aktywnej kontynuacji na licencji MIT. To Oculix jest więc projektem, który należy teraz uwzględnić na krótkiej liście; SikuliX1 przydaje się jako kontekst pochodzenia i zgodności, a nie jako utrzymywana pozycja.

Dwie pozycje ciągle pojawiają się na krótkich listach, choć nie powinny. Własny README Automagica ogłasza, że Netcall przejął firmę 13 października 2020 r. i że robot nie jest już dostępny na AGPL3, podczas gdy publiczna organizacja OpenBots na GitHubie zawiera repozytorium strony statycznej i bibliotekę emulacji terminala, ale nie rdzeń RPA.

Zależne od GUI czy bez interfejsu graficznego: podział, który decyduje o serwerze

Narzędzie RPA open source wymaga sesji pulpitu, gdy przepływ pracy zależy od automatyzacji desktopowego interfejsu użytkownika. Automatyzacja API, plików i danych może działać bez interfejsu graficznego, a automatyzacja przeglądarki również, gdy przeglądarka działa w trybie headless. Narzędzia rozpoznawania obrazu dodatkowo potrzebują pikseli do analizy, ale automatyzacja pulpitu nadal może wymagać sesji graficznej nawet wtedy, gdy identyfikuje kontrolki za pomocą selektorów zamiast obrazów.

Sesja pulpitu to zalogowane środowisko graficzne, które użytkownik otrzymuje po zalogowaniu: ekran, menedżer okien, wskaźnik myszy ze współrzędnymi. Headless oznacza przeciwieństwo, czyli maszynę działającą bez podłączonego wyświetlacza. Większość wynajmowanych serwerów Linux domyślnie działa bez interfejsu graficznego.

Podział wynika z tego, od czego zależy automatyzacja. Oculix, tak jak wcześniej SikuliX, wykorzystuje widzenie komputerowe do odnalezienia przycisku przez porównanie zapisanego obrazu z pikselami widocznymi obecnie na ekranie, dlatego potrzebuje graficznej powierzchni do analizy. Przeglądarka sterowana przez API automatyzacji może działać w trybie headless bez ekranu pulpitu. Automatyzacja pulpitu oparta na selektorach jest jeszcze czymś innym: może rozpoznawać kontrolki zamiast pikseli, ale nadal wymagać graficznego środowiska pulpitu. Przy RPA open source na serwerze praktyczne pytanie brzmi, czy przepływ pracy wymaga sesji graficznej.

TagUI i UI.Vision znajdują się po obu stronach, a strona zależy od używanego trybu. Własna dokumentacja referencyjna TagUI podaje, że opcja -headless uruchamia przepływ z niewidoczną przeglądarką Chrome i nie działa przy automatyzacji wizualnej. Praca UI.Vision w przeglądarce odbywa się wewnątrz rozszerzenia, a praca na pulpicie przez XModules, które rozpoznaje obrazy na ekranie i dlatego potrzebuje ekranu, na którym może je rozpoznawać.

Wirtualny wyświetlacz częściowo niweluje tę różnicę. Xvfb to standardowy sposób zapewnienia maszynie Linux bez ekranu wyświetlacza w pamięci, na którym programy graficzne mogą rysować bez niczyjego nadzoru, dzięki czemu automatyzacja oparta na interakcji z ekranem jest możliwa na serwerze bez monitora. Nie sprawi to, że narzędzie wyłącznie dla Windows zacznie działać na Linuxie, i dodaje kolejną warstwę, która musi działać o trzeciej nad ranem.

Licencja i data commitu mówią, czy narzędzie będzie dostępne w przyszłym roku. Wymóg dotyczący sesji mówi, czy w ogóle możesz je uruchomić.

Gdzie działa każde z nich

Bot działający przez interakcję z ekranem potrzebuje sesji graficznej, którą może kontrolować, niezależnie od tego, czy jest to rzeczywisty pulpit, sesja zdalna czy wirtualny wyświetlacz. Bot działający w trybie headless jej nie potrzebuje. Obie rzeczy brzmią banalnie, dopóki bot nie musi wystartować o 3 nad ranem, gdy nikogo nie ma przy klawiaturze.

Samodzielnie hostowane RPA ma jeden wymóg operacyjny, który obowiązuje niezależnie od wyboru narzędzia: maszyna musi być we właściwym stanie w chwili uruchomienia harmonogramu. W Windows stan ten jest konkretny, a Microsoft precyzyjnie dokumentuje go dla własnego produktu. Wytyczne Microsoftu dotyczące nienadzorowanych przepływów desktopowych Power Automate mówią, że produkt tworzy na maszynie docelowej sesję pulpitu zdalnego do uruchomienia przepływu, że połączenie z sesją konsoli maszyny nie jest dostępne przy uruchomieniach bez nadzoru i że urządzenie z Windows 10 lub Windows 11 nie może uruchomić takiego przepływu, jeśli istnieje sesja użytkownika, nawet zablokowana. Na Windows Server zablokowana sesja otwarta przez tego samego użytkownika co połączenie zamiast tego powoduje błąd.

To implementacja jednego dostawcy, a nie zasada Windows, i stanowi użyteczną mapę trybów awarii, ponieważ każdy bot działający przez interakcję z ekranem musi rozwiązać ten sam problem. Coś musi zarządzać sesją interaktywną, a Twój własny zalogowany pulpit zwykle staje na drodze. W Linuxie odpowiedni problem jest mniejszy, ale nie znika: zadanie, które przetrwa zamknięcie sesji SSH, potrzebuje harmonogramu i menedżera usług, a nie pozostawionego otwartego terminala.

Windows Server obsługuje sesje inaczej niż edycje desktopowe. Jego rola RD Session Host uruchamia pulpity oparte na sesjach na jednej maszynie dla efektywnej obsługi wielu sesji, dzięki czemu sesja bota i Twoja własna mogą współistnieć. Jeśli używasz RD Session Host do pracy wielosesyjnej, każdy łączący się użytkownik lub urządzenie potrzebuje RDS CAL. To koszt, który należy uwzględnić wcześnie, a nie szczegół odkrywany za późno.

Dobór zasobów nie jest wymagający. Nie przydzieliłbym więcej niż 1 vCPU i 2 GB RAM botowi, który przeklikuje formularz i zapisuje plik. Wszystkiemu, co steruje pełną przeglądarką, przydzieliłbym 2 vCPU i 4 GB lub więcej, szczególnie przy kilku kartach, ponieważ to Chrome jest kosztowną częścią tego obciążenia, a nie działające nad nim narzędzie automatyzacji.

Stary komputer w szafie spełnia ten wymóg. Musi pozostać włączony, zalogowany i nie może być laptopem, który zamykasz na noc. Wynajęty serwer usuwa tę klasę problemów, ponieważ może działać niezależnie od Twojego laptopa i nie konkuruje o sesję pulpitu, w której pracujesz.

Jeśli wynajęcie maszyny jest lepsze niż utrzymywanie własnej, ten podział dość jasno przekłada się na dwa produkty. Windows VPS z obrazem Desktop lub Server zapewnia botowi działającemu przez interakcję z ekranem dedykowane środowisko Windows, a Linux VPS obsługuje stronę bez interfejsu graficznego. Oba działają niezależnie od tego, czy Twój laptop jest otwarty.

Które wybrać

Jeśli zadanie dotyczy przeglądarki lub plików i umiesz pisać w Pythonie, wyborem jest RPA Framework, a reszta tej sekcji opisuje przypadki brzegowe. Odpowiedź zmienia się, gdy zadanie dotyczy aplikacji desktopowej bez API, ponieważ wtedy potrzebujesz narzędzia, które potrafi współpracować z graficznym pulpitem, a krótka lista staje się krótsza i starsza.

Do pracy z przeglądarką, plikami i danymi na serwerze Linux wybierz RPA Framework. Działa bez interfejsu graficznego, trafia na maszynę bez ekranu bez dodatkowych mechanizmów i wydał nową wersję jeszcze w październiku 2026 r. Ceną jest pisanie w Pythonie lub Robot Framework zamiast nagrywania makra, co kosztuje pierwszego dnia i zwraca się za każdym razem, gdy zmienia się aplikacja docelowa.

Do starszej aplikacji Windows bez API, gdy chcesz automatyzacji wizualnej zamiast pisania całej bazy kodu automatyzacji, wybierz UI.Vision, ale z zastrzeżeniem. W tym roku otrzymuje commity, co nie dotyczy każdej z tutejszych opcji obsługujących pulpit, a część AGPLv3 jego podwójnej licencji nakłada obowiązki udostępniania źródeł, jeśli modyfikujesz i rozpowszechniasz otwarte oprogramowanie. Drugim wyborem jest taskt. Jego gałąź deweloperska żyje, ostatnie wydanie z tagiem ukazało się w maju 2020 r. i to tę różnicę między projektem przyjmującym commity a projektem publikującym wersje trzeba rozważyć.

Do wieloplatformowej automatyzacji wizualnej wszystkiego, co pojawia się na ekranie, wybierz Oculix, aktywną kontynuację SikuliX. Nadal stawia na obrazy, a nie selektory, ale projekt ma teraz IDE i aktywne wydania zamiast być tylko zbiorem podstawowych mechanizmów dopasowywania obrazów. Używaj go, gdy celem są piksele, a nie DOM czy drzewo dostępności, i traktuj zarchiwizowane repozytorium SikuliX1 jako starszą linię, a nie utrzymywany produkt.

TagUI wciąż jest polecane nie bez powodu. Jego język skryptowy przypomina zwykły angielski, a krzywa uczenia jest najłagodniejsza spośród sześciu narzędzi. Przeciwwaga jest zapisana w jego własnym README, które stwierdza, że AI Singapore zaprzestało utrzymania i wsparcia TagUI, podczas gdy projekt jest kontynuowany przez współtwórców open source i społeczność. To nie jest porzucenie. Współtwórcy nadal wprowadzają poprawki do domyślnej gałęzi, a repozytorium nie jest zarchiwizowane. Nie oznacza to jednak także rozpędu, a wrapper rpa dla Pythona na PyPI jest o lata za historią commitów. Wybierz TagUI do zadania, które możesz pozwolić sobie zamrozić, a nie do platformy, którą planujesz rozwijać przez trzy lata.

OpenRPA jest trudniejszym wyborem. Ma rzeczywiste funkcje orkiestracji na MPL-2.0, ale zarówno jego ostatni commit kodu, jak i najnowsze wydanie z tagiem pochodzą z czerwca 2025 r., a jedyną aktywnością w repozytorium od tego czasu są automatycznie tworzone gałęzie z aktualizacjami zależności. To nie jest porzucenie, bo nic nie zostało zarchiwizowane, ale też nic nie zostało wydane. Rozważ tę różnicę w kontekście tego, jak długo boty muszą działać.

Kiedy dedykowane narzędzie RPA jest złą odpowiedzią

Najmocniejszy argument przeciwko wszystkiemu powyżej pochodził od kogoś, kto wykonuje tę pracę. W wątku r/selfhosted rozpoczętym przez operatora próbującego uwolnić się od komercyjnej umowy RPA jedna z odpowiedzi zamiast tego proponuje Pythona z frameworkiem automatyzacji, takim jak Selenium. Więcej wysiłku przy tworzeniu, mniej awarii po zbudowaniu i niższy bieżący koszt posiadania niż w oprogramowaniu RPA używanym przez tego komentującego. Inny komentujący w tym samym wątku niezależnie się z tym zgadza.

Kryterium jest utrzymanie. Jeśli zadanie ma działać przez lata, wolumen jest duży, a Ty lub ktoś w zespole potraficie utrzymać małą bazę kodu, napisz kod. Selenium i Playwright kosztują więcej pierwszego dnia i mniej czterechsetnego, ponieważ napisany przez Ciebie skrypt psuje się w sposób, który potrafisz odczytać. Jeśli horyzont zadania to miesiące lub nikt w zespole nie pisze kodu, krótsza droga narzędzia RPA do działającego bota jest warta jego podatności na awarie.

Wynik nagrywania działań starzeje się najgorzej. Skrypt wygenerowany przez obserwowanie Twoich kliknięć jest związany z układem, w którym został nagrany, więc przebudowana strona lub przesunięty przycisk psuje go w sposób, którego komunikat błędu rzadko wyjaśnia. Sceptycyzm wobec tej kategorii bywa głębszy: jeden komentujący w wątku r/rpa o opcjach open source nazywa RPA przepakowanym skryptowaniem sprzedawanym nietechnicznym menedżerom i dla dostatecznie wąskiego zadania nie jest to niesprawiedliwy opis.

Warto też wcześnie wychwycić pomylenie kategorii. Jeśli łączone systemy udostępniają API lub webhooki, w ogóle nie potrzebujesz RPA. RPA steruje interfejsem użytkownika, ponieważ nie ma innego wejścia, podczas gdy automatyzacja przepływów pracy korzysta bezpośrednio z tego wejścia, co pozwala szybciej stworzyć rozwiązanie i znacznie zmniejsza jego podatność na awarie. To inny zestaw narzędzi z własną krzywą kosztów, a licencja n8n i koszt samodzielnego hostingu to pierwsza kwestia do rozstrzygnięcia. n8n, Node-RED, Apache Airflow, Kestra i Dagu są aplikacjami instalowanymi jednym kliknięciem na naszym marketplace, jeśli chcesz uruchomić którąś już dziś.

Aktualna strona UI.Vision reklamuje integrację Anthropic Computer Use, więc kategoria już wchłania agentów, którzy sterują ekranem, rozumując o jego zawartości zamiast dopasowywać zapisane obrazy.

Często zadawane pytania