Войны протоколов: почему ИИ-агенты не могут договориться

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

Что вообще пытаются стандартизировать

Разговор про «агентов, которые договариваются» на практике распадается на две разные задачи, и их постоянно путают.

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

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

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

Почему «договориться» технически тяжело

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

• Разная модель состояния. Одни протоколы рассчитаны на короткий запрос-ответ, другие — на долгие задачи, которые выполняются минутами и требуют опроса статуса. Склеить их — значит придумать, куда девать «задача ещё выполняется».
• Разные форматы описания возможностей. Чтобы агент понял, что умеет другой агент, ему нужна машиночитаемая карточка навыков. У MCP это одно, у A2A — другое, у собственных схем OpenAI — третье. Поля не совпадают один в один.
• Аутентификация и права. Кто отвечает за то, что агент А имеет право просить агента Б списать деньги? Единой модели доверия между протоколами нет, и это самое опасное место.
• Семантика ошибок. «Не смог» — это отказ по правам, сбой сети, исчерпанный лимит токенов или галлюцинация? Разные протоколы кодируют это по-разному, и агент-получатель не всегда понимает, повторять запрос или сдаваться.

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

Кто есть кто

Ниже — грубая карта основных подходов. Характеристики берите как ориентир: спецификации активно меняются, точные детали смотрите в документации проектов.

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

Чем это оборачивается на практике

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

1. Переходники вместо стандарта. Приходится писать адаптеры между протоколами и поддерживать их при каждом обновлении спецификации.
2. Дырявая безопасность. MCP-сервер с широкими правами, к которому агент обращается через непроверенное описание, — это классический вектор атаки. Уже описаны сценарии, где вредоносное описание инструмента подсовывает агенту опасную инструкцию (prompt injection**).
3. Привязка к вендору. Выбрав стек, который умеет один протокол хорошо, а остальные никак, вы фактически выбираете экосистему на годы вперёд.

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

Пригодится, если вы:

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

Скорее не пригодится прямо сейчас, если вы:

• Рассчитываете на бесшовное общение агентов от разных вендоров в проде — межпротокольная совместимость сырая, а модель доверия не устоялась.
• Работаете в зоне высоких рисков (платежи, медицина, юридические действия), где непонятная семантика ошибок и слабая аутентификация — недопустимая цена.
• Ждёте, что «один протокол победит» до конца года. Скорее нас ждёт сосуществование нескольких слоёв и медленное сближение, а не быстрый нокаут.

Куда всё движется

Исторически войны протоколов заканчиваются одним из двух способов: либо один стандарт становится де-факто общим (как HTTP), либо появляется слой-абстракция, который прячет различия. В случае агентов вероятнее второй сценарий — набор шлюзов, которые переводят MCP в A2A и обратно, плюс общая работа над безопасностью и идентичностью агентов. Передача A2A в Linux Foundation и открытость MCP — сигнал, что крупные игроки предпочитают нейтральную площадку монополии одного вендора. Но пока это движется медленнее, чем маркетинговые обещания про «армию агентов, которые всё сделают за вас».

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

** Prompt injection — атака, при которой во входные данные подмешивают инструкции, заставляющие модель действовать против замысла разработчика.