Протоколы агентов ИИ: MCP, A2A, ACP, ANP

История распределенных вычислений — это череда появления множества протоколов сменяющихся их последующей консолидацией.

Общая архитектура с запросами объектов (CORBA), распределенная модель компонент объектов (DCOM), удаленный вызов методов Java (RMI) и ранний простой протокол доступа к объектам (SOAP) соперничали за рынок корпоративной интеграции в конце 1990-х годов, прежде чем архитектура передаче репрезентативного состояния (REST) тихо победила за счет большей простоты и нативной поддержки HTTP.

Протокол расширяемого обмена сообщениями и присутствия (XMPP), интернет-ретрансляционный чат (IRC) и дюжина проприетарных протоколов фрагментировали рынок обмена сообщениями в реальном времени до того, как телеметрический транспорт MQTT и WebSockets заняли свои соответствующие ниши. Каждая новая вычислительная парадигма порождает всплеск конкурирующих стандартов, а затем постепенно приходит к консенсусу по мере накопления реализаций и возникновения экономической необходимости в совместимости.

Экосистема ИИ-агентов в настоящее время находится в фазе распространения. За последние восемнадцать месяцев было опубликовано четыре значимых протокола: Model Context Protocol (MCP) от Anthropic в конце 2024 года, Agent Communication Protocol (ACP) от IBM Research в марте 2025 года, Agent2Agent (A2A) от Google в апреле 2025 года и Agent Network Protocol (ANP) от независимой рабочей группы.

Группа сообщества W3C по протоколам ИИ-агентов открыла путь к стандартизации. Инженерный совет Интернета (IETF) получает интернет-черновики по транспорту агентов. На конференциях проводятся семинары по совместимости. Каждую неделю появляется новый репозиторий на GitHub, авторы которого заявляют, что решили проблему связи между агентами.

Понимание того, где и как быстро произойдет эта консолидация, имеет реальные последствия для архитектурных решений, принимаемых прямо сейчас.

Что на самом деле решают протоколы

Этот хаос выглядит масштабнее, чем есть на самом деле, поскольку большинство этих протоколов работают на разных уровнях стека, а не борются за одно и то же место. Путаница возникает из-за маркетинга, который описывает каждый из них как «стандарт для связи ИИ-агентов», не уточняя, какой именно аспект коммуникации имеется в виду.

MCP — это интерфейс вызова инструментов. Он определяет, как модель обнаруживает доступные на сервере функции, как их вызывать и как интерпретировать ответ. Это контракт типизированного удаленного вызова процедур (RPC) между клиентом модели и сервером инструментов, работающий поверх HTTP. К апрелю 2026 года Linux Foundation подтвердила наличие более чем 10 000 активных публичных серверов MCP и 164 миллионов ежемесячных загрузок Python SDK. MCP уже выиграл на уровне вызова инструментов. Работа по стандартизации фактически завершена.

A2A — это интерфейс координации задач. Если MCP определяет, как агент вызывает инструмент, то A2A определяет, как два агента делегируют друг другу задачи. Он вводит карточки агентов (Agent Cards — описание возможностей), состояния жизненного цикла задач и три режима взаимодействия: синхронный, потоковый и асинхронный. Google передала его в Linux Foundation в июне 2025 года, и корпоративные команды, занимающиеся разработкой ИИ, широко приняли его, поскольку он заполняет реальный пробел, оставляемый MCP.

ACP — это формат конверта сообщений. Легковесный, без сохранения состояния (stateless), разработанный для обмена сообщениями между агентами без полноценной семантики координации A2A. Он полезен в системах, где достаточно простой пересылки сообщений, а издержки A2A на управление жизненным циклом задачи избыточны.

ANP — это протокол обнаружения и идентификации. Он использует децентрализованные идентификаторы (DID) для идентификации агентов и графы JSON-LD для описания возможностей, обеспечивая основу для децентрализованных рынков агентов, где не требуется центральный реестр.

Формирующийся стек выглядит следующим образом: обнаружение возможностей с помощью ANP или более простых реестров, координация задач через A2A, вызовы инструментов с помощью MCP и легковесный обмен сообщениями через ACP для тех случаев, когда не требуется полноценное управление жизненным циклом задачи. Эти слои дополняют друг друга, а не конкурируют.

Проблема транспорта, которая остается нерешенной

Каждый протокол из этого списка работает поверх HTTP. Это отражает происхождение самих протоколов: исследовательские группы, поставщики API и компании, создающие корпоративное ПО, исходят из того, что HTTP — это нечто само собой разумеющееся. HTTP — это протокол, который они знают, на котором уже говорят их серверы и который позволяет легко создавать демоверсии.

