MCP vs A2A vs ANP: протоколы ИИ-агентов

Что такое протоколы ИИ-агентов и зачем они нужны?

Протоколы ИИ-агентов — это открытые стандарты, которые определяют, как агенты подключаются к инструментам, общаются друг с другом и находят пиров в сети. Без них каждая интеграция — это кастомная обёртка над API. С ними можно заменить модель или инструмент, и всё продолжит работать.

Для разработчиков, строящих агентные системы, важны три протокола: MCP (Model Context Protocol), A2A (Agent-to-Agent Protocol) и ANP (Agent Network Protocol). Они не конкуренты. Это слои в стеке.

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

Эта статья — ментальная модель. Без кода. Только карта, которая нужна перед тем, как начать строить.

Что такое MCP (Model Context Protocol)?

MCP — открытый стандарт, изначально созданный Anthropic. Он определяет, как ИИ-агенты подключаются к внешним инструментам и источникам данных. MCP-серверы предоставляют возможности MCP-клиентам, встроенным в ИИ-приложения. Представьте себе USB-порт для ИИ: единый интерфейс между любым агентом и любым инструментом. В декабре 2025 года Anthropic передал MCP в Agentic AI Foundation (AAIF) под управлением Linux Foundation.

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

Как работает MCP?

MCP определяет три роли:

Host: ИИ-приложение (Claude Desktop, Cursor, ваше приложение). Управляет одним или несколькими MCP-клиентами.
Client: Коннектор внутри хоста, который поддерживает соединение 1:1 с MCP-сервером.
Server: Легковесный сервис, который предоставляет клиентам инструменты, ресурсы и промпты.

Коммуникация использует JSON-RPC 2.0 по одному из двух типов транспорта:

stdio: Стандартный ввод/вывод. Лучший вариант для локальных серверов на той же машине. Хост запускает сервер как дочерний процесс.
Streamable HTTP: HTTP-транспорт, позволяющий MCP-серверам работать как удалённые сервисы. Клиент отправляет JSON-RPC-запросы через HTTP POST. Сервер может стримить ответы. Именно это даёт возможность запускать MCP-серверы на VPS и подключаться к ним удалённо.

Старый транспорт SSE (Server-Sent Events) всё ещё работает, но вытесняется Streamable HTTP, который поддерживает stateless-режим и горизонтальное масштабирование без sticky-сессий.

MCP-серверы предоставляют три типа примитивов:

Примитив	Назначение	Управление
Tools	Функции, которые ИИ-модель может вызывать (запросить базу, отправить email, запустить скрипт)	Управляется моделью (LLM решает, когда вызывать)
Resources	Данные, которые агент может читать (файлы, записи, ответы API)	Управляется приложением (хост решает, что предоставить)
Prompts	Шаблоны сообщений и воркфлоу	Управляется пользователем (пользователь выбирает из доступных промптов)

Соединения — stateful. Клиент и сервер согласовывают возможности при инициализации, затем обмениваются сообщениями по постоянному соединению. Серверы также могут запрашивать sampling (попросить LLM сгенерировать текст) и elicitation (попросить пользователя ввести данные), что включает рекурсивное агентное поведение.

Как выглядит экосистема MCP в 2026 году?

MCP — протокол интеграции по умолчанию для ИИ-инструментов в 2026 году:

97М+ скачиваний SDK в месяц для Python и TypeScript
10 000+ публичных MCP-серверов в продакшене
Принят всеми крупными ИИ-платформами: Claude, ChatGPT, Gemini, Copilot, Cursor, VS Code
Управляется AAIF под Linux Foundation, основанной Anthropic, OpenAI и Block
Текущая версия спецификации: 2025-11-25

Дорожная карта на 2026 год сфокусирована на выводе Streamable HTTP в продакшен на масштабе: stateless-обработка запросов, упрощённое горизонтальное масштабирование и стандартный способ для реестров обнаруживать возможности серверов без подключения.

Что такое A2A (Agent-to-Agent Protocol)?

A2A (Agent-to-Agent Protocol) — открытый протокол, изначально созданный Google, который стандартизирует взаимодействие и совместную работу ИИ-агентов. Один агент отправляет задачу другому через JSON-RPC по HTTP. Принимающий агент публикует Agent Card с описанием своих возможностей, требований к аутентификации и URL эндпоинта. A2A управляет жизненным циклом задач, стримингом результатов и пуш-уведомлениями для долгих операций.

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

Как работает A2A?

A2A определяет три роли:

User: Человек или автоматизированный сервис, запрашивающий работу.
A2A Client: Приложение, отправляющее задачи от имени пользователя.
A2A Server: Удалённый агент с HTTP-эндпоинтом. Работает как чёрный ящик.

Agent Card — механизм обнаружения. Каждый A2A-сервер публикует JSON-документ (обычно по адресу /.well-known/agent-card.json), описывающий:

Идентичность агента (имя, описание, провайдер)
URL сервисного эндпоинта
Поддерживаемые возможности (стриминг, пуш-уведомления)
Доступные навыки с описаниями
Требования к аутентификации
Опциональную цифровую подпись для верификации

Task (задача) — единица работы. У каждой задачи уникальный ID и жизненный цикл:

submitted → working → completed
                   → failed
                   → canceled
                   → rejected
           → input-required (multi-turn: агенту нужна дополнительная информация от клиента)

Сообщения содержат Parts: текст, ссылки на файлы или структурированные JSON-данные. Результаты задач называются Artifacts, которые тоже содержат Parts. Агент может вернуть файл с кодом, текстовую сводку и JSON-отчёт в одном ответе.

A2A поддерживает три паттерна коммуникации:

Request/Response: Клиент отправляет задачу, опрашивает статус через GetTask.
Streaming (SSE): Инкрементальные обновления в реальном времени через постоянные HTTP-соединения. Клиент вызывает SendStreamingMessage и получает события по мере работы агента.
Push Notifications (Webhooks): Для долгих задач агент отправляет обновления статуса POST-запросом на webhook-URL, зарегистрированный клиентом.

Вся коммуникация — JSON-RPC 2.0 поверх HTTPS. Версия 0.3 добавила поддержку gRPC и подписанные Agent Card. Текущая версия — A2A v1.0.0.

Как объединились A2A и ACP?

IBM запустил Agent Communication Protocol (ACP) в марте 2025 для своей платформы BeeAI. Google анонсировал A2A месяцем позже. Оба протокола решали одну задачу: коммуникацию между агентами.

В августе 2025 Linux Foundation объявил о слиянии ACP с A2A. Команда ACP из IBM во главе с Kate Blair вошла в Технический руководящий комитет A2A вместе с Google, Microsoft, AWS, Cisco, Salesforce, ServiceNow и SAP. Платформа BeeAI перешла с ACP на A2A, разработка ACP прекратилась.

Если вы рассматривали ACP отдельно — хватит. Ответ: A2A.

Что такое ANP (Agent Network Protocol)?

ANP (Agent Network Protocol) — одноранговый протокол, позволяющий ИИ-агентам обнаруживать друг друга и общаться в открытых сетях без центрального органа. В отличие от клиент-серверной модели MCP и клиент-серверной делегации задач A2A, ANP рассматривает каждого агента как равноправного пира. Он использует W3C Decentralized Identifiers (DIDs) для идентификации, JSON-LD для обмена данными и включает уровень мета-протокола, где агенты договариваются о способе коммуникации.

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

Чем ANP отличается от A2A?

У ANP трёхуровневая архитектура:

Уровень 1: Идентификация и зашифрованная коммуникация. Каждый агент получает W3C Decentralized Identifier по методу did:wba (Web-Based Agent). Каждый DID ссылается на DID-документ, размещённый по HTTPS, поэтому разрешение идентификаторов использует существующую веб-инфраструктуру. Два агента могут взаимно верифицировать идентичность и установить зашифрованные каналы без центрального органа.

Уровень 2: Мета-протокол. Агенты динамически согласовывают протоколы коммуникации. Вместо того чтобы обоим поддерживать один фиксированный протокол, они обмениваются требованиями в структурированном виде, договариваются о протоколе и затем общаются через него. Это делает ANP адаптивным к сценариям, которые фиксированный JSON-RPC-подход A2A не может покрыть.

Уровень 3: Прикладной протокол. Описания агентов используют JSON-LD, связанный с онтологиями schema.org. Обнаружение работает двумя способами:

Активное обнаружение: Запрос к эндпоинту /.well-known/agent-descriptions домена.
Пассивное обнаружение: Агенты регистрируются в индексирующих сервисах, которые обходят и каталогизируют описания.

Архитектурное сравнение ANP и A2A:

Аспект	A2A	ANP
Топология	Клиент-сервер	Одноранговая
Идентификация	Agent Card (самоопубликованный JSON)	W3C DIDs (децентрализованные, верифицируемые)
Обнаружение	Известный URL (`/.well-known/agent-card.json`)	Децентрализованная индексация + well-known эндпоинты
Гибкость протокола	Фиксированный (JSON-RPC 2.0)	Согласование через мета-протокол
Формат данных	JSON Parts (текст, файлы, структурированные данные)	JSON-LD (семантически связанные данные)

