🧭 Kanban-доска в Hermes Agent как я собрал управляемую команду агентов.

Три уровня multi-agent-работы, пять созданных профилей и реальная исследовательская задача, прошедшая весь путь от Ready до Done

Как я собирал multi-agent workflow на Windows: профили, dispatcher, heartbeat, workspace и первый живой прогон t_9a60e2a9

Коротко о результатеЯ не стал запускать сразу семь агентов. Сначала закрепил оркестратора, добавил специалистов и проверил передачу задачи на реальном кейсе.В Hermes есть три уровня работы с агентами: одноразовый субагент через delegate_task, ручное переключение профилей и автоматическая раздача задач через Kanban.Задача t_9a60e2a9 ушла к @gza, отработала за 11 минут и вернула memo примерно на 1,8 тысячи слов с 19 релевантными видео и проверенными цитатами.Очередь запускает только готовые и назначенные задачи. Параллельность ограничивает delegation.max_concurrent_children, по умолчанию одновременно работают 2–3 воркера.Два практических ограничения всплыли сразу: web_search и web_extract оказались выдуманными именами скиллов, а поле SKILLS нельзя править в интерфейсе задачи.

Hermes Agent у меня уже был установлен и проверен от начала до конца: версия v0.20.0, Node 22.11.0, npm 10.9.0, вход в Nous Portal, автозапуск через Task Scheduler. На бумаге следующий шаг выглядел просто: создать несколько специализированных профилей и раздать им роли. Но реальная боль начинается не в момент создания профиля. Она начинается, когда задач становится больше одной.

Нужно понимать, что произойдёт после нажатия «создать». Задача стартует сразу или останется ждать? Если в очереди пять карточек, они пойдут одна за другой или все одновременно? Надо ли вручную толкать диспетчер? Где хранится результат? Что случится с контекстом воркера после завершения?

В переписке я сформулировал это без аккуратной терминологии, но по сути точно:

«И если у меня несколько задач на целая оркестра, я готов к работе их накидывая, накидывая, накидываю, накидываю. А она будет первая ушла, я пока вторую заполняю, потом вторая ушла. Или как?»

Именно здесь Kanban перестаёт быть красивой доской со стикерами. В Hermes это операционный слой между человеком, очередью и специализированными агентами.

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

Главный вопрос для меня был не «сколько агентов можно создать», а «можно ли доказать один полный handoff без ручной имитации результата». Такой тест состоялся на задаче t_9a60e2a9.

До него архитектура была планом. После него появился работающий пайплайн с живым исследованием, сохранёнными файлами и переходом карточки в Done.

Что такое Hermes и зачем ему профили

У меня была типичная боль человека, который уже наигрался с одиночными LLM-агентами.

Один агент — удобно.

Один чат — быстро.

Один контекст — понятно.

Но как только задач становится больше, всё начинает ехать.

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

В рамках этого проекта Hermes Agent используется как среда для работы с несколькими специализированными профилями на одном Windows-ПК.

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

Центральный профиль default, он же RZA, общается со мной, маршрутизирует работу и контролирует approvals. Остальные профили получают более узкую специализацию: исследование, программирование, настройка самого Hermes, редактура, аналитика соцсетей или Windows-инфраструктура.

Профиль здесь нужен не ради нового имени в интерфейсе. Он связывает конкретный тип задачи с заранее определённой ролью.

Если нужен глубокий поиск по вебу и документам, задача назначается @gza. Если нужен скрипт, исправление бага или code review, работа уходит @masta-killa. Финальную вычитку должен выполнять @ghostface. За счёт этого оркестратор не пытается одинаково делать всё подряд.

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

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

В исходном ТЗ правило звучало прямо:

«Токены субагентам не отдаём, никаких выдумок в отчётах, без агрессивной автоматизации (только opt-in), multi-agent работа — opt-in (я сам тестирую каждый handoff)».

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

More agents does not make the system better. In most cases they just create more places where things can go wrong.Источник: Pavel, «Multi-Agent Hermes System», Teletype, 3 августа 2026 года

И второе правило, которое задаёт порядок развёртывания:

Start with an orchestrator, add one specialist, prove the handoff, and only then expand.Источник: @NeoAIForecast

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

Method Man и Raekwon остаются в плане до появления задач, которые действительно требуют отдельной специализации.

Архитектура: три уровня multi-agent в Hermes

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

