MCP vs A2A vs UCP vs AP2 vs A2UI: разбор стека протоколов агентов

Протоколы для ИИ-агентов стремительно множатся: MCP, A2A, UCP, AP2, A2UI и смежные стандарты все чаще появляются на одних и тех же архитектурных схемах. Их нередко описывают как конкурирующие протоколы. На практике большинство из них решает различные задачи интероперабельности на разных уровнях взаимодействия. Правильный вопрос заключается не в том, «Какой протокол победит?», а в том, «Какую связь в системе необходимо стандартизировать?»

Главная ошибка: сравнение протоколов, находящихся на разных уровнях взаимодействия

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

В руководстве для разработчиков от Google за 2026 год MCP, A2A, UCP, AP2, A2UI и связанные с ними протоколы пользовательского интерфейса прямо представлены как стек взаимодополняющих стандартов. В одном и том же примере рабочего процесса несколько из них могут использоваться совместно: инструменты для учета запасов, удаленные агенты для поставщиков, коммерция для оформления заказа, авторизация платежей для списания средств и протоколы пользовательского интерфейса для взаимодействия.

Стек зон ответственности протоколов

1. MCP: подключение агента к возможностям

Model Context Protocol — это открытый стандарт для подключения ИИ-приложений к внешним системам, где находятся инструменты, данные и переиспользуемые ресурсы. Сервер предоставляет возможности; MCP-хост подключается к этому серверу и делает эти возможности доступными модели или приложению.

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

Используйте MCP, когда

• ИИ-приложению требуется стандартизированный доступ к инструментам или API.
• Вам нужно, чтобы один сервер возможностей работал с несколькими совместимыми ИИ-хостами.
• Вам необходим структурированный доступ к данным или ресурсам без жесткого кодирования каждой интеграции в каждого агента.
• Внешняя система является поставщиком возможностей, а не автономным одноранговым агентом.

2. A2A: подключение независимых агентов

Agent2Agent (A2A) разработан для взаимодействия между независимыми, потенциально непрозрачными агентскими системами. Его текущая спецификация v1.0 сосредоточена на обнаружении возможностей, обмене сообщениями, задачах, артефактах, мультимодальном контенте и длительном сотрудничестве без необходимости раскрывать внутренние инструменты, память или реализацию одного агента другому.

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

A2A v1.0 также стандартизирует согласование версий и поддерживает различные привязки вокруг общей модели данных. Опубликованный механизм Agent Card предоставляет клиентам стандартную точку обнаружения возможностей агента, поддерживаемых протоколов, требований к аутентификации и навыков.

Используйте A2A, когда

• Одному автономному агенту необходимо делегировать работу другому автономному агенту.
• Удаленная система должна оставаться непрозрачной за контрактом возможностей.
• Задачи могут быть длительными, асинхронными или требовать участия человека (human-in-the-loop).
• Агенты построены на базе различных фреймворков, языков, решений разных вендоров или принадлежат разным организациям.

MCP против A2A: вертикальная интеграция против горизонтального сотрудничества

Сам проект A2A сейчас описывает это различие как горизонтальное против вертикального: MCP подключает агентов к внутренним инструментам и базам данных, тогда как A2A обеспечивает одноранговое (peer-to-peer) сотрудничество между агентскими системами.

3. UCP: стандартизация агентской коммерции

Universal Commerce Protocol не является универсальным протоколом для агентов общего назначения. Он стандартизирует коммерческие сценарии между клиентскими интерфейсами, продавцами и платежными провайдерами. Реализация от Google уже поддерживает такие возможности, как создание корзины, оформление заказа, исполнение и жизненный цикл заказа с помощью версионированных профилей и API.

Продавец может опубликовать UCP-профиль по адресу /.well-known/ucp с описанием сервисов, версий протокола и возможностей. Этот паттерн обнаружения важен, поскольку агентскому интерфейсу не должен требоваться индивидуальный контракт на оформление заказа для каждого продавца.

UCP также намеренно сделан компонуемым. В техническом обзоре Google говорится, что он может интегрироваться через API, A2A и MCP, а также совместим с AP2 для авторизации платежей агентами.

Используйте UCP, когда

• Рабочий процесс включает товары продавца, корзины, оформление заказа, исполнение или жизненный цикл заказа.
• Вы создаете интерфейс продавца, который должен работать с агентскими сценариями покупок.
• Интеграции требуется семантика, специфичная для электронной коммерции, а не стандартные вызовы инструментов.
• Вам нужен совместимый коммерческий контракт, который может сосуществовать с MCP, A2A и платежными протоколами.

4. AP2: подтверждение права агента совершать траты

Агентская коммерция порождает проблему, с которой обычные сценарии оформления заказа не сталкивались напрямую: агент может совершать транзакции без непосредственного нажатия финальной кнопки человеком в реальном времени. Agent Payments Protocol (AP2) решает вопросы авторизации, подлинности и подотчетности для платежей, инициируемых агентами.

