MCP и A2A: выбирайте границу протокола, а не войну брендов

MCP стандартизирует, как ИИ-приложение подключается к инструментам, источникам данных и связанному контексту. A2A стандартизирует, как независимые агенты находят друг друга и совместно выполняют задачи, не разделяя внутреннюю память и реализации инструментов. Прямого API часто достаточно, когда одна команда полностью отвечает за закрытую интеграцию и переносимое обнаружение возможностей между средами или поставщиками не требуется. Многие системы в реальной эксплуатации будут использовать оба протокола: A2A для связи между агентами и MCP для подключения каждого агента к его инструментам.

Это разные границы, а не конкурирующие бренды фреймворков. Детали протоколов ниже сверены с первичной документацией на 2026-08-11. Спецификации продолжают меняться, поэтому перечитайте актуальные страницы MCP и A2A, прежде чем окончательно утверждать архитектуру.

Для чего нужен каждый протокол

Model Context Protocol (MCP)

MCP - открытый стандарт подключения ИИ-приложений к внешним системам, включая источники данных, инструменты и рабочие процессы (MCP intro, docs path 2026-07-28). Архитектура строится по схеме узел / клиент / сервер: ИИ-приложение выступает узлом, каждое соединение с сервером обслуживает клиент, а серверы предоставляют контекст (MCP architecture). Серверы могут предоставлять инструменты для вызываемых действий, ресурсы с контекстными данными и запросы в виде повторно используемых шаблонов (MCP architecture). Слой данных использует JSON-RPC 2.0. Поддерживаются stdio для локального обмена между процессами и Streamable HTTP для удалённых серверов, а для потоковой передачи можно использовать Server-Sent Events (MCP architecture).

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

Протокол Agent2Agent (A2A)

A2A - открытый протокол связи и совместимости между независимыми, часто непрозрачными агентными приложениями (A2A home; A2A specification). Google анонсировал A2A 2025-04-09 и заявил, что он дополняет MCP, который даёт агентам инструменты и контекст (Google A2A announcement). 2025-06-23 проект перешёл под управление Linux Foundation при участии крупных технологических компаний (Google donation post; Linux Foundation launch). На момент проверки 2026-08-11 в документации A2A последней выпущенной версией спецификации была указана 1.0.0 (A2A specification).

Ключевые элементы A2A включают Agent Card с JSON-метаданными возможностей, задачи с сохраняемым состоянием, сообщения, части и артефакты (A2A key concepts). Агенты могут обмениваться запросами и ответами с периодической проверкой состояния, использовать потоковую передачу через Server-Sent Events и получать отправляемые сервером уведомления о долгих задачах (A2A key concepts; Google A2A announcement). Удалённые агенты остаются непрозрачными: участникам взаимодействия не требуется доступ к внутренней памяти, инструментам или закрытой логике друг друга (A2A home; A2A specification).

