Протокол A2A: общий язык агентов, паспорт исполнителя и спор о зрелости

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

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

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

Дневник курса, урок 10. Отсюда пригодится разобранное раньше: устройство агента (урок 1) — что именно прячется за карточкой чужого исполнителя; когда команда агентов окупается (урок 8) — стоит ли заводить второго агента прежде, чем связывать его с первым; модель угроз агента (урок 9) — откуда берётся доверчивость к соседу по контуру. Пост читается отдельно: все термины вводятся заново.

1. Зачем агентам общий протокол

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

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

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

Дальше начинается арифметика, из-за которой такой способ и не масштабируется. Четыре агента, связанные попарно, требуют шести интеграций. Пяти агентам понадобится уже десять, десяти — сорок пять. Показательно здесь не само число, а то, как оно растёт. Добавляя десятого агента к девяти существующим, написать придётся не одну интеграцию, а девять, по одной с каждым, кто уже подключён. Формула n(n−1)/2, и для сотни агентов она даёт 4950 связок.

каждый с каждым: n(n−1)/2        через протокол: n подключений

    A ─────────── B                  A           B
    │ ╲         ╱ │                   ╲         ╱
    │   ╲     ╱   │                    ╲       ╱
    │     ╲ ╱     │                     ╲     ╱
    │      ╳      │                      [A2A]
    │     ╱ ╲     │                     ╱     ╲
    │   ╱     ╲   │                    ╱       ╲
    │ ╱         ╲ │                   ╱         ╲
    C ─────────── D                  C           D

    4 агента → 6 связей              4 агента → 4 подключения
    10 → 45 · 100 → 4950             10 → 10 · 100 → 100

На практике до 4950 интеграций никто, разумеется, не доходит, всё останавливается гораздо раньше. Причём останавливает не объём работы, а то, из чего каждая связка состоит. В ней своё всё: токен со своим сроком действия, своё понимание того, что задача завершена, свой таймаут, свой формат ошибки. Когда у соседней команды меняется схема ответа, ломается не абстрактная «интеграция», а все девять связок этого агента — по одной с каждым, кто к нему обращался. Девять из сорока пяти, пятая часть всей сети, и падают они одновременно. Хорошо, если вы узнаете об этом из алертов, а не из жалоб пользователей.

Задачу такого вида принято называть N×M: N потребителей и M поставщиков дают произведение попарных договорённостей между собой. Тем, кто подключал платёжные шлюзы до появления общих SDK, картина знакома.

Что меняет общий протокол? Саму арифметику. Каждый участник один раз изучает стандарт вместо того, чтобы изучать соседа, и сотня агентов даёт сотню подключений вместо 4950 связок. Новый агент при этом становится доступен всем остальным сразу, включая тех, кто появится через год. В нашем примере третьему агенту больше не нужно ничего заранее знать про агента поиска. Он запрашивает карточку этого агента по стандартному адресу, читает список навыков, находит подходящий и ставит задачу в общем формате.

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

Именно на этой границе возникают четыре вопроса, на которые собственная обвязка ответа не даёт.

• как передать задачу и забрать результат в предсказуемом формате;
• как следить за статусом работы, которая идёт часами, а не секундами;
• как ограничить права исполнителя, чтобы он сделал ровно то, о чём его просили;
• как убедиться, что на том конце действительно тот, за кого он себя выдаёт.

Отвечает на них A2A (Agent2Agent) — открытый протокол делегирования задач между автономными агентами. Один публикует, что умеет, второй поручает ему работу и следит за ходом выполнения. Google анонсировал протокол весной 2025 года, а 23 июня 2025-го передал его в Linux Foundation под лицензией Apache-2.0. Спецификацию ведёт технический комитет из представителей восьми компаний — Google, Microsoft, Cisco, AWS, Salesforce, ServiceNow, SAP и IBM.

2. Вертикаль и горизонталь: агент к инструментам, агент к агенту

