Эра мультиагентов? Как LangChain, только на стероидах: протокол Agent2Agent (A2A) от Google + MCP

---

🔥Подпишитесь, что бы не пропустить новые материалы🔥

📌 Telegram @TheWeeklyBrief — краткие обзоры и подкасты 📰🎧

📌 GitHub Pages — углублённые статьи, код и формулы 📝💻

---

0. Формализация

Предлагаю сначала дать определение понятию "протокол":

Формальное определение:

Протокол (в контексте компьютерных сетей и технологий) — это набор заранее определённых правил и стандартов, которые регулируют взаимодействие между устройствами, программами или системами. Он задаёт:

• формат данных (как информация структурирована и кодируется);

• последовательность действий (например, установка соединения, передача данных, завершение сеанса);

• методы обработки ошибок и гарантии доставки информации.

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

Примеры:

• HTTP — для передачи веб-страниц;

• TCP/IP — для разбивки и сборки данных в интернете;

• FTP — для обмена файлами.

Определение протокола в данном контексте:

Протокол — это стандартизированный набор правил, определяющий:

• Формат данных (например, JSON, HTTP-запросы);

• Порядок взаимодействия (обнаружение агентов, выполнение задач, обмен сообщениями);

• Безопасность (аутентификация, шифрование);

• Поддержку различных сценариев (долгие задачи, мультимодальность).

Оба протокола соответствуют этому определению, но решают разные задачи в экосистеме ИИ.

1. Предыстория

Рост числа агентов ИИ и проблемы взаимодействия

В последние годы в области искусственного интеллекта (ИИ) наблюдается бурное развитие и применение агентных технологий. Агенты ИИ разработаны как программные объекты, которые могут воспринимать окружающую среду, принимать обоснованные решения и выполнять задачи автономно. Они продемонстрировали большой потенциал во многих областях, включая обслуживание клиентов, автоматизацию предприятий и научные исследования, и рассматриваются как следующий рубеж в бизнес- операциях. Однако по мере увеличения числа агентов, созданных разными поставщиками и основанных на разных фреймворках, возникает серьезная проблема: совместимость.

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

Предыстория и цель соглашения A2A компании Google

Чтобы решить эту задачу, Google официально представила новый открытый протокол под названием Agent2Agent (A2A) на конференции Google Cloud Next '25, состоявшейся 9 апреля 2025 года. Основная цель протокола A2A — предоставить общий открытый стандарт для агентов ИИ, позволяющий им безопасно общаться, обмениваться информацией и координировать действия на разных платформах, фреймворках и у разных поставщиков4 . Google утверждает, что разработка протокола A2A основана на опыте компании в области масштабирования интеллектуальных систем внутри компании и призвана решать практические проблемы, возникающие при развертывании крупномасштабных многоагентных систем для клиентов.

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

2. Обзор протокола A2A

Базовое определение и основное ценностное предложение

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

