A2A против MCP: действительно ли ИИ-агентам нужны оба протокола?

Архитектура AI-агентов начинает разделяться на два уровня.

Один уровень связан с предоставлением AI-ассистенту доступа к инструментам, данным, API, файлам, базам данных, поисковым системам, календарям, системам тикетов и другим внешним возможностям — именно здесь в дело вступает MCP.

Другой уровень связан с тем, чтобы один AI-агент мог обнаруживать, общаться с, делегировать задачи и сотрудничать с другим AI-агентом, возможно, созданным другой командой, фреймворком, вендором или организацией — именно здесь в дело вступает A2A.

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

MCP — это в основном взаимодействие агента с инструментами, а A2A — это в основном взаимодействие агента с агентом.

Это не означает, что каждой AI-системе нужны оба. На самом деле, большинство небольших проектов с агентами, вероятно, должны начинать с MCP и игнорировать A2A, пока у них не появится реальная граница между несколькими агентами. Но если вы строите более крупные системы агентов, особенно системы с отдельно развернутыми агентами, специализированными агентами, агентными вендорами или долгосрочными делегированными задачами, A2A начинает иметь смысл.

Эта статья объясняет различия, перекрытия, архитектурные компромиссы и когда вам действительно нужны оба. Если ваше решение касается того, должна ли возможность быть Agent Skill или MCP-сервером, а не о взаимодействии агентов между собой, см. нашу рамку принятия решений: Agent Skills vs MCP Servers.

Что такое MCP?

MCP расшифровывается как Model Context Protocol (Протокол контекста модели).

Это открытый протокол для подключения AI-приложений и агентов к внешним инструментам, ресурсам и промптам. На практическом уровне MCP позволяет AI-хосту, такому как настольный ассистент, IDE, кодинг-агент или чат-приложение, подключаться к одному или нескольким MCP-серверам.

MCP-сервер может предоставлять такие возможности, как:

• Инструменты: вызываемые функции, которые модель может использовать
• Ресурсы: читаемый контекст, такой как файлы, данные API, документы или записи базы данных
• Промпты: повторно используемые шаблоны промптов или рабочие процессы

Официальная архитектура MCP основана на модели хост-клиент-сервер.

MCP-хост — это приложение, с которым взаимодействует пользователь. MCP-клиент — это компонент протокола, который поддерживает соединение с конкретным MCP-сервером. MCP-сервер предоставляет возможности клиенту.

Например, кодинг-ассистент мог бы подключиться к:

• MCP-серверу файловой системы
• MCP-серверу GitHub
• MCP-серверу базы данных
• MCP-серверу Sentry
• MCP-серверу Slack

С точки зрения пользователя ассистент становится более полезным. С точки зрения архитектуры системы ассистент получил контролируемый доступ к внешнему контексту и действиям.

В этом основная ценность MCP: он стандартизирует способ, которым AI-приложение достигает инструментов и контекста.

MCP лучше всего понимать как интеграцию инструментов

MCP — это не только об инструментах, но инструменты — самый простой способ его понять.

Без MCP каждое AI-приложение нуждается в собственном коде интеграции для каждой внешней системы. У одного фреймворка агентов свой формат плагинов. У другого — своя схема инструментов. У третьего — другой паттерн API-обертки. Каждая интеграция строится заново снова и снова.

MCP пытается сократить эти потери.

Если поставщик инструмента предоставляет MCP-сервер, многие совместимые с MCP клиенты могут его использовать. Если разработчик создает MCP-сервер для внутренней системы, несколько AI-приложений могут подключиться к нему. Практические руководства по реализации MCP-серверов на Go и MCP-серверов на Python показывают, насколько простой может быть слой интеграции, когда протокол берет на себя основную работу.

Вот почему MCP стал важным так быстро. Он решает скучную, но болезненную проблему интеграции.

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

Что такое A2A?

A2A расшифровывается как Agent2Agent Protocol (Протокол агент-к-агенту).

Это открытый стандарт для коммуникации и интероперабельности между независимыми системами AI-агентов. Для более глубокого изучения отдельных строительных блоков — Agent Cards, жизненного цикла задач, сообщений, частей и артефактов — Что такое протокол A2A? Объяснение Agent Cards и задач подробно рассматривает каждую концепцию. Официальная спецификация A2A описывает протокол как способ для агентов, созданных с использованием разных фреймворков, языков или вендоров, общаться через общую модель взаимодействия.

