MCP и A2A: как работают протоколы AI-агентов в 2026

В 2025 году AI-агенты перестали быть игрушкой. Компании вроде OpenAI, Anthropic, Google и Microsoft вложили миллиарды в агентные системы. Но чем больше становилось агентов, тем острее вставала проблема: как они общаются друг с другом и с внешними инструментами? Весной 2025 года появились сразу два стандарта — MCP от Anthropic и A2A от Google. Индустрия быстро поняла, что это не конкуренты, а взаимодополняющие протоколы. Разберёмся, чем они отличаются, как устроены и когда каждый нужен.

Проблема, которую решают протоколы

Представьте: вы разработали умного ассистента поддержки. Он обучен на документации компании, умеет отвечать на вопросы клиентов, даже обращаться к CRM за историей заказов. Работает. А потом появляется задача: пусть этот ассистент ещё и передаёт сложные запросы в бухгалтерию, где крутится другой агент, обученный на 1С. И вот начинается ад. Каждый агент говорит на своём языке, использует свои API, свои форматы данных. Никакой стандартизации.

До весны 2025 года экосистема AI-агентов напоминала интернет до появления HTTP-протокола — каждый сервер изобретал свой способ передачи данных. Кто-то использовал REST, кто-то GraphQL, кто-то просто скрипты на Python, которые дёргали базу напрямую. В мультиагентной системе с тремя агентами число интеграций росло квадратично. С пятью — становилось неконтролируемым.

MCP (Model Context Protocol) от Anthropic закрыл одну часть проблемы — унифицировал доступ агента к инструментам: базам данных, API, файлам и любым внешним сервисам. Протокол A2A (Agent-to-Agent) от Google закрыл другую — стандартизировал общение между самими агентами. По отдельности каждый решает только половину задачи. Вместе — покрывают весь спектр взаимодействия.

MCP (Model Context Protocol) от Anthropic

Anthropic представила MCP в ноябре 2024 года как открытый стандарт для подключения LLM к внешним источникам данных и инструментам. К середине 2025 года протокол поддержали десятки компаний — OpenAI, Microsoft, Google, AWS, Cloudflare — и сообщество создало более 1200 MCP-серверов для самых разных задач: от интеграции с Google Calendar до работы с PostgreSQL и Slack.

Архитектура MCP простая и элегантная: клиент-серверная модель. LLM-клиент (агент) подключается к MCP-серверу через стандартизированный транспорт. Сервер предоставляет три типа возможностей:

Tools — исполняемые функции, которые агент может вызвать: создать тикет в Jira, отправить email, выполнить SQL-запрос. Resources — структурированные данные, которые агент может прочитать: документацию, схему БД, текущие значения метрик. Prompts — готовые шаблоны промптов для типовых сценариев. Каждый MCP-сервер может комбинировать эти примитивы в любых пропорциях.

Транспортный уровень MCP поддерживает два режима: stdio (через стандартный ввод-вывод, удобно для локальных процессов) и SSE (Server-Sent Events, для удалённых серверов). В 2026 году Cloud.ru и другие провайдеры начали предлагать готовые MCP-шлюзы, где серверы работают как managed-сервис без настройки инфраструктуры.

На практике MCP-сервер часто выглядит как простой Python-скрипт на FastMCP или TypeScript-сервер на SDK от Anthropic. Разработчику достаточно описать инструменты через декораторы или аннотации типов — протокол сам берёт на себя сериализацию, обработку ошибок и управление контекстом. Многие серверы публикуются в открытом доступе на GitHub и устанавливаются одной командой.

A2A (Agent-to-Agent) от Google

В апреле 2025 года Google выпустила A2A — протокол для прямого общения между агентами. Если MCP решает задачу «агент — мир инструментов», то A2A решает задачу «агент — агент». И Google сделала это с размахом: на старте протокол поддержали более 55 партнёров, включая Salesforce, SAP, LangChain, CrewAI и MongoDB.

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

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

Важная деталь: A2A поддерживает длительные задачи (async tasks). Агент-исполнитель может сразу ответить «принял в работу, вот ID задачи», а потом отправить уведомление о завершении через SSE или webhook. Это кардинально отличает его от простого «запрос-ответ» — агенты могут работать минуты или часы, собирая данные из разных источников.

Протокол использует TLS для шифрования и поддерживает несколько уровней аутентификации: от простого API-ключа до OAuth 2.0. Google явно закладывала enterprise-сценарии — безопасность и аудит встроены в протокол с первого дня, а не добавлены заплаткой позже.

Сравнение: что и когда использовать

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