Проблема промышленного использования заключается в том, что HTTP предполагает наличие доступного сервера. За технологией трансляции сетевых адресов (NAT) — а за NAT находится 88% сетевых устройств — нет доступного сервера без ретранслятора. Для парка агентов, которым необходимо направлять задачи напрямую между пирами через границы облачных сред, домашних сетей и периферийных развертываний (edge deployments), такая централизация заставляет пропускать каждое сообщение через инфраструктуру ретрансляторов. Инфраструктура ретрансляторов добавляет задержки, стоимость и дополнительную точку отказа.

Протоколы прикладного уровня решают семантические задачи того, что агенты говорят друг другу. Они не решают, как агенты находят друг друга и устанавливают прямые соединения. Это проблема сеансового уровня (уровень 5 модели OSI), и ее не решает ни MCP, ни A2A, ни ACP, ни ANP.

Технологии для решения этой задачи существуют. Пробивание дыр в UDP с помощью утилит обхода сеансов для NAT (STUN) обеспечивает обход NAT примерно для 70% сетевых топологий. X25519 Diffie-Hellman и AES-256-GCM обеспечивают аутентифицированное шифрование на уровне туннеля без центра сертификации. Быстрые интернет-соединения UDP (QUIC) (RFC 9000) или пользовательские протоколы с плавающим окном поверх пользовательского датаграммного протокола (UDP) обеспечивают надежную доставку без блокировки заголовка очереди (head-of-line blocking), присущей TCP. Это те же примитивы, которые использует WireGuard для VPN-туннелей и WebRTC для медиапотоков между браузерами.

Что отличается в контексте агентов, так это маршрутизация на основе возможностей. Агентам необходимо находить пиры не по имени хоста, а по тому, что эти пиры умеют делать. Исследовательский агент должен иметь возможность запросить: «у каких пиров есть данные по курсам валют в реальном времени?» — и получить список активных в данный момент специализированных агентов. Это ближе к реестру служб, чем к DNS, и является естественным продолжением философии проектирования ANP, примененной к транспортному уровню.

Горстка проектов собирает эти элементы воедино. Pilot Protocol имеет наиболее полную опубликованную спецификацию, включая интернет-черновик IETF, охватывающий адресацию, установку туннелей и обход NAT для сетей агентов. libp2p предоставляет проверенную в боевых условиях основу с аналогичными примитивами. Рабочая группа QUIC в составе IETF разрабатывает расширения для обхода NAT, которые также будут здесь актуальны.

Как будет выглядеть консенсус

Протоколы на базе HTTP (MCP, A2A) уже приближаются к стабильным версиям. Следующие 12 месяцев принесут промышленное укрепление (hardened production), улучшения безопасности, создание stateless-серверов MCP для горизонтального масштабирования и лучшую федерацию A2A, а не новые фундаментальные разработки. Уровни вызова инструментов и координации задач в значительной степени решены.

Транспортный уровень отстает на 18–24 месяца. Ожидайте периода разнообразия реализаций, пока команды экспериментируют с различными подходами к одноранговым (P2P) сетям агентов, за которым последует консолидация вокруг небольшого числа реализаций по мере накопления эмпирических данных о производительности и надежности. Пути стандартизации IETF и W3C, вероятно, принесут результаты в районе 2027–2028 годов, к моменту чего одна или две реализации с открытым исходным кодом накопят достаточное количество продакшн-развертываний, чтобы установить де-факто стандарты еще до официальной спецификации.

Для технических руководителей, принимающих архитектурные решения сегодня, практическим выводом является поэтапное внедрение. Протоколы прикладного уровня достаточно стабильны, чтобы строить на них решения. Внедрение MCP сейчас сопряжено с низким риском. Внедрение A2A для координации работы нескольких агентов вполне разумно с расчетом на то, что протокол будет развиваться. Транспортный уровень — это то место, где вы либо создаете что-то свое с планами заменить это позже, либо оцениваете ранние реализации, понимая, что область все еще находится в движении.

Команды, которые получат наибольшее преимущество при стабилизации транспортного уровня, — это те, которые спроектировали свои агентные системы с четким разделением семантики приложения (MCP, A2A) и транспорта (всего, что находится ниже). Четкое разделение недорого реализовать сейчас и дорого переделывать потом — урок, который эпоха микросервисов преподала всем, кто пытался добавить наблюдаемость (observability) или прерывание цепи (circuit breaking) в системы, изначально лишенные этого.

Филип Стаецкий — соучредитель Vulture Labs.

Добро пожаловать в сообщество VentureBeat!

Наша программа гостевых публикаций — это площадка, где технические эксперты делятся своими соображениями и представляют независимый, непредвзятый глубокий анализ ИИ, инфраструктуры данных, кибербезопасности и других передовых технологий, формирующих будущее корпоративного сектора.

Читайте далее в рамках нашей программы гостевых публикаций и ознакомьтесь с нашими рекомендациями если вы хотите предложить собственную статью!