# 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](https://github.com/a2aproject/A2A) — на 9 ноября 2026 года около 26,5 тыс. звёзд. Актуальный релиз — v1.0.1 от 28 мая 2026 года.

## Зачем нужен A2A {#zachem}

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

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

## Как это работает {#kak-rabotaet}

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

```text
Пользователь
    │  цель
    ▼
Клиентский агент ──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`.

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

| Объект | Что это | Основные поля |
|---|---|---|
| **Agent Card** | JSON-визитка агента: кто он, что умеет, куда обращаться | `name`, `description`, `supportedInterfaces`, `capabilities`, `skills`, `securitySchemes` |
| **Task** | Единица работы с жизненным циклом | `id`, `contextId`, `status`, `artifacts`, `history` |
| **Message** | Один ход диалога | `role` (`user` или `agent`), `messageId`, `parts` |
| **Part** | Контейнер содержимого: текст, файл или JSON | `text`, `raw`, `url`, `data`, `mediaType` |
| **Artifact** | Итоговый результат задачи | `artifactId`, `name`, `parts` |

Жизненный цикл задачи идёт от `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

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

```json
{
  "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 {#protiv-mcp}

Протоколы решают разные задачи и не конкурируют. [MCP (Model Context Protocol)](/pages/mcp-model-context-protocol) стандартизует связь агента с инструментами и данными, A2A — связь агента с другим агентом.

| | MCP | A2A |
|---|---|---|
| Между кем | агент ↔ инструменты, API, данные | агент ↔ независимый агент |
| Что передаёт | вызовы инструментов, ресурсы, промпты | задачи, сообщения, артефакты, статусы |
| Кто выполняет работу | ваш процесс или сервер инструментов | удалённый агент со своей моделью и логикой |
| Что видно второй стороне | схему инструмента и аргументы | Agent Card: навыки, эндпоинт, схемы аутентификации |

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

## Где применяется {#gde-primenyayut}

- **Оркестратор и специалисты.** Главный агент разбирает запрос на подзадачи и делегирует их узким агентам: один ищет в базе, второй проверяет код, третий формирует счёт. Каждый ведёт свою задачу, оркестратор собирает артефакты.
- **Межвендорные цепочки.** Агент компании вызывает агента партнёра — для проверки контрагента или бронирования, — не получая доступа к его внутренней кухне.
- **Мультиагентные системы в энтерпрайзе.** Команды строят агентов на своих фреймворках и связывают их по одному стандарту. Подробнее — в статьях про [мультиагентные ИИ-системы](/pages/multiagentnye-ii-sistemy) и [оркестрацию ИИ-агентов](/pages/orkestraciya-ii-agentov).

## Связь с RouterAI {#routerai}

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

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

```python
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](/models) за 1 млн токенов, вход / выход, в рублях:

| Модель | Для чего в цепочке | Цена, ₽ |
|---|---|---|
| `anthropic/claude-sonnet-5.5` | оркестратор: разбор задачи, вызовы агентов, длинный контекст | 213,6 / 1067,8 |
| `anthropic/claude-haiku-5.5` | быстрые навыки: классификация, короткие ответы, проверки | 10,7 / 53,4 |
| `openai/gpt-5.5` | сложные рассуждения и планирование | 533,9 / 3203,4 |
| `google/gemini-3.1-pro-preview` | длинный контекст, разбор документов и таблиц | 213,6 / 1281,4 |
| `deepseek/deepseek-v4-flash` | дешёвый массовый навык с большим числом вызовов | 10,1 / 20,3 |

RouterAI работает из России без VPN, оплата в рублях, ключ один на все модели каталога. Как держать запасную модель — в статье про [fallback routing](/pages/perekluchenie-mezhdu-neyrosetyami-fallback-routing).

## Безопасность {#bezopasnost}

Агенты в 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`), которая отдаётся только после входа.

## Что почитать {#chto-pochitat}

- [A2A Protocol](https://a2a-protocol.org/) — сайт и документация протокола, раздел [Core Concepts](https://a2a-protocol.org/latest/topics/key-concepts/)
- [Спецификация A2A](https://a2a-protocol.org/latest/specification/) — объекты, методы, привязки и примеры
- [a2aproject/A2A](https://github.com/a2aproject/A2A) — репозиторий, SDK для Python, JavaScript, Java, C#/.NET, Go и Rust
- [MCP (Model Context Protocol)](/pages/mcp-model-context-protocol) — протокол агента с инструментами
- [ACP (Agent Client Protocol)](/pages/acp-agent-client-protocol) — протокол между редактором и coding-агентом