Параметр	MCP	A2A
Кто создал	Anthropic (ноябрь 2024)	Google (апрель 2025)
Назначение	Подключение LLM к инструментам	Общение агентов между собой
Архитектура	Клиент-сервер	Peer-to-peer с Agent Card
Транспорт	stdio / SSE	HTTP / SSE / WebSocket
Обнаружение	Явное подключение	Автоматическое (Agent Card)
Асинхронность	Нет (синхронный вызов)	Да (long-running tasks)

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

MCP + A2A: как они работают вместе

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

Возьмём типичный кейс из практики N202: автоматизация входящих заявок в B2B-компании. Клиент пишет в Telegram-бота: «Хочу купить 50 лицензий, выставьте счёт». Бот — это первый агент (Coordinator). Он через MCP-сервер подключается к CRM, чтобы проверить, есть ли у клиента договор, и к базе знаний — чтобы найти актуальные цены. MCP-серверы здесь работают как адаптеры: CRM может быть на AmoCRM, 1С или Salesforce — MCP-сервер скрывает эти детали.

Получив контекст, Coordinator через A2A отправляет задачу агенту InvoiceGen: «Сформируй счёт на 50 лицензий по таким-то ценам». Важный момент: Coordinator не знает, как InvoiceGen устроен внутри. Ему достаточно Agent Card — JSON-описания, которое InvoiceGen опубликовал: «Я умею создавать счета, принимаю ID клиента и список позиций, возвращаю ссылку на PDF». Это service discovery для агентов, только без единой точки отказа.

InvoiceGen через свой MCP-сервер обращается к 1С или Stripe API, создаёт документ и возвращает ссылку. Координатор забирает результат, отправляет клиенту — и параллельно через A2A дёргает агента LeadScorer: «Обнови статус лида, перешёл в оплату». Если LeadScorer в этот момент занят другим запросом — A2A поддерживает очередь и асинхронные ответы. LeadScorer может ответить через минуту: «Обновил, новый скор — 92 (горячий лид)».

CrewAI, LangGraph и другие фреймворки уже добавили встроенную поддержку обоих протоколов в 2025-2026 годах. В LangGraph, например, A2A-вызов узла — это просто ещё один тип edge в графе. В CrewAI можно пометить агента как «доступный по A2A», и он автоматически публикует свою Agent Card при старте. Фреймворки берут на себя всю рутину: маршаллинг сообщений, обработку ошибок, ретраи.

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

На практике мы в N202 заметили чёткую закономерность: проекты, где MCP и A2A закладывались с первого дня, дорастали до 5-7 агентов без архитектурных болей. А те, где протоколы добавляли «потом», переписывали интеграции в среднем дважды. Не потому что протоколы сложные, а потому что без них каждый агент обрастает собственной транспортной логикой: один использует Redis Pub/Sub, второй — прямой HTTP, третий — WebSocket. Когда агентов становится много, хаос нарастает.

Как внедрить в свой проект

Начать можно с малого. Если у вас уже есть AI-агент на Python или TypeScript, подключить MCP — задача на вечер. Установите SDK от Anthropic (pip install fastmcp или npm install @modelcontextprotocol/sdk), оберните ваши существующие API-вызовы в инструменты, и LLM получит к ним унифицированный доступ. Вот минимальный пример MCP-сервера на Python:

from fastmcp import FastMCP

mcp = FastMCP("database-agent")

@mcp.tool()
def get_user_orders(user_id: str) -> list:
    """Получить список заказов пользователя."""
    return db.query("SELECT * FROM orders WHERE user_id = ?", user_id)

mcp.run()

Дальше — подключить A2A, если в системе больше одного агента. Google предоставляет SDK на Python и TypeScript с готовыми классами AgentCard, Task и Message. Достаточно создать карточку своего агента, реализовать обработчик входящих задач — и агент готов к общению с любым другим A2A-совместимым агентом.

В нашем гайде по MCP-серверу мы подробно разобрали настройку протокола для бизнес-сценариев. А если вы присматриваетесь к фреймворкам — у нас есть гайд по LangGraph, где показано, как строить мультиагентные системы с MCP-интеграцией.

Коротко

MCP и A2A — это два стандарта, которые превратили AI-агентов из экспериментальных прототипов в промышленные инструменты. MCP даёт агенту «руки» (доступ к данным и API), A2A — «язык» (общение с другими агентами). По отдельности каждый решает ровно половину проблем агентной архитектуры. Вместе — закрывают все основные сценарии enterprise-внедрения.

Если вы строите систему на AI-агентах — неважно, для поддержки, продаж или автоматизации внутренних процессов — имеет смысл закладывать поддержку обоих протоколов с самого начала. Не потому что «модно», а потому что переписывать интеграции, когда агентов станет больше двух, в разы дороже.

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