Ключевая фраза — независимые системы агентов.

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

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

A2A вводит такие концепции, как:

• Agent Cards
• Агенты и клиенты
• Задачи
• Сообщения
• Части
• Артефакты
• Состояния задач
• Стриминг и асинхронная работа

В совокупности эти концепции заставляют A2A казаться скорее протоколом сотрудничества агентов, чем простым протоколом вызова инструментов — он построен вокруг идеи, что агенты имеют идентичность, состояние и продолжающиеся отношения с другими агентами.

A2A лучше всего понимать как сотрудничество агентов

Представьте, что пользователь просит корпоративного ассистента:

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

Простой ассистент мог бы попытаться сделать все самостоятельно. Но более крупная система агентов могла бы делегировать части работы:

• Агент исследований собирает рыночную информацию
• Юридический агент проверяет регуляторные соображения
• Финансовый агент оценивает ценовые риски
• Агент планирования проектов создает план доставки
• Агент написания текста собирает окончательный обзор

Если все эти агенты являются внутренними функциями внутри одного кодовой базы, вам, возможно, не нужен A2A. Вы можете просто вызывать функции или сервисы напрямую.

Но если эти агенты — независимые системы, возможно, принадлежащие разным командам или вендорам, тогда стандартный протокол взаимодействия агентов становится полезным.

В этом и заключается использование A2A.

A2A против MCP: простое различие

Самое простое сравнение таково:

Эта таблица не идеальна, но она полезна для построения начальной ментальной модели. Кратко: MCP отвечает на вопрос «Как это AI-приложение получает доступ к внешним возможностям?», в то время как A2A отвечает на вопрос «Как этот агент работает с другим агентом?»

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

Почему разработчики путают A2A и MCP

Путаница понятна.

Многие MCP-серверы — не просто глупые инструменты. Некоторые MCP-серверы могут выполнять многошаговую работу. Некоторые предоставляют высокоуровневые возможности, которые выглядят агентными. MCP-сервер мог бы оборачивать сервис планирования, систему извлечения или даже другой рабочий процесс на базе LLM.

В этот момент граница становится размытой.

Если MCP-инструмент под названием research_topic выполняет сложный исследовательский рабочий процесс, это инструмент или агент?

Честный ответ: архитектурно это зависит от обстоятельств.

Если хост рассматривает его как вызываемую возможность со схемой инструмента, он функционирует как инструмент.

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

Вот почему «A2A против MCP» — неправильная рамка, когда это становится религиозной дискуссией. Лучшая рамка:

• Лучше ли моделировать эту внешнюю возможность как инструмент?
• Или лучше моделировать ее как независимого агента?

Это решение должно определять выбор протокола.

Случай использования только MCP

Большинство AI-проектов должны начинать только с MCP — это несколько субъективная позиция, но практическая.

Если вы строите кодинг-ассистент, внутренний чат-бот, локальный AI-рабочий процесс, персонального агента автоматизации или простой корпоративный ассистент, первая проблема обычно не в сотрудничестве агентов между собой. Первая проблема — доступ к инструментам.

Вам нужно, чтобы ассистент читал файлы, опрашивал базы данных, искал документы, вызывал API, открывал тикеты, резюмировал логи, проверял метрики или обновлял записи.

MCP очень хорошо подходит для этого.

Используйте только MCP когда:

• Вашему агенту в основном нужен доступ к инструментам и данным
• Вы контролируете хост-приложение
• Вы контролируете большинство интеграций
• Внешние системы не являются действительно автономными агентами
• Рабочий процесс в основном синхронный или краткосрочный
• Обычного вызова инструмента достаточно
• Вам не нужно обнаружение агентов
• Вам не нужно состояние задач между агентами
• Вам не нужны артефакты от независимых агентов

Для многих систем MCP плюс хорошая архитектура приложения достаточны. Многие команды будут избыточно усложнять A2A в системах, которые на самом деле являются просто ассистентами с использованием инструментов, и это не проблема протокола — это проблема архитектурной дисциплины, которую ни один протокол не может исправить за вас.

Случай использования только A2A

Системы только с A2A менее распространены, но они могут существовать.

Вы могли бы использовать A2A без MCP, когда система в основном связана с коммуникацией между агентами, и каждый агент уже управляет своими собственными инструментами внутренне.

