A2A и MCP решают задачи на разных уровнях

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

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

MCP дает агенту возможности, а A2A дает ему партнеров

Проще всего сравнить протоколы, если спросить, кто контролирует каждую сторону соединения. Хост MCP управляет взаимодействием с ИИ и подключается к серверам, которые предоставляют возможности. Клиент A2A делегирует работу удаленному агенту, а тот сам управляет своими рассуждениями, инструментами, состоянием и выполнением.

• На другой стороне MCP находится сервер, который предоставляет инструменты, ресурсы или промпты. На другой стороне A2A находится автономный или частично автономный агент.
• Клиент MCP запрашивает конкретную возможность, например search_tickets. Клиент A2A запрашивает результат с помощью сообщения или задачи.
• Планированием вокруг вызова MCP управляет хост. Удаленный агент A2A сам планирует принятую работу.
• MCP стандартизирует обмен сведениями о возможностях и вызовы. A2A стандартизирует статусы задач, сообщения, дополнительные данные, отмену и артефакты.
• Клиенты MCP узнают о возможностях сервера через методы протокола. Клиенты A2A читают Agent Card, а удаленный агент не раскрывает свои внутренние инструменты и ход рассуждений.

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

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

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

MCP устраняет узкое место интеграции с инструментами

MCP стандартизирует, как ИИ-хост находит и вызывает инструменты и как читает ресурсы, предоставленные сервером. Он заменяет набор разовых адаптеров общим контрактом уровня данных и транспорта. Хост отвечает за вызовы модели, запросы разрешений, выбор контекста, оркестрацию и пользовательский интерфейс.

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

Представим агента поддержки, которому нужна история обращения и возможность вернуть деньги клиенту. Система поддержки может через MCP предоставить get_ticket, search_orders и issue_credit как отдельные инструменты с разными входными схемами. Хост решает, когда вызвать каждый из них, и может потребовать подтверждение человека перед изменяющим данные вызовом. Сервер проверяет запрос с учетом прав вошедшего пользователя и выполняет бизнес-операцию. MCP не решает, был ли план агента разумным.

Текущая спецификация MCP использует сообщения JSON-RPC поверх транспортов, определенных протоколом. Редакция июля 2026 года сделала удаленное ядро протокола независимым от состояния, перенесла сведения о клиенте и его возможностях в метаданные запроса и добавила заголовки маршрутизации, такие как Mcp-Method и Mcp-Name. Обычный вызов теперь имеет понятную форму:

POST /mcp HTTP/1.1
MCP-Protocol-Version: 2026-07-28
Mcp-Method: tools/call
Mcp-Name: search_tickets
Authorization: Bearer <token>
Content-Type: application/json

{"jsonrpc":"2.0","id":17,"method":"tools/call","params":{"name":"search_tickets","arguments":{"account_id":"acct_42","status":"open"},"_meta":{"io.modelcontextprotocol/clientInfo":{"name":"support-agent","version":"1.4"}}}}

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

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

A2A решает задачу делегирования между агентами

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

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

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

После обнаружения клиент отправляет сообщение или создает работу через одну из стандартных привязок A2A. Версия A2A 1.0 определяет независимую от протокола модель данных и стандартные привязки JSON-RPC, gRPC и HTTP с JSON. Сервер может ответить сообщением или задачей. У задачи есть жизненный цикл, в ней могут накапливаться сообщения, обновления состояния и артефакты. Так долгая работа остается наблюдаемой, а удаленному агенту не приходится раскрывать ход рассуждений.

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

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

Один рабочий процесс может использовать оба протокола

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

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

Разделение уровней должно оставаться видимым в журналах и исходном коде:

Product workflow
  A2A task: review release 2026.08.3
    Security agent plan
      MCP tools/call: dependency_findings
      MCP resources/read: deployment_policy
      MCP tools/call: incident_search
    A2A input-required: identify exception owner
    A2A artifact: release-risk-assessment.json

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

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

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

MCP лидирует по внедрению, а A2A получил стабильную основу

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

Разработчики MCP выпустили редакцию спецификации 2026-07-28 с поддержкой официальных SDK. В отчете о выпуске сказано, что загрузки SDK первого уровня приближаются к полумиллиарду в месяц, а SDK для TypeScript и Python преодолели по одному миллиарду загрузок за все время. В эти цифры входят автоматические сборки и косвенное использование, поэтому я не приравниваю их к активным рабочим системам. Более убедительный признак внедрения состоит в том, что MCP поддерживается как точка расширения в распространенных ИИ-приложениях и инструментах разработчика, а за ним стоят официальный реестр и формальный процесс расширений.

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

MCP также перешел под нейтральное управление. В декабре 2025 года Anthropic передала его Agentic AI Foundation под эгидой Linux Foundation. Соучредителями выступили Anthropic, Block и OpenAI, проект поддержали несколько крупных поставщиков инфраструктуры. Такая модель управления не гарантирует совместимость, но снижает риск, что один поставщик моделей случайно изменит протокол под собственный продукт.

