Если вы сейчас собираете AI-агентов для своего продукта, внутренней автоматизации или стартапа, то очень быстро выясняется неприятная вещь: главная боль обычно не в самой модели
Модель может писать, рассуждать, анализировать, делать выводы и выполнять инструкции. Но как только агенту нужно сделать что-то полезное в реальной системе, начинаются вопросы.
Как агенту безопасно сходить в CRM, базу данных, GitHub, Notion, Google Drive, внутренний API или поиск по документам?
Как нескольким агентам работать вместе, передавать задачи, получать промежуточные результаты, уточнять детали и не превращать процесс в клубок промптов, вебхуков и временных решений?
Именно здесь появляются два важных протокола: MCP и A2A
MCP, Model Context Protocol, отвечает за интеграцию модели или агента с инструментами. Проще говоря, это слой агент - инструмент
A2A, Agent-to-Agent, отвечает за координацию между агентами. Это слой агент - агент.
Если у вас один простой AI-помощник, который просто отвечает в чате, можно долго не думать об этих протоколах. Но если вы строите мультиагентную систему, где один агент исследует, второй анализирует, третий пишет, четвёртый проверяет, а пятый отправляет результат в продукт, без нормальной архитектуры всё быстро превращается в технический долг.
Разберёмся, какую проблему решают MCP и A2A, чем они отличаются, как работают вместе и как подойти к внедрению, если вы строите не игрушечную демку, а систему, которую потом придётся поддерживать.
Проблема, которую они решают
ИИ-агенты становятся по-настоящему полезными не тогда, когда красиво отвечают в чате
Они становятся полезными, когда могут действовать:
делать запросы к базе данных;
вызывать API;
читать документы;
искать информацию;
создавать задачи;
собирать отчёты;
проверять статусы;
делегировать подзадачи другим агентам;
возвращать результат в понятном формате
Пока агент просто рассуждает, это ещё не полноценная бизнес-система. Это умная оболочка вокруг модели.
Бизнес-система начинается там, где агент получает доступ к инструментам и начинает выполнять действия в реальной среде
До появления MCP и A2A каждая команда решала эти задачи по-своему:
схемы инструментов описывались по-разному у разных моделей и фреймворков;
не было единого способа сказать агенту, какие инструменты ему доступны;
не было нормального стандарта для обнаружения других агентов;
не было единого формата передачи задач между агентами;
смена модели часто означала переписывание интеграций;
отладка превращалась в ручной разбор цепочки “кто что вызвал и почему всё сломалось”.
Для соло-предпринимателя или маленькой команды это особенно болезненно. На старте всё выглядит быстро: добавили пару промптов, связали через API, подключили таблицу, сделали Telegram-бота. Но потом появляется вторая модель, третий инструмент, пятый сценарий, десятая автоматизация - и система начинает жить своей жизнью.
MCP закрывает первый уровень проблемы - интеграцию инструментов
A2A закрывает второй уровень - координацию агентов
Если сказать совсем по-практически: MCP помогает агенту пользоваться внешними возможностями, а A2A помогает нескольким агентам работать как команда.
MCP( Model Context Protocol) - это стандартный способ подключать AI-модель или AI-агента к внешним инструментам
Представьте, что вы делаете AI-помощника для своего бизнеса. Он должен уметь:
найти клиента в CRM;
достать историю заказов;
проверить оплату;
посмотреть заявку в базе;
создать черновик ответа;
собрать короткий отчёт
Без MCP вы будете писать отдельную кастомную интеграцию под каждый инструмент и под каждую среду. Потом появится новая модель или новый агентный фреймворк - и часть работы придётся переделывать.
MCP предлагает другой подход: инструмент описывается один раз в стандартном формате, а агент может его обнаружить и вызвать предсказуемым образом.
MCP определяет:
универсальную схему описания инструментов: имя, описание, входные данные, выходные данные;
стандартный транспорт, например stdio или HTTP + Server-Sent Events;
механизм обнаружения во время выполнения, чтобы модель могла динамически находить доступные инструменты и вызывать их.
Если объяснять на бытовом примере, MCP - это как меню для AI-агента.
Плохо: “Агент, догадайся сам, какие у нас есть инструменты и как ими пользоваться”.
Хорошо: “Вот список инструментов, вот что каждый делает, вот какие параметры принимает, вот какой результат возвращает”.
Для стартапа это означает важную вещь: вы меньше зависите от конкретной модели и конкретной реализации. Интеграции становятся не набором разрозненных костылей, а отдельным слоем архитектуры
Как MCP работает на практике
MCP-сервер - это процесс, который предоставляет список инструментов.
Модель или агент подключается к этому серверу, запрашивает список доступных инструментов и вызывает нужный инструмент по имени, передавая типизированные входные данные.
Например, у вас есть CRM, и агенту нужно получать данные о клиенте. Вы можете поднять MCP-сервер, который предоставляет инструмент query_crm
# Упрощённый пример MCP-сервера (Python с fastmcp)
from fastmcp import FastMCP
mcp = FastMCP("Database Server")
@mcp.tool()
def query_crm(customer_id: str) -> dict:
"""Получить запись о клиенте из CRM"""
return crm_client.get(customer_id)
mcp.run()
После этого любая MCP-совместимая модель может использовать инструмент query_crm без отдельной интеграции под каждую модель.
Именно здесь появляется практическая польза. Вы не зашиваете доступ к CRM внутрь одного конкретного агента. Вы выносите этот доступ в понятный слой инструментов.
Сегодня агент использует Claude. Завтра вы захотели подключить другую модель. Послезавтра вы добавили ещё одного агента, которому тоже нужен доступ к CRM. Если инструмент оформлен через MCP, его проще переиспользовать.
Для маленькой команды это экономит самое дорогое - время на переписывание интеграций
MCP начали поддерживать крупные игроки и инструменты вокруг AI-разработки
В экосистеме уже есть:
нативная поддержка MCP в Claude;
поддержка MCP у OpenAI;
движение в сторону поддержки со стороны Google Gemini;
публичные MCP-серверы для GitHub, Stripe, Notion, Slack и других сервисов.
Для предпринимателя это сигнал: MCP стоит воспринимать не как модную аббревиатуру, а как слой, на который можно ориентироваться при проектировании AI-интеграций.
Конечно, это не значит, что нужно срочно переписывать всё подряд. Но если вы с нуля подключаете агента к инструментам, базам, API или внутренним сервисам, имеет смысл сразу подумать, можно ли оформить эту интеграцию как MCP-сервер.
Потому что через несколько месяцев у вас может появиться не один агент, а пять. И тогда хорошо оформленный слой инструментов сэкономит намного больше времени, чем кажется на старте
A2A протокол: стандартизация координации между агентами
Если MCP отвечает за инструменты, то A2A отвечает за взаимодействие агентов между собой
A2A, Agent-to-Agent, решает другой класс задач: как агентам находить друг друга, понимать возможности друг друга, передавать задачи, возвращать результаты и вести многошаговую работу.
Это становится важно, когда вы переходите от одного AI-помощника к мультиагентной системе.
Например, у вас есть процесс подготовки аналитической статьи.
Один агент собирает источники.
Второй агент анализирует данные.
Третий агент выделяет инсайты.
Четвёртый агент пишет черновик.
Пятый агент редактирует стиль.
Шестой агент проверяет факты и структуру.
Без стандарта координации вы начинаете склеивать всё вручную: промпты, JSON, вебхуки, внутренние соглашения, временные статусы, кастомные обработчики. На демке это терпимо. В рабочей системе - быстро становится больно.
A2A предлагает более формальный подход.
Он определяет:
Agent Cards - карточки агентов, то есть JSON-дескрипторы, доступные по адресу вроде /.well-known/agent.json, где описано, что умеет агент;
структурированные сообщения задач;
явное отслеживание состояния задачи;
потоковые результаты для долгих операций;
многоходовое взаимодействие, когда агент может задавать уточняющие вопросы в процессе выполнения.
Если MCP можно представить как меню инструментов, то A2A можно представить как внутренний каталог специалистов.
Оркестратор видит: вот агент-исследователь, он умеет искать и синтезировать информацию. Вот агент-редактор, он умеет приводить текст к стилю. Вот агент-аналитик, он умеет сравнивать данные и находить закономерности.
Дальше система может не просто “вызвать промпт”, а осознанно передать задачу нужному агенту.
Как A2A работает на практике
У агента может быть карточка с описанием его возможностей.
Например:
{
"name": "Research Agent",
"description": "Searches and synthesizes information from web sources",
"url": "https://agents.example.com/research",
"capabilities": {
"streaming": true
},
"skills": [
{
"id": "web-research",
"name": "Web Research",
"inputModes": ["text"],
"outputModes": ["text", "file"]
}
]
}
Что здесь важно?
Агент описывает, кто он, где находится, что умеет, какие входные данные принимает и какие результаты может вернуть.
Оркестрирующий агент может обнаружить такую карточку, понять возможности агента, отправить ему задачу и получить структурированный результат.
Для бизнес-сценариев это принципиально важно.
Вы не просто запускаете “ещё один промпт”. Вы обращаетесь к агенту как к отдельному участнику системы с понятной ролью, интерфейсом и ожидаемым результатом.
Это особенно полезно, когда задачи долгие или многошаговые. Например, агенту нужно не просто ответить, а собрать данные, обработать их, вернуть промежуточный прогресс, задать уточняющий вопрос, а потом отдать итоговый файл.
Как MCP и A2A сочетаются друг с другом
MCP и A2A не конкурируют. Это разные уровни одной архитектуры.
MCP - про инструменты.
A2A - про координацию агентов.
Можно запомнить так:
если агенту нужно сходить в базу, API, CRM, файловое хранилище, браузер, поиск или другой инструмент - это зона MCP;
если агенту нужно передать задачу другому агенту, получить промежуточный результат, дождаться выполнения или встроиться в цепочку работы - это зона A2A.
Пример: Пользователь просит систему подготовить обзор конкурентов. Сначала агент-оркестратор получает задачу. Он понимает, что нужна исследовательская работа, и через A2A передаёт задачу агенту-исследователю. Агент-исследователь, чтобы выполнить задачу, использует MCP-инструменты: веб-поиск, парсер страниц, базу заметок, инструмент сохранения источников. Потом исследователь возвращает результаты оркестратору через A2A
Оркестратор передаёт данные агенту-аналитику
Аналитик может снова использовать MCP, например, чтобы достать прошлые исследования или сравнить данные в таблице.
Затем результат передаётся агенту-редактору, который собирает финальный текст.
Вся схема выглядит так:
пользователь ставит задачу;
оркестратор распределяет работу через A2A;
отдельные агенты используют инструменты через MCP;
результаты возвращаются назад;
система собирает финальный ответ.
Вот это уже похоже не на чат-бота, а на рабочую мультиагентную систему.
Модель в этой схеме остаётся интеллектом. А MCP и A2A становятся инфраструктурой: связями, инструментами, правилами передачи задач и способом не утонуть в хаосе.
Права доступа: момент, который нельзя откладывать
В мультиагентных системах легко допустить опасную ошибку: дать агентам слишком много прав
Например, оркестратор получил задачу от пользователя и имеет доступ к нескольким системам. Но если он передаёт часть работы агенту-редактору, это не значит, что редактору автоматически нужны все права оркестратора
Редактору может быть достаточно доступа к черновику текста. Агенту-исследователю может быть достаточно доступа к поиску и базе знаний. Агенту-публикатору можно дать право создать черновик, но не публиковать без подтверждения
Лучше сразу мыслить через минимальный scope:
можно читать документы;
можно искать по конкретной базе;
можно создать черновик;
нельзя удалять данные;
нельзя менять статус сделки;
нельзя отправлять письмо клиенту без подтверждения;
нельзя публиковать материал без финальной проверки.
Это особенно важно, потому что ошибки в мультиагентной системе могут распространяться цепочкой
Один агент неправильно понял задачу.
Второй вызвал не тот инструмент.
Третий сделал неверный вывод.
Четвёртый отправил результат дальше.
Пятый что-то опубликовал или изменил в системе.
И потом вы пытаетесь понять, где именно всё пошло не так.
Поэтому права, логи и трассировка - это не “лишняя сложность”. Это базовая страховка, если агенты работают не в песочнице, а с реальными данными и процессами
Архитектурные последствия
Если вы создаёте интеграции инструментов, стоит сразу думать в сторону MCP-серверов
Это не значит, что нужно переписывать весь продукт. Но если вы подключаете новый инструмент, базу, API или внутренний сервис к AI-агенту, лучше сразу спросить себя: можно ли оформить это как отдельный MCP-слой?
Такой подход даёт несколько преимуществ
Во-первых, инструмент становится переиспользуемым
Во-вторых, вы меньше зависите от конкретной модели
В-третьих, вам проще подключать новых агентов
В-четвёртых, интеграции не размазываются по промптам, обработчикам и случайным скриптам
Если вы строите многоагентные рабочие процессы, проектируйте с учётом A2A с самого начала.
Даже если в первой версии у вас всего два агента, полезно сразу понимать:
какие роли есть в системе;
кто кому может передавать задачи;
какие статусы у задачи;
какой формат результата считается нормальным;
где хранится трассировка;
что делать, если один агент не справился.
Команды, которые рассчитывают только на одну модель или одну проприетарную среду выполнения, часто быстро накапливают технический долг. Сначала это незаметно, потому что MVP работает. Потом появляется необходимость масштабировать систему, менять модель, добавлять инструменты, подключать сторонних агентов - и архитектура начинает сопротивляться.
Если вы создаёте агентную платформу, имеет смысл публиковать Agent Cards по стандартному эндпоинту. Это делает вашу систему более компонуемой: другим агентам и платформам проще понять, что ваш агент умеет и как с ним взаимодействовать.
Проще говоря: MCP и A2A помогают строить AI-систему не как закрытую коробку, а как набор понятных, заменяемых и расширяемых компонентов.
Нерешённые проблемы
Важно не воспринимать MCP и A2A как магическую таблетку. Они решают важную часть хаоса, но не закрывают все вопросы. Остаются как минимум две большие проблемы
Первая - авторизация через границы агентов.
Если агент A делегирует задачу агенту B, чьи права применяются? Права пользователя? Права агента A? Права агента B? Отдельный временный scope под конкретную задачу?
Это не теоретический вопрос. Если агенты работают с CRM, платежами, документами, публикациями или внутренними данными, ошибка в правах может привести к реальному ущербу
Вторая проблема - отладка многоагентных цепочек
Если у вас один агент и один инструмент, отладка ещё понятна. Если у вас пять агентов, десять инструментов и несколько промежуточных шагов, появляется много точек отказа. Нужно понимать:
кто получил задачу;
какой агент выбрал следующий шаг;
какой инструмент был вызван;
какие данные пришли на вход;
какой результат вернулся;
где появилась ошибка;
почему система выбрала именно такой маршрут
Инструменты наблюдаемости для мультиагентных систем всё ещё развиваются. Поэтому при внедрении MCP и A2A нельзя забывать о логировании, трассировке и понятных статусах задач.
Иначе система будет выглядеть умной только на презентации. В реальной работе она будет раздражать, потому что никто не сможет быстро понять, почему результат оказался неправильным.
MCP нужен, чтобы агент мог нормально пользоваться инструментами.
A2A нужен, чтобы агенты могли нормально работать друг с другом
Вместе они помогают построить систему, где AI-агенты не просто генерируют текст, а выполняют задачи, обмениваются результатами, используют инструменты и остаются управляемыми.
Если вы делаете маленький эксперимент, можно обойтись простыми связками.
Но если вы строите продукт, внутреннюю автоматизацию или мультиагентный пайплайн, лучше сразу понимать, где у вас инструменты, где агенты, где права, где логи и где потенциальная точка отказа.
Иначе мультиагентная система очень быстро станет не преимуществом, а новым источником хаоса