Карта экосистемы протоколов AI-агентов 2026
загрузок MCP
партнёров запуска A2A
ключевых протокола экосистемы
год сближения протоколов
Что важно понять сразу
Ещё совсем недавно рынок протоколов для AI-агентов напоминал ящик с проводами под столом: всё вроде подключено, но лучше не трогать. В 2024 году почти каждый фреймворк для агентных систем тащил за собой собственные соглашения о вызове инструментов, собственную логику координации и, если доходило до транзакций, собственные костыли. К марту 2026-го картина стала заметно чище: на поверхности остались четыре протокола с реальным отраслевым весом — MCP, A2A, ACP и UCP.
Ниже — не просто обзор, а карта экосистемы: кто за что отвечает, где проходят границы, как протоколы сочетаются между собой и что это значит для бизнеса, который планирует разработку AI-агентов и автоматизацию. Если вы проектируете корпоративную платформу, оцениваете мультиагентные системы или выбираете базу под enterprise AI, понимать эту схему уже не роскошь, а рабочая необходимость.
Важно: все цифры, версии и статусы внедрения в этом материале отражают состояние рынка на март 2026 года. Экосистема двигается быстро, местами даже нервно, поэтому часть деталей со временем наверняка уточнится.
Четыре протокола. Один стек.
Если отбросить маркетинговый шум, логика довольно простая. Эти четыре протокола работают на разных этажах одной и той же системы: один отвечает за доступ к инструментам, другой — за взаимодействие между агентами, ещё два — за коммерческие операции. То есть речь не о битве стандартов, а о разделении ролей внутри агентной архитектуры.
Стек протоколов AI-агентов — визуальная карта
Как MCP, A2A, ACP и UCP складываются в рабочую архитектуру enterprise AI
Открытые транзакции agent-to-agent — IBM / Linux Foundation
Коммерческие сценарии внутри экосистемы Google — Google
Обнаружение агентов, делегирование задач и защищённая межагентная коммуникация — Google (50+ партнёров)
Стандартизированное подключение agent-to-tool и agent-to-data — Anthropic (97M загрузок, широкая кросс-вендорная поддержка)
Claude, GPT-4o, Gemini, Llama и другие модели внутри агентных фреймворков: LangChain, AutoGen, CrewAI, LlamaIndex и кастомных платформ
Читать этот стек лучше снизу вверх. Сначала — модель и runtime, где живут рассуждение, планирование и выполнение. Затем MCP, который открывает агенту доступ к внешним данным и действиям. Выше — A2A, если агентам нужно координироваться между собой. И уже поверх этого — ACP или UCP, когда в сценарии появляются закупки, продажи, офферы, оплата и прочая взрослая жизнь.
Для команд, которые занимаются архитектурой AI-агентов, это, пожалуй, главный принцип: не путать уровни. Иначе система быстро превращается в набор пересекающихся интеграций, который сложно масштабировать, защищать и объяснять аудиторам.
MCP: как агент получает доступ к инструментам
Model Context Protocol — базовый протокол всей экосистемы. Его придумала Anthropic и открыла как open source в ноябре 2024 года. По сути, MCP задаёт стандартный клиент-серверный интерфейс, через который AI-агенты могут обращаться к внешним возможностям: API, базам данных, файловым системам, поиску, выполнению кода, внутренним сервисам компании и любым другим инструментам, которые разработчик выставляет через MCP-сервер.
Почему MCP так быстро взлетел? Потому что он решает очень приземлённую проблему. До него каждая команда городила собственный способ «подружить» модель с инструментами. С MCP появляется единый контракт. Не идеальный, не волшебный — но единый. А это в инфраструктуре почти всегда важнее блеска.
MCP-сервер — это относительно лёгкий процесс, который публикует tools, resources и prompts. Каждый tool описывается как типизированная функция, обычно со схемой входных параметров на JSON Schema. Агент вызывает инструмент по имени, сервер исполняет запрос и возвращает структурированный результат. На практике такие серверы делают для CRM, ERP, БД, браузеров, IDE, внутренних API и SaaS-платформ.
Клиентом MCP выступает runtime агента: Claude Desktop, VS Code Copilot, Cursor, Gemini CLI или собственная платформа. Клиент считывает manifest сервера, понимает, какие инструменты доступны, и передаёт эти описания модели в контекст выполнения. Дальше агент уже решает, когда и какой инструмент вызвать.
MCP поддерживает stdio для локальных процессов и HTTP с Server-Sent Events для удалённых развёртываний. Это важно: локальный режим удобен для desktop-сценариев и разработки, а HTTP нужен там, где начинается production, масштабирование и нормальная эксплуатация, без магии на честном слове.
Как выглядит подключение по MCP
Граница ответственности MCP: этот протокол отвечает только за взаимодействие agent-to-tool. Он не описывает, как один агент делегирует задачу другому, как ведутся переговоры между агентами или как оформляется коммерческая транзакция. Если агент обращается к базе данных — это MCP. Если он передаёт подзадачу другому агенту — это уже не MCP, а, как правило, A2A.
Именно поэтому разработка агентов сегодня почти всегда начинается с MCP-слоя. Спецификация сравнительно компактная, SDK доступны, а ценность появляется быстро: один раз нормализовали доступ к инструментам — и дальше можете подключать разные модели, рантаймы и сценарии автоматизации без полного переписывания интеграций.
Есть и ещё один момент, о котором иногда забывают. MCP хорошо сочетается с агентной памятью и RAG: retrieval-слой, векторные хранилища, корпоративные документы и поисковые индексы можно выставлять как инструменты или ресурсы, а не вшивать намертво в конкретный фреймворк. Это делает архитектуру заметно спокойнее в сопровождении.
A2A: когда агентам нужно разговаривать друг с другом
Протокол Agent-to-Agent от Google, представленный в апреле 2025 года вместе с 50+ партнёрами запуска, решает задачу, которую MCP специально не трогает: координацию между агентами. В мультиагентной системе один агент может выступать оркестратором, а специализированные агенты — брать на себя исследование, анализ, генерацию текста, расчёты, проверку соответствия требованиям и другие функции.
И вот тут начинается совсем другая логика. Инструмент не рассуждает. Агент — рассуждает. Инструмент не планирует. Агент — планирует. Поэтому подменять межагентное взаимодействие обычными tool-вызовами — идея так себе, если мягко.
Схема координации по A2A
Ключевой элемент A2A — Agent Card. Это JSON-документ, который публикуется через well-known endpoint и описывает возможности агента, ожидаемые входы и выходы, правила аутентификации и ограничения доступа. Благодаря Agent Cards оркестратор может динамически находить подходящих агентов, а не жить в мире жёстко прописанных интеграций.
- — Agent Card объявляет требования к аутентификации
- — OAuth 2.0 или API key для доступа к агенту
- — scope-ограничения на допустимые действия
- — audit trail делегирования задач
- — human-in-the-loop для чувствительных операций
- — уникальные ID задач и явные состояния жизненного цикла
- — streaming-обновления через Server-Sent Events
- — типизированные артефакты в ответах
- — push-уведомления для асинхронного завершения
- — структурированные коды ошибок для программной обработки
На практике A2A почти всегда живёт рядом с MCP, а не вместо него. Оркестратор делегирует задачу через A2A, а каждый дочерний агент уже использует свои MCP-подключения к данным и инструментам. Это нормальная, здоровая схема. Собственно, так и строятся мультиагентные системы, если их делают не на коленке.
Отдельно стоит думать про безопасность AI-агентов. Как только в архитектуре появляется делегирование между агентами, резко возрастает значение аутентификации, разграничения полномочий, журналирования и контроля автономных действий. Иначе один неудачный сценарий — и разбираться потом будет очень, очень весело.
ACP: открытая коммерция между агентами
Agent Commerce Protocol, который развивают IBM Research и экосистема Linux Foundation, переносит агентное взаимодействие в плоскость коммерческих транзакций. Если MCP отвечает за доступ к инструментам, а A2A — за делегирование и координацию, то ACP описывает, как агенты обсуждают цену, формируют офферы, подтверждают сделку, инициируют оплату и отслеживают исполнение.
Иными словами, ACP нужен там, где агент уже не просто «что-то делает», а реально участвует в покупке или продаже. Это совсем другой уровень риска, ответственности и требований к управлению. Тут уже не до красивых демо.
- автономные B2B-закупки, где purchasing-агенты взаимодействуют с поставщиками
- API marketplace, в которых агенты покупают данные, вычисления или сервисы по запросу
- кросс-вендорные рынки агентных услуг
- автоматизированный выбор поставщика в рамках утверждённых лимитов и правил
Сильная сторона ACP — модель управления через Linux Foundation. Для enterprise-команд это не мелочь: спецификация развивается через более формальный, коллективный процесс, а значит, лучше подходит для долгосрочных сценариев, где важны стабильность, предсказуемость и соответствие требованиям. Да, развитие может идти медленнее. Но иногда медленнее — это как раз надёжнее.
Если компания рассматривает автономные закупки, агентные маркетплейсы или финансово значимые workflow, без слоя AI compliance и соответствия требованиям туда лучше даже не заходить. Серьёзно. Нужны лимиты, журналирование, контроль контрагентов, правила эскалации и понятная модель ответственности.
UCP: коммерческий протокол Google для агентных покупок
Universal Commerce Protocol от Google — самый узкоспециализированный из четырёх ключевых протоколов. Если ACP пытается быть открытым стандартом агентной коммерции, то UCP заточен под сценарии внутри экосистемы Google: Google Shopping, Merchant Center, Business Profile и связанные коммерческие данные в инфраструктуре Google.
UCP-агенты получают доступ к структурированным данным Google Shopping: карточкам товаров, ценам, наличию, рейтингам продавцов и прогнозам доставки. Это богаче и надёжнее, чем пытаться вытаскивать ту же информацию через обычный web search.
Продавцы могут публиковать совместимые с UCP agent actions для каталога. Тогда shopping-агент способен добавить товар в корзину, оформить заказ и отслеживать доставку без скрейпинга сайта и без отдельной кастомной интеграции под каждого продавца.
UCP соединяет agentic search в Google с реальным действием покупки. Агент не просто находит товар — он может довести пользователя до транзакции внутри той же экосистемы.
Граница между UCP и ACP: если бизнес в основном живёт внутри коммерческой инфраструктуры Google, UCP выглядит естественным выбором. Если же нужен открытый, мультивендорный сценарий без привязки к одной платформе, логичнее смотреть в сторону ACP. В крупных архитектурах возможна и комбинация обоих подходов — да, такое тоже бывает.
Где протоколы пересекаются, а где — нет
Самые дорогие архитектурные ошибки обычно происходят не из-за отсутствия технологий, а из-за путаницы в границах. Команда видит, что два протокола «вроде умеют передавать данные», и решает, что они взаимозаменяемы. А потом начинается переделка. Долгая. Нервная.
| Тип коммуникации | MCP | A2A | ACP | UCP |
|---|---|---|---|---|
| Агент вызывает внешний API | Основной | |||
| Агент читает из базы данных | Основной | |||
| Агент делегирует задачу другому агенту | Основной | |||
| Агент обнаруживает возможности другого агента | Основной | |||
| Обмен файлами или данными между агентами | возможно | Основной | ||
| Согласование цены покупки | частично | Основной | ||
| Завершение транзакции покупки | Основной | Основной | ||
| Покупки в Google Shopping | Основной | |||
| Доступ к Google Knowledge Graph | возможно | Основной | ||
| Автономные B2B-закупки | частично | Основной |
Самая важная граница — между MCP и A2A. Оба протокола могут передавать структурированные данные, но смысл у них разный. MCP нужен для вызова пассивного инструмента. A2A — для взаимодействия с автономным агентом, у которого есть собственный контекст, логика, состояние и жизненный цикл задач. Смешивать эти роли — всё равно что пытаться нанять калькулятор руководителем проекта. Формально он что-то считает, но дальше начинаются нюансы.
Кто что поддерживает: матрица внедрения
Поддержка со стороны крупных вендоров определяет не только популярность протокола, но и реальную интероперабельность. Чем шире поддержка, тем ниже риск vendor lock-in и тем проще строить переносимую инфраструктуру AI-автоматизации.
| Вендор / Платформа | MCP | A2A | ACP | UCP |
|---|---|---|---|---|
| Anthropic (Claude) | Создатель | Клиент | — | — |
| Google (Gemini / Vertex) | Полная | Создатель | — | Создатель |
| OpenAI (GPT / Assistants) | Полная | Партнёр | — | — |
| Microsoft (Copilot / Azure) | Полная | Партнёр | — | — |
| Amazon (Bedrock) | Полная | Партнёр | — | — |
| IBM (watsonx) | Полная | Партнёр | Создатель | — |
| Salesforce (Einstein) | Полная | Партнёр | — | — |
| LangChain | Полная | Полная | Планируется | — |
| AutoGen (Microsoft) | Полная | Полная | — | — |
| CrewAI | Полная | Полная | Планируется | — |
Из всех четырёх протоколов именно MCP сегодня имеет самую широкую и зрелую поддержку. Он уже вышел за рамки «инициативы Anthropic» и превратился в межвендорный стандарт де-факто. У A2A старт очень сильный, но у него меньше production-истории. ACP и UCP пока заметно нишевее — в основном потому, что далеко не каждая компания уже дошла до автономной агентной коммерции.
Как выбрать правильную комбинацию протоколов
Выбор стека должен идти от сценария, а не от симпатии к конкретному вендору или модному термину. Ниже — практичная схема, без лишней романтики.
Один агент, работающий с данными и инструментами
Нужен: только MCP. Если у вас один агент и ему требуется доступ к CRM, БД, документам, API и внутренним сервисам, не усложняйте. Поднимите MCP-серверы, нормализуйте доступ к инструментам и получите базу для дальнейшей автоматизации.
Несколько специализированных агентов
Нужны: MCP + A2A. Каждый агент использует MCP для своих инструментов, а A2A отвечает за делегирование задач, обнаружение возможностей и координацию. Это типовой вариант для enterprise-сценариев, где один универсальный агент уже начинает захлёбываться.
Автономные транзакции с поставщиками
Нужны: MCP + A2A + ACP. Добавляйте ACP, если агентам предстоит запрашивать цены, согласовывать условия, оформлять заказы и работать в рамках утверждённых лимитов. Начинать лучше с read-only сценариев и только потом переходить к write-операциям.
Shopping-агенты в экосистеме Google
Нужны: MCP + A2A + UCP. Если продукт строится вокруг Google Shopping и связанных поверхностей Google, UCP даёт более прямой и богатый доступ к commerce-данным и транзакционным действиям внутри этой среды.
Проще говоря: большинству компаний сначала нужен MCP. Потом, возможно, A2A. А до ACP или UCP доходят уже те, у кого агентные сценарии действительно упираются в коммерческие операции, а не просто в красивую презентацию для совета директоров.
Практический план внедрения для бизнеса
Для руководителей вопрос обычно звучит не как «какой протокол лучший?», а как «что именно нам нужно построить, чтобы AI-агенты приносили пользу, а не создавали новый слой хаоса?». И это, пожалуй, правильная постановка.
Проведите аудит всех инструментов, API и источников данных, с которыми уже работают ваши AI-сценарии. Затем вынесите доступ к ним в MCP-серверы. Это создаст единый слой интеграции для текущих и будущих агентных платформ.
Когда слой инструментов стабилен, можно проектировать мультиагентную топологию: роли агентов, зоны ответственности, правила делегирования, Agent Cards, маршрутизацию задач. Не раньше. Ну правда, не раньше.
ACP или UCP стоит рассматривать только после того, как организация получила реальный операционный опыт с агентными workflow, а процессы контроля, аудита и исключений перестали быть теорией на слайдах.
Лучше всего переживают время те архитектуры, которые строятся поверх стандартных протокольных интерфейсов, а не вокруг SDK одного вендора. Сегодня у вас один runtime, завтра — другой. Сегодня один orchestration layer, через год — новый. Если логика системы завязана на протоколы, а не на частные API, переносимость и управляемость остаются на вашей стороне.
Итог — без лишнего пафоса
К 2026 году экосистема протоколов AI-агентов стала заметно понятнее. MCP закрепился как универсальный слой доступа к инструментам. A2A оформился как протокол координации между агентами. ACP и UCP заняли коммерческий слой — один в открытой мультивендорной среде, другой внутри Google-экосистемы.
Главный вывод простой: не нужно внедрять все четыре протокола сразу только потому, что они существуют. Нужно выбрать те, которые соответствуют вашей задаче. Для большинства компаний путь выглядит так: сначала MCP, затем — при необходимости — A2A, и только потом коммерческие протоколы. Спокойно, по слоям, без героизма. Так надёжнее.
Соберите рабочий стек AI-агентов
Если вам нужна не просто теория, а практическая архитектура — от MCP и агентной памяти до мультиагентной оркестрации, безопасности и AI compliance, команда SynthIQ поможет спроектировать и внедрить решение под ваш контекст.