Połączenie N narzędzi z M modelami wymagało wcześniej N×M warstw integracyjnych. MCP rozdziela stronę narzędzi od strony modeli, dzięki czemu każda z nich implementuje protokół tylko raz. Artykuł omawia ten wybór projektowy, abstrakcję środowisk i działań w przeglądarce oraz problemy, których protokół nadal nie rozwiązuje.
Gdy Agent ma rzeczywiście wykonać zadanie, zwykle kończy w przeglądarce: loguje się, publikuje, zbiera dane albo wypełnia formularze. Technicznie trudne nie jest samo klikanie, lecz koszt integracji potrzebny do przekazania przeglądarki Agentowi.
Pułapka integracji N×M
Załóżmy, że na rynku jest N narzędzi i M modeli. Dostawca narzędzia musi napisać osobną integrację dla każdego modelu, a strona modelu potrzebuje warstwy adaptacyjnej dla każdego narzędzia. Obie strony utrzymują własne implementacje, co daje łącznie N×M wariantów.
Problem polega na mnożeniu. Dodanie jednego narzędzia nie oznacza jednej dodatkowej pracy, lecz konieczność połączenia tego narzędzia z każdym modelem. Z kolei po zmianie wersji modelu narzędzia już podłączone mogą wymagać ponownej weryfikacji. Funkcja może być świetna, ale bez adaptera dla konkretnego modelu nie da się jej tam użyć — narzędzie zatrzymuje się na etapie dystrybucji.
Na początku każdy musiał tworzyć własne rozwiązanie. Te same czynności — wylistowanie środowisk, uruchomienie przeglądarki, odczyt strony — trzeba było przepisywać dla kolejnego wywołującego, a logika często się różniła: jedni umieszczali oczekiwanie po stronie klienta, inni po stronie serwera.
Protokół rozdziela obie strony
MCP (Model Context Protocol) został publicznie udostępniony pod koniec 2024 roku. Jego podejście polega na ustandaryzowaniu wykrywania i wywoływania narzędzi: protokół określa, co jest udostępniane, jak opisuje się parametry i jaką strukturę ma odpowiedź.
Architektura staje się wtedy następująca: Agent łączy się z MCP Client, a Client zgodnie z protokołem łączy się z wieloma MCP Server, za którymi znajdują się konkretne możliwości. Liczba implementacji spada z N×M do N+M: strona modelu implementuje klienta raz, a strona narzędzia serwer raz.
Są tylko trzy role. Host to aplikacja uruchamiająca model i odpowiedzialna za start klienta. Client to implementacja klienta protokołu, zwykle jedna na każdy Server. Server jest tworzony przez dostawcę narzędzia i udostępnia możliwości w postaci standaryzowanych narzędzi.
Obecnie są dwa tryby komunikacji. Tryb lokalny korzysta ze standardowego wejścia i wyjścia, a klient i serwer działają na tej samej maszynie; ścieżka jest krótka i wymaga niewielkiej konfiguracji, dlatego często stosuje się go w automatyzacji. Tryb zdalny używa HTTP lub WebSocket i nadaje się do wdrożeń rozproszonych, ale wymaga dodatkowego przemyślenia uwierzytelniania i granic sieci.
W przeglądarce ujawniane są trzy warstwy
Po podłączeniu środowiska przeglądarki do protokołu udostępniane możliwości można z grubsza podzielić na trzy warstwy.
Najwyżej znajduje się środowisko: lista środowisk konta, utworzenie nowego według konfiguracji, uruchomienie wskazanego środowiska, przypisanie wyjścia sieciowego i zamknięcie po użyciu. Wcześniej działania te były rozproszone po API różnych dostawców; teraz stają się narzędziami, które model może wykrywać i wywoływać. Po uruchomieniu zwykle zwracany jest endpoint debugowania, na przykład port lub adres WebSocket, który można przekazać sterownikom takim jak Selenium czy Puppeteer.
Warstwa środkowa to strona: otwarcie adresu, odczyt DOM lub drzewa dostępności, przełączanie kart i wykonywanie zrzutów ekranu.
Najniższa warstwa to działania: klikanie, wpisywanie, przewijanie, czekanie na spełnienie warunku oraz obsługa wyskakujących okien.
Kluczowa zmiana nie polega na liczbie działań. Środowisko przestaje być kodem, który trzeba samemu napisać, a staje się zasobem, który Agent może sam wybrać i wykorzystać. Wystarczy jasno określić cel; Agent może zdecydować, czy utworzyć nowe środowisko, czy użyć istniejącego, oraz w jakiej kolejności wywoływać narzędzia. Widać to szczególnie przy wielu środowiskach działających równolegle: harmonogram trafia do promptu zamiast być na sztywno zapisany w skrypcie.
Co pozostaje nierozwiązane
Protokół rozwiązuje problem połączenia, a nie poprawności. Nadal istnieje kilka łatwych do przeoczenia kwestii.
Jakość opisów narzędzi decyduje o wyniku wywołań. Jeśli parametry są błędne albo wybrano niewłaściwe narzędzie, protokół tego nie naprawi. Wraz ze wzrostem liczby narzędzi ich opisy zajmują też kontekst, więc trzeba znaleźć równowagę między liczbą a granularnością. Zbyt ogólne narzędzia utrudniają modelowi ocenę, ile zadań obsługują; zbyt drobne szybko wypełniają kontekst.
Uprawnienia i audyt są nadal na wczesnym etapie. Wiele Server działa lokalnie na pojedynczej maszynie, startuje ze znacznymi uprawnieniami i nie zapewnia precyzyjnej autoryzacji ani pełnych rejestrów wywołań. W trybie zdalnym najpierw trzeba ustalić, kto może się łączyć i co może zobaczyć.
Niestabilność stron również nie znika. Nieodnalezione elementy, nieprzewidywalny czas ładowania, wygasłe sesje logowania i CAPTCHA wciąż wymagają oczekiwania, ponownych prób i logiki awaryjnej. Protokół ujednolica tylko punkt wejścia.
Dojrzałość ekosystemu także jest nierówna. Różne Server nie obsługują dokładnie tych samych typów zasobów, struktur odpowiedzi ani kodów błędów. Gdy zadanie łączy kilka Server, logikę orkiestracji często nadal trzeba napisać samodzielnie. Sam protokół również się rozwija, dlatego należy zwracać uwagę na różnice zachowania między wersjami.
Trzeba też zachować inną granicę: protokół określa, jak model wywołuje narzędzia, ale nie rozstrzyga, czy samo zadanie jest zgodne z zasadami. To, czy zbieranie danych jest autoryzowane, czy konto jest używane w uzasadnionym celu i czy nie narusza się reguł platformy, wymaga osobnej oceny i nie zależy od płynności połączenia.
W scenariuszach z wieloma środowiskami izolacja między nimi oraz spójna konfiguracja wyjścia sieciowego, strefy czasowej i języka często wpływają na wynik bardziej niż sposób integracji. Na warstwie izolacji środowisk PurpleMark udostępnia interfejsy tworzenia, uruchamiania i konfiguracji sieci, które mogą być wywoływane przez narzędzia AI i koordynowane przez jednego klienta.
Ten materiał służy wyłącznie do objaśnienia zasad technicznych. Korzystaj z odpowiednich protokołów i narzędzi zgodnie z obowiązującym prawem i zasadami.
