Протокол A2A: как связать ИИ-агентов и когда нужен MCP

Протокол A2A нужен, когда ваш агент передаёт работу другому агенту, которым управляет независимая сторона. Model Context Protocol (MCP) нужен для доступа к инструментам или данным. A2A v1.0 меняет правила интеграции, поэтому при выборе важно учитывать и границу между системами, и версии протокола, которые поддерживают ваши конечные точки.

A2A и MCP: доступ к инструментам или передача работы?

MCP открывает агенту доступ к возможностям внешних систем. A2A позволяет поручить другому агенту часть работы и передать ему ответственность за её выполнение. Оба протокола могут использоваться в одной системе.

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

Пример MCP: найти сведения о заказе

Представим агента службы поддержки, который отвечает на вопрос о доставке. MCP-сервер предоставляет инструмент поиска заказов. Агент передаёт идентификатор заказа, получает данные и составляет ответ клиенту.

Польза для бизнеса — в подключении к системе заказов, которое можно использовать повторно. Вводить ещё одного агента ради получения записи незачем. О подключении инструментов подробнее рассказано в руководстве по MCP-серверам.

Пример A2A: поручить агенту подбор поставщиков

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

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

Сам агент по поиску поставщиков может получать данные каталога через MCP. В такой схеме A2A отвечает за передачу работы, а MCP — за доступ к данным.

Разница заключается в том, какой интерфейс вам нужен. За MCP-инструментом тоже может скрываться сложная логика. Выбирайте A2A, если другая система должна предоставлять интерфейс агента, который позволяет узнавать о его навыках и отслеживать жизненный цикл работы. Сложность внутренних алгоритмов сама по себе не определяет выбор протокола.

Что такое протокол A2A?

A2A — это единый контракт обмена сообщениями для агентов разных разработчиков и на разных фреймворках. Он позволяет обращаться к агенту без доступа к его внутренней памяти, инструментам и логике принятия решений. На сайте протокола эти внутренние механизмы названы непрозрачными. Обзор A2A.

Сторона, отправляющая запрос, — это клиент A2A. Система, принимающая запрос, — сервер A2A, или удалённый агент. Для основателя компании, который подключает специализированный сервис, это означает возможность сосредоточиться на внешнем интерфейсе, не воспроизводя внутреннее устройство чужого решения.

Кто создал A2A и кто управляет проектом?

Официальный сайт формулирует это однозначно: «A2A изначально разработала Google, после чего передала его Linux Foundation». Там же указано, что проект поддерживает Technical Steering Committee — технический руководящий комитет. Таким образом, управление проектом выходит за рамки компании, которая его создала. Управление проектом и открытый исходный код.

В репозитории a2aproject/A2A собраны спецификация, ссылки на SDK и примеры. Сам A2A — это протокол; программное обеспечение для создания и эксплуатации агентов вы по-прежнему выбираете сами.

Спецификация A2A: основные понятия

Прежде всего нужно различать переписку, работу, состояние которой отслеживается, и её результат. Если разделять эти понятия, проектировать систему с A2A проще.

Agent Card: как клиент узнаёт о возможностях агента

Agent Card, или карточка агента, — это JSON-документ с метаданными: сведениями об агенте, его навыках и возможностях, параметрами подключения и требованиями к аутентификации. Карточка помогает клиенту решить, стоит ли обращаться к агенту и как это сделать. Основные понятия.

В примере с закупками карточка может сообщать, что агент умеет исследовать поставщиков. Это отправная точка для интеграции, а не доказательство того, что итоговый список будет соответствовать вашим критериям закупки.

В документации указан стандартный путь обнаружения карточки: /.well-known/agent-card.json. Её также можно получить через прямую настройку подключения или реестр с отобранными агентами. A2A не задаёт стандартный API для таких реестров. Обнаружение агентов.

Задачи, сообщения, части содержимого и артефакты

Задача (task) — это единица работы с сохраняемым состоянием, идентификатором и жизненным циклом. Сообщение (message) — отдельная реплика в обмене. Part содержит непосредственно текст, содержимое файла или ссылку на него либо структурированные данные. Артефакт (artifact) — конкретный результат, созданный при выполнении задачи. Основные понятия.

В примере с поставщиками вопрос «В какой регион нужна доставка?» относится к переписке. Отслеживаемая работа по подбору поставщиков — это задача. Готовый список кандидатов — артефакт. Процесс закупки должен получать этот список как результат работы, а не искать в переписке фрагмент, похожий на окончательный ответ.

Агент может вернуть самостоятельное сообщение или создать задачу. Связанные взаимодействия объединяются по contextId. Когда задача переходит в конечное состояние, уточнение результата запускает новую задачу, а не возобновляет старую. Жизненный цикл задачи.

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

Транспорт: как передаются операции протокола

