Betyder understøttelse af WebMCP, at vi skal bygge en AI-assistent?

Nej. At understøtte WebMCP betyder at erklære applikationens handlinger som navngivne værktøjer. Agenten, der kalder dem, kan leveres af browseren, af en udvidelse eller agentplatform, organisationen godkender, eller af en assistent, I selv indlejrer. Kun den sidste er et produkt, I skal bygge og drive.

Er det brugbart, før browserne har en agent?

Ikke for slutbrugeren. Værktøjer uden en agent til at kalde dem er et API uden en klient. Argumentet for at annotere tidligt er, at arbejdet er lille, at det tvinger en nyttig gennemgang af egne handlinger og autorisation, og at det er på plads, når en agent dukker op.

Klikker agenten rundt i vores brugerflade?

Ikke på den måde, browserautomatisering gør. Agenten kalder en handling, jeres applikation har erklæret, og applikationen afgør, hvad der sker: sætte filtre, navigere, kalde en service, vise et resultat. Brugeren ser arbejdet ske i den almindelige flade, og det er dét, der gør det muligt at kontrollere.

Erstatter det vores hjemmeside med en prompt?

Det er designet til at lade være. Applikationen, brugeren og agenten deler én flade, og brugeren kan overtage når som helst. Den visuelle side er stadig der, hvor folk sammenligner, læser vilkår og beslutter sig, og det er størstedelen af et overvejet køb eller en myndigheds sagsbehandling.

Hvad er den største risiko?

At eksponere mere, end man havde tænkt sig. Et værktøjsskema er en invitation, og det arver, hvad autorisationsmodellen i forvejen tillader. Behandl listen af værktøjer som en sikkerhedsflade, hold handlinger med konsekvenser bag en udtrykkelig bekræftelse fra et menneske, og start med handlinger, der kun læser.

indsigt

WebMCP og hjemmesiden med to indgange: hvad ledelsen rent faktisk beslutter

Core Purpose Tech6. august 20269 min. læsning

Svaret først

Der er en udbredt forventning om, at websider ender som et promptfelt. WebMCP er den mere beskedne udgave af den fremtid: applikationen bliver synlig, og prompten lægges ved siden af som en anden måde at betjene den på. To ting skal være til stede. Kun den ene er din at bygge, og om du også bygger den anden, er beslutningen om, hvem der styrer agenten.

Spørger man, hvor nettet er på vej hen, kommer en variant af det samme svar: siderne viger for en prompt, og brugeren beskriver et ønsket resultat i stedet for at lære en brugerflade at kende. Det er en rimelig læsning af markedet, og det er den læsning, der gør bestyrelser urolige, for den indebærer, at den applikation, man har brugt fire år på at bygge, ender som et tekstfelt, en anden ejer.

WebMCP er den gradvise udgave af den overgang. Siderne bliver, som de er. Prompten lægges ved siden af, leveret fra en af tre forskellige kilder, og agenten bag den betjener den applikation, brugeren allerede sidder og kigger på. Brugeren kan følge med, overtage undervejs og give næste skridt tilbage. Det er hele idéen, og den er mindre end den, den konkurrerer med.

To komponenter, og kun den ene er jeres

Det første, der skal på plads i enhver ledelsessamtale om det her: at understøtte WebMCP betyder ikke, at der skal en AI-assistent ind i produktet. To adskilte ting skal eksistere, og de behøver ikke komme fra samme organisation.

Jeres del er den midterste kasse. Agenten til venstre kan komme fra browseren, fra en udvidelse, organisationen godkender, eller fra en assistent, I selv bygger ind i produktet. Den fjerde bane er tilfældet, hvor ingen leverer en.

Jeres applikation erklærer, hvilke handlinger en agent må udføre. Noget andet forstår brugerens ønske, vælger en handling, udfylder dens parametre og forklarer resultatet. Det første er en integrationsopgave af kendt størrelse. Det andet er et produkt i sig selv, og den interessante beslutning er, om I bygger det.

Hvad et erklæret værktøj egentlig er

Et værktøj er en kort erklæring med fire dele, og formen er værd at se én gang, for det meste af snakken om agenter forudsætter noget langt mere indviklet.

Ét værktøj: et navn, en beskrivelse i almindeligt sprog, de input det tager imod, og en regel om, hvem der bekræfter. Agenten læser beskrivelsen for at afgøre, at værktøjet passer, og udfylder så felterne. Selve bookingen laves stadig af den service, der i forvejen laver bookinger.

