Sluit u aan bij de WebMCP Origin-proefperiode

Nadat Chrome 149 begint met het aanbieden van een proefversie van de WebMCP-oorsprong, zal de relatie tussen de webpagina en de proxy directer worden: de pagina toont niet langer alleen de DOM en de zichtbare kopie zodat de machine deze kan raden; het besturingselement zelf kan ook het doel, de status en de uitvoerbare grenzen aangeven. Deze verandering lijkt op een API-proef, maar lijkt in feite meer op het optillen van de “interface-intentie” van impliciete informatie naar een expliciet protocol.

De waarde van zoiets als WebMCP is niet het toevoegen van een terminologielaag aan de webpagina, maar het vergroten van de onzekerheid waar agenten het meest bang voor zijn. Of een knop nu bedoeld is om te verzenden, over te schakelen, te bevestigen of gewoon een pop-uplaag te openen; of een invoervak ​​een datum, een zoekterm of een afspraaktijd is waarvoor een speciaal formaat vereist is. In het verleden werd deze informatie vooral afgeleid uit tekst, structuur en context. Inferentie werkt, maar zodra de pagina complex wordt, begint de agent ‘lijkt op’ te verwarren met ‘is’.

Voor mensen is deze verkeerde lezing meestal slechts een misklik. Voor agenten veranderen verkeerde lezingen in een gestaag pad van fouten. Het zal doorgaan met het uitvoeren volgens het verkeerde inzicht totdat het verificatie, terugdraaien of bijwerkingen tegenkomt, waaruit blijkt dat de vorige stap op een dwaalspoor is geraakt. Nadat WebMCP deze semantieklaag expliciet heeft gemaakt, hoeft de agent de pagina niet meer te raden als een puur visuele kaart, en kan de webpagina ook duidelijk de verantwoordelijkheden van de belangrijkste interactieoppervlakken uitleggen.

Deze kwestie is het meest geschikt voor die interfaces die moeilijk uit te leggen zijn met pure HTML-copywriting, zoals kalenders, reserveringen, toestemmingsapplicaties, instellingenpanelen of een heleboel pagina’s die op gewone invoervakken lijken, maar in werkelijkheid een andere zakelijke betekenis hebben. Wanneer de agent alleen op label en tijdelijke aanduiding vertrouwt, moet hij vaak de pagina rondgaan en het steeds opnieuw proberen; zodra de pagina kan aangeven “hier is de datumselectie”, “hier is de bevestigingsactie” en “de status hier kan alleen in deze richting veranderen”, worden de integratiekosten direct verlaagd.

Maar het onderzoek naar de oorsprong roept ook een ander probleem op: deze laag van semantiek moet in stand worden gehouden. De paginastructuur zal veranderen, de knopkopie zal veranderen en de bedrijfsstatus zal veranderen. Als de intentielaag waar de agent echt op vertrouwt niet samen met de componenten wordt bijgewerkt, zal deze snel verdwijnen. Op dat moment is de gevaarlijkste toestand niet ‘volledig onbruikbaar’, maar ‘kan nog steeds draaien, maar maakt af en toe fouten, en die fouten zijn natuurlijk’.

Daarom lijkt WebMCP meer op een contract voor de webpagina zelf, dan op een herinneringskaart die naar de agent wordt gestuurd. Het vereist dat de front-end interactiegrenzen in de implementatie, in tests en in regressiecontroles schrijft. Zolang deze contractlaag zich nog in de demonstratiefase bevindt, kan de agent alleen maar begrijpen dat er sprake is van een succes; wanneer het de echte pagina betreedt, wordt wat echt moet worden afgehandeld de versiecompatibiliteit, het downgradepad en de oplossing nadat de declaratie ongeldig wordt.

Ik beschouw deze oorsprongsproef liever als een richtinggevend signaal. Browsers begonnen serieus na te denken over de manier waarop agenten webpagina’s lezen, wat betekent dat de front-end niet alleen de opmaak voor mensen verzorgt, maar ook acties voor machines definieert. Hoe complexer de pagina, hoe waardevoller deze definitielaag is; hoe vaker de pagina wordt gewijzigd, hoe groter de onderhoudskosten van deze definitielaag zijn. De laatste erfenis van mogelijkheden zoals WebMCP zal geen nieuwe term zijn, maar een term voor continue afstemming tussen de frontend en de agent.