A OpenClaw dividiu o trabalho multiagente em três modos: agentes independentes, subagentes e ACP

OpenClaw показала мультиагентную модель не как абстрактную идею, а как набор рабочих режимов для реальных задач в Telegram. Пользователь может держать одного главного агента, а дальше раздавать роли постоянным исполнителям, временным субагентам и внешним инструментам для разработки через ACP.

Три режима работы В основе схемы OpenClaw лежат три разных способа делегирования.

Первый — отдельные постоянные агенты со своей рабочей папкой, памятью и инструкциями. Второй — субагенты, которых основной агент запускает под конкретную разовую задачу и снабжает только нужным контекстом. Третий — ACP, то есть режим, где инженерную работу выполняет уже не сам OpenClaw, а подключённый внешний инструмент вроде Codex, Claude Code или Gemini CLI. Получается не один универсальный помощник, а диспетчер, который умеет выбирать подходящий уровень исполнения под тип работы.

• Постоянный агент — для роли, которая нужна регулярно Субагент — для разового исследования или части большой задачи ACP — для задач по разработке во внешней среде * Основной агент — для маршрутизации, контроля и сборки результата > «Мультиагентность в OpenClaw — это не одна кнопка, а несколько режимов работы агентов».

Когда нужен каждый

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

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

Это особенно полезно для ресерча и предварительного анализа. В таком режиме не нужно заранее заводить нового постоянного участника: субагент появляется под задачу, получает ограниченный контекст и исчезает после выполнения, не перегружая общую систему лишней памятью. Для разработки OpenClaw предлагает отдельный маршрут через ACP.

Здесь главный агент остаётся точкой входа и оркестратором, но сам код пишет внешний инструмент. В статье описаны три сценария: разовая ACP-сессия для одиночной инженерной задачи, постоянная ACP-сессия для длительного проекта и привязка ACP-контекста к отдельному Telegram topic, где техническая линия обсуждения живёт отдельно от основного чата. Такой режим нужен, когда проекту важны длинный контекст, последовательные итерации и преимущества специализированных CLI-инструментов.

Telegram как пульт

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

Для пользователя это выглядит не как сложная инфраструктура, а как понятная карта диалогов с разными типами исполнителей. Из этого вытекает и главный сценарий OpenClaw: основной агент перестаёт быть просто собеседником и становится координатором системы. Он может отправить ресерч отдельному агенту, разовую подзадачу — субагенту, инженерную часть — в ACP через Codex, а затем вернуть один собранный ответ.

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

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

OpenClaw фактически предлагает не «магического AI-агента», а операционную модель для команд и соло-разработчиков, которые хотят разнести роли, контекст и инструменты по разным каналам. Если такой подход приживётся, Telegram-чаты с агентами начнут всё больше напоминать лёгкую IDE и диспетчерскую одновременно: одна точка входа, несколько исполнителей и более чистое разделение между ресерчем, контентом и кодом.