Рядом с A2A почти всегда упоминают MCP. Так какой из двух брать? Вопрос поставлен неверно: они отвечают за разные направления связи и в живой системе стоят оба.

MCP (Model Context Protocol) стандартизует подключение агента к внешним инструментам и данным. Работает он по вертикали и подаёт одному агенту базы, API, файлы, контекст. Его вопрос звучит так: «как агенту прочитать эту таблицу или вызвать этот сервис». Удачная метафора здесь — разъём USB-C: один порт, через который агент дотягивается до всего, что ему нужно для работы. Сам протокол, его цена и границы разобраны отдельным уроком.

A2A работает по горизонтали и отвечает за обнаружение соседей, делегирование задач, отслеживание статусов, передачу результатов между несколькими автономными агентами. Его вопрос звучит иначе: «как поручить работу агенту, которого писал не я». И метафора другая — ближе к телефонной сети. Вы звоните абоненту, не зная и не спрашивая, что у него внутри.

        ваши инструменты                    его инструменты
        БД · API · файлы                    (вам не видны)
               │                                   │
               │ MCP — вертикаль                   │ MCP
               ▼                                   ▼
      ┌────────────────┐       A2A        ┌────────────────┐
      │   ваш агент    │ ←──────────────→ │  чужой агент   │
      └────────────────┘   горизонталь    └────────────────┘
                  «как поручить задачу другому агенту»

Обратите внимание на правую половину схемы. У чужого агента тоже есть свои инструменты, подключённые своим MCP, и вам они не видны в принципе. Это не недоработка, а замысел. Спецификация формулирует его в первом же разделе. Агенты обмениваются информацией «without needing access to each other's internal state, memory, or tools», без доступа к внутреннему состоянию, памяти и инструментам друг друга. Непрозрачность соседа здесь — требование к дизайну, а не ограничение, с которым приходится мириться.

Сама спецификация называет протоколы комплементарными, то есть дополняющими друг друга. MCP описывает, как агенту воспользоваться конкретной возможностью, а A2A — как агенты партнёрствуют и делегируют работу. С 2026 года оба проекта живут под Linux Foundation, так что вопрос «кто кого вытеснит» снят даже на уровне управления.

Сведём практический выбор в три строки.

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

3. Паспорт агента: что в карточке и как её находят

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

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

{
  "name": "Research Agent",
  "skills": [{ "id": "market-research", "description": "анализ рынка" }],
  "capabilities": { "streaming": true },
  "supportedInterfaces": [
    { "url": "https://api.acme.ai/a2a",
      "protocolBinding": "JSONRPC", "protocolVersion": "1.0" }
  ],
  "securitySchemes": { "oauth2": {} },
  "signatures": [{ }]
}

Разберём, что здесь на что влияет. По массиву skills клиент выбирает исполнителя, причём не по имени сервиса, а по описанию умения. capabilities говорит, как с агентом можно разговаривать технически, то есть поддерживает ли он стриминг и умеет ли слать push-уведомления. securitySchemes перечисляет способы аутентификации, которые агент принимает. signatures нужен для проверки подлинности самой карточки, и к нему мы вернёмся в шестой секции.

Отдельного внимания заслуживает supportedInterfaces — массив интерфейсов в порядке предпочтения, где каждая запись несёт адрес, привязку протокола (JSONRPC, GRPC или HTTP+JSON) и версию. В версиях до 1.0 на этом месте стояли два плоских поля, url и preferredTransport, но их больше нет. Если вы копируете пример из статьи 2025 года и он не работает, дело, скорее всего, именно в этом.

Найти карточку можно тремя способами, и спецификация (§ 8.2) описывает все три, хотя вспоминают обычно только первый.

