Czym jest obsługa komputera i dlaczego ma znaczenie? Obsługa komputera to prosta koncepcja o szerokich konsekwencjach: zamiast prosić modele o odpowiadanie na pytania, powierzamy im autonomiczną obsługę oprogramowania — poruszanie się po witrynach, wypełnianie formularzy, przechodzenie przez procesy i wykonywanie całych zadań od początku do końca.
Otwiera to drogę do automatyzacji licznych rzeczywistych zadań, które są dziś rozproszone między różnymi interfejsami, takich jak kompleksowe rezerwacje, finalizowanie zakupów internetowych, wieloetapowe planowanie podróży czy procesy administracyjne bez prostego odpowiednika w postaci API. Nie są to nowe problemy. Nowa jest możliwość rozwiązywania ich za pomocą modeli ogólnego przeznaczenia.
Najnowsze systemy Anthropic i OpenAI pokazały agentów, którzy nie tylko działają, lecz także analizują stan, naprawiają błędy i na bieżąco tworzą rozwiązania dostosowane do konkretnego zadania. Przeglądarka staje się dzięki temu uniwersalnym środowiskiem wykonawczym dla agentów, ale natychmiast pojawia się pytanie projektowe: jak dużą część tego środowiska należy udostępnić modelowi?
Pierwsze systemy odpowiadały na nie, zamykając przeglądarkę w stałym zestawie bezpiecznych, zdefiniowanych działań. Jak wykażemy w tym artykule, podejście to zbliża się do granic swoich możliwości.
Podczas tworzenia agentów przeglądarkowych pojawia się znajomy odruch: nie ufać modelowi zbyt mocno.
Opakowujemy więc przeglądarkę warstwą abstrakcji. Udostępniamy zdefiniowane narzędzia, takie jak click, type, scroll, select i read_text. Upraszczamy obiektowy model dokumentu (DOM). Ograniczamy przestrzeń działań. Próbujemy sprawić, by zachowanie było zrozumiałe i możliwe do kontrolowania za pomocą zaprojektowanych przez nas abstrakcji.
To rozsądny punkt wyjścia. Jednocześnie coraz częściej okazuje się to niewłaściwą architekturą długoterminową.
W miarę rozwoju pionierskich modeli problemem przestaje być wyłącznie brak narzędzi. Problem polega na tym, że zmuszamy model do działania za pośrednictwem abstrakcji, które ukrywają zbyt wiele elementów bazowego systemu. Sprowadzamy złożone, dynamiczne środowisko do stałego interfejsu działań, a następnie oczekujemy, że model będzie skutecznie pracował mimo tej utraty informacji.
Taki kompromis staje się coraz mniej korzystny.
Badaną przez nas zmianę łatwo opisać, ale ma ona istotne konsekwencje. Zamiast traktować agenta jako selektor zdefiniowanych działań, traktujemy go jako syntezator programów działający w ograniczonym środowisku wykonawczym.
Modele stały się naprawdę skuteczne i nie potrzebują już abstrakcyjnych zabezpieczeń — potrzebują pełnej przestrzeni działań, aby zaprojektować i wykonać zadanie, a następnie je udoskonalać aż do osiągnięcia celu.
Ten artykuł opisuje przejście od automatyzacji przeglądarki opartej na licznych abstrakcjach do ograniczonej obsługi komputera oraz zmiany wynikające z takiego sposobu projektowania systemów.
Problem nie polega na tym, że stałe interfejsy działań są z założenia błędne. Problem w tym, że internet nie chce się do nich dostosować.
Nowoczesne interfejsy powstają w technologiach React, Vue i Angular. Korzystają z asynchronicznych aktualizacji stanu, syntetycznych systemów zdarzeń oraz osadzonych widżetów innych firm, które działają w ramkach iframe z innych źródeł i mają własne cykle życia. Komponent opakowujący wydający polecenie „wpisz tekst w tym polu” działa poprawnie tylko wtedy, gdy strona podziela jego definicję wpisywania. Wiele stron jej nie podziela. Bezpośrednie ustawienie wartości często całkowicie omija mechanizm wykrywania zmian używanego frameworka. Pole wygląda na wypełnione. Walidacja się nie uruchamia. Formularz nadal nie działa.
Można to załatać. Można dodać specjalną obsługę pól React, wyzwalać zdarzenia blur po zdarzeniach focus i przed odczytem stanu czekać na ustanie ruchu sieciowego. Każda taka poprawka jest trafna w danym przypadku. Łącznie tworzą jednak system, który jest coraz trudniejszy w utrzymaniu i coraz ściślej dopasowany do wcześniej napotkanych witryn.
Głębszy problem polega na tym, że warstwa abstrakcji utrwala założenia dotyczące sposobu działania interakcji, po czym okazuje się, że internet kieruje się innymi założeniami.
Rozważmy formularz płatności Stripe lub Adyen osadzony w ramce iframe z innego źródła. Komponent opakowujący nie może uzyskać do niego bezpośredniego dostępu, ponieważ formularz pochodzi z innego źródła. Narzędzie read_text nie może odczytać jego stanu wewnętrznego. Narzędzie type nie może korzystać z jego pól. Agent oparty na komponencie opakowującym trafia tutaj na mur. Abstrakcję zaprojektowano z myślą o dokumencie głównym. Rzeczywiste zadanie znajduje się poza jej zasięgiem.
Podobne niedopasowanie występuje w mniej oczywistych procesach. Lista rozwijana kontrolowana przez framework może w ogóle nie reagować na bezpośrednie kliknięcia, ponieważ widoczny element nie jest właściwym elementem sterującym. Wywołanie bazowej zmiany stanu może wymagać sekwencji zdarzeń klawiatury. Z zewnątrz interfejs wygląda tak, jakby można było go kliknąć. Abstrakcja wydaje polecenie „kliknij”. Nic się nie dzieje.
Inny przykład to wieloetapowy proces w oknie modalnym, w którym aktualizacje widocznego drzewa DOM są opóźnione względem zmian stanu wewnętrznego. Właściwe kolejne działanie zależy od zmiany stanu, której nie odzwierciedlają jeszcze elementy widoczne dla komponentu opakowującego. Agent oparty na takim komponencie działa zbyt wcześnie lub odczytuje nieaktualny stan, ponieważ ma niepełny obraz systemu.
W każdym z tych przypadków abstrakcja ukrywa sygnały, których agent rzeczywiście potrzebuje.
Model działający na niższym poziomie — analizujący aktywne drzewo DOM i granice ramek oraz tworzący sekwencję interakcji dla danego interfejsu — potrafi poradzić sobie w takich sytuacjach. Nie oznacza to, że model jest z natury inteligentniejszy. Ma po prostu dostęp do informacji, które wcześniej usunięto.
Zmianę, do której dążymy, łatwo opisać: zamiast prosić model o wybór zdefiniowanych działań, udostępniamy mu interfejs wykonawczy niższego poziomu i ograniczamy go za pomocą zasad środowiska wykonawczego, a nie konstrukcji warstwy abstrakcji.
Ta decyzja projektowa wynika z szerszej zmiany w branży, która zaczyna preferować podstawowe narzędzia niższego poziomu. Wykorzystują one naturalną zdolność agenta do korygowania działań w czasie wykonywania i tworzenia kodu wysokiej jakości, zamiast narzucać mu sztywne, wyspecjalizowane narzędzia, które są wprawdzie niezawodne, ale odbierają modelowi możliwość dostosowania się do różnych środowisk.
Świadczy o tym sukces Claude Code, będącego podstawowym narzędziem wielu programistów, oraz szerszy zwrot branży ku agentom działającym w terminalu. Największą zaletą Claude Code nie jest sam model, lecz otoczenie operacyjne niższego poziomu. Udostępnienie modelowi mniejszej liczby bardziej modułowych narzędzi niższego poziomu — czyli terminala — poprawia skuteczność wywoływania narzędzi, głównie dlatego, że agent może analizować zadanie i tworzyć dla niego niestandardowe skrypty, zamiast korzystać z uogólnionych narzędzi zaśmiecających okno kontekstu.
W przypadku automatyzacji przeglądarki oznacza to, że model może bezpośrednio analizować bieżący stan strony, poruszać się między ramkami i tworzyć kod interakcji dostosowany do aktualnego interfejsu, zamiast odwzorowywać wszystko na stały zestaw gotowych działań.
Model działa mniej jak selektor, a bardziej jak autor kodu wykonywanego na bieżąco. Sprawdza bieżący stan, analizuje interfejs i syntetyzuje logikę interakcji odpowiednią dla konkretnej sytuacji. Potrafi tworzyć wieloetapowe sekwencje, dostosowywać się do nietypowych procesów i weryfikować wyniki przed przejściem dalej. Gdy działanie się nie powiedzie, model widzi źródłowy błąd i sam się koryguje. To rozwiązanie ma większe możliwości i wiąże się z większym ryzykiem, ale znacznie lepiej odpowiada rzeczywistej naturze problemu.
Co ważne, usunięcie warstwy abstrakcji nie oznacza, że system staje się mniej rygorystyczny. Rygor zostaje przeniesiony w inne miejsce.
Praca wykonywana wcześniej podczas projektowania komponentów opakowujących i obsługi przypadków brzegowych przenosi się do trzech obszarów: polecenia, które staje się formą szkolenia operacyjnego; środowiska wykonawczego, które egzekwuje granice, takie jak zakres nawigacji, działania wrażliwe i sposób ponawiania prób; oraz warstwy oceny, która sprawdza nie tylko powodzenie zadania, lecz także poprawność kroków pośrednich. Mniej kruchych abstrakcji. Silniejsze systemy pomocnicze.
Jednym ze skutków tej zmiany jest uproszczenie kodu produktu, mimo że cały system zyskuje większe możliwości. Zamiast zapisywać wzorce interakcji w postaci opakowujących komponentów wielokrotnego użytku, agent syntetyzuje zachowanie w czasie wykonywania. Zamiast rozbudowywać zestaw wyspecjalizowanych narzędzi i logiki obsługującej przypadki brzegowe, utrzymujesz niewielki zbiór zaawansowanych operacji podstawowych oraz ograniczone środowisko wykonawcze.
Zmienia to również sposób generalizacji systemu. Agent oparty na komponentach opakowujących dobrze generalizuje zadania podobne do tych, dla których takie komponenty już zbudowano. Agent działający w ograniczonym środowisku wykonawczym generalizuje zadania korzystające ze wspólnej warstwy wykonawczej, nawet jeśli ich widoczne interfejsy są różne.
Na przykład obsługa formularza wyszukiwania, procesu rezerwacji i strony ustawień może wyglądać zupełnie inaczej na poziomie interfejsu użytkownika. W głębi łączą je jednak wspólne wzorce: odczytywanie stanu, wyzwalanie zdarzeń, weryfikowanie wyników i obsługa asynchronicznych aktualizacji. System działający na tym poziomie łatwiej przenosi swoje możliwości między zadaniami.
Komponentem wielokrotnego użytku nie jest lista działań, lecz zdolność modelu do sprawdzania stanu, bezpiecznego działania i weryfikowania wyników.
Najważniejszy wniosek z tej pracy jest taki, że niezawodność nie wynika z udostępniania modelowi większej liczby funkcji pomocniczych. Często zapewnia ją mniejszy zestaw bardziej zaawansowanych operacji podstawowych, ograniczonych we właściwy sposób. Nadmierna pomoc utrwala założenia dotyczące sposobu wykonania zadania. Ograniczenia wyznaczają bezpieczne granice działania i pozwalają modelowi znajdować lepsze rozwiązania w danej sytuacji.
Potężniejszy interfejs wykonawczy wymaga również bardziej rygorystycznego modelu bezpieczeństwa. Gdy agent przestaje być ograniczony do niewielkiego zestawu zdefiniowanych działań, w praktyce zaczyna bezpośrednio obsługiwać rzeczywiste oprogramowanie. Natychmiast zmienia to profil ryzyka.
Projekt musi uwzględniać cztery kwestie:
Ujawnienie danych. Agent korzystający z rzeczywistych interfejsów często napotyka informacje poufne. Wymaga to konsekwentnego maskowania danych i kontroli dostępu. Dane należy ujawniać tylko wtedy, gdy jest to konieczne do wykonania zadania, a dzienniki i ślady trzeba chronić, aby mechanizmy obserwowalności nie stały się najbardziej wrażliwą częścią systemu.
Zakres działania. Zaawansowany agent nie powinien mieć pełnej swobody działania. W praktyce należy ograniczyć miejsca, do których może przechodzić, domeny, do których ma dostęp, oraz systemy, z którymi wolno mu współdziałać. Ograniczenia te powinny być egzekwowane na poziomie środowiska wykonawczego, a nie pozostawione jako konwencje w poleceniach.
Zaufanie do środowiska. Nowoczesne interfejsy mogą zawierać instrukcje, treści lub procesy, które wprowadzają w błąd albo są celowo wrogie. Wstrzykiwanie poleceń za pośrednictwem zawartości strony stanowi rzeczywisty wektor ataku. System potrzebuje jasnej hierarchii instrukcji, mechanizmów weryfikacji i warunków zakończenia, aby agent nie podążał za niezamierzonymi wskazówkami.
Spektrum autonomii. Nie wszystkie działania powinny być w pełni autonomiczne. W wielu środowiskach produkcyjnych należy traktować autonomię jako spektrum. System może działać w wysoce agentowy sposób podczas badania środowiska i wykonywania zadań, a jednocześnie wymagać zatwierdzenia określonych kategorii działań.
Podstawowa zasada jest prosta: zapewnienie modelowi większych możliwości wymaga wzmocnienia otaczającego go systemu. Autonomia bez odpowiednich zasad nie jest gotowa do zastosowań produkcyjnych.
Przestaliśmy pytać: jakie działania w przeglądarce należy udostępnić?
Zaczęliśmy pytać: jak zapewnić modelowi pełną przestrzeń działań i otoczyć ją zasadami środowiska wykonawczego, które nadal zagwarantują bezpieczeństwo?
Takie ujęcie zmienia priorytety. Taksonomie działań i kompletność komponentów opakowujących tracą na znaczeniu. Ważniejsze stają się zasady środowiska wykonawczego, obserwowalność i ocena poszczególnych kroków. Możliwości modelu i projekt systemu nie zastępują się nawzajem. Wraz z rozwojem modeli rola systemu staje się ważniejsza, a nie mniej istotna.
Agenci przeglądarkowi działający podczas prezentacji często zawdzięczają sukces wąskiemu zakresowi zadania i sprzyjającemu środowisku. Systemy produkcyjne wymagają czegoś innego: ograniczonego wykonywania, monitorowanego zachowania oraz oceny, która pozwala odróżnić poprawny wynik od szczęśliwego trafu.
Mniej projektowania komponentów opakowujących. Więcej inżynierii systemowej.
Choć skupiliśmy się na agentach przeglądarkowych, wnioski te wskazują na szersze podejście do obsługi komputera jako dziedziny inżynierii systemowej.