Уровень 1. Субагент через delegate_task

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

Это самый короткий путь к делегированию. Он не требует построения отдельного Kanban-процесса. Но он же хуже подходит для набора задач с разными исполнителями, зависимостями и артефактами, которые должны пережить один диалог.

Уровень 2. Ручное переключение профилей

На втором уровне я сам выбираю профиль в Hermes Desktop. Например, переключаюсь на gza для исследования или на masta-killa для работы с кодом. Здесь специализация уже постоянная, но решение о запуске и переключении остаётся у человека.

Этот режим полезен при настройке нового профиля. Можно проверить его роль, инструкции и поведение без автоматического диспетчера. Именно такой подход соответствует правилу «сам тестирую каждый handoff». Сначала профиль должен показать ожидаемый результат в контролируемом сценарии, и только потом его имеет смысл подключать к очереди.

Уровень 3. Kanban-доска

Третий уровень добавляет автоматическую диспетчеризацию. Я создаю карточку, назначаю исполнителя, при необходимости задаю время старта или родительскую зависимость. Дальше диспетчер проверяет, готова ли задача, забирает её в очередь и запускает соответствующего воркера.

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

Три уровня дают практическую лестницу внедрения. Одноразовую работу можно передать через delegate_task. Новый профиль сначала проверить вручную. Повторяемые или зависимые задачи перевести на Kanban только после успешного handoff. Такая последовательность сохраняет управление у человека и не заставляет использовать автоматизацию там, где достаточно одного вызова.

6. Kanban: колонки, lifecycle, heartbeat, workspace и concurrency

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

Сортировка, или Triage

Triage хранит сырые идеи и неконкретные задачи. Карточку можно положить туда через +, но диспетчер её не забирает. Никакого автоматического запуска не происходит. Это входящий список, где мысль можно зафиксировать до появления нормального задания, исполнителя и условий готовности.

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

К выполнению, или Todo

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

Когда блокировка исчезает, карточка может перейти в Ready. Этот статус особенно важен для цепочек. Например, подготовку промпта для статьи нельзя начинать до завершения исследования, если второй этап использует артефакты первого.

Запланировано, или Scheduled

Scheduled удерживает задачу до конкретного времени. В исходной переписке приведена команда hermes kanban schedule "..." --at 2026-08-05T09:00. Для повторяющейся задачи указан вариант с --repeat daily, а для утреннего запуска в 09:00 приведена комбинация --repeat daily --at 09:00.

Этот статус отвечает на вопрос «как создать карточку сейчас, но не запускать сразу». До времени X она просто ждёт. В назначенный момент её забирает диспетчер. Важно не путать Scheduled с Todo: первая карточка ждёт времени, вторая ждёт исполнителя или снятия зависимости.

Готово к работе, или Ready

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

Ready не гарантирует одновременный старт всех карточек. Это допуск в очередь, а не команда открыть неограниченное число процессов.

В работе, или In Progress

In Progress означает, что диспетчер сделал claim задачи и воркер уже запущен. Статус обновляется автоматически. После завершения воркер переводит задачу в Done. Для немедленного визуального обновления доски можно нажать F5 или «Обновить».

Heartbeat в этом сценарии приходит примерно раз в 60 секунд. Он показывает, что воркер продолжает работать, а диспетчер может обновлять состояние карточки. Это также объясняет, почему интерфейс не всегда меняется в ту же миллисекунду, когда завершился внутренний шаг. Mavis описала это так:

«Сама. Worker шлёт heartbeat каждые ~60 сек, dispatcher обновляет статус. Жми F5 / „Обновить“, если хочется сразу увидеть».

Done и полный lifecycle

Успешный путь карточки выглядит так: Ready, claim диспетчером, In Progress, работа воркера, сохранение результата, Done. Возможны и другие входы. Сырая идея сначала живёт в Triage. Заблокированная задача ждёт в Todo. Задача по времени начинает путь из Scheduled.

Если речь идёт о контексте активного воркера, отдельной кнопки clear context у карточки нет.

По переписке контекст очищается после перехода в Done.

Для принудительного прекращения используется hermes kanban cancel <id>.

Это отличается от текущего чата Mavis, где чистый контекст создаётся через New chat или +.

Workspace и артефакты

