Agent AI w przeglądarce: przycisk kliknięty to jeszcze nie zadanie wykonane

Agent zaznaczył wiersz, kliknął „Zapisz” i napisał, że zadanie wykonane. W aplikacji zmieniła się jednak druga firma o podobnej nazwie. Na nagraniu wszystko wygląda sprawnie: kursor trafia w przycisk, okno znika, pojawia się zielony komunikat. Sukces ma tylko niewłaściwego adresata.

Przy agencie obsługującym przeglądarkę trzeba odróżnić zamiar, wykonaną czynność i potwierdzony skutek. Narzędzie może poprawnie zrealizować kliknięcie, a całe zadanie nadal zakończyć się błędem. Audyt powinien więc przejść od polecenia przez właściwy obiekt do stanu widocznego w aplikacji docelowej.

Najlepiej zrobić to w kontrolowanym środowisku z fikcyjnymi rekordami. Pozwala sprawdzić podobne nazwy, opóźnione okna i niepewny wynik bez poprawiania rzeczywistych danych klientów. Film z efektownym przebiegiem jest pomocny, ale sam nie zastępuje ustalonego punktu odbioru zadania.

Co dokładnie miało zostać zmienione

Załóżmy, że agent ma uzupełnić pole w fikcyjnym rekordzie firmy. W bazie są „Studio Północ” i „Studio Północ — oddział”, a lista pokazuje nazwy w skrócie. Polecenie powinno wskazywać właściwy obiekt w sposób możliwy do sprawdzenia, na przykład identyfikatorem i nazwą. Inaczej agent oraz osoba oceniająca mogą rozwiązywać dwa różne zadania.

Przed próbą zapisz stan początkowy i oczekiwaną zmianę. Wymień pole, wartość oraz zakres: jeden rekord, wybrana grupa czy cała lista. Ustal także elementy, których zadanie nie obejmuje. Dobrze przygotowany odbiór sprawdza nie tylko obecność nowej wartości, lecz również brak niezamierzonych zmian w podobnych rekordach.

Zdefiniuj dowód wyniku. Może nim być ponowne otwarcie właściwego rekordu i odczyt zapisanego pola. W innym procesie potrzebny będzie status zgłoszenia albo widok pobranego pliku. Ważne, by dowód odpowiadał zadaniu. Zniknięcie okna edycji nie mówi jeszcze, czy aplikacja zachowała zmianę.

OpenAI w dokumentacji computer use wyjaśnia, że status completed wywołania oznacza ukończenie generowania żądania przez model; aplikacja nadal musi je wykonać. Po wykonaniu przekazuje aktualny ekran. Już ten techniczny podział pokazuje, dlaczego nazwa stanu narzędzia nie może bezpośrednio zastępować odbioru zadania użytkownika.

W odpowiedzialnym workflow agentów AI przypisz te etapy do ról i ograniczeń. Kto określa obiekt, kto wykonuje operację, kto sprawdza rezultat? Jeśli wszystko nazywa się jedynie „agent zrobił”, trudno ustalić, gdzie zabrakło informacji albo potwierdzenia.

Zmień układ, nie zmieniając zadania

Najpierw wykonaj prostą próbę na znanym widoku. Potem zachowaj to samo zadanie, lecz zmień sortowanie listy albo szerokość okna. Czy agent nadal odnajduje właściwy rekord, czy odtwarza ruch do dawnej pozycji? Zapisz, na podstawie jakiej obserwacji zdecydował się działać i co zobaczył bezpośrednio przed zmianą.

Anthropic w opisie problemów z klikaniem wskazuje między innymi różnicę skali obrazu i ekranu oraz niejednoznaczne, podobne elementy. To konkretne możliwe źródła pomyłki. Nie należy jednak każdej nieprawidłowej operacji sprowadzać do przesuniętego kursora; czasem błędnie rozpoznano sam obiekt lub cel.

W próbie umieść dwa podobne przyciski, ale unikaj zagadki stworzonej wyłącznie po to, by narzędzie przegrało. Użyj układu występującego w danej aplikacji: „Zapisz” dla szkicu i „Zapisz oraz wyślij” albo akcji dostępnych przy sąsiednich wierszach. Oczekiwany wybór powinien wynikać z polecenia i aktualnego widoku.

Przygotuj okno pojawiające się z opóźnieniem: podpowiedź, potwierdzenie albo komunikat aplikacji. Sprawdź, czy następny ruch trafia w zamierzony element, czy w nową warstwę. W zapisie zachowaj obraz przed działaniem i stan po nim. To pozwala odróżnić błędną interpretację widoku od zmiany, która zaszła już po jego odczytaniu.