Официальная рекомендация A2A однозначна: MCP следует использовать для инструментов, а A2A для агентов (A2A home; A2A and MCP). Руководство Google для разработчиков от 2026-03-18 проводит ту же границу: MCP предназначен для инструментов и данных, а A2A для обнаружения агентов и совместной работы, включая Agent Card по стандартному адресу вроде /.well-known/agent-card.json (Developer's Guide to AI Agent Protocols).

Карта границ протоколов

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

Сравнительная таблица

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

Строки поведения протоколов отражают первичную документацию, сверенную 2026-08-11.

Источники для колонок протоколов: MCP architecture, MCP security best practices, A2A key concepts, A2A and MCP, A2A specification, Google A2A announcement, Google developer guide (2026-03-18).

Когда проще прямое API

Рекомендация: оставляйте прямое API, когда верно всё ниже.

1. Одно приложение владеет интеграцией от начала до конца.
2. Набор доступных инструментов мал и стабилен.
3. Вам не нужно, чтобы несколько ИИ-сред, например настольное приложение, IDE, чат-продукт и операционный агент, использовали один переносимый сервер.
4. Для этого API уже настроены авторизация, журналирование и дежурная поддержка.

Протокол оправдан, когда обнаружение возможностей, повторное использование или межкомандная совместимость важнее затрат на защиту и мониторинг ещё одного интерфейса. Руководство Google по протоколам формулирует практическое правило так: добавляйте протоколы по мере необходимости и начинайте с доступа к инструментам и данным, а не внедряйте все стандарты в первый день (Developer's Guide to AI Agent Protocols).

Гипотетический пример: единственный агент поддержки в вашей серверной части, который только создаёт заявки через API собственной службы поддержки, может остаться закрытой функцией-инструментом. Для этого пути не нужны MCP или A2A.

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

Совмещённая архитектура: оба протокола сразу

Официальная документация A2A прямо описывает дополняющую архитектуру: агентное приложение может общаться с другими агентами через A2A, а каждый агент использует MCP для собственных инструментов и ресурсов (A2A and MCP).

Полезная схема:

Пользователь / клиентский агент
        |
        | A2A (задачи, сообщения, артефакты)
        v
  Удалённый специализированный агент
        |
        | MCP (инструменты, ресурсы)
        v
  API, базы данных, файлы, системы SaaS

Сценарий автомастерской из документации A2A показывает границу на практике: диалог в несколько этапов и взаимодействие с поставщиками остаются на A2A, а диагностические сканеры и руководства подключаются как инструменты MCP (A2A and MCP). Это решение о границе, а не предпочтение бренда.

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

О различии между агентом для реальной эксплуатации и демонстрационным чатом читайте в статье что такое ИИ-агент для реальной эксплуатации.

Режимы сбоев, которые важнее аббревиатур

Протоколы не устраняют операционные сбои. Они лишь меняют место их проявления.

Режимы сбоев на стороне MCP

Рекомендации MCP по безопасности считают передачу токенов насквозь антипаттерном: серверы не должны принимать токены, выпущенные не для самого сервера MCP (MCP security best practices). Те же рекомендации рассматривают риск подмены полномочий посредника при использовании OAuth, SSRF во время обнаружения метаданных, перехват сеанса, небезопасный запуск локального сервера и чрезмерно широкие области доступа (MCP security best practices).

Операционные последствия, если это игнорировать:

• Один инструмент с избыточными правами расширяет область ущерба на каждую среду, подключённую к серверу.
• Журналы аудита перестают показывать настоящего клиента, когда токены пересылаются без проверки.
• Надпись «поддерживает MCP» создаёт ложное чувство безопасности.

Для практических ограничений на инструменты дополните эту страницу материалами о безопасных вызовах инструментов для бизнес-агентов и защите агентов с инструментами от внедрения вредоносных инструкций.

Режимы сбоев на стороне A2A

A2A предполагает, что удалённые агенты являются непрозрачными участниками взаимодействия, а не прозрачными функциями-инструментами (A2A specification). Отсюда другие режимы сбоев:

• Потеря ответственности за задачу: долгая задача завершается, даёт сбой, отменяется или ждёт ввода, но за её конечное состояние никто не отвечает.
• Несоответствие возможностей: Agent Card обещает навык, который удалённый агент не может применить с вашими правилами авторизации или типами содержимого.
• Потеря ограничений при непрозрачной передаче: при слабых контрактах ограничения исчезают между последовательными сообщениями.
• Имитация авторизации: обнаружение возможностей условно открыто, но авторизация реальных навыков не завершена.

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

Общие сбои в реальной эксплуатации

Они появляются, используете ли вы MCP, A2A, оба или ни один:

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

Учитывайте эти риски с помощью материалов о сбоях агентов в реальной эксплуатации и наблюдаемости агентов.

Чеклист решения

Используйте этот список для решения о начале или остановке внедрения любого из протоколов.

1. Кто другая сторона? Структурированный инструмент или система данных указывает на MCP или прямое API. Независимый агент со своей логикой рассуждения и навыками указывает на A2A.
2. Кто отвечает за авторизацию и область возможного ущерба? Если вы не можете назвать границу авторизации, не открывайте этот интерфейс.
3. Нужны ли нескольким средам одни и те же инструменты? Да - в пользу MCP. Нет - в пользу закрытого API или инструментов внутри процесса.
4. Нужно ли агентам разных команд или поставщиков взаимодействовать без раскрытия внутреннего устройства? Да - в пользу A2A. Нет - в пользу одного агента с инструментами.
5. Это долгая работа со статусом, артефактами или ожиданием действий человека? A2A рассчитан на такой класс задач. MCP может поддерживать долгую работу через расширения и уведомления, но остаётся протоколом инструментов и контекста, а не сетью равноправных агентов.
6. Можете ли вы наблюдать и отменять работу? Если путь нельзя залогировать, отозвать или остановить, выбор протокола преждевременен.
7. Есть ли более простой путь? Предпочитайте самую тонкую границу, которая закрывает требование.

Частые вопросы

MCP и A2A - конкуренты?

Нет, не по первичной литературе протоколов. И запуск A2A от Google, и официальная документация A2A позиционируют A2A как дополнение к MCP (Google A2A announcement; A2A and MCP).

Можно ли предоставлять агента как инструмент MCP?

Иногда чётко определённый навык похож на инструмент, и документация A2A отмечает, что сервер A2A может предоставлять некоторые навыки в совместимом с MCP виде. Там же сказано, что преимущество A2A состоит в гибком взаимодействии с сохраняемым состоянием, которое выходит за рамки обычного вызова инструмента (A2A and MCP). Рекомендация: не сводите равноправных агентов к инструментам лишь ради того, чтобы не осваивать вторую границу.

Нужны ли оба протокола для первого пилота?

Обычно нет. Рекомендация: начните с границы, которую пилот реально пересекает. Большинству первых агентов для реальной эксплуатации безопасные инструменты нужнее, чем сеть агентов от разных поставщиков. Добавляйте A2A, когда независимые агенты и обнаружение возможностей становятся реальным требованием (Developer's Guide to AI Agent Protocols).

Определяет ли MCP или A2A выбор фреймворка?

Нет. A2A прямо не является комплектом разработки агентов, а MCP представляет собой протокол подключения, а не среду выполнения для координации (A2A home; MCP intro). Выбирайте фреймворки отдельно от границ протоколов.

Следующий шаг

Нарисуйте один рабочий процесс на бумаге:

1. какие системы являются инструментами или источниками данных;
2. какие участники - независимые агенты;
3. какие действия необратимы и требуют согласования человеком;
4. кто отвечает за авторизацию, журналы и отмену.

Затем выберите MCP, A2A, прямое API или комбинированный стек по этим границам.

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