Протокол A2A (Agent2Agent) — это открытый стандарт обмена сообщениями между ИИ‑агентами, который задает единый формат описания агентов, постановки задач и передачи результатов. Он позволяет агентам из разных фреймворков и от разных поставщиков взаимодействовать друг с другом через согласованный API, не раскрывая внутреннюю реализацию.
Содержание статьи
Краткое определение протокола A2A
Agent2Agent — это протокол поверх HTTP, JSON‑RPC и связанных веб‑технологий, который описывает, как один агент может обнаружить другого, аутентифицироваться и вести диалог в виде задач, сообщений и артефактов. Его цель — обеспечить интероперабельность мультиагентных систем и разделить «ум» агента и транспортную прослойку.
В отличие от закрытых схем общения внутри отдельных фреймворков, A2A выступает как общий «слой сообщений», согласованный на уровне открытой спецификации. Стандарт находится под управлением Linux Foundation как открытый проект, а изначальную версию спецификации инициировала команда Google совместно с технологическими партнерами в экосистеме Google Cloud.
Зачем нужен протокол Agent2Agent
Протокол A2A нужен для того, чтобы разные ИИ‑агенты могли обмениваться задачами и результатами без жесткой привязки к одному вендору или одному стеку разработки. Он решает задачу «общего языка» для мультиагентных систем.
До появления A2A большинство решений для оркестрации агентов работали внутри собственных границ: один фреймворк — своя модель диалога, свои сообщения, свои форматы. В результате агент из одной системы не мог «напрямую» взаимодействовать с агентом из другой, требовался кастомный клей-код и ручные интеграции.
Agent2Agent вводит общие сущности — карты агентов, задачи, сообщения, артефакты — и фиксирует, как именно они передаются по сети. Это уменьшает количество точечных интеграций и делает архитектуру ближе к микросервисной: агент становится самостоятельным сервисом с описанным интерфейсом, который другие агенты могут вызывать по общим правилам.
Чем A2A отличается от MCP
Model Context Protocol (MCP) стандартизирует, как ИИ‑модели и приложения обращаются к внешним сервисам и данным, а Agent2Agent описывает, как агенты общаются между собой. MCP — про подключения и инструменты, A2A — про координацию и взаимодействие агентов.
MCP, предложенный Anthropic, фокусируется на том, чтобы унифицировать доступ к API, базам данных, файловым хранилищам и другим источникам контекста. Приложение или агент через MCP вызывает внешнюю функцию, получает данные, подготавливает контекст для модели и так далее. Важно, что MCP описывает взаимодействие «приложение/агент → сервис/инструмент».
Agent2Agent, напротив, описывает сценарий «агент ↔ агент». Один агент может поручить задачу другому, получить ход выполнения, дождаться артефактов и продолжить уже на своей стороне. В архитектуре реальных систем эти два протокола обычно дополняют друг друга: агент с помощью MCP ходит в данные и инструменты, а по A2A общается с другими специализированными агентами.
Основные компоненты архитектуры A2A
Спецификация Agent2Agent описывает набор базовых сущностей: клиентский агент, удаленный агент, карту агента, задачу, сообщение, артефакт и часть (part). Вместе они образуют общий формат, который понимают обе стороны соединения.
Клиентский агент инициирует взаимодействие, удаленный агент принимает запрос, карта агента помогает их найти и описывает возможности, а задача и сообщения фиксируют процесс общения. Артефакты и части, в свою очередь, описывают сам контент, который агенты создают и передают.
A2A‑клиент (client agent)
A2A‑клиент — это агент, сервис или приложение, которое инициирует запрос и делегирует выполнение работы удаленному агенту по протоколу Agent2Agent. Он формирует задачу, отправляет ее через описанный HTTP‑эндпоинт и обрабатывает ответы.
Роль клиента может выполнять как автономный ИИ‑агент, так и обычное приложение, которое пользуется возможностями удаленных агентов. Для протокола важен не способ реализации, а то, что именно эта сторона создает задачи и управляет их жизненным циклом с точки зрения «заказчика».
A2A‑сервер (remote agent)
A2A‑сервер — это удаленный агент, который принимает задачи, обрабатывает их и возвращает статусы, сообщения и артефакты. Он публикует HTTP‑эндпоинт, совместимый со спецификацией A2A, и следует формату JSON‑RPC 2.0 для обмена данными.
Серверная сторона может обслуживать широкий диапазон задач: от простых одношаговых операций до продолжительных процессов с участием людей и других систем. При этом для клиента все представлено через единый интерфейс: задача, сообщения с ролями и артефакты в оговоренном формате.
Карта агента (Agent card)
Карта агента — это JSON‑документ, доступный по URL, который описывает метаданные и интерфейс агента: имя, описание, версию, адрес сервиса, поддерживаемые типы данных и требования к аутентификации. По сути, это формализованная визитка агента.
Карта агента напоминает «model card» для больших языковых моделей. Она помогает другим агентам и системам автоматически обнаруживать сервис, понимать, что он умеет, и как с ним корректно работать. Через карту видно, с какими модальностями агент готов работать (текст, файлы, структурированные данные) и какие схемы безопасности он поддерживает.
Задача (Task)
Задача в A2A — это единица работы, которой удаленный агент должен заняться. У нее есть уникальный идентификатор и набор состояний, через которые она проходит: отправлена, в работе, требуется ввод, завершена, завершилась ошибкой.
Разделение процесса на задачи особенно важно для многошаговых сценариев и долгих вычислений. Клиентский агент видит четкий жизненный цикл: сначала постановка задачи, затем промежуточные сообщения и, наконец, артефакты и итоговый статус. Это позволяет отслеживать выполнение, восстанавливать связь после разрывов и управлять несколькими задачами параллельно.
Сообщение (Message)
Сообщение — базовая единица коммуникации между клиентским и удаленным агентом. Оно представляет собой один шаг диалога и содержит одну или несколько частей с содержимым.
Через сообщения передаются вопросы, ответы, инструкции, уточнения, статусные обновления. Каждое сообщение маркируется ролью: сообщения от сервера имеют агентскую роль, а сообщения от клиента — пользовательскую. Такая схема напоминает привычную структуру диалога «user / assistant» в LLM‑API, но тут она применяется для общения агентов друг с другом.
Артефакт (Artifact)
Артефакт — это осязаемый результат работы удаленного агента: документ, изображение, таблица, файл другого типа. Как и сообщение, артефакт может состоять из нескольких частей, а также может передаваться по частям в потоке.
Артефакты полезны для тех случаев, когда результат нельзя свести к простому текстовому ответу. Они позволяют отделить служебный диалог от финальных материалов, которые затем может обрабатывать другой агент или человек. Поддержка потоковой передачи делает возможной доставку крупных результатов или генерацию контента «на лету».
Часть (Part)
Часть (Part) — это отдельный фрагмент контента внутри сообщения или артефакта. Тип части определяется видом данных, которые она содержит: текст, файл или структурированный JSON.
TextPart описывает текстовые данные, FilePart ссылается на файл, а DataPart содержит структурированные данные в формате JSON. Такое разбиение дает возможность комбинировать разные форматы внутри одного сообщения или артефакта и обрабатывать их целенаправленно на стороне агента.
Как работает протокол A2A
Работа по протоколу A2A обычно проходит три этапа: обнаружение агента, аутентификация и собственно обмен задачами и сообщениями. Все это строится поверх HTTPS с использованием JSON‑RPC 2.0 и стандартных механизмов веб‑безопасности.
На первом шаге клиентский агент находит подходящий удаленный агент и получает его карту. Далее он проходит процедуру аутентификации согласно схеме, указанной в этой карте. После этого между агентами начинается диалог в терминах задач, сообщений и артефактов, при необходимости с асинхронными обновлениями и потоковой передачей.
Этап обнаружения (Discovery)
На этапе обнаружения клиентский агент получает запрос от пользователя или другого агента и должен подобрать подходящий удаленный агент. Для этого он ищет доступные сервисы и запрашивает их карты агентов по указанным URL.
Карта агента дает клиенту достаточно информации, чтобы сопоставить задачу и возможности сервиса: вид задач, поддерживаемые модальности, ограничения и т.п. После этого клиент выбирает одного или нескольких удаленных агентов, которые лучше всего подходят для выполнения конкретной задачи, и готовится к аутентификации.
Аутентификация и авторизация
Когда подходящий удаленный агент найден, клиентский агент проходит аутентификацию в соответствии с описанной в карте схемой безопасности. Agent2Agent полагается на схемы, совместимые с OpenAPI: API‑ключи, OAuth 2.0, OpenID Connect Discovery и другие варианты, описанные в спецификации.
После подтверждения подлинности клиента удаленный агент решает вопрос авторизации и доступа к своим функциям. Разделение аутентификации (доказательство личности) и авторизации (права доступа) позволяет применять корпоративные практики безопасности и централизованно управлять доступом к агентам.
Обмен задачами и сообщениями
Обмен начинается с отправки задачи от клиентского агента к выбранному удаленному агенту по HTTPS с использованием JSON‑RPC 2.0. Клиент формирует запрос с описанием задачи, необходимым контекстом и, при необходимости, начальными сообщениями.
Удаленный агент обрабатывает задачу и отправляет обратно сообщения с промежуточными статусами или запросами дополнительной информации. Когда работа завершена, он возвращает финальное сообщение и артефакты, связанные с задачей.
Для сложных задач протокол предусматривает: асинхронные уведомления через безопасный вебхук, потоковую передачу результатов и детальное управление жизненным циклом задачи. Клиентский агент может получать обновления даже в случае долгих расчетов или при временных разрывах соединения.
Механизмы асинхронных обновлений и стриминга
Agent2Agent поддерживает асинхронные уведомления и потоковую передачу данных, чтобы работать с долгими задачами и крупными результатами без блокировки соединения. Для этого применяются вебхуки и серверные события (SSE).
Если задача занимает часы или дни, клиентский агент может предоставить защищенный URL вебхука. Удаленный агент будет отправлять на него обновления статуса и части результатов по мере готовности. Такой подход позволяет не держать постоянное соединение и при этом не терять информацию о ходе выполнения.
Для длинных ответов и сценариев с частыми статусными обновлениями используется потоковая передача с помощью Server‑Sent Events. В этом режиме артефакты или сообщения приходят частями, а клиентский агент может отображать прогресс или обрабатывать данные по мере поступления.
Преимущества протокола A2A
Agent2Agent дает ряд преимуществ для построения реальных мультиагентных систем: защиту внутренней логики агентов, совместимость с существующей инфраструктурой и интеграцию с корпоративными политиками безопасности.
Ниже представлена краткая сводка ключевых выгод.
| Преимущество | Суть |
| Конфиденциальность | Агенты взаимодействуют как «черные ящики», не раскрывая внутренние данные и реализацию |
| Интеграция | Используются знакомые технологии: HTTP, JSON‑RPC, SSE |
| Безопасность | Поддержка корпоративных схем аутентификации и авторизации |
Конфиденциальность и изоляция логики
Протокол трактует ИИ‑агентов как отдельные сущности с четким интерфейсом, но без обязанности раскрывать внутреннюю структуру. Другие агенты видят только карту, список поддерживаемых возможностей и результаты в формате сообщений и артефактов.
Это упрощает совместную работу автономных агентов, которые принадлежат разным организациям или командам, и снижает риск утечки деталей реализации, внутренней памяти и специфики инструментов. В итоге бизнес‑логика и интеллектуальная собственность остаются внутри контура владельца агента.
Интеграция с существующим стеком
Agent2Agent базируется на уже распространенных протоколах и форматах: HTTP как транспорт, JSON‑RPC 2.0 для описания вызовов и ответов, SSE для стриминга. Это облегчает внедрение в инфраструктуру, где эти технологии уже используются.
Инженерам не требуется осваивать экзотические протоколы: достаточно применять знакомые инструменты для работы с веб‑API и добавить понимание специфических сущностей A2A — задач, сообщений, артефактов и карт агентов.
Безопасность и управление доступом
Протокол учитывает требования корпоративной безопасности: поддерживает разные схемы аутентификации и предоставляет удаленному агенту контроль над авторизацией. Это позволяет согласовать доступ к агентам с существующими политиками и системами управления учетными данными.
Благодаря опоре на схемы, совместимые с OpenAPI, организации могут использовать уже апробированные механизмы — от простых API‑ключей до полноценных OAuth‑ и OpenID‑потоков.
Развитие и перспективы A2A
Agent2Agent находится в стадии активного развития как открытый проект под управлением Linux Foundation, поэтому спецификация будет постепенно дополняться и уточняться. В планах эволюции обсуждаются расширения карт агентов, улучшение описания навыков и развитие поддержки динамичных интерфейсов.
Направления развития включают: более детальное описание схем авторизации и опциональных учетных данных в картах агентов, механизмы проверки неожиданных или пока не поддерживаемых навыков, а также расширение возможностей по согласованию пользовательского опыта в рамках задач — например, добавление аудио или видео по ходу диалога.
Дополнительно обсуждаются улучшения механизмов push‑уведомлений и надежности стриминга, чтобы крупные и долгие задачи обрабатывались устойчиво и предсказуемо. Спецификация, примеры кода и SDK на разных языках публикуются в открытых репозиториях и используются как основа для экспериментальных и продакшн‑систем с мультиагентной архитектурой.