Например:

• Маркетплейс специализированных агентов
• Интеграция агент-к-агенту между вендорами
• Межорганизационный рабочий процесс
• Система нескольких агентов, где у каждого агента своя частная цепочка инструментов
• Сеть делегирования, где клиенты не должны знать внутренние детали инструментов

В этой модели A2A — это публичная граница между независимо управляемыми агентами. Агенту А не нужно знать, использует ли Агент B PostgreSQL, Elasticsearch, MCP, LangChain, кастомные API или shell-скрипты за кулисами. Агенту А нужно только знать, что может сделать Агент B, как отправить ему задачу и как получить результаты.

Это чистая абстракция.

Используйте только A2A когда:

• Вы предоставляете агентов как независимые сервисы
• Вызывающая сторона не должна знать внутренние инструменты агента
• Важно обнаружение возможностей агентов
• Делегирование важнее прямого доступа к инструментам
• Задачи могут быть долгосрочными
• Результаты могут включать артефакты
• Агенты могут быть созданы разными вендорами или командами

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

Случай использования обоих: A2A и MCP

Самая интересная архитектура — это не A2A против MCP. Это A2A плюс MCP.

В этом паттерне агент предоставляет A2A-интерфейс другим агентам, но внутренне использует MCP для доступа к инструментам.

Это дает вам два чистых уровня:

• A2A снаружи: как агенты общаются друг с другом
• MCP внутри: как каждый агент получает доступ к инструментам, данным и сервисам

Это, вероятно, самая долговечная ментальная модель.

Агент поддержки клиентов мог бы предоставлять A2A-интерфейс. Другие агенты могли бы делегировать ему задачи, связанные с поддержкой. Внутренне агент поддержки использует MCP-серверы для Zendesk, Slack, поиска документации, проверки CRM и извлечения внутренней политики.

DevOps-агент мог бы предоставлять A2A-интерфейс. Другие агенты могли бы попросить его расследовать инцидент. Внутренне он использует MCP-серверы для Prometheus, Grafana, GitHub, Kubernetes, логов и облачных API.

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

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

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

Справочная архитектура: A2A снаружи, MCP внутри

Практическая архитектура нескольких агентов могла бы выглядеть так:

Пользователь
  |
  v
Основной ассистент или оркестратор
  |
  |-- A2A --> Исследовательский агент
  |              |
  |              |-- MCP --> Веб-поиск
  |              |-- MCP --> Хранилище документов
  |
  |-- A2A --> Кодинг-агент
  |              |
  |              |-- MCP --> GitHub
  |              |-- MCP --> Файловая система
  |              |-- MCP --> CI-система
  |
  |-- A2A --> DevOps-агент
                 |
                 |-- MCP --> Метрики
                 |-- MCP --> Логи
                 |-- MCP --> Kubernetes

В этом дизайне A2A обрабатывает делегирование между агентами, в то время как MCP обрабатывает интеграцию между каждым агентом и его инструментами. Оркестратору не нужно знать каждый инструмент, доступный каждому специалисту — ему нужно только знать, какой агент ответственен за какой тип работы, что снижает перегрузку инструментами и сохраняет общую архитектуру более модульной. Внутренняя топология этого слоя оркестрации — использует ли она модель хаб-спок, иерархическое дерево, fan-out или mesh — это отдельное проектное решение, рассмотренное в Паттернах оркестрации нескольких агентов. Для более глубокого рассмотрения того, как инференс, память, маршрутизация и инструменты сочетаются внутри производственного ассистента, Архитектура AI-ассистентов: LLM, Память, Инструменты, Маршрутизация, Наблюдаемость подробно рассматривает эти слои.

Когда A2A избыточен

A2A избыточен, когда «другой агент» на самом деле просто функция.

Если ваше приложение имеет один рабочий процесс LLM, который вызывает несколько инструментов, не добавляйте A2A просто потому, что это звучит современно. Python-функция, HTTP-эндпоинт, очередь или MCP-инструмент могут быть достаточны.

A2A может быть слишком много когда:

• Есть только один агент
• Все компоненты находятся в одной кодовой базе
• Рабочий процесс короткий и синхронный
• Вам не нужно обнаружение
• Вам не нужно независимое состояние задач
• Вам не нужна отдельная идентичность агента
• Вы не ожидаете сторонних агентов
• Вам не нужна интероперабельность между вендорами или фреймворками

