MCP решил вызов инструментов, A2A - координацию. Что решит транспорт для AI-агентов?

Экосистема AI-агентов переживает протокольный бум. За полтора года вышли четыре значимых стандарта: MCP от Anthropic, A2A от Google, ACP от IBM и ANP от независимой рабочей группы. Каждый решает свою часть пазла. Но есть одна проблема, которую не закрыл никто - транспорт. Ии агенты новости пишут о протокольной войне, но на деле войны нет: протоколы дополняют друг друга. Проблема в другом - они все работают поверх HTTP, а HTTP не умеет заглядывать за NAT.

История распределённых вычислений - это история протокольной конкуренции, которая каждый раз заканчивается консолидацией. CORBA, DCOM, Java RMI, SOAP боролись за enterprise-интеграцию в конце 90-х - REST пришёл и всех съел, потому что был проще и работал поверх HTTP. XMPP, IRC и десяток проприетарных протоколов дробили рынок мгновенных сообщений - MQTT и WebSockets заняли свои ниши. Сейчас та же история повторяется с AI-агентами, только быстрее.

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

Путаница возникает из-за маркетинга: каждый протокол называют «стандартом для коммуникации AI-агентов». Но ни один не решает коммуникацию целиком - каждый закрывает свой слой стека.

MCP - это интерфейс вызова инструментов. Протокол описывает, как модель узнаёт, какие функции есть на сервере, как их вызывать и как интерпретировать ответ. Это типизированный RPC-контракт между моделью-клиентом и сервером инструментов, работающий поверх HTTP. MCP уже выиграл: стандартизация фактически закончена, работу над версиями признают завершённой.

A2A - интерфейс координации задач. Если MCP определяет, как агент вызывает инструмент, то A2A - как два агента делегируют задачу друг другу. Google передала его Linux Foundation в июне 2025 года. Enterprise-команды приняли его массово, потому что он закрывает реальную дыру, которую MCP оставляет открытой.

ACP от IBM - формат сообщения-конверта. Лёгкий, без сохранения состояния, для обмена сообщениями между агентами без полной семантики координации A2A. Полезен там, где нужно просто передать сообщение, а жизненный цикл задачи - избыточен.

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

«Каждый протокол в этом списке работает поверх HTTP. И это проблема. HTTP предполагает, что сервер доступен по адресу. Но 88% сетевых устройств сидят за NAT - там нет доступного сервера без релея» - Philip Stayetski, сооснователь Vulture Labs

Проблема, которую никто не решил

Все перечисленные протоколы решают прикладной уровень. Что агенты говорят друг другу. Никто не решает, как агенты находят друг друга и устанавливают прямое соединение. Это проблема сессионного уровня (Layer 5 в модели OSI). MCP, A2A, ACP и ANP к ней даже не притрагиваются.

HTTP предполагает доступный сервер. За NAT - а там 88% устройств - сервера нет. Чтобы агенты могли маршрутизировать задачи напрямую между пирами через облачные границы, домашние сети и edge-развёртывания, нужна релейная инфраструктура. Которая добавляет задержку, стоимость и ещё одну точку отказа.

Технологии для решения есть. UDP hole-punching с STUN работает для 70% сетевых топологий. X25519 Diffie-Hellman и AES-256-GCM дают аутентифицированное шифрование без центрального центра сертификации. QUIC (RFC 9000) или кастомные sliding-window протоколы поверх UDP обеспечивают надёжную доставку без head-of-line blocking TCP.

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

Что будет через год

Транспортный слой отстаёт от прикладного на 18-24 месяца. Сейчас идёт период экспериментальной имплементации: команды пробуют разные подходы к P2P-сетям для агентов. Консолидация начнётся, когда накопится эмпирика по производительности и надёжности. IETF и W3C выпустят стандарты в районе 2027-2028 годов, но к тому времени одна-две open-source реализации уже станут де-факто стандартами.

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

«Самый большой рычаг влияния будет у тех команд, которые спроектировали свои агентные системы с чистым разделением между семантикой приложения (MCP, A2A) и транспортом. Микросервисная эра научила нас этому - разделение слоёв дёшево сделать сейчас и дорого встроить потом» - Philip Stayetski, Vulture Labs

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

Что это значит для бизнеса

Если вы строите AI-агентов для бизнеса - не ждите, пока транспортный слой устаканится. Берите MCP и A2A уже сейчас. Вы не ошибётесь: эти протоколы уже настолько устоялись, что Linux Foundation за ними стоит. А транспорт абстрагируйте через прослойку, которую можно будет заменить через год-два.

Для бизнеса на Дальнем Востоке история особенно актуальна. Внедрение ai-агентов влечёт за собой вопросы не только протоколов, но и инфраструктуры. Во Владивостоке, где задержка до западных облаков выше, AI-архитектура с peer-to-peer транспортным слоем может дать серьёзное преимущество в производительности. Нейросети для бизнеса - это не только про качество модели, но и про то, как агенты общаются между собой.

Мы помогаем компаниям во Владивостоке строить устойчивые AI-решения с правильной архитектурой: чистым разделением слоёв, multi-provider стратегией и оптимизацией под локальную инфраструктуру. Начните с аудита - разберём ваши процессы и предложим архитектуру, которая не устареет через год.