[3/x] Model Context Protocol (MCP) и Agent-to-Agent (A2A) - Архитектура A2A (Рубрика AI)

Продолжая рассказ про протоколы (1 и 2), расскажу про то, как устроен A2A протокол от Google. Архитектура A2A также следует модели клиент-сервер, но на уровне агентов. Здесь A2A-клиентом выступает один агент, инициирующий задачу, а A2A-сервером – другой агент, способный эту задачу выполнить. В отличие от MCP, где сервер – просто коннектор к данным, в A2A оба конца коммуникации – интеллектуальные агенты с потенциалом автономного поведения. Протокол A2A определяет стандарт, как один агент может обнаружить другого, узнать, что тот “умеет”, и далее передать ему задачу на выполнение с последующим получением результата.

Технически A2A основан на HTTP и JSON-RPC, дополняемых протоколом событий SSE для асинхронного обмена сообщениями и потоковых обновлений состояния. Каждый агент, работающий по A2A, экспонирует HTTP-эндпойнт (например, небольшой веб-сервер) со стандартным API A2A. Чтобы агенты могли находить друг друга и правильно обращаться, A2A вводит понятие Agent Card – своего рода паспорт агента. Agent Card – это JSON-документ, публикуемый агентом, где указаны его имя, адрес (URL для подключения), версия, а главное – перечень его навыков/умений (Agent Skills) с описаниями того, какие задачи он способен выполнять. Другие агенты могут получить этот «карт-бланш» и понять, к какому агенту за чем обращаться.

Обмен задачами в A2A происходит через Task – стандартизованное описание задания, которое клиент-агент формирует для удалённого агента. Задача включает контекст (например, запрос пользователя), требуемое действие и формат ожидаемого ответа. Агенты обмениваются сообщениями (Messages) в процессе решения задачи – это могут быть шаги выполнения, уточняющие вопросы, промежуточные результаты. В итоговом ответе могут передаваться так называемые Artifacts – артефакты, например файлы, изображения или другие результаты работы агента. Протокол поддерживает потоковое взаимодействие: если задача длительная, удалённый агент может слать промежуточные обновления (статус выполнения, частичные результаты) через SSE-поток, пока задача не будет завершена.

Ключевые технические принципы A2A, заявленные Google и партнёрами: 1. Опора на существующие стандарты: не изобретать новый транспорт, а использовать HTTP для совместимости с любыми веб-технологиями, JSON-RPC для структурированных вызовов, SSE для стриминга. Это облегчает интеграцию A2A в существующую ИТ-инфраструктуру предприятий. 2. Безопасность по умолчанию: протокол изначально разработан с учётом корпоративных требований безопасности – поддерживает аутентификацию и авторизацию агентов по аналогии со схемами безопасности OpenAPI. Каждый агент может требовать проверку ключа или токена перед приёмом задач, устанавливать разрешения на выполняемые действия и т.п., чтобы предотвратить несанкционированный доступ. 3. Поддержка длительных задач: архитектура учитывает, что агентские взаимодействия могут занимать значительное время (часы или дни, если в цикле есть человек). Благодаря событийной модели, A2A позволяет агентам поддерживать диалог о ходе задачи, уведомлять о промежуточном прогрессе, ожидать внешних действий и затем продолжать работу. 4. Мультимодальность: A2A не ограничивается текстом – предусмотрена передача аудио- и видеопотоков, если агенты работают с этими типами данных. Это важно, например, для агентов, обрабатывающих голосовые запросы или видеоданные (они тоже могут сотрудничать через единый протокол).

Архитектурно A2A создает надстройку над отдельными агентами, превращая их в единый оркестр. Например, если пользовательскому ассистенту (агенту) поступает сложный запрос – спланировать деловую поездку – он может через A2A делегировать подзадачи специализированным агентам: один агент бронирует билеты и отели, другой – обрабатывает оплату, третий – проверяет соответствие поездки корпоративной политике

#AI #Engineering #Architecture #DistributedSystems #ML #Software