17. Hermes Kanban: структурированное многоагентное управление задачами и их передача.
Предоставьте нескольким именованным профилям Hermes общую доску задач со структурированными передачами дел, повторными попытками, комментариями, восстановлением после сбоев и панелью контроля со стороны человека.
Hermes Kanban превращает многоагентную работу в настоящую доскуБольшинство «многоагентных» рабочих процессов по-прежнему остаются малозаметными.Вы просите одного агента распределить работу между субагентами. Они запускаются где-то внутри процесса. Результат возвращается в родительский контекст. Если все прошло успешно, отлично.Но в реальной жизни все гораздо сложнее.Агентам приходится ждать друг друга. Людям приходится разблокировать задачи. Рабочие процессы дают сбой. Пропадают учетные данные. Рецензенты отклоняют первые попытки. Для длительных проектов нужен журнал аудита, который сохраняется после перезапусков, повторных попыток и сжатия контекста.Для этого и создан Hermes Kanban.Это превращает многоагентную работу в стабильную систему на базе SQLite, где каждая задача, выполнение, комментарий, зависимость и передача дел становятся доступными для проверки.Вывод: Hermes Kanban — это не просто «агенты со списком задач». Это настоящий уровень координации для ИИ-помощников с именами.
Проблема невидимых субагентов
Стандартный многоагентный шаблон выглядит так:
- Родительский агент получает цель
- Родитель разбивает задачу на подзадачи
- Дочерние агенты запускаются
- Родитель ждет ответов
- Все сводится к одному последнему ответу
Это работает для коротких синхронных рассуждений.
Это приводит к сбоям, когда работа должна выполняться вне контекстного окна родительского элемента.
- Если рабочий процесс блокируется, где хранится причина блокировки?
- Если рецензент отклоняет реализацию, как следующий разработчик узнает, что пошло не так?
- Если процесс завершается сбоем, кто возвращает задачу в очередь?
- Если человек хочет проверить ход выполнения работы, куда ему смотреть?
В Hermes уже есть delegate_task для работы субагентов по принципу «разделяй и властвуй». Канбан решает другую задачу.
delegate_task — это вызов функции.
Канбан — это устойчивая рабочая очередь и конечный автомат.
Вывод: используйте delegate_task, когда родителю нужен быстрый ответ. Используйте Kanban, когда работа требует постоянства, повторных попыток, прозрачности, участия человека или нескольких ролей в течение длительного времени.
Что добавляет Hermes Kanban
Hermes Kanban предоставляет агентам общую доску, которая не привязана к конкретному чату.
Доска по умолчанию хранится по адресу:
~/.hermes/kanban.db
Новая функция поддержки нескольких досок позволяет создавать отдельные доски для каждого проекта, репозитория, клиента или домена:
hermes kanban boards create atm10-server \ --name "ATM10 Server" \ --description "Minecraft modded server ops" \ --icon 🎮 \ --switch
Дополнительные платы находятся под:
~/.hermes/kanban/boards/<slug>/kanban.db
У каждой доски есть собственная база данных, рабочие пространства, журналы и область действия диспетчера.
Это значит, что ваш «конвейер новостей с использованием искусственного интеллекта», «обслуживание серверов Minecraft», «рецензирование PR-запросов на GitHub» и «изучение потребностей клиентов» могут быть отдельными задачами, а не одним гигантским смешанным бэклогом.
Вывод: канбан теперь применим не только к нескольким агентам, но и к нескольким проектам.
Именованные профили, а не анонимные исполнители
Это ключевая ментальная модель.
Канбан-задачи назначаются профилям Hermes.
researcher writer backend-dev reviewer ops
Когда диспетчер получает готовое задание, он запускает назначенный профиль как полноценный рабочий процесс.
У этого работника есть собственная личность, память, навыки, набор инструментов, журналы и рабочий контекст.
Это сильно отличается от анонимного вызова субагента.
hermes kanban create "Research new open-weight model releases" \ --assignee researcher \ --tenant ai-news
Теперь за эту задачу отвечает профиль исследователя. Если задача блокируется, происходит сбой или выполняется повторная попытка, доска фиксирует произошедшее.
Вывод: Hermes Kanban координирует работу постоянных именованных агентов, а не одноразовых скрытых вызовов.
Новая модель платы
В Hermes Kanban появилась более понятная модель доски:
Доска: одна изолированная очередь, обычно по одной на проект или домен
Задача: единица работы с заголовком, описанием, исполнителем, приоритетом, клиентом и статусом
Ссылка: зависимость между задачами «родитель — потомок»
Комментарий: примечания от человека или агента
Выполнить: одна попытка выполнения задачи одним работником
Рабочее пространство: где работает сотрудник
Диспетчер: цикл, который продвигает и утверждает готовые работы
triage todo ready running blocked done archived
Это обеспечивает полноценный рабочий процесс.
- Сырые идеи могут лежать в триаде.
- Задачи, ожидающие выполнения зависимостей, остаются в разделе todo.
- Выполняемые задачи перемещаются в готовность.
- Заявленные задачи становятся выполняемыми.
- Задачи, требующие участия человека, переходят в категорию заблокированы.
- Выполненные задачи перемещаются в раздел выполнено.
- Старые задачи можно заархивировать.
Вывод: Канбан предоставляет агентам общий механизм управления состоянием, а не просто список подсказок.
Диспетчер теперь живет в шлюзе
Одно из самых важных операционных обновлений: диспетчер по умолчанию работает внутри шлюза Hermes.
hermes gateway start
Затем встроенный диспетчер Kanban по умолчанию просыпается каждые 60 секунд и:
- Возвращает устаревшие претензии
- Обнаруживает вышедших из строя работников
- Продвигает задачи, удовлетворяющие требованиям зависимости
- Утверждает, что готовые задачи выполняются атомарно
- Создает назначенный профиль
- Прикрепляет рабочего к нужной доске
Конфигурация выглядит следующим образом:
kanban: dispatch_in_gateway: true dispatch_interval_seconds: 60
Старый автономный путь к демону существует только как устаревший запасной вариант:
hermes kanban daemon --force
Но предполагаемый путь прост: запускаем шлюз, пусть он выполняет диспетчеризацию.
Вывод: Kanban теперь является частью стандартной среды выполнения Hermes. Большинству пользователей не потребуется отдельный демон.
Люди используют интерфейс командной строки, команды со слэшем и дашборд
Теперь у пользователя есть три способа взаимодействия с доской.
hermes kanban list hermes kanban show t_abc hermes kanban comment t_abc "Need to check the source link" hermes kanban unblock t_abc hermes kanban stats
2. Команда Slash в Hermes Agent
В чате можно использовать ту же поверхность:
/kanban list /kanban show t_abc /kanban create "Draft AI recap" --assignee writer /kanban unblock t_abc /kanban boards list /kanban --board atm10-server list
Полезное обновление: команда /kanban create может автоматически подписывать исходный чат на события терминала, связанные с новой задачей, чтобы вы получали уведомления о ее завершении, блокировке, сбое, зависании или истечении времени ожидания.
На панели управления Hermes появился плагин Kanban.
hermes dashboard
Затем откройте вкладку «Канбан».
- Столбцы для отображения состояния задачи
- Переключатель платы
- Ящик для карточек с историей запуска
- Комментарии
- Родительские и дочерние ссылки
- Фильтры для поиска, арендатора и исполнителя
- Вид «Полосы по профилям»
- Кнопка «Нажатие диспетчера»
- Изменение статуса при перетаскивании
- Текущие обновления от событий задачи
Вывод: люди могут контролировать работу нескольких агентов, не просматривая логи и не дожидаясь окончательного ответа.
Рабочие не раскошеливаются
Это небольшое, но важное обновление.
hermes kanban ...
Когда диспетчер запускает рабочего, он устанавливает следующие параметры:
HERMES_KANBAN_TASK=<task_id> HERMES_KANBAN_BOARD=<board_slug>
Эта среда позволяет использовать специальный набор инструментов kanban_* в схеме модели рабочего процесса:
kanban_show kanban_complete kanban_block kanban_heartbeat kanban_comment kanban_create kanban_link
Итак, рабочий начинает с того, что звонит:
kanban_show()
hermes kanban show t_abc
Это важно, поскольку серверная часть терминала рабочего может быть локальной, работать на Docker, SSH, Modal, Singularity или на чем-то еще. Инструменты Kanban запускаются в собственном процессе Python агента и используют тот же уровень kanban_db, что и интерфейс командной строки и панель управления.
В обычных сессиях Hermes эти инструменты не используются. Инструменты kanban_* появляются только при наличии параметра HERMES_KANBAN_TASK.
Никаких задач по Канбан, никаких раздутых схем Канбан.
Вывод: сотрудники, использующие канбан-методологию, взаимодействуют с помощью защищенных вызовов инструментов, а не команд оболочки.
Зависимости становятся автоматическим продвижением
Задачи можно объединять в пайплайны:
SCHEMA=$(hermes kanban create "Design auth schema" \ --assignee backend-dev \ --json | jq -r .id) API=$(hermes kanban create "Implement auth API endpoints" \ --assignee backend-dev \ --parent $SCHEMA \ --json | jq -r .id) hermes kanban create "Write auth integration tests" \ --assignee qa-dev \ --parent $API
Только первое задание начинается с отметки «Готово».
Задача API ожидает завершения задачи по созданию схемы.
Тесты выполняются до завершения задачи API.
Когда родительский элемент завершает работу, механизм зависимостей переводит подходящие дочерние элементы из категории «в работе» в категорию «готово».
Это позволяет создавать настоящие конвейеры для агентов:
спецификатор → исполнитель → рецензент → автор → издатель
Вывод: канбан позволяет организовать последовательность действий с участием нескольких агентов, не заставляя главного агента контролировать каждый шаг.
История повторных попыток — это высший класс
Настоящая работа часто не получается с первого раза.
- Рабочий процесс может быть заблокирован из-за отсутствия учетных данных.
- Рецензент может отклонить предложенную реализацию.
- Процесс может завершиться аварийно.
В системе Hermes Kanban каждая попытка сохраняется в виде отдельной строки.
Run 1: blocked Run 2: completed
Run 1: spawn_failed Run 2: spawn_failed Run 3: gave_up
Run 1: crashed Run 2: completed
При повторной попытке выполнения задачи следующий исполнитель видит предыдущие попытки в контексте текущей.
Это значит, что он не повторяет вслепую один и тот же неудачный путь.
kanban_block(
reason="Review: password strength check missing, reset link can be replayed"
)
После того как человек разблокирует его:
hermes kanban unblock t_abc
При следующем запуске система видит причину предыдущего сбоя и точно знает, что нужно исправить.
Вывод: в канбан-методе повторные попытки зависят от состояния системы. Вторая попытка учитывает ошибки первой.
Восстановление после сбоев и автоматические выключатели
Диспетчер также занимается устранением серьезных сбоев в работе.
Если рабочий процесс завершается, диспетчер может обнаружить его идентификатор, освободить заявку и вернуть задачу в состояние готовности.
Если задача не запускается несколько раз подряд, диспетчер в конце концов прекращает попытки и автоматически блокирует ее с указанием последней ошибки. Это важно в случае отсутствия учетных данных, поврежденных профилей, некорректных рабочих пространств или недоступных инструментов.
Вместо бесконечного беззвучного воспроизведения на доске появляется сообщение:
spawn_failed spawn_failed gave_up
А уведомление от шлюза может сообщить вам, что задача не выполнена.
Вывод: в Hermes Kanban сбой рассматривается как состояние системы, а не как невидимая ошибка, возникающая во время выполнения.
Поддержка нескольких плат меняет масштаб
Последние обновления плат имеют большое значение, поскольку серьезные агенты редко работают над одним проектом.
Возможно, вам понадобится что-то вроде этого:
default ai-news github-review local-llm-wiki home-ops client-research
Каждой доской можно управлять отдельно:
hermes kanban boards list hermes kanban boards create ai-news --switch hermes kanban --board github-review list hermes kanban boards switch local-llm-wiki
Порядок принятия решения Правлением таков:
Рабочие процессы привязаны к своей доске с помощью переменных среды, поэтому они не могут случайно прочитать задачи с другой доски.
Арендаторы по-прежнему существуют внутри доменов как более мягкое пространство имен, но домены — это реальная граница изоляции.
Вывод: доски нужны для разделения проектов. Домены — это фильтры внутри доски.
Практическая установка
Простой рабочий процесс по методу Канбан:
# Initialize the board hermes kanban init # Start the gateway, which hosts the dispatcher hermes gateway start # Create work hermes kanban create "Research AI funding landscape" \ --assignee researcher # Watch live events hermes kanban watch # Inspect state hermes kanban list hermes kanban stats
Для доски по конкретному проекту:
hermes kanban boards create ai-news \ --name "AI News Pipeline" \ --description "Daily research, writing, and publishing workflow" \ --switch hermes kanban create "Collect official AI announcements" \ --assignee researcher \ --tenant daily-recap hermes kanban create "Draft X article from research" \ --assignee writer \ --tenant daily-recap
/kanban boards list /kanban create "Check blocked ops tasks" --assignee ops /kanban list --mine /kanban unblock t_abc
Вывод: вы можете запускать Hermes Kanban из терминала, панели управления, чата, скриптов, cron или из самих агентов.
Где это становится мощным
Канбан особенно полезен, когда рабочий процесс имеет одну из следующих форм:
Несколько исследователей параллельно собирают источники. Аналитик обобщает данные. Автор пишет черновик. Рецензент проверяет утверждения.
Менеджер проекта пишет спецификацию. Разработчик реализует ее. QA пишет тесты. Рецензент проверяет различия. Оператор развертывает.
3. Участие человека в процессе
Рабочий процесс блокируется, когда требуется подтверждение, одобрение или принятие решения. Вы комментируете или разблокируете чат.
Один специалист выполняет множество схожих задач: расшифровку аудиозаписей, переводы, составление описаний товаров, сортировку проблем, проверку аккаунтов.
Cron создает повторяющиеся задачи в Канбан-доске с ключами идемпотентности. Доска становится надежным операционным журналом.
Названные профили, такие как «сортировка входящих», «исследователь», «проверка операций» или «администратор вики», накапливают данные и со временем обрабатывают повторяющиеся задачи.
Вывод: канбан лучше всего работает, когда у работы есть память, состояние, повторные попытки, контроль и ролевые границы.
Заключение
Hermes Kanban — это тот момент, когда многоагентная работа перестает быть скрытым трюком и начинает восприниматься как операционная система.
Доска предоставляет каждой задаче свое место. Диспетчер дает каждому исполнителю возможность начать работу. Структурированная передача задач обеспечивает каждый последующий агент необходимым контекстом. История выполнения позволяет анализировать сбои, а не гадать, в чем причина. Панель управления, интерфейс командной строки и команда /kanban дают людям реальные возможности управления.
Hermes Kanban делает работу агентов видимой, устойчивой и управляемой, а это именно то, что нужно мультиагентным системам, если они хотят перейти от демонстрационных версий к полноценному использованию.
Главный вывод: будущее агентов — это не только более совершенные модели. Это улучшенная инфраструктура для распределения задач, сохранения контекста, восстановления после сбоев и обеспечения вовлеченности человека.