WebMCP: сайты публікуюць інструменты, а агенты не клікаюць па інтэрфейсе

Уявіце саб-праект, у яком агент ШЫ павінен самастае кераваць веб-дзеяннем. Першая версія працуе так, як большасць браузерных агентоў: агент отрымае доступ да дзеяння і вырашвае, што робіць, на адваротнае ад таго, што паказвае сторанка. Для простаг дзеяння тыпу „Спіс задач“ запіт можа быць „Дадзіце ‘Купіць яйця’ у мой спіс“. Ён павінен пераглянуць сторанку, знайсці поле для вводу, выявіць, які кнопкі выканае форму, нажаць на яе, а пасля пераканацца ў выніку.

Гэта працуе, але для гэтага трэба зусіллі, якія здаюцца занадта велікімі. Дзеянне ужо точна знае, што трэба зрабіць. За тойю кнопкай знаходзіцца функцыя, за тойой функцыяй — API, а сама операцыя ўскладнюецца толькі адной ясной вызовам:

add_todo(title)

Тады чаму агенту трэба стаяць на інтэрфейсе і здагадвацца, як зрабіць калякво, што прыкладнэць ужо можа опісаць? Самэ гэта і ўчыняе WebMCP зрозумелым. Працэс стае такім:

User request
     ↓
AI agent
     ↓
WebMCP tool
     ↓
Application logic
     ↓
UI updates

Інтэрфейс застаўся для людзей-візітараў. Агенту проста не трэба яго дэкадаваць, каб выканаць дзеянне. Гэта зміняе падход да всія проблемы. Пытанне можа не быць у тым, як зробіць ШЫ лепшым у вікорыстоўванні веб-сайтаў. Яго можа быць у тым, як зробіць веб-сайты крашчымі у тым, каб паведаміць ШЫ, што яны можуць робіць.

Два спосабы, якімі агенты выкорыстоўваюць інтэрнэт сёння, і дзе кожны з іх мае слабасі

Агент, які павінен дзеяць на сайце, наразе мае два распашчытаныя спосабы.

Першы — аўтаматызацыя браузера. Агент робіць скрыншоты, выявляе, што можна клікнуць, перамешчае курсор, запоўняе поле, клікае, пераканальваецца, што сталося, і так далей. Гэта нагадвае спагляданне чалавека, які керуе браузерам, і у гэтага спосабу ёсць тыя ж слабасі: ён медленны, спалюе токены і лёгка ламаецца. Незначныя змяны у макеце, закрытыя меню, взаімадзеянне, якое можліва толькі пад час наведэння курсара, або дапэўніцы ў працэсе можу збіць агента з курсу.

Другій варыянт — гэта спецыяльны сервер MCP, створаны для вашага прыемніка. Для інструментаў гэта дае набліжна лепшы досвід. Аднак расходы вырастаюць іншым чынам, адтуды што агент павінен спачатку знайсці існаванне сервера і падключыцца да яго. Калі кожны веб-сайт разрабатвае сваю сабэйскую інтэграцыю, гэта не дазволяе масштабавання. Гэта практычны ліміт падходу з спецыяльным MCP.

Гэта стварае праслойку. Автаматызацыя браузера занадта опосерэдкована, а спецыяльныя інтэграцыі — занадта ручныя. WebMCP створаны для прыемніка між гэтымі двума падходамі.

Што такое WebMCP

Проста кажучы, WebMCP дазволяе веб-сайту паведаміць агенту AI: «Ось што можна зрабіць на гэтай сторанцы». У звярзанні з тым, што агент мусіць сам выбіраць, які кнопкі нажыць, сайт проста дае спіс дзеянняў.

Напрыклад, інтэрнэт-магазін могаў бы публікаваць такія інструменты:

search_products()
get_product_details()
add_to_cart()

Агент, які выкашвае сайт, сам нарабатывае інструменты і вызывае іх за дапамою структураваных даных, які кожны з іх задае. Не трэба нічога рэўіструваць у агенце загадзя. Інструменты адкрываюцца дынамічна з веб-сайта, і гэта тое, што варта адзначыць. Сайт перастае быць проста сумкай стороніц і пачынае запрошваць можлівасці.

Конкрэтны прыклад: дапыткі Todo

Возьмім простую дапытку Todo. Без WebMCP агенту было бы трэба пераглядаць стораніцу, знаходзіць поле для вводу, пісаць тэкст, шукаць кнопку «Дадзіць», нажыць яе і зноў чытаць апцэнаваны інтэрфейс.

З WebMCP дапытка можа публікуваць чатыры інструменты:

add_todo(title)
list_todos()
toggle_todo(id)
delete_todo(id)

Агент большэй не патрабуе жадных ведомаў пра візуальную структуру. Ён знае, што можа робіць прыкладна програма. Дэман, створаны самэ так, паказаў прыкладную програму Todo, якая адкрывала чатыры інструменты; падключаны агент чытаў іх схемы і негайна вызываў add_todo. Калі агенту было сказана дадаць у спіс фразу „Мне трэба купіць яйця“, быў вызваны відпаведны інструмент, і новы элемент з’явіўся ў прыкладнай програме.

