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

BI-задачи неплохо подходят для такой проверки ввиду своей разнородности. Дашборд — это не один SQL-запрос и не одна визуализация. Нужно понять бизнес-запрос, уточнить KPI, проверить данные, спроектировать датасет, собрать чарты, собрать дашборд и на каждом этапе обеспечить соответствующие проверки.

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

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

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

Суть эксперимента: проверить, можно ли сделать переходы между агентами управляемыми на конкретном BI-сценарии: провести задачу от входного запроса до готового дашборда в Apache Superset через команду агентов на multica — open-source платформе управления задачами с канбан доской в стиле Jira/Yougile. В multica можно создавать изолированные рабочие пространства, в каждому свои runtime и набор агентов. При этом задачи канбан доски можно назначить не только человеку, но и агенту: агент получает конкретный issue, в которой видны все его сессии, также через CLI агенту доступны комментарии, изменения статусов, создание новых задач для передачи работы дальше по конвейеру. Таким образом агенты участвует в процессе как исполнитель конкретного шага, так и как координаторы.

Задача

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

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

Именно поэтому BI оказался удобным сценарием для проверки мультиагентного подхода. Задача достаточно сложная, чтобы в ней были разные режимы работы, не укладывающиеся в роль одного агента, но при этом достаточно структурированная, чтобы разложить её на этапы, роли и критерии приёмки.

Рабочий цикл выглядит так:

→ уточнение постановки
→ проверка данных
→ проектирование датасета
→ проектирование дашборда
→ подготовка данных
→ сборка чартов
→ сборка дашборда
→ проверка кода, разметки
→ повторный цикл для доработок
→ проверка дашборда

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

Десять ролей с узкой специализацией

В системе используется 10 ролей.

Coord — координатор процесса. Разбирает входную задачу, делегирует этапы, открывает review-issues, маршрутизирует доработки, принимает решение о переходе к следующей фазе и делать merge результат.

AUTHOR — 3 роли:

scoping — уточняет постановку, KPI, границы задачи;
dataset-architect — проектирует структуру датасета;
dashboard-designer — описывает логику и структуру будущего дашборда.

BUILDER — 3 роли:

data-engineer — готовит данные и проверяемые датасеты;
chart-builder — собирает чарты;
dashboard-builder — собирает дашборды.

REVIEWER — 3 роли:

data-steward — проверяет данные, KPI и смысловую корректность;
bi-tech-lead — проверяет техническую реализуемость и качество решения;
dashboard-reviewer — проверяет как отдельные чарты, так и дашборд целиком.

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

Базовая цепочка работы команды:

→ scoping (data steward)

→ dataset-architect (bi-tech-lead)

