A2A (Agent2Agent Protocol): что это и чем отличается от MCP

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

Протокол разработала Google, а в июне 2025 года передала проект Linux Foundation. Спецификацию ведёт Technical Steering Committee с представителями AWS, Cisco, Google, IBM Research, Microsoft, Salesforce, SAP и ServiceNow. Код открыт под лицензией Apache 2.0 в репозитории a2aproject/A2A — на 9 ноября 2026 года около 26,5 тыс. звёзд. Актуальный релиз — v1.0.1 от 28 мая 2026 года.

Зачем нужен A2A

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

A2A убирает эту привязку. Агент публикует описание возможностей и эндпоинт по общему формату, вызов оформляется как задача с отслеживаемым состоянием, результат приходит артефактом. Поэтому агент на LangGraph, CrewAI или Semantic Kernel общается с агентом на другом стеке без адаптера под каждую пару.

Как это работает

Клиент (client) — приложение или агент, который инициирует запрос. Удалённый агент (remote agent, server) — система, которая публикует HTTP-эндпоинт и выполняет задачи. Пользователем может быть и человек, и автоматический сервис.

Пользователь
    │  цель
    ▼
Клиентский агент ──1. GET /.well-known/agent-card.json──▶ Удалённый агент
    │                     ◀── Agent Card: навыки, эндпоинт, схемы ──
    │
    ├──2. SendMessage (JSON-RPC 2.0, задача) ──────────────▶
    │                     ◀── Task: TASK_STATE_WORKING ────
    │
    ├──3a. SSE-поток обновлений статуса и артефактов ◀─────
    └──3b. или push-уведомление на webhook клиента ◀───────
                          ◀── Task: TASK_STATE_COMPLETED,
                              Artifact с результатом ───────

1. Обнаружение. Клиент запрашивает Agent Card по адресу /.well-known/agent-card.json и узнаёт, что агент умеет, куда обращаться и какие схемы аутентификации принимает.
2. Задача. Клиент отправляет сообщение методом SendMessage. На короткую работу агент отвечает сразу сообщением, на длинную создаёт Task с id и contextId.
3. Наблюдение. Статус приходит опросом через GetTask, потоком Server-Sent Events (SendStreamingMessage, SubscribeToTask) или push-уведомлениями на webhook.
4. Результат. Готовый результат приходит как Artifact — документ, изображение или структурированные данные из частей Part.

Ключевые объекты

Жизненный цикл задачи идёт от TASK_STATE_SUBMITTED и TASK_STATE_WORKING через промежуточные TASK_STATE_INPUT_REQUIRED и TASK_STATE_AUTH_REQUIRED к одному из терминальных: TASK_STATE_COMPLETED, TASK_STATE_FAILED, TASK_STATE_CANCELED или TASK_STATE_REJECTED. Завершённая задача неизменяема: уточнение оформляется новой задачей в том же contextId, а ссылка на исходную передаётся в referenceTaskIds.

Пример Agent Card

Сокращённый пример из спецификации: агент планирует маршруты и объявляет один навык.

{
  "name": "GeoSpatial Route Planner Agent",
  "description": "Планирование маршрутов с учётом пробок и построение карт.",
  "supportedInterfaces": [
    {"url": "https://georoute-agent.example.com/a2a/v1", "protocolBinding": "JSONRPC", "protocolVersion": "1.0"},
    {"url": "https://georoute-agent.example.com/a2a/grpc", "protocolBinding": "GRPC", "protocolVersion": "1.0"}
  ],
  "version": "1.2.0",
  "capabilities": {
    "streaming": true,
    "pushNotifications": true
  },
  "securitySchemes": {
    "google": {
      "openIdConnectSecurityScheme": {
        "openIdConnectUrl": "https://accounts.google.com/.well-known/openid-configuration"
      }
    }
  },
  "security": [{"google": ["openid", "profile", "email"]}],
  "defaultInputModes": ["application/json", "text/plain"],
  "defaultOutputModes": ["application/json", "image/png"],
  "skills": [
    {
      "id": "route-optimizer-traffic",
      "name": "Traffic-Aware Route Optimizer",
      "description": "Считает оптимальный маршрут между точками с учётом пробок.",
      "tags": ["maps", "routing", "traffic"]
    }
  ]
}

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

Транспорт

