Dołącz do wersji próbnej WebMCP Origin

Gdy Chrome 149 zacznie udostępniać wersję próbną WebMCP Origin, relacja między stroną internetową a serwerem proxy stanie się bardziej bezpośrednia: strona nie tylko przedstawia DOM i widoczną kopię do odgadnięcia przez maszynę, ale sama kontrola może również zadeklarować cel, stan i granice pliku wykonywalnego. Ta zmiana wygląda na próbę API, ale w rzeczywistości bardziej przypomina przeniesienie „zamiaru interfejsu” z ukrytych informacji na jawny protokół.

Wartość czegoś takiego jak WebMCP nie polega na dodawaniu warstwy terminologii do strony internetowej, ale na zwiększeniu niepewności, której agenci boją się najbardziej. Niezależnie od tego, czy przycisk służy do przesyłania, przełączania, potwierdzania, czy po prostu otwierania wyskakującej warstwy; czy pole wprowadzania jest datą, wyszukiwanym hasłem lub godziną spotkania wymagającą specjalnego formatu. W przeszłości informacje te wyciągano głównie z tekstu, struktury i kontekstu. Wnioskowanie działa, ale gdy strona staje się złożona, agent zaczyna mylić „wygląda” z „jest”.

Dla ludzi takie błędne odczytanie jest zwykle po prostu błędnym kliknięciem. W przypadku agentów błędne odczyty zamieniają się w ciągłą ścieżkę błędów. Będzie kontynuował wykonywanie według błędnego zrozumienia, dopóki nie napotka weryfikacji, wycofania lub skutków ubocznych, które ujawnią, że poprzedni krok poszedł na manowce. Gdy WebMCP wyraźnie wyjaśni tę warstwę semantyki, agent nie musi odgadnąć strony jako mapy czysto wizualnej, a strona internetowa może również jasno wyjaśnić obowiązki kluczowych powierzchni interakcji.

Sprawa ta najlepiej sprawdza się w przypadku interfejsów, które trudno wytłumaczyć copywritingiem w czystym formacie HTML, takich jak kalendarze, rezerwacje, wnioski o pozwolenia, panele ustawień czy też zbiór stron, które wyglądają jak zwykłe pola wejściowe, ale w rzeczywistości mają inne znaczenie biznesowe. Opierając się wyłącznie na etykiecie i symbolu zastępczym, agent często musi krążyć po stronie i próbować raz po raz; gdy strona będzie mogła zadeklarować „tu jest wybór daty”, „tutaj jest akcja potwierdzająca” i „status tutaj może się zmienić tylko w tym kierunku”, koszt integracji zostanie bezpośrednio obniżony.

Jednak proces dotyczący pochodzenia podnosi także inny problem: należy zachować tę warstwę semantyki. Struktura strony ulegnie zmianie, zmieni się kopia przycisku i zmieni się status firmy. Jeśli warstwa intencji, na której naprawdę polega agent, nie zostanie zaktualizowana wraz z komponentami, wkrótce nastąpi dryf. W tym czasie najniebezpieczniejszy stan nie jest „całkowicie bezużyteczny”, ale „można nadal biegać, ale czasami popełnia błędy, a błędy są naturalne”.

Dlatego WebMCP bardziej przypomina umowę z samą stroną internetową, a nie kartę przypominającą wysyłaną agentowi. Wymaga od frontonu zapisania granic interakcji w implementacji, testach i kontrolach regresji. Dopóki ta warstwa kontraktu jest wciąż w fazie demonstracyjnej, agent może zrozumieć jedynie przypadek sukcesu; kiedy wejdzie na prawdziwą stronę, tak naprawdę trzeba się zająć zgodnością wersji, ścieżką do zmiany wersji i rozwiązaniem, gdy deklaracja stanie się nieważna.

Wolę traktować tę próbę pochodzenia jako sygnał kierunkowy. Przeglądarki zaczęły poważnie zastanawiać się, w jaki sposób agenci czytają strony internetowe, co oznacza, że ​​front-end nie tylko formatuje ludzi, ale także definiuje działania dla maszyn. Im bardziej złożona strona, tym cenniejsza jest ta warstwa definicji; im częściej strona jest zmieniana, tym większy jest koszt utrzymania tej warstwy definicji. Ostateczna spuścizna funkcji takich jak WebMCP nie będzie nowym terminem, ale określeniem ciągłego dostosowania pomiędzy interfejsem użytkownika a agentem.