Ментальная модэль значна простэйшая: інтэрфейс назначаны для людзей, інструменты — для агентоў, і абодва працуюць з той самым прыкладным програмам.

Як выглядае апісанне інструмента

Тут інжынеры фронтэнду знайдуць гэта цікавым. Рэалізацыя ў тым дэмане рэгіструе інструменты праз navigator.modelContext. Кожны інструмент складаецца з калькі частак:

{
  name: "add_todo",
  description: "Add a todo item",
  inputSchema: {
    // structured inputs
  },
  execute: async (input) => {
    // application logic
  }
}

Фармат застаецца аднаковым: імя, апісанне, схема вводу дадзейнаў і функцыя-выканавальнік, якая выканае задачу, зазвычай праз вызов API-ў сервера, якія ўжо ёсць ў прыемліку. Гэты аспект мае важлівэ значэнне. WebMCP не вымагае перапісваць логіку бізнесу для AI. Існуючы прыемлік застаецца сістэмай, якая выканае операцыю, а агент проста отрымае структураваны спосаб яе запуску.

Проблемы з аўтэнтыфікацыяй

Усё стае серйозней, калі прыемлік больш не ёсць простым інструментам. Уявіце сабе такія інструменты:

get_profile()
update_profile()
create_order()
cancel_order()
transfer_money()

Нявядомы агент не павінен мець можлівасць свабодна выканання такіх дзеянняў. Другі прыклад у там самым матэрыяле рашае самэ гэта пытанне за дапамою OAuth. Інструменты WebMCP працуюць у межах аўтэнтыфікованага прыемніка, і корыстувальнікі, якія не заўважыліся, не можуць выканання захішчаных дзеянняў.

Гэта мае значэнне, таму што агенты можуць выходзіць з розных кліентав: прыемніка з падтрымкай AI, стацыонарнага агента чы іншага додатку-агента. Стандартны механізм, такі як OAuth, значна спрыяе захыцеўці шара можлівасцей у всіх іх, у пораўнанні з неабходнасцю стварання окрэмага працэса заўважэнняся для кожнай інтэграцыі. Калі сайты адкрываюць свае можлівасці для агентаў, аўтэнтыфікацыя стае часткай ўжо з першага дня ўжыцця агента, а не патчам, даданым пазней.

Новы пытанне для дызайну фронтэнду

Прывычна архітэктура фронтэнду гадзінаў гэтыя гады цікавілася толькі адной ланцоўкай: інтэрфейс, стан, API, бэкэнд. WebMCP дагаўляе ўсё новы пытанне: якія можлівасці должна аплікацыя адкрываць для агента?

Гэта здаецца дробным пытаннем, але гэта можа змяніць спосаб праектавання функцый. Кнопка „Да кошыка“ — гэта взаімадзеянне з чалавекам. Што ж, гэты вызов — гэта можлівасць самай аплікацыі:

add_to_cart(productId, quantity)

І тое, і іншэ зрэшты можа быць спраектавана разам. Людзі атрымліваюць апрануты інтэрфейс, а агенты — структураваны інтэрфейс з можлівасцямі, і якія-то з іх у канцэ справляюцца ў рамках адной і той жа бізнес-логікі.

Гэта не толькі пра швальнасць

Ёсць глыбокія прычыны, чаму гэта мае значэнне, а не толькі пра швэйшыя агенты. Калі агент працуе за дапамою скрыншотаў і клікаў, сам інтэрфейс являе сабою кантракт, і будзь-яя змяна інтэрфейса можа зламаць агента. З WebMCP апісанне інструмента стае часткай кантракта.

Гэта прыводзіць да таго, што ў спектр абавязакаў распрацоўшчыка фронтэнду прабраўцца новы набор пунктав: назвы інструментаў, апісанні, схемы вхідных дадзенняў, модзель выканання і межы аутэнтыфікацыі. Праца больш не заключаецца толькі у дызайне экранаў. Яна начыняе включаць у сябе дызайн таго, як програмнае забезпечэнне прадстаўляе ся інтэлігентным сістэмам.

Яшчэ раннія стадыя

Ўсім трэба падкрэсліць адну важлівую прымету. WebMCP застаецца толькі прыцэпам прыбліжнай версіі і не ўжо стаў стандартам веба. Дэман працаваў у Chrome Beta, калі WebMCP быў увёрнуты за дапамогою настройкаў прыгледача, і выступаючы ясна заявіў, што API ўсё ўсё можа змяніцца. Стварэнне архітэктуры для практычнага выкарыстоўвання на ўсіх апаратах зараз было бы прытэмна. Експерыментаванне з ям ўжо іншая справа, адтолькі ідэя, якая стоіць за ям, ёсць болей шырокай, чым сучасны API.

Веб-сайты працоўваюць вялікія гады на адной падставе: з іншай стороны знаходзіцца чалавек. WebMCP ўжо адна з першых спробыяць паставіць гэта пад сумнев. Веб-зявы можа скора змагчыцца адпавядаць на два пытанні: як чалавек павінен яго выкарыстоўваць? І як яго можа выкарыстоўваць штучны інтэлект? Першае пытанне прынесла стварэнне сучаснай інжынерыі фронтэнду. Другае можа сутліва паўтарыць тэндэнціі, якія будуць развівацца далей.