Протокол Agent2Agent: архитектура, безопасность и сравнение с MCP
Agent2Agent (A2A) — открытый протокол, запущенный Google Cloud в апреле 2025 года и переданный Linux Foundation. Он позволяет ИИ-агентам, построенным на разных фреймворках и от разных вендоров, общаться, делегировать задачи и обмениваться результатами через стандартизированный HTTP/JSON-интерфейс. Если MCP решает проблему доступа к инструментам (LLM вызывает внешние API), то A2A решает проблему координации: агент делегирует целую подзадачу специализированному агенту-пиру с его собственным циклом рассуждений, памятью и инструментами. В репозитории GitHub a2aproject/A2A присутствуют вклады более 50 организаций, включая Salesforce, Atlassian и SAP.
Agent2Agent (A2A) — открытый HTTP/JSON-протокол для обеспечения взаимодействия ИИ-агентов, поддерживаемый Linux Foundation. Он стандартизирует, как автономные агенты объявляют о своих возможностях, делегируют задачи и обмениваются результатами между разными фреймворками и вендорами.
Что такое протокол Agent2Agent (A2A)?
A2A возник из конкретного пробела в экосистеме ИИ-агентов: коммуникация модель-инструмент имела стандарт (MCP, запущен в ноябре 2024), а коммуникация агент-агент — нет. Когда агент-оркестратор должен передать подзадачу специализированному пиру, не было стандартизированного проводного формата для такой делегации.
Google Cloud объявил A2A 9 апреля 2025 года совместно с начальной группой из более чем 50 технологических партнёров, вносящих вклад в спецификацию. В отличие от многих стандартов, продвигаемых вендорами, A2A был передан Linux Foundation для нейтрального управления.
Основа протокола — HTTP/JSON. Совместимый с A2A агент предоставляет небольшой набор конечных точек: карточку агента (манифест возможностей), конечную точку для отправки задач, конечную точку для опроса статуса и конечную точку SSE-стриминга для долгосрочных задач.
Для контекста о проблеме мультиагентной координации, которую решает A2A, смотрите архитектуру многоагентных систем и паттерны оркестрации ИИ-агентов.
Архитектура протокола A2A
A2A определяет три основных концепции: карточки агентов (обнаружение возможностей), жизненный цикл задач (отслеживание делегирования с сохранением состояния) и режимы доставки (SSE-стриминг и webhook-пуш).
Карточки агентов: объявление возможностей и риск перечисления
Карточка агента — JSON-документ, доступный по известному URL (/.well-known/agent.json), описывающий, что умеет агент. Минимальная карточка агента включает:
{
"name": "web-research-agent",
"description": "Исследует темы с помощью веб-поиска и возвращает структурированные резюме",
"version": "1.0.0",
"url": "https://agents.example.com/web-research",
"skills": [
{
"id": "research_topic",
"name": "Исследование темы",
"description": "Поиск информации по теме в интернете и возврат структурированного резюме",
"inputModes": ["text"],
"outputModes": ["text", "data"]
}
],
"authentication": {
"schemes": ["bearer"]
}
}
Карточки агентов обеспечивают динамическое обнаружение возможностей, но несут риски безопасности: в базовом профиле A2A карточки агентов по умолчанию не аутентифицированы, что открывает всю поверхность навыков для перечисления без аутентификации.
Производственные развёртывания должны предоставлять карточки агентов только после аутентификации или ограничивать их внутренними сетевыми сегментами. Модель угроз безопасности ИИ-агентов рассматривает перечисление возможностей как вектор разведывательных атак.
Жизненный цикл задачи: пять состояний от отправки до завершения
A2A определяет жизненный цикл из пяти состояний:
- submitted - Задача получена удалённым агентом; ещё не принята в обработку
- working - Удалённый агент активно обрабатывает задачу (может транслировать прогресс через SSE)
- input-required - Удалённый агент нуждается в уточнении перед продолжением (контрольная точка с участием человека)
- completed - Задача завершена; результирующий артефакт доступен для получения
- failed - Задача провалилась; детали ошибки в объекте статуса задачи
Состояние input-required — механизм A2A для контрольных точек с участием человека в длинных автономных конвейерах.
Доставка задач: пуш vs. пул (SSE и webhook)
A2A поддерживает два режима доставки результатов задач:
SSE (Server-Sent Events): Делегирующий агент открывает постоянное соединение со стриминговой конечной точкой принимающего агента. SSE — основной механизм для долгосрочных задач, требующих инкрементального прогресса.
Webhook-пуш: Делегирующий агент предоставляет callback URL при отправке задачи. Предпочтителен в бессерверных средах, где невозможно поддерживать постоянное SSE-соединение.
A2A vs. MCP: разные слои, разные проблемы
A2A и MCP дополняют друг друга, а не конкурируют. Они работают на разных уровнях стека агентов и решают разные проблемы координации.
| Измерение | MCP | A2A |
|---|---|---|
| Цель | Доступ к инструментам — LLM вызывает внешние API | Координация агентов — агент делегирует другому агенту |
| Коммуникация | Синхронный вызов инструмента в рамках одного хода рассуждения | Асинхронное делегирование задачи; принимающий агент имеет собственный цикл |
| Аутентификация (по умолчанию) | Обязательна — MCP-серверы аутентифицируют клиентов | Опциональна в базовом профиле — анонимный доступ разрешён |
| Обнаружение | Манифест MCP-сервера (список инструментов) | Карточка агента (JSON: навыки + требования к аутентификации) |
| Состояние | Без состояния для каждого вызова инструмента | С сохранением состояния, жизненный цикл из 5 состояний |
| Стриминг | Отсутствует в основной спецификации | SSE в реальном времени; webhook-пуш для асинхронного режима |
| Основная угроза | Отравление инструментов (OWASP LLM07:2025) | Инъекция полезной нагрузки задачи, перечисление карточек агентов |
Когда агенту нужен инструмент (MCP)
MCP — правильный выбор, когда единственному агенту нужно вызвать внешнюю возможность в рамках одного хода рассуждения. Инструмент не имеет собственного цикла рассуждений; он выполняет функцию и возвращает значение.
Когда агенту нужен другой агент (A2A)
A2A — правильный выбор, когда задача требует полной мощи рассуждений агента-пира. Принимающий агент имеет собственную модель, память, доступ к инструментам и многошаговый цикл рассуждений.
Совместное использование MCP и A2A в одной системе
Производственная многоагентная система обычно использует оба. Агент-оркестратор использует A2A для делегирования специализированным агентам. Каждый специалист использует MCP для своих вызовов инструментов.
Аутентификация и модель безопасности A2A
В модели безопасности A2A есть критический пробел: базовый профиль делает аутентификацию опциональной. Инъекция промптов через полезную нагрузку задачи A2A — задокументированный класс атак против любого развёртывания A2A, принимающего задачи от ненадёжных вызывающих.
Поверхность атаки в системах A2A:
1. Инъекция полезной нагрузки задачи: Описание задачи и входные данные в отправке задачи A2A находятся под управлением пользователя.
2. Перечисление карточек агентов: Неаутентифицированные карточки агентов открывают всю поверхность навыков.
3. Предположения о доверии между агентами: Делегирующий агент, доверяющий результатам агента-пира без проверки выходных данных, уязвим к инъекции через цепочку.
4. Анонимное делегирование: Без обязательной аутентификации любой вызывающий в сети может отправлять задачи агенту A2A.
Позиция OpenLegion: A2A — это проводной формат, а не модель безопасности
A2A хорошо спроектирован как проводной формат. Модель безопасности не соответствует производственным требованиям.
Подход OpenLegion к межагентной коммуникации обязывает то, что базовый профиль A2A оставляет опциональным:
-
Каждый межагентный вызов маршрутизируется через хранилище учётных данных. Нет режима анонимного делегирования.
-
Санитизация полезной нагрузки задачи в 56 сетевых точках перехвата. Контент под управлением пользователя санитизируется от атак через unicode перед тем, как достичь контекста LLM.
-
Типизированные контракты передачи задач, проверяемые оркестратором. Полезные нагрузки инъекций через цепочку блокируются на границе передачи.
-
Манифесты возможностей агентов требуют аутентификации для доступа. Поверхность навыков не открыта анонимным вызывающим.
Реализация A2A: технический обзор
Схема карточки агента
Производственная карточка агента должна явно включать требования к аутентификации:
{
"name": "data-analysis-agent",
"description": "Анализирует структурированные наборы данных и возвращает статистические резюме с визуализацией",
"version": "1.2.0",
"url": "https://agents.internal.example.com/data-analysis",
"skills": [
{
"id": "analyze_dataset",
"name": "Анализ набора данных",
"description": "Выполнить статистический анализ предоставленного набора данных",
"inputModes": ["data"],
"outputModes": ["text", "data", "file"]
}
],
"authentication": {
"schemes": ["bearer"],
"required": true
}
}
Отправка задач и опрос статуса
Отправка задачи — POST к /tasks/send. Опрос статуса использует GET /tasks/{task_id}. Опрашивать с экспоненциальной задержкой (1s, 2s, 4s, 8s, максимум 30s). Долгосрочные задачи (>60s) должны переключаться на SSE.
Стриминг долгосрочных задач через SSE
Для задач продолжительностью более 30 секунд использовать SSE через POST /tasks/sendSubscribe. Флаг "final": true сигнализирует о завершении задачи. Реализовать переподключение SSE с заголовком Last-Event-ID для возобновления после разрыва соединения.
Часто задаваемые вопросы
Что такое протокол Agent2Agent (A2A)?
Agent2Agent (A2A) — открытый HTTP/JSON-протокол для обеспечения взаимодействия ИИ-агентов, запущенный Google Cloud в апреле 2025 года и переданный Linux Foundation. Он стандартизирует, как автономные агенты, построенные на разных фреймворках, объявляют о своих возможностях, делегируют задачи и обмениваются результатами. Более 50 организаций, включая Salesforce, Atlassian и SAP, внесли вклад в протокол с момента его запуска в апреле 2025 года.
В чём разница между A2A и MCP?
MCP решает задачу доступа к инструментам: один агент вызывает внешний API в рамках одного хода рассуждений (вызов функции без состояния). A2A решает задачу координации агентов: агент делегирует целую подзадачу агенту-пиру с его собственным циклом рассуждений, памятью и инструментами (делегирование с состоянием). MCP требует аутентификации по умолчанию; базовый профиль A2A делает её опциональной. Оба протокола дополняют друг друга.
Что такое карточки агентов A2A?
Карточки агентов — JSON-документы, предоставляемые по адресу /.well-known/agent.json, описывающие возможности агента, принимаемые режимы ввода/вывода и требования к аутентификации. По умолчанию в базовом профиле A2A они предоставляются без аутентификации. Производственные развёртывания должны требовать аутентификации для доступа к карточкам агентов.
Безопасен ли протокол A2A?
Базовый профиль A2A имеет существенные пробелы в безопасности. Аутентификация по умолчанию опциональна. Инъекция промптов через полезную нагрузку задачи A2A — реальный производственный риск. Производственные развёртывания A2A должны явно реализовывать расширенный профиль аутентификации и санитизировать весь контент полезной нагрузки задачи перед передачей в LLM.
Что такое жизненный цикл задачи A2A?
A2A определяет пять состояний задачи: submitted (получена, ещё не обрабатывается), working (активная обработка, может транслировать прогресс SSE), input-required (удалённый агент нуждается в уточнении перед продолжением — контрольная точка с участием человека), completed (результат доступен) и failed (задача провалилась с деталями ошибки). Состояние input-required — механизм A2A для контрольных точек с участием человека в автономных конвейерах.
Какие компании поддерживают A2A?
A2A был запущен в апреле 2025 года с более чем 50 участвующими организациями, включая Salesforce, Atlassian и SAP. Google Cloud возглавил начальную спецификацию и передал управление Linux Foundation. Протокол ориентирован на корпоративные ИИ-платформы, где агенты, построенные на разных фреймворках, должны взаимодействовать без привязки к вендору.
Как OpenLegion реализует межагентную коммуникацию?
Архитектура сети OpenLegion реализует межагентную координацию с обязательной аутентификацией при каждом вызове — без режима анонимного делегирования. Каждая межагентная передача задачи маршрутизируется через хранилище учётных данных, проверяя идентификатор вызывающего и применяя ACL-шлюзы для каждого агента до того, как задача достигнет принимающего агента. Контент полезной нагрузки задачи санитизируется от атак через unicode в 56 сетевых точках перехвата. Эти контролы работают на инфраструктурном уровне, вне кода агента.
Построение многоагентных систем с аутентификацией при каждом вызове
A2A предоставляет проводной формат для взаимодействия агентов между фреймворками и вендорами. Модель безопасности должна быть выстроена поверх или обеспечена инфраструктурным уровнем.
Для полной классификации угроз смотрите безопасность ИИ-агентов и модель угроз, для паттернов координации — архитектуру многоагентных систем.