Транспортные протоколы для AI-агентов (Рубрика #AI)

За последний год мы наблюдаем интересную эволюцию: AI постепенно перестаёт быть "надстройкой" над существующими интерфейсами и начинает формировать собственный слой взаимодействия. Вспомним путь, которые прошли протоколы MCP, A2A, A2UI

- MCP (Model Context Protocol)
Это попытка от Antrhropic стандартизировать, как модели получают доступ к контексту (файлы, базы, API). По сути, это про data plane для LLM
- A2A (Agent-to-Agent)
Это попытка от Google выстроить коммуникации между агентами как между равноправными участниками системы. По сути формализует диалоги, delegation, coordination. Раньше я уже сравнивал MCP и A2A протоколы
- A2UI (Agent-to-UI)
Предложенный Google протокол вокруг идеи того, что UI становится не primary интерфейсом, а "рендером" агентных действий. В итоге, пользователь взаимодействует с агентом, а не с формой/кнопками. Раньше я уже про него рассказывал
Если смотреть на тренды, то мы больше не описываем API для людей - мы описываем намерения для агентов

Продолжая эту тенденцию дальше мы приходим к идее собственного транспортного протокола для агентов, так как сейчас агентский мир живет поверх обычного http, который
- Заточен под request/response
- Плохо выражает intent (всё прячется в JSON)
- Не имеет нативной модели identity/authority для агентов
- Не оптимизирован под высокочастотный stateful трафик
И мы получаем агентные системы, которые выглядят как RPC поверх HTTP с кучей костылей.

Дальше появляется мысль вынести агентную коммуникацию в отдельный протокол ««« мы здесь
И у нас уже есть два кандидата в такой протокол: AGTP (19 марта 2026 года) и ATP (22 марта 2026 года)

1️⃣ AGTP (Agent Transfer Protocol, Chris Hood)
Этот протокол предлагает
- Новые методы вместо HTTP verbs: QUERY, EXECUTE, BOOK, ESCALATE
А значит intent становится частью протокола
- Protocol-level identity: agent_id, authority, delegation chain
А значит больше не нужно прятать это в headers/body
- Новая система статусов
Она отражает результат агентных действий, а не HTTP semantics
- Транспорт
Приоритет отдается QUIC (стримы, low latency), fallback на TCP/TLS

Основная идея в том, чтобы сделать трафик агентов наблюдаемым и управляемым на уровне сети

2️⃣ ATP (Agent Transfer Protocol, Li et al.)
Независимая инициатива, с похожими целями:
- Специализированные примитивы для agent workflows
- Поддержка stateful взаимодействия
- Фокус на interoperability между агентами разных систем

У протоколов есть как похожие черты, так и отличия

Общие черты
- Отказ от HTTP как универсального слоя
- Intent-driven коммуникация
- Встроенные identity/authority модели
- Подготовка к high-frequency agent traffic

Различия
- AGTP - более "операционный" (методы, статусы, observability) и уже предлагает более конкретную структуру протокола
- ATP - более "концептуальный" (interoperability и primitives)

Но мало ли сколько предложений о новых протоколах бывает. Конкретно эти интересны тем, что мы приходим к разделению интернета на два слоя
1. Human web (HTTP, UI, REST)
2. Agent web (AGTP/ATP, intent, delegation)
А это влияет на остальные моменты, например
- API gateway будут понимать agent traffic нативно
- В observability стеке появятся метрики уровня intent
- В security identity агентов станет first-class
- А SDK перестанут быть "обёртками над REST"

Если эти протоколы взлетят, нас ждёт
- Отдельные agent-native API gateways
- Маршрутизация по intent, а не по URL
- Policy engines на уровне агентных действий
- Встроенная экономика взаимодействия агентов (оплата, квоты, ...)
- Тесная интеграция с DNS и service discovery

Нам как архитекторам придется думать не только про API, но и про семантику действий. Архитектуры будут смещаться от request/response к workflow orchestration. Observability нужно будет строить вокруг intent и outcome, а не только latency, ну и конечно нам придется построить новый платформенный слой под агентов:)

#AI #Architecture #DistributedSystems #Network #SystemDesign #Software