Текущий статус: ANP находится на стадии предложения и ранней разработки. Есть GitHub-репозиторий и белая книга W3C Community Group, но нет продакшен-SDK или широкого внедрения. Спецификация не управляется AAIF.

Как сравнить MCP, A2A и ANP?

Три протокола по параметрам, которые важны при проектировании агентной системы:

	MCP	A2A	ANP
Решаемая задача	Подключение агента к инструментам	Делегирование задач между агентами	Обнаружение и коммуникация агентов между сетями
Архитектура	Клиент-сервер (host → client → server)	Клиент-сервер (client → удалённый агент)	Одноранговая (агент ↔ агент)
Транспорт	stdio, Streamable HTTP	HTTPS (JSON-RPC 2.0), SSE, gRPC	HTTPS, согласуемый через мета-протокол
Модель идентификации	Идентичность сервера неявная (настраивается хостом)	Agent Card (самоопубликованный JSON)	W3C DIDs (`did:wba`)
Формат данных	JSON-RPC 2.0	JSON-RPC 2.0 с Parts (текст, файлы, структурированные)	JSON-LD (семантические связанные данные)
Обнаружение	Ручная настройка или запрос к реестру	`/.well-known/agent-card.json`	DID-разрешение + децентрализованная индексация
Управление	AAIF / Linux Foundation	AAIF / Linux Foundation	W3C Community Group (независимый)
Версия спецификации	2025-11-25	v1.0.0	Стадия белой книги
Зрелость	Продакшен (97М+ скачиваний SDK в месяц)	Продакшен (v1.0.0, SDK крупных вендоров)	Ранняя разработка (нет продакшен-SDK)
Сценарий использования	Дать агенту доступ к базам данных, API, файлам	Дать агенту возможность делегировать работу специализированным агентам	Позволить агентам находить друг друга в открытом интернете

Как эти протоколы работают вместе?

Эти протоколы — не альтернативы. Это уровни. Возьмём конкретный пример.

Допустим, вы запускаете агента-программиста на своём VPS. Ему нужно:

Читать файлы из вашего Git-репозитория
Запрашивать базу данных проекта для получения информации о схеме
Попросить отдельного агента-ревьюера проверить его работу
Найти агента для деплоя, которым управляет инфраструктурная команда вашего клиента

Протоколы укладываются так:

┌─────────────────────────────────────────────────────────┐
│                    Ваш VPS                               │
│                                                         │
│  ┌──────────────┐    MCP     ┌───────────────────────┐  │
│  │              │◄──────────►│ MCP Server: Git tools  │  │
│  │  Агент-      │            └───────────────────────┘  │
│  │  програм-    │    MCP     ┌───────────────────────┐  │
│  │  мист        │◄──────────►│ MCP Server: DB schema  │  │
│  │  (Host)      │            └───────────────────────┘  │
│  │              │                                       │
│  │              │    A2A     ┌───────────────────────┐  │
│  │              │───────────►│ Review Agent (A2A)     │  │
│  └──────┬───────┘            └───────────────────────┘  │
│         │                                               │
└─────────┼───────────────────────────────────────────────┘
          │
          │  ANP (обнаружение между сетями)
          ▼
┌─────────────────────────┐
│ Агент деплоя клиента     │
│ (обнаружен через         │
│ DID-разрешение)          │
└─────────────────────────┘

Уровень 1 (MCP): Агент-программист использует MCP-клиенты для подключения к локальным MCP-серверам для Git-операций и запросов к базе. Это интеграции инструментов. Агент вызывает функции и читает данные.

Уровень 2 (A2A): Агент-программист делегирует код-ревью отдельному агенту-ревьюеру на том же сервере (или другом). Он отправляет задачу через A2A, агент-ревьюер работает асинхронно и стримит результаты обратно. Агент-программист не знает, какую модель или фреймворк использует агент-ревьюер.

Уровень 3 (ANP): Агенту-программисту нужно найти агента деплоя, с которым он никогда не взаимодействовал, управляемого другой организацией. DID-обнаружение ANP находит агента, верифицирует его идентичность и согласовывает протокол коммуникации.

Для большинства self-hosted конфигураций сегодня достаточно MCP. Добавляйте A2A, когда у вас несколько специализированных агентов, которым нужно взаимодействовать. ANP пока бесполезен в продакшене, но станет актуален, когда агентные экосистемы выйдут за организационные границы.