• Well-known URI — GET /.well-known/agent-card.json. Логика та же, что у robots.txt: клиент знает, куда смотреть, без всякой предварительной договорённости. Суффикс agent-card.json подан на регистрацию в IANA. Путь /.well-known/agent.json действовал до версии 0.3 и теперь считается устаревшим.
• Реестры и каталоги агентов — отдельный сервис, в котором агенты регистрируются. В корпоративном контуре обычно выигрывает этот вариант: реестр даёт единую точку, где видно, кто вообще выставлен наружу и с какими правами.
• Прямая конфигурация — адрес карточки прописан в настройках клиента. Годится, когда партнёров двое и они договорились заранее.

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

4. Задача как единица работы: восемь состояний и два способа получать обновления

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

Вокруг задачи крутятся ещё три объекта. Message — одно сообщение в диалоге, с ролью user или agent. Part — наименьшая единица содержимого, то есть TextPart, FilePart или DataPart. Artifact — результат, собранный из частей и неизменяемый после создания.

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

Состояний у задачи в версии 1.0 девять, но одно из них служебное (TASK_STATE_UNSPECIFIED, нулевое значение перечисления), так что содержательных восемь.

                        ┌──── клиент ответил ────┐
                        ▼                        │
  submitted ───────→ working ───────────→ input-required
      │                 │  │
      │                 │  └───────────→ auth-required
      │                 │                (клиент приносит права)
      │                 ▼
      │      completed · failed · canceled
      │      артефакт  · сбой   · отмена
      ▼
   rejected
   отказ на входе: «это не ко мне»

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

Зачем протоколу два разных кода неуспеха? Затем, что rejected и failed требуют от клиента разного. rejected означает «посмотрел на задачу и не взялся» — не тот профиль, нет прав или не хватает данных на входе. failed означает «взялся и сломался». В первом случае осмысленно искать другого исполнителя, во втором стоит повторить попытку или эскалировать проблему. Схлопни протокол эти два случая в один код ошибки, клиенту пришлось бы гадать.

Состояние auth-required реализует механизм In-Task Authorization (§ 7.6). Исполнитель, упёршийся в нехватку прав посреди работы, не падает с ошибкой и не требует заранее выдать ему всё на свете. Он переводит задачу в это состояние и ждёт, пока клиент принесёт нужную авторизацию. Запрос доступа к чужой системе становится штатной веткой сценария, а не аварией. В материалах старше марта 2026 этого состояния нет, поэтому там перечисляют семь состояний вместо восьми.

Обновления о ходе работы приходят двумя способами, и выбор между ними архитектурный, а не вкусовой.

Streaming через SSE (Server-Sent Events, поток событий по одному открытому соединению) даёт пошаговые обновления статуса и части артефакта по мере готовности. Клиент подписывается методом SendStreamingMessage (REST-биндинг POST /message:stream) и ничего не опрашивает. Подходит, когда работа занимает минуты и хочется показывать прогресс.

Push-уведомления работают наоборот: исполнитель сам стучится на вебхук клиента, когда есть что сообщить. Годится для задач, идущих часами, — держать соединение открытым всё это время бессмысленно. Зато вебхук становится ещё одной точкой, которую придётся закрывать TLS, аутентификацией входящих и проверкой, что стучится действительно ваш исполнитель.

Короткие задачи, где ответ приходит сразу, отправляются обычным SendMessage (POST /message:send). Имена tasks/send и tasks/sendSubscribe встречаются в примерах старше версии 1.0 и в актуальной спецификации отсутствуют.

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

• Опубликовать карточку по адресу /.well-known/agent-card.json — с честным списком skills, схемой аутентификации и хотя бы одним интерфейсом в supportedInterfaces. Честным в буквальном смысле: навык, которого агент не умеет, вернётся к вам жалобой чужой команды, а не молчаливым отказом.
• Поднять POST /message:send: принимать Message, возвращать Task с идентификатором. Одного этого метода хватает, чтобы вас начали звать.
• Взять готовый SDK вместо собственной сериализации — python-a2a, google-adk и остальные из пятёрки, которую фонд считает готовой к продакшену, привозят Task, Artifact и перечень состояний уже описанными. Руками эти объекты собирают ровно один раз, и обычно об этом жалеют на первом же патч-релизе спецификации.