Det er reelt implementeringsarbejde, og det er tyndere, end det ser ud, for det bør være en adapter og ikke en ny implementering af funktionen. WebMCP er lavet til at eksponere de funktioner, formularer og den applikationslogik, siden allerede har. Er en booking et servicekald i dag, er værktøjet en afbildning ned på det kald, et autorisationstjek og en ærlig beskrivelse.

Omkostningen ligger i beslutningerne omkring det, ikke i koden:

Hvilke handlinger der overhovedet eksponeres, og hvilke der kun kan nås af et menneske
Navne og beskrivelser, som er det eneste, agenten har at ræsonnere ud fra
Validering af input, for en parameter kan nu være genereret i stedet for indtastet
Autorisation i brugerens egen session, ikke i en bredere
Bekræftelse på alt med konsekvenser, og hvem der giver den
Strukturerede resultater og fejl, en agent kan handle på i stedet for at omskrive
Prompt injection og utilsigtet dataudstilling, som specifikationen behandler som centrale hensyn

Læs den liste som en integrations- og sikkerhedsflade, ikke som metadata på nogle knapper. Specifikationen behandler eksplicit tool poisoning, lækage af persondata og grænser mellem origins, og det er et rimeligt signal om, hvad gennemgangen skal dække, før noget går i luften.

Hvor agenten kommer fra

Tre steder, og valget er en investeringsbeslutning snarere end en teknisk.

Agent	I eksponerer værktøjer	I bygger assistenten	Hvad I giver afkald på
Leveret af browseren	Ja	Nej	Kontrol over model, ordlyd og bekræftelsesflow
Godkendt udvidelse eller agentplatform	Ja	Nej	Afhængighed af en leverandørs plan og adgangsregler
Indlejret i jeres applikation	Ja	Ja	Budget: brugerflade, model, samtaletilstand, logning, omkostningsstyring
Ingen tilgængelig	Ja	Nej	Der sker ingenting; værktøjerne findes, og ingen kalder dem

Den sidste række er den, man skal holde fast i. Værktøjer uden en agent er et API uden en klient: teknisk til stede, usynligt for brugeren.

For en offentligt tilgængelig side, der sigter mod browsere, som med tiden får en agent, kan det vise sig at være nok bare at eksponere værktøjer, og annoteringen er billig nok til at tage det væddemål nu. For et kontrolleret virksomhedsprodukt, hvor der er brug for ensartet adfærd, et revisionsspor og en kendt model, er en indlejret assistent eller én godkendt udvidelse den klarere vej, og den indlejrede er den med et reelt budget: assistentens brugerflade, modelleverandør, samtaletilstand, orkestrering af værktøjskald, autentificeringskontekst, rettigheder, bekræftelser, logning og styring af forbrug og omkostninger.

At bygge begge dele er beslutningen om kontrol

Kun værktøjslaget kræves af jer. Agenten er valgfri i den forstand, at I ikke behøver bygge den, og slet ikke valgfri i den forstand, at nogen skal levere den. At eksponere værktøjer og stoppe dér er et valg, ikke fraværet af et: det lader den, brugeren møder op med, betjene jeres applikation, hvad enten det er browserleverandøren, en udvidelse, de har installeret, eller den agentplatform, deres arbejdsgiver har godkendt.

At bygge den anden halvdel er det, der køber kontrollen tilbage. Jeres egen assistent er der, hvor I bestemmer ordlyden, modellen, hvornår et menneske skal bekræfte, hvad der logges, og hvilke forespørgsler den slet ikke forsøger. Det er forskellen på en flade, I betjener, og en, I har givet fra jer, og det er derfor den indlejrede vej findes, selv om den har en løbende omkostning.

De to udelukker ikke hinanden, og det er den del, der som regel bliver overset. De samme erklærede værktøjer betjener både jeres egen assistent og enhver udefrakommende agent, der dukker op senere, så at bygge den ene lukker ikke døren for de andre. Den lukker heller ikke døren til dem: det, I eksponerer, kan nås af enhver agent, der finder det, så beslutningen om eksponering bliver, hvor den altid har været, i listen af værktøjer og i rettighedstjekket.

Spørgsmålet i en bestyrelse er derfor ikke, om I skal bygge en assistent. Det er, hvilke af jeres handlinger I er villige til at lade en agent, I ikke kontrollerer, styre, og om dem, der ikke består den prøve, overhovedet bør eksponeres.

forveksles ofteWebMCP er ikke den MCP-server, I måske allerede har, og forskellen er, hvor agenten kører

