Computer use: agenci AI, którzy klikają w interfejs — stan 2026 i 4 zastosowania, które dają efekt 

Computer use to podejście, w którym model językowy obsługuje program tak, jak robi to człowiek: dostaje zrzut ekranu, przesuwa kursor, klika, pisze i patrzy na efekt. W 2026 roku działa na tyle dobrze, że ma już realne zastosowania w firmach, ale na tyle słabo, że liczby w materiałach producentów trzeba czytać z ostrożnością. Poniżej rozłóż to na cztery zastosowania, które dały efekt w praktyce, pokażę ile kosztuje pojedyncze zadanie i wskażę miejsca, w których lepiej nie wchodzić. Bez tabeli „computer use vs wszystko", bo takich tabeli w internecie jest dużo i niczego nie wnoszą.

Czym naprawdę jest computer use

Model nie ma dostępu do Twojego systemu. Dostaje obraz tego, co widzi użytkownik, i zwraca decyzję: kliknij tutaj, wpisz to, przewiń o tyle. Twoja aplikacja wykonuje tę decyzję na prawdziwym pulpicie i odsyła modelowi kolejny zrzut. Anthropic opisuje to dosłownie - model patrzy na zrzut widoczny dla użytkownika, a potem liczy, o ile pikseli w pionie i poziomie trzeba przesunąć kursor, żeby trafić w właściwe miejsce. Liczenie pikseli to umiejętność trenowana osobno: bez niej model nie potrafi sensownie wydać poleceń myszy.

Zwróć uwagę na jedną rzecz: to nie jest dostęp do interfejsu przez API. Nie ma tu żadnego odczytu bazy, żadnego zapytania do bazy danych. Model operuje na pikselach i na tym, co one dla niego znaczą. Jak ujmuje to jeden z materiałów porównawczych - strona została wyrenderowana dla oczu, nie dla parsera, więc to piksele, a nie HTML, są tym, na czym opiera decyzję model i człowiek przed nim. To jedno zdanie tłumaczy całą różnicę w koszcie i w niezawodności.

Model dostaje 17 narzędzi w jednym zestawie: zrzut ekranu, powiększenie fragmentu, kliknięcia (lewe, prawe, środkowe, podwójne, potrójne, przeciągnięcie), ruch myszy, przyciski, kursor, przewijanie, pisanie, klawisze, przytrzymanie klawisza i pauza. Zwykle planuje kilka akcji naraz i kończy serię zrzutem ekranu, żeby zobaczyć efekt, zanim zdecyduje o kolejnych krokach. Pętlę, w której model prosi o akcję, a Twoja aplikacja zwraca wynik, dokumentacja nazywa agent loop i w przykładach ogranicza ją do 10 iteracji. Ten limit jest w kodzie po to, żeby pętla nie wpadła w nieskończoność i nie wygenerowała rachunku, którego się nie spodziewasz.

Stan 2026 w liczbach - i dlaczego te liczby rozjeżdżają się

Pierwsza liczba, która zaskakuje: w dniu premiery, w październiku 2024 roku, Claude 3.5 Sonnet obsługiwał 14,9% zadań w OSWorld - benchmarku, w którym model musi wykonać realne zadania na pulpicie z Ubuntu, Windows i macOS, a wynik sprawdzają 134 funkcje wykonawcze oglądające stan środowiska po przebiegu. Dla porównania: człowiek w tym benchmarku osiąga 70-75%, a najlepszy konkurencyjny model w tej samej chwytali 7,7%.

Dwa lata później skala jest inna. Tabela premierowa Anthropic z lipca 2026 podaje dla OSWorld 2.0 wyniki 70,6 dla Opus 5, 66,1 dla Fable 5 i 62,6 dla GPT-5.6 Sol. Wygląda na przełom. Nie jest.

Publiczny leaderboard projektu OSWorld prowadzony niezależnie pokazuje dla tego samego Opus 4.8 wynik 20,6% przy metryce binarnej i 54,8% przy częściowym credit, podczas gdy tabela producenta podaje dla niego 55,7. To różnica 35,1 punktu, czyli około 2,7 raza. Porównanie najlepszej liczby z tabeli (70,6) z sufitem publicznego leaderboardu (20,6%) daje około 3,4 raza. Jeśli budujesz na tym prognozę, planuj według dolnej liczby.

