Dwa protokoły dominują w sterowaniu przeglądarką przez AI: CDP (Chrome DevTools Protocol) i MCP (Model Context Protocol). Rozwiązują różne problemy na różnych warstwach, ale programiści budujący agentów przeglądarkowych często je mylą albo wybierają niewłaściwy dla swojego scenariusza. Ten poradnik wyjaśnia, co robi każdy protokół, kiedy stosować który i jak współpracują w produkcyjnym stosie agenta.
TL;DR: CDP daje agentowi bezpośrednią, niskopoziomową kontrolę nad przeglądarką przez połączenie WebSocket. MCP daje LLM-owi wysokopoziomowe narzędzia przeglądarkowe przez ustandaryzowany interfejs tool-use. CDP to silnik; MCP to kierownica. Większość produkcyjnych agentów AI potrzebuje obu: MCP, żeby LLM decydował o akcjach, a CDP pod spodem, żeby przeglądarka faktycznie działała. Clawbrowser wspiera oba natywnie.
Uwaga: "CDP" w tym artykule oznacza Chrome DevTools Protocol, standard sterowania przeglądarką.
Czym właściwie są CDP i MCP
CDP: Chrome DevTools Protocol
CDP to protokół oparty na WebSocket do programowego sterowania przeglądarkami Chromium. Google stworzył go dla Chrome DevTools (inspektora, który otwierasz przez F12), ale stał się standardem automatyzacji przeglądarek. Playwright, Puppeteer i każda ważna biblioteka automatyzacji korzystają z CDP wewnętrznie.
Kiedy wywołujesz page.goto() w Playwright, wysyłasz polecenie CDP przez WebSocket do przeglądarki. CDP daje granularną kontrolę: nawigacja po stronach, wykonywanie JavaScript, przechwytywanie żądań sieciowych, manipulacja cookies i robienie zrzutów ekranu.
# CDP: your code controls the browser directly
from playwright.async_api import async_playwright
async with async_playwright() as p:
browser = await p.chromium.connect_over_cdp("http://127.0.0.1:9222")Pełne omówienie CDP znajdziesz w CDP Browser for AI Agents: A Developer Guide.
MCP: Model Context Protocol
MCP to protokół standaryzujący sposób, w jaki LLM-y łączą się z zewnętrznymi narzędziami. Zamiast pisać własne definicje function-call dla każdego narzędzia, LLM odkrywa dostępne narzędzia przez serwer MCP i wywołuje je za pomocą standardowego interfejsu.
W kontekście sterowania przeglądarką serwer MCP udostępnia akcje takie jak nawigacja, kliknięcie, wpisanie tekstu, zrzut ekranu i ekstrakcja jako narzędzia, które LLM może wywołać. LLM decyduje, które narzędzie wywołać na podstawie zadania. Bez kodu Playwright, bez selektorów CSS, bez własnych definicji narzędzi w agencie.
{
"mcpServers": {
"clawbrowser": {
"command": "clawctl",
"args": ["mcp", "serve"]Dodaj tę konfigurację do Claude Code, Cursor, Gemini CLI albo dowolnego agenta kompatybilnego z MCP. LLM natychmiast dostaje narzędzia przeglądarkowe.
Dlaczego się mylą
Oba protokoły łączą agenta AI z przeglądarką. Oba używają słowa "protocol". Oba pojawiają się w tych samych rozmowach o infrastrukturze agentów AI. Ale działają na różnych warstwach:
- CDP to protokół na poziomie przeglądarki. Rozmawia z Chromium.
- MCP to protokół na poziomie aplikacji. Rozmawia z LLM-ami.
Serwer MCP do obsługi przeglądarki używa CDP wewnętrznie do sterowania nią. To nie są alternatywy. To warstwy tego samego stosu.
Porównanie obok siebie
| CDP (Chrome DevTools Protocol) | MCP (Model Context Protocol) | |
|---|---|---|
| Stworzony przez | Google (zespół Chrome) | Anthropic |
| Typ protokołu | Sterowanie przeglądarką (WebSocket) | Użycie narzędzi (stdio/SSE) |
| Kto go wywołuje | Twój kod (Playwright, Puppeteer, surowy WebSocket) | LLM (Claude, GPT, Gemini) |
| Poziom kontroli | Niskopoziomowy: DOM, sieć, wykonywanie JavaScript, cookies | Wysokopoziomowy: nawigacja, kliknięcie, wpisanie tekstu, zrzut ekranu, ekstrakcja |
| Konfiguracja | Połączenie z portem debugowania przeglądarki | Konfiguracja serwera MCP w agencie |
| Elastyczność | Pełna: wszystko, co przeglądarka umie | Ograniczona do narzędzi udostępnianych przez serwer |
| Szybkość na akcję | Milisekundy (bez inferencji) | 0,5-3 sekundy (LLM decyduje przy każdym kroku) |
| Obsługa błędów | Twój kod obsługuje błędy | LLM wnioskuje o błędach |
| Anti-detection | Nie wbudowany (zależy od przeglądarki) | Nie wbudowany (zależy od przeglądarki) |
| Najlepszy do | Skryptowa automatyzacja, precyzyjna kontrola, budowa frameworków | Przeglądanie sterowane przez LLM, otwarte zadania, szybkie prototypowanie |
Żaden protokół nie zajmuje się anti-detection. To problem na poziomie przeglądarki, nie protokołu. Zwykła instancja Chrome podłączona przez CDP lub przez serwer MCP pozostawia te same sygnały automatyzacji. Anti-detection wymaga rozwiązania na poziomie silnika, takiego jak Clawbrowser: zarządzane fingerprints na ponad 20 powierzchniach, wbudowany proxy routing i tłumienie sygnałów CDP na poziomie źródła Chromium.
Kiedy używać CDP
Używaj CDP, gdy potrzebujesz precyzyjnej, programowej kontroli nad przeglądarką i z góry znasz dokładne kroki.
Scenariusze, w których CDP wygrywa:
- Strukturalny scraping. Wiesz, które selektory targetować, jakie dane wyciągnąć i jak obsłużyć paginację. Twój kod wykonuje te same kroki za każdym razem.
- Przechwytywanie sieci. Musisz blokować zasoby, modyfikować nagłówki żądań, przechwytywać odpowiedzi API albo wstrzyknąć JavaScript przed załadowaniem strony.
- Złożone warunki oczekiwania. Musisz czekać na konkretne elementy DOM, stan idle sieci albo zmiany zmiennych JavaScript przed wykonaniem akcji.
- Automatyzacja krytyczna pod względem wydajności. Polecenia CDP wykonują się w milisekundach. Bez opóźnienia inferencji LLM na akcję. 50-krokowe zadanie scrapingu, które przez CDP trwa sekundy, zajęłoby minuty przy wnioskowaniu LLM na każdym kroku.
- Budowa frameworków. Budujesz framework agentowy, harness testowy albo bibliotekę automatyzacji, z której będą korzystać inni.
# CDP: full control, full responsibility
await page.wait_for_selector("#login-form")
await page.fill("#email", "[email protected]")
await page.fill("#password", credentials)
await page.click("#submit")Kompromis: piszesz i utrzymujesz cały kod łączący z przeglądarką. Każdy selektor, każdy warunek oczekiwania, każdy handler błędów. Kiedy zmieni się struktura docelowej strony, kod przestaje działać.
Kiedy używać MCP
Używaj MCP, gdy LLM powinien decydować, co robić dalej na podstawie tego, co widzi na stronie.
Scenariusze, w których MCP wygrywa:
- Otwarte przeglądanie. "Znajdź stronę z cenami i wyciągnij szczegóły planów." Agent nawiguje, czyta stronę i decyduje, co kliknąć bez zakodowanych na stałe selektorów.
- Wieloetapowe workflow z oceną sytuacji. "Zaloguj się, sprawdź, czy jest nowa faktura, pobierz ją, jeśli kwota przekracza 500 $." LLM obsługuje logikę warunkową, czytając zawartość strony na każdym kroku.
- Szybkie prototypowanie. Chcesz mieć agenta przeglądarkowego w pięć minut bez pisania kodu Playwright. Dodaj konfigurację MCP, opisz zadanie, gotowe.
- Użytkownicy nietechniczni. Operator agenta opisuje zadania w języku naturalnym. Kod nie jest wymagany.
- Środowiska natywne dla agentów. Claude Code, Cursor i Gemini CLI już mówią MCP. Dodanie przeglądarki to jeden blok konfiguracji.
# MCP: the LLM decides what to do
User prompt: "Go to example.com and tell me the page title"
LLM calls: navigate(url="https://example.com")
LLM calls: screenshot()Kompromis: mniejsza precyzja. LLM może kliknąć nie ten element, wykonać dodatkowe kroki albo źle odczytać zawartość strony. Każda akcja niesie opóźnienie inferencji LLM. Przez standardowe narzędzia MCP nie da się przechwytywać żądań sieciowych ani wstrzykiwać JavaScript.
Kiedy używać obu naraz
Tak kończy większość produkcyjnych agentów AI. MCP obsługuje interfejs LLM-agent. CDP obsługuje interfejs agent-przeglądarka. Serwer MCP siedzi pomiędzy nimi i tłumaczy wysokopoziomowe wywołania narzędzi na niskopoziomowe komendy przeglądarki.
LLM ← MCP → MCP Server ← CDP → Browser
(clawctl) (Clawbrowser)LLM wysyła wywołania narzędzi MCP ("nawiguj do tego URL-a", "kliknij przycisk logowania"). Serwer MCP tłumaczy je na komendy CDP i wysyła do przeglądarki. Wyniki wracają tą samą ścieżką.
Dlaczego warstwa przeglądarki ma znaczenie
Większość serwerów MCP do obsługi przeglądarek łączy się ze zwykłą instancją Chrome przez CDP. Taka przeglądarka nie ma zarządzania fingerprintami, proxy routingu ani anti-detection. Agent działa na stronach demo, ale jest blokowany na produkcyjnych witrynach za Cloudflare, DataDome czy Akamai.
Wbudowany serwer MCP Clawbrowser łączy się z własnym silnikiem Chromium. Kiedy LLM wywołuje navigate, serwer MCP wysyła komendę CDP do przeglądarki, która ma już zarządzane fingerprints, proxy routing dopasowany geograficznie i tłumienie sygnałów CDP na poziomie silnika. Bez wtyczek stealth, bez middleware proxy, bez kodu rotacji fingerprintów.
Ścieżka MCP (sterowana przez LLM, zero kodu łączącego):
{
"mcpServers": {
"clawbrowser": {
"command": "clawctl",
"args": ["mcp", "serve"]Ścieżka CDP (skryptowa, pełna kontrola):
browser = await playwright.chromium.connect_over_cdp(
"http://127.0.0.1:9222"
)Obie ścieżki łączą się z tą samą instancją Clawbrowser z tymi samymi fingerprintami, proxy routingiem i anti-detection. Wybierz interfejs pasujący do Twojego scenariusza. Używaj obu w tym samym projekcie, gdy różne części workflow wymagają różnych poziomów kontroli.
Krok po kroku jak zbudować agenta z oboma protokołami znajdziesz w How to Build an AI Agent That Browses the Web.
Framework decyzyjny
| Pytanie | CDP | MCP |
|---|---|---|
| Znasz dokładne kroki z góry? | Tak | Użyj CDP |
| LLM ma decydować, co kliknąć? | Użyj MCP | Tak |
| Potrzebujesz przechwytywania sieci? | Tak | Niedostępne |
| Potrzebujesz szybkości poniżej sekundy na akcję? | Tak | Nie (opóźnienie LLM) |
| Budujesz dla użytkowników nietechnicznych? | Nie | Tak |
| Używasz Claude Code albo Cursor? | Dostępne | Natywna integracja |
| Chcesz zero kodu przeglądarki? | Nie | Tak |
Jeśli odpowiedziałeś "tak" na pytania po obu stronach, użyj obu: MCP do części sterowanych przez LLM, CDP do części wymagających precyzji. Clawbrowser obsługuje warstwę przeglądarki dla obu protokołów.
FAQ
Czy mogę przełączać się między CDP a MCP bez zmiany przeglądarki?
Tak, jeśli Twoja przeglądarka obsługuje oba. Clawbrowser udostępnia endpoint CDP na każdym profilu i ma wbudowany serwer MCP. Połącz Playwright z endpointem CDP do skryptowej automatyzacji i użyj serwera MCP do przeglądania sterowanego przez LLM, na tych samych profilach przeglądarki z tymi samymi fingerprintami i sesjami. Zobacz How to Connect Cursor to a Real Browser via CDP po instrukcję obu metod połączenia.
Który protokół jest szybszy?
CDP. Komendy wykonują się w milisekundach, bo nie ma inferencji LLM. MCP dodaje 0,5-3 sekundy na akcję, bo LLM musi zdecydować, które narzędzie wywołać, i zinterpretować wynik. Przy 50-krokowym zadaniu scrapingu CDP kończy w sekundach. To samo zadanie przez MCP trwa minuty. Używaj CDP do masowej automatyzacji, gdy znasz kroki. Używaj MCP do zadań wymagających oceny na każdym etapie.
A co z WebDriver BiDi?
WebDriver BiDi to standard W3C, który ma zastąpić zarówno WebDriver (używany przez Selenium), jak i części CDP protokołem niezależnym od przeglądarki. Wciąż dojrzewa. Playwright i Puppeteer nadal korzystają z CDP wewnętrznie. Gdy WebDriver BiDi osiągnie pełną adopcję, będzie konkurować z CDP na warstwie sterowania przeglądarką, nie z MCP na warstwie narzędzi. Framework decyzyjny CDP-vs-MCP z tego artykułu obowiązuje niezależnie od tego, który niskopoziomowy protokół przeglądarkowy wygra.
Czy do któregoś z protokołów potrzebuję przeglądarki anti-detect?
Tak, jeśli agent automatyzuje strony z ochroną anti-bot. Ani CDP, ani MCP nie mają wbudowanego anti-detection. To protokoły do wysyłania komend do przeglądarki. Jeśli przeglądarka ujawnia sygnały automatyzacji (navigator.webdriver, headless User-Agent, generyczny canvas hash), strona ją blokuje niezależnie od protokołu. Zobacz Browser Automation Without Getting Blocked po pełny model detekcji.
Zacznij budować
Zainstaluj Clawbrowser z clawbrowser.ai, wklejając prompt instalacyjny do swojego agenta AI.
Ścieżka MCP (sterowana przez LLM): dodaj konfigurację serwera MCP Clawbrowser do swojego agenta i zacznij przeglądać w języku naturalnym.
Ścieżka CDP (skryptowa): połącz Playwright lub Puppeteer z endpointem CDP i napisz kod automatyzacji.
Obie: używaj MCP do części, w których LLM wnioskuje o tym, co robić. Używaj CDP do części, w których potrzebujesz precyzyjnej, szybkiej i deterministycznej kontroli. Ta sama przeglądarka, te same fingerprints, te same sesje.
Pełne omówienie CDP znajdziesz w CDP Browser for AI Agents: A Developer Guide. Tutorial krok po kroku: How to Build an AI Agent That Browses the Web.
Continue exploring
Ask AI how Clawbrowser helps
Czytaj dalej
Powiązane artykuły
Jak połączyć Cursor z prawdziwą przeglądarką przez CDP
Wbudowana przeglądarka Cursor to izolowany webview. Połącz Cursor z Clawbrowser przez CDP, żeby mieć trwałe profile, zarządzany fingerprint i proxy routing.
Czytaj artykuł →
Puppeteer-Extra-Stealth jest przestarzały: czego używa nowoczesna automatyzacja
puppeteer-extra-plugin-stealth nie był aktualizowany od 2023 roku. Dlaczego nie radzi sobie z nowoczesnymi systemami Anti-Bot i co warto wybrać zamiast niego.
Czytaj artykuł →