Заслуживают внимания сроки появления и позиционирование на рынке протокола A2A. Он был запущен после того, как протокол контекста модели (MCP) от компании Anthropic (о нам мы писали тут https://habr.com/ru/articles/893482/) привлек значительное внимание рынка и был принят в отрасли. MCP в основном решает проблему того, как интеллектуальные агенты подключаются и используют внешние инструменты и источники данных. Его успех подтвердил ценность стандартизации в области интеллектуальных агентов. Компания Google внимательно следит за этой тенденцией и определяет следующую ключевую область, требующую стандартизации: взаимодействие между интеллектуальными агентами. Google явно позиционирует A2A как дополнение к MCP, а не как конкурента. Такая стратегия позиционирования позволяет A2A использовать существующий импульс MCP, снижая порог принятия нового протокола разработчиками и предприятиями и избегая сопротивления рынка, которое может возникнуть в результате прямой конкуренции.

Таким образом, Google может устанавливать стандарты в ключевой смежной области экосистемы агентов (межагентное взаимодействие) и тесно интегрировать ее со своей более широкой стратегией облачного ИИ (такой как Vertex AI, Agentspace, Agent Development Kit и т.д.), одновременно стимулируя внедрение на корпоративном рынке, подчеркивая сильную партнерскую экосистему. Это говорит о том, что Google пытается сформировать и направить развитие экосистемы агентов посредством, казалось бы, коллективного подхода (основанного на существующих стандартах), который может помочь направить взаимодействие агентов в облачную инфраструктуру или через нее.

3. Цели и основные принципы дизайна

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

Используйте возможности агентов: A2A предназначен для поддержки взаимодействия агентов естественным образом, даже если эти агенты не используют общую внутреннюю память, инструменты или контекст. Цель протокола — обеспечить реализацию настоящих сценариев многоагентного взаимодействия, а не просто рассматривать одного агента как простой «инструмент» или API-интерфейс для другого агента. Это контрастирует с простой интеграцией API или расширенными вызовами инструментов, которые часто ограничивают гибкость и глубину взаимодействия.

Создание на основе существующих стандартов: для упрощения интеграции и обучения, протокол A2A создан на основе широко используемых существующих технологических стандартов, включая HTTP, Server-Sent Events (SSE) и JSON-RPC. Выбор этих зрелых технологий означает, что предприятиям будет проще интегрировать A2A в существующую IT-инфраструктуру, которую они используют каждый день.

Безопасность по умолчанию: безопасность является краеугольным камнем архитектуры протокола A2A. Протокол предназначен для поддержки механизмов аутентификации и авторизации на уровне предприятия. На момент выпуска его модель безопасности была приведена в соответствие со схемой аутентификации OpenAPI, что обеспечивало совместимость с принятыми в отрасли стандартами безопасности.

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

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

В совокупности эти принципы проектирования воплощают прагматичную стратегию, направленную на широкое внедрение протокола в корпоративных средах. Выбор зрелых веб-стандартов (HTTP, JSON-RPC, SSE) и следование модели безопасности OpenAPI, значительно снижает технический порог и затраты предприятий на интеграцию. Вместо того чтобы вкладывать огромные ресурсы в изучение совершенно нового технологического стека или парадигмы, компании могут напрямую использовать существующую инфраструктуру и технический опыт.

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

4. Техническая архитектура и основные функции

Механизм коммуникации

Уровень связи протокола A2A построен на следующих широко используемых стандартах:

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

• SSE (Server-Sent Events): используется для реализации одностороннего потока данных в реальном времени от сервера к клиенту. Это особенно важно для длительных задач, поскольку позволяет удаленному агенту отправлять обновления статуса, уведомления или промежуточные результаты клиентскому агенту без необходимости постоянного опроса со стороны клиента. SSE позволяет удаленным агентам транслировать обновления клиентам по мере выполнения работы, что обеспечивает эффективность при длительных операциях. Для долгосрочных задач серверы, поддерживающие функцию потоковой передачи, могут использовать метод tasks/sendSubscribe, при котором клиент получает событийные уведомления, содержащие сообщения TaskStatusUpdateEvent или TaskArtifactUpdateEvent для отслеживания выполнения в режиме реального времени.

• JSON-RPC: облегченный протокол удаленного вызова процедур (RPC), использующий JSON в качестве формата данных. A2A использует JSON-RPC для стандартизации структурированных вызовов методов и ответов между агентами. A2A использует JSON-RPC 2.0 для обмена сообщениями, что обеспечивает простой, независимый от языка способ выполнения удаленных вызовов процедур с использованием формата данных JSON. Базовая структура запросов JSON-RPC включает поле method (строка, идентифицирующая операцию, например "tasks/send"), params (объект или массив с параметрами для метода) и id (уникальный идентификатор для корреляции запроса и ответа).

• Модель взаимодействия "клиент-сервер": A2A реализует чистую модель клиент-сервер, где клиентские и серверные агенты могут работать и размещаться удаленно. Конфигурация агента достаточно проста и требует только указания базового URL-адреса, а "Карточка агента" заботится об обмене контекстом. Этот подход упрощает интеграцию и обеспечивает гибкость при добавлении новых агентов в систему. Протокол чётко определяет типы взаимодействий: открытие (получение карточки агента), инициирование (отправка задачи), взаимодействие (при необходимости ввода) и завершение (когда задача достигает терминального состояния).

Формат и структура данных

Обмен данными в протоколе в основном осуществляется в формате JSON. Ключевые структуры данных включают в себя:

• Карточка агента (Agent Card): объект JSON, используемый агентом для публикации и описания своих возможностей, идентификационной информации и т.д. Это основа для реализации функции обнаружения интеллектуальных агентов. Способ, которым сервер A2A сообщает миру о своих возможностях, реализуется через "Карточку агента" в формате JSON. Карточка обычно размещается по стандартному пути /.well-known/agent.json, что делает процесс обнаружения предсказуемым, аналогично тому, как веб-браузеры находят файлы robots.txt. Карточка содержит информацию о возможностях агента, необходимых схемах аутентификации, поддерживаемых типах содержимого и конечных точках API.

• Задача (Task): основной объект, представляющий собой запрос на работу и являющийся центром общения между агентами. Протокол определяет механизм управления жизненным циклом задачи. Задача является центральной единицей работы. Клиент инициирует задачу, отправляя сообщение (tasks/send или tasks/sendSubscribe). Задачи имеют уникальные идентификаторы и проходят через различные состояния (submitted, working, input-required, completed, failed, canceled). Это позволяет отслеживать прогресс выполнения и обеспечивает асинхронное взаимодействие агентов.

• Сообщение (Message): представляет коммуникационные обороты между клиентом (role: "user") и агентом (role: "agent"). Сообщения содержат Части (Parts) и используются для передачи контекста, ответов, артефактов или инструкций пользователя. Структура сообщений позволяет агентам вести многошаговый диалог в рамках одной задачи и обмениваться различными типами контента.

• Артефакт (Artifact): выходные данные или результат, полученные после успешного выполнения задачи. Артефакты также содержат Части и могут представлять собой сгенерированные файлы, структурированные данные или другие результаты работы агента. Это стандартизированный способ возврата результатов выполнения задач.

• Часть (Part): автономный блок контента, включенный в сообщение, например текст, сгенерированные изображения и т.д. Часть может быть текстовой (TextPart), файловой (FilePart) с встроенными байтами или URI, или структурированным JSON (DataPart), например, для форм. Каждая часть имеет четкий тип контента, что позволяет клиенту и удаленному агенту согласовывать требуемый формат данных. Это механизм согласования пользовательского интерфейса, где каждое сообщение включает "части", являющиеся полностью сформированными фрагментами контента.

• Потоковая передача (Streaming): для длительных задач A2A предоставляет механизм получения обновлений в реальном времени. Для длительных задач серверы, поддерживающие возможность потоковой передачи, могут использовать tasks/sendSubscribe. Клиент получает события Server-Sent Events (SSE), содержащие сообщения TaskStatusUpdateEvent или TaskArtifactUpdateEvent, обеспечивающие ход выполнения в реальном времени.

• Push-уведомления (Push Notifications): серверы, поддерживающие функцию pushNotifications, могут проактивно отправлять обновления задач на URL-адрес вебхука, предоставленный клиентом через tasks/pushNotification/set. Эта функция позволяет клиентам получать обновления без необходимости постоянного опроса сервера.

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

Подробная спецификация JSON доступна в официальном репозитории GitHub.

Подробное объяснение основных функций

Полная реализация программного кода доступна в дирректории A2A.

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

1. Обнаружение возможностей (Capability Discovery):

• Механизм: это процесс, посредством которого агенты находят друг друга и узнают о возможностях друг друга. Агенты «транслируют» свои возможности с помощью Карточек агентов (Agent Card) в формате JSON. Как правило, эта карточка доступна по стандартному пути (/.well-known/agent.json), что делает обнаружение предсказуемым. Клиентские агенты (используя компоненты вроде A2ACardResolver )) могут получить эту карточку для обнаружения и выбора удаленного агента, который лучше всего подходит для выполнения конкретной задачи.

