Automatyzacja powtarzalnych przepływów pracy w przeglądarce za pomocą interfejsu wiersza poleceń Narzędzi deweloperskich w Chrome

Narzędzia deweloperskie w Chrome dla agentów zawierają interfejs wiersza poleceń (CLI), który umożliwia agentowi kodującemu lub Tobie uruchamianie narzędzi deweloperskich jako standardowych poleceń powłoki. Zamiast dynamicznie wywoływać narzędzia przez serwer MCP, agent zapisuje te same działania jako polecenia powłoki i może je połączyć w skrypt, który można uruchomić ponownie w dowolnym momencie. Agent może na przykład wygenerować taki skrypt:

chrome-devtools new_page "https://example.com"
chrome-devtools take_snapshot 1
chrome-devtools fill 1 "1_4" "hello"

Zarówno serwer MCP, jak i interfejs wiersza poleceń łączą się z tym samym silnikiem: trwałym demonem działającym w tle, który komunikuje się z Chrome za pomocą protokołu narzędzi deweloperskich w Chrome (CDP). Różnica polega na tym, jak agent dociera do tego silnika:

  • Serwer MCP: agent łączy się przez standardowy strumień wejścia/wyjścia za pomocą JSON-RPC i traktuje każde narzędzie przeglądarki jako interaktywne wywołanie funkcji.
  • Interfejs wiersza poleceń: agent wykonuje polecenia powłoki bezpośrednio w tym samym demonie działającym w tle.

Za pomocą interfejsu wiersza poleceń możesz wykonywać te czynności:

  • Utrwalanie przepływu pracy: przekształć działania podjęte przez agenta podczas sesji debugowania eksploracyjnego w skrypt wielokrotnego użytku.
  • Odtwarzanie stanu aplikacji: uruchom ponownie skrypt, aby przywrócić przeglądarkę do znanego stanu przed ponownym debugowaniem.
  • Działania zbiorcze: uruchamiaj sekwencję poleceń nawigacji, wprowadzania danych, emulacji i kontroli bez tury rozmowy między poszczególnymi krokami.
  • Uruchamianie skryptów bez agenta AI: wygenerowane skrypty możesz uruchamiać z dowolnego terminala, podpowłoki lub kontenera CI, który może wykonywać skrypty powłoki, bez konieczności aktywnej sesji LLM lub klienta MCP.

Wybór między interfejsem wiersza poleceń a serwerem MCP

Wybór między interfejsem wiersza poleceń a serwerem MCP to decyzja inżynieryjna dotycząca kosztów, kontekstu i przepływu pracy.

  • Koszt okna kontekstu: gdy rejestrujesz serwer MCP, każda definicja narzędzia i schemat JSON są wstrzykiwane do promptu systemowego LLM w każdej rozmowie. Dzięki umiejętności CLI agent wczytuje tylko kompaktowe podsumowanie w formacie Markdown i płaci za tokeny, gdy zdecyduje się przeczytać pełną umiejętność i utworzyć potrzebne polecenia. W przypadku długich sesji agenta z wieloma turami ta różnica wpływa zarówno na koszty, jak i opóźnienia.
  • Eksploracja a wykonywanie: narzędzia MCP doskonale sprawdzają się w dynamicznym, eksploracyjnym debugowaniu, gdy ani Ty, ani Twój agent nie wiecie jeszcze, co należy sprawdzić. Ponieważ agent zna wszystkie dostępne narzędzia, jest bardziej prawdopodobne, że użyje ich do osiągnięcia celu. Jeśli ścieżka jest już znana, interfejs wiersza poleceń umożliwia uruchomienie tylko tych kroków, których potrzebujesz.
  • Możliwość ponownego wykorzystania: skrypt CLI można zapisać, użyć go ponownie w umiejętności lub uruchomić ręcznie poza pętlą agenta. Nie możesz tego zrobić za pomocą wywołań narzędzia MCP.
Używaj serwera MCP, gdy Użyj interfejsu wiersza poleceń, gdy:
Analizujesz nieznany problem i potrzebujesz pełnego zestawu narzędzi. Znasz już kroki i chcesz je powtórzyć w niezawodny sposób.
Chcesz rozwiązywać problemy na żywo i dynamicznie oraz przeprowadzać szczegółową analizę przeglądarki. Potrzebujesz umiejętności agenta, które efektywnie wykorzystują tokeny, lub automatyzacji opartej na terminalu.
Agent działa w IDE lub kliencie z obsługą MCP. Twoje środowisko nie obsługuje klientów MCP.

