MCP против A2A: чем агенты разных вендоров учатся говорить

В ноябре 2024 года Anthropic опубликовала Model Context Protocol (MCP) — открытую спецификацию для подключения моделей к внешним инструментам и данным. В апреле 2025 года Google представила Agent2Agent (A2A) — протокол для общения агентов между собой, а летом того же года передала его под управление Linux Foundation. За несколько месяцев поддержку MCP объявили OpenAI и Microsoft, и у отрасли впервые появился шанс, что агент, собранный на одном стеке, сможет дергать инструменты и других агентов, написанных на другом.

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

Две разные проблемы

Чтобы не путаться, полезно развести две задачи, которые часто валят в одну кучу.

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

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

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

Как устроен MCP

MCP описывает клиент-серверную связку поверх JSON-RPC. Сервер объявляет три типа сущностей: инструменты (действия, которые модель может вызвать), ресурсы (данные для чтения) и подсказки-шаблоны. Клиент внутри хоста — например, внутри desktop-приложения или IDE — подключается к серверу и передает модели список доступного.

Практический выигрыш: вместо десятка проприетарных плагинов вы поднимаете один MCP-сервер к своей CRM, и он работает и в приложении Anthropic, и в тех продуктах, что заявили поддержку протокола. Реестр готовых серверов уже насчитывает подключения к GitHub, Slack, Postgres, файловой системе и множеству других сервисов.

Как устроен A2A

A2A строится вокруг «карточки агента» (agent card) — машиночитаемого описания того, что агент умеет и по какому адресу к нему обращаться. Дальше агенты обмениваются задачами: инициатор ставит task, исполнитель отвечает статусами и артефактами. Протокол опирается на привычный веб-стек — HTTP, JSON-RPC, Server-Sent Events для стриминга — и не требует, чтобы агенты раскрывали свою внутреннюю логику или использованные модели.

MCP и A2A в сравнении

Даты и состав поддержки сверяйте по официальным спецификациям — экосистема меняется быстро, и список участников на момент чтения может быть шире.

Где здесь конфликт

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

• Кто контролирует стандарт. A2A ушёл под нейтральную крышу Linux Foundation, MCP пока остаётся спецификацией одной компании, пусть и открытой. Для крупного заказчика это разница в оценке рисков вендорлока.
• Безопасность. Оба протокола дают модели или чужому агенту право что-то делать в вашей системе. MCP-сервер с доступом к файлам или базе — это новая поверхность атаки: вредоносное описание инструмента способно подтолкнуть модель к нежелательному действию. Разграничение прав и аудит вызовов ложатся на вас.
• Совместимость реализаций. Наличие спецификации не гарантирует, что два SDK от разных вендоров поведут себя одинаково в краевых случаях: стриминг, отмена задачи, обработка ошибок. Пока это область, где стоит тестировать, а не доверять на слово.

Кому это пригодится, а кому нет

Пригодится:

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

Не пригодится или преждевременно:

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

Что делать сейчас

1. Разведите свои задачи: вам нужен доступ к инструментам (смотрите в сторону MCP) или общение агентов между собой (A2A). Часто нужно и то, и другое.
2. Начните с одного MCP-сервера для самого болезненного интеграционного места и проверьте его в вашем клиенте.
3. Заранее продумайте права доступа и логирование вызовов — не выставляйте наружу больше, чем нужно конкретной задаче.
4. Перед продакшеном протестируйте краевые случаи между реализациями разных вендоров, а не только внутри одного SDK.

¹ Агент здесь — программа на основе языковой модели, которая не просто отвечает на запрос, а сама планирует шаги, вызывает инструменты и выполняет многоходовую задачу с минимальным участием человека.