Када агент вештачке интелигенције посети веб локацију, то је у суштини туриста који не говори локални језик. Било да је изграђен на ЛангЦхаин-у, Цлауде Цоде-у или све популарнијем ОпенЦлав оквиру, агент се своди на нагађање које дугмад треба да притисне: стругање сировог ХТМЛ-а, испаљивање снимака екрана мултимодалним моделима и нарезивање хиљада токена само да би открио где се налази трака за претрагу.
Та ера се можда завршава. Раније ове недеље, Гоогле Цхроме тим је покренуо ВебМЦП — Контекстни протокол веб модела — као рани преглед у Цхроме 146 Цанари. ВебМЦП, који су заједнички развили инжењери у Гоогле-у и Мицрософт-у и инкубиран кроз В3Ц-ове Заједничка група за веб машинско учењеје предложени веб стандард који омогућава било којој веб локацији да изложи структуриране алате који се могу позвати директно АИ агентима преко новог АПИ-ја претраживача: навигатор.моделЦонтект.
Импликације за ИТ предузећа су значајне. Уместо да граде и одржавају одвојене позадинске МЦП сервере у Питхон-у или Ноде.јс-у да би повезали своје веб апликације са АИ платформама, развојни тимови сада могу да умотају своју постојећу ЈаваСцрипт логику на страни клијента у алате читљиве агентима — без поновне архитектуре једне странице.
Агенти вештачке интелигенције су скупи, крхки туристи на вебу
Проблеми са трошковима и поузданошћу са тренутним приступима интеракцији веб-агента (агента претраживача) добро разумеју свако ко их је применио у великом обиму. Две доминантне методе — визуелно скрапинг екрана и ДОМ рашчлањивање — обе пате од фундаменталних неефикасности које директно утичу на буџет предузећа.
Са приступима заснованим на снимцима екрана, агенти прослеђују слике у мултимодалне моделе (као што су Цлауде и Гемини) и надају се да модел може да идентификује не само шта је на екрану, већ и где се налазе дугмад, поља обрасца и интерактивни елементи. Свака слика троши хиљаде токена и може имати дуго кашњење. Са приступима заснованим на ДОМ-у, агенти уносе сирови ХТМЛ и ЈаваСцрипт — страни језик пун разних ознака, ЦСС правила и структурних ознака које нису релевантне за задатак који се налазе, али и даље троше простор прозора контекста и трошкове закључивања.
У оба случаја, агент преводи између онога за шта је веб локација дизајнирана (људске очи) и онога што је моделу потребно (структурирани подаци о доступним акцијама). Једна претрага производа коју човек заврши за неколико секунди може захтевати десетине узастопних интеракција агената — кликање на филтере, померање страница, рашчлањивање резултата — свака од њих је позив закључивања који додаје кашњење и цену.
Како функционише ВебМЦП: Два АПИ-ја, један стандард
ВебМЦП предлаже два комплементарна АПИ-ја која служе као мост између веб локација и АИ агената.
Тхе Декларативни АПИ рукује стандардним радњама које се могу директно дефинисати у постојећим ХТМЛ формама. За организације са добро структуираним облицима који су већ у производњи, овај пут захтева минималан додатни рад; додавањем назива алата и описа постојећим ознакама образаца, програмери могу учинити да те форме могу позвати агенти. Ако су ваши ХТМЛ обрасци већ чисти и добро структурирани, вероватно сте већ на 80% пута.
Тхе Императив АПИ обрађује сложеније, динамичке интеракције које захтевају извршавање ЈаваСцрипт-а. Овде програмери дефинишу богатије шеме алата — концептуално сличне дефиницијама алата које се шаљу ОпенАИ или Антхропиц АПИ крајњим тачкама, али раде у потпуности на страни клијента у претраживачу. Преко регистерТоол(), веб локација може да изложи функције као што су сеарцхПродуцтс(упит, филтери) или ордерПринтс(цопиес, паге_сизе) са пуним шемама параметара и описима природног језика.
Кључни увид је да један позив алата преко ВебМЦП-а може заменити оно што је могло бити десетине интеракција коришћења претраживача. Сајт за е-трговину који региструје алатку сеарцхПродуцтс омогућава агенту да упути један позив структуриране функције и прими структуриране ЈСОН резултате, уместо да агент кликне кроз падајуће меније филтера, скролује кроз резултате са страницама и снима екран сваке странице.
Случај предузећа: цена, поузданост и крај крхког стругања
За доносиоце одлука у ИТ-у који процењују примену агентске вештачке интелигенције, ВебМЦП истовремено решава три упорне болне тачке.
Смањење трошкова је најнепосреднија корист која се може измерити. Заменом секвенци снимака екрана, мултимодалних позива за закључивање и итеративног ДОМ рашчлањивања са једним структурираним позивима алата, организације могу очекивати значајно смањење потрошње токена.
Поузданост побољшава јер агенти више не нагађају о структури странице. Када веб локација експлицитно објави уговор о алаткама — "ево функција које подржавам, ево њихових параметара, ево шта враћају" — агент ради са сигурношћу, а не закључивањем. Неуспеле интеракције услед промена корисничког интерфејса, динамичког учитавања садржаја или двосмислене идентификације елемената су углавном елиминисане за било коју интеракцију покривену регистрованим алатом.
Брзина развоја убрзава јер веб тимови могу да искористе свој постојећи фронт-енд ЈаваСцрипт уместо да постављају засебну позадинску инфраструктуру. У спецификацији се наглашава да сваки задатак који корисник може да изврши преко корисничког интерфејса странице може да се претвори у алатку поновним коришћењем већег дела постојећег ЈаваСцрипт кода странице. Тимови не морају да уче нове серверске оквире или да одржавају одвојене АПИ површине за кориснике агената.
Човек у петљи по дизајну, а не накнадно
Критична архитектонска одлука одваја ВебМЦП од парадигме потпуно аутономног агента која је доминирала недавним насловима. Стандард је изричито осмишљен око кооперативних токова рада који се одвијају у кругу – а не аутоматизације без надзора.
Према Кхусхалу Сагару, софтверском инжењеру за Цхроме, ВебМЦП спецификација идентификује три стуба који су у основи ове филозофије.
-
Контекст: Сви агенти података морају да разумеју шта корисник ради, укључујући садржај који се често тренутно не види на екрану.
-
Могућности: Радње које агент може предузети у име корисника, од одговарања на питања до попуњавања образаца.
-
Координација: Контролисање преноса између корисника и агента када агент наиђе на ситуације које не може самостално да реши.
Аутори спецификације у Гуглу и Мајкрософту то илуструју сценаријем куповине: корисник по имену Маја тражи од свог АИ асистента да помогне у проналажењу еколошки прихватљиве хаљине за венчање. Агент предлаже продавце, отвара прегледач на сајту за одевање и открива да страница открива ВебМЦП алате као што су гетДрессес() и сховДрессес(). Када Маиа-ини критеријуми превазиђу основне филтере сајта, агент позива те алате да дохвати податке о производу, користи сопствено резоновање да филтрира "одговарајућа коктел одећа," а затим позива сховДрессес() да ажурира страницу само релевантним резултатима. То је флуидна петља људског укуса и способности агента, управо она врста колаборативног прегледавања коју је ВебМЦП дизајниран да омогући.
Ово није стандард прегледавања без главе. Тхе спецификација експлицитно наводи да безглави и потпуно аутономни сценарији нису циљеви. За те случајеве употребе, аутори указују на постојеће протоколе као што је Гоогле-ов Агент-то-Агент (А2А) протокол. ВебМЦП се односи на претраживач — где је корисник присутан, гледа и сарађује.
Није замена за МЦП, већ допуна
ВебМЦП није замена за Антхропиц-ов Модел Цонтект Протоцол, упркос томе што дели концептуалну лозу и део његовог имена. Не прати ЈСОН-РПЦ спецификацију коју МЦП користи за комуникацију клијент-сервер. Тамо где МЦП функционише као бацк-енд протокол који повезује АИ платформе са провајдерима услуга преко хостованих сервера, ВебМЦП функционише у потпуности на страни клијента у оквиру претраживача.
Однос је комплементаран. Туристичка компанија би могла да одржава позадински МЦП сервер за директне АПИ интеграције са АИ платформама као што су ЦхатГПТ или Цлауде, док истовремено имплементира ВебМЦП алате на својој веб локацији која је окренута потрошачима, тако да агенти засновани на претраживачу могу да комуницирају са његовим током резервација у контексту активне сесије корисника. Ова два стандарда служе различитим обрасцима интеракције без сукоба.
Разлика је важна за архитекте предузећа. Позадинске МЦП интеграције су прикладне за аутоматизацију од услуге до услуге где није потребан кориснички интерфејс претраживача. ВебМЦП је прикладан када је корисник присутан и интеракција има користи од заједничког визуелног контекста — који описује већину веб интеракција окренутих према потрошачима до којих је предузећима стало.
Шта следи: Од заставе до стандарда
ВебМЦП је тренутно доступан у Цхроме-у 146 Цанари иза "ВебМЦП за тестирање" заставица на цхроме://флагс. Програмери се могу придружити Програм раног прегледа Цхроме-а за приступ документацији и демонстрацијама. Други претраживачи још нису објавили временске рокове имплементације, иако Мицрософт-ово активно коауторство спецификације сугерише да је подршка Едге-а вероватна.
Индустријски посматрачи очекују званичне најаве претраживача до средине до краја 2026. године, уз Гоогле Цлоуд Нект и Гоогле И/О као вероватна места за шире најаве увођења. Спецификација прелази са инкубације заједнице у оквиру В3Ц на формални нацрт — процес који историјски траје месецима, али сигнализира озбиљну институционалну посвећеност.
Поређење које је Сагар направио је поучно: ВебМЦП има за циљ да постане УСБ-Ц интеракција АИ агената са вебом. Јединствени, стандардизовани интерфејс у који сваки агент може да се укључи, замењујући тренутни сплет прилагођених стратегија за гребање и крхких скрипти за аутоматизацију.
Да ли ће се та визија остварити зависи од усвајања — и од стране добављача претраживача и од стране веб програмера. Али са Гоогле-ом и Мицрософт-ом који заједнички испоручују код, В3Ц који обезбеђује институционалну скелу и Цхроме 146 који већ користи имплементацију иза заставице, ВебМЦП је отклонио најтежу препреку са којом се суочава било који веб стандард: прелазак од предлога до функционалног софтвера.