Podczas korzystania z interfejsu wiersza poleceń pamiętaj o tych kwestiach:

  • Zakres narzędzi: interfejs wiersza poleceń obsługuje większość narzędzi deweloperskich w Chrome dla agentów do automatyzacji opartej na powłoce. Pełną listę poleceń znajdziesz w dokumentacji umiejętności interfejsu wiersza poleceń.
  • Niejawne uruchamianie: serwer działający w tle uruchamia się automatycznie przy pierwszym użyciu. Nie musisz uruchamiać polecenia start, status ani stop przed każdym poleceniem.
  • Stan trwały: stan przeglądarki jest zachowywany między poleceniami, więc strona otwarta w jednym poleceniu jest nadal dostępna w następnym, jeśli nie zostanie wyraźnie zamknięta.
  • Identyfikatory stron i identyfikatory UID elementów: większość poleceń przyjmuje identyfikator strony jako pierwszy argument. Uruchom chrome-devtools list_pages, aby go znaleźć, i chrome-devtools take_snapshot, aby uzyskać identyfikatory UID elementów, z którymi chcesz wejść w interakcję.
  • Format danych wyjściowych: domyślnie dane wyjściowe są zwykłym tekstem w formacie Markdown. Jeśli chcesz wykorzystać wyniki w innych skryptach lub potokach CI, przekaż --output-format=json.
  • Dostęp do plików: domyślnie interfejs wiersza poleceń ma pełny dostęp do systemu plików w przypadku parametrów zapisywania plików i upload_file. Przekaż --allowUnrestrictedPaths=false, aby ograniczyć dostęp do plików do katalogu tymczasowego systemu operacyjnego.
  • Lighthouse w trybie ciągłej integracji: możesz uruchomić lighthouse_audit z interfejsu wiersza poleceń, ale samodzielny interfejs wiersza poleceń Lighthouse i jego akcje GitHub są lżejsze, jeśli potrzebujesz tylko wyników Lighthouse w trybie ciągłej integracji.
  • Prostsza abstrakcja niż skrypty automatyzacji przeglądarki: w przeciwieństwie do pisania pełnych skryptów Puppeteer lub Playwright w języku JavaScript lub TypeScript interfejs wiersza poleceń Narzędzi deweloperskich udostępnia ograniczony, wysoce ukierunkowany interfejs API. Ta składnia powłoki jest łatwiejsza do odczytania i utrzymania przez człowieka, a także znacznie łatwiejsza do niezawodnego wygenerowania bez halucynacji nawet przez modele niższej klasy.

Wymagania wstępne

Zanim zaczniesz korzystać z interfejsu wiersza poleceń, upewnij się, że masz:

  • Zainstalowane Narzędzia deweloperskie w Chrome dla agentów: postępuj zgodnie z przewodnikiem dla początkujących. Wtyczki i rozszerzenia przeznaczone dla agentów (np. rozszerzenie interfejsu wiersza poleceń Gemini) obejmują umiejętności agentowe oraz serwer MCP.
  • Interfejs wiersza poleceń dostępny w powłoce: instalacja jest jednorazowa i nie jest częścią regularnego przepływu pracy agenta. Zapoznaj się z dokumentacją instalacji.
  • Umiejętność chrome-devtools-cli (instalowana z Narzędziami deweloperskimi w Chrome dla agentów): ta umiejętność uczy agenta, jak pisać skrypty powłoki lub uruchamiać polecenia powłoki za pomocą interfejsu wiersza poleceń.

Struktura polecenia

Polecenia są zgodne ze wzorcem chrome-devtools <tool> [arguments] [flags]. Wymagane argumenty są pozycyjne, a opcjonalne używają flag. Aby uzyskać szczegółowe informacje, użyj --help z dowolnym poleceniem.

Na przykład:

chrome-devtools new_page "https://example.com"      # Open a page
chrome-devtools list_pages                          # Find the page ID
chrome-devtools take_snapshot 1                     # Get element UIDs for page 1
chrome-devtools fill 1 "1_4" "hello"                # Fill an input
chrome-devtools click 1 "1_7" --includeSnapshot true
chrome-devtools list_console_messages 1 --types error
chrome-devtools take_screenshot 1 --filePath "result.png"

Przypadki użycia interfejsu wiersza poleceń Narzędzi deweloperskich w Chrome

Poinstruuj agenta, aby zapisał kroki, które już wykonał, jako skrypt, zamiast ponownie rozwiązywać ten sam proces w przeglądarce podczas każdej sesji.

Zapisywanie sesji debugowania jako skryptu wielokrotnego użytku