Workspace нужен не для красивого статуса, а для файлов, которые останутся после выполнения. В реальном тесте memo было сохранено в D:\AI\hermes-kanban\kanban\attachments\t_9a60e2a9\memo.md.

Второй экземпляр появился в памяти профиля: C:\Users\vin-m\AppData\Local\hermes\profiles\gza\memories\tonbis-garage-hermes-agents.md.

Это важное разделение. Карточка отвечает на вопрос «что сейчас происходит», а файл отвечает на вопрос «что именно сделано». Summary в интерфейсе удобно читать, но исходный memo остаётся проверяемым артефактом для следующего агента или человека.

Concurrency и очередь

Concurrency задаёт, сколько дочерних задач могут выполняться одновременно. В текущей конфигурации по умолчанию это 2–3 параллельных воркера, параметр называется delegation.max_concurrent_children.

Если положить пять карточек в Ready, диспетчер запустит первые 2–3. Остальные останутся ждать свободного слота. Как только одна активная задача завершится, следующая сможет стартовать. Поэтому Ready можно наполнять заранее, не ожидая, что все карточки одновременно нагрузят систему.

Такой лимит делает поведение очереди предсказуемым. Он не определяет качество ответа и не отменяет зависимостей. Он только ограничивает число активных дочерних исполнителей.

Живой пример: t_9a60e2a9

Карточка t_9a60e2a9 была назначена профилю @gza и оказалась в In Progress. Задача состояла в исследовании материалов канала @TonbisAIGarage о Hermes Agent, multi-agent-системах и агентах.

Дальше пайплайн прошёл полный цикл. Диспетчер забрал карточку. Воркер @gza поднялся и выполнил исследование.

Через 11 минут задача получила статус completed. Результат сохранился в workspace и продублировался в memories профиля.

Summary воркера:

«Нашёл 19 релевантных видео на @TonbisAIGarage про Hermes Agent / multi-agent / агентов (период май–август 2026), для каждого дал тему, ключевую идею и релевантные таймкоды из описания. Memo на ~1.8K слов сохранено в workspace и продублировано в memories gza. Все 20 источников зарегистрированы в citations ledger и inline-процитированы (coverage 86%, citations OK)».

В этом примере важен не только объём результата.

Система вернула конкретные файлы, зарегистрировала 20 источников, добавила inline-цитирование и зафиксировала coverage 86%. Задача не зависла в In Progress и не потребовала ручного перевода в Done.

Это и стало end-to-end-подтверждением Kanban-пайплайна.

7. Wu-Tang-профили: роли без путаницы

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

• RZA, профиль default: оркестратор, общение со мной, роутинг задач и approvals. Это центральная точка системы.
• GZA, профиль gza: глубокие исследования по вебу и документам, литературные обзоры. Именно этот профиль выполнил t_9a60e2a9.
• Masta Killa, профиль masta-killa: обычное программирование, скрипты, исправление багов и code review.
• Inspectah Deck, профиль inspectah-deck: работа над самим Hermes, включая skills, profiles и prompts.
• Ghostface, профиль ghostface: редактура и TRT, copy-edit и финальная вычитка материалов.
• Method Man: аналитика X/Twitter и контент-стратегия. Профиль пока не развёрнут, он появится после реальной задачи соответствующего типа.
• Raekwon: Windows-рантайм и инфраструктура, gateways, cron, tunnels и MCP. Этот профиль также оставлен на потом.

Фактический набор созданных профилей: default, gza, masta-killa, inspectah-deck, ghostface. Это важно проговорить отдельно, потому что архитектура на семь ролей и работающая система из пяти профилей являются разными состояниями проекта.

Порядок добавления тоже зафиксирован.

Сначала закрепляется RZA через SOUL.md и материалы команды. Затем добавляются GZA и Masta Killa.

После них подключаются Inspectah Deck и Ghostface. Method Man и Raekwon не создаются ради полноты списка. Для каждого нового профиля сначала нужна задача, затем проверяемый handoff.

8. Что пошло не так

Первый сбой был связан с названиями инструментов. В задачу попали web_search и web_extract, но таких скиллов в реестре не существовало. Воркер из-за этого падал дважды.

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

Практический вывод из самой сессии: перед передачей задачи нужно проверять реестр доступных инструментов и использовать точные идентификаторы. Если точная CLI-команда или имя скилла в источнике не указаны, их нельзя дописывать «по смыслу».