5. Три паттерна общения и границы ответственности

Все взаимодействия в протоколе сводятся к трём паттернам, и отличаются они тем, сколько ходов занимает договориться.

При запросе-ответе задача короткая, артефакт один, клиент ждёт результат («переведи этот текст»). При делегировании работа долгая, прогресс приходит через streaming или push, и клиент не висит на линии («сделай анализ рынка»). Переговоры идут многоходовым обменом через состояние input-required. Клиент просит забронировать, исполнитель отвечает, что нужны даты, клиент их присылает.

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

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

CLIENT AGENT              ОБЩАЯ ЗОНА (A2A)         REMOTE AGENT
─────────────────────────────────────────────────────────────────────
сформулировать задачу     версия протокола         честная карточка
выбрать по карточке       схема аутентификации     принять или отклонить
хранить свой контекст     что считать «выполнено»  работать в рамках skills
принять артефакт          кто пишет и хранит лог   не просить лишних прав
решить, доверять ли       что делать при failed    вернуть артефакт и статус

Средняя колонка самая коварная. Протокол задаёт формат обмена, но не решает за вас, что считать выполненной работой и кто хранит логи. Эти вещи выглядят очевидными ровно до первого спора. Агент вернул completed с артефактом, который клиент считает негодным, и выясняется, что критерий приёмки нигде не зафиксирован. Контракт в A2A живёт в двух местах: в карточке (навыки плюс требования к безопасности) и в жизненном цикле задачи. Всё, что не описано ни там, ни там, придётся оговаривать вне протокола.

6. Честность карточки: что закрывает подпись, а что нет

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

УРОВЕНЬ                       ЧЕМ РЕШАЕТСЯ
────────────────────────────────────────────────────────────────────
Карточку не подменили         подпись JWS (RFC 7515) поверх
по дороге                     канонизации JCS (RFC 8785):
                              любая правка становится заметной

Карточку отдаёт тот,          ничем внутри протокола; нужна
за кого себя выдаёт           workload-identity (SPIFFE/SPIRE)
                              и авторизация в сервисной сети (mesh)

Навык заявлен честно,         ничем: репутация, тестовый прогон,
но выполняется плохо          проверка результата

Первый уровень спецификация закрывает прямо (§ 8.4). Карточку разрешено подписывать по JWS, это JSON Web Signature, стандарт подписи JSON-документа. Есть одна обязательная деталь: перед подписью документ приводят к канонической форме по JCS (RFC 8785, детерминированная сериализация JSON), иначе подпись развалится на банальном переупорядочивании ключей. Два семантически одинаковых JSON дадут разные байты и разные подписи. После этого карточка становится tamper-evident, то есть изменить содержимое незаметно уже не выйдет.

Второй уровень точнее всех сформулировали инженеры Red Hat. Карточка несёт метаданные и подпись, но «nothing inherently ties that metadata back to the workload actually serving it at runtime», ничто в самом документе не привязывает эти метаданные к процессу, который отдаёт карточку в рантайме. Их аналогия бьёт в цель. Визитку с надписью «врач» может напечатать кто угодно, и печать типографии подлинности профессии не добавляет. Что помешает вредоносной нагрузке внутри кластера опубликовать карточку «I am the Payment Processor»? Ничто на уровне протокола. Отсюда и предложение привязывать карточку к утверждённой workload-identity через SPIFFE/SPIRE (выдачу рабочей нагрузке проверяемого криптографического удостоверения), а вызовы разрешать по этой идентичности на уровне сервисной сети.

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

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

7. Контроль межагентного обмена: доверие, права, аудит, политики

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

• Доверие — кто звонит? TLS на транспорте, проверка каждого запроса по схеме из карточки (API-ключ, OAuth2, OpenID Connect, mutual TLS), подпись карточки против подмены.
• Права — что можно? Принцип наименьших привилегий: авторизация по конкретным навыкам, действиям и OAuth-скоупам. Дополнительные доступы запрашиваются отдельным ходом через auth-required, а не подсовываются в промпт.
• Аудит — что произошло? Логи задач, смен статуса, артефактов и запросов прав. Терминальные состояния (completed, failed, rejected) — естественные точки для записи в журнал.
• Политики — что запрещено? Какие навыки видны внешним клиентам, какие действуют лимиты, как проверять вебхук перед отправкой push, как изолировать исполнение.

