A2A: как ИИ-агенты обмениваются задачами — открытый протокол, в котором клиентский агент формулирует задачу, а удалённый агент выполняет её и возвращает артефакт. Внутреннее устройство исполнителя остаётся скрытым: клиент видит Agent Card, идентификатор задачи, сообщения и готовый результат.
Модель, агент и протокол: где проходит граница
Слово «агент» в разговорах о нейросетях означает три разные вещи, и путаница между ними ломает понимание A2A. Модель — это генератор текста или изображения, который получает запрос и выдаёт ответ. Агент — программа, которая вокруг модели держит план, память, инструменты и цикл повторных попыток. Протокол — соглашение о том, как два агента разговаривают между собой.
Документация проекта на a2a-protocol.org описывает A2A как открытый стандарт связи и совместной работы между ИИ-агентами. Агенты собираются на разных фреймворках и у разных поставщиков, и протокол даёт им общий язык. В той же документации перечислены участники обмена: пользователь, клиентский агент и удалённый агент. Пользователь ставит цель, клиентский агент действует от его имени, удалённый агент принимает запросы, обрабатывает задачи и возвращает результаты или обновления статуса.
Ключевое свойство удалённого агента — непрозрачность. Для клиента он остаётся чёрным ящиком: внутренняя логика, память и инструменты скрыты. Это позволяет соединять системы, которые не делятся исходниками и данными. Документация проекта отдельно перечисляет, чем A2A не является: это не набор для разработки агентов вроде LangGraph, CrewAI или ADK, не протокол вызова подагентов и инструментов, не замена MCP и не мессенджер для людей. A2A работает как слой связи между агентами, построенными на любом из этих инструментов.
MCP занимает соседнюю позицию. Документация проекта описывает MCP как протокол связи агента с инструментами и ресурсами, а A2A — как протокол связи агента с агентом. В примере с автомастерской менеджер обсуждает поломку с клиентом, механик через MCP обращается к сканеру ошибок и базе ремонтных процедур, а через A2A заказывает деталь у агента поставщика. Один агент получает глубину, система в целом — охват.
| Сущность | Что описывает | Кто её создаёт |
|---|---|---|
| Модель | Генерацию ответа на запрос | Поставщик модели |
| Агент | План, память, инструменты, цикл работы | Разработчик агента |
| Протокол A2A | Формат обмена задачами между агентами | Сообщество стандарта |
| MCP | Подключение инструментов к одному агенту | Сообщество стандарта |
Что клиент ищет в Agent Card
Agent Card — это JSON-документ, который удалённый агент публикует о себе. Документация проекта называет его цифровой визиткой: клиент читает карточку, чтобы решить, подходит ли агент для задачи, как строить запрос и как безопасно общаться. В карточке перечислены идентичность агента, адрес сервиса, возможности A2A, требования аутентификации и навыки.
Разбор карточки идёт по четырём вопросам. Первый: какие навыки заявлены. Навык «составление программы вебинара» подходит для учебного примера ниже, навык «проверка кода» — нет. Второй: какой адрес у сервиса. Клиент обращается по endpoint, указанному в карточке. Третий: какие условия доступа. Требования аутентификации объявлены в карточке, а учётные данные вроде токенов OAuth или API-ключей передаются в HTTP-заголовках, отдельно от сообщений протокола. Четвёртый: какие расширения поддерживает агент — документация проекта упоминает, что пользовательские расширения протокола объявляются в AgentCard.
Практический порядок чтения карточки выглядит так:
- Сверьте навык с формулировкой задачи.
- Проверьте endpoint и доступность сервиса.
- Прочитайте требования аутентификации и подготовьте заголовки.
- Проверьте заявленные расширения и форматы контента.
- Только после этого формируйте задачу.
Ошибка новичка — считать карточку обещанием результата. Карточка описывает способность агента, и в учебной матрице она прямо отделена от программы вебинара: карточка говорит, что агент умеет составлять программы, а сама программа появляется позже как артефакт. Исполнитель может вернуть отказ даже при заявленном навыке. Клиент обрабатывает такой исход по правилам протокола.
Задача с входами и ожидаемым результатом
Задача в A2A — это единица работы с уникальным идентификатором и определённым жизненным циклом. Документация проекта описывает её как stateful-единицу, которая инициируется агентом и позволяет отслеживать долгие операции, вести многошаговый диалог и совместную работу. Ответ удалённого агента приходит либо новой задачей, когда нужна длительная операция, либо сообщением, когда агент отвечает сразу.
Учебный пример: пользователь просит подготовить программу вебинара для новичков на 45 минут с 10 минутами вопросов. Клиентский агент выбирает удалённого агента по навыку составления программ. Задача получает идентификатор T-17 и содержит входы: аудиторию, общий лимит 45 минут и блок вопросов на 10 минут. Эти значения условны и служат учебным входом.
Что должно лежать во входах задачи:
- цель в формулировке пользователя;
- ограничения, которые проверяются потом;
- ожидаемый формат результата;
- контекст, нужный исполнителю.
Формат результата стоит назвать заранее. Если клиенту нужен документ с разбивкой по минутам, это часть условия задачи. Тогда результат можно проверить по сумме минут и составу блоков. Идентификаторы и имена в примере иллюстративны и не являются схемой JSON или выполненным сетевым запросом.
Идентичность задачи во время уточнения
Задача T-17 не завершается сразу. Удалённый агент обнаруживает, что темы вебинара во входах нет, и задаёт вопрос. Документация проекта описывает сообщение как один ход общения между клиентом и агентом: у него есть роль «user» или «agent», уникальный messageId и один или несколько объектов Part. Сообщение передаёт инструкции, контекст, вопросы, ответы или обновления статуса.
Ключевое правило: вопрос агента не создаёт новую задачу. T-17 остаётся той же задачей с тем же идентификатором, а уточнение идёт внутри неё. Пользователь отвечает «Автоматизация почты», и этот ответ присоединяется к контексту T-17. Документация проекта упоминает contextId — серверный идентификатор, который группирует связанные задачи и переносит контекст через серию взаимодействий.
Практический смысл идентичности в том, что клиент может вернуться к задаче позже. Если соединение оборвалось, клиент запрашивает состояние T-17 и продолжает с того места, где остановился. Для новой связанной задачи контекст можно перенести через общий contextId; клиенту нужно сохранить аудиторию, лимит 45 минут и блок вопросов.
| Событие | Идентификатор задачи | Статус |
|---|---|---|
| Задача создана с входами | T-17 | В работе |
| Агент спрашивает тему | T-17 | Ждёт уточнения |
| Пользователь отвечает | T-17 | В работе |
| Артефакт готов | T-17 | Завершена |
Сообщение о ходе работы и готовый артефакт
Эти две сущности различаются по назначению. Сообщение передаёт ход общения: вопрос, ответ, пояснение, обновление статуса. Артефакт — материальный результат работы: документ, изображение, структурированные данные. Документация проекта подчёркивает, что артефакты служат настоящими результатами работы, у них есть уникальный artifactId, читаемое имя и один или несколько Part.
В учебном примере сообщение «работаю над программой» не является артефактом. Артефактом становится program-v1 — программа с разбивкой: введение 5 минут, демонстрация 15, самостоятельный разбор 10, разбор ошибок 5, вопросы 10. Сумма равна 45 минутам, блок вопросов равен 10 минутам.
Part — контейнер содержимого внутри сообщений и артефактов. Документация проекта перечисляет четыре варианта содержимого: текст, встроенные байты файла, ссылка на внешний файл и структурированные данные JSON. Дополнительно Part может нести mediaType, имя файла и карту метаданных. Такая конструкция делает протокол независимым от модальности: в одном артефакте могут лежать текст и таблица.
Практический вывод для читателя: при приёмке результата сверяйте артефакт с исходной задачей. Сообщения объясняют, что происходит. Артефакт показывает, что получилось.
Polling, stream и push: три способа ждать
Документация проекта перечисляет три механизма взаимодействия, и каждый подходит своему сценарию. Обязательства использовать все три нет: выбирается один под характер задачи.
Request/Response с опросом: клиент отправляет запрос, сервер отвечает, а для долгих задач клиент периодически опрашивает сервер об обновлениях. Простой вариант, который легко отлаживать.
Потоковая передача через Server-Sent Events: клиент открывает поток по открытому HTTP-соединению и получает результаты или обновления статуса по мере появления. Подходит, когда пользователю полезно видеть прогресс.
Push-уведомления: сервер вызывает вебхук, который предоставил клиент, при значимом обновлении задачи. Документация проекта рекомендует этот вариант для очень долгих задач и для клиентов, которые отключаются от сети.
| Механизм | Кто инициирует обновление | Когда уместен |
|---|---|---|
| Опрос | Клиент по таймеру | Короткие задачи, простая отладка |
| SSE-поток | Сервер в открытом соединении | Нужен прогресс в реальном времени |
| Push на вебхук | Сервер при событии | Долгие задачи, отключённый клиент |
Практический порядок выбора: начните с опроса, пока задача укладывается в минуты. Переходите на поток, когда пользователь ждёт результат на экране. Добавляйте вебхук, когда задача живёт часами и клиент может закрыться. Смешивать три механизма в одном сценарии без нужды усложняет отладку.
Проверка результата по условиям задачи
Статус «завершена» сообщает, что исполнитель закончил работу. Соответствие результата условиям задачи проверяется отдельно. В учебной матрице этот шаг выделен явно: program-v1 соответствует лимитам 45 и 10 минут, а вариант с 50 минутами получает FAIL, даже если удалённый агент сообщил о завершении.
Порядок проверки:
- Извлеките из задачи исходные ограничения.
- Посчитайте фактические значения в артефакте.
- Сравните каждое ограничение с фактом.
- Зафиксируйте расхождения с указанием, какое условие нарушено.
- Верните задачу на доработку с конкретным требованием.
Сумма блоков должна равняться 45 минутам, включая 10 минут вопросов. Отклонение требует доработки независимо от статуса задачи.
Ошибка новичка — принимать статус за результат. Статус описывает состояние задачи, артефакт описывает продукт. Проверка идёт по артефакту и условиям.
Отказ и неполный результат при нехватке данных
Когда входам не хватает данных, удалённый агент может вернуть отказ или неполный результат. Документация проекта описывает ответ агента как новую задачу или сообщение; вопрос о недостающих данных приходит именно сообщением, и задача продолжает жить. В учебном примере агент спрашивает тему вебинара, потому что без темы программа не собирается.
Практические варианты обработки нехватки данных:
- уточнить у пользователя и продолжить ту же задачу;
- вернуть частичный артефакт с явно помеченными пробелами;
- отказаться от задачи с указанием, какого входа не хватает.
Промпт для клиентского агента, который формулирует задачу и проверяет результат:
Ты — клиентский агент. Сформируй задачу для удалённого агента по теме [ваша тема].
Входы: [аудитория], [общий лимит минут], [блок вопросов минут], [формат результата].
Требуй артефакт с разбивкой по блокам и суммой минут.
Если удалённый агент запрашивает уточнение, сохрани идентификатор задачи и передай ответ пользователя.
После получения артефакта сверь сумму минут и состав блоков с условиями задачи.
При расхождении верни задачу на доработку с указанием нарушенного условия.
Замените тему, аудиторию, лимиты и формат результата в квадратных скобках.
Отказ при нехватке данных — нормальный исход. Клиент получает точное указание, какого входа не хватает, и может запросить его у пользователя. Хуже, когда исполнитель додумывает недостающее и возвращает артефакт, который не проходит проверку по условиям.
Частые вопросы
Что такое A2A простыми словами?
Открытый протокол, по которому один ИИ-агент передаёт задачу другому и получает результат. Клиентский агент формулирует задачу, удалённый выполняет её и возвращает артефакт. Внутреннее устройство исполнителя для клиента скрыто.
Что клиент ищет в Agent Card?
Навыки агента, адрес сервиса, требования аутентификации и заявленные расширения. Документация проекта описывает карточку как JSON-документ с идентичностью, endpoint, возможностями и навыками. По этим данным клиент решает, подходит ли агент для задачи.
Как устроен жизненный цикл задачи в A2A?
Задача получает уникальный идентификатор и живёт до завершения. Внутри неё идут сообщения: вопросы, ответы, обновления статуса. Результат приходит артефактом. Уточнение не создаёт новую задачу, а продолжает текущую.
Чем A2A отличается от MCP?
MCP подключает инструменты и ресурсы к одному агенту. A2A связывает агентов между собой. Документация проекта описывает их как дополняющие: MCP даёт агенту глубину, A2A даёт системе охват.
Что делать, если результат не соответствует условиям задачи?
Сверить артефакт с исходными ограничениями и вернуть задачу на доработку. Статус завершения описывает состояние работы, а соответствие проверяется по артефакту. В учебном примере вариант с 50 минутами не проходит проверку при лимите 45 минут.