Begge beskriver handlinger som navngivne værktøjer med typede input, og ét sæt definitioner kan betjene dem begge, og derfor bliver de behandlet som samme beslutning. Det er de ikke. En MCP-klient på serversiden er en separat proces med sin egen adgang, og den ser aldrig siden. Så hvis nogen siger, at agentspørgsmålet er løst, fordi der findes en MCP-server, er det her, den version ikke kan:

Hvem agenten handler som: I siden, WebMCPbrugerens eksisterende browsersession, samme origin; På serveren, MCPsin egen adgang, en ekstra autentificering, I skal bygge
Sidens tilstand: filtre, markering, en uafsendt formular: I siden, WebMCPkan læses og bruges; På serveren, MCPusynlig
Hvor resultatet vises: I siden, WebMCPjeres flade, der opdateres, mens brugeren ser på; På serveren, MCPagentens eget chatvindue
Hvor bekræftelsen sker: I siden, WebMCPjeres flade, jeres vilkår, jeres knap; På serveren, MCPagentklientens flade, i en ordlyd I ikke styrer
At skiftes med brugeren: I siden, WebMCPhele pointen; På serveren, MCPikke muligt
Hvad I kan sige bagefter: I siden, WebMCPet menneske var til stede og trykkede; På serveren, MCPder kom et autentificeret kald

Begge er værd at have, og ingen af dem erstatter den anden: kun versionen i siden kan dele skærm med brugeren, og kun den på serveren virker i alle klienter i dag.

Det er ikke fjernstyret klikkeri

Sondringen betyder noget for enhver, der har set en demo med browserautomatisering og konkluderet, at teknologien er upålidelig. Det er den som regel, og af en grund, WebMCP fjerner.

Øverst arbejder agenten sig gennem brugerfladen ét skridt ad gangen og går i stå, når en ledetekst, den byggede på, bliver skrevet om. Nederst laver den ét kald, og applikationen afgør, hvad det betyder.

På skærmen kan det godt ligne navigation. Et værktøj kan flytte brugeren til en anden visning, sætte filtre, udfylde en formular, starte en booking eller vise et resultat, og Chromes dokumentation beskriver netop det: værktøjerne udføres synligt i siden, så brugeren ser arbejdet ske inde i jeres design og jeres brand. Det, der er ændret, er, hvem der afgør, hvad handlingen betyder. Det gør jeres applikation, én gang, i stedet for at agenten udleder det forfra ved hvert besøg.

Brugeren og agenten skiftes

En kunde, der leder efter en garage til leje, viser mønstret bedre end noget diagram.

Kunden formulerer et mål: en garage tæt på arbejdspladsen, stor nok til en SUV
Agenten spørger om det, der mangler: adressen og et månedligt budget
Agenten tager det trivielle: søger, filtrerer, sorterer og viser tre muligheder
Kunden overtager: billeder, adgangsforhold, kvarteret
Kunden uddelegerer igen: sammenlign den første og den tredje, og vis opsigelsesvilkårene
Applikationen viser sammenligningen i sin almindelige brugerflade
Agenten foreslår en handling: skal jeg forberede lejeanmodningen?
Kunden bekræfter, og applikationen viser de endelige vilkår, før noget sendes

Intet trin i det forløb er en chatbot, der står foran en hjemmeside. Prompten er god til at udtrykke hensigt. Den visuelle flade er god til sammenligning, gennemsyn og til at opbygge tillid nok til at beslutte sig. Kombinationen er stærkere end hver for sig, og det er præcis den pointe, WebMCP-projektet selv illustrerer med sit indkøbseksempel.

Lad forretningslogikken blive, hvor den er

Til noget, der skal i produktion: tre lag, og det midterste holdes tyndt.

Adapteren beskriver, validerer og tjekker rettigheder. Den afgør intet, resten af applikationen ikke allerede afgør, og et kald, brugeren ikke må lave, standses dér frem for ved en service.

Rettighedstjekket er det samme, som alle andre kaldere skal igennem. En agent er en tredje vej ind, ved siden af brugerfladen og API'et, oven på én implementering af reglerne. Hvor det holder, kan en agent ikke gøre noget, den person, den handler for, ikke selv kunne have gjort i hånden, og det er den egenskab, der gør resten af diskussionen til at håndtere.

Gjort på den måde er WebMCP-arbejdet noget, der lægges til, og som kan rulles tilbage. Standarden er i origin trial og kommer til at flytte sig. Et adapterlag uden forretningslogik kan skrives om på en sprint, når den gør, og kan fjernes helt, hvis hele tilgangen aldrig finder et publikum.

Hjemmesiden med to indgange