Warto dodać, że OSWorld 2.0 to w ogóle inny benchmark niż OSWorld-Verified, a nie aktualizacja tego samego: 108 długich przepływów na 31 hostowanych samodzielnie witrynach, średnio 27,25 punktów kontrolnych na zadanie. Dla tego samego GPT-5.5, który na OSWorld-Verified ma 75%, na OSWorld 2.0 wypada około 13-14%. To nie sprzeczność - to dwa różne testy mierzące różne rzeczy. Narracja „model przekroczył poziom człowieka" dotyczy wyłącznie pierwszego z nich.

Jest jeszcze jeden wynik, który mówi więcej niż wszystkie tabele. Na OSWorld 2.0 wynik mocno spada wraz z czasem zadania wykonywanym przez człowieka: przy zadaniach poniżej 45 minut modele osiągają 20-24%, przy 137-163 minutach poniżej 10%, a powyżej około 163 minut spada do zera. Zero, nie „nisko". Autorzy benchmarku tłumaczą to obserwacją, że modele gubią ograniczenia podane na początku, przepuszczają informacje pojawiające się w połowie, zgadują zamiast pytać i pomijają weryfikację. Praktyczny wniosek: im dłuższy łańcuch decyzji, tym mniej wiarygodny wynik.

Jest też efekt, o którym mówi się rzadziej, a zmienia sposób myślenia o wyborze modelu. Ten sam Claude Fable 5 na Terminal-Bench 2.1 daje 83,8% w otoczce Claude Code i 80,4% w Terminus 2, czyli różnica 3,4 punktu. Dla Opus 4.7 jest to 2,8 punktu, dla Gemini 3.1 Pro 0,2 punktu. W pierwszym przypadku ten skok jest większy niż 0,7-punktowa odległość między pierwszym a drugim miejscem w tabeli. Wybór rusztowania potrafi mieć większe znaczenie niż wybór między dwoma modelami czołowymi.

Koszt: gdzie zarabia na tym dostawca tokenów

Tu nie da się podać jednej stawki za zadanie, bo liczby w źródłach dotyczą różnych rzeczy. Podaję elementy, z których składa się rachunek, i zostawiam Ci decyzję, czy złożyć z nich własny rachunek.

Pierwszy koszt stały: deklaracja zestawu narzędzi dodaje około 4500 tokenów wejścia do każdego zapytania (około 4520 na Fable 5, Mythos 5, Opus 5 i Opus 4.8, około 4590 na Sonnet 5). Wyłączenie powiększania obrazu zdejmuje z tego około 410 tokenów. W starszych wersjach narzędzia było to około 735 tokenów na definicję plus 466-499 tokenów narzutu w prompcie systemowym.

Drugi koszt, rosnący: każdy zrzut ekranu w kontekście to około 1000-1800 tokenów wejścia. Pętla agentowa akumuluje je szybko, dlatego dokumentacja sugeruje trzymanie trzech ostatnich zrzutów i przycinanie historii co 25 tur.

Przykładowy cennik, na którym możesz oprzeć własną kalkulację, pochodzi ze strony Claude Opus 5.5: 4 USD za milion tokenów wejścia, 20 USD za milion wyjścia, 0,20 USD za milion odczytów z cache. Odczyt z cache jest tu ważny, bo przy długich pętlach stanowi istotną część kosztu, a dokumentacja zwraca uwagę na pułapkę: przycinanie zrzutów po jednym w każdej turze zmienia prefiks i unieważnia cache. Przycinaj partiami.

Skala kosztu pojedynczego przebiegu jest łatwa do złudzenia. Jeden opublikowany przebieg na Terminal-Bench 2.1 kosztował 552,67 USD przy wyniku 83,8%, a drugi 2059,19 USD przy 83,1%. Różnica w dokładności to 0,7 punktu, różnica w koszcie 1506,52 USD. To nie jest porównanie z zadaniem w panelu klienta, tylko skala, o której warto pamiętać przy zadaniach długich. Jednocześnie dla krótkich interakcji przewodnik kosztowy cytuje przeciwny sygnał: 30-krokowa interakcja, która kiedyś kosztowała dolary, ma poniżej dolara, z drogą do groszy. Traktuj obie liczby jako kierunkowe, nie jako cennik.

Jest jedno porównanie, które warto zapamiętać, bo dotyczy decyzji projektowej: pętla wizyjna płaci za zrzut ekranu na każdym kroku i może kosztować dziesiątki razy więcej niż wywołanie narzędzia zwracającego JSON, jeśli to samo zadanie da się wykonać przez API. Dla właściciela procesu, który dziś ma API, to nie jest porównanie kosztów, tylko porównanie kategorii.