Протоколы не бесплатны — они добавляют концепции, инфраструктуру, поверхность отладки, вопросы безопасности и операционные затраты. Скудный API или простой вызов функции иногда является лучшим инженерным выбором, и обращение к A2A по привычке, а не по необходимости, — это своего рода избыточное усложнение. Выбор более простого варианта — это не анти-A2A; это про-архитектуру.

Когда MCP недостаточно

MCP начинает казаться недостаточным, когда вы используете его для представления вещей, которые явно являются агентами.

Например, предположим, что MCP-сервер предоставляет инструмент под названием:

complete_enterprise_procurement_review

Этот инструмент выполняет следующее:

• Читает данные поставщиков
• Проверяет правила политики
• Задаёт уточняющие вопросы
• Делегирует юридический обзор
• Создаёт отчёт о рисках
• Возвращает несколько артефактов
• Работает 20 минут
• Поддерживает состояние задачи
• Требует истории аудита

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

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

Если это ваши реальные проблемы, вы в области A2A.

Безопасность: та часть, которую все недооценивают

Модель безопасности — вот где A2A и MCP становятся серьёзными.

MCP предоставляет агентам доступ к инструментам и данным. Это означает, что AI-система может читать файлы, опрашивать базы данных, вызывать API, отправлять сообщения, обновлять тикеты или запускать инфраструктурные действия.

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

Оба мощны. Оба могут быть опасными.

Основные вопросы безопасности различаются:

Для MCP:

• Какие инструменты может использовать этот агент?
• Какие данные он может читать?
• Какие действия он может выполнять?
• Одобрено ли действие пользователем?
• Могут ли метаданные инструмента манипулировать моделью?
• Доверяются ли локальные и удалённые серверы?

Для A2A:

• Какие агенты разрешены общаться друг с другом?
• Какая идентичность у каждого агента?
• Может ли Агент А делегировать авторитет Агенту B?
• Сколько контекста может быть разделено?
• Кто отвечает за окончательный результат?
• Может ли цепочка задач быть аудирована?

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

Хорошая производственная архитектура должна включать:

• Идентичность агента
• Идентичность инструмента
• Идентичность пользователя
• Ограниченные разрешения
• Шлюзы одобрения для рискованных действий
• Аудиторские логи на уровне задач
• Логи вызовов инструментов
• Логи делегирования
• Происхождение артефактов
• Лимиты скорости
• Политики таймаутов
• Контроль исходящего трафика

