Как управлять несколькими ИИ-агентами: тест Multica с Codex и Hermes

Codex пишет код. Hermes отвечает в Telegram и может сходить на сервер. Cursor открыт рядом. Пока задача одна, всё выглядит почти красиво: написал, подождал, проверил.

Потом задач становится пять.

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

В этот момент я понял, что больше не вайбкодер. Я диспетчер табуна терминалов.

Чтобы понять, как управлять несколькими ИИ-агентами без постоянного обхода вкладок, я собрал Codex и Hermes в Multica. Создал проект, отдал Codex задачу, получил декомпозицию, передал одну из подзадач Hermes и посмотрел, где эта схема начинает помогать, а где пока требует ручной проверки.

Что получилось за один тест

Коротко:

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

Умнее агенты от Multica не стали. Зато у них появилась диспетчерская.

С несколькими агентами проблема уже в процессе

Один агент ещё помещается в голове. История чата примерно заменяет трекер: сверху задача, ниже уточнения, ещё ниже результат.

С несколькими эта схема разваливается. Нужны ответы на скучные вопросы:

• кто взял задачу;
• что сейчас выполняется;
• где агент застрял;
• какой артефакт оставил;
• кто должен сделать следующий шаг;
• сколько попыток и токенов уже ушло.

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

Один агент работает как инструмент. Несколько агентов уже маленькая команда, даже если команда пока состоит из окон терминала.

Как прошёл живой тест Multica

Multica это open-source панель для совместной работы людей и coding agents. В интерфейсе у меня нашлись Hermes, Codex и Cursor. Cursor в тот момент был отключён, поэтому в живой прогон я его не записываю.

Тест выглядел так.

1. Создал проект и исходную задачу

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

2. Codex забрал задачу

На доске появился исполнитель и статус. Можно было открыть задачу и увидеть активность агента, без поиска нужной сессии среди вкладок.

3. Агент создал дочерние задачи

После работы Codex исходная задача превратилась в план с отдельными подзадачами. Здесь Multica перестала быть для меня просто красивым канбаном: результат одной агентной сессии стал частью общего процесса.

4. Одну подзадачу передал Hermes

Я назначил Hermes следующий кусок работы. Теперь в одной системе были видны проект, задачи, исполнители, статусы, комментарии и артефакты.

Никакой магии, обычная проектная бытовуха, которой ИИ-агентам как раз не хватает.

Контур, без которого панель бессмысленна

Для себя я свёл управление агентами к одной цепочке:

задача → агент → статус → артефакт → проверка → следующий шаг

Если цепочка заканчивается на слове «готово», утром всё равно придётся открывать терминал и разбираться руками.

Статус «готово» без артефакта ещё не результат. Это уведомление о том, что пора начинать проверку.

Поэтому от панели мне нужны ответы на три вопроса, анимация agent is working их не заменит:

1. Что именно изменилось?
2. Где лежит результат?
3. Кто принимает следующий шаг?

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

Где на самом деле работают агенты

Здесь легко неверно понять архитектуру.

По официальной документации на момент моего теста (июль 2026) Multica не запускала coding agents на своих серверах. Задачи исполнял локальный daemon на моей машине через установленные CLI-инструменты, облачные среды были доступны только по листу ожидания.

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

Есть облачный вариант, десктоп-клиент и установка на свой сервер. Но свой сервер сам по себе безопасности не даёт. Права на директории, секреты, MCP-инструменты и разрешения каждого агента всё равно надо настраивать отдельно.

И ещё одна граница: блок AI Context справа в моём интерфейсе я дописал сам. Туда выведены контекст, задачи и заметки, в стандартную Multica он не входит.

Что панель пока не закрыла

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

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

Мелочью это не назовёшь. Если панель показывает задачи, а фактический расход приходится сверять в Codex, Hermes и у провайдеров отдельно, единый пульт остаётся частичным.

То же относится к результатам. Агент может перевести задачу в done, но человек всё равно должен открыть артефакт, проверить diff, тесты и последствия. Multica помогает увидеть, где идёт работа. Ревью она не заменяет.

Autopilot не исправляет плохую задачу

В Multica есть Autopilot: можно создавать задачи по расписанию или по webhook. Это удобно для регулярной проверки, отчёта или реакции на событие.

Но расписание отвечает только на вопрос «когда запустить». Критерии готовности, безопасные права и понятный формат результата оно не добавляет.

Плохо поставленная задача по расписанию остаётся плохо поставленной задачей. Просто теперь она ошибается регулярно.

Как бы я запускал такую схему в реальной работе

Начинал бы с одного агента и без доступа к production.

Сначала одна безопасная задача в тестовом репозитории. После неё я бы проверил:

• какую рабочую директорию получил агент;
• какие файлы и инструменты ему доступны;
• где сохранился результат;
• что происходит при ошибке и перезапуске;
• можно ли остановить опасное действие;
• совпадает ли расход с данными провайдера;
• видит ли человек блокер без чтения полного лога;
• остаётся ли после done проверяемый артефакт.

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

Что изменилось для меня

С одним агентом я работаю через диалог. С несколькими приходится управлять процессом.

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

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

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

В видео я показываю весь тест на экране: создаю проект, отдаю задачу Codex, получаю декомпозицию и передаю часть работы Hermes. Там же видно странное поведение статистики расхода, без попытки придумать красивую причину.