MCP и ACP: протоколы для AI-агентов — что это, чем отличаются и зачем бизнесу в 2026 году

Введение

К 2026 году термин «AI-агент» перестал быть маркетинговым — это конкретная архитектурная единица, которая вызывает инструменты, читает данные и общается с другими агентами. Но как заставить агента вызвать функцию CRM, прочитать файл из S3, а потом передать результат коллеге, написанному на другом фреймворке? Именно для этого появились протоколы MCP и ACP.

В этой статье разберём:

• что такое Model Context Protocol (MCP) от Anthropic и зачем он стал стандартом «агент ↔ инструменты»;

• что такое Agent Communication Protocol (ACP) от IBM Research и почему он перестал существовать как отдельный стандарт;

• чем MCP отличается от ACP, A2A и ANP — и почему сравнивать их как конкурентов некорректно;

• что всё это значит для команд, которые строят агентные системы в продакшне.

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

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

Происхождение

Model Context Protocol был анонсирован Anthropic в ноябре 2024 года как открытый стандарт подключения LLM к внешним источникам данных и инструментам. К моменту годовщины проекта — 25 ноября 2025 — вышла спецификация версии 2025-11-25, в экосистеме работало более 10 000 MCP-серверов, а поддержку протокола добавили OpenAI, Google DeepMind, Microsoft, блокчейн-проекты и большинство крупных облачных провайдеров.

MCP иногда называют «USB-C для AI»: одна розетка — и любая модель получает доступ к любым инструментам и данным, если для них написан сервер.

Архитектура: клиент, сервер, хост

MCP строится на классической клиент-серверной модели с тремя ролями:

Связь — JSON-RPC 2.0 поверх двух транспортов:

• stdio — для локальных серверов, запускаемых как подпроцесс;

• Streamable HTTP + Server-Sent Events — для удалённых серверов с поддержкой сессий (Mcp-Session-Id) и асинхронных задач.

Три базовых примитива

MCP оперирует тремя типами «контента», которые сервер может выставить клиенту:

1. Tools (инструменты) — функции, которые LLM может вызвать. Например, create_issue(repo, title, body) для GitHub или sql_query(statement) для базы данных. Модель видит JSON-схему инструмента и решает, когда его вызывать.

2. Resources (ресурсы) — данные, к которым агент может обратиться по URI. Например, file:///docs/contract.pdf или postgres://orders/recent. Ресурсы не вызываются, а читаются.

3. Prompts (шаблоны) — заранее заготовленные промпты с параметрами, которые пользователь или приложение может явно выбрать. Это не «системные инструкции», а управляемая палитра шаблонов.

Спецификация 2025-11-25 добавила четвёртый класс возможностей — асинхронные задачи (long-running tasks): сервер может принять запрос, вернуть taskId, и клиент опрашивает статус. Это снимает классическую боль HTTP-таймаутов для задач, которые длятся минуты и часы.

Авторизация

Свежая спецификация интегрирует OpenID Connect Discovery 1.0 и инкрементальное согласие на scope через заголовок WWW-Authenticate. Это значит, что MCP-серверы теперь могут запрашивать у пользователя ровно те права, которые нужны текущему вызову, а не «всё или ничего» при первом подключении.

Минимальный пример сервера на Python

from mcp.server.fastmcp import FastMCP

mcp = FastMCP("docs-server")

@mcp.tool()
def search_docs(query: str, limit: int = 5) -> list[dict]:
    """Ищет релевантные документы во внутренней базе знаний."""
    return db.search(query, top_k=limit)

@mcp.resource("docs://recent")
def recent_docs() -> list[str]:
    """Возвращает URI последних обновлённых документов."""
    return [f"docs://{d.id}" for d in db.recent(20)]

if __name__ == "__main__":
    mcp.run(transport="stdio")

Этот сервер сразу доступен любому MCP-совместимому клиенту — Claude Desktop, Cursor, собственный агент на LangChain. Никакой интеграции «под каждого клиента» писать не нужно.

Что такое ACP (Agent Communication Protocol)

Происхождение

Agent Communication Protocol разработан IBM Research в марте 2025 года как «общий проводной формат» для общения автономных агентов независимо от фреймворка, языка и среды выполнения. Первой платформой, построенной вокруг ACP, стала BeeAI Platform — открытый проект IBM для исследования интерпретируемости и оркестрации агентов.

В конце марта 2025 проект BeeAI вместе с ACP был передан Linux Foundation. А 29 августа 2025 организация LF AI & Data объявила, что ACP объединяется с протоколом A2A (Agent2Agent, запущенным Google в апреле 2025) в единый стандарт. На сайте проекта сейчас прямо написано: «ACP is now part of A2A under the Linux Foundation».