Пример получения карты агента клиентом:

# Из A2A/hosts/cli/__main__.py
card_resolver = A2ACardResolver(agent_url)
card = card_resolver.get_agent_card()
print("======= Agent Card ========")
print(card.model_dump_json(exclude_none=True))

# Класс A2ACardResolver использует httpx для GET запроса
# к self.base_url + "/" + self.agent_card_path
# и парсит JSON ответ в модель AgentCard
class A2ACardResolver:
    # ...
    def get_agent_card(self) -> AgentCard:
        with httpx.Client() as client:
            response = client.get(self.base_url + "/" + self.agent_card_path)
            response.raise_for_status()
            try:
                # Использует Pydantic модель AgentCard для парсинга
                return AgentCard(**response.json())
            except json.JSONDecodeError as e:
                raise A2AClientJSONError(str(e)) from e

• Детали: AgentCard содержит исчерпывающую информацию, определенную с помощью Pydantic моделей: идентификационные данные (name, description, url, provider, version), ключевые возможности (capabilities), требуемые схемы аутентификации (authentication), поддерживаемые по умолчанию и специфичные для навыков режимы ввода/вывода (inputModes, outputModes), а также список навыков (skills).

Пример структуры AgentCard и вложенных моделей:

# Из A2A/common/types.py
class AgentCapabilities(BaseModel):
    streaming: bool = False
    pushNotifications: bool = False
    stateTransitionHistory: bool = False

