Agent Communication Protocol (ACP): как работает стандарт связи ИИ-агентов

Автономные агенты стремительно эволюционируют: сегодня они умеют писать код, анализировать документы, управлять инфраструктурой и даже спорить друг с другом о погоде. Но есть одна загвоздка — каждый агент чаще всего живёт в собственном «коконе»: свой фреймворк, свой API, свои хитрые форматы данных. Пока системы малы, мы закрываем глаза на зоопарк технологий. Однако стоит добавить десяток разнородных агентов, и интеграционные костыли начинают скрипеть громче, чем вентилятор на старом ноутбуке.

Agent Communication Protocol ( ACP ) призван положить конец этому феодализму. Это открытый стандарт, предложенный командой IBM BeeAI, который позволяет любым агентам, написанным на разных стэках и живущим в разных организациях, общаться на одном языке. В этом обзоре мы разберёмся, какие проблемы решает ACP, как он устроен, чем отличается от Model Context Protocol (MCP) и Agent2Agent (A2A), а главное — как начать использовать его уже сегодня, не утопив проект в документации и чужих SDK .

Что такое ACP и зачем он нужен

Начнём с терминов.

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

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

Сегодняшние агенты часто построены на несовместимых фреймворках — LangChain, crewAI, AutoGen или кастомных решениях. Каждый раскрывает API по-своему, а потому интеграция превращается в бесконечное написание мостов: вчера связали два агента, завтра появилось ещё пять, и получается n(n-1)/2 потенциальных точек стыков. Умножьте их на особенности авторизации, форматов данных и сетевых политик двух разных компаний — и вся экономия от автоматизации тает.

ACP меняет правила игры. Это «эсперанто» для агентов: единый, строго определённый, но гибкий протокол на базе привычного REST. С его помощью агенты могут:

• обнаруживать друг друга, даже когда находятся офлайн;
• общаться асинхронно (по умолчанию) или синхронно (при необходимости);
• масштабироваться, не полагаясь на «проволочные» интеграции;
• сохранять независимость стэков и одновременно работать в одной экосистеме.

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

У протокола есть несколько «фирменных» черт, которые делают его особенно дружелюбным к девелоперам.

• REST, а не JSON-RPC. Любой разработчик, хоть раз отправлявший запрос через curl, уже умеет разговаривать на ACP. Никаких экзотических транспорта или бинарных обёрток.
• SDK не обязателен. Хотите — берите готовый Python-набор, хотите — стучитесь напрямую HTTP-клиентом. Это снижает порог входа и избавляет от вечного «поддержим ли мы ваш рантайм?».
• Offline-discovery. Агент может зашить метаданные в Docker-образ или архив, и другие системы узнают о его возможностях ещё до того, как контейнер стартует. Очень полезно для scale-to-zero-архитектур, где сервис спит до первого запроса.
• Асинхронность по умолчанию. Долгие задачи не блокируют клиента: запрос ушёл — ответ придёт, когда агент освободится. При этом синхронное взаимодействие остаётся, если оно реально нужно (например, при коротком чате).

Как ACP меняет ландшафт многоагентных систем

Представьте, что ваша команда разрабатывает 10 агентов: пять — аналитика данных на Pandas, два — DevOps-бота, три — фронтенд-ассистента. Каждый строился «под задачу» и использует разные библиотеки. Без ACP между ними будут расти «надстройки» из конвертеров и адаптеров — пока не придёт день, когда обновление версии Python в одном сервисе отправит половину системы в нокаут.

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

Важно подчеркнуть: ACP не управляет оркестровкой. Он лишь даёт общий язык. За дирижирование отвечает, например, BeeAI — open-source платформа для развертывания и управления агентами, которая использует ACP как транспортный слой.

Реальный пример: производитель и логистический провайдер

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

