Книжный куб

Транспортные протоколы для 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