Cztery zastosowania, które dają efekt

Testy interfejsu i wykrywanie zmian po wdrożeniu

To zastosowanie, w którym agent działa bez konta produkcyjnego i bez realnych transakcji, więc ryzyko jest najmniejsze, a wynik najłatwiej zmierzyć. Agent wykonuje scenariusz w interfejsie, robi zrzut po każdym kroku i oznacza to, co się zmieniło. Nie porównujesz wyglądu strony z wzorcem, tylko z tym, co agent faktycznie zobaczył. Każdy przypadek testowy, który dziś wykonujesz ręcznie przed premierą, jest kandydatem na taki przebieg.

Konfiguracja jest tu prosta, bo wszystko dzieje się w kontenerze. Standardowa konfiguracja ekranu to 1280x720, dla aplikacji webowych 1280x800 albo 1366x768, dla zadań desktopowych 1024x768 albo 1280x720. Powyżej 1920x1080 dokumentacja odradza, bo pojawiają się problemy z wydajnością. To dobrze wpada w testy regresji wizualnej, gdzie liczy się powtarzalność.

Systemy, do których nie ma API

Drugie zastosowanie jest odwrotnością pierwszego i daje największy efekt tam, gdzie innych opcji nie ma. ERP z lat dziewięćdziesiątych, portal zakupowy instytucji publicznej, wewnętrzne narzędzie z administracją, która ma tylko interfejs i hasło - wszystko takie da się obsłużyć przez interfejs, bez pisania integracji i bez proszenia dostawcy o API. Opis wdrożenia mówi o tym wprost: systemy ERP, portale zakupowe, systemy ewidencji medycznej o ograniczonym API i wewnętrzne narzędzia pisane w latach 1999-2000 można zautomatyzować przez agentów bez modyfikowania tych systemów i bez prac rozwojowych po stronie API.

Tutaj warto znać granicę. Agent widzi dokładnie to, co widzi człowiek zalogowany w przeglądarce, więc każde zabezpieczenie, które blokuje automatyzację, blokuje też jego. Weryfikacja dwuetapowa oparta o SMS albo połączenie głosowe nie jest obsługiwana, a to wyłącza całą klasę portali, które wymagają kodu z telefonu. Także zaawansowane systemy wykrywające boty potrafią zablokować przepływ, więc przed jakimikolwiek zobowiązaniami produkcyjnymi potrzebny jest test na konkretnym portalu, a nie na podobnym podobnym.

Monitoring portali i zgodności procesów

Trzecie zastosowanie to zadania, w których agent sam chodzi po stronach i zbiera dane, ale niczego nie zmienia. Przeglądanie portali dostawców, baz regulacyjnych i stron konkurencji w celu wyciągnięcia i uporządkowania informacji, pobieranie stanów zamówień, sprawdzanie, czy cennik się zmienił, czy regulamin się zaktualizował. Nie ma tu klikania w „wyślij" ani „potwierdź", więc human-in-the-loop sprowadza się do przeglądu wyniku, a nie do zatwierdzania każdego kroku.

Takie zadania dobrze się sklejają z resztą Twojej automatyzacji. Jeśli wyniki i tak mają wylądować w arkuszu albo w rekordzie, warto to zrobić przez zautomatyzowany przebieg raportowy, a agent zostaje wyłącznie na etapie zbierania, gdzie jego wkład jest najbardziej mierzalny.

Weryfikacja transakcji tam, gdzie nie ma API do odczytu

Czwarte zastosowanie brzmi najdokładniej, bo chodzi o potwierdzenie, że coś się faktycznie stało, zamiast założenia, że się stało. Dodanie pozycji do koszyka i obserwacja, czy suma faktycznie spadła. Odczytanie ekranu potwierdzenia rezerwacji, zamiast czekania na webhook, o którym nie wiadomo, czy istnieje. Wypełnienie formularza i spojrzenie na stan sukcesu, zamiast ufania, że zdarzenie kliknięcia wystartowało.

Tu jest pułapka, o której trzeba powiedzieć wprost, bo brzmi kontrintuicyjnie: nie weryfikuj działania tym samym kanałem, który je wykonał, jeśli masz wybór. Jeśli formularz wypełnił kod, sprawdź wynik wzrokiem. Jeśli stan zmienił kliknięcie, odczytaj to, co jest na ekranie. Powód jest praktyczny: model obserwujący ekran to ten sam mechanizm, który mógł popełnić błąd, a potwierdzanie jego własnego błędu niczego nie wnosi.