class AgentAuthentication(BaseModel):
    schemes: List[str]
    credentials: str | None = None

class AgentSkill(BaseModel):
    id: str
    name: str
    description: str | None = None
    # ... другие поля ...
    inputModes:  List[str] | None = None
    outputModes: List[str] | None = None

class AgentCard(BaseModel):
    name: str
    description: str | None = None
    url: str # URL для JSON-RPC эндпоинта
    provider: AgentProvider | None = None
    version: str
    capabilities: AgentCapabilities
    authentication: AgentAuthentication | None = None
    defaultInputModes:  List[str] = ["text"]
    defaultOutputModes: List[str] = ["text"]
    skills: List[AgentSkill]

• Значение: обнаружение возможностей позволяет клиенту динамически адаптировать стратегию взаимодействия. Например, клиент будет использовать метод tasks/sendSubscribe для потоковой передачи, только если AgentCard указывает streaming: true. Это имеет решающее значение для создания динамических и адаптивных многоагентных систем.

Пример использования возможностей в CLI клиенте:

# Из A2A/hosts/cli/__main__.py
async def completeTask(client: A2AClient, streaming, ...):
    # ...
    if streaming: # Значение получено из card.capabilities.streaming
        response_stream = client.send_task_streaming(payload)
        async for result in response_stream:
            print(f"stream event => {result.model_dump_json(exclude_none=True)}")
        taskResult = await client.get_task({"id": taskId})
    else:
        taskResult = await client.send_task(payload)
    # ...

2. Управление задачами (Task Management):

• Механизм: это основная модель взаимодействия протокола A2A. Все коммуникации вращаются вокруг создания, выполнения и завершения Задач (Task). Клиент инициирует задачу, отправляя запрос JSON-RPC (например, tasks/send или tasks/sendSubscribe).

Примеры JSON-RPC запросов для управления задачами:

# Из A2A/common/types.py
class SendTaskRequest(JSONRPCRequest):
    method: Literal["tasks/send"] = "tasks/send"
    params: TaskSendParams  # Содержит id, sessionId, message и др.

class SendTaskStreamingRequest(JSONRPCRequest):
    method: Literal["tasks/sendSubscribe"] = "tasks/sendSubscribe"
    params: TaskSendParams

class GetTaskRequest(JSONRPCRequest):
    method: Literal["tasks/get"] = "tasks/get"
    params: TaskQueryParams # Содержит id, historyLength

class CancelTaskRequest(JSONRPCRequest):
    method: Literal["tasks/cancel",] = "tasks/cancel"
    params: TaskIdParams    # Содержит id

• Детали: каждая Task имеет уникальный id, опциональный sessionId для группировки связанных задач, текущий status, список полученных artifacts и history сообщений. Протокол определяет четкие состояния жизненного цикла для задач через перечисление TaskState. Текущий статус задачи (TaskStatus) включает само состояние (state), опциональное сообщение от агента (message) и временную метку (timestamp).

Пример структуры Task, TaskStatus и TaskState:

# Из A2A/common/types.py
class TaskState(str, Enum):
    SUBMITTED = "submitted"
    WORKING = "working"
    INPUT_REQUIRED = "input-required"
    COMPLETED = "completed"
    CANCELED = "canceled"
    FAILED = "failed"
    UNKNOWN = "unknown"

class TaskStatus(BaseModel):
    state: TaskState
    message: Message | None = None # Сообщение от агента о статусе
    timestamp: datetime = Field(default_factory=datetime.now)
    # ... сериализатор для timestamp ...

