ACP стремится стать «HTTP для взаимодействия агентов», преобразуя нынешний разрозненный ландшафт изолированных ИИ-агентов во взаимосвязанные системы агентов с высокой степенью совместимости.

С помощью ACP (Agent Communication Protocol) ИИ-агенты могут свободно взаимодействовать между собой — независимо от используемых команд, фреймворков, технологий и организаций. Это универсальный протокол, превращающий фрагментированный мир современных ИИ-агентов в согласованно взаимодействующие компоненты. Такой подход открывает новые возможности для совместимости, повторного использования решений и масштабирования.

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

Ключевые особенности ACP

Взаимодействие через REST
ACP использует стандартные HTTP-шаблоны для взаимодействия, что облегчает интеграцию в продакшен. В отличие от JSON-RPC, использующего более сложные схемы вызова и интеграции, ACP делает упор на простоту и совместимость.

Нет необходимости в SDK (но он доступен при необходимости)
Для работы с ACP не требуются специализированные библиотеки. Взаимодействовать с агентами можно с помощью инструментов вроде curl, Postman или даже через браузер. Однако для удобства доступен SDK.

Оффлайн-обнаружение
Агенты ACP могут встраивать метаданные прямо в свои распространяемые пакеты, что позволяет обнаруживать их даже в неактивном состоянии. Это особенно полезно для защищённых, изолированных или масштабируемых до нуля (scale-to-zero) сред, где обычное обнаружение сервисов (service discovery) недоступно.

Асинхронность по умолчанию, поддержка синхронных вызовов
ACP изначально ориентирован на асинхронное взаимодействие, что оптимально для длительных или ресурсоёмких задач. Тем не менее, синхронные запросы также поддерживаются.

Примечание: ACP позволяет оркестрацию для любого архитектурного паттерна взаимодействия агентов, но не управляет рабочими процессами, развёртываниями или координацией между агентами. Вместо этого она обеспечивает оркестрацию взаимодействия между разными агентами, стандартизируя способ обмена сообщениями. Исследования IBM разработали BeeAI — открытое решение, предназначенное для управления оркестрацией агентов, развёртыванием и обменом данными (с использованием ACP в качестве слоя коммуникации).

Зачем нужен ACP?

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

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

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

Текущие проблемы

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

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

• Индивидуальная интеграция: при отсутствии стандартного протокола разработчикам приходится писать отдельные адаптеры для каждого типа взаимодействия между агентами.

• Экспоненциальная сложность: при наличии n агентов потенциально требуется настроить до n(n-1)/2 точек интеграции — что делает масштабные мультиагентные экосистемы крайне трудными в обслуживании.

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

Пример из реального мира

Чтобы продемонстрировать практическую необходимость в коммуникации между агентами, рассмотрим ситуацию с участием двух организаций:

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

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

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

Без ACP
Для этого пришлось бы писать кастомную интеграцию между системой планирования производителя и API логистической компании. Это означает настройку аутентификации вручную, преобразование форматов данных и управление доступностью сервисов. Такие интеграции дороги, нестабильны и плохо масштабируются с ростом числа партнёров.

С ACP
Каждая организация оборачивает своего агента в ACP-интерфейс. Производственный агент отправляет детали заказа и назначения логистическому агенту, который отвечает актуальными вариантами доставки и предполагаемыми сроками прибытия. Обе системы взаимодействуют, не раскрывая внутренние данные и не создавая кастомных интеграций. Новые партнёры легко подключаются, реализовав ACP.

Насколько просто создать агента, совместимого с ACP?

Простота — ключевой принцип ACP. Обернуть агента в ACP можно буквально за несколько строк кода. Используя Python SDK, вы можете определить агента, совместимого с ACP, просто декорируя функцию.

Минимальная реализация делает следующее:

• Создаёт экземпляр ACP-сервера.

• Определяет функцию агента с помощью декоратора @server.agent().

• Реализует агента на базе фреймворка LangChain с LLM-моделью и памятью для сохранения контекста.

• Преобразует сообщения из формата ACP в нативный формат фреймворка и возвращает структурированный ответ.

• Запускает сервер, делая агента доступным по HTTP.

Пример кода

Теперь у вас есть полностью совместимый с ACP агент, который может:

• Быть обнаружен другими агентами (в том числе в офлайне);

• Обрабатывать запросы синхронно и асинхронно;

• Общаться в стандартных форматах сообщений.

• Интегрироваться с любой другой системой, поддерживающей ACP.

Как ACP сравнивается с MCP и A2A

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

