Как AI-агенты договариваются: MCP, A2A и другие протоколы

За полгода рынок AI-агентов получил сразу несколько протоколов межмашинного общения. Anthropic открыла Model Context Protocol (MCP) в ноябре 2024 года как способ подключать модели к внешним данным и инструментам. Google в апреле 2025-го анонсировала Agent2Agent (A2A) — стандарт, где агенты разных вендоров говорят напрямую друг с другом. Оба проекта заявлены как открытые, у обоих десятки компаний в списке партнёров. Проблема, которую они решают, простая: когда у вас пять агентов от четырёх поставщиков, каждый должен уметь дёрнуть чужой инструмент и понять чужой ответ — без ручной склейки под каждую пару.

Почему одного API мало

Классический подход — интеграция «каждый с каждым». Ваш агент планирования вызывает CRM через один SDK, календарь через другой, поисковый сервис через третий. Каждое подключение — отдельный код, отдельная аутентификация, отдельный формат ответа. При N сервисах и M агентах вы пишете и поддерживаете до N×M связок.

Протокол разрывает эту квадратичную зависимость. Сервис один раз реализует серверную сторону протокола, агент один раз — клиентскую. Дальше они находят и вызывают друг друга по общим правилам. Это ровно та же логика, по которой USB заменил зоопарк разъёмов — Anthropic и сама сравнивает MCP с «USB-C для приложений».

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

Что именно стандартизируют

Протоколы для агентов покрывают несколько слоёв, и путаница обычно начинается там, где их смешивают:

• Доступ к инструментам и данным — как модель узнаёт, какие функции ей доступны, и как их вызывает. Это территория MCP.
• Общение агента с агентом — как один автономный агент делегирует задачу другому и получает результат, не зная его внутренней реализации. Это A2A.
• Транспорт и аутентификация — по какому каналу идут сообщения (HTTP, SSE, stdio) и как стороны доверяют друг другу.

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

Три подхода к сравнению

Function calling исторически появился раньше и привязан к конкретному вендору: вы описываете функции в формате провайдера, модель возвращает JSON с аргументами, а исполнение остаётся на вашей стороне. Это работает, но не переносится между поставщиками без переписывания. MCP как раз вынес описание инструментов в отдельный протокол, не завязанный на конкретную модель.

Как устроен MCP на практике

В терминологии MCP есть хост (приложение вроде IDE или чат-клиента), клиент внутри хоста и серверы — процессы, отдающие ресурсы, инструменты и промпт-шаблоны. Сервер объявляет список доступных инструментов, клиент их обнаруживает, модель решает, какой вызвать. Транспорт — либо локальный stdio, либо сетевой поверх HTTP с server-sent events. SDK доступны для нескольких языков, включая Python и TypeScript.

Практический выигрыш: один MCP-сервер к вашей базе знаний работает и с десктопным клиентом Claude, и с любым другим MCP-совместимым хостом. Вы пишете сервер один раз.

Как устроен A2A

A2A вводит понятие Agent Card — машиночитаемого описания, что агент умеет, как к нему обращаться и как аутентифицироваться. Один агент (клиент) находит карту другого (удалённого), ставит ему задачу, следит за её статусом и забирает результат — так называемые артефакты. Протокол опирается на привычные веб-стандарты: HTTP, JSON-RPC, SSE для стриминга длинных задач. Логика в том, чтобы агенты кооперировались, не раскрывая друг другу внутреннее устройство и не делясь памятью.

Что это меняет для тех, кто строит агентов

Если вы собираете продукт на агентах прямо сейчас, ставка на протокол — это ставка на то, что вам не придётся переписывать интеграции при смене модели или добавлении партнёрского сервиса. Порядок действий, если вы только подступаетесь:

1. Разделите слои. Отдельно решите, откуда агент берёт инструменты (кандидат — MCP), и отдельно — нужно ли ему координироваться с чужими агентами (кандидат — A2A).
2. Проверьте зрелость экосистемы под вашу платформу. Наличие официального SDK для вашего языка важнее, чем красота спецификации.
3. Начните с одного сервера или одной карты агента, а не с полной миграции. Протоколы молодые, ломающие изменения возможны.
4. Отдельно продумайте аутентификацию и права. Агент, который сам вызывает инструменты, — это агент, который может сделать лишнее.

Риски, о которых говорят реже

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

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

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