Транспорт, или привязка протокола к способу передачи (protocol binding), определяет, как операции передаются по соединению. Спецификация описывает привязки JSON-RPC, gRPC и HTTP+JSON/REST. Интерфейсы в Agent Card указывают конечную точку, привязку и версию протокола. Спецификация A2A.

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

Что изменилось в A2A v1.0?

Существующие интеграции нужно проверить на совместимость: одной замены строки версии недостаточно. Ниже перечислены изменения из официального раздела What's New, в котором сравниваются v0.3.0 и v1.0:

• Единое определение: a2a.proto становится основным нормативным определением протокола; для привязок предусмотрены формальные спецификации.
• Новые форматы передачи данных: единый Part заменяет отдельные типы содержимого; вместо дискриминаторов kind используются имена полей, а значения перечислений записываются в SCREAMING_SNAKE_CASE.
• Новая структура Agent Card: supportedInterfaces объединяет сведения о подключении, а версия протокола указывается для каждого интерфейса отдельно.
• Изменения операций: message/send становится SendMessage; ListTasks добавляет получение списка с фильтрацией и курсорной пагинацией.
• Изменения для корпоративных систем: поля арендаторов, правила проверки подписи Agent Card и обновлённые потоки OAuth влияют на проектирование интеграции.

Эти изменения сверены со страницей What's New in v1.0 проекта 12 октября 2026 года.

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

Какие фреймворки и платформы поддерживают A2A?

Реализации с опубликованной документацией уже есть, но поддержка версий и функций у них различается. Выбирайте по требованиям своего рабочего процесса. Перечисленные ниже возможности и ограничения проверены по открытой документации разработчиков 12 октября 2026 года; тестирование продуктов с входом в учётную запись не проводилось.

Google Agent Development Kit

Google Agent Development Kit (ADK), фреймворк для создания агентов, описывает функцию to_a2a, которая открывает доступ к агенту и создаёт его Agent Card. Интеграция A2A для Python помечена как экспериментальная (Experimental). В документации заявлена поддержка a2a-sdk 0.3.x и 1.x.x, а для новых интеграций рекомендуется 1.x.x. Руководство ADK по публикации агента.

ADK также описывает RemoteA2aAgent для обращения к удалённому агенту. Таким образом, разработчику на ADK доступны документированные средства для обеих сторон взаимодействия. При принятии решения о развёртывании следует учитывать экспериментальный статус интеграции, даже если пользоваться обёрткой удобно. Руководство ADK по вызову удалённого агента.

LangGraph через LangSmith Agent Server

LangSmith Agent Server — серверный слой, описанный для развёртывания LangGraph, — предоставляет конечную точку A2A по пути /a2a/{assistant_id}. В документации указаны привязка JSON-RPC версии v1.0 и поддержка имён методов v0.3. В состоянии графа должно быть поле messages. Документация LangSmith по A2A.

На той же странице перечислены ограничения: gRPC и HTTP+JSON не реализованы, а SubscribeToTask и настройка push-уведомлений пока не поддерживаются. Потоковая передача сообщения есть, но из этого не следует, что доступны все операции подписки и уведомлений. Поэтому перед проектированием фоновых задач нужно проверить, какие именно операции реализованы.

CrewAI и CrewAI AMP

CrewAI, фреймворк для координации агентов, описывает A2AClientConfig для передачи работы удалённому агенту и A2AServerConfig для предоставления доступа к собственным агентам. Один агент может быть настроен на обе роли. Документация CrewAI по делегированию.

Платформа развёртывания CrewAI AMP помечает серверных агентов A2A как ранний релиз (early release) и указывает версии протокола 0.2 и 0.3. В документации также описано постоянное распределённое хранилище, которое заменяет хранение состояния в памяти, используемое в реализации с открытым исходным кодом. Наличие поддержки A2A в CrewAI не означает, что конечная точка AMP поддерживает v1.0. A2A в AMP.

Microsoft Foundry Agent Service

Microsoft Foundry Agent Service, управляемая платформа агентов, описывает общедоступный тип инструмента a2a для протокола 1.0. Более старый тип a2a_preview поддерживает 0.3 и остаётся в статусе предварительной версии. Для новых интеграций Microsoft рекомендует общедоступный тип. Документация Foundry по A2A.

На странице также указано, что целевые агенты Foundry поддерживают только текст и не поддерживают потоковую передачу ответов. Если вашему процессу нужен мультимедийный результат с потоковой передачей, это ограничение необходимо учитывать. Типы содержимого, допустимые в протоколе, не гарантируют их поддержку каждой платформой размещения.

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

Что A2A даёт разработчикам, командам эксплуатации и заказчикам?

Преимущество — в интерфейсе интеграции, который проще использовать повторно, если эксплуатация дополнительного сервиса себя оправдывает. Практические выводы зависят от того, кто принимает решение.

