A2A и MCP: Два дополнительных протокола для развивающейся экосистемы агентов

Увеличение использования агентов ИИ — автономных или полуавтономных программных сущностей, которые выполняют рассуждения и действия от имени пользователей — приводит к появлению нового слоя в архитектуре приложений.

В начале 2025 года появились два отдельных протокола для решения этой задачи — A2A (Agent-to-Agent) и MCP (Model Context Protocol). Простым способом понять их роли является:

A2A: Как агенты взаимодействуют друг с другом

MCP: Как агенты взаимодействуют с инструментами или внешним контекстом

ссылка: https://google.github.io/A2A/#/topics/a2a_and_mcp

Они решают основную проблему построения систем с множественными агентами, множественными LLM и множественными источниками контекста — все из которых должны сотрудничать.

Один из способов взглянуть на это: “MCP обеспечивает вертикальную интеграцию (приложение к модели), в то время как A2A обеспечивает горизонтальную интеграцию (агент к агенту)”.

Независимо от того, являетесь ли вы разработчиком или нет, любой, кто строит ИИ-продукты или агентные системы, должен понимать основную архитектуру — потому что она формирует то, как мы разрабатываем продукты, пользовательские взаимодействия, экосистемы и долгосрочный рост.

Эта статья представляет оба протокола простым, легким для понимания способом и подчеркивает ключевые выводы для разработчиков и создателей ИИ-продуктов.

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

A2A (Agent-to-Agent) — это открытый протокол, разработанный компанией Google и более чем 50 индустриальными партнерами. Его цель — обеспечить взаимодействие между агентами — независимо от того, кто их создал, где они размещены или какую структуру они используют.

Механизм протокола A2A#

A2A использует JSON-RPC 2.0 по HTTP(S) как механизм коммуникации с поддержкой Server-Sent Events (SSE) для потоковой передачи обновлений.

Модели коммуникации A2A#

A2A определяет структурированную модель взаимодействия двух агентов. Один агент берет на себя роль “клиентского” агента, который инициирует запрос или задание, а другой выступает как “удаленный” агент, который получает запрос и пытается его выполнить. Клиентский агент может сначала выполнить обнаружение способностей, чтобы определить, какой агент лучше всего подходит для выполнения данной задачи.

Возникает вопрос, как агенты обнаруживают друг друга. Каждый агент может публиковать Карту Агента (JSON-документ метаданных, часто размещенный по стандартному URL, например, /.well-known/agent.json), описывающую его возможности, навыки, конечные точки API и требования к аутентификации.

Читая Карту Агента, клиентский агент может определить подходящего партнера для выполнения задачи — по сути, это каталог того, что агент знает или может сделать. После выбора целевого агента клиентский агент формирует объект Task, чтобы отправить его.

ссылка: https://google.github.io/A2A/#/

Управление задачами#

Всякое взаимодействие в A2A ориентировано на выполнение задач. Задача — это структурированный объект (определенный схемой протокола), который включает детали запроса и отслеживает его состояние.

В A2A каждый агент выполняет одну из двух ролей:

• Клиентский агент: инициирует задачу
• Удаленный агент: получает и обрабатывает задачу

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

Сотрудничество и согласование контента#

A2A поддерживает больше, чем просто запросы задач — агенты могут обмениваться богатыми, многочастными сообщениями, которые включают текст, JSON, изображения, видео или интерактивный контент. Это позволяет согласованию формата в зависимости от того, что каждый агент может обработать или отобразить.

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

Пример использования#

Вот пример из реального мира, как A2A может использоваться в корпоративном сценарии:

В крупной компании нанимается новый сотрудник. В процесс его адаптации вовлечено множество систем и отделов:

• Отдел кадров должен создать карточку сотрудника и отправить приветственное письмо
• ИТ-отдел должен заказать ноутбук и создать учетные записи
• Административный отдел должен подготовить рабочее место и бейдж доступа

Традиционно эти шаги выполняются вручную или через тесно связанные интеграции между внутренними системами.

Вместо создания пользовательских API для каждой системы, каждый отдел предоставляет своего агента, используя протокол A2A:

Многоагентная система — назовем её OnboardingPro (например, onboarding-agent.company.com) — координирует весь процесс адаптации.

1. Обнаружение: она считывает .well-known/agent.json каждого агента, чтобы понять возможности и аутентификацию.
2. Делегирование задач:
   • Отправляет задачу createEmployee агенту отдела кадров.
   • Отправляет задачи setupEmailAccount и orderHardware IT-агенту.
   • Отправляет assignDesk и generateBadge агенту административного отдела.
3. Потоковые обновления: агенты отсылают прогресс с помощью Server-Sent Events (например, “ноутбук отправлен”, “рабочее место назначено”).
4. Сбор артефактов: окончательные результаты (например, PDF-бейдж, подтверждающие письма, учетные данные) возвращаются как артефакты A2A.
5. Завершение: OnboardingPro уведомляет менеджера по найму, когда адаптация завершена.

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

MCP (Model Context Protocol), разработанный компанией Anthropic, решает другую задачу: как внешние приложения могут предоставлять структурированный контекст и инструменты для агента на основе языковой модели во время выполнения.

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

• Динамически вводить релевантные инструменты, документы, функции API или состояние пользователя в сеанс вывода модели
• Позволять моделям вызывать функции или извлекать документы без жесткой кодировки запроса или логики

Ключевая архитектура MCP#

Чтобы понять MCP, сначала нужно понять общую архитектуру — как все части работают вместе.

MCP Host: “ИИ, с которым вы разговариваете”#

Представьте MCP Host как само приложение ИИ — как Claude Desktop или ваш помощник по программированию.

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

Он стремится подключить инструменты и данные, которые помогают модели дать лучшие ответы.

MCP Client: “Связующий”#

MCP Client — это программное обеспечение, которое соединяет ваш хост ИИ (как Claude) с внешним миром. Оно работает как коммутатор — управляет безопасными, индивидуальными соединениями с различными MCP-серверами. Когда ИИ хочет что-то получить, он проходит через клиент.

Полезно думать об инструментах, таких как ChatGPT, Claude chat или Cursor IDE как о MCP-хостах — они предоставляют интерфейс, с которым вы взаимодействуете. За кулисами они используют MCP клиент для подключения к различным инструментам и источникам данных через MCP-серверы.

ссылка: https://modelcontextprotocol.io/introduction

MCP Server: “Поставщик инструмента”#

MCP Server — это небольшая, специализированная программа, которая предоставляет один конкретный инструмент или возможность, например:

• Поиск файлов на вашем компьютере
• Поиск данных в локальной базе данных
• Вызов внешнего API (например, погоды, финансов, календаря)

Каждый сервер следует MCP-протоколу, так что ИИ может понять, что он может сделать и как его вызвать.

Локальные источники данных: “Ваши собственные файлы и сервисы”#

Некоторые MCP-серверы подключаются к вещам на вашей собственной машине, например:

• Документы и папки
• Проекты кода
• Базы данных или локальные приложения

Это позволяет ИИ искать, извлекать или вычислять что-то без загрузки ваших данных в облако.

Удаленные сервисы: “API и онлайн-инструменты”#

Другие MCP-серверы подключены к интернету — они общаются с:

• API (например, Stripe, Notion, GitHub)
• SaaS-инструментами
• Корпоративными базами данных в облаке

Так что ИИ может, например, сказать: “Позвони на сервер GitHub и извлеки список открытых PR”.

Теперь MCP поддерживает подключение к удаленным MCP-серверам. Это значит, что MCP-клиент может получить более мощные возможности. Теоретически,

С правильным набором MCP-серверов пользователи могут превратить каждый MCP-клиент в “приложение для всего”.

ссылка: https://a16z.com/a-deep-dive-into-mcp-and-the-future-of-ai-tooling/

Как все это работает вместе#

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

1. Вы просите ИИ что-то сложное
2. ИИ (хост) просит клиента о помощи
3. Клиент вызывает подходящий MCP-сервер — возможно, тот, который проверяет файлы или использует API
4. Сервер отправляет обратно данные или выполняет функцию
5. Результат возвращается модели, чтобы помочь завершить задачу

A2A vs MCP — сравнение#

Как они работают вместе#

Вместо того чтобы быть альтернативами, A2A и MCP дополняют друг друга. Во многих системах они будут использоваться вместе.

Пример рабочего процесса#

1. Пользователь подает сложный запрос в интерфейсе корпоративного агента.
2. Оркестрирующий агент использует A2A для делегирования подзадач специализированным агентам (например, аналитика, отдел кадров, финансы).
3. Один из этих агентов использует MCP внутри для вызова функции поиска, извлечения документа или вычисления с использованием модели.
4. Результат возвращается как артефакт через A2A, обеспечивая сквозное сотрудничество агентов с модульным доступом к инструментам.

Эта архитектура разделяет межагентное взаимодействие (A2A) от вызова внутрисистемных возможностей (MCP) — что делает систему проще в компоновке, расширении и защите.

Заключение#

A2A о том, как агенты общаются с другими агентами по сети — безопасно, асинхронно и ориентированно на задачи.

MCP о том, как вводить структурированные возможности в сеанс модели, позволяя LLM рассуждать над инструментами и данными контекстуально.

Совместно они поддерживают компонуемые, многоагентные системы, которые являются одновременно расширяемыми и совместимыми.

Как инфраструктура MCP + A2A может формировать будущее рыночных продуктов агентов#

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

Изменение взаимодействия человека с компьютером#

Яркий пример этого сдвига можно увидеть в рабочих процессах разработчиков и предоставления сервисов. С интеграцией MCP-серверов в IDE и агентов программирования, способы взаимодействия разработчиков с инструментами существенно меняются.

Ранее типичный рабочий процесс включал поиск нужного сервиса, настройку хостинга, чтение документации, ручную интеграцию API, написание кода в IDE и настройку функций через панель низкокодового конфигурирования. Это был фрагментированный опыт, требующий переключения контекста и технических накладных расходов на каждом шаге.

Теперь с MCP-связанными агентами программирования большая часть этой сложности может быть абстрагирована. Разработчики могут находить и использовать инструменты более естественно через диалоговые подсказки. Интеграция API становится частью самого процесса разработки — часто без необходимости наличия отдельного интерфейса или ручной настройки. (Только подумайте, насколько сложными могут быть панели AWS или Microsoft). Взаимодействие становится более плавным — больше о направлении поведения, чем о сборке функций.

В этой модели взаимодействие пользователя или разработчика смещается от настройки функций к оркестровке поведений. Это также изменяет роль в дизайне продукта.

Вместо использования пользовательских интерфейсов для «завуалирования» технических сложностей (например, «это слишком сложно закодировать, давайте сделаем панель настройки»), теперь нужно:

• Думать об опыте от начала до конца
• Проектировать, как и когда должны объединяться взаимодействия ИИ и пользователя
• Позволить ИИ обрабатывать логику и направлять пользователей через намерение и поток

Задача становится вопросом решения, когда и как ИИ и ввод пользователя должны объединяться, позволяя ИИ обрабатывать логику, направляя пользователя через намерение и поток и как внедрять правильные взаимодействия в нужное время.

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

Агентные продуктовые парадигмы и их влияние на SaaS#

Мы начинаем наблюдать рост числа MCP-серверов. Представьте, что Airbnb предлагает сервер MCP для бронирования, или Google Maps предлагает сервер MCP для карт. Агент (как MCP-клиент) может подключаться к многим из этих серверов одновременно — разблокируя рабочие процессы, которые ранее требовали бы индивидуальных интеграций или тесно связанных приложений.

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

1. Проектировать по документам

   Вы пишете PRD в Notion. Агент Figma читает документ и автоматически создает макет, который отрисовывает основные концепции — без необходимости вручного перехода.

2. Конкурентный анализ от начала до конца

   Вы запрашиваете конкурентный анализ. Группа агентов ищет в интернете, регистрируется на релевантные сервисы от вашего имени (с безопасной аутентификацией), собирает результаты и доставляет артефакты обратно — уже организованные в вашем рабочем пространстве Notion.

Проблемы с грань аутентификации и авторизации#

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

До сих пор есть несколько сценариев, специфичных для нового подъема агентов-агентов и MCP.

1. Агент против SaaS и веб-приложений
2. MCP клиент (Агент) против MCP сервера
3. Пользователь против Агента
4. Агент против Агента

Еще один интересный случай использования — федерация нескольких идентичностей, упомянутая Google:

Например, пользователь U работает с агентом A, требующим идентификатора A-системы. Если Агент A затем зависит от Инструмента B или Агента B, которые требуют идентификатора B-системы, пользователь может понадобиться предоставить идентификаторы для обеих A-системы и B-системы в одном запросе. (Предположим, что A-система — это корпоративный идентификатор LDAP, а B-система — это идентификатор поставщика SaaS).

Logto является поставщиком OIDC и OAuth, хорошо подходящим для будущего ИИ-интеграций.

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

Есть вопросы?

Свяжитесь с нами — или погружайтесь и изучите, что вы можете создать с Logto сегодня.