A2A достиг версии 1.0 после первоначального выпуска Google и передачи Linux Foundation. Проект называет 1.0 первым стабильным производственным выпуском, определяет три стандартные привязки и поддерживает SDK для Python, Go, JavaScript, Java, .NET и Rust. В технический руководящий комитет входят представители восьми крупных технологических компаний. При запуске проекта в 2025 году Linux Foundation сообщила о поддержке более чем ста компаний.

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

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

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

В новом проекте выбирайте новейшую стабильную версию, которую действительно поддерживают все нужные конечные точки, а код протокола изолируйте за небольшим внутренним интерфейсом. Не разносите объекты SDK по бизнес-логике. Когда следующая редакция изменит состояние транспорта или поля задач, лучше исправить один адаптер и набор контрактных тестов, чем десятки обработчиков процессов.

Сначала внедряйте границу, которая уже есть в продукте

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

Прежде чем поручать работу над протоколом, пройдите эту последовательность:

1. Опишите бизнес-операцию одним предложением. «Найти записи по нашим счетам» указывает на возможность. «Исследовать этот счет и вернуть отчет о рисках» может указывать на задачу агента.
2. Отметьте владение. Если ваша команда контролирует вызывающую и вызываемую стороны, а последняя работает детерминированно, используйте MCP или обычный API. Если другая команда управляет планированием и циклами выпуска вызываемой стороны, оцените A2A.
3. Отметьте время и взаимодействие. Быстрый ограниченный ответ подходит инструменту. Для работы, которая приостанавливается ради данных, передает состояние, создает артефакты или требует отмены, лучше подходит A2A.
4. Докажите один вертикальный путь. Для MCP возьмите одну операцию чтения и одну тщательно подтверждаемую запись. Для A2A возьмите один навык с полным жизненным циклом задачи. Не начинайте с универсальной платформы протоколов.
5. Добавляйте второй протокол только тогда, когда измеряемый рабочий процесс пересекает его границу. Сохраняйте исходную границу и не переписывайте все под новую абстракцию.

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

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

Можно ли отложить оба протокола? Да. Если одно приложение вызывает два стабильных внутренних API, прямые типизированные клиенты могут быть дешевле и проще в эксплуатации. Внедряйте протокол, когда совместимость или переносимость хоста окупает дополнительные версии, обнаружение и поверхность безопасности. Соответствие протоколу не становится этапом продукта, пока благодаря ему пользователь не может выполнить работу.

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

Безопасность нужна на каждом переходе

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

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

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

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

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

Подтверждение человеком должно показывать конкретный объект. Покажите операцию, цель, важные аргументы, действующий субъект и ожидаемое побочное действие. Фраза «Разрешить агенту?» приучает людей подтверждать шум. Если агент A2A запрашивает данные, которые приведут к записи через MCP, компонент с пользовательской сессией должен получить подтверждение и связать его именно с этим запросом.

Совместимость доказывают тесты сбоев, а не одинаковые схемы

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

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

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

Короткая запись о приемке часто полезнее толстого архитектурного документа:

{
  "implementation": "release-review-agent",
  "a2a_version": "1.0",
  "binding": "HTTP+JSON",
  "client": "independent-test-client/2.1",
  "cases": {
    "auth_wrong_audience": "denied",
    "task_resume": "passed",
    "cancel_during_work": "passed",
    "cross_tenant_task_get": "denied",
    "artifact_checksum": "passed"
  }
}

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

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

Архитектура должна сокращать границы команд

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

MCP обычно сосредотачивает оркестрацию в хосте и передает узкие возможности командам, которые владеют системами учета. Это хорошо работает, если владельцы инструментов публикуют стабильные схемы и сами отвечают за авторизацию. Модель ломается, когда «команда ИИ-платформы» согласовывает каждое изменение инструмента или серверы просто повторяют огромные внутренние API, которыми модели не умеют надежно пользоваться.

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

Поэтому я возражаю против идеи сначала построить универсальную сеть агентов. Она популярна, потому что инфраструктуру легко измерять, а внутри компании она кажется политически нейтральной. Но без доказанных процессов команда не знает, какие состояния задач, точки подтверждения, цели обслуживания и поля аудита действительно нужны. Узкая вертикальная реализация быстро показывает эти требования.

Во время Team & AI Audit на oleg.is я связываю работу над протоколами с инженерными часами и передачами между людьми, которые она устраняет, а затем убираю интеграции, создающие больше эксплуатационной нагрузки, чем продукта. Эту проверку можно провести самостоятельно: назовите результат для пользователя, текущее узкое место, владельца каждой стороны и сбой, который должен сдержать стандарт.

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