class Task(BaseModel):
    id: str
    sessionId: str | None = None
    status: TaskStatus
    artifacts: List[Artifact] | None = None
    history:   List[Message]  | None = None # История сообщений user/agent
    metadata:  dict[str, Any] | None = None

Длительные задачи: протокол поддерживает как задачи, которые выполняются немедленно, так и длительные задачи. Для последних используются:

• SSE (Server-Sent Events): Метод tasks/sendSubscribe позволяет клиенту получать асинхронные обновления (TaskStatusUpdateEvent, TaskArtifactUpdateEvent) в реальном времени без необходимости опроса.

Пример обработки SSE клиентом и структура событий:

# Из A2A/common/client/client.py
async def send_task_streaming(
    self, payload: dict[str, Any]
) -> AsyncIterable[SendTaskStreamingResponse]:
    request = SendTaskStreamingRequest(params=payload)
    with httpx.Client(timeout=None) as client:
        with connect_sse( # Использует httpx_sse
            client, "POST", self.url, json=request.model_dump()
        ) as event_source:
            for sse in event_source.iter_sse():
                # Парсит данные события в SendTaskStreamingResponse
                yield SendTaskStreamingResponse(**json.loads(sse.data))
                
# Из A2A/common/types.py
class TaskStatusUpdateEvent(BaseModel):
    id: str             # ID задачи
    status: TaskStatus  # Новый статус
    final: bool = False # Является ли это финальным статусом
    metadata: dict[str, Any] | None = None

class TaskArtifactUpdateEvent(BaseModel):
    id: str            # ID задачи
    artifact: Artifact # Новый артефакт
    metadata: dict[str, Any] | None = None

• Push-уведомления: если агент поддерживает (pushNotifications: true в AgentCard), клиент может настроить URL для получения проактивных уведомлений о статусе задачи через методы tasks/pushNotification/set и tasks/pushNotification/get.

Пример настройки Push Notifications клиентом и структура конфигурации:

# Из A2A/hosts/cli/__main__.py - формирование payload для send_task
if use_push_notifications:
    payload["pushNotification"] = {
        "url": f"http://{notification_receiver_host}:{notification_receiver_port}/notify",
        "authentication": {
            "schemes": ["bearer"], # Указывает на JWT Bearer аутентификацию
        },
    }

# Из A2A/common/types.py - структуры для запросов и конфигурации
class SetTaskPushNotificationRequest(JSONRPCRequest):
    method: Literal["tasks/pushNotification/set",] = "tasks/pushNotification/set"
    params: TaskPushNotificationConfig

class TaskPushNotificationConfig(BaseModel):
    id: str # ID задачи
    pushNotificationConfig: PushNotificationConfig

class PushNotificationConfig(BaseModel):
    url: str # URL клиента для получения уведомлений
    token: str | None = None # Может использоваться для простой аутентификации
    authentication: AuthenticationInfo | None = None # Для более сложной аутентификации (например, JWT)

• Результат: конечный результат задачи представляется в виде Артефактов (Artifact), которые содержат одну или несколько Частей (Part) с результатами работы. Артефакты также могут иметь метаданные, имя, описание и флаги для управления сборкой больших или потоковых результатов (index, append, lastChunk).

Пример структуры Artifact:

# Из A2A/common/types.py
class Artifact(BaseModel):
    name: str | None = None
    description: str | None = None
    parts: List[Part]             # Содержит фактические данные результата
    metadata: dict[str, Any] | None = None
    index: int = 0                # Для упорядочивания частей артефакта
    append: bool | None = None    # Указывает, добавлять ли к предыдущему артефакту
    lastChunk: bool | None = None # Указывает, является ли это последней частью

3. Сотрудничество (Collaboration):

• Механизм: определяет, как агенты обмениваются информацией при выполнении задач. Основной единицей обмена является Сообщение (Message).

• Детали: каждое Message имеет role ("user" для клиента, "agent" для сервера), список Частей (Part), содержащих фактический контент, и опциональные metadata. Агенты могут обмениваться сообщениями для передачи контекста, отправки ответов, передачи артефактов или пользовательских инструкций. История сообщений (history в Task) сохраняет контекст диалога.

Пример структуры Message:

# Из A2A/common/types.py
class Message(BaseModel):
    role: Literal["user", "agent"] # Определяет отправителя
    parts: List[Part]              # Список частей сообщения (текст, файлы, данные)
    metadata: dict[str, Any] | None = None

