Как A2A‑протокол обеспечивает оркестрацию ИИ‑агентов

Мир ИИ-разработки стремительно движется от парадигмы «один модельный вызов — один ответ» к системам, в которых множество специализированных агентов решают сложные задачи совместно. Представьте себе оркестр, где каждый музыкант — это отдельный ИИ-агент со своей специализацией: один анализирует данные, другой генерирует код, третий проверяет результаты. Такие мультиагентные системы позволяют декомпозировать задачу и ускорить ее выполнение за счет параллельной работы. Крупнейшие игроки — Google, Microsoft, IBM — уже делают ставку на эту парадигму как на фундамент приложений следующего поколения. 

Однако путь от прототипа к работающему продукту усеян типичными провалами. На Reddit (MachineLearning) или Хабре разработчики жалуются: «Агенты теряют контекст при передаче задач», «Они зациклились в бесконечных дебатах, сожгли весь бюджет на токены, а результата нуль». Анализ таких кейсов показывает: дело не в «глупости» LLM или неудачных промптах. Корень зла почти всегда лежит в отсутствии грамотной оркестрации.

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

Фундаментальная проблема интероперабельности

Внутренняя оркестрация решает проблемы координации, но это лишь половина проблемы. Даже при наличии грамотного оркестратора экосистема AI-агентов сталкивается с глобальной проблемой масштабирования — интероперабельностью. Агенты, созданные разными командами на разных фреймворках, не умеют взаимодействовать «из коробки». Каждый вендор предлагает собственный API, уникальный формат описания возможностей и специфический транспортный протокол. В результате интеграция двух агентов превращается в ручную работу по написанию адаптеров. Это классическая проблема сложности O(n^2), которая делает создание круп��ых экосистем экономически и технически нецелесообразным.

Лучшие современные практики предполагают переход от кастомных решений к использованию открытых стандартов и фреймворков, решающих эту проблему системно. Ярким примером такого подхода является Agent-to-Agent Protocol (A2A), предлагаемый Google и поддерживаемый сообществом open source.

Что такое Agent-to-Agent Protocol (А2А)

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

Протокол анонсирован Google в апреле 2025 года, а в марте 2026 года вышла стабильная production-ready версия 1.0. Это знаковое событие: A2A перестал быть экспериментом и стал индустриальным стандартом.

Сейчас A2A управляется Linux Foundation при участии AWS, Google, Microsoft, IBM и других гигантов, что гарантирует его открытость. После слияния с протоколом ACP от IBM, A2A стал единым индустриальным стандартом, который поддерживают более 50 компаний.

Ключевые концепции A2A

A2A построен вокруг четырех фундаментальных абстракций:

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

Примерная структура AgentCard:

{
  "name": "My AI Agent",
  "description": "Agent that processes documents",
  "url": "https://your-agent-domain.com",
  "version": "1.0.0",
  "supportsAuthenticatedExtendedCard": false,
  "documentationUrl": "https://docs.your-agent-domain.com",
  "capabilities": {
        "extensions": [
            {
                "description": "Provides agent driven UI using the A2UI JSON format.",
                "uri": "https://a2ui.org/a2a-extension/a2ui/v0.8"
            }
        ],
        "pushNotifications": true,
        "stateTransitionHistory": true,
        "streaming": true
    },
    "skills": [
      {
        "id": "document-processing",
        "name": "Document Processing",
        "description": "Processes and analyzes documents"
      }
    ],
  "defaultInputModes": ["application/json"],
  "defaultOutputModes": ["application/json"],}

Для того, чтобы посмотреть AgentCard настоящего агента, достаточно в Postman вызвать GET метод https://myagent.example.com/.well-known/agent.json вашего агента.

Стоит обратить внимание ^[1] на поле extensions — оно позволяет агенту заявлять о поддержке дополнительных протоколов через URI-ссылки, не меняя ядро A2A. Например, так подключаются AGP (маршрутизация через шлюзы) и AP2 (платежи между агентами). Клиент считывает эти расширения из карточки и, при поддержке указанных стандартов, автоматически активирует расширенную функциональность. Это сохраняет протокол минималистичным в основе, но дает гибкость для сложных enterprise-сценариев.

Task — центральная единица работы в A2A. У задачи есть жизненный цикл: создание → отправка на выполнение → промежуточные обновления → завершение. Задача может быть успешной, неудачной или отмененной. Клиент может отслеживать прогресс задачи в реальном времени через Server-Sent Events.

Работа с Task начинается с отправки сообщения через метод message/send — именно так создается задача и передается агенту ваш запрос. Чтобы отправить сообщение агенту, можно использовать POST-запрос https://myagent.example.com/ с соответствующим Body:

{
  "jsonrpc": "2.0",
  "id": "{{$randomUUID}}",
  "method": "message/send",
  "params": {
    "message": {
      "role": "user",
      "parts": [
        {
          "kind": "text",
          "text": "Привет! Что такое интеграл"
        }
      ],
      "messageId": "{{$randomUUID}}",
      "kind": "message"
    },
    "configuration": {
      "acceptedOutputModes": ["text/plain", "application/json"],
      "historyLength": 5,
      "blocking": true
    }
  }
}

Для получения статуса задачи используется метод tasks/get. Отправляем POST-запрос https://myagent.example.com/ с таким Body:

{
  "jsonrpc": "2.0",
  "id": "{{$randomUUID}}",
  "method": "tasks/get",
  "params": {
    "id": "{{taskId}}",
    "historyLength": 10
  }
}

Например, если агент получил вопрос «Что такое интеграл?», то task будет выглядеть так:

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

{
  "artifacts": [
    {
      "name": "chart",
      "mimeType": "image/png",
      "data": {
        "url": "https://storage.example.com/charts/report-123.png"
      }
    }
  ]
}

Skill — описание конкретного навыка агента. Агент может заявить о нескольких навыках через свою Agent Card, что позволяет клиентам точно знать, какие задачи агент способен решить. Пример Skills представлен на рисунке с Agent Card.

Транспортные механизмы

A2A использует JSON-RPC 2.0 поверх HTTP(S) как основной транспорт. Это сознательный выбор: JSON-RPC — простой, хорошо документированный протокол, поддерживаемый практически на любом языке программирования. Также поддерживаются транспортные механизмы:

• JSON-RPC 2.0 — основной транспорт для синхронных вызовов. Стандартный запрос-ответ для создания задач и получения результатов.

• Server-Sent Events (SSE) — потоковая передача промежуточных результатов. Клиент подписывается на обновления задачи и получает их в реальном времени.

• gRPC (с v0.3.0) — бинарный транспорт для высокопроизводительных сценариев. Подходит для внутрикластерной коммуникации, где latency критичен.

Что нового в v1.0

Версия 1.0, выпущенная 12 марта 2026 года, принесла ряд важных изменений:

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

• Signed Agent Cards. Криптографическая подпись Agent Cards позволяет верифицировать подлинность агента, что критично для enterprise-окружений.

• Улучшенная безопасность. Расширены схемы аутентификации: OAuth 2.0, OIDC, API keys, mTLS.

• Расширяемость через Extensions. Механизм URI-based Extensions позволяет добавлять новые возможности протокола без изменения его ядра. AGP (Agent Gateway Protocol) и AP2 (Agent Payments Protocol), A2UI (Agent to UI) реализованы именно как Extensions.

Почему Extensions критичны для enterprise

A2A-протокол позволяет агентам общаться напрямую друг с другом. Но в корпоративных системах с десятками или сотнями агентов возникают новые вызовы: как правильно направлять запросы, контролировать безопасность данных и управлять затратами? Agent Gateway Protocol (AGP) решает эти задачи, расширяя A2A системой шлюзов, которые автоматически подбирают исполнителей по политикам безопасности и стоимости.

Что такое Agent Gateway Protocol (AGP)

AGP — это расширение протокола A2A, которое добавляет уровень маршрутизации. Если базовый A2A обеспечивает прямое взаимодействие «агент-к-агенту», то AGP вводит концепцию шлюзов (gateways) — посредников, которые принимают запросы, оценивают доступных исполнителей и направляют задачи оптимальному агенту.

Вдохновленный Border Gateway Protocol (BGP), AGP организует агентов в доменные squads (отряды) и направляет запросы (Intents) на основе объявленных возможностей (Capabilities), стоимости и политик безопасности.

AGP решает ключевые проблемы масштабирования:

Иерархическая маршрутизация. В больших системах плоские сети создают чрезмерную нагрузку и хаос. AGP организует иерархические шлюзы и агрегирует маршруты для эффективной работы.

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

Оптимизация затрат: выбирает самый «короткий» маршрут среди подходящих.

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

Ключевые компоненты AGP

Squads — это автономные группы агентов, специализирующиеся на определенных доменах: finance, engineering, HR. Они объявляют свои capabilities — конкретные навыки или сервисы, которые могут выполнять.

Поля:

• Capability: уникальный идентификатор навыка или функции в формате domain:category:action.Примеры: financial_analysis:quarterly, infra:provision:vm, hr:onboarding:new_employee.

• ​Version (string, обязательно): версия API/схемы сервиса.

