A2A Protocol (Google):
стандарт коммуникации агентов по HTTP

Проблема: агенты-острова

Внутри одной системы агенты понимают друг друга — они написаны на одном фреймворке, делят state или обмениваются сообщениями в общей памяти (урок про shared state vs messages). Но экосистема агентов взрывообразно растёт: разные компании, разные фреймворки (LangGraph, CrewAI, AutoGen), разные облака. Как чужому агенту вызвать твоего? Как твоему найти и использовать сторонний агент-сервис?

Без стандарта каждая пара агентов требует кастомной интеграции: свои форматы, свои эндпоинты, своя аутентификация. N агентов — до N² несовместимых «переходников». Это ровно та проблема, которую в вебе решил HTTP, а для инструментов LLM — MCP (модуль 02): единый протокол вместо зоопарка интеграций. A2A делает то же для общения агентов между собой.

A2A: HTTP для агентов

A2A — открытый протокол (изначально от Google, передан в Linux Foundation), задающий, как агенты находят друг друга и обмениваются задачами по сети. Каждый агент выставляется как HTTP-сервис с известной «визиткой» и стандартным API. Другой агент (или оркестратор) читает визитку, понимает, что тот умеет, и шлёт ему задачу — не зная и не заботясь, на чём он написан.

Четыре кита A2A:

• Agent Card — «визитка» агента: JSON по адресу /.well-known/agent.json, где описано, кто он, что умеет (skills), как к нему обращаться и аутентифицироваться. Механизм обнаружения (следующий урок раскроет детально).
• HTTP + JSON-RPC — транспорт: обычные HTTP-запросы, метод вроде message/send. Никакой экзотики — тот же стек, что у веб-API.
• Task (задача) — единица работы с жизненным циклом: submitted → working → (input-required) → completed/failed. Долгие задачи можно отслеживать.
• Modality-agnostic — обмен не только текстом: части сообщений (parts) могут быть текстом, файлами, структурированными данными.

Как выглядит обмен

Схема простая и знакомая по вебу: обнаружил → отправил задачу → получил результат. Клиент сначала читает Agent Card, чтобы понять возможности и адрес, потом шлёт задачу через JSON-RPC.

# 1. DISCOVERY — читаем визитку агента
GET https://research-agent.example.com/.well-known/agent.json

# ответ — Agent Card:
{
  "name": "Research Agent",
  "description": "Ищет и суммаризует информацию",
  "url": "https://research-agent.example.com/a2a",
  "skills": [{ "id": "web_research", "description": "поиск и выжимка по теме" }],
  "capabilities": { "streaming": true },
  "authentication": { "schemes": ["bearer"] }
}

# 2. SEND — отправляем задачу через JSON-RPC (метод message/send)
POST https://research-agent.example.com/a2a
{
  "jsonrpc": "2.0", "id": 1, "method": "message/send",
  "params": {
    "message": {
      "role": "user",
      "parts": [{ "kind": "text", "text": "Собери факты про рынок EV 2025" }]
    }
  }
}

# 3. ответ — Task с результатом и статусом (working → completed)

Обрати внимание: клиенту всё равно, что research-agent внутри написан на LangGraph, а он сам — на CrewAI. Они говорят на общем «языке» HTTP+JSON-RPC. Это и есть смысл стандарта: интероперабельность — агенты разных вендоров работают вместе без кастомных переходников.

Жизненный цикл задачи

Ключевое отличие A2A от простого «запрос-ответ» — задачи могут быть долгими. Агент-исследователь может работать минуты, агент-аналитик — запросить уточнение. Поэтому у Task есть состояния, которые клиент отслеживает:

submitted  — задача принята
    │
    ▼
working    — агент выполняет (можно стримить прогресс)
    │
    ├──▶ input-required — нужен ответ от клиента → и снова working
    │
    ▼
completed  — готово, есть результат (artifacts)
    │
    └──▶ failed / canceled — ошибка или отмена

Это делает A2A пригодным для реальной совместной работы, а не только быстрых вызовов: долгие задачи, стриминг прогресса (SSE), запрос доп. информации у клиента посреди работы (тот самый human-in-the-loop, но между агентами). Результат приходит в виде artifacts — структурированных выходов задачи.

Зачем это важно

A2A превращает агентов из «функций в моём коде» в сервисы в общей экосистеме. Практические следствия:

• Интероперабельность вендоров: агент от одной компании вызывает агент от другой — без интеграционного проекта под каждую пару.
• Композиция систем: из готовых агентов-сервисов собираются большие пайплайны (оркестратор + специалисты по A2A) — привет масштабируемости.
• Инкапсуляция: внутренности агента (промпты, инструменты, модель) скрыты за протоколом — снаружи виден только контракт Agent Card.
• Рынок агентов: появляется возможность «маркетплейсов» — публикуешь агента, другие находят и используют по стандарту.

Типичные ошибки

Шпаргалка

ЧТО: открытый протокол общения агент↔агент по HTTP («HTTP для агентов»)
  (Google → Linux Foundation) · интероперабельность между вендорами/фреймворками

A2A vs MCP:
  MCP — агент → ИНСТРУМЕНТ (руки)
  A2A — агент ↔ АГЕНТ (коллеги)
  часто вместе: агент = A2A-сервис снаружи + MCP-клиент внутри

4 КИТА:
  Agent Card — визитка /.well-known/agent.json (кто, skills, url, auth) → DISCOVERY
  HTTP + JSON-RPC — транспорт (метод message/send)
  Task — задача с ЖИЗНЕННЫМ ЦИКЛОМ (submitted→working→completed/failed)
  parts/artifacts — текст, файлы, структурированные данные

ПОТОК: читаю Agent Card → шлю задачу (message/send) → статусы → artifacts
  долгие задачи · стриминг (SSE) · input-required (уточнение по ходу)

ЗАЧЕМ: интероперабельность · композиция сервисов · инкапсуляция · рынок агентов

СВЯЗЬ: A2A = message passing, выросший в СЕТЕВОЙ стандарт (агенты-сервисы)

ГРАБЛИ:
  • A2A ≠ MCP (агент↔агент vs агент→инструмент)
  • в одном процессе A2A не нужен (хватит state/messages)
  • аутентификация обязательна (агент = сетевой сервис)
  • долгие задачи → обрабатывай lifecycle, не жди синхронного ответа

Практическое задание

Разберись с протоколом на практике (концептуально/по докам):

Что дальше

A2A стоит на «визитке» агента — Agent Card. Она заслуживает отдельного разбора: как агент декларирует свои возможности, как клиенты его находят и по каким полям выбирают. Это следующий урок.