Dodaj zmianę listy po przewinięciu lub odświeżeniu. Rekordy mogą zajmować inne miejsca niż w poprzedniej obserwacji. Sprawdź, czy agent wraca do aktualnego stanu przed operacją, zwłaszcza gdy poprzedni krok zajął czas. Stary zrzut ekranu jest zapisem wcześniejszej sytuacji, a nie wieczystą mapą przycisków.

Sprawdź właściwą kartę przeglądarki oraz konto. Dwa podobne widoki mogą dotyczyć innych projektów lub organizacji. Przed zmianą proces powinien rozpoznać kontekst w sposób dostępny użytkownikowi. Sam tytuł strony bywa zbyt ogólny, jeśli w obu kartach brzmi „Klienci”.

W środowisku testowym automatyzacji AI przygotuj takie rozróżnienie celowo: dwa fikcyjne projekty z jednym podobnym rekordem. Odbierz nie tylko poprawną zmianę w pierwszym, ale też niezmieniony stan drugiego. Dzięki temu dowód obejmie granicę zadania, a nie tylko znalezioną nową wartość.

Poczekaj na stan, który pozwala wybrać następny krok

Po kliknięciu aplikacja może przez chwilę przetwarzać zmianę. Sprawdź, co agent robi w tym czasie. Jeśli nie widzi odpowiedzi, czy ponawia akcję, przechodzi dalej, czy odczytuje stan? W kontrolowanej próbie dodaj opóźnienie i zobacz cały przebieg. Nie oceniaj wyłącznie najszybszej ścieżki, w której każde okno pojawia się natychmiast.

Dodaj również wynik częściowy. Pole tekstowe mogło zostać zachowane, a załącznik odrzucony. Jeżeli zadanie obejmuje oba elementy, agent powinien pokazać różne stany, zamiast wybrać jeden ogólny komunikat na podstawie pierwszego sukcesu. Zapisz, czy użytkownik może bezpiecznie dokończyć brakującą część bez ponownego wykonania tej już potwierdzonej.

Dodaj walidację formularza: jedno pole wymaga poprawki, a pozostałe dane pozostają wpisane. Sprawdź, czy agent rozpoznaje właściwy komunikat i zmienia tylko objęty nim zakres. Jeżeli zaczyna wypełniać cały formularz od początku, porównaj wartości końcowe z zatwierdzoną propozycją. Poprawienie jednego błędu nie powinno niezauważalnie zmieniać reszty zadania.

Osobno przygotuj komunikat błędu zapisu. Agent powinien odróżnić brak wyniku od potwierdzonego zakończenia. Zapisz, co pokazuje człowiekowi i jaki stan przypisuje zadaniu. „Nie udało się potwierdzić” bywa uczciwym wynikiem; nie powinno jednak w raporcie zamieniać się w „nic nie zmieniono”, jeśli stan pozostaje nieznany.

Przy operacjach o skutku zewnętrznym ustal wcześniej granicę wymaganej zgody i techniczne możliwości środowiska. Jeżeli agent korzysta również z plików lub sieci, sprawdź rzeczywiste granice jego piaskownicy, zamiast wyprowadzać je z samej nazwy środowiska. W próbie nie trzeba naprawdę wysyłać wiadomości czy zmieniać dostępów. Można sprawdzić przygotowanie działania i podgląd przy podstawionej operacji, która zapisuje propozycję. Audyt ma ujawnić zachowanie, nie tworzyć realnych skutków ubocznych.

W zatwierdzaniu działań AI przez człowieka pokaż obiekt, zmianę i zakres przed akceptacją. Jeśli zgoda dotyczy jednego rekordu, nie może po cichu objąć całej strony wyników. Sprawdź także odmowę: czy agent zatrzymuje odpowiednią czynność i czy aplikacja nie wykonuje jej inną drogą.

Przy zadaniu pobrania pliku sprawdź plik, a nie tylko naciśnięcie przycisku „Pobierz”. W kontrolowanej próbie porównaj nazwę, rodzaj materiału i zawartość z oczekiwaniem. Osobno przygotuj stan, w którym aplikacja generuje dokument później. Agent powinien rozpoznać oczekiwanie, zamiast wskazać pusty lub wcześniejszy plik jako nowy rezultat.

Jeżeli zadanie wymaga podglądu przed zapisem, oceń, co człowiek rzeczywiście widzi. Czy pokazano pełną nazwę obiektu i zmieniane pole, czy tylko przycisk zgody? Zatwierdzenie bez właściwego kontekstu może pozostawić błąd nierozpoznany, mimo że w historii procesu występuje formalny etap akceptacji.

