Оперативна съвместимост на инструментите за кодиране с MCP и A2A

Начало » Питон » Оперативна съвместимост на инструментите за кодиране с MCP и A2A

Агентите с изкуствен интелект вече не са просто причудливи чатботове, които отговарят на въпроси в един прозорец. Те се превръщат в разпределени системи, които могат да четат и пишат код, да извикват API, да се координират с други услуги и дори да преговарят с други агенти, за да си свършат работата. Веднага щом преминете от „един интелигентен асистент“ към „мрежа от агенти“, възниква брутален проблем: как всички тези части общуват помежду си, без да изпаднат в хаос?

Точно това е празнината, която MCP (Model Context Protocol - Протокол за контекст на модела) и A2A (Agent-to-Agent Protocol - Протокол между агенти) се опитват да запълнят. MCP се фокусира върху това как агентът се свързва с инструменти, данни и контекст, докато A2A се фокусира върху това как агентите комуникират и си сътрудничат. Те се припокриват по дух, но работят на различни нива. В тази статия ще разгледаме подробно какво прави всеки един от тях, как се допълват взаимно, как вече се използват в реални системи и какво означава това за бъдещето на инструментите за кодиране и многоагентните архитектури.

Какво всъщност представлява MCP на практика

В основата си MCP е стандартен начин за предоставяне на инструменти, ресурси и подкани на AI агент, така че агентът да може да ги извиква безопасно и последователно. Вместо да свързвате всеки инструмент директно към всеки агент с персонализиран свързващ код, вие предоставяте тези инструменти зад MCP сървър и позволявате на MCP клиентите (агентите) да ги откриват и извикват чрез унифициран протокол.

MCP следва ясна клиент-сървър архитектура: Хост приложение (като редактор, CLI или среда за изпълнение на агент) вгражда MCP клиент и този клиент отваря индивидуални връзки с един или повече MCP сървъри. Всеки сървър е просто лек процес, който предоставя набор от възможности – обикновено инструменти, ресурси само за четене и подкани за многократна употреба.

Вдъхновението е много близко до Language Server Protocol (LSP). LSP абстрахира проблема „редактор ↔ езикови функции“, така че не се налагаше да пишем персонализирани интеграции между всеки редактор и всеки език за програмиране. Ако имплементирате езиков сървър веднъж, всеки LSP-съвместим редактор може да комуникира с него. MCP възприема същата идея и я прилага към инструменти и контекст за LLM: имплементирайте инструмент веднъж като MCP сървър и всеки MCP-съвместим агент може да го използва.

От транспортна гледна точка, MCP е гъвкав, но достатъчно категоричен, за да бъде практичен. Той използва JSON‑RPC 2.0 като формат на съобщенията и поддържа множество транспорти: stdio за локални процеси (чудесно за настолни приложения и локални разработчици) и HTTP или SSE за отдалечени сървъри (перфектно за Cloud Run или контейнеризирани внедрявания). Протоколът също така определя как клиентът открива възможности и как инструментите се описват с помощта на JSON Schema, така че LLM да може да реши кога и как да ги извика.

Най-важното е, че MCP не се опитва да дирижира разсъжденията на вашия агент. То не решава когато трябва да се извика инструмент или как инструментите трябва да бъдат свързани във верига. MCP е слоят за свързване: той предоставя инструменти, ресурси и подкани по структуриран и откриваем начин, оставяйки вземането на решения на вашата агентска рамка, плановик или инженеринг на подкани.

Основни градивни елементи на MCP: инструменти, ресурси и подкани

MCP сървърите се въртят около три основни елемента: инструменти, ресурси и подкани. Тези три концепции са достатъчни, за да покрият повечето нужди на агентите в реалния свят, без да превръщат протокола в пълноценна рамка за оркестрация.

Инструментите са отделни действия, които агентът може да задейства. Мисля "get_weather","search_inventory","book_flight","run_sql_query"Или"get_exchange_rate„Всеки инструмент е деклариран с име, описание, което може да се чете от човек, и входна схема. Тази схема позволява на LLM да разбере какви параметри трябва да предаде, а също така защитава вашия backend, като валидира аргументите преди изпълнение.“

Ресурсите представляват данни само за четене, които сървърът може да обслужва при поискване. Файлове, лог файлове, редове от база данни, фрагменти от документация, конфигурационни файлове – всяка информация, която е по-добре моделирана като „извличане на това нещо“, отколкото като „изпълнение на тази функция“. Ресурсите могат да бъдат големи, така че MCP определя начини за тяхното пренасочване към страници и стрийминг, което е критично при подаване на контекст в модел с ограничен прозорец.