⚠️ Важно для продакшна в 2026: ACP как самостоятельный протокол прекратил развитие. Если вы только планируете агентную систему — используйте A2A, который наследует идеи ACP (REST-нативность, оффлайн-обнаружение, async-first). Документация ACP остаётся в открытом доступе как исторический референс, но рекомендации и обновления теперь публикуются в репозитории A2A.

Ключевые идеи ACP

Несмотря на слияние, идеи ACP никуда не делись — они легли в основу A2A. Что ACP принёс в индустрию:

• REST-based HTTP вместо JSON-RPC. Для агент-агент общения это дешевле и привычнее фронтенд-бэкенд командам — не нужен специальный SDK, достаточно curl.

• Оффлайн-обнаружение (offline discovery). Агент публикует манифест (Agent Manifest) с описанием своих возможностей — и другие агенты могут найти его без центрального реестра.

• Async-first, sync supported. Длинные задачи — норма, синхронные вызовы — частный случай. В ответе приходит taskId, по которому можно опрашивать статус.

• Структурированные сообщения вместо свободного текста. В ACP есть типизированные message-типы для переговоров о передаче задачи (handoff) — это снижает «галлюцинации парсинга», когда один агент пытается понять свободный текст от другого.

Минимальный пример ACP-стиля (через A2A)

POST /agents/research/agent.json HTTP/1.1
Host: acp-bridge.local
Content-Type: application/json

{
  "jsonrpc": "2.0",
  "id": 1,
  "method": "tasks/send",
  "params": {
    "message": {
      "role": "user",
      "parts": [{"type": "text", "text": "Подготовь анализ рынка за Q3 2025"}]
    }
  }
}

Ответ — асинхронный taskId со статусом working, дальше опрос tasks/get до терминального состояния completed. Семантика и поля практически совпадают с A2A — это и есть результат слияния.

MCP vs ACP vs A2A vs ANP: разбираемся в зоопарке

К 2026 году в индустрии устоялись четыре протокола. Их часто смешивают, но они решают разные задачи:

Главная мысль: эти протоколы не конкурируют, они складываются в стек. Типичная продакшн-система 2026 года выглядит так:

1. Внутри одного агента он использует MCP, чтобы вызвать CRM, БД, поисковик, файловую систему.

2. Когда нужно передать задачу другому агенту — внутри компании или партнёру — используется A2A (он впитал идеи ACP).

3. Если в системе есть требования к децентрализации и открытому обнаружению без центрального реестра — добавляется ANP.

Niklas Heidloff сформулировал это коротко: «MCP определяет, как вызывать инструменты. Протоколы вроде ACP определяют, как вызывать агентов». Граница между «инструментом» и «агентом» постепенно размывается, но на уровне протоколов разделение пока сохраняется.

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

Сценарий 1. Внутренний корпоративный ассистент

Задача: агент в чате должен искать в Confluence, создавать задачи в Jira, читать почту через IMAP, делать выгрузки из 1С.

Решение: только MCP. Под каждый источник пишется MCP-сервер (готовых уже тысячи — от @modelcontextprotocol/server-github до серверов для Notion, Slack, Postgres). Агент подключает их все через единый конфиг, пользователь не видит разницы между «вызовом инструмента» и «получением данных».

Сценарий 2. Мультиагентная система для обработки заявок

Задача: один агент классифицирует заявку, второй ищет релевантные документы, третий готовит ответ, четвёртый проверяет соответствие политикам.

Решение: MCP + A2A. Каждый агент — отдельный сервис со своим набором MCP-инструментов. Между собой они общаются по A2A: «у меня входные данные такие, передаю тебе task с такими-то артефактами, ожидай ответ через taskId».

Сценарий 3. B2B-маркетплейс агентов между компаниями

Задача: компания A хочет, чтобы её агент-аналитик мог вызвать платный API агента-юриста компании B, а агент-юрист — вызвать агента-нотариуса компании C.

Решение: A2A + авторизация на уровне сообщений. A2A поддерживает расширенные сценарии аутентификации, стриминг и кросс-организационные workflow. Здесь MCP вообще не нужен — у каждого агента свои инструменты, наружу они выставляют только своё «агентное» API.

Сценарий 4. Децентрализованная сеть агентов

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

Решение: ANP (Agent Network Protocol). Это нишевая история, но она важна для сценариев, где нет доверия к единому оператору.

Что важно понимать при внедрении

MCP-серверы — это новая поверхность атаки

Каждый MCP-сервер фактически выполняет код, который LLM попросил запустить. Это делает модель угроз принципиально другой, чем у обычного REST API:

• prompt injection через инструменты. Если инструмент возвращает текст, который попадает в контекст модели, атакующий может внедрить инструкции, которые модель воспримет как «от пользователя». Решение — sandboxing, фильтрация возвращаемых значений и минимальные описания инструментов.