→ dashboard-designer (

→ data-engineer (bi-tech-lead)

→ chart-builder (dashboard-reviewer)

→ dashboard-builder (dashboard-reviewer)

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

Проза в промптах и координация агентов

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

В реальном процессе такой формат быстро столкнулся с проблемами:

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

Поэтому появился структурированный handoff между агентам. По сути в конце работы агент оставляет блок с обязательными полями:

===HANDOFF===

STATUS: ...

REVIEWERS-REQUESTED: ...

NEXT: ...

NEXT-PHASE: ...

===/HANDOFF===

Для ревью используется отдельный verdict:

===VERDICT===

REVIEW-VERDICT: APPROVED | APPROVED-WITH-AMENDMENTS | REQUESTS-REWORK

AMENDMENTS: ...

===/VERDICT===

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

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

Почему не строгий контракт на весь обмен

Логичный вопрос: почему не сделать полноценный строгий контракт — JSON-схему, typed events, набор обязательных моделей — и не заставить агентов общаться только через него.

Полная типизация всего обмена слишком рано фиксирует границы процесса. В BI-задаче передаётся не только статус. Нужно объяснить, почему KPI трактуется именно так, какие данные вызывают сомнение, где есть риск по источнику, какие замечания критичны, а какие можно принять как amendments.

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

Поэтому контракт разделён на два слоя.

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

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

Такой компромисс оказался практичнее полного typed contract:

процесс ещё менялся, и жёсткая схема быстро фиксировала бы неудачные границы;
ревью требует пояснений, которые редко укладываются в короткий enum;
следующему агенту нужен контекст, а не только команда;
человеку нужен читаемый журнал задачи;
управляющая часть остаётся строгой там, где это действительно влияет на state machine.

Чтобы гарантировать, что агент выдаст итоговый результат с handoff, реализован дополнительный post-hook, который заставляет агента повторно отправить свой ответ в корректном формате. Обычно модели со второго раза справляются с этой задачи, если не хватило инструкций в роли чтобы справиться с первой попытки.

Маршрутизация детерминирована, но решения за агентами

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

BUILD-COMPLETE

READY-FOR-REVIEW

REVIEW-DONE

Такие статусы возвращают управление координатору. Координатор решает, что делать дальше: открыть ревью, принять результат, вернуть на доработку или передать задачу к следующей фазе.

Практический вывод: handoff должен содержать не только адресата, но и тип события. Статус важнее свободной инструкции о следующем шаге.

Жизненный цикл - в коде

BI-задача проходит через конечный набор состояний:

→ новая задача

→ в работе

→ на ревью

→ на доработке

→ снова на ревью

→ готово

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

Поэтому состояние задачи читается кодом перед запуском координатора. Координатор получает не длинную историю обсуждения, а конкретный следующий шаг:

разобрать бриф

открыть ревью

обработать замечания

вернуть на доработку

принять результат

смерджить артефакт

Практический вывод: промпт задаёт специализацию агента и контекст. Жизненный цикл живёт в коде.

Агентам нужны примитивы, а не полная свобода действий

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

Поэтому действия сведены к runtime-примитивам:

оставить комментарий;
изменить статус;
открыть blocker;
создать ревью;
передать задачу дальше;
вернуть на доработку;
отметить применённые amendments;
смерджить результат.

Для разных ролей доступны разные действия. Координатор управляет процессом, но не меняет рабочие артефакты. Builder собирает результат, но не принимает его за reviewer. Reviewer проверяет и выносит вердикт, но не меняет исполнителя. Отдельно важна идемпотентность. Повторный запуск не должен создавать второе ревью, повторно отправлять тот же verdict или делать повторный merge.

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

Ревью лучше вынести в отдельную задачу

Когда ревью остаётся в той же ленте, контекст быстро загрязняется. В одном месте оказываются исходная постановка, артефакт, замечания, ответы, исправления и повторная проверка. В рабочей схеме ревью оформляется как отдельная child-задача. В ней есть только контекст проверки: какой артефакт проверяется, из какой ветки читать, какой verdict нужно вынести. После завершения ревью управление возвращается в основную задачу. Координатор принимает решение: принять результат, отправить точечные amendments или вернуть на rework.

Практический вывод: ревью должно быть отдельным объектом процесса. Так проще удерживать состояние и не раздувать основной контекст.

Общие знания нужно делить на зоны ответственности

BI-задача создаёт общий артефакт: описание KPI, структуру датасета, логику дашборда, замечания ревью. Если несколько агентов пишут в один файл без ограничений, решения начинают конфликтовать. Поэтому в данном случае использовался механизм section-locking: читать можно всё, писать — только в свою секцию.

Например:

scoping отвечает за KPI и границы задачи;
data-steward — за замечания по данным;
dataset-architect — за структуру решения;
dashboard-designer — за логику представления;
builder — за техническую сборку;
reviewer — за verdict и замечания.

BI нельзя проверять только через API

Для части работы достаточно SQL, REST API и git. Можно проверить, что запрос выполняется, датасет создан, чарт сохранён, дашборд обновлён. Но BI — визуальный продукт. API может вернуть корректный ответ, а дашборд при этом выдаёт ошибки или выглядит непрофессионально: нечитаемые подписи, неудачный тип графика, визуальный шум, не эргономичная компоновка.

Поэтому для проверки чартов и дашборда подключены browser-инструменты. Агент может не только открыть Superset и посмотреть на результат в интерфейсе, но и проанализировать информацию в devtools, и даже найти проблемы на уровне кода веб-страницы, что особенно полезно при работе с несовершенным API Superset.

Что уже работает

Система проходит полный цикл по BI-задаче: от входного запроса до готового дашборда. Покрыты не только прямые сценарии, но и обратные ветки:

amendments
rework
deviation
missing KPI
переход к следующей фазе

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

Планы по развитию

Следующий этап развития — работа с входным брифом и составление спецификации. Чем точнее на входе описаны KPI, источники, границы задачи и ожидаемый результат, тем устойчивее проходит весь цикл. Если постановка расплывчатая, ошибка возникает ещё до сборки: можно неверно понять KPI, пропустить scoping или передать дальше слабо проработанную задачу. Поэтому отдельным этапом нужен manager gate перед координатором. Его задача — проверить бриф до запуска основного цикла: достаточно ли описаны KPI, понятны ли источники, есть ли ограничения, можно ли уже передавать задачу в исполнение или сначала нужно задать уточняющие вопросы.

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

Ну и третье – дальнейшее совершенствование самого процесса работы команды за счёт постоянных прогонов на тестовых и реальным задачах.

Технический вывод

Мультиагентная BI-команда работает не за счёт количества агентов. Рабочей её делает инженерная обвязка:

задачи можно назначать агентам как исполнителям;
handoff фиксирует переход состояния;
terminal status возвращает управление координатору;
жизненный цикл задачи хранится в коде;
координатор получает конкретный следующий шаг;
действия агентов ограничены runtime-примитивами;
роли разделяют постановку, исполнение и ревью;
операции сделаны идемпотентными;
ревью вынесено в отдельную child-задачу;
общие знания разделены на зоны ответственности;
результат в Superset проверяется через браузер.
типовые задачи вынесены в runtime-примитивы

Главная граница между демо и рабочей системой проходит именно здесь. Модель может сгенерировать SQL, код или конфигурацию. Но воспроизводимый процесс появляется только после протокола, состояния, маршрутизации, ограничений и проверяемых действий.

Технический эпилог

Стек

Платформа задач: multica, open-source task-management платформа, доработанная под многоагентный BI-цикл. Стек: Go backend, Next.js frontend, PostgreSQL.
Агентский runtime: Hermes. Один контейнер на агента, отдельный role prompt, набор skills, рабочий контекст, разрешённые runtime-примитивы и ограничения по действиям.
LLM-провайдеры: chatgpt, ollama cloud
BI-система: Apache Superset 6x.
Источник данных: PostgreSQL.

Что доработано в multica

Поверх базовой multica добавлены доработки вокруг lifecycle задачи.

Pre‑wake обработчик. Перед запуском агента читает состояние issue: статус, последние HANDOFF/VERDICT, дочерние review‑задачи, служебные маркеры. На основе этого формирует для координатора конкретный следующий шаг: открыть ревью, обработать amendments, вернуть на rework, продолжить цепочку или завершить задачу.
Post‑comment обработчик. Срабатывает после комментария агента. Парсит HANDOFF, определяет следующий шаг, маршрутизирует задачу и проверяет соблюдение протокола.
Status‑driven routing. Для терминальных статусов управление возвращается координатору независимо от того, что агент написал в NEXT. Это защищает процесс от ошибок в адресации следующего исполнителя.
Protocol guards. Обработчик отслеживает комментарии без обязательного HANDOFF, обход notify‑механизма и некорректные переходы между work‑issue и review‑issue.
Исходящие уведомления. Используются для Telegram‑моста: пользователь получает уведомления о важных статусах без участия LLM в доставке.

Skills

Используются skills для:

определения и уточнения метрик;
проектирования SQL-view;
стандартов SQL;
работы с Superset API;
типовых ошибок и найденных обходных решений;
правил оформления артефактов;
правил ревью.

Важный принцип: исполнитель и ревьюер работают на общей базе skills.

Hermes

Hermes выбран как готовый персональный помощник, который можно переиспользовать как runtime для агентов с прицелом на будущее развитие проекта. В описании проекта Hermes прямо акцентируется learning loop: агент создаёт skills из опыта, улучшает их в процессе использования, ищет прошлые разговоры и строит модель пользователя между сессиями. В BI-команде это может быть полезно как основа для эволюции ролей: scoping, data-steward, chart-builder или dashboard-reviewer могут постепенно накапливать практики по метрикам, Superset, ревью и типовым ошибкам, оставаясь при этом запускаемыми runtime-агентами внутри multica.

Мультики про агентов: BI-команда на multica