Это напрямую связано с исходным ограничением проекта:

«Никаких выдумок в отчётах».

Второе ограничение обнаружилось в интерфейсе Kanban. Поле SKILLS у уже созданной задачи нельзя редактировать через UI.

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

Оба случая показывают одно и то же: визуальная доска не отменяет проверки реального runtime. Название скилла должно существовать, а возможность редактирования поля должна быть подтверждена интерфейсом или CLI.

9. Что получилось

К концу этапа собрана рабочая база из пяти профилей: default, gza, masta-killa, inspectah-deck, ghostface.

Оркестратор RZA закреплён через SOUL.md, team-agents.md, MEMORY.md и USER.md.

Kanban использует базу D:\AI\hermes-kanban\kanban.db. Gateway автоматически запускается при входе в Windows через fallback в папке Startup.

Локальный дашборд доступен по адресу http://localhost:9119.

Проверены два сценария.

Сначала gza прошёл smoke-тест на исследовательской задаче по Teletype multi-agent. Затем реальная карточка t_9a60e2a9 проанализировала материалы @TonbisAIGarage и вернула memo примерно на 1,8 тысячи слов.

Главный результат этапа: появился не просто набор профилей, а доказанный путь задачи. Карточка попала в Ready, диспетчер сделал claim, воркер выполнил исследование, материалы сохранились в attachments и memories, после чего задача завершилась. Артефакты можно открыть, проверить и передать следующему исполнителю.

10. Следующие шаги

Следующий этап строится как цепочка зависимостей.

Вторую задачу должен выполнить masta-killa; её parent равен t_9a60e2a9. Результатом должен стать промпт для Notion на основе завершённого исследования. Третья задача предназначена ghostface, её parent будет указывать на второй этап. Она отвечает за редактуру финального драфта.

Отдельно остаётся технический шаг: добавить VBS-скрипт в Startup для автозапуска дашборда.

Method Man и Raekwon будут добавлены позже. Условие уже определено: должна появиться реальная повторяющаяся задача по X/Twitter или по Windows-инфраструктуре. До этого создавать два дополнительных профиля смысла нет, потому что их handoff невозможно проверить на настоящем рабочем материале.

11. Заключение

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

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

CTA: если строишь свою систему на Hermes, возьми одну реальную задачу, назначь одного специалиста и проверь четыре вещи: переход в Done, сохранённый артефакт, корректные источники и передачу результата следующему профилю.

12. Приложение: словарь и ссылки

Короткий словарь

• Assignee: профиль, назначенный исполнителем карточки.
• Parent: родительская задача. Пока она не завершена, зависимая карточка остаётся заблокированной.
• Claim: момент, когда диспетчер забирает готовую карточку и закрепляет её за воркером.
• Dispatcher: компонент, который отслеживает готовые карточки, очередь, расписание и доступные слоты параллельного выполнения.
• Worker: запущенный исполнитель задачи, связанный с назначенным профилем.
• Heartbeat: периодический сигнал активного воркера. В описанном сценарии он отправляется примерно раз в 60 секунд.
• Workspace: место, где сохраняются файлы и другие артефакты задачи.
• Citations ledger: реестр источников, использованных в исследовании. Для t_9a60e2a9 зарегистрировано 20 источников.
• Smoke-тест: короткая проверка, что основной маршрут вообще работает до запуска полноценной задачи.
• Triage / Todo / Scheduled / Ready / In Progress / Done: сырая идея, заблокированная задача, задача по времени, готовая очередь, активная работа и завершение.

Команды и адреса из переписки

• Запланировать запуск: hermes kanban schedule "..." --at 2026-08-05T09:00.
• Указать ежедневное повторение: --repeat daily.
• Остановить задачу: hermes kanban cancel <id>.
• Параметр параллельности: delegation.max_concurrent_children.
• Локальный дашборд: http://localhost:9119.
• База Kanban: D:\AI\hermes-kanban\kanban.db.
• Артефакт задачи: D:\AI\hermes-kanban\kanban\attachments\t_9a60e2a9\memo.md.
• Память GZA: C:\Users\vin-m\AppData\Local\hermes\profiles\gza\memories\tonbis-garage-hermes-agents.md.

Публичные ссылки

• Telegram-канал Павла: @Novopoltsev_Pavel.
• Блог Павла на Teletype: teletype.in/@rovniy_paha.