Обзор:

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

• ACP (Agent Communication Protocol от Linux Foundation): предназначен для коммуникации между независимыми агентами в разных системах и организациях.
  Фокус: много агентов, работающих на равных, без привязки к конкретному вендору, с открытым управлением.

• A2A (Agent-to-Agent от Google): тоже предназначен для связи между независимыми агентами в разных системах и организациях.
  Фокус: много агентов, работающих на равных, оптимизирован для экосистемы Google.

ACP и MCP

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

Почему MCP не подходит для мульти-агентных систем:

• Потоковая передача (Streaming): MCP поддерживает потоковую передачу данных, но не умеет работать с дельта-потоками (например, обновления токенов или состояний). Это связано с тем, что MCP изначально не задумывался для агентских взаимодействий.

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

• Структура сообщений: MCP принимает любую схему JSON, но не задаёт формата тела сообщения. Эта гибкость делает совместимость сложной (особенно при создании пользовательских интерфейсов или оркестрации агентов, которые должны интерпретировать различные форматы сообщений).

• Сложность протокола: MCP использует JSON-RPC и требует специальных SDK и сред выполнения, тогда как ACP базируется на REST с поддержкой асинхронных и синхронных вызовов, что делает его легче для интеграции.

Больше подробностей о сравнении — в официальной документации.

Представьте, что MCP — это как дать человеку инструмент, например смартфон, чтобы повысить его эффективность. В то время как ACP — это про возможность формировать команды, где каждый человек (или агент) привносит свои способности и сотрудничает с другими.

ACP и MCP могут дополнять друг друга:

ACP и A2A

Протокол Agent-to-Agent (A2A) от Google, который был представлен вскоре после ACP, тоже решает задачу стандартизации взаимодействия между ИИ-агентами. Оба протокола нацелены на поддержку мультиагентных систем, но различаются по философии и управлению.

Ключевые различия:

ACP с самого начала проектировался, чтобы быть:

• Простым для интеграции с использованием обычных HTTP-инструментов и REST-конвенций.

• Гибким для широкого спектра типов агентов и рабочих нагрузок.

• Независимым от вендоров, с открытым управлением и широкой поддержкой экосистемы.

Оба протокола могут сосуществовать, решая разные задачи в зависимости от среды. Легковесный, открытый и расширяемый дизайн ACP делает его хорошим выбором для децентрализованных систем и межорганизационной совместимости в реальных условиях. В то же время, A2A благодаря тесной интеграции может быть более подходящим вариантом для пользователей экосистемы Google.

Дорожная карта и сообщество

По мере развития ACP команда исследует новые возможности для улучшения коммуникации между агентами. Вот ключевые направления работы:

• Федерация идентичностей: как ACP может работать с системами аутентификации для повышения доверия в сетях?

• Делегирование доступа: как агенты могут безопасно делегировать задачи, сохраняя контроль у пользователя?

• Поддержка мульти-реестров: может ли ACP поддерживать децентрализованное обнаружение агентов в разных сетях?

• Общий доступ к агентам: как упростить обмен и повторное использование агентов между организациями или внутри одной организации?

• Развёртывание: какие инструменты и шаблоны могут упростить развёртывание агентов?

ACP разрабатывается открыто, так как стандарты работают лучше всего, когда они создаются совместно с пользователями. Вклад от разработчиков, исследователей и организаций, заинтересованных в будущем совместимости агентов, приветствуется. Присоединяйтесь и помогайте формировать открытый стандарт будущего.

Если вы интересуетесь тем, как ИИ-агенты, LLM и инженерия процессов взаимодействия становятся частью продакшен-среды — приходите на ближайшие открытые уроки:

• 4 июня, 20:00
  Multimodal RAG: как LLM работают с текстами, картинками и документами
  Практика интеграции языковых моделей с внешними источниками знаний: от PDF до изображений. Как построить мультимодальный пайплайн и применить его в продуктах.

• 10 июня, 20:00
  Jenkins Job Builder: автоматизируем развёртывание jobs и упрощаем CI/CD процесс
  Управление Jenkins без ручного создания задач: jinja2, шаблоны, docker-compose и стабильная автоматизация в действии.

• 17 июня, 20:00
  Автоматизация ML-экспериментов с помощью GitLab CI/CD и CML
  Организация воспроизводимых ML-экспериментов, визуализация метрик в Merge Requests и запуск моделей через GitLab-пайплайны.

Пройдите вступительное тестирование по машинному обучению — проверьте, сможете ли потянуть программу продвинутого курса по ML.