Пример формирования сообщения клиентом:

# Из A2A/hosts/cli/__main__.py
payload = {
    # ...
    "message": {
        "role": "user",
        "parts": [
            {
                "type": "text", # Указывает тип части
                "text": prompt, # Текст от пользователя
            }
        ],
    },
    # ...
}

• Многошаговое взаимодействие: состояние TaskState.INPUT_REQUIRED явно указывает, что агент ожидает дополнительного ввода от клиента для продолжения задачи, позволяя реализовать многошаговый диалог в рамках одной задачи.

Пример обработки INPUT_REQUIRED в CLI клиенте:

# Из A2A/hosts/cli/__main__.py
async def completeTask(client: A2AClient, ...):
    # ... (отправка задачи, получение taskResult) ...
    state = TaskState(taskResult.result.status.state)
    if state.name == TaskState.INPUT_REQUIRED.name:
        # Если агент требует ввода, рекурсивно вызываем ту же функцию
        # для получения следующего ввода от пользователя в рамках той же задачи (taskId)
        return await completeTask(
            client,
            streaming,
            use_push_notifications,
            notification_receiver_host,
            notification_receiver_port,
            taskId, # Используем тот же ID задачи
            sessionId
        )
    else:
        # Задача завершена (COMPLETED, FAILED, CANCELED)
        return True

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

4. Согласование пользовательского опыта (User Experience Negotiation):

• Механизм: позволяет агенту и клиенту согласовывать и адаптировать формат и способ представления информации на основе возможностей друг друга и потребностей пользователя. Ключевым элементом здесь являются Части (Part).

• Детали: протокол определяет различные типы Part с помощью Pydantic Union и дискриминатора type.

Пример определения Part и его вариантов:

# Из A2A/common/types.py
class TextPart(BaseModel):
    type: Literal["text"] = "text"
    text: str
    metadata: dict[str, Any] | None = None

class FileContent(BaseModel):
    name: str | None = None
    mimeType: str | None = None
    bytes: str | None = None # base64 закодированные данные
    uri: str | None = None   # Ссылка на внешний ресурс
    # Валидатор требует наличия bytes ИЛИ uri

class FilePart(BaseModel):
    type: Literal["file"] = "file"
    file: FileContent
    metadata: dict[str, Any] | None = None

class DataPart(BaseModel):
    type: Literal["data"] = "data"
    data: dict[str, Any] # Произвольные JSON данные
    metadata: dict[str, Any] | None = None

# Union с дискриминатором для автоматического парсинга нужного типа
Part = Annotated[Union[TextPart, FilePart, DataPart], Field(discriminator="type")]

• Клиент при отправке задачи может указать предпочитаемые форматы ответа в поле acceptedOutputModes запроса TaskSendParams. Серверный агент, зная свои возможности (из AgentCard и AgentSkill) и предпочтения клиента, может выбрать наиболее подходящий формат для ответа.

  Пример указания принимаемых форматов клиентом:

# Из A2A/hosts/cli/__main__.py
payload = {
    # ...
    "acceptedOutputModes": ["text", "image/png"],   # Клиент готов принять текст или PNG изображения
    # ...
}

# Из A2A/common/types.py
class TaskSendParams(BaseModel):
    # ...
    acceptedOutputModes: Optional[List[str]] = None # Список MIME-типов или других идентификаторов
    # ...

• Гибкость: эта система позволяет явно поддерживать согласование различных пользовательских интерфейсов (текст, изображения, файлы, формы, потенциально потоковое аудио/видео), делая взаимодействие более богатым и адаптируемым к контексту. Поля metadata на разных уровнях (Task, Message, Part, Artifact) предоставляют дополнительный канал для передачи информации, специфичной для UI или контекста.

Безопасность протокола A2A

Спецификация протокола A2A включает в себя корпоративные соображения безопасности:

• Поддержка механизмов аутентификации (AuthN) и авторизации (AuthZ) на уровне предприятия;

• Модель безопасности соответствует схеме аутентификации OpenAPI на момент выпуска;

• В официальной документации представлено тематическое обсуждение Enterprise Ready;

• Цель протокола — обеспечить безопасный обмен информацией и координацию действий.

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

Особенности протокола A2A:

Взаимодействие между "непрозрачными" агентами

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