• Сost (number, опционально): оценочная метрика затрат: USD, токены и т.д. Используется для выбора минимального маршрута.

• Policy (object, обязательно): требования безопасности провайдера для фильтрации. Поле представляет собой словарь политик безопасности и требований. Содержит ключ-значение пары для фильтрации маршрутов.

{
  "capability": "data_processing:etl_pipeline", 
  "version": "2.0",
  "cost": 0.12,
  "policy": {
    "security_level": "high",
    "pii_handling": true,
    "allowed_regions": ["EU", "US"]
  }
}

Intent Payload — это основной способ, как клиент (любой агент или приложение) говорит шлюзу AGP: «Мне нужно выполнить задачу X с условиями Y».

Представьте: у вас корпоративная сеть из 50+ ИИ-агентов. Клиент не знает, кто именно умеет генерировать счета, обрабатывать PII или развертывать виртуальные машины. Вместо поиска по всей сети, клиент отправляет Intent — и шлюз сам находит исполнителя.

Поля:

• target_capability (string, обязательно). Уникальный идентификатор требуемого действия в формате domain:category:action. Примеры: billing:invoice:generate, infra:provision:vm, hr:employee:onboard
  Шлюз ищет всех провайдеров с точно таким же ключом в AGPTable.

• payload (object, обязательно). Входные данные и контекст для выполнения задачи.

• policy_constraints (object, опционально). Жесткие требования безопасности для фильтрации агентов.

{
  "target_capability": "billing:invoice:generate",  
  "payload": {                                     
    "customer_id": 123,
    "amount": 99.99,
    "currency": "USD"
  },
  "policy_constraints": {                          
    "requires_pii": true,
    "security_level": 4,
    "geo": "EU"
  }
}

RouteEntry — это запись в AGPTable, которая описывает один конкретный провайдер (Squad) для определенной capability.

{
  "path": "EngineeringSquad/vm_provisioner",
  "cost": 0.08,
  "policy": {
    "security_level": 4,
    "requires_pii": false,
    "allowed_geo": ["US", "EU"]
  }
}

AGPTable — основная структура данных шлюза, которая отображает каждую capability на список доступных провайдеров в виде RouteEntry.

Встраиваем AGP в A2A

Шлюзы AGP должны объявлять свою роль и поддерживаемые версии через расширения в A2A-протоколе (поле extensions):

{
  "uri": "https://github.com/a2aproject/a2a-samples/tree/main/extensions/agp",
  "params": {
    "agent_role": "enterprise_gateway", 
    "supported_agp_versions": ["1.1", "1.2"]
  }
}

A2A и MCP как взаимодополняющие протоколы

Частый вопрос: зачем нужны и A2A, и MCP? Ответ в том, что они решают разные задачи и дополняют друг друга.

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

Российская платформа для мультиагентных систем

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

Наша команда разработала Evolution AI Agents ^[2] —платформу, которая упрощает создание мульти-агентных систем без написания кода. Вы можете выбирать готовых ИИ-агентов и MCP-серверы из маркетплейса или загружать собственные решения через Docker-образы. Агенты из маркетплейса использует A2A для коммуникации и подключает MCP-инструменты, избавляя от необходимости разбираться в JSON-RPC, SSE или генерации Agent Cards. Встроенные механизмы логирования и трейсинга обеспечивают полную наблюдаемость за выполнением задач, а guardrails контролируют безопасность и предсказуемость работы агентов. Масштабирование, мониторинг и управление доступом работают из коробки, без дополнительной настройки. Подробнее о платформе мы рассказываем в документации ^[3].

Вы фокусируетесь на бизнес-логике, а мы берем на себя всю инфраструктурную сложность.

Вместо заключения

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

Индустрия движется по двум параллельным путям:

1. Стандартизация: появление протоколов вроде A2A решает проблему «Вавилонской башни», позволяя агентам от разных вендоров понимать друг друга.

2. Абстракция инфраструктуры: для тех, кто хочет фокусироваться на бизнес-логике, а не настройке Kubernetes и трассировке, появляются мощные PaaS-решения, например, Evolution AI Agents, берущие всю сложность оркестрации на себя.

Какой путь выбрать? Если вам нужен полный контроль над архитектурой и поведением ^[4] агентов — стройте свою систему на открытых фреймворках. Если критична скорость запуска и надежность в продакшене — присмотритесь к готовым облачным решениям. Главное правило остается неизменным: успех мульти-агентной системы зависит не от «ума» отдельной модели, а от качества архитектуры, которая ими управляет.

Готовы приступить к практике? У нас есть серия лабораторных работ ^[5], которые шаг за шагом научат работать с протоколом A2A, подключать MCP-инструменты и запускать агентов.