Подканите са шаблони за многократна употреба, които сървърите могат да показват на клиентите. Вместо да кодирате твърдо дълги, крехки низове за подкани във вашия агент, можете да ги централизирате като MCP подкани. Сървърът ги предоставя с имена, описания и слотове за параметри, а клиентът запълва тези слотове по време на изпълнение. Това е изненадващо мощно, когато множество агенти трябва да споделят едни и същи модели за това как да общуват с конкретен инструмент или да следват правилата за безопасност и съответствие в цялата компания.

Когато клиент се свърже със сървър, той извършва стъпка за откриване на възможности. Сървърът отговаря с каталог с инструменти, ресурси и подкани, всеки с подробни метаданни. След това този каталог се въвежда в LLM (обикновено в обобщена форма), така че моделът да може да разсъждава: „Мога да използвам get_exchange_rate да отговоря на този въпрос относно конвертирането на валута и не би трябвало да се опитвам да измислям отговора.“

Тъй като всичко това е декларативно, нови възможности могат да бъдат добавяни или премахвани, без да се засяга основната логика на агента. Добавете нов инструмент към сървъра, преразположите го и всеки MCP клиент, който се свърже, ще го види при следващото договаряне на възможности. Това е моментът на „включване на още едно USB устройство“ за инструментите с изкуствен интелект.

Конкретен пример за MCP: инструмент за конвертиране на валута

Демонстрацията на валутен агент от комплекта за разработка на агенти (ADK) на Google е перфектна илюстрация на MCP в действие. Започва се с изграждането на малък MCP сървър, който предоставя достъп до един единствен инструмент, get_exchange_rate, подкрепен от публичния Frankfurter API. На диска това е просто малък Python скрипт, използващ fastmcp.

Сървърът дефинира инструмента с типизирани аргументи за currency_from, currency_to намлява currency_date, плюс надеждно регистриране и обработка на грешки. Когато агентът го извика, сървърът се свързва с Frankfurter през HTTP, валидира отговора и връща JSON полезен товар с валутния курс или обект за грешка. Нищо в това не е специфично за ИИ; MCP просто стандартизира как тази функционалност се описва и извиква.

Локално, стартирате сървъра с проста команда и той слуша http://localhost:8080. Отделен тестов клиент, също използващ MCP, се свързва и открива get_exchange_rate и задейства повикване за USD → EUR. Логът показва извикването на инструмента, изходящата HTTP заявка, успешния отговор и върнатия JSON. От гледна точка на вашия агент, той просто пита „какви инструменти имам?“ и след това „моля, обадете се на този“.

Разгръщането на същия сървър в Cloud Run едва променя историята. Контейнеризирате MCP сървъра, разгръщате го с --no-allow-unauthenticated така че изисква удостоверяване, подкрепено от IAM, и след това отваря защитен тунел от локалната ви машина, използвайки командата Cloud Run proxy. Локално вашият MCP клиент все още смята, че общува с http://127.0.0.1:8080; проксито обработва прозрачно удостоверяването и мрежовите преходи.

Този модел е мощен в екипи: можете да управлявате централизиран MCP сървър за споделени инструменти като валутни курсове, вътрешни API или собствени бази данни. Всеки агент-разработчик в организацията може да се свърже с този сървър чрез защитен транспорт, вместо да доставя своя собствена, малко по-различна, полуподдържана обвивка около същия API.

Изграждане на агенти върху MCP: от единични инструменти до пълноценни работни процеси

MCP става наистина интересен, когато го вградите в агентска рамка като ADK на Google. В примера с валутния агент, ADK се използва за създаване на специализиран LLM агент, чиято единствена задача е да отговаря на въпроси относно валутните курсове, използвайки инструмента MCP. Системната инструкция на агента буквално му казва: „Вашата единствена цел е да използвате get_exchange_rate инструмент“.

ADK свързва тази инструкция, избраният модел (например gemini-2.5-flash) и an MCPToolset екземпляр, който сочи към URL адреса на MCP сървъра. От този момент нататък, когато потребител попита „Колко са 250 канадски долара в щатски долари?“, агентът обмисля дали е необходимо извикване на инструмент, попълва параметрите на инструмента, изпраща заявката чрез MCP и след това пише удобен за потребителя отговор, използвайки върнатия JSON.

