A2A протокол (Agent2Agent) позволяет ИИ-агентам делегировать задачи друг другу через стандартный HTTP-интерфейс. Google запустил протокол 9 апреля 2025 года на конференции Google Cloud Next вместе с 50+ компаниями-партнёрами, включая Salesforce, Atlassian и SAP. К середине 2026 года A2A ИИ-архитектуры работают в production у 150+ организаций, спецификация передана в Linux Foundation и развивается как открытый стандарт.
До A2A каждая компания придумывала собственный способ связать агентов: кастомные JSON-контракты, брокеры очередей, ручная оркестрация через HTTP-хуки. Это решало задачу внутри одной команды, но разваливалось при интеграции с внешними системами и сторонними агентами. A2A фиксирует общий язык, понятный любому фреймворку, независимо от того, какая LLM внутри агента.
Что такое A2A-протокол и какую проблему решает
Представьте компанию с тремя агентами: один читает входящие заявки, второй проверяет наличие товара в ERP, третий формирует ответ клиенту. Без общего протокола разработчик пишет три разных интеграции. При замене одного агента на другой (например, при смене LLM-провайдера) интеграции ломаются. A2A убирает эту проблему: агент объявляет свои возможности в стандартном формате, и любой другой агент обращается к нему без кастомного кода.
Протокол строится поверх HTTP/HTTPS и описывает три вещи: как агент публикует свои способности (Agent Card), как другой агент отправляет задачу (Task) и как передаётся результат в трёх режимах. Авторизация строится на OAuth 2.0. Текущая версия спецификации 0.2.
Как работает A2A: три участника и Agent Card
В A2A-взаимодействии участвуют три роли. Оркестратор принимает пользовательский запрос и решает, кому делегировать части задачи. Агент-исполнитель получает задачу и выполняет её в рамках своей специализации. Клиент (пользователь или система) взаимодействует с оркестратором и не знает о существовании внутренних агентов.
Каждый агент публикует Agent Card по фиксированному пути /.well-known/agent-card.json. В карточке указаны: название, описание, поддерживаемые типы задач, способности (skills) и требования к авторизации. Оркестратор читает карточку и решает, подходит ли агент для конкретного шага.
Протокол поддерживает три режима коммуникации. Синхронный (REST) подходит для коротких задач с немедленным ответом. Стриминг через SSE (Server-Sent Events) передаёт промежуточные результаты по мере генерации. Push-уведомления через webhook используют для долгих задач, где агент завершает работу асинхронно. Конкретный режим выбирается по характеру задачи.
A2A и MCP: два разных слоя, не конкурентов
Распространённое заблуждение: A2A заменяет MCP (Model Context Protocol от Anthropic). Это не так. Протоколы решают разные задачи и хорошо работают вместе. Подробнее о втором протоколе читайте в нашей статье про MCP-протокол.
| Параметр | MCP (Anthropic) | A2A (Google / Linux Foundation) |
|---|---|---|
| Направление | Вертикальное: агент подключается к инструментам и данным | Горизонтальное: агент координирует задачи с другими агентами |
| Что соединяет | Агент ↔ CRM, БД, файловая система, API | Агент ↔ Агент |
| Транспорт | JSON-RPC поверх stdio / HTTP | HTTP REST, SSE, Webhook |
| Авторизация | API-ключи, токены через конфиг | OAuth 2.0 |
| Кто поддерживает | Anthropic, LangChain, Cursor | Google, Salesforce, SAP, Atlassian, LangGraph, AutoGen, CrewAI |
| Аналогия | Руки агента (инструменты) | Язык между агентами (координация) |
| На практике | Оба протокола работают вместе: MCP даёт агенту доступ к инструментам, A2A позволяет передавать часть задачи специализированному агенту | |
Кто уже использует A2A
Протокол запустили не в одиночку: 50 компаний участвовали в разработке с первого дня. Salesforce встроил A2A в Agentforce: агенты делегируют задачи внешним специализированным агентам по продажам, поддержке и маркетингу. Atlassian использует протокол для координации агентов внутри Jira и Confluence: задача из тикета автоматически распределяется между агентом-аналитиком и агентом-документатором. SAP тестирует A2A для цепочек поставок, где агент проверки наличия товара взаимодействует с агентом логистики через стандартный интерфейс.
В России облачный провайдер cloud.ru объявил о поддержке A2A в своей агентной платформе. Для компаний, которые строят инфраструктуру внутри российских дата-центров, это сигнал: протокол работает независимо от западных облаков.
По данным Linux Foundation на июнь 2026 года, 150+ организаций используют A2A в production. Среди них финтех, ретейл, производство и SaaS-компании. Передача спецификации в независимый open-source фонд гарантирует, что протокол не станет проприетарным инструментом одного вендора.
Пять бизнес-сценариев для российских компаний
Мультиагентная архитектура на базе A2A решает задачи, где один агент упирается в специализацию или объём контекста. Пять сценариев, которые уже реализуются в российском бизнесе.
1. Обработка входящих заявок. Агент-маршрутизатор принимает заявку из любого канала (почта, мессенджер, CRM), определяет тип и приоритет, затем делегирует специализированному агенту через A2A: заявка на возврат уходит агенту по возвратам, технический вопрос уходит агенту техподдержки. Каждый специализированный агент обучен на своём наборе данных и правилах. Оркестратор только распределяет, не вникая в детали обработки.
2. Документооборот и согласования. Агент-аналитик читает входящий договор, извлекает ключевые условия и параллельно передаёт задачу агенту юридической проверки и агенту финансового анализа. Оркестратор агрегирует результаты обоих и формирует итоговый отчёт для ответственного сотрудника. Цикл согласования, который занимал 2-3 дня, сокращается до часов.
3. Аналитика данных из разных систем. Оркестратор принимает запрос «Почему упали продажи в марте?», делегирует агенту аналитики продаж (данные из CRM), агенту аналитики трафика (данные из Яндекс Метрики) и агенту аналитики склада (данные из ERP). Каждый агент работает со своим источником параллельно, оркестратор собирает выводы в связный ответ.
4. Интеграция с 1С. Агент на базе YandexGPT или GigaChat принимает запрос на выставление счёта от менеджера в мессенджере. Через MCP-коннектор к 1С он получает данные контрагента, через A2A делегирует агенту-валидатору проверку лимитов и статуса задолженности, затем формирует счёт и отправляет его на согласование. Связка A2A + MCP + 1С-коннектор работает без изменений в самой 1С.
5. Голосовые мультиагентные системы. Голосовой агент принимает звонок клиента, переводит речь в текст и через A2A обращается к агенту идентификации (проверяет клиента по базе), агенту продуктового знания (отвечает на вопрос) и агенту CRM (фиксирует обращение). Клиент общается с одним агентом, за ним стоит оркестрируемая цепочка специализированных агентов. Среднее время обработки звонка сокращается на 30-45%.
Как мы строим такие системы, читайте на странице ИИ-агентов для бизнеса.
Три шага к мультиагентной архитектуре
Переход от одного агента к мультиагентной системе не требует переписывать всё с нуля. Три шага, которые продакшн-системы проходили без остановки рабочих процессов.
Шаг 1. Аудит задач агента. Определите, где ваш текущий агент тратит 80% контекста на одну специализацию, например только отвечает на вопросы по продуктам, хотя мог бы ещё и фиксировать обращения в CRM. По этой границе стоит разделить агентов. Оркестратор плюс один-два специализированных агента составляют минимальную рабочую конфигурацию. Пилот на такой архитектуре обходится в 300 000-600 000 рублей в зависимости от сложности интеграций.
Шаг 2. Реализация Agent Card и A2A-сервера. Каждый специализированный агент публикует /.well-known/agent-card.json с описанием своих capabilities. Оркестратор читает карточки и строит маршрут задачи. На этом шаге выбирайте фреймворк с нативной поддержкой A2A: LangGraph, Google ADK или AutoGen. Это сокращает время реализации на 40-60% по сравнению с реализацией транспорта с нуля.
Шаг 3. Слой абстракции поверх транспорта. Спецификация A2A версии 0.2 ещё меняется. Слой абстракции (adapter pattern) изолирует бизнес-логику агентов от деталей транспортного протокола. Когда выйдет версия 0.3, обновится только адаптер, а не логика каждого агента. Подробнее о подходе к внедрению читайте на странице внедрения ИИ.
Ограничения и риски A2A
A2A работает в production у 150+ компаний, но несколько ограничений протокола прямо влияют на архитектурные решения.
Спецификация продолжает меняться. Версия 0.2 стабильна для базовых сценариев, но некоторые детали транспорта и формат Agent Card менялись между минорными версиями. Без слоя абстракции обновление протокола превращается в рефакторинг всей системы.
Безопасность требует больше, чем OAuth 2.0. Протокол предусматривает авторизацию через OAuth 2.0, но не описывает, что агент имеет право делать с полученными данными. Политики доступа, аудит вызовов и ограничения на уровне бизнес-логики остаются ответственностью разработчика. Агент с широкими OAuth-правами может передать конфиденциальные данные другому агенту, у которого нет соответствующих бизнес-прав.
Vendor-зависимость от фреймворков. LangGraph, AutoGen и Google ADK реализуют A2A со своими особенностями. Переход с одного фреймворка на другой требует адаптации, даже если транспортный протокол стандартный. Закладывайте фреймворк-нейтральный интерфейс на уровне оркестратора с первого дня.
Latency в агентных цепочках. Каждый A2A-вызов добавляет сетевой round-trip. Цепочка из 5 агентов с последовательными вызовами накапливает задержку: при среднем времени ответа агента 2-4 секунды суммарное ожидание составит 10-20 секунд. Параллельные вызовы через оркестратор снижают задержку, но усложняют обработку ошибок. Проектируйте топологию так, чтобы независимые агенты работали параллельно с первого шага.
Отладка распределённых агентов. Когда задача проходит через оркестратор и трёх специализированных агентов, найти источник ошибки сложнее, чем в монолитном агенте. Распределённый трейсинг (OpenTelemetry) и структурированные логи на каждом A2A-переходе обязательны с первого дня, не добавляются потом.
A2A в российском стеке: что работает сейчас
Российские компании не ждут официального релиза enterprise-версии протокола. Пилоты уже запущены в нескольких вертикалях.
В финтехе: агент-андеррайтер (модель GigaChat self-hosted) передаёт через A2A структурированный запрос агенту-аналитику кредитной истории. Данные не покидают периметр VPC: требование 152-ФЗ соблюдается на транспортном уровне, потому что A2A добавляет авторизацию OAuth 2.0 к каждому вызову, а не только к первому соединению.
В ретейле: агент-кластеризатор заказов (FastAPI + YandexGPT) маршрутизирует аномальные заявки агенту-антифроду, не передавая данные через публичный интернет. Round-trip внутри одной VPC составляет 40-80 мс, это приемлемо для real-time сценариев.
В B2B-сервисах: оркестратор на LangGraph выступает единой точкой входа для CRM-агента (Bitrix24 connector), агента документооборота (1С через MCP) и агента уведомлений (Telegram Bot API). Без A2A каждый дополнительный агент требовал нового REST-контракта. С A2A добавление четвёртого агента занимает день, а не неделю.
Общая черта российских пилотов: предпочтение self-hosted деплоя A2A-серверов на VPS в российских дата-центрах (Selectel, Yandex Cloud, Cloud.ru). Это закрывает требования по локализации данных без изменений в самом протоколе.
Observability по умолчанию слабая. A2A передаёт task_id в каждом запросе, но не определяет, как этот ID попадёт в логи агента-исполнителя. На практике разные фреймворки логируют task_id по-разному: LangGraph пишет его в trace, AutoGen нет. Если не стандартизировать формат логов на старте, через три месяца production-системы будут невозможно отлаживать. Минимальный набор: request_id, task_id, agent_name, timestamp, duration_ms на каждом A2A-переходе.
Версионирование агентов не описано. Когда агент-исполнитель выходит с обновлённой версией API (новые поля в ответе, изменённый формат Task), A2A не предоставляет встроенного механизма семантического версионирования. Agent Card содержит поле version, но клиент не обязан его проверять. Команда протокола обсуждает обязательную negotiation в v0.3, но пока это остаётся инициативой разработчика, а не частью спецификации.
EQ.team — практика, а не теория
Готовы внедрить мультиагентную архитектуру?
Разрабатываем ИИ-агентов для бизнеса: от пилота до production. Знаем специфику интеграции с 1С, CRM и российскими LLM.
FAQ: Agent2Agent протокол
В чём разница между A2A и MCP?
MCP (Anthropic) — вертикальный протокол: агент подключается к инструментам и данным (CRM, БД, API). A2A (Google/Linux Foundation) — горизонтальный: агенты координируют задачи между собой. На практике оба нужны: MCP даёт агенту инструменты, A2A позволяет делегировать часть работы другому агенту.
Нужен ли A2A, если у меня один ИИ-агент?
Нет. A2A полезен, когда задача требует нескольких специализированных агентов с разными доменными знаниями. Один агент, который «знает всё», остаётся валидной архитектурой до определённого масштаба. A2A актуален при 3+ агентах с чёткими границами ответственности.
Как A2A связан с LangChain и другими фреймворками?
LangGraph, AutoGen, CrewAI и Google ADK поддерживают A2A из коробки или через адаптеры. LangChain с адаптерами под YandexGPT/GigaChat позволяет строить A2A-совместимых агентов, которые работают с данными на территории РФ.
Можно ли использовать A2A с YandexGPT или GigaChat?
Да. A2A — транспортный протокол, не привязан к конкретной LLM. Агент на основе YandexGPT Pro или GigaChat реализует A2A-сервер так же, как агент на основе GPT-4o. Для self-hosted деплоя GigaChat в связке с LangChain и A2A закрывает требования по локализации данных.
Когда A2A будет полностью стабилен для production?
Спецификация уже в production у 150+ организаций (данные Linux Foundation, июнь 2026). Версия 0.2 стабильна для базовых сценариев. Рекомендуется добавить слой абстракции поверх транспорта, чтобы обновления протокола не ломали бизнес-логику.