Дополнение к MCP

• A2A служит дополнением к MCP, который сам оказался уязвимым к атакам с мгновенным внедрением при предоставлении разрешений инструментам агента.

Причины уязвимостей

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

• Атаки типа "внедрение подсказок" или "социальная инженерия" нацелены на возможности понимания и следования инструкциям Большой языковой модели (LLM), которые действуют выше уровня протокола связи.

• Подключение нескольких агентов через A2A и предоставление им инструментальных возможностей в сочетании с MCP формирует сложную цепочку взаимодействий, усиливая потенциальное воздействие компрометации одного агента.

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

Вывод

Хотя A2A обеспечивает базовые механизмы безопасности (такие как аутентификация), общая безопасность многоагентных систем, созданных с использованием A2A (и MCP), будет зависеть от:

• Надежной конструкции агента;

• Сложного контроля разрешений;

• Строгой проверки и фильтрации входных данных;

• Постоянного мониторинга;

• Разработки новых парадигм безопасности для агентских систем.

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

5. История отрасли и экосистема

Запуск протокола A2A — не единичное событие. Это происходит на фоне быстрого развития технологий ИИ-агентов и растущего спроса отрасли на стандартизацию. Понимание A2A требует рассмотрения его в контексте более широкой отрасли и экосистемы.

Позиционирование отношений

Представители Google неоднократно подчеркивали, что A2A является дополнением к MCP. Эти два решения решают разные проблемы, но могут работать вместе.

Основная направленность

• MCP: Основная цель MCP — подключение интеллектуальных агентов к внешним инструментам, API и ресурсам данных, с упором на предоставление структурированных возможностей ввода/вывода для интеллектуальных агентов, чтобы они могли использовать внешние возможности.

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

Требования к совместной работе

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

Другие протоколы связи интеллектуальных агентов

Помимо MCP, в отрасли могут существовать или появляться другие протоколы связи интеллектуальных агентов. Например, протокол Agent Connect Protocol (ACP) компании Cisco также упоминается как дополнение к MCP. Это свидетельствует о том, что отрасль в целом осознает необходимость стандартизации взаимодействия интеллектуальных агентов.

Сравнительная таблица характеристик протоколов A2A и MCP

Сравнительная таблица характеристик протоколов A2A и MCP

Преимущества A2A включают:

• Обеспечение кроссплатформенной коммуникации;

• Содействие совместной работе;

• Разработка специально для предприятий (аутентификация, долгосрочные задачи, непрозрачные агенты);

• Использование стандартных форматов;

• Мощная поддержка партнеров;

• Снижение барьеров интеграции.

Потенциальные недостатки или опасения относительно A2A

Возможные недостатки или опасения включают:

• Сомнительную необходимость (по сравнению с соглашениями REST+);

• Возможную избыточную разработку;

• Опасения по поводу мотивации и контроля Google;

• Риски безопасности (особенно быстрое внедрение);

• Потенциальную сложность и хрупкость;

• Возможное совпадение с функциональностью MCP;

• Отсутствие четких примеров на ранних стадиях.

Пересечение протоколов

Google рекомендует приложениям моделировать агентов A2A как ресурсы MCP (описанные AgentCard). Таким образом, фреймворк может не только вызывать инструменты через MCP, но и взаимодействовать с пользователями, удаленными агентами и другими агентами через A2A для достижения бесперебойного взаимодействия.

Вывод

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

Ключевыми аспектами протокола A2A являются его ориентация на взаимодействие между "непрозрачными" агентами, использование существующих веб-стандартов (HTTP, SSE, JSON-RPC) для упрощения интеграции, поддержка длительных задач и обратной связи в реальном времени, а также независимость от модальности взаимодействия. Техническая архитектура A2A включает механизм обнаружения возможностей агентов через "Карточку агента", управление жизненным циклом задач, поддержку многошагового сотрудничества через обмен "Сообщениями" и "Частями", и согласование пользовательского опыта через определение форматов данных.

Важно отметить, что Google позиционирует A2A как дополнение к протоколу контекста модели (MCP) от Anthropic, где MCP фокусируется на подключении агентов к внешним инструментам и данным, а A2A — на взаимодействии между самими агентами. Таким образом, для построения сложных многоагентных систем может потребоваться одновременное использование обоих протоколов.

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

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