Co zmienia się w przepływie pracy, gdy operacje przeglądarki przejmuje MCP, i które fragmenty znikają z kodu? Ten praktyczny opis pokazuje podział odpowiedzialności, cztery częste problemy konfiguracyjne oraz kolejność ich diagnozowania.
Przy tworzeniu automatyzacji przeglądarki w Claude Code najszybciej zaczyna męczyć kod klejący: uruchamianie przeglądarki, podpinanie proxy, tworzenie środowisk i czekanie na uchwyty. Nie ma to wiele wspólnego z logiką biznesową, a mimo to trzeba pisać te elementy w kółko. Gdy operacje przeglądarki zostaną przekazane przez MCP, większość tego kodu znika. Opisujesz, co trzeba zrobić, a model sam wybiera narzędzie do wywołania.
Jak podzielić odpowiedzialności
Claude Code to asystent programistyczny działający w wierszu poleceń. Potrafi czytać i zapisywać pliki, uruchamiać polecenia oraz pracować z Git. Jego mocną stroną jest kod i terminal. Bezpośrednia obsługa przeglądarki nie jest jego domeną i nie powinna nią być.
MCP uzupełnia właśnie ten brak. Opakowuje możliwości środowiska automatyzacji przeglądarki w zestaw narzędzi, które po rejestracji model może wywoływać: listowanie i tworzenie środowisk, uruchamianie i zatrzymywanie przeglądarki, wykonywanie zrzutów ekranu oraz odczyt zawartości strony. Jedna strona zajmuje się kodem i logami, druga przeglądarką i stronami. Jasny podział ułatwia też znalezienie źródła problemu.
Jak zmienia się przepływ pracy
Najbardziej widoczna zmiana to szybkość zbudowania całego łańcucha. Wcześniej każda zmiana procesu wymagała edycji skryptu. Teraz można najpierw spróbować w języku naturalnym: wyświetlić dostępne środowiska, zalogować się w dwóch z nich, zrobić zrzuty ekranu i zebrać wyniki. Gdy przepływ działa, dopiero wtedy utrwala się go w skrypcie.
W praktycznych projektach zwykle współpracują trzy warstwy. MCP obsługuje polecenia w języku naturalnym, więc dobrze nadaje się do eksploracji i zadań tymczasowych. Lokalny interfejs HTTP obsługuje operacje masowe, na przykład utworzenie kilkudziesięciu środowisk naraz, i łatwo poddaje się ponowieniom. Precyzyjne interakcje, takie jak oczekiwanie na określony stan lub pobieranie ze strony danych strukturalnych, można realizować przez CDP połączone z przeglądarką. Te trzy podejścia nie konkurują ze sobą, tylko odpowiadają za różne części przepływu.
Osobne zarządzanie warstwą środowisk było kolejnym wnioskiem z tego etapu. Gdy środowiska są porozrzucane po różnych skryptach, diagnozowanie problemów staje się trudne wraz ze wzrostem liczby zadań. Teraz środowiska są centralnie tworzone, przeglądane i grupowo zwalniane za pomocą narzędzi warstwy środowiskowej, a skrypt dostaje tylko identyfikator środowiska do użycia. W scenariuszach z wieloma kontami rozwiązanie izolacyjne takie jak PurpleMark obsługuje właśnie tę warstwę: rozdziela środowisko, sesję i pamięć podręczną każdego konta, aby warstwa wykonawcza mogła je poprawnie planować.
Cztery miejsca, w których łatwo utknąć
Pierwszy problem to nierozpoznane narzędzie. Większość klientów wczytuje konfigurację tylko przy uruchomieniu, więc po rejestracji narzędzia konieczny jest restart. Częsty jest też błędny path do pliku konfiguracyjnego, ponieważ różne narzędzia przechowują go w różnych miejscach. Prosty test działa zaskakująco dobrze: uruchom usługę ręcznie. Jeśli startuje, problem prawdopodobnie dotyczy konfiguracji; jeśli nie, środowiska.
Drugi problem to nieudane uwierzytelnianie. Najczęściej przyczyną jest skopiowanie danych dostępowych z dodatkową spacją lub znakiem nowej linii. Najpierw sprawdź to, a potem sposób odczytu zmiennych środowiskowych. Wynik może się różnić zależnie od systemu operacyjnego i sposobu uruchamiania.
Trzeci problem to niedziałający lokalny interfejs API. Wiele usług MCP zależy od tego, czy uruchomiona jest sama aplikacja kliencka. Gdy klient jest zamknięty, usługa może nie wystartować albo połączenie może zakończyć się timeoutem. Warto też sprawdzić zajętość portu; pozostawiony proces może nadal go blokować. Numer portu można potwierdzić w ustawieniach klienta.
Czwarty problem to wzajemne zakłócanie się zadań równoległych. Pojedyncze zadanie działa poprawnie, ale po uruchomieniu kilku naraz dane zaczynają się mieszać albo sesje logowania się nadpisują. Zwykle przyczyną jest współdzielenie tego samego środowiska przez wiele zadań. Nie rozwiąże tego samo debugowanie; potrzebna jest reguła: jedno środowisko na zadanie, a tworzenie i zwalnianie środowisk przez interfejs wsadowy, nie doraźnie w skrypcie.
Kilka nawyków przy debugowaniu
Warunki oczekiwania warto zapisywać w poleceniach wprost. „Kliknij przycisk Wyślij” zawiera za mało informacji. „Poczekaj, aż przycisk Wyślij będzie aktywny, a potem kliknij” działa wyraźnie lepiej. Model może decydować, co zrobić, ale moment oczekiwania trzeba określić.
Testowanie łańcucha zacznij od zadań tylko do odczytu. Listowanie środowisk, wykonywanie zrzutów ekranu i odczyt tekstu strony nie mają skutków ubocznych, a jednocześnie sprawdzają uwierzytelnianie, sieć i usługę. Jeśli łańcuch nie działa, nie warto od razu uruchamiać operacji ze skutkami ubocznymi.
Nie zapisuj danych dostępowych w kodzie. Używaj zmiennych środowiskowych lub lokalnych plików konfiguracyjnych i dodaj te pliki do listy ignorowanych; po zmianach w zespole rotuj dane dostępowe. Jeśli lokalny interfejs API ma wyłączoną własną walidację, co najmniej upewnij się, że nasłuchuje tylko na komputerze lokalnym i nie jest dostępny z zewnątrz.
Na końcu warto pamiętać o granicy: MCP łączy techniczny łańcuch, ale nie zmienia zasad platformy. Nawet przy bardzo płynnej integracji zadanie nadal musi przestrzegać wszystkich właściwych warunków korzystania z usługi.