• Без ACP. Две команды садятся и пишут кастомную интеграцию: договариваются об эндпойндах, форматах JSON, обмене токенами, политике таймаутов. Следующий партнёр — и всё повторяется.
• С ACP. Оба агента публикуют себя через ACP-интерфейс. Производственный агент отправляет заказ и адрес доставки, логистический отвечает вариантами перевозки и ETA. Нового перевозчика? Достаточно, чтобы у него был ACP-совместимый агент — и завод подключит его «из коробки», ничего не ломая.

Сравнение ACP с MCP и A2A

Чтобы расставить «маячки» на карте, посмотрим, какие задачи решают родственные протоколы.

Model Context Protocol ( MCP ). Предназначен для «обогащения» одного LLM доступом к инструментам и памяти. Хорош, когда у вас один «мега-модель» и много внешних вспомогателей — но он был задуман без учёта полноценной межагентной коммуникации. У него ограниченный стриминг и неопределённый формат тела сообщений.

Agent2Agent ( A2A ). Предложен Google и тоже ориентирован на коммуникацию агентов, но исторически тесно интегрирован с «гугловской» экосистемой. Если вы закручены вокруг Google Cloud, он может оказаться удобнее; если же нужно vendor-neutral решение и открытое управление стандартом — ACP будет ближе.

На практике MCP, ACP и A2A не конкуренты, а «слои пирога»: MCP — это один агент + инструменты, ACP и A2A — множество равноправных агентов. Никто не мешает использовать MCP внутри агента, а ACP наружу.

Первый шаг: оборачиваем агента в ACP

Красота ACP в том, что «Hello, Agent!» пишется на пяти строчках. Пример ниже иллюстрирует Python-сервер, который принимает сообщения, прокидывает их в LangChain-асистента и возвращает ответ.

from acp_sdk.server import Server, RunYield, RunYieldResume  from acp_sdk.models import Message, MessagePart  from langchain_anthropic import ChatAnthropic  import os, asyncio    llm = ChatAnthropic(      model="claude-3-5-sonnet-latest",      api_key=os.getenv("ANTHROPIC_API_KEY")  )    server = Server()    @server.agent()  async def chatbot(messages: list[Message]) -> RunYield:      query = " ".join(          part.content          for msg in messages          for part in msg.parts      )      llm_resp = llm.invoke(query)      yield {"messages": [Message(parts=[MessagePart(content=llm_resp.content)])]}    server.run()

Что получили:

• ACP-сервер поднят: любой клиент может стучаться обычным HTTP-запросом.
• Асистент переживёт долгие расчёты, отвечая асинхронно.
• Другие агенты легко обнаружат сервис, даже если он «спит» в контейнере.

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

Протокол не высечен в граните. В планах команды — федерация идентификации (чтобы доверять агентам из разных доменов), безопасная делегация прав, децентрализованные реестры и каталоги для «магазина» агентов. Особое внимание уделяется механизму шаринга: хотелось бы обмениваться «квантами интеллекта» так же просто, как сегодня мы делимся Docker-образами.

ACP развивается в открытом репозитории — каждый баг-репорт или Pull Request приветствуется. Чем шире круг участников , тем быстрее появятся ответ на «вечные» вопросы: как валидировать сообщения, как шифровать трафик между организациями, как версионировать агента.

Заключение

Agent Communication Protocol вырос из желания разработчиков сэкономить себе нервы. Он снимает боль интеграций, позволяя агентам говорить на общем языке, независимо от того, на каком фреймворке они написаны и в чьём дата-центре работают. Как и любой открытый стандарт, ACP силён ровно настолько, насколько активно им пользуются — поэтому лучший способ ускорить его эволюцию — попробовать в деле.

Подключите к проекту первого ACP-совместимого агента, и вы заметите: писать новый функционал интереснее, чем чинить старые мосты. А когда к вашей системе захочет присоединиться партнёр с «экзотическим» стеком, вы просто скажете ему: «Просто добавь ACP». И это, пожалуй, самый короткий путь от идеи к работающей коллаборации.