Същият модел се мащабира и до много по-сложни агенти. Вместо единен API за валута, можете да свържете множество сървъри: един за вътрешни бази данни, друг за SaaS на трети страни, друг за търсене на документи, плюс сървър, който предоставя многократно използваеми подкани или RAG канали. MCP не се интересува дали тези сървъри работят локално, в Cloud Run, в Kubernetes или зад VPN, стига транспортът да се поддържа и удостоверяването да е правилно конфигурирано.

ADK също добавя перспектива, насочена към агента, която MCP умишлено избягва. Той третира агентите като композируеми софтуерни компоненти: можете да дефинирате агенти, базирани на LLM, агенти с тежки инструменти, агенти за оценка и оркестратори, всички от които способни да говорят MCP директно от кутията. Резултатът е, че „създаване на агент“ започва да изглежда много повече като „създаване на микросървис“ и много по-малко като „настройване на безкраен подканващ елемент в бележник“.

Какво е A2A – и защо само MCP не е достатъчен

Ако MCP е за свързване на агенти към инструменти, A2A е за свързване на агенти към други агенти. Веднага щом имате множество агенти, всеки от които знае как да прави нещо добре, ви е необходим начин те да се намират, да обменят задачи и да останат синхронизирани, докато работата е в ход. Това е проблемното пространство, за което е предназначен A2A.

A2A, иницииран от Google Cloud и сега под егидата на Linux Foundation, е отворен стандарт за оперативна съвместимост между агенти. Използва познати технологии (HTTP(S), JSON‑RPC 2.0 и SSE за стрийминг), но ги обгръща в домейн модел, който разбира агенти, умения, задачи, артефакти и възможности. Вместо „извиквания на инструменти“, получавате език за сътрудничество от по-високо ниво.

Двете основни идеи в A2A са картите на агентите и задачите. Картата на агента е JSON документ – обикновено откриваем на /.well-known/agent.json – който описва какво може да прави един агент, как да го достигне, какво удостоверяване очаква и какви режими на вход/изход поддържа. Задачите са единиците работа, които един агент може да изпрати на друг, с добре дефиниран жизнен цикъл и структурирани резултати.

При A2A взаимодействие, един агент поема ролята на „клиентски агент“, а друг действа като „отдалечен агент“. Клиентът открива картата на отдалечения агент, решава дали това е правилният партньор за работата и след това създава заявка за задача. Отдалеченият агент получава задачата, използва собствения си LLM и вътрешни инструменти (често чрез MCP), за да я изпълни, и след това предава обратно актуализации на напредъка и финални артефакти.

Този дизайн прави A2A директен, асинхронен и лесен за работа в мрежа. Под капака, Python имплементациите се основават на ASGI рамки като Starlette (чрез A2AStarletteApplication) и uvicorn, като артефактите и актуализациите на задачите се изпълняват през JSON‑RPC и SSE. Това означава, че задачите могат да се изпълняват секунди или часове, без да блокират нито една HTTP заявка, което е от съществено значение за реалните многоагентни работни процеси.

Пример от A2A: показване на агент „Hello“ и отвъд него

Каноничният A2A „HelloWorldAgent“ показва механиката в опростен вид. Вие дефинирате AgentExecutor подклас, който реализира execute метод. Вътре, вие добавяте в опашката на събитията едно текстово съобщение – „Здравей от A2A!“ – като резултат от задачата. Анулирането става „невъзможна операция“ за този прост случай, но куката съществува за реални натоварвания.

След това създавате AgentSkill описвайки какво може да прави този агент. В примера, умението hello носи име, описание, набор от тагове и представителни потребителски заявки. Това умение след това се обединява в AgentCard заедно с името на агента, версията, URL адреса, възможностите и поддържаните режими на вход/изход.

Накрая свързвате всичко в A2AStarletteApplication с DefaultRequestHandler и го стартирайте под uvicorn. Що се отнася до външния свят, вече имате пълноправен A2A агент, който слуша http://localhost:9000Всеки клиент, който поддържа A2A, може да извлича /.well-known/agent.json, разберете какво предлага този агент и му изпратете задачи.

В по-реалистични внедрявания, същият модел се мащабира до сценарии за оркестрация, като резервиране на пътувания, адаптация или автоматизация на поддръжката. „Туристически агент“ може да открие и да разговаря с „Агент за полети“, „Агент за хотели“ и „Агент за коли под наем“, като всеки от тях работи зад собствена A2A крайна точка и крие вътрешните си инструменти и специфични за доставчиците API договори. Туристическият агент вижда само задачи, умения и артефакти.