Если вы строите с использованием обоих A2A и MCP, безопасность — это не дополнение. Это часть архитектуры. [Безопасность агентов A2A и MCP: Идентичность, делегирование и аудиторские следы](https://www.glukhov.org/ru/llm-architecture/guardrails/a2a-mcp-agent-security/ “Обеспечьте безопасность систем агентов A2A и MCP с помощью идентичности, аутентификации, контроля делегирования, шлюзов, реестров, аудиторских следов и производственного чек-листа для развёртывания нескольких агентов.”} подробно рассматривает полную модель угроз, слои идентичности, паттерн шлюза и контроль делегирования.

Наблюдаемость: вам нужны трассы, а не просто логи

Системы нескольких агентов трудно отлаживать.

Пользователь задаёт один вопрос. Оркестратор вызывает два агента. Один агент вызывает три инструмента. Другой агент стримит частичный прогресс. Третий агент падает и повторяет попытку. Окончательный ответ выглядит разумным, но никто не знает, какой источник данных повлиял на него.

Это неприемлемо в производстве.

Для систем с упором на MCP вам нужно наблюдать:

• Выбор инструмента
• Аргументы инструмента
• Результаты инструмента
• Латентность инструмента
• Ошибки инструмента
• Одобрения пользователя
• Контекст, внедрённый в модель

Для систем с упором на A2A вам нужно наблюдать:

• Обнаружение агентов
• Создание задач
• Изменения состояния задач
• Сообщения между агентами
• Созданные артефакты
• Цепочки делегирования
• Сбои и повторные попытки
• Происхождение окончательного ответа

Чем более агентной становится система, тем важнее становится трассируемость — обычных логов приложения недостаточно, когда работа охватывает несколько агентов, вызовов инструментов и передач артефактов. Вам нужна трасса задачи, которая следует за полным путём выполнения, чтобы любой ответ мог быть отслежен до его источника. [Наблюдаемость для LLM-систем: Метрики, трассы, логи и тестирование в производстве](https://www.glukhov.org/ru/observability/observability-for-llm-systems/ “Глубокое, ориентированное на производство руководство по наблюдаемости для LLM-систем, охватывающее метрики LLM, распределённую трассировку, логи, профилирование, синтетическое тестирование, SLO и сравнение инструментов наблюдаемости LLM.”} подробно рассматривает инструменты и инструментацию этой области. Когда агенты стримят прогресс или приостанавливаются в input_required в долгосрочных A2A-задачах, [Стриминг и асинхронные задачи A2A для долгосрочных рабочих процессов агентов](https://www.glukhov.org/ru/ai-systems/architecture/a2a-streaming-async-task-lifecycle/ “Как проектировать стриминг протокола A2A, асинхронные задачи, push-уведомления и долгосрочные рабочие процессы агентов с SSE, опросом, состояниями HITL и производственной наблюдаемостью.”} охватывает, что логировать на каждом переходе состояния и шаге делегирования.

Рамка принятия решений: нужен ли вам A2A, MCP, оба или ни один?

Используйте эту рамку принятия решений.

Используйте ни один, когда простого кода достаточно

Выбирайте обычные функции, API или очереди когда:

• Вы контролируете все компоненты
• Нет необходимости в LLM-нативном обнаружении инструментов
• Нет необходимости в интероперабельности агентов
• Система детерминирована
• Интеграция стабильна и проста

Не каждой интеграции нужен AI-протокол.

Используйте MCP, когда агенту нужны инструменты

Выбирайте MCP когда:

• AI-приложению нужны внешние данные
• Агенту нужно вызывать инструменты
• Вы хотите повторно используемые интеграции
• Вы хотите обнаружение инструментов
• Вы хотите стандартную клиент-серверную интеграцию
• Вы строите для кодинг-агентов, ассистентов, IDE или внутренних инструментов

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

Используйте A2A, когда агентам нужны равные

Выбирайте A2A когда:

• Агенты развёрнуты независимо
• Агентам нужно обнаруживать друг друга
• Агенты созданы разными командами или вендорами
• Задачи долгосрочные
• Делегирование важно
• Артефакты важны
• Вам нужна граница агента, а не просто граница инструмента

Это правильный выбор, когда единицей архитектуры является агент.

Используйте оба, когда специализированным агентам нужны инструменты

Выбирайте оба когда:

• Агенты сотрудничают друг с другом
• Каждый агент также нуждается в доступе к инструментам
• Вы хотите чистые границы между делегированием и выполнением
• Вы хотите специализированных агентов с частными внутренними цепочками инструментов
• Вы хотите масштабируемую архитектуру нескольких агентов

Это самый реалистичный корпоративный паттерн.

Общие анти-паттерны

Анти-паттерн 1: превращение каждого инструмента в агента

Не каждая функция заслуживает обёртки агента.

API конвертации валюты, вероятно, является инструментом. Запрос базы данных, вероятно, является инструментом. Чтец файлов, вероятно, является инструментом.

Обёртывание каждой небольшой возможности как A2A-агента создаёт ненужную сложность.

Анти-паттерн 2: скрытие целого агента за одним MCP-инструментом

Противоположная ошибка также распространена.

Если MCP-инструмент тайно запускает долгосрочный, состояние-зависимый, много-агентный рабочий процесс, абстракция MCP может стать слишком тонкой. Вы теряете видимость состояния задачи, делегирования, артефактов и ответственности.

В этот момент это, возможно, заслуживает границы A2A.

Анти-паттерн 3: позволять каждому агенту вызывать каждый инструмент

Это создаёт хаос разрешений.

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

Используйте наименьшие привилегии.

Анти-паттерн 4: отсутствие человеческого одобрения для рискованных действий

Агентные системы не должны молча выполнять действия с высоким воздействием.

Человеческое одобрение должно требоваться для таких действий, как:

• Отправка внешних писем
• Модификация производственных данных
• Развёртывание инфраструктуры
• Удаление файлов
• Изменение разрешений
• Покупка сервисов
• Разделение конфиденциальных данных

Протоколы облегчают интеграцию. Они не снимают ответственность.

Практические примеры

Пример 1: локальный кодинг-ассистент

Локальный кодинг-ассистент использует MCP для доступа к:

• Файловой системе
• Git-репозиторию
• Тестовому раннеру
• Менеджеру пакетов
• Поиску документации

Ему, вероятно, не нужен A2A.

MCP достаточно.

Пример 2: корпоративный ассистент поддержки

Ассистент поддержки использует MCP для доступа к:

• CRM
• Системе тикетов
• Документации
• Slack
• Базе данных клиентов

Сначала MCP достаточно.

Позже компания добавляет специализированных агентов:

• Агент биллинга
• Юридический агент политики
• Агент устранения неполадок продукта
• Агент эскалации

Теперь A2A начинает иметь смысл, потому что ассистенту поддержки нужно делегировать работу другим агентам.

Используйте оба.

Пример 3: маркетплейс агентов

Платформа позволяет сторонним агентам рекламировать возможности и получать задачи от других агентов.

Платформа не знает внутреннюю реализацию каждого агента.

A2A — сильный выбор.

Отдельные агенты могут по-прежнему использовать MCP внутренне, но публичная граница — A2A.

Пример 4: агент анализа данных

Агент анализа данных опрашивает хранилище, читает дашборды, создаёт графики и пишет отчёт.

Если это один агент, использующий инструменты, MCP достаточно.

Если он делегирует статистический обзор одному агенту, бизнес-объяснение другому и комплаенс-обзор третьему, A2A становится полезным.

Мое субъективное мнение

MCP — это практический выбор по умолчанию для большинства создателей, в то время как A2A — это архитектурная граница, в которую более крупные системы вырастают, когда у них появляются реальные потребности в координации агентов между собой.

Если вы строите своего первого полезного AI-агента, начните с MCP. [Кластер AI-систем](https://www.glukhov.org/ru/ai-systems/ “Стройте self-hosted AI-системы с OpenClaw, Hermes, RAG и локальной LLM-инфраструктурой. Учитесь оркестрировать ассистентов с памятью, извлечением, маршрутизацией и наблюдаемостью.”} охватывает self-hosted ассистентов, MCP-серверы и память агентов как связанную группу, что даёт более широкую картину того, как эти части сочетаются на практике. Дайте агенту безопасный, хорошо ограниченный доступ к инструментам и данным. Узнайте, где описания инструментов ломаются. Узнайте, где разрешения становятся запутанными. Узнайте, где наблюдаемость слаба.

Не начинайте с фантастической архитектуры нескольких агентов.

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

Ошибка — рассматривать A2A и MCP как конкурентов.

Их лучше понимать как разные слои:

• MCP соединяет агентов с возможностями.
• A2A соединяет агентов с другими агентами.

Вы можете строить полезные системы только с MCP.

Вы можете строить сети агентов только с A2A.

Но самый масштабируемый паттерн, вероятно, — оба: A2A для сотрудничества агентов, MCP для интеграции инструментов.

Окончательный вердикт: действительно ли AI-агентам нужны оба?

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

Если вашему AI-агенту нужны только инструменты, используйте MCP.

Если вашей AI-системе нужно, чтобы независимо развёрнутые агенты сотрудничали, используйте A2A.

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

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

Для более широкого взгляда на то, где A2A находится в 2026 году — уровни принятия, требования безопасности, корпоративные случаи использования и рамка принятия решений для того, когда вводить его, см. [Протокол Google A2A в 2026: принятие, хайп и реальность](https://www.glukhov.org/ru/ai-systems/comparisons/a2a-protocol-2026-adoption/ “Полезен ли протокол A2A от Google на самом деле в 2026 году? Практический обзор принятия A2A, перекрытия с MCP, вопросов безопасности и когда использовать протоколы агент-к-агенту в производстве.”}.

Источники

• Спецификация протокола A2A: https://a2a-protocol.org/latest/specification/
• Сравнение A2A и MCP: https://a2a-protocol.org/latest/topics/a2a-and-mcp/
• Введение в MCP: https://modelcontextprotocol.io/docs/getting-started/intro
• Обзор архитектуры MCP: https://modelcontextprotocol.io/docs/learn/architecture
• Концепции сервера MCP: https://modelcontextprotocol.io/docs/learn/server-concepts
• Обновление принятия A2A от Linux Foundation: https://www.linuxfoundation.org/press/a2a-protocol-surpasses-150-organizations-lands-in-major-cloud-platforms-and-sees-enterprise-production-use-in-first-year