Какой протокол выбрать?

Начните с простейшего протокола, решающего вашу задачу. Добавляйте уровни только при столкновении с ограничениями.

Руководство по выбору:

Нужен ли вашему агенту доступ к инструментам, базам данных или API? Да → Реализуйте MCP. Постройте или установите MCP-серверы для своих источников данных. Это покрывает 80% потребностей интеграции агентов.
Есть ли у вас несколько агентов, которым нужно делегировать задачи друг другу? Да → Добавьте A2A. Опубликуйте Agent Card для каждого агента. Используйте A2A для делегирования задач и стриминга результатов. Нет → A2A не нужен. Если один агент вызывает API через MCP — этого достаточно.
Нужно ли вашим агентам находить неизвестных агентов за пределами организации? Да → Оцените ANP, когда появятся продакшен-SDK. Сейчас это решается ручным реестром или общим каталогом A2A-агентов. Нет → Пропустите ANP.

Типичные паттерны:

Конфигурация	Нужные протоколы
Один агент + инструменты (большинство проектов)	Только MCP
Несколько специализированных агентов на одном сервере	MCP + A2A
Межорганизационное взаимодействие	MCP + A2A + ANP (когда созреет)
Маркетплейс агентов / открытое обнаружение	A2A + ANP

Если вы только начинаете с ИИ-агентами на VPS, начните с MCP. Подключите одного агента к одному инструменту. Заставьте работать. Потом масштабируйте архитектуру по мере роста потребностей.

Какие риски безопасности у каждого протокола?

Каждый протокол открывает свою поверхность атаки. Если вы хостите агентов самостоятельно, вот угрозы, которые важны.

Протокол	Угроза	Последствие	Митигация
MCP	Server-Side Request Forgery (SSRF)	Вредоносный промпт заставляет агента вызвать MCP-инструмент, который делает запросы к внутренним сервисам (metadata-эндпоинты, базы данных, админ-панели).	Запускайте MCP-серверы в изолированных сетевых пространствах. Ограничьте исходящие соединения правилами файрвола. Валидируйте входные данные инструментов на стороне сервера.
MCP	Ненадёжные описания инструментов	Аннотации MCP-инструментов (описания, схемы параметров) приходят от сервера. Скомпрометированный сервер может лгать о функциях инструмента для манипуляции LLM.	Подключайте только те MCP-серверы, которые вы контролируете или которым доверяете. Проверяйте описания. Спецификация MCP явно помечает аннотации инструментов как ненадёжные.
A2A	Подмена агента	Без подписанных Agent Card атакующий может опубликовать поддельную Agent Card по известному URL и перехватить задачи, предназначенные легитимному агенту.	Используйте цифровую подпись Agent Card в A2A (добавлена в v0.3). Проверяйте подписи перед отправкой задач. Закрепляйте эндпоинты известных агентов.
A2A	Утечка данных задач	Задачи могут содержать чувствительные данные (код, учётные данные, бизнес-логику). Если удалённый агент скомпрометирован, эти данные утекают.	Шифруйте чувствительные данные задач на прикладном уровне. Используйте mutual TLS между агентами. Минимизируйте данные в задачах.
ANP	Начальное установление доверия DID	Метод `did:wba` опирается на DID-документы, размещённые по HTTPS. Если домен скомпрометирован, все идентичности агентов на этом домене скомпрометированы.	Используйте отдельные домены для идентификации агентов. Мониторьте изменения DID-документов. Реализуйте пиннинг DID-документов для известных агентов.
ANP	Злоупотребление мета-протоколом	Слой согласования может быть использован, чтобы заставить агента использовать небезопасный или вредоносный протокол коммуникации.	Ограничьте согласование мета-протокола белым списком известных протоколов. Логируйте и аудируйте все согласования протоколов.

Полное руководство по защите сервера с агентами — в .

Куда движется управление?

И MCP, и A2A находятся под Agentic AI Foundation (AAIF), входящей в Linux Foundation. AAIF создана в декабре 2025 года тремя со-основателями: Anthropic, OpenAI и Block. Google, Microsoft, AWS, Bloomberg и Cloudflare присоединились как платиновые участники. Ни один вендор не контролирует направление развития протоколов единолично.

AAIF также хостит goose (опенсорсный агентный фреймворк Block) и AGENTS.md (стандарт OpenAI для предоставления ИИ-агентам проектных инструкций).

ANP управляется независимо через W3C Community Group. Он не входит в AAIF. Присоединится ли ANP к AAIF или останется независимым — повлияет на его траекторию внедрения.

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