To veje ind, ét sæt regler nedenunder, og en opgave, hvor styringen skifter hænder flere gange. Uanset hvilken vej brugeren tager, gælder samme autorisation og samme forretningslogik.

Det er den del, der er værd at tage med i en bestyrelse. Den sandsynlige fremtid er ikke et valg mellem den side, I har, og et blankt promptfelt. Det er en side, der understøtter begge dele, hvor kunden kan browse, sammenligne og udfylde en formular i hånden eller beskrive resultatet og lade en agent tage de gentagne dele, og skifte mellem de to undervejs.

WebMCP handler mindre om at gøre hjemmesider usynlige end om at gøre det, de kan, tilgængeligt gennem hensigt.

Hvad vi anbefaler

Begynd med formularerne, for den halvdel af API'et er deklarative HTML-attributter og koster en eftermiddag. Vælg derefter to-tre handlinger, der kun læser, søgning og sammenligning frem for noget, der skriver, og eksponér dem som værktøjer oven på services, I allerede har. Det er nok til at lære, hvad beskrivelserne skal sige, og hvor autorisationsmodellen er tyndere end antaget, uden at lægge en uigenkaldelig handling bag en genereret parameter.

Vent med den indlejrede assistent, indtil noget fremtvinger den. Det er den eneste af de tre veje med en løbende omkostning, og spørgsmålet, der afgør den, er ikke, om agenterne kommer. Det er, om jeres brugere har brug for en ensartet, revisionsbar assistent, I kontrollerer, eller om de møder op med deres egen.

Vi har taget det første af de skridt på dette site. Formularerne her er annoteret, ingen af dem sender sig selv, og hvad det kostede, og hvad det bragte frem, står i artiklen om formularer, en agent kan udfylde. At beslutte, hvilke handlinger der hører hjemme på listen, er den sværere halvdel. Efter vores erfaring er det en eftermiddag med dem, der ejer servicene, snarere end et projekt, og det er det samme spørgsmål, vi stiller i starten af enhver opgave om systemarkitektur: hvilken handling er det her, hvem må kalde den, og hvad skal være opfyldt, før den kører.

Betyder understøttelse af WebMCP, at vi skal bygge en AI-assistent?: Nej. At understøtte WebMCP betyder at erklære applikationens handlinger som navngivne værktøjer. Agenten, der kalder dem, kan leveres af browseren, af en udvidelse eller agentplatform, organisationen godkender, eller af en assistent, I selv indlejrer. Kun den sidste er et produkt, I skal bygge og drive.
Er det brugbart, før browserne har en agent?: Ikke for slutbrugeren. Værktøjer uden en agent til at kalde dem er et API uden en klient. Argumentet for at annotere tidligt er, at arbejdet er lille, at det tvinger en nyttig gennemgang af egne handlinger og autorisation, og at det er på plads, når en agent dukker op.
Klikker agenten rundt i vores brugerflade?: Ikke på den måde, browserautomatisering gør. Agenten kalder en handling, jeres applikation har erklæret, og applikationen afgør, hvad der sker: sætte filtre, navigere, kalde en service, vise et resultat. Brugeren ser arbejdet ske i den almindelige flade, og det er dét, der gør det muligt at kontrollere.
Erstatter det vores hjemmeside med en prompt?: Det er designet til at lade være. Applikationen, brugeren og agenten deler én flade, og brugeren kan overtage når som helst. Den visuelle side er stadig der, hvor folk sammenligner, læser vilkår og beslutter sig, og det er størstedelen af et overvejet køb eller en myndigheds sagsbehandling.
Hvad er den største risiko?: At eksponere mere, end man havde tænkt sig. Et værktøjsskema er en invitation, og det arver, hvad autorisationsmodellen i forvejen tillader. Behandl listen af værktøjer som en sikkerhedsflade, hold handlinger med konsekvenser bag en udtrykkelig bekræftelse fra et menneske, og start med handlinger, der kun læser.

WebMCP-specifikationen, herunder agenttyper og sikkerhedshensyn — Web Machine Learning Community Group
WebMCP, forklaring og eksempler på anvendelser — webmachinelearning/webmcp, GitHub
WebMCP, overblik — Chrome for Developers
WebMCP, anvendelser, herunder navigation og udfyldning af formularer — Chrome for Developers

Nyhedsbrev

En kort mail, når vi udgiver noget, der er din tid værd. Arkitektur, integration og operationel AI i regulerede organisationer. Ingen løfter om kadence, og din adresse bliver ikke givet videre.

Jeg accepterer at modtage disse mails og har læst privatlivspolitikken.