Разработчикам: определите, какую работу вы делегируете, прежде чем добавлять транспорт. «Подготовь список кандидатов с источниками и обоснованием» — задача для отдельного сервиса. «Выполни этот поиск в базе данных» — обращение к инструменту. Сохраняйте это различие, даже если оба запроса в итоге вызывают модели.

Командам эксплуатации: назначьте ответственного за задачу после её передачи. В примере с закупками кто-то должен решить, что делать, если агент по подбору поставщиков запрашивает дополнительные сведения, перестаёт отвечать или возвращает список, который не проходит приёмку. Общий формат сообщений не распределяет эту ответственность.

Заказчикам и основателям компаний: запрашивайте сведения о поддерживаемой версии протокола, привязке, операциях, типах содержимого и статусе готовности решения к развёртыванию. Сопоставляйте их с требованиями своего процесса. Одного заявления о совместимости без этих подробностей недостаточно, чтобы брать на себя обязательства по интеграции.

Как оценить бюджет внедрения A2A?

Для A2A нет единой конфигурации развёртывания, по которой можно рассчитать месячные расходы. У размещённого у провайдера специализированного агента и сервиса, который вы эксплуатируете сами, разные статьи затрат. Документация протокола не устанавливает универсальную цену платформы.

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

Чистая выгода от интеграции = сэкономленные расходы на коннекторы минус затраты на миграцию, дополнительную инфраструктуру и текущую эксплуатацию.

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

Какие ожидания от A2A завышены?

Общий протокол не делает незнакомых агентов заслуживающими доверия и не обеспечивает надёжность распределённой работы автоматически. Стандартизация полезна, но решения на уровне приложения остаются за вами.

Agent Card сообщает, что предлагает сервис. Доверять ли его оператору и принимать ли результат, решаете вы. Корпоративные рекомендации A2A возлагают проверку аутентификации и авторизации на реализацию, включая контроль прав на действия, выполняемые за интерфейсом. Рекомендации по внедрению в корпоративных системах.

В процессе подбора поставщиков разрешение на исследование не должно незаметно превращаться в право совершать закупки. Подготовка рекомендации и оформление заказа должны требовать разных разрешений в вашем приложении.

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

Ещё одно избыточное решение — добавлять A2A к каждому внутреннему вызову субагента. Сам проект явно исключает из своей области действия правила внутренних вызовов субагентов и инструментов. Если компоненты работают в рамках единого контракта приложения, встроенных средств их композиции во фреймворке уже может быть достаточно. Область применения A2A.

Что выбрать: A2A, MCP или оба протокола?

Начните с границы между системами, которая уже существует в вашем продукте.

Выбирайте MCP, когда агенту нужен доступ к бизнес-системам, файлам или API через повторно используемые интерфейсы инструментов. Если вы хотите сами открыть доступ к функции, воспользуйтесь руководством по созданию MCP-сервера на Python. Когда возникнет задача управлять доступом через эти подключения, пригодится разбор MCP-шлюзов.

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

Выбирайте оба протокола, когда ваш агент передаёт работу специалисту, которому также нужны инструменты и данные. Пример с подбором поставщиков устроен именно так: A2A — для порученного исследования, MCP — для доступа к каталогу внутри агента.

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

С чего начать реализацию?

Опишите контракт передачи работы для конкретного бизнес-результата, прежде чем менять остальной стек. Для помощника по закупкам начните со списка подходящих поставщиков, оставив само оформление закупки за рамками первого этапа.

1. 1

   Определите критерии приёмки артефакта

   Укажите, какие сведения должен содержать список поставщиков, при каких условиях он неприемлем и какое приложение фиксирует принятый результат. Чётко ограничьте ответственность удалённого агента.

2. 2

   Сопоставьте документированные интерфейсы

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

3. 3

   Продумайте случаи, когда работа не завершена

   Решите, кто обрабатывает уточнения, тайм-ауты, отклонения и неоднозначный ответ после повторной попытки. Определите, что видит пользователь, пока работа не завершена, и как доработанный артефакт заменяет предыдущий.

Такой контракт даёт конкретное основание для внедрения A2A. Если при его составлении выяснится, что предполагаемый специалист лишь получает запись, начните с подключения инструмента.

Вопросы перед внедрением A2A

Можно ли использовать A2A без MCP?

Да. A2A не определяет, как удалённый агент обращается к своим инструментам и данным. MCP полезен, когда требуется ещё и стандартизация подключения инструментов. Как протоколы работают вместе.

Должны ли оба агента использовать один фреймворк?

Нет. Взаимодействие агентов на разных фреймворках — одна из основных целей A2A. Согласовать нужно внешний интерфейс и функции, необходимые для взаимодействия, а не внутреннюю реализацию агентов. Обзор A2A.

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