MCP решил проблему вызова инструментов. A2A решил проблему координации. Что решает проблему транспорта?
Филип Стайецки
История распределенных вычислений — это история распространения протоколов, за которой последовала консолидация.
Архитектура Common Object Request Broker Architecture (CORBA), распределенная компонентная объектная модель (DCOM), удаленный вызов методов Java (RMI) и ранний простой протокол доступа к объектам (SOAP) конкурировали за рынок корпоративной интеграции в конце 1990-х годов, пока протокол REST (Representational State Transfer) незаметно не одержал победу благодаря своей простоте и совместимости с HTTP.
Протоколы XMPP (Extensible Messaging and Presence Protocol), IRC (Internet Relay Chat) и десяток проприетарных протоколов фрагментировали обмен сообщениями в реальном времени, прежде чем MQTT (MG telemetry transport) и WebSocket заняли свои ниши. Каждая новая вычислительная парадигма порождает всплеск конкурирующих стандартов, а затем постепенно сближается по мере накопления реализаций и экономической необходимости обеспечения совместимости.
Экосистема ИИ-агентов в настоящее время находится на стадии активного развития. За последние восемнадцать месяцев были опубликованы четыре важных протокола: протокол контекста модели (MCP) от Anthropic в конце 2024 года, протокол связи агентов (ACP) от IBM Research в марте 2025 года, Agent2Agent (A2A) от Google в апреле 2025 года и сетевой протокол агентов (ANP) от независимой рабочей группы.
Группа сообщества W3C AI Agent Protocol открыла направление по стандартизации. Рабочая группа по проектированию интернета (IETF) принимает проекты интернет-стандартов по передаче данных от агентов. На конференциях проводятся семинары по вопросам совместимости. Каждую неделю появляется новый репозиторий на GitHub, претендующий на решение проблемы связи между агентами.
Понимание того, где и как быстро происходит это сближение, имеет реальные последствия для архитектурных решений, принимаемых уже сегодня.
Что именно решают эти протоколы?
Распространение этих протоколов выглядит более хаотичным, чем есть на самом деле, потому что большинство из них взаимодействуют с различными уровнями стека, а не конкурируют за одно и то же место. Путаница возникает из-за маркетинга, который описывает каждый из них как «стандарт для общения агентов ИИ», не уточняя, какой именно аспект общения имеется в виду.
MCP — это интерфейс вызова инструментов. Он определяет, как модель обнаруживает, какие функции предоставляет сервер, как их вызывать и как интерпретировать ответ. Это типизированный контракт удаленного вызова процедур (RPC) между клиентом модели и сервером инструментов, работающий по протоколу HTTP. Фонд Linux подтвердил наличие более 10 000 активных публичных серверов MCP и 164 миллионов ежемесячных загрузок Python SDK к апрелю 2026 года. MCP уже занял лидирующие позиции в области уровня вызова инструментов. Работа по стандартизации фактически завершена.
A2A — это интерфейс координации задач. Если MCP определяет, как агент вызывает инструмент, то A2A определяет, как два агента делегируют задачу. Он вводит карточки агентов (рекламу возможностей), состояния жизненного цикла задачи и три режима взаимодействия: синхронный, потоковый и асинхронный. Google передал его в дар Linux Foundation в июне 2025 года, и корпоративные команды, занимающиеся ИИ, широко его внедрили, поскольку он заполняет реальный пробел, который остается открытым в MCP.
ACP — это формат конверта сообщений. Легковесный, без сохранения состояния, предназначенный для обмена сообщениями между агентами без полной семантики координации A2A. Он полезен в системах, где достаточно простой передачи сообщений и не требуется дополнительный жизненный цикл задач A2A.
ANP — это протокол обнаружения и идентификации. Он использует децентрализованные идентификаторы (DID) для идентификации агентов и графы JSON-LD для описания возможностей, обеспечивая основу для децентрализованных рынков агентов, где не требуется центральный реестр.
Формирующаяся структура включает в себя: обнаружение возможностей через ANP или более простые реестры, координацию задач через A2A, вызовы инструментов через MCP и упрощенный обмен сообщениями через ACP для случаев, не требующих полного управления жизненным циклом задачи. Эти уровни дополняют друг друга, а не конкурируют.
Проблема транспорта, которая остается
Все протоколы в этом списке работают поверх HTTP. Это отражает происхождение протоколов: исследовательские группы, поставщики API и компании-разработчики корпоративного программного обеспечения создают системы, где HTTP является само собой разумеющимся. HTTP — это протокол, который им знаком, тот, на котором уже говорят их серверы, и тот, который упрощает демонстрацию.
Проблема в производственной среде заключается в том, что HTTP предполагает наличие доступного сервера. За трансляцией сетевых адресов (NAT) — а 88% сетевых устройств находятся за NAT — нет доступного сервера без ретранслятора. Для групп агентов, которым необходимо маршрутизировать задачи напрямую между узлами через границы облака, домашние сети и периферийные развертывания, эта централизация заставляет каждое сообщение проходить через инфраструктуру ретрансляции. Инфраструктура ретрансляции увеличивает задержку, стоимость и создает потенциальный источник сбоев.
Протоколы прикладного уровня решают семантическую задачу обмена информацией между агентами. Однако они не решают задачу поиска агентами друг друга и установления прямых соединений. Это проблема сессионного уровня, уровня 5 в модели межсистемного взаимодействия (OSI), и ни MCP, ни A2A, ни ACP, ни ANP её не решают.
Технологии для решения этой проблемы существуют. Технология пробивания UDP-пропусков с использованием утилит обхода сессий для NAT (STUN) обеспечивает обход NAT примерно для 70% сетевых топологий. X25519 Diffie-Hellman и AES-256-GCM обеспечивают аутентифицированное шифрование на уровне туннеля без центра сертификации. Быстрые UDP-соединения в интернете (QUIC) (RFC 9000) или пользовательские протоколы скользящего окна поверх протокола пользовательских дейтаграмм (UDP) обеспечивают надежную доставку без блокировки начала очереди TCP. Это те же самые примитивы, которые WireGuard использует для VPN-туннелей, а WebRTC — для потоковой передачи мультимедиа между браузерами.
В контексте работы агентов отличие заключается в маршрутизации на основе возможностей. Агенты должны находить узлы не по имени хоста, а по тому, что эти узлы могут делать. Исследовательский агент должен иметь возможность запросить «какие узлы имеют данные об обмене валюты в реальном времени?» и получить список активных в данный момент агентов-специалистов. Это ближе к реестру служб, чем к DNS, и является естественным расширением философии проектирования ANP, примененной к транспортному уровню.
Несколько проектов занимаются сборкой этих компонентов. Pilot Protocol имеет наиболее полную опубликованную спецификацию, а проект IETF Internet-Draft охватывает адресацию, установление туннелей и обход NAT для агентских сетей. libp2p предоставляет проверенную на практике основу с аналогичными примитивами. Рабочая группа QUIC IETF разрабатывает расширения для обхода NAT, которые будут актуальны в данном случае.
Как будет выглядеть конвергенция
Протоколы на основе HTTP (MCP, A2A) уже приближаются к стабильным версиям. В ближайшие 12 месяцев планируется усиление защиты в производственной среде, улучшение безопасности, внедрение серверов MCP без сохранения состояния для горизонтального масштабирования, улучшение федерации A2A — а не разработка новых фундаментальных решений. Проблемы с вызовом инструментов и координацией задач в значительной степени решены.
Транспортный уровень отстаёт на 18-24 месяца. Ожидается период разнообразия реализаций, поскольку команды будут экспериментировать с различными подходами к одноранговой (P2P) сетевой архитектуре, за которым последует консолидация вокруг небольшого числа реализаций после накопления эмпирических данных о производительности и надёжности. Стандартизация IETF и W3C, вероятно, даст результаты в 2027-2028 годах, к тому времени одна или две реализации с открытым исходным кодом накопят достаточное количество развертываний в производственной среде, чтобы установить стандарты де-факто ещё до формальной спецификации.
Для руководителей инженерных отделов, принимающих сегодня архитектурные решения, практическим следствием является внедрение многоуровневых решений. Протоколы прикладного уровня достаточно стабильны для дальнейшего развития. Внедрение MCP сейчас сопряжено с низким риском. Внедрение A2A для координации многоагентных систем является разумным, учитывая ожидаемое развитие протокола. Транспортный уровень – это место, где либо создается собственное решение с планированием его замены, либо оцениваются ранние реализации, зная, что эта область все еще развивается.
Наибольшее влияние после стабилизации транспортного уровня окажутся у тех команд, которые разработали свои агентские системы с четким разделением между семантикой приложения (MCP, A2A) и транспортом (все, что находится ниже). Четкое разделение дешево реализовать сейчас, но дорого в дальнейшем — урок, который преподала эпоха микросервисов всем, кто пытался добавить наблюдаемость или защиту от сбоев в системы, которые этого не имели.
Филип Стайетски — соучредитель Vulture Labs.
Добро пожаловать в сообщество VentureBeat!
Наша программа гостевых публикаций — это площадка, где технические эксперты делятся своими знаниями и предоставляют нейтральные, непредвзятые аналитические материалы по искусственному интеллекту, инфраструктуре данных, кибербезопасности и другим передовым технологиям, формирующим будущее предприятий.
Узнайте больше о нашей программе гостевых публикаций — и ознакомьтесь с нашими рекомендациями, если вы заинтересованы в написании собственной статьи!
Подпишитесь, чтобы получать самые свежие новости!
Подробные аналитические данные для руководителей предприятий в области искусственного интеллекта, данных и безопасности.
Отправляя свой адрес электронной почты, вы соглашаетесь с нашими Условиями использования и Политикой конфиденциальности.
Получайте обновления ! Вы подписаны! Наши последние новости скоро поступят на вашу электронную почту.
Источник: venturebeat.com
Оцените материал:
