Всем привет! Меня зовут Александр, я COO в SaaS-платформе аналитики данных. Последний год активно изучаю внедрение AI-решений в кросс-функциональные процессы. Делюсь материалами, которые помогают:
Продуктовым менеджерам — интегрировать AI без перегрузки команд;
Разработчикам — выбирать инструменты под конкретные бизнес-задачи;
Специалистам по данным — избегать ошибок в production-развертывании.
У себя в телеграм-канале делюсь сжатыми и структурированными саммери статей.
Сегодняшний перевод — MCP vs. A2A: Friends or Foes?
Ниже подробное сравнение двух ключевых AI-протоколов: Model Context Protocol (MCP) от Anthropic и Agent2Agent (A2A) от Google, определяющих будущее коммуникации в агентных системах.
Ключевые инсайты:
MCP превосходно подходит для подключения LLM к источникам данных и инструментам, но имеет ограничения в области межагентного взаимодействия
A2A обеспечивает критически важные функции безопасности, управления задачами и совместной работы, отсутствующие в MCP
Компании, вероятно, будут все чаще предоставлять функциональность через агентов, а не через MCP-серверы, что может снизить значимость MCP
Успех MCP (Model Context Protocol) от Anthropic явно вдохновил других игроков в индустрии ИИ присоединиться к гонке, чтобы стать теми, кто определит открытые протоколы, которые будут использоваться в интеграции агентных систем.
На прошлой неделе Google публично представила свой открытый протокол под названием A2A (Agent2Agent), целью которого является нормализация способов реализации коммуникации между мульти-агентными системами. Многие говорят, что два протокола скорее конкурируют, чем дополняют друг друга.
Официальная позиция Google заключается в том, что A2A дополняет MCP. Это разумное утверждение. Однако, могут ли существовать скрытые долгосрочные конкурентные цели? Скоро ли мы увидим начало войн протоколов?
Меня несколько раз спрашивали, как я считаю, могут ли эти два протокола стать конкурентами в будущем. Читайте до конца, чтобы узнать мои мысли об этом.
В этой статье:
Что такое A2A?
Что такое MCP?
Как A2A дополняет MCP и наоборот?
Может ли A2A поглотить MCP в долгосрочной перспективе?
A2A объяснение.
Давайте сначала определим A2A, поскольку это новичок на рынке (про MCP уже много говорили).
Проблема.
Становится очевидным, что агентные системы будущего будут мульти-агентными. Более того, агенты будут взаимодействовать друг с другом удаленно, и каждый из них потенциально может быть реализован с использованием различных фреймворков агентов (например, LangGraph, CrewAI, Agent Development Kit и т.д.).
С этим связано несколько проблем:
Передача и обмен состоянием системы между системами, реализованными в разных фреймворках, не поддерживается.
Передача состояния системы между удаленными агентами также невозможна.
Разрозненные агенты не делятся инструментами, контекстом и памятью (включая состояние системы).
Решение.
A2A — это открытый протокол, который предоставляет стандартный способ для агентов сотрудничать друг с другом, независимо от базового фреймворка или вендора.
Согласно официальной документации Google:
Протокол A2A обеспечивает коммуникацию между "клиентским" и "удаленным" агентом.
Простыми словами, "клиентский" агент создает задачи и передает их "удаленному" агенту, ожидая, что будет выполнена некоторая работа или возвращены данные.
Основные возможности A2A, обеспечивающие это:
Обнаружение возможностей - все агенты, реализующие A2A, предоставляют каталог своих возможностей через "Карточку агента". Это помогает другим агентам обнаруживать потенциально полезные функции, реализованные данным агентом.
Управление задачами - коммуникационный протокол, который обеспечивает выполнение как краткосрочных, так и долгосрочных задач. Он помогает взаимодействующим агентам оставаться синхронизированными до тех пор, пока запрошенная задача не будет завершена и ответ не будет возвращен. Это важно, потому что некоторым агентам может потребоваться длительное время для выполнения своей работы, и нет стандартов, как ожидать этого.
Сотрудничество - агенты могут отправлять друг другу сообщения для передачи контекста, ответов, артефактов или инструкций пользователя.
Согласование пользовательского опыта - это довольно интересно. Оно позволяет согласовать формат, в котором данные должны быть возвращены, чтобы соответствовать ожиданиям пользовательского интерфейса (например, изображение, видео, текст и т.д.).
Обнаружение агентов, предоставляемых через A2A, является важной темой. Google предлагает унифицированное место для хранения "Карточек агентов" организаций. Например:
https://<DOMAIN>/<agreed-path>/agent.json
Это неудивительно, поскольку Google тогда был бы в наилучшем положении для индексации всех доступных агентов по всему миру, потенциально создавая глобальный каталог агентов, аналогичный текущему поисковому индексу.
Было много разговоров о безголовых браузерах и о том, как будет реализован будущий интернет агентов. Вышеуказанный способ — один из возможных путей, с использованием уже существующих технологий.
Мне нравится, как A2A подчеркивает необходимость не изобретать колесо заново и строится на существующих стандартах:
Протокол построен на основе существующих популярных стандартов, включая HTTP, SSE, JSON-RPC, что означает, что его легче интегрировать с существующими ИТ-стеками, которые бизнес уже использует ежедневно.
Безопасен по умолчанию - A2A разработан для поддержки корпоративной аутентификации и авторизации, с паритетом со схемами аутентификации OpenAPI.
MCP объяснение.
MCP (Model Context Protocol), как определено Anthropic, это:
Открытый протокол, который стандартизирует, как приложения предоставляют контекст LLM.
Если быть более точным, он пытается стандартизировать протокол того, как приложения на основе LLM интегрируются с другими средами.
В агентных системах контекст может быть предоставлен различными способами:
Внешние данные - это часть долговременной памяти.
Инструменты - способность системы взаимодействовать с окружающей средой.
Динамические промпты - которые могут быть внедрены как часть системного промпта.
…
Зачем нужна стандартизация?
Текущий процесс разработки агентных приложений хаотичен:
Существует много фреймворков для агентов с небольшими различиями. Хотя развитие экосистемы обнадеживает, эти небольшие различия редко добавляют достаточную ценность, но потенциально значительно меняют способ написания кода.
Интеграции с внешними источниками данных обычно реализуются специально для каждого случая и с использованием различных протоколов даже внутри организаций. Это, очевидно, верно и для разных компаний.
Инструменты определяются в репозиториях кода немного по-разному. То, как вы подключаете инструменты к расширенным LLM, также отличается.
Цель состоит в том, чтобы улучшить скорость, с которой мы можем внедрять инновации в агентные приложения, насколько хорошо мы можем их защитить и насколько легко можно привнести соответствующие данные в контекст.
Ниже представлена высокоуровневая архитектура MCP.
MCP Host - программы, использующие LLM в качестве ядра, которые хотят получать доступ к данным через MCP.
MCP Client - клиенты, которые поддерживают соединения 1:1 с серверами.
MCP Server - легковесные программы, каждая из которых предоставляет определенные возможности через стандартизированный протокол Model Context Protocol.
Local Data Sources - файлы вашего компьютера, базы данных и сервисы, к которым серверы MCP могут безопасно обращаться.
Remote Data Sources - внешние системы, доступные через интернет (например, через API), к которым могут подключаться серверы MCP.
Разделение ответственности по контролю через MCP.
Серверы MCP предоставляют три основных элемента, которые целенаправленно созданы так, чтобы помочь реализовать конкретное разделение контроля.
Prompts (Промпты) разработаны для управления пользователем.
Программист сервера может предоставлять определенные промпты (подходящие для взаимодействия с данными, предоставляемыми сервером), которые могут быть внедрены в приложение, использующее LLM, и предоставлены пользователю данного приложения.
Resources (Ресурсы) разработаны для управления приложением.
Ресурсы - это любой вид данных (текст или бинарные), которые могут использоваться приложением, построенным на LLM. Программист приложения (обычно AI Engineer) несет ответственность за кодификацию того, как эта информация должна использоваться приложением. Обычно в этом нет автоматизации, и LLM не участвует в этом выборе.
Tools (Инструменты) разработаны для управления моделью.
Если мы предоставляем агентность нашему приложению в том, как оно должно взаимодействовать с окружающей средой, мы используем инструменты для этого. Сервер MCP предоставляет конечную точку, которая может перечислить все доступные инструменты с их описаниями и необходимыми аргументами, приложение может передать этот список LLM, чтобы он мог решить, какие инструменты необходимы для задачи и как они должны быть вызваны.
A2A + MCP.
Согласно официальной позиции Google:
Агентным приложениям нужны и A2A, и MCP. Мы рекомендуем MCP для инструментов и A2A для агентов.
Что это означает? Давайте рассмотрим архитектуру агентной системы, включающей нескольких агентов.
Движущиеся части в MCP:
MCP Host - Здесь становится интересно, при комбинировании с A2A, MCP Host это Агент.
MCP Client.
MCP Server.
Local Data Sources.
Remote Data Sources.
A2A:
Агенты (MCP Hosts) будут реализовывать и взаимодействовать через протокол A2A, который обеспечивает:
Безопасное сотрудничество - MCP не имеет аутентификации.
Управление задачами и состоянием.
Согласование пользовательского опыта.
Обнаружение возможностей - аналогично инструментам MCP.
Предложение заключается в том, что MCP используется в основном для интеграции устаревших систем данных (MCP Resources) и API (MCP Tools) с приложениями на основе LLM, в то время как A2A заботится о межагентной коммуникации.
Я действительно верю, что по мере продвижения вперед станет более распространенным предоставлять свои платформы как агенты, а не серверы MCP, поэтому важность MCP в пункте 5. будет постепенно уменьшаться.
Обнаружение агентов через MCP.
Google заходит так далеко, что предлагает предоставлять агентов A2A через ресурсы сервера MCP.
Каждый агент в сети сможет обнаруживать других доступных агентов, подключаясь к выделенному серверу MCP через клиент MCP и просматривая каталог ресурсов. Предложение заключается в том, чтобы предоставлять карточки агентов через эти ресурсы MCP.
После обнаружения агенты будут продолжать общение между собой, используя протокол A2A.
С учетом сказанного, если мы движемся к обнаружению агентов через глобальный индекс, важность MCP здесь также уменьшится или даже может исчезнуть.
Может ли A2A поглотить MCP в долгосрочной перспективе?
Итак, рискует ли MCP потерять актуальность?
Уже довольно давно существовала явная потребность в среде, которая соединяла бы между собой рои агентов, выпущенных в мир, а также с другими устаревшими системами. Были разговоры о безголовых браузерах, но похоже, что эти открытые коммуникационные протоколы действительно будут путем вперед. Я считаю, что именно отсюда исходили разговоры о том, что MCP - это новая форма http.
Следующие мысли основаны на некоторых предположениях:
Открытые коммуникационные протоколы будут интегрировать агентов нового мира.
Есть преимущество в том, чтобы стоять за ведущим протоколом.
Оба протокола будут продолжать развиваться и потенциально расширять границы ответственности.
Сходства в MCP и A2A.
Существуют некоторые явные сходства в обоих протоколах, и пользователь может выбрать, как моделировать свои агентные приложения и предоставлять их миру различными способами.
Поскольку популярность MCP стремительно растет, компании все чаще отправляют серверы MCP как часть своих предложений, чтобы разработчики могли беспрепятственно интегрировать контекст из этих платформ в свои приложения на основе LLM.
Однако MCP сталкивается с некоторыми проблемами при внедрении.
Одним из основных недостатков протокола является отсутствие безопасности и аутентификации. Вам необходимо настраивать базовую реализацию, чтобы безопасно предоставлять удаленный сервер MCP.
Инструменты могут описывать что угодно, включая других агентов. К сожалению, MCP не реализует никаких примитивов, которые облегчают правильную коммуникацию между агентами через инструменты (обмен состоянием/контекстом, поддержка долгосрочных задач и т.д.).
Именно здесь Google мог найти лазейку, чтобы вступить в войны протоколов с A2A, исправляя вышеуказанное.
Я не могу избавиться от ощущения, что у Anthropic были более масштабные планы на MCP, чем его текущее состояние. В том числе взаимосвязь нескольких агентов между собой. Теперь дверь для расширения в эту область может быть закрыта из-за появления A2A.
Что действительно важно в долгосрочной перспективе?
Если мы думаем о долгосрочной перспективе, как будет моделироваться мир агентов?
Компании предоставляют свои данные для использования агентами.
Компании предоставляют агентов, которые могут возвращать данные или выполнять действия.
Компании ЯВЛЯЮТСЯ агентами, с которыми могут взаимодействовать другие агенты.
Я делаю ставку на движение к последнему варианту.
Если предположение верно, реальная сила находится в руках протокола, который контролирует протокол удаленной межагентной коммуникации.
Даже в краткосрочной перспективе, предполагая, что второй пункт будет стандартным вариантом для вновь появляющихся компаний, если кто-то решит предоставлять свои данные через агента, A2A является явным победителем.
Учитывая вышесказанное, останется ли MCP протоколом для соединения новых видов приложений с устаревшими системами и потеряет ли актуальность, когда агенты возьмут верх? Кто знает, давайте подождем и увидим.
Но если это случится, догадайтесь, на какого игрока в индустрии я делаю ставку :)
Заключение.
Мы живем в захватывающие времена. Способ, которым новый тип агентных приложений будет соединяться в масштабе, определяется на наших глазах.
A2A может быть новичком, но он быстро становится лидером в межагентной коммуникации. В то время как MCP внес структуру в то, как LLM интегрируют контекст, A2A решает то, чего не хватает MCP: безопасность, управление состоянием и сотрудничество в реальном времени. Поглотит ли A2A протокол MCP? Кто знает.
Хотя официальная позиция заключается в том, что два протокола решают совершенно разные проблемы, существуют потенциальные пересечения, и можно ожидать, что протоколы также будут расширены по объему.
Если будущее агентно, и компании начнут предоставлять агентов, а не просто инструменты или данные, то протокол, который обеспечивает беспрепятственное взаимодействие между агентами, может стать победителем. Сейчас кажется, что A2A может выбирать правильные ходы.