Что такое MCP (Model Context Protocol)?
Model Context Protocol (MCP), представленный компанией Anthropic, определяет стандартизированный интерфейс для предоставления структурированного, актуального контекста большим языковым моделям (LLM).
Основные функции
Внедрение контекстных данных
MCP позволяет подключать внешние ресурсы — такие как файлы, строки из баз данных или ответы API — непосредственно в промпт или рабочую память. Всё это происходит через стандартизированный интерфейс, благодаря чему ваша LLM остаётся лёгкой и чистой.
Маршрутизация и вызов функций
MCP также позволяет моделям динамически вызывать инструменты. Вы можете зарегистрировать возможности, такие как searchCustomerData
или generateReport
, и LLM сможет вызывать их по требованию. Это похоже на предоставление вашему ИИ доступа к набору инструментов, но без жёсткой привязки инструментов к самой модели.
Оркестрация промптов
Вместо того чтобы заполнять промпт всеми возможными деталями, MCP помогает собрать только тот контекст, который имеет значение. Представьте себе модульную, создаваемую на лету конструкцию промптов — более умный контекст, меньше токенов, лучшие результаты.
Характеристики реализации
- Работает через HTTP(S) с дескрипторами возможностей на основе JSON
- Разработан независимо от модели — любая LLM с совместимым временем выполнения может использовать серверы, соответствующие MCP
- Совместим с шлюзами API и корпоративными стандартами аутентификации (например, OAuth2, mTLS)
Примеры использования в разработке
- Интеграции LLM для внутренних API: обеспечить безопасный, только для чтения или интерактивный доступ к структурированным бизнес-данным без раскрытия необработанных конечных точек.
- Корпоративные агенты: оснастить автономных агентов контекстом выполнения из таких инструментов, как Salesforce, SAP или внутренние базы знаний.
- Динамическая конструкция подсказок: адаптировать подсказки на основе пользовательской сессии, состояния системы или логики конвейера задач.
Что такое ACP (Agent Communication Protocol)?
Agent Communication Protocol (ACP) — это открытый стандарт, изначально предложенный BeeAI и IBM, предназначенный для обеспечения структурированной коммуникации, обнаружения и координации между AI-агентами, работающими в одной локальной или периферийной среде.
В отличие от ориентированных на облако протоколов, таких как A2A, или протоколов маршрутизации контекста, таких как MCP, ACP разработан для локальной, в первую очередь, оркестрации агентов в реальном времени с минимальной сетевой нагрузкой и тесной интеграцией между агентами, развернутыми в рамках общего времени выполнения.
Дизайн и архитектура протокола
ACP определяет децентрализованную среду агентов, в которой:
- Каждый агент объявляет свою личность, возможности и состояние, используя слой локальной трансляции/обнаружения.
- Агенты общаются через событийно-ориентированную передачу сообщений, часто используя локальную шину или систему межпроцессного взаимодействия (IPC).
- Контроллер выполнения (опционально) может оркестрировать поведение агентов, агрегировать телеметрию и обеспечивать выполнение политик.
Агенты ACP обычно работают как лёгкие, без состояния сервисы или контейнеры с общей коммуникационной основой.
Характеристики реализации
- Разработан для сред с низкой задержкой (например, локальная оркестрация, робототехника, офлайн периферийный ИИ)
- Может быть реализован поверх gRPC, ZeroMQ или кастомных коммуникационных шин
- Подчеркивает локальный суверенитет — не требует зависимости от облак или регистрации внешних сервисов
- Поддерживает типизацию возможностей и семантические дескрипторы для автоматической маршрутизации задач
Примеры использования
- Оркестрация нескольких агентов на периферийных устройствах (например, дроны, кластеры IoT или роботизированные флоты)
- Системы LLM, ориентированные на локальность, координирующие вызовы моделей, входы сенсоров и выполнение действий
- Автономные среды выполнения, где агенты должны координироваться без централизованной облачной инфраструктуры
Проще говоря, ACP — это локальный протокол взаимодействия для модульных AI-систем, который делает упор на быструю координацию, отказоустойчивость и гибкую сборку компонентов. Он особенно хорошо подходит для автономных, чувствительных к приватности и периферийных решений, где облачные протоколы использовать затруднительно.
Что такое A2A (Agent-to-Agent Protocol)?
Agent-to-Agent (A2A) Protocol, представленный Google, представляет собой кроссплатформенную спецификацию, позволяющую AI-агентам общаться, сотрудничать и делегировать задачи в различных системах.
В отличие от локального фокуса ACP или слоя интеграции инструментов MCP, A2A решает проблему горизонтальной совместимости — стандартизируя, как агенты от разных поставщиков или сред выполнения могут обмениваться возможностями и координировать рабочие процессы через открытый веб.
Обзор протокола
A2A определяет модель коммуникации на основе HTTP, где агенты рассматриваются как совместимые сервисы. Каждый агент предоставляет «Карту агента» — машиночитаемый JSON-дескриптор, описывающий его личность, возможности, конечные точки и требования к аутентификации.
Агенты используют эту информацию для:
- Программного обнаружения друг друга
- Переговоров о задачах и ролях
- Обмена сообщениями, данными и потоковыми обновлениями
A2A по сути независим от транспортного уровня, но в настоящее время специфицирует JSON-RPC 2.0 поверх HTTPS как основной механизм взаимодействия.
Основные компоненты
Карты агентов
JSON-документы, описывающие возможности агента, конечные точки, поддерживаемые типы сообщений, методы аутентификации и метаданные времени выполнения.
Интерфейс клиента/сервера A2A
Каждый агент может функционировать как клиент (инициатор задач), сервер (исполнитель задач) или оба, что позволяет динамическую маршрутизацию задач и переговоры.
Обмен сообщениями и артефактами
Поддерживает многокомпонентные задачи с контекстом, потоковым выводом (через SSE) и постоянными артефактами (например, файлы, фрагменты знаний).
Переговоры о пользовательском опыте
Агенты могут адаптировать формат сообщений, степень детализации контента и визуализацию, чтобы соответствовать возможностям последующих агентов.
Архитектура безопасности
- Авторизация на основе OAuth 2.0 и API-ключей
- Конечные точки с ограничением возможностей — агенты раскрывают только функции, необходимые для заявленных взаимодействий
- Агенты могут работать в «непрозрачном» режиме — скрывая внутреннюю логику при раскрытии вызываемых сервисов
Характеристики реализации
- Веб-нативный по дизайну: построен на HTTP, JSON-RPC и стандартной веб-безопасности
- Независим от модели: работает с любой системой агентов (LLM или другой), реализующей протокол
- Поддерживает потоковую передачу задач и многократное сотрудничество с лёгкими полезными нагрузками
Примеры использования
- Кроссплатформенные экосистемы агентов, где агенты от разных команд или поставщиков должны безопасно взаимодействовать
- Распределённая оркестрация агентов в облачных AI-средах (например, Vertex AI, LangChain, HuggingFace Agents)
- Фреймворки для многократного сотрудничества агентов, такие как корпоративные AI-рабочие процессы, охватывающие несколько систем (например, CRM, HR, IT-агенты)
Сравнение протоколов
Вот переведённая таблица сравнения протоколов MCP, ACP и A2A:
Характеристика | MCP | ACP | A2A |
---|---|---|---|
Основной фокус | Внедрение контекста в LLM | Локальная координация агентов | Коммуникация агентов между платформами |
Архитектура | Клиент-сервер (модель хост/сервер) | Децентрализованная, локальная среда исполнения | Клиент/сервер на HTTP с «Картами агентов» |
Область применения | Вертикальная интеграция (инструменты → модель) | Локальная среда исполнения агентов | Горизонтальная интеграция (агент ↔ агент) |
Механизм обнаружения | Реестр инструментов на сервере | Локальная трансляция / регистрация во время выполнения | «Карта агента» через HTTP(S) |
Транспортный протокол | HTTP(S), JSON | IPC, ZeroMQ, gRPC (гибко) | JSON-RPC 2.0 по HTTPS |
Модель безопасности | Аутентификация на уровне приложений, OAuth2, ограниченные API | Изолированная среда исполнения, безопасность локальной сети | OAuth2, ограниченный доступ к конечным точкам |
Лучше всего подходит для | Приложений LLM, которым нужен доступ к внешним данным/инструментам | Edge-ИИ, встроенные системы, офлайн-агенты | Многокомпонентные AI-решения на разных платформах |
Пример использования | Подключение LLM к внутренним API | Координация множества мелких агентов на устройстве | Совместная работа распределённых агентов в компании |
Дополняющие или конкурирующие?
A2A + MCP
A2A и MCP не конкурируют друг с другом — они решают совершенно разные части головоломки агентного ИИ и на самом деле хорошо сочетаются.
Представьте MCP как протокол, позволяющий AI-агентам подключаться к миру. Он предоставляет им доступ к файлам, API, базам данных — в основном, ко всем структурированным контекстам, необходимым для выполнения полезных действий. Будь то получение данных о продажах в реальном времени или создание пользовательского отчёта, MCP обрабатывает подключение к инструментам и данным.
Теперь добавьте A2A. Здесь агенты начинают сотрудничать. A2A предоставляет им общий язык и набор правил для обнаружения друг друга, делегирования задач и переговоров о том, как они будут работать вместе — даже если они созданы разными поставщиками или работают на разных платформах.
Итак, простое объяснение:
- MCP подключает AI к инструментам.
- A2A подключает AI к другим AI.
Вместе они формируют прочную модульную основу для создания умных, совместных систем.
А как насчёт ACP?
Затем есть ACP, который предлагает совершенно иной подход. Всё дело в локальной координации агентов — облако не требуется. Вместо использования HTTP и веб-обнаружения ACP позволяет агентам находить и общаться друг с другом прямо внутри общей среды выполнения.
Это идеально подходит для ситуаций, когда:
- У вас ограниченная пропускная способность или требуется низкая задержка (например, в робототехнике или встроенных помощниках),
- Важна конфиденциальность, и всё должно оставаться офлайн,
- Или вы работаете в изолированной среде, не подключённой к интернету (например, заводские цеха, edge-устройства).
ACP не пытается конкурировать с A2A — он просто решает другую задачу. Но в некоторых сценариях, особенно в жёстко контролируемых системах, ACP может полностью заменить A2A, поскольку избавляется от избыточности веб-протоколов и просто делает свою работу локально.
Конвергенция или фрагментация?
По мере того как всё больше команд начинают использовать эти протоколы, начинают вырисовываться несколько возможных сценариев развития.
Лучший исход?
Мы придём к конвергенции. Представьте единую платформу агентов, где A2A отвечает за координацию между агентами, MCP управляет доступом к инструментам и данным, а среды в стиле ACP подключаются для периферийных или офлайн-сценариев. Всё работает как единое целое, и разработчики могут строить поверх этого свои решения, не вдаваясь в детали того, какой протокол что делает за кулисами.
Худший исход?
Произойдёт фрагментация. Разные вендоры будут продвигать собственные версии A2A и MCP, и в итоге нас ждёт хаос — как в начале эпохи веб-сервисов, когда системы не могли взаимодействовать без кучи “костыльного” кода.
Компромиссный сценарий?
Нас могут спасти open-source-инструменты и прослойки. Такие проекты будут находиться между агентами и протоколами, абстрагируя различия и предоставляя разработчикам единый, чистый API — автоматически адаптируясь под то, где и как выполняются агенты.
Короче говоря: мы всё ещё в самом начале пути. Но то, как мы сейчас создаём и принимаем эти стандарты, определит, станут ли AI-агенты целостной экосистемой — или останутся разрозненной мозайкой несовместимых решений.
Этот текст является переводом статьи: What Every AI Engineer Should Know About A2A, MCP & ACP