Тук е мястото, където A2A разделянето на грижите блести. Всеки агент надолу по веригата може да избира свои собствени модели, рамки и инструменти – хотелски агент, изграден с ADK и MCP, агент на авиокомпания, изграден с друг стек, агент за коли под наем, разположен в инфраструктурата на партньор – и всички те все още да си сътрудничат чисто чрез A2A повърхността.

Обединяване на MCP и A2A в една архитектура

На хартия разделението звучи добре – MCP за инструменти, A2A за агенти – но на практика границите бързо се размиват. Реалните системи често искат да скрият A2A зад MCP, да сложат MCP вътре в A2A или да смесят и двете в един и същ процес. Официалните A2A примери дори обгръщат A2A комуникацията като MCP инструменти, достъпни от един сървър, така че LLM вижда „един MCP набор от инструменти“ вместо два паралелни протоколни стека.

Един често срещан модел е MCP да се третира като вътрешно окабеляване на всеки агент, а A2A като външна мрежа между агентите. Вътре в агент, вашият LLM извиква MCP инструменти, за да достигне до бази данни, API или хранилища за документи. Отвън, вашият оркестратор комуникира с този агент чрез A2A, предавайки задачи и четейки артефакти обратно. От гледна точка на оркестратора, агентът е услуга тип „черна кутия“ с изчистен, типизиран интерфейс.

Обратният модел – извеждане на A2A като MCP инструменти – е привлекателен от гледна точка на интеграцията. Много доставчици на LLM вече имат усъвършенствани инструменти около MCP: инструменти за разработка, демонстрации на потребителски интерфейси, SDK и ръководства за сигурност. Като изложите „свържете се с отдалечен агент X“ като един единствен MCP инструмент, вие позволявате на LLM да задейства A2A взаимодействие с минимална настройка. Регистрирате само един MCP сървър, но „под капака“ този сървър може да брокерира задачи в цяла A2A мрежа.

Точно това демонстрират някои примерни хранилища: вместо да свързва всеки отдалечен A2A агент директно към модела, MCP сървърът предлага компактен набор от инструменти, които самите говорят A2A. Това нарушава наивния ментален модел („MCP и A2A трябва да са напълно отделни“), но значително опростява практическата интеграция и поддържа повърхността на вашия LLM интерфейс малка и добре организирана.

Също така нищо не ви пречи да използвате MCP и A2A изолирано, където това има смисъл. Много проекти ще се нуждаят само от MCP, за да свържат един агент с няколко инструмента. Други, особено когато обединяват доставчици или вътрешни екипи, ще разчитат предимно на A2A за координация между организациите, като използват собствена вътрешна мрежа вместо MCP. Важното е, че протоколите не се конкурират – те се допълват.

Оперативна съвместимост, рамки и липсващата „голяма структура“

Сами по себе си протоколите не гарантират оперативна съвместимост, ако всеки ги вгражда в коренно различни архитектури от по-високо ниво. Можете да говорите перфектно MCP и A2A и пак да се окажете със зоопарк от взаимно несъвместими модели на агенти, всеки от които преоткрива планирането, паметта, обработката на грешки и управлението.

Вероятната следваща стъпка в екосистемата е слой от рамки, изградени върху MCP и A2A, които стандартизират не само проводниците, но и по-голямата структура. Помислете как уеб фреймворците са се появили върху HTTP или как ORM са изградени върху SQL. Започваме да виждаме това с ADK, оркестратори, подобни на LangGraph, управлявани платформи като Vertex AI Agent Engine и AI шлюзове, които разбират и двата протокола.

След като индустрията се сближи около няколко прагматични модела – „ето как се структурира многоагентен работен процес върху A2A и MCP“, „ето как се разкриват инструментите на екипите зад MCP“ – споровете относно това дали нещо „трябва да бъде зад MCP или A2A“ ще започнат да избледняват. Повечето разработчици просто ще изберат рамка, ще включат един или два сървъра и ще получат разумни настройки по подразбиране.

По-сложният и по-бавен проблем е бързото инженерство и бързата оперативна съвместимост. Дори и с перфектни протоколи, когато свързвате системи чрез MCP и A2A, вие ефективно позволявате на произволни подкани – системни инструкции, описания на инструменти, предпазни релси – да изтичат и да взаимодействат през граници. Ако тези подкани са неправилно подравнени, излишни или напълно противоречиви, производителността ви страда много преди да възникнат опасения за сигурността.

