OpenIDE ajoute ACP : comment le protocole de JetBrains et Zed change la façon dont les agents AI travaillent dans les IDE

ACP становится новым слоем совместимости между IDE и AI-агентами: вместо отдельной интеграции под каждый инструмент редактор и агент договариваются по общему протоколу. В OpenIDE уже сделали базовую поддержку ACP и готовят её к бета-тестированию.

Что такое ACP

За последний год рынок AI-инструментов для разработки превратился в мешанину из отдельных экосистем. Claude Code, Codex, Cursor, Windsurf, Kilo Code, Qwen Code и другие агенты умеют писать, исправлять и рефакторить код, но почти каждый приходит со своей схемой подключения к редактору. В результате разработчик выбирает не только самого сильного агента, но и тот редактор, где под него уже написана интеграция.

ACP пытается сломать именно эту зависимость. По своей идее ACP очень похож на LSP, который когда-то избавил редакторы от необходимости отдельно реализовывать поддержку каждого языка. Если тогда единый протокол связал редактор и языковой сервер, то теперь такой же слой совместимости появляется между IDE и AI-агентом.

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

Почему без стандарта сложно

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

Но как только хочешь сравнить нескольких агентов, быстро упираешься в несовместимость, лишние настройки и vendor lock-in. Для команд это ещё болезненнее: смена редактора или агента начинает тянуть за собой лишнюю миграцию процессов. ACP нужен именно для того, чтобы разделить роли.

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

Важно и другое: подключение модели по API — это не то же самое, что подключение агента. Когда ты просто указываешь ключ к LLM, редактор сам остаётся оркестратором и лишь отправляет запросы провайдеру. ACP позволяет встроить в IDE именно готового агента как отдельную сущность.

Для разработчика это удобнее: можно использовать любимый редактор, не теряя особенности конкретного AI-инструмента. Иначе говоря, стандарт переносит в IDE не только модель, но и весь её рабочий контур.

Что появится в

OpenIDE Haulmont пишет, что в OpenIDE базовая реализация ACP уже готова, а следующая стадия — бета-тестирование. Для пользователей это не абстрактное «поддержим когда-нибудь», а вполне прикладной шаг в сторону IDE, где агент подключается как стандартный компонент. Если поддержка дойдёт до стабильного релиза без серьёзных ограничений, OpenIDE сможет быстрее принимать новых совместимых агентов без отдельных кастомных интеграций под каждого из них.

• Базовая поддержка ACP уже реализована Функция войдёт в состав OpenIDE Pro На время бета-теста совместимость обещана и в базовой версии OpenIDE * Желающие могут запросить ранний доступ и настройку заранее Логика понятна: вместо того чтобы вручную поддерживать всё больше отдельных AI-плагинов, IDE получает единый интерфейс для внешних агентов. При этом сама OpenIDE продолжает опираться на привычные для разработчика вещи — редактор, навигацию, рефакторинги, терминал и экосистему плагинов. В статье отдельно подчёркивается, что уже сейчас среда рассчитана на Java, Spring, Python, Go, JavaScript и TypeScript, а также умеет работать с Docker и расширениями из совместимого маркетплейса. ACP в этой схеме выглядит не как модная надстройка, а как следующий инфраструктурный слой.

Что это значит

Если ACP закрепится так же, как когда-то закрепился LSP, рынок AI-кодинга станет заметно более открытым. Разработчики смогут выбирать лучший агент отдельно от любимой IDE, а создатели агентов — тратить меньше сил на десятки индивидуальных интеграций. Для OpenIDE это шанс быстрее подключать популярные инструменты, а для всей экосистемы — шаг от хаотичного зоопарка AI-плагинов к более внятному стандарту. Именно такие протоколы обычно и решают, какие подходы становятся массовыми, а какие остаются нишевыми.