История распределённых вычислений — это бесконечная драма протокольного зоопарка, где выживают не самые хитрые, а самые простые. CORBA, DCOM, Java RMI и ранний SOAP грызлись за корпоративную интеграцию в конце 90-х, пока REST тихо не пришёл и не положил всех на лопатки одной лишь HTTP-нативностью. XMPP, IRC и дюжина проприетарных протоколов дробили мир мгновенных сообщений, пока MQTT и WebSocket не расчертили свои ниши. Каждая новая вычислительная парадигма взрывается фейерверком конкурирующих стандартов, а потом медленно сползается в единую точку, когда интероперабельность становится экономически неизбежной.
Экосистема AI-агентов сейчас как раз в стадии этого взрывного размножения. За последние полтора года выстрелили сразу четыре значимых протокола: Model Context Protocol (MCP) от Anthropic в конце 2024-го, Agent Communication Protocol (ACP) от IBM Research в марте 2025-го, Agent2Agent (A2A) от Google в апреле 2025-го и Agent Network Protocol (ANP) от независимой рабочей группы. W3C уже запустил стандартизацию через свою AI Agent Protocol Community Group. IETF получает Internet-Drafts по транспорту агентов. Конференции штампуют воркшопы по интероперабельности. Каждую неделю на GitHub появляется очередной репозиторий, который «окончательно решает проблему общения между агентами».
Понимание того, когда и как быстро этот хаос сойдётся в точку, напрямую влияет на архитектурные решения, которые инженеры принимают прямо сейчас. Не просто академический интерес — деньги и время на кону.
Что на самом деле решают протоколы
На первый взгляд кажется, что все смешалось в кучу, но на самом деле большинство этих протоколов закрывают разные уровни стека, а не бьются за один слот. Путаницу создаёт маркетинг: каждый пишут «стандарт для общения AI-агентов», умалчивая, какую именно грань общения они стандартизируют.
MCP — это интерфейс вызова инструментов. Он описывает, как модель узнаёт, какие функции доступны на сервере, как их дёргать и как разбирать ответ. По сути — типизированный RPC-контракт между моделью-клиентом и сервером инструментов, работающий поверх HTTP. Linux Foundation к апрелю 2026 года насчитал более 10 000 активных публичных MCP-серверов и 164 миллиона ежемесячных загрузок Python SDK. MCP уже выиграл слой вызова инструментов. Работа по стандартизации фактически завершена.
A2A — это интерфейс координации задач. Если MCP говорит, как агент вызывает инструмент, то A2A описывает, как два агента делегируют задачу друг другу. Он вводит Agent Cards (рекламные объявления о возможностях), состояния жизненного цикла задачи и три режима взаимодействия: синхронный, потоковый и асинхронный. Google в июне 2025 года передал протокол Linux Foundation, и корпоративные AI-команды широко его приняли, потому что он закрывает реальную дыру, которую MCP оставил открытой.
ACP — это формат конверта сообщений. Лёгкий, без сохранения состояния, спроектированный для обмена сообщениями между агентами без полной семантики координации A2A. Пригодится в системах, где достаточно простой передачи сообщений, а оверхед жизненного цикла задач A2A излишен.
ANP — это протокол обнаружения и идентификации. Он использует децентрализованные идентификаторы (DID) для идентификации агентов и графы JSON-LD для описания возможностей, создавая основу для децентрализованных маркетплейсов агентов, где не нужен центральный реестр.
Вырисовывается такой стек: обнаружение возможностей через ANP (или более простые реестры), координация задач через A2A, вызов инструментов через MCP и лёгкий обмен сообщениями через ACP для случаев, где полное управление жизненным циклом задач не требуется. Эти уровни не конкурируют — они дополняют друг друга.
Проблема транспорта, которая осталась
Каждый протокол из этого списка работает поверх HTTP. Это отражает их происхождение: исследовательские команды, API-провайдеры и корпоративные софтверные компании, где HTTP — неоспоримая данность. HTTP — знакомый протокол, с которым их серверы уже умеют работать, и который делает демо простыми как пять копеек.
Проблема в продакшене: HTTP требует, чтобы сервер был доступен по сети. А 88% сетевых устройств сидят за NAT — за трансляцией сетевых адресов. Без ретранслятора до них не достучаться. Когда флотилия агентов должна маршрутизировать задачи напрямую между пирами через облачные границы, домашние сети и edge-деплои, эта централизация прогоняет каждое сообщение через инфраструктуру ретрансляции. А ретрансляция — это лишняя задержка, лишние деньги и лишняя точка отказа.
Протоколы прикладного уровня решают семантику того, что агенты говорят друг другу. Они не решают, как агенты находят друг друга и устанавливают прямые соединения. Это проблема сеансового уровня — пятого уровня модели OSI. И ни MCP, ни A2A, ни ACP, ни ANP её не трогают.
Технологии для решения существуют. UDP hole-punching с STUN обеспечивает NAT traversal примерно для 70% сетевых конфигураций. X25519 Diffie-Hellman и AES-256-GCM дают аутентифицированное шифрование на уровне туннеля без центра сертификации. QUIC (RFC 9000) или кастомные протоколы со скользящим окном поверх UDP обеспечивают надёжную доставку без блокировки головы очереди, как у TCP. Те же примитивы, что WireGuard использует для VPN-туннелей, а WebRTC — для медиа-потоков между браузерами.
Разница в контексте агентов — это маршрутизация на основе возможностей. Агентам нужно искать пиров не по хостнейму, а по тому, что эти пиры умеют делать. Исследовательский агент должен спросить: «Какие пиры имеют данные о курсах в реальном времени?» — и получить список активных специализированных агентов. Это ближе к сервис-регистру, чем к DNS, и естественное расширение философии ANP, применённое к транспортному уровню.
Несколько проектов уже собирают эти кусочки. Pilot Protocol имеет наиболее полную опубликованную спецификацию с IETF Internet-Draft по адресации, установке туннелей и NAT traversal для сетей агентов. libp2p предоставляет боевую основу с похожими примитивами. Рабочая группа IETF по QUIC разрабатывает расширения для NAT traversal, которые будут здесь к месту.
Как будет выглядеть конвергенция
HTTP-базированные протоколы MCP и A2A уже сходятся к стабильным версиям. Следующие 12 месяцев — это закалка для продакшена, улучшения безопасности, stateless MCP-серверы для горизонтального масштабирования, лучшая федерация A2A — но не новые фундаментальные архитектуры. Слой вызова инструментов и координации задач практически решён.
Транспортный уровень отстаёт на 18–24 месяца. Ждите периода разнообразия реализаций, пока команды экспериментируют с разными подходами к P2P-сетям агентов, а затем консолидации вокруг небольшого числа реализаций, когда накопятся эмпирические данные по производительности и надёжности. Стандартизационные треки IETF и W3C, скорее всего, выдадут результат в окне 2027–2028 годов. А к тому времени одна-две opensource-реализации наберут достаточно продакшен-деплоев, чтобы стать де-факто стандартами раньше формальной спецификации.
Для тех, кто прямо сейчас принимает архитектурные решения, практический вывод — многослойное внедрение. Протоколы прикладного уровня достаточно стабильны, чтобы на них строить. MCP сейчас — низкий риск. A2A для мультиагентной координации — разумно с ожиданием, что протокол будет эволюционировать. Транспорт — это либо строить кастом и готовиться заменить, либо присматриваться к ранним реализациям, понимая, что всё ещё движется.
Команды, которые получат максимальный рычаг, когда транспорт стабилизируется, — это те, кто спроектировал свои агентские системы с чётким разделением между семантикой приложения (MCP, A2A) и транспортом (что бы там ни было снизу). Чистое разделение дёшево внедрить сейчас и дорого встроить потом — урок эры микросервисов, который выучил любой, кто пытался добавить observability или circuit breaker в систему, где их не было.
Philip Stayetski — сооснователь Vulture Labs.