A2A: как AI-агенты общаются друг с другом

Один агент может многое. Но реальные бизнес-процессы часто требуют координации нескольких специализированных агентов. Один анализирует данные, другой пишет код, третий тестирует, четвёртый деплоит. Google A2A (Agent-to-Agent) — протокол, который стандартизирует общение между агентами. И это меняет правила игры.

Представьте задачу: «Проанализируй данные о продажах за Q1, создай отчёт, отправь его CFO и запланируй follow-up meeting». Один агент теоретически может это сделать, но ему нужны инструменты для аналитики, генерации документов, email, календаря. Это много контекста, много инструментов, высокий риск ошибки.

Альтернатива: четыре специализированных агента. Analytics Agent получает данные и формирует insights. Document Agent создаёт отчёт. Communication Agent отправляет email. Calendar Agent планирует встречу. Каждый делает одно дело хорошо. Координирует их Orchestrator Agent, который знает, в каком порядке вызывать и как передавать данные.

Google анонсировал A2A (Agent-to-Agent) протокол в апреле 2025 года. Цель — создать открытый стандарт, по которому агенты от разных провайдеров могут взаимодействовать. Агент от Anthropic вызывает агента от Google, который делегирует задачу агенту от OpenAI. Без A2A это было бы хаосом проприетарных интеграций.

Agent Cards (Карточки агентов)

Каждый A2A-агент публикует Agent Card — JSON-документ, описывающий его возможности. Это как OpenAPI spec, но для AI-агентов. Card содержит: имя, описание, список skills (навыков), поддерживаемые форматы ввода/вывода, endpoints для коммуникации.

Agent Card размещается по стандартному URL: /.well-known/agent.json. Любой другой агент может обнаружить карточку, прочитать capabilities и решить, подходит ли этот агент для текущей задачи. Это автоматическое обнаружение сервисов — service discovery для AI.

JSON-RPC транспорт

A2A использует JSON-RPC 2.0 для коммуникации между агентами. Это тот же протокол, что используется в Language Server Protocol (LSP) и многих других стандартах. Простой, хорошо документированный, с поддержкой batch-запросов и уведомлений.

• tasks/send — отправить задачу агенту и получить результат
• tasks/sendSubscribe — отправить задачу с подпиской на обновления (streaming)
• tasks/get — получить статус ранее отправленной задачи
• tasks/cancel — отменить выполняемую задачу

Task Lifecycle

Задача в A2A проходит через состояния: submitted → working → completed (или failed/canceled). Каждое изменение состояния генерирует событие, на которое может подписаться вызывающий агент. Это позволяет строить асинхронные pipeline, где агенты работают параллельно и уведомляют друг друга о завершении.

Паттерн 1: Orchestrator (Оркестратор)

Центральный агент получает задачу, декомпозирует её и распределяет подзадачи между специализированными агентами. Оркестратор не выполняет работу сам — он координирует. Это самый распространённый паттерн, аналог API Gateway в микросервисах.

Преимущества: чёткий контроль, предсказуемый flow, легко отлаживать. Недостатки: оркестратор — single point of failure, bottleneck при высокой нагрузке.

Паттерн 2: Pipeline (Конвейер)

Агенты выстроены в цепочку: выход одного — вход другого. Data Agent → Analysis Agent → Report Agent → Review Agent → Publish Agent. Каждый обрабатывает данные и передаёт дальше. Как конвейер на заводе.

Преимущества: простота, каждый агент независим. Недостатки: если один агент падает — весь pipeline останавливается, сложно добавить ветвление.

Паттерн 3: Peer-to-Peer (Равноправный)

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

Паттерн 4: Recursive Arguing (Рекурсивная дискуссия)

Два или более агента дискутируют о решении, пока не достигнут консенсуса. Один предлагает решение, другой критикует, первый улучшает. Этот паттерн используется для задач, где важно качество: code review, архитектурные решения, стратегическое планирование.

MCP (Model Context Protocol) и A2A решают разные задачи, хотя часто упоминаются вместе. MCP — протокол взаимодействия AI-модели с инструментами. A2A — протокол взаимодействия AI-агентов друг с другом. Они комплементарны, не конкурентны.

• MCP: модель → инструмент. «Прочитай файл», «Выполни SQL-запрос», «Отправь HTTP-запрос»
• A2A: агент → агент. «Проанализируй данные», «Напиши отчёт», «Проведи code review»
• MCP — низкоуровневый: конкретные операции с чёткими параметрами
• A2A — высокоуровневый: абстрактные задачи, которые агент декомпозирует самостоятельно
• Агент использует MCP для работы с инструментами, A2A для работы с другими агентами

Stripe: платёжная автоматизация

Stripe интегрировала A2A для автоматизации сложных финансовых workflow. Agent «Бухгалтер» обрабатывает транзакции, Agent «Комплаенс» проверяет на соответствие регуляциям, Agent «Отчётность» формирует документы. Всё координируется через A2A.

Zapier: автоматизация бизнес-процессов

Zapier превратила свои «Zaps» в A2A-совместимых агентов. Теперь внешние AI-системы могут вызывать Zapier-автоматизации как A2A-задачи. Это открывает 6000+ интеграций для любого AI-агента.

DevOps Pipeline

Code Agent пишет код → Review Agent проводит ревью → Test Agent запускает тесты → Security Agent проверяет уязвимости → Deploy Agent деплоит в staging → QA Agent проводит end-to-end тесты → Deploy Agent деплоит в production. Весь pipeline автоматизирован через A2A.

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

Шаг 1: Определите агентов

Каждый агент — одна зона ответственности. Coder Agent пишет код, Reviewer Agent проверяет его. Чёткое разделение = чёткая коммуникация.

Шаг 2: Опишите Agent Cards

Для каждого агента создайте описание capabilities. Что он умеет, что принимает на вход, что возвращает. Это контракт между агентами.

Шаг 3: Реализуйте коммуникацию

Используйте JSON-RPC для обмена задачами. Агент-оркестратор отправляет tasks/send специализированным агентам и ожидает результат. Начните с синхронного режима, потом добавьте streaming через tasks/sendSubscribe.

Шаг 4: Добавьте error handling

Агент может не справиться с задачей. Предусмотрите fallback: retry, передача другому агенту, эскалация человеку. Мульти-агентная система без error handling — это мульти-агентный хаос.

• Начните с 2 агентов — Coder + Reviewer
• Используйте JSON-RPC для коммуникации
• Добавьте Agent Cards для service discovery
• Реализуйте retry и fallback логику
• Логируйте каждое межагентное взаимодействие
• Тестируйте на реальных задачах, не на hello-world

A2A — это начало. В ближайшие годы мы увидим экосистему специализированных AI-агентов, доступных как сервисы. Нужен анализ данных? Вызови Analytics Agent. Нужен перевод? Translation Agent. Нужен дизайн? Design Agent. Каждый лучший в своём деле, все координируются через стандартные протоколы.

Навык проектирования мульти-агентных систем — это то, что определит следующее поколение AI-инженеров. Не просто использовать одного агента, а проектировать системы агентов, которые решают сложные задачи автономно и надёжно.

В BRIQ.TEAM мы изучаем оба протокола — MCP и A2A — и строим реальные мульти-агентные системы. От простого coding agent до полноценного DevOps pipeline из пяти агентов. Это не будущее — это то, что можно построить сегодня.