A2A Protocol: полное руководство по внедрению меж-агентного протокола (2026)

Что такое A2A Protocol

A2A (Agent-to-Agent Protocol) — открытый протокол, который позволяет AI-агентам общаться напрямую, без общего кода, фреймворка или базы данных. Представьте: один агент написан на LangGraph, другой — на CrewAI, третий — кастомный на Python. Без A2A их интеграция требует ручного REST API, общей базы или шины сообщений. С A2A каждый агент публикует Agent Card — JSON-файл, в котором описано, что он умеет, как с ним связаться и какие форматы данных принимает. Другие агенты находят эту карточку, устанавливают соединение по HTTP/SSE и обмениваются задачами.

Протокол родился в 2025 году как инициатива Google, но уже в апреле 2025 года был передан под управление Linux Foundation. К апрелю 2026 года — чуть больше чем за год — A2A поддерживают 150+ организаций, включая Adobe, Microsoft, SAP и ServiceNow. IBM, у которой был собственный конкурирующий стандарт ACP (Agent Communication Protocol), влилась в A2A. Версия 1.0.0 спецификации стабильна, SDK есть для Python, Go и TypeScript.

Gartner прогнозирует, что к концу 2026 года 40% корпоративных приложений будут интегрировать AI-агентов. A2A — один из ключевых протоколов, который делает такую интеграцию возможной между агентами разных вендоров.

Архитектура протокола: Agent Card, Task и Message

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

Agent Card — это визитная карточка агента. JSON-документ, доступный по URL, в котором указаны: название агента, описание умений (skills), поддерживаемые форматы данных (text, file, form), URL для отправки задач, ключ для аутентификации. Агент публикует карточку в реестре (или просто вешает на свой эндпоинт), и клиенты читают её, чтобы понять, как с ним общаться. Agent Card — это аналог robots.txt или OpenAPI-спецификации, но для AI-агентов.

Task — основная единица работы в A2A. Клиентский агент создаёт задачу, отправляет её агенту-исполнителю и отслеживает её жизненный цикл. Задача проходит через строго определённые состояния: submitted (отправлена), working (выполняется), input-required (нужны уточнения), completed (завершена), failed (ошибка). Протокол поддерживает как синхронный режим (задача выполняется мгновенно), так и асинхронный (результат приходит через SSE Streaming).

Message — данные, которыми обмениваются агенты в рамках задачи. Каждое сообщение содержит role (client или agent), контент (текст, файл, JSON) и необязательные метаданные. Сообщения формируют лог взаимодействия — полную историю того, как агенты пришли к результату.

Архитектура A2A спроектирована так, что агенты остаются «непрозрачными» — протокол не требует доступа к внутреннему состоянию, памяти или инструментам агента. Всё, что нужно знать клиенту: Agent Card и API для управления задачами. Ниже — упрощённая схема того, как агент-клиент взаимодействует с удалённым агентом через A2A:

Как выглядит жизненный цикл задачи

Клиент находит Agent Card агента (по URL или через реестр). Отправляет POST-запрос на эндпоинт assignTask с описанием задачи. Агент принимает задачу в статусе submitted, переводит в working и начинает выполнение. Если агенту не хватает данных — он запрашивает уточнение (status input-required). Клиент может отправить дополнительное сообщение. Когда задача выполнена — статус меняется на completed, а в ответе приходит артефакт (текст, файл, структура).

Для долгих задач A2A использует SSE Streaming — клиент подписывается на эндпоинт задачи и получает обновления по мере генерации ответа. Для коротких — достаточно одного HTTP-запроса. Такой подход делает протокол одинаково удобным для QA-бота (ответ за секунду) и анализатора документов (обработка несколько минут).

A2A vs MCP: не конкуренты, а стек

Одна из самых частых ошибок — противопоставлять A2A и MCP. На деле это разные уровни одного стека. MCP отвечает за agent-to-tool — как агент подключает базу данных, файловую систему или API. A2A отвечает за agent-to-agent — как один агент делегирует задачу другому. MCP — это драйверы и периферия, A2A — сетевой протокол между узлами.

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

Выбор между A2A и MCP — ложный. Стек выглядит так: на нижнем уровне MCP подключает инструменты (БД, API, файлы), на верхнем уровне A2A соединяет агентов, каждый из которых использует свои MCP-инструменты. Аналитики Zylos (март 2026) описывают это как трёхуровневый стек: MCP для инструментов — WebMCP для веба — A2A для агентов.

Установка и настройка Python SDK

Для работы с A2A на Python есть два основных SDK. Официальный — a2a-sdk от проекта A2A (версия 1.1.0, Python 3.10+). Альтернатива — python-a2a с открытыми исходниками, который добавляет интеграцию с LangChain и MCP.

Начнём с официального SDK:

pip install a2a-sdk

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

python -c "from a2a_sdk import A2AClient; print('OK')"

Если ошибок нет — всё готово. SDK предоставляет классы A2AClient (для отправки задач), AgentCard (для описания агента) и A2AServer (для создания агента-исполнителя).

Для установки с расширенными возможностями (SSE streaming, поддержка корутин):

pip install a2a-sdk[streaming]

Альтернативный SDK — python-a2a (документация). Основное преимущество — встроенная интеграция с MCP и LangChain:

pip install python-a2a

Эта библиотека также включает визуальный редактор Agent Flow UI для построения сетей агентов перетаскиванием — полезно для прототипирования, но в production вряд ли пригодится.

Создаём A2A-агента на Python

Рассмотрим минимальный сценарий: один агент (клиент) отправляет задачу другому агенту (исполнителю) через A2A.