Спецификация v1.0 делится на три слоя: каноническая модель данных, абстрактные операции (SendMessage, SendStreamingMessage, GetTask, ListTasks, CancelTask, SubscribeToTask, GetExtendedAgentCard) и привязки к транспорту. Основная привязка — JSON-RPC 2.0 поверх HTTP(S), потоковые ответы приходят как text/event-stream. Есть также gRPC и HTTP+JSON/REST; расширения описываются отдельно, чтобы не менять ядро.

A2A против MCP

Протоколы решают разные задачи и не конкурируют. MCP (Model Context Protocol) стандартизует связь агента с инструментами и данными, A2A — связь агента с другим агентом.

В одной системе они работают вместе. Агент-оркестратор сам ходит в базы и файлы через MCP, а специализированные агенты (ревью кода, поиск по документации, биллинг) вызываются по A2A. Каждый такой агент внутри тоже может использовать MCP для своих инструментов — протоколы складываются. С ACP (Agent Client Protocol) путаницы ещё меньше: ACP описывает связку «редактор — coding-агент», а не «агент — агент».

Где применяется

• Оркестратор и специалисты. Главный агент разбирает запрос на подзадачи и делегирует их узким агентам: один ищет в базе, второй проверяет код, третий формирует счёт. Каждый ведёт свою задачу, оркестратор собирает артефакты.
• Межвендорные цепочки. Агент компании вызывает агента партнёра — для проверки контрагента или бронирования, — не получая доступа к его внутренней кухне.
• Мультиагентные системы в энтерпрайзе. Команды строят агентов на своих фреймворках и связывают их по одному стандарту. Подробнее — в статьях про мультиагентные ИИ-системы и оркестрацию ИИ-агентов.

Связь с RouterAI

A2A стандартизует вызов агента, но не говорит, какая модель за ним стоит. Модель по-прежнему обращается к API провайдера, и в цепочке из нескольких агентов это превращается в набор разных ключей и счетов. Здесь помогает RouterAI — единый шлюз с OpenAI-совместимым API (https://routerai.ru/api/v1) и Anthropic Messages API (https://routerai.ru/api).

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

from openai import OpenAI

client = OpenAI(
    base_url="https://routerai.ru/api/v1",
    api_key="sk-xxxxxxxxxxxxxxxx",
)

# Внутренний обработчик навыка A2A-агента
def handle_task(skill: str, text: str) -> str:
    resp = client.chat.completions.create(
        model="anthropic/claude-sonnet-5.5",
        messages=[{"role": "user", "content": text}],
    )
    return resp.choices[0].message.content

Модели удобно распределять по ролям. Цены — по каталогу RouterAI за 1 млн токенов, вход / выход, в рублях:

RouterAI работает из России без VPN, оплата в рублях, ключ один на все модели каталога. Как держать запасную модель — в статье про fallback routing.

Безопасность

Агенты в A2A непрозрачны, поэтому безопасность строится на обычных веб-механизмах: HTTPS обязателен, TLS не ниже 1.2, сертификат сервера проверяется.

• Аутентификация вне протокола. В JSON-RPC-сообщениях нет личности: токены передаются в HTTP-заголовках (Authorization: Bearer ...) и получаются через OAuth 2.0 или OpenID Connect отдельным потоком. Требования агент объявляет в Agent Card.
• Права по навыкам. Scope OAuth привязывается к конкретным skills: один навык разрешён, другой нет. Плюс принцип минимальных привилегий на действия с внутренними системами.
• Дополнительные учётные данные. Если во время задачи нужен доступ в стороннюю систему от имени пользователя, агент переводит задачу в TASK_STATE_AUTH_REQUIRED, а клиент добывает и передаёт вторые учётные данные.
• Риск публичной карточки. Agent Card раскрывает навыки, версии, эндпоинт и схемы аутентификации — это удобно для обнаружения и полезно атакующему. Для внутренних возможностей предусмотрена расширенная карточка (extendedAgentCard), которая отдаётся только после входа.

Что почитать

• A2A Protocol — сайт и документация протокола, раздел Core Concepts
• Спецификация A2A — объекты, методы, привязки и примеры
• a2aproject/A2A — репозиторий, SDK для Python, JavaScript, Java, C#/.NET, Go и Rust
• MCP (Model Context Protocol) — протокол агента с инструментами
• ACP (Agent Client Protocol) — протокол между редактором и coding-агентом