Po sesji debugowania eksploracyjnego w MCP często nie można zagwarantować, że ten sam problem nie pojawi się ponownie. Zamiast ponownie wyjaśniać kroki reprodukcji następnym razem, poproś agenta o zapisanie wykonanego właśnie przepływu.

Przykładowy prompt:

Please write a chrome-devtools CLI script for this user flow, and save it as test.sh.

Przykładowe działanie agenta: agent sprawdza kroki nawigacji, wprowadzania danych i kontroli, które wykonał podczas sesji, i przekształca je w sekwencję poleceń chrome-devtools, np. new_page, take_snapshot, fill, click i list_console_messages. Skrypt zostanie zapisany jako test.sh. Gdy następnym razem będziesz debugować ten obszar, możesz wskazać agentowi skrypt, aby ponownie osiągnąć ten sam stan, lub uruchomić go poza pętlą agenta, aby debugować ręcznie.

Odtwarzanie stanu aplikacji przed analizą

Złożone stany, takie jak wieloetapowy proces płatności czy filtrowany panel, są kosztowne dla agenta, który musi je odtwarzać w rozmowie za każdym razem. Użyj zapisanego skryptu jako punktu wyjścia do nowego dochodzenia.

Przykładowy prompt:

Run ./scripts/checkout-flow.sh to get the browser into the payment step, then check why the "Pay now" button stays disabled after I select Google Pay.

Przykładowe wykonanie agenta: agent uruchamia skrypt, który przechodzi do kasy, wypełnia formularz adresu i wybiera opcję dostawy. Ponieważ stan przeglądarki jest zachowywany między poleceniami, agent używa następnie poleceń take_snapshot i evaluate_script na tej samej stronie, aby sprawdzić stan przycisku i moduły obsługi zdarzeń dołączone do selektora płatności.

Grupowe kontrole wizualne w różnych widocznych obszarach

Weryfikowanie zmian układu na ekranach o różnych rozmiarach jest powtarzalne i zwykle wykonywane ręcznie. Poproś pracownika obsługi klienta o skrypt, który stosuje ustawienia emulacji i rejestruje dowody dla każdego z nich w jednym uruchomieniu.

Przykładowy prompt:

Write a chrome-devtools CLI script that opens http://localhost:3000/pricing, captures a full-page screenshot at 375x667, 768x1024, and 1920x1080, and saves them to ./screenshots with the viewport size in the filename.

Przykładowe wykonanie agenta: agent zapisuje pętlę, która wywołuje chrome-devtools emulate 1 --viewport "<size>", a następnie chrome-devtools take_screenshot 1 --fullPage true --filePath "./screenshots/pricing-<size>.png" dla każdego widocznego obszaru. Możesz ponownie uruchomić skrypt po każdej zmianie usługi porównywania cen bez otwierania rozmowy.

Test dymny procesu, w którym nie jest dostępny żaden klient MCP

Niektóre środowiska, takie jak kontenery CI lub zablokowane konfiguracje firmowe, nie obsługują klientów MCP. Praktycznie każdy terminal, podpowłoka, kontener CI i platforma agenta obsługują uruchamianie standardowych skryptów powłoki i odczytywanie stdout, dzięki czemu interfejs wiersza poleceń nadaje się do przeprowadzania lekkich kontroli w tych miejscach.

Przykładowy prompt:

Create a shell script that opens the sign-up page on the staging URL passed as the first argument, submits the form with test data, and exits with a non-zero code if any console errors are logged. Use --output-format=json so the script can parse the result.

Przykładowe wykonanie agenta: agent pisze skrypt, który używa new_page, take_snapshot, fill i click, a następnie wywołuje list_console_messages 1 --types error --output-format=json i analizuje dane wyjściowe JSON, aby określić kod wyjścia.

Pakowanie przepływu pracy jako lekkiej umiejętności

Jeśli przepływ jest przydatny w różnych projektach lub dla różnych członków zespołu, agent może opakować skrypt w umiejętność. To jest umiejętność CLI Narzędzi deweloperskich: lekki plik referencyjny, który umożliwia agentowi uruchamianie określonych poleceń przeglądarki bez konieczności ponoszenia kosztów tokenów za wszystkie narzędzia.

Przykładowy prompt:

Turn ./scripts/checkout-flow.sh into a skill named "reproduce-checkout" with a short description of when to use it, so I can invoke it in future sessions.

Przykładowe działanie agenta: agent tworzy SKILL.md z nazwą, jednowierszowym opisem sytuacji, w których umiejętność ma zastosowanie, oraz instrukcjami odwołującymi się do skryptu. W późniejszych sesjach agent odczytuje pełną umiejętność tylko wtedy, gdy zadanie pasuje do jej opisu.

Dalsze kroki