Человек встраивается в эту схему штатно, а не костылём поверх. Типовой поток выглядит так. Клиент читает карточку, получает токен доступа по схеме client credentials (машинная авторизация, при которой клиент предъявляет свой идентификатор и секрет, а человек в обмене не участвует), запрашивает данные — и прежде чем данные уйдут, владельцу приходит push с запросом подтверждения. Пока владелец не ответит «да», токен не выдаётся, а сам факт одобрения попадает в аудит.

У этого шага есть имя, по которому его можно найти в документации любого провайдера идентификации: CIBA, Client-Initiated Backchannel Authentication — расширение OpenID Connect, где согласие спрашивают не в браузере пользователя, а по отдельному каналу, обычно push-уведомлением на телефон. Разница с привычным редиректом принципиальна для агентов: инициатор запроса и тот, кто одобряет, — разные участники. Агент работает в фоне, браузера у него нет и сессии человека тоже. Сам человек в этот момент может заниматься чем угодно и узнаёт о запросе из уведомления.

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

Так выглядит agent session smuggling — подмешивание инструкций в уже установленную межагентную сессию. Это единственный задокументированный класс атаки именно на A2A-обмен, и разбирали его исследователи Unit 42.

Механика такая: вредоносный агент прячет команды между обычными запросами и ответами, пользуясь тем, что сессия stateful. Состояние живёт между ходами, и агенты помнят, о чём говорили минуту назад. В разобранном сценарии доверенный агент-исследователь за несколько ходов диалога склоняет агента-клиента к несанкционированной биржевой сделке. Корень проблемы в презумпции доверия, ведь агентов по умолчанию проектируют доверчивыми к соседям по контуру. Агент-самозванец (rogue-агент) опаснее вредоносного документа именно тем, что ведёт диалог, подстраивает стратегию под ответы и наращивает ложное доверие постепенно.

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

8. Спор о зрелости: что поддаётся проверке

Оценки готовности A2A расходятся радикально. Одни говорят «протокол, на котором уже выпускают в продакшен», другие называют его сырым и вообще замороженным проектом. Кто прав? Выбирать по авторитету бессмысленно, обе позиции звучат от практиков. Зато почти всё в этом споре проверяется, чем мы и займёмся.

Версия 1.0.0 вышла 12 марта 2026 года, дальше пошли патч-релизы. Тезис о замороженном проекте рассыпается при первом же взгляде на репозиторий. a2aproject/A2A не архивирован, за последние 52 недели в нём 270 коммитов, и правки идут по существу спецификации, а не по косметике. В конце июля 2026 уточняли семантику скоупов для In-Task Authorization.

Тезис «Google в агентов не верит» не выдерживает проверки датой. 23 июня 2025 года компания передала в Linux Foundation спецификацию, SDK и инструментарий, с семью соучредителями и заявленным мотивом сделать протокол независимым от вендора и развиваемым сообществом. Так снимают вендорную привязку, а не сворачивают направление. Отдать спецификацию в нейтральный фонд значит убедить конкурентов, что стандарт не будет развиваться в интересах одной компании.

Реальные внедрения фиксирует пресс-релиз Linux Foundation от 9 апреля 2026 года. Более 150 организаций против 50 годом раньше, а число SDK выросло с одной реализации на Python до пяти, готовых к продакшену. Развёртывания идут в цепочках поставок, финансовых сервисах, страховании и IT-операциях. Проверяемую часть спора сведём в три строки.