Gdy agent dostaje treść strony lub dokumentu, ta treść nie powinna sama rozszerzać zlecenia. Przegląd granic wymaga odrębnego scenariusza z kontrolowanym materiałem. W tym odbiorze zachowaj przynajmniej rozpoznawalne źródło polecenia i ustalony zakres operacji. Nie traktuj każdego komunikatu na ekranie jak nowej zgody osoby zlecającej.

Do przeglądu w Aeneia Audit przygotuj jedno zadanie, kontrolowany widok aplikacji i definicję końcowego rezultatu. Pozwoli to sprawdzić zachowanie procesu bez opierania oceny na samej deklaracji modelu.

Powrót po przerwie jest osobnym zadaniem

Przerwij próbę po kliknięciu, zanim agent otrzyma potwierdzenie. Po wznowieniu sprawdź, czy odczytuje aktualny stan przed ponowieniem. Jeśli poprzednia operacja jednak się powiodła, powtórka może wywołać drugi skutek. Przy nieznanym wyniku potrzebna jest droga ustalenia stanu, a nie odruchowe rozpoczęcie całego zadania od nowa.

Zachowaj w zapisie identyfikator obiektu i etap, na którym przerwano pracę. Długi opis ruchów kursora nie zastępuje tych informacji. Osoba przejmująca zadanie powinna wiedzieć, co już potwierdzono, co jedynie zaproponowano i czego nie udało się odczytać. To ułatwia kontynuację także wtedy, gdy interfejs po powrocie wygląda inaczej.

Przy większej liczbie pozycji powiąż każdą odpowiedź z właściwym wejściem. Rozwija to kontrola wyników wsadowych AI. Informacja „zakończono serię” nie wyjaśnia, które rekordy mają potwierdzoną zmianę, które odrzucono, a które nadal czekają na sprawdzenie.

Jeśli częścią pracy jest przyjęcie nowego kodu lub narzędzia, zachowaj odrębną decyzję opisaną w kontroli zależności proponowanych przez AI. Agent może sprawnie obsłużyć panel, a nadal nie mieć podstaw do rozszerzenia zakresu środowiska. Techniczna możliwość kliknięcia nie ustala, czy dana operacja należy do zadania.

Dla każdego przebiegu zapisz osobno wybór obiektu, próbę operacji i potwierdzenie skutku. Jeśli błąd pojawia się już przy wyborze, poprawka powinna dotyczyć rozpoznania lub polecenia. Jeśli właściwy rekord wybrano, lecz zapis nie został odebrany, potrzeba innej zmiany. Jeden ogólny wynik zadania pomaga raportować, ale nie zastępuje diagnozy etapu.

Porównaj też nakład osoby sprawdzającej. Jeżeli po każdej czynności musi samodzielnie otworzyć wszystkie podobne rekordy, rozwiązanie przesunęło znaczną część pracy na odbiór. Zapisz ten koszt wraz z zakresem potwierdzenia. Dzięki temu decyzja o dalszym użyciu uwzględnia cały proces, a nie tylko czas widoczny na nagraniu kursora.

Na potrzeby przekazania wyniku przygotuj krótki zapis dla człowieka: obiekt, zmiana, potwierdzenie i nierozstrzygnięte elementy. Poproś osobę nieobserwującą próby o wskazanie następnego kroku. Jeśli nie potrafi ustalić, czy trzeba ponowić operację, czy tylko odczytać stan, podsumowanie wymaga poprawy. To odrębny problem użyteczności procesu, nawet gdy wszystkie wcześniejsze kliknięcia dało się odtworzyć.

W końcowej decyzji ogranicz dopuszczenie do sprawdzonych zadań i warunków. Jeśli oceniono jeden typ formularza, zapisz ten zakres oraz moment ponownego przeglądu po zmianie aplikacji. Dzięki temu zespół wie, kiedy może korzystać z ustalonej drogi, a kiedy potrzebna jest nowa próba.

Po poprawce powtórz przypadek, który ujawnił problem, oraz kilka sąsiednich wariantów. Jeżeli naprawiono rozpoznanie właściwego wiersza, sprawdź inne sortowanie i podobną nazwę. Zapisz, co potwierdziła próba. Jedno udane nagranie nie powinno zamieniać się w obietnicę działania przy dowolnej zmianie aplikacji.

Dobry odbiór kończy się zdaniem możliwym do sprawdzenia: w tym rekordzie zapisano tę wartość, pozostałe objęte kontrolą rekordy zachowały stan, a dowód znajduje się w tym miejscu. Agent może wtedy powiedzieć „wykonane” z przydatnym wyjaśnieniem. Zielony komunikat na ekranie nadal jest miły, ale ma już właściwego adresata.