В руководстве по протоколу Google за 2026 год AP2 описывается через типизированные мандаты, фиксирующие намерения пользователя, ограничения на расходы и конкретную авторизуемую транзакцию. AP2 может работать как расширение вместе с UCP: UCP описывает коммерческую транзакцию, а AP2 подтверждает полномочия агента на проведение платежа.

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

UCP против AP2: семантика транзакций против полномочий

5. A2UI: позвольте агентам описывать интерфейсы, не отдавая им контроль над вашим фронтендом

Agent-to-User Interface (A2UI) решает задачу другой границы: как удаленный или локальный агент передает насыщенный интерактивный интерфейс хост-приложению. Вместо отправки произвольного HTML, CSS и JavaScript, A2UI использует декларативные данные, которые хост отрисовывает через собственный доверенный каталог компонентов.

Это сохраняет дизайн-систему и модель безопасности хост-приложения, позволяя агенту запрашивать динамические интерфейсы. A2UI v0.9 особо акцентирует внимание на независимых от фреймворков намерениях UI и потоковых обновлениях для веба, мобильных и других клиентов.

Последующая работа Google над связкой A2UI + MCP Apps также демонстрирует, что эти модели UI не обязательно исключают друг друга. Декларативный нативный UI и более богатый опыт встроенных приложений могут сосуществовать в зависимости от задачи.

Используйте A2UI, когда

• Удаленному агенту необходимо запрашивать формы, карточки, элементы управления или другой интерактивный UI.
• Хост должен сохранять свои нативные компоненты, стилизацию и периметр безопасности.
• Вы не хотите, чтобы удаленные агенты передавали произвольный исполняемый код фронтенда.
• Одно и то же определенное агентом намерение UI должно работать в различных клиентских фреймворках.

Тест для выбора протокола

Отталкивайтесь не от аббревиатуры. Отталкивайтесь от взаимодействия, требующего интероперабельности.

Реалистичный мультипротокольный рабочий процесс

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

Универсальный протокол кажется более простым решением ровно до тех пор, пока ему не потребуется описывать семантику каждой предметной области. Обнаружение инструментов, длительное взаимодействие агентов, оформление заказов, авторизация платежей и нативный UI имеют совершенно разные требования к жизненному циклу, безопасности и корректности.

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

Таким образом, архитектурная задача смещается с вопроса «какой протокол победит?» к вопросу о том, насколько органично протоколы сочетаются между собой без дублирования семантики идентификации, авторизации, состояния и аудита.

Композиция протоколов создает новые сценарии сбоев

Выбор протокола не заменяет архитектуру приложения

Открытые стандарты снижают связность интеграции, но они не определяют вашу доменную модель, политику авторизации, источник истины, стратегию повторных попыток или критерии приемки. Инструмент MCP все еще может предоставить не ту возможность. Агент A2A все еще может вернуть некорректный артефакт. Оформление заказа UCP все еще может содержать устаревшие данные продавца. Мандат AP2 все еще может быть неверно применен логикой приложения.

Относитесь к протоколам как к контрактам между независимо развивающимися компонентами. Сохраняйте доменную истину и определяющие политики на уровне приложения, которому они принадлежат, а затем используйте протоколы для обеспечения интероперабельности границ.

Что может изменить этот расклад?

Стек изменится, если протоколы сойдутся воедино, один стандарт формально поглотит другой или поставщики стандартизируют общий уровень идентификации и авторизации для нескольких границ. UCP уже демонстрирует композицию, поддерживая API, A2A и MCP, а также интегрируясь с AP2 вместо их вытеснения.

Ответ также зависит от масштаба приложения. Небольшому внутреннему агенту может потребоваться только MCP. Мультикорпоративному рабочему процессу может понадобиться A2A. Продавцу может потребоваться UCP без A2UI. Делегированному агенту по закупкам могут потребоваться все эти стандарты. Используйте минимальный набор протоколов, который отражает реальные границы, не упрощая доменную семантику.

Ограничения

Обсуждаемые здесь протоколы находятся на разных уровнях зрелости и имеют разные модели управления. A2A достиг стабильной спецификации версии 1.0, тогда как другие стандарты продолжают быстро развиваться. Внедрение в экосистему также распределено неравномерно среди поставщиков и фреймворков.

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

Заключение

MCP, A2A, UCP, AP2 и A2UI становятся более понятными, если рассматривать их как протоколы для различных типов взаимодействия, а не как пять конкурирующих попыток стандартизировать «агентов».

MCP открывает доступ к возможностям. A2A координирует независимых агентов. UCP дает коммерции собственный машиночитаемый контракт. AP2 добавляет верифицируемые полномочия для платежей. A2UI предоставляет агентам безопасный декларативный способ взаимодействия с пользовательскими интерфейсами. Таким образом, формирующийся агентный веб не заменяет протоколы искусственным интеллектом — он создает новый стек протоколов вокруг ИИ.

Часто задаваемые вопросы

Глоссарий

Основные источники и материалы для дальнейшего чтения