Шесть агентов вместо одного: собираем инженерную команду на Hermes

Сложность: средняя

Ты думаешь, что мультиагентность - это про то, как запустить пять окошек с чатом и попросить их "работать вместе". На самом деле это про границу ответственности: у каждого агента должна быть одна работа, один артефакт на выходе и точка, где он обязан остановиться. Всё остальное - способ надёжно это сломать.

Проблема: один агент - это лейка вместо оркестра

Возьмём типовую инженерную задачу: развернуть стенд под демонстрацию продукта. Это значит: поднять виртуалки, разобрать сетевую связность, поставить ОС и сервисы, настроить доступ для заказчика, проверить, что всё переживает перезагрузку, и задокументировать, что где живёт. Или сайт: DNS, сертификаты, реверс-прокси, деплой, мониторинг. Или VPN-нода: конфиг, порты, файрвол, клиентские подписки, проверка из нескольких регионов.

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

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

При этом "мультиагентность" в 2026 году - это в основном контент-команды: боты, которые пишут посты и редакции дают "мощность целой медиакомпании". Инженеру мультиагентность нужна для другого: разложить развёртывание, диагностику и поддержку на специалистов, которые не путают друг другу карты.

Классическая практика: контракт вместо "сделай хорошо"

Мультиагентность - это не про ИИ. Это классическая организационная задача, и классическая же практика её решает: разделение ответственности и формальные контракты на стыках.

Когда я описываю роль для агента, использую тот же контракт, что и для человека в команде:

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

Второй принцип - состояние живёт в файлах, а не в переписке. Общий контекст (инвентарь стендов, шаблоны конфигов, правила безопасности, журнал инцидентов) - это хранилище markdown, которое читают все участники. Общение - только координация. Любой агент, хранящий состояние в истории сообщений, теряет его при перезапуске, и это не гипотеза, а наблюдённый факт.

Как это устроено в Hermes

Hermes Agent (Nous Research) с релиза v0.21 Pantheon даёт три слоя, ровно под три задачи из классической схемы.

`hermes profile create researcher --description "Reads source code and external docs, writes findings."`

Параметр --description не украшение: его читает канбан-оркестратор, когда решает, кому отдать задачу. Профиль становится отдельной командой CLI: researcher chat, researcher gateway start.

`hermes kanban create --title "..." --assign researcher
hermes kanban dispatch
hermes kanban request-review <task-id>`

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

Между машинами работает hermes peer - прямые сообщения между шлюзами с ключом в окружении. Для команды, разбросанной по VPS, этого достаточно.

Разложим типовую инфраструктурную задачу

Вот как роли раскладываются на три классических кейса. Скелет один, роли те же.

Роль | Владеет | Возвращает

Scout | приём запроса, выбор задачи | карточка: что, где, срочность, ограничения

Researcher | сбор фактов: инвентарь, документация, текущее состояние | пакет проверенных наблюдений со ссылками на источники

Architect | план развёртывания | бриф: план, порядок шагов, критерии приёмки

Executor | прогон шагов | результаты команд + сырой вывод

Editor | сверка результата с критериями | вердикт: принято или возврат с замечаниями

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

Цена решения: на моём хосте живёт больше десятка профилей под инженерные роли, все на бесплатных каналах (nvidia/nemotron-3-super-12 и deepseek/deepseek-v4-flash через OpenRouter). То есть эксперимент стоит ноль токенодней, если не гонять тяжёлые модели без нужды.

Где граница автономии

Первый релиз должен готовить всё и решать ничего. У меня жёсткое правило - всё, что меняет инфраструктуру или смотрит наружу, проходит через человека. Канбан это поддерживает конструктивно: request-review переводит задачу в очередь, и решение принимает человек, а не "следующий бот по цепочке".

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

Что вынести

Собирать так:

1. Опиши одну реальную инфраструктурную задачу, где роли реально разные (стенд, сайт, нода, апгрейд - подходят; "поразмысли" - нет). 2. Заведи профили под роли с --description и узким набором скиллов. Минимальный бот лучше клона со всеми возможностями. 3. Пропиши контракты (владеет/возвращает/готово когда) в SOUL-файл каждого профиля. 4. Общий контекст (инвентарь, шаблоны, журнал) - в общее хранилище markdown. Состояние задач - в канбан. Переписка - только координация. 5. Погони одну задачу через всю линию до статуса done на канбане. Только после этого добавляй вторую.

Главный вывод: мультиагентность не делает систему умнее. Она делает её разборчивее. Умнее она становится от того, что ошибки больше не смешиваются в одном контексте, а граница между "агент решил" и "человек одобрил" наконец очерчена явно.

Харнессы и материалы: github.com/NikolayGusev-astra/channel-materials

hermes-agent.ru