MCP ці A2A: адзін дае агенту інструменты, другі — партнёраў

|Аўтар: Рэдакцыя QUASA|5 хв чытання
MCP ці A2A: адзін дае агенту інструменты, другі — партнёраў

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

Выбар залежыць ад таго, што знаходзіцца па другі бок злучэння. Калі агенту патрэбна функцыя з вядомымі параметрамі, падыходзіць MCP. Калі ён даручае працу іншаму выканаўцу, які сам выбірае спосаб дзеяння і можа падтрымліваць размову пра задачу, патрэбны A2A. Калі агент адначасова карыстаецца сваімі інструментамі і супрацоўнічае з аддаленым агентам, у сістэме з’яўляюцца абодва ўзроўні.

Дзе праходзіць мяжа паміж інструментам і агентам

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

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

Тры схемы ў адной архітэктуры

Агент выклікае інструмент праз MCP

У гэтай схеме агент звяртаецца да MCP-кліента, той — да MCP-сервера, які адкрывае патрэбныя функцыі. Спецыфікацыя інструментаў MCP апісвае запыт tools/list для атрымання даступных функцый і tools/call для іх выкліку. Апісанне інструмента змяшчае назву і схему ўваходных параметраў; сервер можа вызначыць таксама схему структураванага выніку. Гэта дазваляе кліенту ведаць, якую аперацыю ён запускае і якія аргументы ёй патрэбныя.

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

Агент даручае задачу агенту праз A2A

Тут кліент звяртаецца да аддаленага агента як да самастойнага выканаўцы. Апісанне асноўных паняццяў A2A вызначае Agent Card як звесткі пра магчымасці, адрас і патрабаванні да аўтэнтыфікацыі агента. Task адлюстроўвае працу са станам і жыццёвым цыклам, Message перадае паведамленне, а Artifact — атрыманы вынік. На просты зварот аддалены агент можа адказаць паведамленнем; працяглая праца можа ісці як задача, за станам якой сочыць кліент.

У тым жа ўмоўным сэрвісе агент падтрымкі можа перадаць пытанне агенту дастаўкі. Той сам вызначыць, якія ўласныя сістэмы праверыць, пры патрэбе запытае дадатковыя звесткі і верне адказ. Кліенту не трэба ведаць унутраную паслядоўнасць яго выклікаў. A2A дае спосаб узгадняць працу паміж такімі ўдзельнікамі, у тым ліку калі яны створаны рознымі камандамі і маюць розныя ўнутраныя інструменты.

Агенты супрацоўнічаюць і карыстаюцца сваімі інструментамі

У камбінаванай схеме агент падтрымкі правярае даступныя яму даныя праз MCP і перадае асобную частку працы агенту дастаўкі праз A2A. Аддалены агент таксама можа карыстацца MCP для доступу да сваіх функцый. Вынік вяртаецца праз сувязь паміж агентамі, а выклікі інструментаў адбываюцца ўнутры той часткі сістэмы, якая выконвае даручэнне.

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

Бяспека праходзіць праз абедзве межы

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

Для A2A дадаецца мяжа паміж арганізацыямі або асобнымі сістэмамі. Правілы карпаратыўнага выкарыстання A2A патрабуюць HTTPS у працоўным асяроддзі, апісваюць аўтэнтыфікацыю праз стандартныя вэб-механізмы і ўскладаюць праверку правоў на сервер аддаленага агента. У камбінаванай схеме трэба асобна вырашыць, каму дазволена перадаць задачу і якія дзеянні выканаўца мае права зрабіць праз уласныя інструменты. Схаваная ад кліента ўнутраная логіка партнёра не замяняе кантроль доступу.

Калі дадатковы пратакол апраўданы

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

Міжагентную каардынацыю тэхнічна можна пабудаваць і праз MCP. Рэалізацыйнае даследаванне MCP і A2A параўнала абодва падыходы на адной задачы праграмнай інжынерыі: рэалізацыя на MCP мела меншую складанасць каардынацыі, але стан размовы і жыццёвы цыкл задач патрабавалі асобнай прыкладной логікі. A2A прапаноўваў для іх пратакольныя механізмы пры большай складанасці рэалізацыі. Аўтары абмяжоўваюць высновы разгледжаным сцэнарыем. Для архітэктурнага выбару гэта азначае канкрэтны кампраміс: падтрымліваць каардынацыю ў сваім кодзе або ўзяць яе гатовыя паняцці разам з дадатковымі патрабаваннямі пратакола.

Чытайце таксама:

Падзяліцца:

Падпішыцеся на нашу рассылку

Атрымлівайце свежыя навіны пра Web3, ШІ і крыптавалюты проста на пошту.

0