Agent Communication Protocol (ACP) — это открытый протокол, который задаёт единые правила обмена сообщениями между ИИ‑агентами. Он позволяет разным агентам из разных фреймворков и инфраструктур общаться через REST‑интерфейс и работать как единая система, без жёсткой привязки к одному вендору.
ACP изначально появился как часть проекта IBM BeeAI и решал очень конкретную задачу: связать независимых агентов в общую среду, где они могут находить друг друга, вызывать, обмениваться результатами и при этом оставаться изолированными на уровне реализации. Сейчас ACP объединён с протоколом Agent2Agent (A2A) под управлением Linux Foundation, но базовые идеи ACP остаются ключевыми для обсуждения агентных протоколов и интероперабельности.
Содержание статьи
Зачем нужен ACP и какую проблему он решает
ACP нужен для того, чтобы убрать «островки» автономных агентов и заменить их сетью совместимых сервисов, которые понимают единый формат запросов и ответов. Это особенно важно там, где в одной среде работают десятки и сотни агентов разных типов, написанных на разных стэках.
Современные агентные фреймворки дают много возможностей, но почти всегда внутри своего «контейнера». Один агент живёт в LangChain, другой — в AutoGen, третий — вообще кастомный сервис с собственным API. Их можно связать вручную, но каждая такая связка превращается в отдельный проект интеграции со своими форматами, аутентификацией и обработкой ошибок. Масштабировать это тяжело технически и дорого экономически.
ACP предлагает одно правило игры: если агент «говорит» на ACP, то он становится частью общей сети. Любой другой ACP‑совместимый агент может его обнаружить, отправить запрос по HTTP, дождаться синхронного ответа или подписаться на асинхронный результат. При этом никто не требует переписывать агент на конкретный фреймворк, нужно только реализовать протокольный слой.
Как в ACP понимается ИИ‑агент и агентные системы
В контексте ACP ИИ‑агент — это программа или сервис, который самостоятельно выполняет задачи по запросу пользователя или другой системы, используя доступные инструменты и планируя шаги работы. Мультиагентная система — это связка из нескольких таких агентов, которые взаимодействуют между собой.
Простой пример: один агент анализирует текст, другой ходит в базы данных, третий отвечает за планирование цепочек действий. По отдельности они полезны, но сильный эффект появляется, когда они могут запрашивать друг у друга информацию и делегировать подзадачи. Именно на этом уровне и нужен протокол вроде ACP, который:
- определяет, как описывать сообщения между агентами;
- задаёт формат запросов, статусов и ответов;
- позволяет использовать единый HTTP‑слой вместо множества несогласованных API.
В результате, агентная система перестаёт быть монолитом одного фреймворка и превращается в набор «узлов», связанных общим стандартом общения.
Ключевые особенности ACP
ACP концентрируется на стандартизации коммуникации между агентами, а не на управлении их логикой или развёртыванием. Его особенности связаны с тем, как именно проходят запросы, как агенты обнаруживают друг друга и как обеспечивается гибкость интеграции.
REST‑подход и HTTP‑совместимость
ACP основан на обычных HTTP‑запросах и REST‑конвенциях. Это значит, что для общения с агентом достаточно уметь отправлять HTTP‑запросы и читать ответы в JSON.
В отличие от MCP, который опирается на JSON‑RPC и требует более сложной схемы взаимодействия, ACP выглядит привычно для backend‑разработчиков и легко включается в существующие сервисы. Агент за протоколом ACP — это по сути HTTP‑сервер с предсказуемыми путями и телом сообщений, описанным стандартом.
Работа без обязательного SDK
Одна из важных идей ACP — отсутствие жёсткой зависимости от библиотек. Для общения с агентом не нужен клиент‑SDK, достаточно любого HTTP‑клиента.
На практике это означает, что к ACP‑агенту можно обратиться:
- через cURL в терминале;
- через Postman или аналогичный инструмент;
- из браузера, если эндпоинт это допускает.
При этом разработчики всё равно могут использовать готовые SDK для удобства, но протокол к ним не привязан, что снижает риск блокировки на уровне платформы.
Оффлайн‑описание и обнаружение агентов
ACP предусматривает возможность встраивать метаданные агента прямо в его дистрибутив или пакет. Эти метаданные описывают способности агента, поддерживаемые операции и схему сообщений, которые он принимает.
Такой подход полезен в сценариях, где среда работает по принципу scale‑to‑zero: агент может быть выключен большую часть времени, но его описание всё равно доступно в регистре или репозитории. Система заранее знает, как к нему обращаться и какие задачи ему можно делегировать, даже если он в данный момент не активен.
Асинхронность по умолчанию
ACP изначально ориентирован на асинхронный обмен. Это удобно для долгих задач: обучение модели, сложная аналитика, обработка большого массива данных.
Клиент отправляет запрос и получает подтверждение, что задача принята. Результат можно забрать позже или получить через отдельный канал уведомлений, если это предусмотрено реализацией. При этом протокол поддерживает и синхронные запросы, когда ответ можно вернуть сразу, без ожидания.
Что ACP не делает
ACP не отвечает за то, как именно планируются цепочки вызовов агентов и как они развёртываются в инфраструктуре. Он не управляет жизненным циклом контейнеров, не строит графы задач, не решает вопросы оркестрации на уровне кластеров.
Эти задачи берут на себя системы поверх ACP. В экосистеме IBM эту роль выполнял BeeAI — открытый проект, который использовал ACP как коммуникационный слой, а сам занимался оркестрацией, развёртыванием и обменом агентами. ACP в этом наборе — транспорт и общий язык, а не диспетчер.
Почему без общего протокола интеграция агентов буксует
Без общего протокола коммуникации организация получает набор разрозненных агентов, каждый из которых требует ручной интеграции. Чем больше агентов и команд, тем быстрее растут затраты на поддержку таких связок.
Типовой сценарий: в компании появляются агенты для документов, кода, данных, мониторинга, внутреннего саппорта. Одни написаны на LangChain, другие через crewAI, третьи — внутренние сервисы. Чтобы агент А попросил что‑то у агента B, разработчикам приходится:
- разобраться в его API и формате данных;
- добавить аутентификацию и авторизацию;
- написать адаптеры для запросов и ответов;
- обработать ошибки сети и статусы задач.
Если агентов n, а интеграции делаются попарно, потенциальное количество связок растёт по формуле n(n‑1)/2. Это быстро превращается в малоуправляемую сеть зависимостей, где любое изменение в одном агенте тянет за собой правки во множестве адаптеров.
ACP сокращает это до одной общей точки соглашения: каждый агент реализует протокол один раз. Дальше он может общаться с любым другим ACP‑агентом без индивидуальной интеграции, поскольку формат сообщений и базовые механизмы уже описаны стандартом.
Типичные технические сложности без ACP
При отсутствии общего протокола компании сталкиваются с повторяющимся набором задач. ACP фокусируется ровно на этих местах.
Основные проблемы выглядят так:
- Разнообразие фреймворков. В одной инфраструктуре одновременно живут LangChain‑агенты, AutoGen‑агенты, crewИИ‑конвейеры и полностью кастомные реализации.
- Уникальные коннекторы. Для каждого нового взаимодействия приходится писать отдельный коннектор и думать, как трансформировать данные между форматами.
- Рост числа интеграций. По мере роста числа агентов количество точек связки увеличивается нелинейно, что усложняет тестирование и сопровождение.
- Разные модели безопасности. У партнёров и даже у внутренних команд могут быть разные подходы к аутентификации, токенам, правам доступа и логированию.
ACP не решает все организационные вопросы, но вводит единый слой общения, на который можно опереться при проектировании мультиагентной архитектуры и взаимодействии с внешними организациями.
Как ACP работает на примере взаимодействия компаний
Характерный пример применения ACP — стыковка агентов из разных организаций без написания специальных интеграций под каждого партнёра. Это хорошо видно на связке «производство — логистика».
С одной стороны есть производственная компания. У неё есть автономный агент, который следит за производственным графиком, учитывает складские остатки и статус заказов. С другой стороны — логистический оператор, у которого свой агент, рассчитывающий сроки доставки, варианты маршрутов и стоимость с учётом загруженности перевозчиков.
Производитель хочет автоматически включать в коммерческие предложения реалистичные сроки поставки крупного заказа. Для этого его агенту нужен внешний расчёт доставки.
Без ACP командам приходится:
- создавать прямую интеграцию между внутренней системой планирования и API логистики;
- согласовывать форматы запросов и ответов;
- разбираться в механизмах авторизации логистического API;
- учитывать особенности доступности сервисов, версий и обновлений.
Каждый новый логистический партнёр означает ещё один отдельный контур интеграции, который необходимо разрабатывать и поддерживать.
С ACP обе стороны описывают своих агентов в терминах протокола и размещают ACP‑совместимые интерфейсы. Производственный агент отправляет стандартный ACP‑запрос с параметрами заказа и точкой назначения. Логистический агент, получив сообщение, возвращает через ACP возможные варианты доставки и расчётные даты. При этом внутренние детали обеих систем не раскрываются, а добавление нового логистического партнёра сводится к тому, чтобы он тоже предоставил интерфейс по ACP.
Как начать использовать ACP на практике
Основная идея запуска ACP‑агента — обернуть существующую логику или фреймворк в HTTP‑слой, который понимает сообщения в формате ACP. Стартовая интеграция может занимать минимальное количество кода.
В типичном сценарии на Python с использованием SDK процесс выглядит так:
- Создаётся сервер ACP, который слушает HTTP‑запросы.
- Функция или класс‑агент помечается специальным декоратором, связывающим её с ACP‑эндпоинтом.
- Внутри агента используется, например, LangChain с LLM и памятью для сохранения контекста диалога.
- Реализуется преобразование между форматом сообщений ACP и внутренними структурами фреймворка.
- Сервер запускается и становится доступен другим ACP‑агентам через REST.
Результат — агент, который:
- может быть обнаружен по метаданным, даже если сейчас не запущен;
- принимает запросы синхронно или асинхронно;
- использует единый формат сообщений;
- интегрируется с любым другим ACP‑совместимым участником без отдельного коннектора.
ACP, MCP и A2A: как соотносятся протоколы
ACP не существует в вакууме. Вокруг него формируется слой стандартов, которые решают разные уровни интеграции: от доступа к инструментам до коммуникации между независимыми агентами и организациями.
Кратко о трёх протоколах
Для наглядности можно свести их основные цели в одну таблицу.
| Протокол | Основной фокус | Инициатор |
| MCP (Model Context Protocol) | Обогащение контекста одной модели инструментами, памятью и ресурсами | Anthropic |
| ACP (Agent Communication Protocol) | Общение независимых агентов между собой через REST, без привязки к вендору | IBM BeeAI |
| A2A (Agent2Agent) | Коммуникация агентов, ориентированная на экосистему Google |
MCP отвечает на вопрос «как дать одной модели доступ к нужным инструментам и данным». ACP и A2A решают другую задачу: «как разные агенты, часто в разных организациях, могут разговаривать на общем языке».
Почему MCP не закрывает сценарии мультиагентного обмена
MCP хорошо подходит для того, чтобы расширить одну модель набором инструментов, но у него есть ограничения для широких мультиагентных систем. Разработчики ACP столкнулись с несколькими принципиальными моментами.
Стриминг обновлений. MCP поддерживает потоковую передачу, но в более грубом формате, без полноценного «дельта»-подхода, где изменения приходят по мере появления частями (токены, обновления траектории и др.). Для сложных агентных сценариев, где важно отслеживать ход выполнения задач и промежуточные результаты, этого оказывается недостаточно.
Совместное использование памяти. MCP не даёт схемы для распределённых агентов на разных серверах с разделяемой памятью. ACP тоже ещё не завершил работу в этом направлении, но тема обозначена как одно из направлений развития.
Структура сообщений. MCP допускает произвольные JSON‑схемы и не навязывает чёткой формы тела сообщения. Гибкость полезна, но при взаимодействии множества независимых агентов это ведёт к тому, что каждый участник по‑своему трактует форматы, и интероперабельность страдает.
Сложность стека. MCP завязан на JSON‑RPC и отдельные SDK, которые необходимо поддерживать. ACP, опираясь на REST и стандартный HTTP, делает вход ниже и позволяет быстрее оборачивать существующие сервисы без глубокой перестройки.
Хороший способ смотреть на связку MCP и ACP — мысленно разделить уровни. MCP укрепляет одного «исполнителя», давая ему инструменты и память. ACP строит «команду исполнителей», которым нужно понятное общее средство общения.
Сходства и различия ACP и A2A
Agent2Agent (A2A), предложенный Google, по цели очень близок к ACP: это тоже протокол для общения независимых агентов, в том числе через организационные границы. Но подходы отличаются, прежде всего по окружению и управлению.
ACP проектировался как:
- простое встраивание в любые системы, которые уже используют HTTP и REST;
- подходящее под разные типы агентов и сценариев нагрузки;
- вендорно‑нейтральное решение с открытым управлением и участием разных игроков рынка.
A2A, в свою очередь, естественно интегрируется с сервисами и инфраструктурой Google и более органично вписывается в этот стек. В реальных проектах возможна ситуация, когда внутри среды Google разумно использовать A2A, а при выходе за её пределы — ориентироваться на ACP или совместимые с ним подходы.
Направления развития ACP и связанные вопросы
Идеи ACP продолжают развиваться уже в связке с A2A под Linux Foundation. При этом ряд тем, поднятых вокруг ACP, остаётся актуальным для любых открытых агентных протоколов.
К ключевым зонам внимания относятся:
- Федерация идентичностей. Как связать разные системы аутентификации и удостоверяющие центры, чтобы агенты могли доверять друг другу в распределённой сети.
- Делегирование доступа. Каким образом агент может временно передавать права другому агенту для выполнения подзадачи, не выдавая лишние полномочия.
- Мультирегистры и каталог агентов. Возможность поддерживать несколько реестров агентов в разных сетях и при этом обеспечивать единый поиск и обнаружение.
- Обмен и переиспользование агентов. Форматы описаний и практики, которые упрощают перенос агентов между организациями или командами без написания обвязки с нуля.
- Шаблоны развёртывания. Набор типовых конфигураций и инфраструктурных решений для запуска ACP‑совместимых агентов в облаках, on‑prem и гибридных средах.
Работа над ACP велась в открытом формате: спецификации и код доступны, обсуждения проходили публично. Такой подход облегчает включение идей ACP в другие инициативы и протоколы, в частности в A2A, и создаёт базу для согласованных стандартов, которые проще внедрять в крупных организациях.