На практика, лошо проектираните подкани и инструкции в MCP + A2A стек могат да доведат до масивна латентност, халюцинации и нестабилност. Всеки агент може да е локално „добре подканван“, но когато ги наслоите, потоците могат да станат крехки: инструментите са неправилно приоритизирани, контекстните прозорци са пропилени и очакванията на потребителско ниво са нарушени. A2A може да координира задачи, MCP може да разкрива инструменти, но нито един от тях не ви принуждава да поддържате подканите последователни.

Ето защо екипи, които действително са доставяли LLM продукти в голям мащаб, са склонни да третират бързото инженерство като първокласен инженерен проблем, а не като корекция в последния момент. Заинтересованите страни в бизнеса често виждат подканите като магически начин да поправят всичко; инженерите понякога отхвърлят подканите като второстепенен детайл в сравнение с кода. Реалността е по средата: подканите няма да направят лоша система добра, но небрежните подкани могат напълно да съсипат иначе солидна архитектура.

Сигурност, идентичност и управление в MCP и A2A

След като започнете да позволявате на агентите да действат от името на хора през границите на MCP и A2A, идентичността и оторизацията бързо се превръщат в централни проблеми. Една заявка може да премине през няколко нива на делегиране: потребител общува с оркестратор, който извиква инструмент през MCP, който вътрешно извиква други MCP сървъри или A2A агенти, които изискват отделни идентификационни данни.

Конкретни сценарии изникват навсякъде: SaaS приложение предоставя MCP сървър, който се нуждае от OAuth токени; вътрешен HR агент зад A2A използва корпоративни LDAP самоличности; инструмент за анализ на трета страна използва собствен SSO. Потребителят очаква „влезте веднъж и свършете работата си“, но зад кулисите трябва да бъдат обединени множество системи за самоличност.

Документацията на Google A2A изрично посочва федерацията с множество идентичности като основно предизвикателство. Потребител U може да взаимодейства с Агент A, който изисква самоличността на система A (например, корпоративен LDAP), докато Агент A вътрешно трябва да делегира на Агент B, който изисква самоличността на система B (например, външен SaaS доставчик). Протоколите трябва да поддържат пренасянето и определянето на обхвата на тези самоличности, без да се принуждават потребителите да се удостоверяват повторно ръчно за всеки хоп.

Доставчиците на самоличност и OAuth/OIDC платформите бързо се адаптират към тази нова реалност. Инфраструктури като Logto, Auth0 или вътрешни доставчици на идентификация вече могат да издават токени, които агентите носят чрез MCP и A2A разговори. Отвореният въпрос не е дали това е възможно – очевидно е – а как да стандартизираме моделите, така че инструмент, създаден днес, да не се превърне в проблем за сигурността или управлението утре.

В допълнение към удостоверяването, наблюдаемостта и прилагането на политики вероятно ще се преместят в споделени „шлюзове за агенти“. Тези шлюзове могат да прекратяват MCP и A2A трафик, да централизират регистрирането, да налагат ограничения на скоростта, да прикачват потребителски и агентски самоличности и дори да филтрират кои инструменти или агенти са достъпни в кои контексти. Това започва да прилича много на API шлюзове – просто настроени за AI трафик, вместо за обикновен HTTP.

Отстъпвайки назад, MCP и A2A тихомълком променят начина, по който мислим за софтуерната интеграция и инструментите за кодиране. За разработчиците, асистент по кодиране, свързан с MCP и ACP (протоколът за агентски клиенти за IDE), може да открива инструменти, да се свързва с езикови сървъри, да се интегрира с контрол на версиите и да общува с агенти на други програмисти – всичко това чрез стандартни протоколи. За предприятията, многоагентните системи могат да работят взаимодействат между екипи и доставчици, без да се пренастройва всичко за всеки нов случай на употреба.

Дългосрочната промяна е от „твърдо вградени приложения“ към „агентски екосистеми“. Точно както USB и HTTP направиха възможно свързването на произволни устройства и услуги, MCP и A2A се стремят да направят инструментите и агентите с възможност за включване. Победители ще бъдат екипите, които третират тези протоколи не като лъскави лога, а като фундаментална инфраструктура за това как техните системи общуват, си сътрудничат и се развиват с течение на времето.