Agent2Agent (A2A) — подробный обзор открытого протокола Google для общения ИИ-агентов

За последние два года мир ИИ пережил бум «агентов» — автономных или полуавтономных программ, которые планируют задачи и вызывают внешние инструменты без участия человека. Но по-настоящему командная работа таких агентов до недавнего времени упиралась в нехватку общего «языка». Эту проблему Google решила открытым протоколом Agent2Agent (A2A), публично представленным 9 апреля 2025 года на Google Cloud Next.

В статье разбираемся, зачем понадобился ещё один стандарт, как он устроен и почему уже через несколько месяцев после анонса к проекту присоединились десятки крупных игроков, а сама спецификация переехала под крыло Linux Foundation.

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

Как появился A2A и кто за ним стоит

Google позиционирует A2A как «универсальный переводчик» для ИИ-агентов: стандартный набор HTTP/gRPC-методов и JSON-объектов, который даёт агентам возможность узнавать возможности друг друга, договариваться о формате ответов и поддерживать долгие stateful-задачи. В создании протокола участвовало более 50 партнёров — от Atlassian и Salesforce до SAP и MongoDB.

Через два с небольшим месяца инициативу официально принял Linux Foundation, пообещав открытое, нейтральное управление и инклюзивную модель развития. Такой шаг сразу повысил доверие индустрии: к проекту подтянулись AWS, Cisco, ServiceNow и ряд сервисных гигантов типа Accenture и BCG.

Параллельно команда Google выпустила набор SDK (Python, JS, Java) и фреймворк Agent Development Kit (ADK), где A2A «вшит» из коробки, а также публичный репозиторий a2aproject/A2A с открытой спецификацией.

Архитектура и ключевые понятия

Спецификация A2A строится вокруг трёх базовых акторов: user (человек или сторонний сервис), A2A client (агент-клиент, инициатор запроса) и A2A server (агент-исполнитель). Каждый сервер публикует «Agent Card» — JSON-паспорт, доступный по адресу /.well-known/agent-card.json.

Обмен ведётся сообщениями (Message) и/или задачами (Task). Сообщение содержит набор «Part» — от простого текста до бинарного файла или JSON-данных формы. Если задача требует длинного исполнения, сервер создаёт Task с жизненным циклом submitted → working → completed/failed.

Гранулы результата называются Artifacts; ими могут быть отчёты, изображения или таблицы, возвращённые частями по мере готовности. Такой дизайн позволяет аген­там оставаться «чёрными ящиками» — клиенту не нужно знать, какая LLM или какие инструменты скрыты внутри.

Модель взаимодействия

У A2A три режима коммуникации:

• Poll / request-response — классический HTTP вызов message/send с периодическим tasks/get для получения статуса.
• Streaming — серверные SSE-потоки через message/stream; требует флага "streaming": true в Agent Card.
• Push notifications — сервер сам стучится на веб-хук клиента, когда задача завершается или требует дополнительных данных.

gRPC-поддержка появилась лишь в версии 0.3 (1 августа 2025) и резко снизила задержки при межъязыковых вызовах, что особенно актуально для real-time-координации нескольких агентов.

Важно, что протокол предусматривает «переговоры пользовательского опыта»: агенты обмениваются метаданными о том, способен ли клиент отображать видео, формы или, скажем, 3D-сцены, и подбирают формат контента автоматически.

Безопасность и доверие

С релизом 0.3 в A2A добавились подписанные security-cards — криптографические аттестаты, которые позволяют удостовериться, что удалённый агент действительно принадлежит заявленному провайдеру.

Аутентификация запросов базируется на стандартных схемах OAuth 2.0 / OIDC, но протокол не навязывает конкретный механизм — достаточно указать его в Agent Card. Для высокорисковых сценариев (финансы, здоровье) рекомендуется двойная проверка: подпись карты + mTLS на транспортном уровне.

Отдельное внимание уделено защите PII: в спецификации прописан формат «policy tags», которыми агент может помечать поля, содержащие персональные данные, чтобы клиент имел право замаскировать или удалить их до логирования.

Версии, управление и дорожная карта

Ниже — ключевые вехи развития стандарта:

1. v0.1 (Aпрель 2025) — стартовый черновик, HTTP/JSON-API, поддержка SSE.
2. v0.2 (Июнь 2025) — передача проекта Linux Foundation, расширенные типы Part, бета SDK.
3. v0.3 (Август 2025) — gRPC-транспорт, подписанные security-cards, tight-интеграция с ADK.

На публичном роадмапе заявлены WebRTC-каналы для p2p-обмена, кураторские «Agent-директории» и совместимость с будущим OpenLLM Service Mesh Spec.

Управление ведётся через технический Steering Committee, избираемый голосованием контрибьюторов. Крупные изменения проходят трёхступенчатый RFC-процесс и минимум две реализационные референс-имплементации, прежде чем входят в основную ветку.

Экосистема и реальные кейсы

Протокол уже стал частью продуктовых релизов Box AI: компания использует A2A, чтобы комбинировать собственные агенты по обработке документов с внешними моделями Gemini 2.5 Pro, сохраняя при этом сквозные confidence-метрики.

Подключаются и облачные вендоры: Google Cloud выпускает «Agentspace», где A2A служит «шиной», а ADK отвечает за локальное планирование. McDonald's и Verizon тестируют омниканальные ботов-агентов, которые заказывают поставки и синхронизируются с SAP через тот же протокол.

Для хакатонов и POC-проектов достаточно развернуть Python SDK и запускать локальные агенты на Flask или FastAPI; демо-UI из репозитория показывает, как цепочка LangGraph → A2A → CrewAI выполняет сложное задание «собрать пресс-клиппинг + сгенерировать резюме».

Сравнение с альтернативами

MCP (Anthropic) фокусируется на подключении инструментов к модели, тогда как A2A — на «равноправном» общении агентов. При этом оба стандарта не конкурируют, а дополняют друг друга: разработчик может описать набор функций в MCP и вызывать другой агент по A2A, передавая ему контекст.

Существуют и узкозаточенные решения — Autogen RPC от Microsoft или OpenAgents Hub. Они хороши внутри экосистемы, но создают эффект «садовых стен». A2A же намеренно проектировался как высокоуровневый, но расширяемый: часть полей Agent Card объявлены как «extension-friendly», а типы Part можно наращивать без нарушения обратной совместимости.

Наконец, стоит помнить про «старый добрый» gRPC. После появления v0.3 разработчики получают право выбрать «проводной» уровень сами: чистый HTTP + SSE, WebSockets или двоичный gRPC — всё это остаётся A2A, пока соблюдается семантика объектов.

Лучшие практики внедрения

1. Начинайте с Agent Card. Опишите skills, версию и эндпоинт, даже если пока работаете локально. Это избавит от «магических» констант в коде.
2. Разделяйте роли. Пусть один процесс отвечает за A2A-приём и валидацию входящих данных, а «мозг» агента живёт в отдельном контейнере — так проще масштабировать.
3. Следите за состоянием Task. Ошибка многих POC — полагаться на единичный ответ. Реальная бизнес-логика часто требует цепочки input-required → working с check-point'ами.
4. Безопасность по умолчанию. Включите подписи security-cards и проверку mTLS сразу, а не «потом». Так легче пройти аудит.
5. Не бойтесь смешивать A2A и MCP. Выигрыш в продуктив­ности очевиден, когда один агент умеет вызывать инструменты, а другой — фокус-эксперт, который завершает задачу.

Перспективы развития

Переезд под Linux Foundation превращает A2A в де-факто инфраструктурный стандарт: корпоративные ИТ-архитекторы видят в нём долгий жизненный цикл и совместимость. В среднесрочной перспективе (2025–2026 гг.) ожидается появление «каталогов агентов» с поиском по skill-тэгам, а также улучшение потоковой передачи мультимедиа — от SVG-диаграмм до AR-объектов.

Долгосрочная фантазия — Internet of Agents, где «умные» сервисы договариваются напрямую, а пользователям остаётся выдать единый запрос. A2A уже сегодня — первый кирпич этого будущего: спецификация достаточно проста для интеграции и достаточно гибка, чтобы не устареть вместе с очередной LLM.

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