Полезно отделить тех, кто заявил о поддержке, от тех, кто выпустил работающий код. У Microsoft класс A2AAgent в Agent Framework оборачивает любой A2A-совместимый endpoint в обычный AIAgent, который вызывается привычными RunAsync и RunStreamingAsync. Правда, пакет Microsoft.Agents.AI.A2A ставится с флагом --prerelease, то есть работает, но в стабильный канал ещё не переехал. Copilot Studio подключается к внешнему A2A-агенту по сквозному сценарию и передаёт вместе с задачей контекстные метаданные. AWS добавил поддержку в Bedrock AgentCore Runtime.

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

Cisco в том же пресс-релизе Linux Foundation называет протокол «the syntactic layer», слоем синтаксиса, который сделал обмен надёжным и совместимым, и тут же добавляет, что богатая семантика ещё впереди. То есть договорились о том, как передавать сообщения, но не о том, что они означают в спорной ситуации.

Формально это разбирает препринт arXiv:2606.31498. Авторы провели анализ пробелов пяти протоколов (MCP, A2A, ACP, ANP, ERC-8004) по шести измерениям управления. Это членство, совещательность, голосование, сохранение особого мнения, эскалация к человеку и аудит с воспроизведением. Последняя пара идёт одним измерением, потому что журнал, по которому нельзя проиграть спорное решение заново, ничем не управляет.

Результат такой: голосования и права на особое мнение нет ни в одном из пяти, а совещательность либо отсутствует, либо в лучшем случае частична. Вывод авторов стоит привести дословно. Управление сообществом агентов у них названо «a missing architectural layer above current interoperability standards, not a missing feature within them». Недостающий архитектурный слой над стандартами, а не недостающая функция внутри них.

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

И последнее, чисто практическое. Переход с версии 0.3 на 1.0 сломал обратную совместимость, поэтому материалы и код старше марта 2026 года читайте с поправкой. Имена операций, поля карточки и перечень состояний там другие.

Итог

• A2A снимает задачу из разряда N×M: без него сотня агентов даёт 4950 парных интеграций, у каждой пары свой формат и своя авторизация; с ним — сто подключений, и новый участник доступен всем сразу.
• MCP и A2A не конкурируют: первый тянет инструменты в агента по вертикали, второй связывает агентов по горизонтали; в живой системе стоят оба, и оба под Linux Foundation.
• Карточка агента — контракт и точка входа: навыки, схема аутентификации, supportedInterfaces; канонический адрес /.well-known/agent-card.json, механизмов обнаружения три, а не один.
• Восемь содержательных состояний задачи превращают делегирование в переговоры: input-required для уточнений, auth-required для штатного запроса прав, rejected как право сказать «это не ко мне».
• Подпись карточки доказывает, что документ не подменили, но не то, что его отдаёт настоящий владелец, — этот разрыв снимает workload-identity; а качество навыка не проверить ничем, кроме результата.
• Войти в сеть дёшево: карточка по /.well-known/agent-card.json, один метод POST /message:send и готовый SDK. Человек при этом остаётся в контуре штатно — через CIBA, где согласие спрашивают push-уведомлением, а не редиректом в браузере, которого у фонового агента нет.
• Протокол зрелый на уровне синтаксиса и внедрённый в проде; сырым остаётся слой договорённостей о смысле и управлении поверх него.

FAQ

A2A уже готов для продакшена?

На уровне обмена сообщениями да. Версия 1.0.0 вышла 12 марта 2026, дальше идут патч-релизы. Репозиторий активен, спецификацию правят по существу. Linux Foundation в апреле 2026 отчиталась о более чем 150 организациях, пяти готовых к продакшену SDK и развёртываниях в цепочках поставок, финансах, страховании и IT-операциях. Незакрытым остаётся слой выше протокола. Коллективные решения, голосование и разрешение разногласий между агентами не описаны ни в одном из существующих стандартов интероперабельности.

Нужно ли выбирать между A2A и MCP?