Шаг 1: создаём агента-исполнителя

Агент-исполнитель — это просто веб-сервер, который реализует эндпоинты A2A-спецификации. На официальном SDK:

from a2a_sdk import A2AServer, AgentCard

# Конфигурация агента
card = AgentCard(
    name="ResearchAgent",
    description="Ищет информацию по заданной теме",
    url="http://localhost:8000",
    skills=["web_search", "data_summarize"]
)

server = A2AServer(agent_card=card, port=8000)

# Обработчик задач
@server.on_task
async def handle_task(task):
    topic = task.input["topic"]
    result = f"Найденные данные по теме: {topic}"
    return {"status": "completed", "artifact": {"text": result}}

server.run()

Этот код запускает HTTP-сервер на порту 8000 с A2A-эндпоинтами (Agent Card по /.well-known/agent.json, assignTask, getTask, sendMessage). Другие A2A-агенты могут находить его и отправлять задачи.

Шаг 2: создаём агента-клиента

Клиент читает Agent Card удалённого агента и отправляет задачу:

from a2a_sdk import A2AClient

client = A2AClient()

# Читаем Agent Card удалённого агента
agent_card = client.fetch_agent_card(
    "http://localhost:8000/.well-known/agent.json"
)
print(f"Агент: {agent_card.name}")
print(f"Умения: {agent_card.skills}")

# Создаём задачу
task = client.create_task(
    agent_url="http://localhost:8000",
    input={"topic": "AI-агенты в enterprise 2026"}
)

print(f"Статус: {task.status}")
print(f"Результат: {task.artifact['text']}")

Всё взаимодействие — через HTTP. Клиент не знает, на каком фреймворке написан агент, какие LLM он использует и какие у него инструменты. Только Agent Card и API.

Шаг 3: обработка уточнений

Если агенту не хватает данных, он переводит задачу в статус input-required. Клиент может отправить уточнение:

if task.status == "input-required":
    task = client.send_message(
        task_id=task.id,
        content={"clarification": "искать источники только за 2026 год"}
    )
    print(f"Новый статус: {task.status}")

Этот паттерн — ключевое отличие A2A от простого API: взаимодействие может быть многошаговым, как диалог между двумя разработчиками. И при этом каждый агент остаётся «чёрным ящиком» — ни один не видит код или данные другого.

Enterprise-внедрение: кейсы и цифры

Год с момента запуска — достаточный срок, чтобы оценить, как A2A работает в production. Данные из апрельского отчёта Linux Foundation и обзоров AgentMarketCap (апрель 2026):

Что интересно — распределение кейсов. В enterprise A2A используют не для замены людей, а для соединения уже существующих AI-агентов в единую цепочку, где один агент может делегировать задачу другому, не дожидаясь, пока разработчик напишет интеграцию. Adobe внедрила A2A для связки AI-агентов в Creative Cloud, Microsoft — в Azure AI Foundry, SAP — для SAP BTP агентов.

Ailoitte (июнь 2026) выделяет три типовых сценария: RAG-пайплайн, где один агент ищет информацию, а второй генерирует ответ на основе найденного; multi-agent экспертная система, где несколько узкопрофильных агентов собирают решение из своих фрагментов; и голосовые ассистенты, требующие распознавания, поиска и синтеза речи в одном потоке.

Безопасность и A2A: Agent Card и верификация

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

Каждый Agent Card может содержать ключ аутентификации: API-ключ, JWT-токен или ссылку на OAuth-провайдера. Агент-клиент перед отправкой задачи проверяет, аутентифицирован ли удалённый агент и можно ли ему доверять. HTTPS — mandatory. SSE-стримы шифруются.

Но главная особенность A2A в том, что он не раскрывает внутреннее устройство агента. Протокол обменивается только задачами и артефактами — никаких промптов, никаких данных о модели, никаких ключей к MCP-инструментам. Если агент A просит агента B найти информацию — B не видит, какие ещё инструменты есть у A, какие у него промпты и какие данные он хранит.

На практике это означает, что enterprise может подключить к A2A-сети внешнего агента (SaaS, партнёрский сервис) без риска, что тот прочитает внутренние данные. Всё, что получает внешний агент — описание задачи, которую ему отправляют. Ответ приходит структурированным артефактом, и только.

Когда внедрять A2A, а когда достаточно MCP

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

Но есть признаки, что пора внедрять A2A: у вас больше одного агента, каждый специализирован на своей задаче (например, поиск в БД + генерация отчётов + проверка качества); агенты написаны на разных фреймворках и их кодовая база не пересекается; вы хотите подключать внешние агенты (SaaS, партнёрские решения) без написания кастомных интеграций; требуется оркестрация с возможностью делегировать часть работы и получать промежуточные результаты.

По данным WebNuz (март 2026), оптимальная архитектура для enterprise — трёхуровневый стек: MCP для инструментов, A2A для агентов, единый Agent Registry для обнаружения. Эта схема покрывает 90% production-кейсов, от простого чат-бота до multi-agent пайплайна с десятком узлов.

Коротко

A2A Protocol — открытый стандарт для прямого общения AI-агентов, поддерживаемый Linux Foundation, 150+ организациями и всеми тремя крупными облачными платформами. A2A решает задачу agent-to-agent, тогда как MCP — agent-to-tool. На Python SDK можно поднять A2A-агента за 20 строк кода, а сценарии внедрения варьируются от простой связки двух агентов до enterprise-оркестрации с Agent Registry. Если у вас больше одного агента — A2A стоит рассматривать уже сейчас.

Что ещё важно знать