Istnieje wersja hybrydowa tej strategii, która jest szybsza od czystej wizji: agent generuje kod wypełniający kilka pól naraz, a potem patrzy na wyrenderowane piksele, żeby sprawdzić, czy strona faktycznie się zmieniła. Kod dla szybkości, obraz dla dowodu. Przy procesach powtarzanych setki razy w miesiącu ta hybryda wygrywa z czystym computer use o wiele kosztowniej w tokenach.

Pułapki, na które wejdziesz przy pierwszym wdrożeniu

Wersja narzędzia to pułapka, która zatrzymuje najwięcej osób. Dokumentacja Anthropic wymaga zestawu oznaczonego computer_toolset_20260801, bez nagłówka beta, a modele Claude 5.5 i nowsze obsługują computer use wyłącznie przez ten zestaw - wcześniejsza wersja zwraca błąd. Tymczasem instrukcja Browserless wciąż używa starszej kombinacji z nagłówkiem beta i innym modelem, a zmiana wersji po stronie dostawcy i po stronie narzędzia idzie równolegle. Mieszanie ich kończy się błędem zapytania. Jeśli kopiujesz przykład z bloga z 2025 roku, sprawdź najpierw, z jakiej wersji pochodzi.

Prompt injection przez obraz to realne zagrożenie, nie akademicki przykład. Instrukcja na stronie albo widoczna na zrzucie może nadpisać Twoje polecenie. Anthropic dlatego przepuszcza to, co narzędzia zwracają, przez klasyfikatory wykrywające potencjalne wstrzyknięcie, a model jest kierowany do sprawdzenia, czy instrukcja rzeczywiście pochodzi od Ciebie, zanim na niej oprze swoje działanie. Ta warstwa działa, ale dokumentacja ostrzega, że używanie computer use w aplikacjach wymagających logowania podnosi ryzyko złych skutków. Kluczowe jest zdanie o naturze tego zagrożenia: model widzi ekran tak jak Ty, więc wroga treść widzi dokładnie tak samo dobrze jak Twoje polecenie.

Skończę technicznym detalem, który oszczędza godziny. Współrzędne, które model zwraca, są w przestrzeni pikseli pełnego zrzutu ekranu, nigdy względem powiększonego obrazu. Jeśli skalujesz zrzut przed wysłaniem, musisz z powrotem przeskalować współrzędne, zanim wykonasz kliknięcie. Na monitorach Retina w macOS zrzut powstaje w dwukrotnej rozdzielczości, więc albo zmniejszasz obraz dwa razy, albo dzielisz współrzędne. Błąd w tym miejscu wygląda na „agent klika obok przycisku", a źródło jest zupełnie inne niż myślisz.

Od czego zacząć, jeśli chcesz to sprawdzić u siebie

Reguła, która oszczędza najwięcej pieniędzy, jest krótka: jeśli istnieje stabilne API, wywołaj API. Nie rób zrzutu ekranu strony, do której masz już JSON. Computer use ma sens tam, gdzie API nie ma, a warstwa pokrycia. Jeśli interfejs jest stabilny, a zadanie wykonuje się tysiące razy w miesiącu na niezmienionym ekranie, klasyczne RPA będzie tańsze i bardziej przewidywalne. Zespoły RPA i tak wydają 30-70% swojego czasu na utrzymanie botów zamiast na budowanie nowych, ale przy niezmiennym interfejsie to wciąż lepszy zakład.

Jeśli zdecydujesz się spróbować, kolejność jest taka. Zacznij od jednego zadania, które nie rusza pieniędzy i nie zmienia danych: test interfeisu albo odczyt stanu. Uruchom je w kontenerze, z kontami bez dostępu do produkcji. Zmierz dwa razy to, co dla Ciebie liczy się najbardziej - czas wykonania i liczbę ręcznych poprawek - zanim rozszerzysz zakres. Trzymaj limit iteracji i zapisuj każdą akcję, bo bez dziennika nie odbudujesz przyczyny, gdy agent zacznie się mylić w trzecim zadaniu z rzędu.

Reszta to kwestia wyboru, którego nie da się zrobić bez Twojego procesu. Które z tych czterech zastosowań najbardziej zjada Ci dziś godziny? Napisz do mnie - odpowiadam zwykle tego samego dnia. Przy pierwszej rozmowie zwykle wystarcza jedno spotkanie, żeby zamknąć temat jednego konkretnego procesu i policzyć, ile godzin w tygodniu odzyskasz. Zero zakładania konta, zakres i wycena zawsze na piśmie.