MCP, A2A и дальше: как договариваются ИИ-агенты

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

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

Что решает MCP

MCP стандартизирует связь «модель — инструмент». Вместо того чтобы под каждый источник данных (база, файловая система, API CRM) писать отдельный адаптер под конкретную модель, вы поднимаете MCP-сервер, который описывает свои возможности в общем формате. Любой MCP-совместимый клиент — будь то Claude Desktop, редактор кода или ваш собственный агент — подключается к нему по одному протоколу.

Технически MCP построен на JSON-RPC и описывает три основных типа ресурсов, которые сервер отдаёт клиенту:

• Tools — функции, которые модель может вызвать: отправить запрос, записать файл, дёрнуть API.
• Resources — данные, которые можно прочитать: документы, записи из базы, содержимое файлов.
• Prompts — заготовленные шаблоны сценариев, которые сервер предлагает клиенту.

Смысл в переиспользовании. Один раз написанный MCP-сервер для, скажем, GitHub работает с любым клиентом, который понимает протокол. Это то же обещание, что дал в своё время Language Server Protocol для редакторов кода: один сервер — много клиентов.

MCP решает проблему «модель и её инструменты», A2A — проблему «агент и другой агент». Это не конкуренты за один слот, а два уровня одной стопки.

Что решает A2A

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

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

Кто за чем стоит

MCP вырос из Anthropic, но быстро вышел за её пределы: поддержку заявили в OpenAI и в экосистеме Microsoft. A2A изначально собрал вокруг себя широкий пул партнёров и был передан под управление Linux Foundation, что снимает вопрос «а вдруг вендор передумает». Оба протокола открытые, оба развиваются публично.

Сравнение

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

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

MCP имеет смысл разбирать, если вы:

• строите ассистента поверх модели и устали писать по адаптеру на каждый источник данных;
• хотите, чтобы ваш инструмент был доступен в разных клиентах (условный Claude Desktop, редактор кода) без переписывания;
• разрабатываете внутренний сервис, который несколько разных ИИ-приложений компании должны дёргать одинаково.

A2A стоит изучать, если у вас:

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

Кому пока рано. Если у вас один агент с двумя-тремя жёстко заданными интеграциями и они работают — стандартный протокол добавит слой абстракции, который вы не окупите. MCP и A2A оправдывают себя на масштабе: когда интеграций много, когда их пишут разные команды или когда систему собирают из чужих кусков. Для прототипа выходного дня прямой вызов API проще и быстрее.

Что дальше

Пока идёт закрепление обоих стандартов и обкатка совместимости. Открытые вопросы, которые ещё предстоит решить экосистеме:

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

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

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