Суть
Когда MCP стандартизировал «агент ↔ инструмент», осталась незакрытой следующая проблема — «агент ↔ агент» (разные команды, разные фреймворки, разные вендоры). A2A даёт общий язык: как агенту объявить свои способности, как поставить другому задачу и получить результат.
Экономика решения считается на связях. Четыре агента, соединённые попарно напрямую, дают шесть связей, десять агентов — сорок пять, сотня — несколько тысяч, и у каждой связи свой формат и своя авторизация. Это задача N×M. Когда все подключаются к одному протоколу по одному разу, связей становится N+M: каждый учит стандарт, а не соседа.
Как работает
- Agent Card — JSON-объект, которым агент публикует свои возможности, аутентификацию, типы контента, endpoints. Канонический путь —
/.well-known/agent-card.json(суффикс подан на регистрацию в IANA, §14.3);agent.jsonиз ранних версий — легаси до v0.3. Обнаружение предсказуемо, по аналогии сrobots.txt. Клиент черезA2ACardResolverнаходит подходящего удалённого агента. - Task — центральная единица работы со своим жизненным циклом:
submitted → working → input-required / auth-required → completed / failed / canceled / rejected. Запускается методамиSendMessage/SendStreamingMessage(REST-биндинг:POST /message:send,POST /message:stream). Старыеtasks/sendиtasks/sendSubscribeиз версий до 1.0 в актуальной спеке отсутствуют. - Message / Part / Artifact — сообщения (role: user/agent) состоят из частей; результат успешной задачи возвращается как Artifact (файлы, структурированные данные).
- Транспорт: HTTP (базовый запрос/ответ), JSON-RPC 2.0 (структурированные вызовы методов), SSE (Server-Sent Events — стриминг статусов длинных задач без поллинга:
TaskStatusUpdateEvent/TaskArtifactUpdateEvent).
Подробности вынесены в отдельные atomic-заметки: состав карточки и границы ответственности сторон — в Agent Card, полный набор состояний задачи (включая rejected — отказ на входе, в отличие от failed) и механику обновлений — в A2A Task Lifecycle.
Ключевое свойство протокола зафиксировано в §1: агенты обмениваются информацией «without needing access to each other's internal state, memory, or tools». Непрозрачность соседа здесь не ограничение, а требование.
A2A на MCP. Отдельная инженерная идея (статья kts.tech): сам MCP можно дотянуть до межагентного взаимодействия, если у MCP-инструментов есть streaming, resumability (EventStore), durability и многошаговость — тогда «инструмент» становится полноценным агентом. То есть граница MCP/A2A на практике размывается.
Как протокол ложится на уже написанного агента
Практическая новость в том, что A2A добавляется слоем сверху, а не переписыванием. Существующий граф не меняется ни на строку — меняется то, что вокруг него.
Чтобы вас могли вызывать, нужны три эндпоинта: отдача карточки, приём задачи, выдача статуса. Приём устроен асинхронно — возвращает идентификатор задачи немедленно и запускает работу в фоне:
@app.post("/message:send") # приём задачи
async def send_task(request: SendTaskRequest, background_tasks: BackgroundTasks):
task = Task(input_text=extract_text(request.message), state=TaskState.SUBMITTED)
TASKS[task.task_id] = task
background_tasks.add_task(process_task, task.task_id) # не держим клиента
return task.to_dict()
async def run_agent_logic(task: Task) -> Artifact: # ← единственная точка стыка
result = await your_graph.ainvoke({"input": task.input_text})
return Artifact(parts=[TextPart(text=result["output"])])Синхронный приём выглядел бы проще, но ломает сам смысл жизненного цикла: если клиент всё равно ждёт ответа на открытом соединении, состояния working и input-required не нужны, а длинная задача упирается в таймаут прокси.
Чтобы вызывать чужих, в граф добавляется один узел. Внутри него — клиент, который делает discovery, отправляет задачу и опрашивает статус до терминального. Остальная часть графа, инструменты и MCP-серверы не затрагиваются: было агент → инструмент, стало агент → чужой агент → инструмент.
Что этот минимум сознательно не покрывает и что придётся добавить перед продом: схема аутентификации в карточке, стриминг вместо поллинга (иначе клиент опрашивает сервер всю длинную задачу), хранение задач вне памяти процесса — иначе рестарт пода теряет все незавершённые задачи, и здесь работает та же логика, что в Durable Execution.
Отдельная оговорка к учебным материалам: разборы 2025–2026 годов используют путь /.well-known/agent.json и методы tasks/send, которых в версии 1.0 уже нет. Форма кода остаётся верной, имена — нет.
Альтернативный взгляд: вертикаль против горизонтали
Разводить два протокола полезнее не по функциям, а по направлению связи: это даёт более устойчивую интуицию, чем перечисление возможностей.
MCP — вертикаль. Впрыск возможностей и контекста в одного агента: инструменты, данные, ресурсы. Отвечает на вопрос «как агенту прочитать базу или вызвать API». Метафора — USB-C порт: один разъём, через который агент дотягивается до всего.
A2A — горизонталь. Координация между несколькими автономными агентами: обнаружение, делегирование, статусы, артефакты. Отвечает на вопрос «как агенту поручить задачу другому агенту». Метафора — телефонный протокол или HTTP для агентов: вы звоните абоненту, не зная, что у него внутри.
Отсюда практический вывод: протоколы не конкуренты и в реальной системе живут вместе. Внутрь агента кладут MCP, чтобы он подтягивал инструменты, наружу выставляют A2A, чтобы с ним могли разговаривать чужие.
Спор о зрелости протокола
Два источника одной партии оценивают готовность A2A прямо противоположно, и это стоит держать в голове при выборе.
Оценка со стороны практики — протокол готов. «Спецификация уже развилась до версии 1.0. То есть это не какая-то экспериментальная разработка, а это протокол, на котором уже в продакшн выпускают различные системы». Изложение целиком построено на практической реализации: карточка, сервер, клиент, обёртка вокруг существующего графа.
Оценка со стороны архитектуры мультиагентных систем — протокол сырой. «Есть A2A, но он сырой… A2A — это замороженный проект». Рядом стоит наблюдение, что Google «в агентов не особо верит», и указание на нехватку стандартизованных протоколов обмена промежуточными статусами между планировщиками.
Сверка с первоисточниками (04.08.2026). Спор разрешается фактами, и не в пользу той рамки, в которой его вели.
Проверяемая часть — за оптимистичной оценкой. Версия 1.0.0 действительно вышла, 12 марта 2026, дальше пошли патч-релизы. «Замороженный проект» опровергается прямо: репозиторий a2aproject/A2A не архивирован, 270 коммитов за последние 52 недели, правки идут по существу спеки (docs(spec): clarify in-task authorization scope semantics, #2081, конец июля 2026). Тезис «Google в агентов не верит» опровергается донацией: 23.06.2025 Google передал спецификацию, SDK и тулинг в Linux Foundation с семью соучредителями — это не отказ от проекта, а снятие вендорной привязки. Продакшен подтверждён пресс-релизом LF от 09.04.2026: 150+ организаций, развёртывания в supply chain, финансах, страховании и ITOps.
Но скептическая сторона права в другом месте, чем сама указала. Претензия «нет стандартизованных протоколов обмена промежуточными статусами между планировщиками» попадает в реальный разрыв — просто разрыв не внутри A2A, а над ним. Cisco в том же пресс-релизе LF называет A2A «the syntactic layer» и говорит, что богатая семантика ещё впереди. Академически это формализовано в arXiv:2606.31498: gap-анализ пяти протоколов (MCP, A2A, ACP, ANP, ERC-8004) по шести измерениям управления показал, что voting и dissent preservation отсутствуют во всех пяти, а управление сообществом агентов — «a missing architectural layer above current interoperability standards, not a missing feature within them».
ACP в этом перечне — не тот ACP, что про редакторы. Здесь это Agent Communication Protocol из линии BeeAI/IBM, про обмен между агентами. Одноимённый Agent Client Protocol решает другую задачу — кто пускает агента в среду пользователя — и в этом сравнении не участвует. Аббревиатура занята дважды, и оба значения про агентов, поэтому разводить их надо по вопросу, а не по названию.
Итоговая рамка: протокол живой, стабильный и внедрённый на синтаксическом уровне. Сырым остаётся слой договорённостей о смысле и управлении поверх него. Отдельно стоит держать в голове, что переход v0.3 → v1.0 сломал обратную совместимость — материалы и код до марта 2026 читать с поправкой.
Agent session smuggling
Единственный задокументированный класс атаки именно на A2A-взаимодействие (Unit 42, Palo Alto Networks). Вредоносный агент пользуется уже установленной межагентной сессией и подмешивает инструкции агенту-жертве между обычными запросами и ответами. В демонстрации доверенный агент-исследователь за несколько ходов диалога склоняет агента-клиента к несанкционированной биржевой сделке.
Механика опирается на stateful-природу протокола: агенты помнят недавние взаимодействия, и это же свойство даёт атакующему рычаг. Корень — презумпция доверия, агенты по умолчанию проектируются доверяющими соседям по контуру. Rogue-агент опаснее вредоносного документа тем, что ведёт диалог, подстраивает стратегию и наращивает ложное доверие за несколько ходов.
Оговорка, без которой цитировать нельзя: исследователи прямо пишут, что это не уязвимость протокола. Техника эксплуатирует неявные доверительные отношения между агентами и сработала бы в любом stateful-протоколе. Защита многослойная: human-in-the-loop на критичных действиях, криптографическая верификация удалённого агента через подписанную карточку (см. Agent Card), детекция инструкций не по теме через context-grounding.
Слой управления, которого в стандартах нет
Протокол описывает транспорт и контракт задачи, но не отвечает на вопрос, что делать, когда два агента дали разные ответы и оба формально успешны. Пока стандарта нет, слой достраивается своими средствами — и важно, что он не должен жить внутри агентов: голосование, реализованное каждым участником по-своему, невоспроизводимо и не аудируется.
Практическая сборка — вынести решение в оркестратор на своей стороне: он получает результаты, применяет заранее заданное правило разрешения (приоритет источника, детерминированная проверка, требование совпадения двух из трёх) и фиксирует не только выбранный ответ, но и отвергнутые вместе с причиной. Сохранение несогласия здесь не формальность: без него разбор инцидента покажет один ответ и не покажет, что альтернатива была и её отклонили.
Эскалация к человеку выстраивается по тому же признаку, что и везде: не по факту расхождения, а по необратимости действия, к которому ведёт решение (Human in the Loop). Расхождение на справочном запросе разрешается правилом, расхождение перед платежом — человеком.
Связано с
- Multi Agent Systems — A2A как протокольный слой координации команды
- MCP — «агент ↔ инструмент»; A2A — «агент ↔ агент» (дополняют друг друга)
- MAS Frameworks — фреймворки могут говорить между собой через A2A
- Agent Card — паспорт агента и механизм обнаружения
- A2A Task Lifecycle — объекты протокола и восемь состояний задачи
- Durable Execution — почему хранилище задач нельзя оставлять в памяти процесса
- Orchestrator Adapter — тот же приём развязки, но между приложением и фреймворком оркестрации