Нет, они отвечают за разные направления. MCP подключает одного агента к инструментам, данным и ресурсам. Это вертикаль, «как прочитать базу или вызвать API». A2A связывает независимых агентов между командами, фреймворками и организациями, то есть работает по горизонтали, «как поручить задачу другому агенту». Спецификация называет их комплементарными, и в реальной системе обычно работают оба, MCP внутрь агента и A2A наружу.

Где лежит карточка агента и что в ней должно быть?

Канонический адрес выглядит как /.well-known/agent-card.json, суффикс подан на регистрацию в IANA. Внутри лежат идентификация, перечень навыков с описаниями, поддерживаемые возможности вроде стриминга, схемы аутентификации и массив supportedInterfaces с адресом, биндингом протокола и версией для каждого интерфейса. Обнаружить карточку можно тремя способами — по well-known URI, через реестр агентов или по заранее прописанному адресу.

Что сломалось при переходе с версии 0.3 на 1.0?

Обратная совместимость. Операции tasks/send и tasks/sendSubscribe переименованы в SendMessage и SendStreamingMessage (REST-биндинги POST /message:send и /message:stream). Плоские поля карточки url и preferredTransport заменены массивом supportedInterfaces. Добавилось состояние auth-required, поэтому в старых разборах перечисляют семь содержательных состояний вместо восьми. Путь /.well-known/agent.json объявлен устаревшим.

Можно ли доверять подписанной карточке агента?

Подпись решает одну задачу из трёх. JWS поверх канонической формы JCS делает подмену заметной, так что изменить содержимое незаметно не выйдет. Однако ничто в самом документе не связывает его с рабочей нагрузкой, которая его отдаёт. Для этого нужна отдельная workload-identity, например через SPIFFE/SPIRE, и авторизация вызовов на уровне сервисной сети. А качество заявленного навыка криптография не проверяет вовсе, здесь работают только тестовый прогон и репутация.

Что такое agent session smuggling и это дыра в A2A?

Это техника, при которой вредоносный агент подмешивает инструкции в уже установленную межагентную сессию, пряча их между обычными запросами и ответами. Исследователи Unit 42 показали сценарий, где доверенный агент за несколько ходов диалога склоняет агента-клиента к несанкционированной биржевой сделке. Уязвимости в самом протоколе тут нет, атака эксплуатирует презумпцию доверия между агентами и воспроизводится в любом stateful-обмене. Лечится человеком в контуре на критичных действиях, верификацией удалённого агента и обнаружением инструкций не по теме.

Когда A2A не нужен?

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

Источники

• Спецификация A2A, репозиторий a2aproject/A2A — канонический текст: механизмы обнаружения (§ 8.2), состав карточки и подпись (§ 8.3, § 8.4), In-Task Authorization (§ 7.6), перечень состояний задачи и имена операций.
• Linux Foundation: A2A Protocol Surpasses 150 Organizations — статус за первый год, состав SDK, продакшен-вертикали, формулировка про «syntactic layer».
• Google Developers Blog: Google Cloud donates A2A to Linux Foundation — что именно передано в фонд 23 июня 2025 и с какой мотивацией.
• arXiv:2606.31498 — Governance Gaps in Agent Interoperability Protocols — gap-анализ пяти протоколов по шести измерениям управления; управление как недостающий слой над стандартами.
• Unit 42: Agent Session Smuggling Attack in A2A Systems — механика атаки, презумпция доверия как корень, оговорка об отсутствии уязвимости в протоколе, многослойная защита.
• Red Hat: Who's really calling? Securing agent-to-agent communication — разрыв между заявленным и проверяемым, привязка карточки к workload-identity, обнаружение по навыку вместо имени сервиса.
• Microsoft Learn: A2A Agent (Microsoft Agent Framework) — рабочая реализация у второго по величине участника комитета, резолвер карточки, статус пакета.

Числовые ориентиры в тексте — срез на начало августа 2026. Число организаций, состав SDK и метрики репозитория меняются, а спецификацию активно правят. Имена операций, поля карточки и перечень состояний сверяйте с текущей версией текста спецификации, а не с материалами старше марта 2026.