Как я использую mxBoard для работы с ИИ-агентами
Хочу поделиться рабочим сетапом для ИИ-агентов. Не теорией из презентации, а тем, что реально помогает мне каждый день не терять задачи, не раздувать контекст и не превращать разработку в бесконечный чат с моделью.
В центре схемы — mxBoard: канбан-доска для задач, где у карточки есть проект, тип, стадия, исполнитель, постановщик, комментарии, файлы и история. Поверх неё у меня работает телеграм-бот, который связывает доску с агентами Claude и Codex.
Зачем здесь доска
Главная проблема при работе с агентами — не в том, что они «не умеют». Они как раз умеют слишком многое и легко уезжают вместе с тобой в сторону.
Начинаешь с одной задачи, по дороге вспоминаешь вторую, потом третью, потом «а давай ещё вот это посмотрим». Контекст растёт, дорожает, деградирует, а в конце уже сложно понять: что мы вообще делали, что проверили и где результат.
Доска решает это грубо, но эффективно:
Как связаны проекты, топики и задачи
Телеграм-бот добавлен в группу с топиками. Каждый топик — это не просто переписка, а рабочая сессия агента: у него есть Telegram thread_id, рабочий каталог проекта, движок и модель. Один топик может быть закреплён за mxBoard, другой — за poller, третий — за конкретным сайтом или модулем.
На стороне mxBoard проект тоже соответствует реальному репозиторию. В описании проекта хранится служебная привязка: абсолютный путь к репозиторию и thread_id топика. Поллер читает список проектов через REST, строит карту «проект доски → Telegram-топик» и понимает, куда отправлять следующий ход.
Связка получается такая:
Что делает поллер
Поллер — это отдельный процесс между mxBoard и телеграм-ботом. Он смотрит события доски: движение карточек по стадиям и новые комментарии.
Важная деталь: поллер не выбирает адресата по названию стадии. Он смотрит, кто сделал ход, и будит второго участника задачи. Если ход сделал исполнитель — следующий ход за менеджером. Если ход сделал менеджер — следующий ход за исполнителем.
Это правило появилось не из любви к архитектуре. Мы уже ловили живую проблему: комментарий агента создавал новый запуск, агент отвечал комментарием, тот снова создавал запуск, и получался цикл «комментарий → job → комментарий → job». После этого роли и маршрутизацию пришлось сделать явными.
Две роли: менеджер и исполнитель
В моём сетапе на доске остались две основные агентские личности: ai-manager и ai-agent.
Менеджер — это не просто ревьюер. Его главная ценность в том, что он превращает мой поток сознания в нормальную постановку задачи. Я могу написать как думаю: кусками, с сомнениями, с «ещё вот это проверь» и «кажется, мы уже это обсуждали». Менеджер вытаскивает из этого задачу, ограничения, план, критерии проверки и передаёт исполнителю уже нормальный промт.
Исполнитель делает работу по карточке: исследует код, пишет план, ждёт разрешения, реализует, проверяет и возвращает отчёт.
Две роли удобнее, чем зоопарк пользователей. Проще разграничивать права, проще понимать, чей сейчас ход, и проще не дать агентам говорить самим с собой до тепловой смерти вселенной.
Стадии как рабочий протокол
Стадии в mxBoard — это не просто колонки. У каждой стадии есть описание, и это описание поллер передаёт агенту как инструкцию текущего этапа.
Важно: там не описан абстрактный «формат ответа». Там описано действие стадии.
Задачи типизированы: багфикс, исследование, фича, интеграция, вёрстка, контент, SEO, настройка, обновление и так далее.
У типа есть описание и набор обязательных полей. Например, для багфикса нужно указать шаги воспроизведения, фактический результат, ожидаемый результат, окружение и severity. Это сразу отсекает постановки уровня «сайт не работает, почини».
В описание типа можно положить ссылку на инструкцию по выполнению задач этого класса. Тогда агент получает не просто текст карточки, а понятный рабочий протокол.
Три режима работы
Полностью автономный
Используются очереди mxBoard. Очередь привязана к проекту, и очередей может быть сколько угодно. Независимые задачи можно выполнять параллельно: разные проекты, разные потоки, разные агенты.
Технически очередь — сущность проекта, а задача может состоять максимум в одной очереди. В очередь попадают задачи из начальной стадии. Когда задача доходит до финальной стадии, очередь автоматически запускает следующую. Менеджер в таком режиме сам принимает план, сам проверяет результат и сам закрывает карточку, если она действительно была частью очереди.
Полуавтоматический
Очереди не используются. Карточки лежат на доске, но запуск в работу происходит по моей команде через менеджера в телеграм-боте.
Это мой обычный режим для задач, где хочется сначала руками выбрать приоритет, уточнить формулировку или решить, какой агент и модель сейчас уместны.
Ручной
Агенты запущены в терминале. Один — менеджер-ревьюер, второй — исполнитель. План я обсуждаю напрямую с исполнителем, менеджер создаёт карточки и делает ревью перед закрытием.
Для такого режима хорошо подходит herdr — агентский терминальный мультиплексер. Он держит несколько агентов в отдельных терминалах, сохраняет состояние и показывает, кто работает, кто ждёт, кто закончил. Плюс звуковые уведомления: очень приятно, когда железка сама говорит «там кто-то дозрел», а ты не обновляешь терминал как биржевой стакан.
Телефон как пульт управления
Телеграм-бот даёт ещё одну практичную вещь: управлять агентами можно с телефона. Из дома, из кафе, из дороги, из любого места, где есть интернет и не блокируют Telegram. А если блокируют — ну, все знают, что делать, я же не Роскомнадзор обучать пришёл.
Если весь сетап поднят на VPS, агенты могут работать круглосуточно. Ты только ставишь задачи, принимаешь планы и смотришь результаты. Главное, чтобы токены не закончились раньше энтузиазма.
Как повторить мой сетап
Сразу предупрежу: я работаю на Ubuntu. На Windows напрямую это поднимать не советую, будет боль. Нормальный путь — Ubuntu-машина или VPS на Linux.
Минимальный набор:
Ссылки
В центре схемы — mxBoard: канбан-доска для задач, где у карточки есть проект, тип, стадия, исполнитель, постановщик, комментарии, файлы и история. Поверх неё у меня работает телеграм-бот, который связывает доску с агентами Claude и Codex.
Зачем здесь доска
Главная проблема при работе с агентами — не в том, что они «не умеют». Они как раз умеют слишком многое и легко уезжают вместе с тобой в сторону.
Начинаешь с одной задачи, по дороге вспоминаешь вторую, потом третью, потом «а давай ещё вот это посмотрим». Контекст растёт, дорожает, деградирует, а в конце уже сложно понять: что мы вообще делали, что проверили и где результат.
Доска решает это грубо, но эффективно:
- одна карточка — одна задача;
- контекст задачи хранится в карточке, а не размазывается по чату;
- комментарии и файлы остаются рядом с задачей;
- история работы видна до закрытия и после;
- агент получает только нужный контекст, а не весь поток сознания за последние три дня.
Как связаны проекты, топики и задачи
Телеграм-бот добавлен в группу с топиками. Каждый топик — это не просто переписка, а рабочая сессия агента: у него есть Telegram thread_id, рабочий каталог проекта, движок и модель. Один топик может быть закреплён за mxBoard, другой — за poller, третий — за конкретным сайтом или модулем.
На стороне mxBoard проект тоже соответствует реальному репозиторию. В описании проекта хранится служебная привязка: абсолютный путь к репозиторию и thread_id топика. Поллер читает список проектов через REST, строит карту «проект доски → Telegram-топик» и понимает, куда отправлять следующий ход.
Связка получается такая:
- проект mxBoard знает, где лежит репозиторий и какой Telegram-топик ему соответствует;
- Telegram-топик знает свой рабочий каталог, движок и модель;
- карточка mxBoard знает проект, тип задачи, стадию, автора и исполнителя;
- поллер по событию в карточке будит нужного агента в нужном топике.
Что делает поллер
Поллер — это отдельный процесс между mxBoard и телеграм-ботом. Он смотрит события доски: движение карточек по стадиям и новые комментарии.
Важная деталь: поллер не выбирает адресата по названию стадии. Он смотрит, кто сделал ход, и будит второго участника задачи. Если ход сделал исполнитель — следующий ход за менеджером. Если ход сделал менеджер — следующий ход за исполнителем.
Это правило появилось не из любви к архитектуре. Мы уже ловили живую проблему: комментарий агента создавал новый запуск, агент отвечал комментарием, тот снова создавал запуск, и получался цикл «комментарий → job → комментарий → job». После этого роли и маршрутизацию пришлось сделать явными.
Две роли: менеджер и исполнитель
В моём сетапе на доске остались две основные агентские личности: ai-manager и ai-agent.
Менеджер — это не просто ревьюер. Его главная ценность в том, что он превращает мой поток сознания в нормальную постановку задачи. Я могу написать как думаю: кусками, с сомнениями, с «ещё вот это проверь» и «кажется, мы уже это обсуждали». Менеджер вытаскивает из этого задачу, ограничения, план, критерии проверки и передаёт исполнителю уже нормальный промт.
Исполнитель делает работу по карточке: исследует код, пишет план, ждёт разрешения, реализует, проверяет и возвращает отчёт.
Две роли удобнее, чем зоопарк пользователей. Проще разграничивать права, проще понимать, чей сейчас ход, и проще не дать агентам говорить самим с собой до тепловой смерти вселенной.
Стадии как рабочий протокол
Стадии в mxBoard — это не просто колонки. У каждой стадии есть описание, и это описание поллер передаёт агенту как инструкцию текущего этапа.
Важно: там не описан абстрактный «формат ответа». Там описано действие стадии.
- Бэклог — накопитель задач. Работа не начата, карточку можно уточнять сколько угодно. Если задача не нужна — её удаляют, а не двигают в отдельную мусорную колонку.
- Старт — исполнитель пишет в карточке, что начал выполнение, изучает постановку, готовит план и переводит задачу в «План».
- План — менеджер показывает оператору краткое резюме плана и ждёт явного одобрения, если задача не в очереди. Если задача в очереди, менеджер сам оценивает план и либо запускает работу, либо возвращает замечания.
- В работе — исполнитель действует по согласованному плану, после завершения пишет отчёт в карточку и переводит её на проверку.
- На проверке — менеджер готовит резюме результата для оператора, проверяет полноту и решает, можно ли закрывать задачу.
- Готово — финальная стадия, автор принял работу, задача закрыта.
Backlog — это не очередь на выполнение. Это погреб для идей. Там задача настаивается, дозревает, обрастает деталями. В работу она идёт только когда стала похожа на задачу, а не на «сломалось что-то где-то».Типы задач
Задачи типизированы: багфикс, исследование, фича, интеграция, вёрстка, контент, SEO, настройка, обновление и так далее.
У типа есть описание и набор обязательных полей. Например, для багфикса нужно указать шаги воспроизведения, фактический результат, ожидаемый результат, окружение и severity. Это сразу отсекает постановки уровня «сайт не работает, почини».
В описание типа можно положить ссылку на инструкцию по выполнению задач этого класса. Тогда агент получает не просто текст карточки, а понятный рабочий протокол.
Три режима работы
Полностью автономный
Используются очереди mxBoard. Очередь привязана к проекту, и очередей может быть сколько угодно. Независимые задачи можно выполнять параллельно: разные проекты, разные потоки, разные агенты.
Технически очередь — сущность проекта, а задача может состоять максимум в одной очереди. В очередь попадают задачи из начальной стадии. Когда задача доходит до финальной стадии, очередь автоматически запускает следующую. Менеджер в таком режиме сам принимает план, сам проверяет результат и сам закрывает карточку, если она действительно была частью очереди.
Полуавтоматический
Очереди не используются. Карточки лежат на доске, но запуск в работу происходит по моей команде через менеджера в телеграм-боте.
Это мой обычный режим для задач, где хочется сначала руками выбрать приоритет, уточнить формулировку или решить, какой агент и модель сейчас уместны.
Ручной
Агенты запущены в терминале. Один — менеджер-ревьюер, второй — исполнитель. План я обсуждаю напрямую с исполнителем, менеджер создаёт карточки и делает ревью перед закрытием.
Для такого режима хорошо подходит herdr — агентский терминальный мультиплексер. Он держит несколько агентов в отдельных терминалах, сохраняет состояние и показывает, кто работает, кто ждёт, кто закончил. Плюс звуковые уведомления: очень приятно, когда железка сама говорит «там кто-то дозрел», а ты не обновляешь терминал как биржевой стакан.
Телефон как пульт управления
Телеграм-бот даёт ещё одну практичную вещь: управлять агентами можно с телефона. Из дома, из кафе, из дороги, из любого места, где есть интернет и не блокируют Telegram. А если блокируют — ну, все знают, что делать, я же не Роскомнадзор обучать пришёл.
Если весь сетап поднят на VPS, агенты могут работать круглосуточно. Ты только ставишь задачи, принимаешь планы и смотришь результаты. Главное, чтобы токены не закончились раньше энтузиазма.
Как повторить мой сетап
Сразу предупрежу: я работаю на Ubuntu. На Windows напрямую это поднимать не советую, будет боль. Нормальный путь — Ubuntu-машина или VPS на Linux.
Минимальный набор:
- mxBoard — доска задач, стадии, типы, очереди, REST и MCP;
- телеграм-бот — интерфейс для топиков, сессий и команд с телефона;
- jarvis-mxboard-poller — процесс, который читает события mxBoard и будит агентов;
- Claude CLI и Codex CLI — сами агенты;
- herdr — по желанию, если хочется удобно держать несколько агентов в терминале.
Ссылки
- mxBoard: https://modstore.pro/packages/ai/mxboard
- мой телеграм-бот: https://github.com/ShevArtV/jarvis
- поллер mxBoard → бот: https://github.com/ShevArtV/jarvis-mxboard-poller
- herdr: https://github.com/ogulcancelik/herdr
Комментарии: 0