• exfiltration через параметры. Атакующий может заставить модель передать чувствительные данные в параметрах безобидного на вид инструмента. Решение — allowlist допустимых значений и audit log всех вызовов.

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

💡 Практический совет: перед добавлением нового MCP-сервера в корпоративный агент — посмотрите его исходники, проверьте, какие ресурсы и инструменты он объявляет, и зафиксируйте версию. Сторонний npm install MCP-сервера без ревью — это как pip install пакета с двумя звездами на PyPI.

Авторизация и аудит

Спецификация MCP 2025-11-25 ввела OpenID Connect Discovery — теперь можно выдавать агенту OAuth-токен с минимальным scope и ротировать его. Это закрывает огромную дыру ранних версий, где сервер либо получал «всё», либо не получал ничего.

Со стороны A2A — тоже зрелая история с bearer-токенами и mTLS для кросс-организационных вызовов. На стыке A2A и корпоративного SSO жить становится сильно проще, чем в 2024 году, когда каждый писал свою авторизацию.

Стоимость инфраструктуры

MCP-серверы по умолчанию долгоживущие: между клиентом и сервером держится сессия, сервер может держать состояние, асинхронные задачи висят минуты и часы. На каждый активный агентский сеанс приходится держать серверный процесс, коннекшен к БД и connection pool. На 100 параллельных агентов это уже ощутимые расходы.

Практический вывод:

• stdio-серверы дёшевы, но запускаются на одной машине с клиентом — не подходят для масштабирования.

• Streamable HTTP-серверы можно шарить между агентами и держать в Kubernetes, но нужен service discovery и health-check.

• Асинхронные задачи (taskId) требуют stateful-сервера или внешнего хранилища статусов (Redis, Postgres).

Наблюдаемость

Стандартных средств трассировки MCP-потока пока мало. На практике работает связка:

• OpenTelemetry для трассировки вызовов инструментов;

• структурированные логи в JSON с sessionId, toolName, latencyMs;

• отдельный дашборд по «отказы по инструментам» — обычно это первое место, где ломается агент в продакшне.

Коротко об эволюции

Хронология ключевых событий:

• Ноябрь 2024 — Anthropic анонсирует MCP.

• Март 2025 — IBM Research запускает ACP вместе с BeeAI Platform.

• Апрель 2025 — Google анонсирует A2A.

• Конец марта 2025 — BeeAI и ACP переданы Linux Foundation.

• 25 ноября 2025 — спецификация MCP 2025-11-25: OIDC Discovery, async-задачи, серверные иконки.

• Конец 2025 — более 10 000 публичных MCP-серверов, поддержка от OpenAI и Google DeepMind.

• 2026 — массовое использование A2A (наследник ACP), MCP как де-факто стандарт доступа к инструментам.

Главный тренд — конвергенция. Через год-два «чистый ACP» как термин, скорее всего, исчезнет из словаря, и инженеры будут выбирать между MCP (инструменты) и A2A (агенты). ANP останется нишевым для децентрализованных сценариев.

Заключение

MCP и ACP — это не «два конкурента», а два слоя одной архитектуры:

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

• ACP исторически отвечал за то, чтобы агенты могли разговаривать друг с другом. В августе 2025 он объединился с A2A — теперь это один стандарт.

Для команды, которая строит агентную систему в 2026 году, практический рецепт такой:

1. Внутри агента — MCP для всех интеграций с данными и инструментами.

2. Между агентами — A2A (бывший ACP) с явной авторизацией и трассировкой.

3. Не пытайтесь покрыть оба сценария одним протоколом — это разные задачи с разными требованиями к безопасности и наблюдаемости.

⚠️ Важно: копировать «пример агента на MCP» из интернета и сразу нести в продакшн — плохая идея. Без аудита MCP-серверов, продуманной авторизации и изоляции вы получаете новую поверхность атаки вместо помощника. Для продакшн-решений стоит привлекать специалистов, которые уже прошли этот путь и знают типичные грабли — от prompt injection через инструменты до утечек токенов через описания ресурсов.

Источники

• Introducing the Model Context Protocol — Anthropic

• MCP specification version 2025-11-25 (one-year anniversary) — Model Context Protocol Blog

• Update on the Next MCP Protocol Release — MCP Blog

• MCP Roadmap — modelcontextprotocol.io

• ACP Joins Forces with A2A — LF AI & Data Foundation

• Agent Communication Protocol — IBM Research

• What is Agent Communication Protocol (ACP)? — IBM Think

• ACP Welcome (now part of A2A)

• MCP vs A2A vs ACP vs ANP — K21 Academy

• MCP, ACP, A2A, Oh my! — WorkOS Guides

• Comparison of Agent Protocols MCP, ACP and A2A — Niklas Heidloff