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

Зачем вообще несколько агентов#

Один AI-ответ часто звучит уверенно даже тогда, когда пропустил риск. Consensus Planner нужен для задач, где цена ошибки выше цены обсуждения: архитектура, миграции, безопасность, спорные рефакторинги.

Смысл не в том, чтобы собрать «совет моделей» ради красоты. Смысл в независимых аргументах: один агент ищет риски, другой предлагает путь, третий проверяет слабые места, а итоговый план можно выполнять и проверять.

Так появился Hermes Consensus Planner (HCP) — пользовательский плагин для Hermes Agent. Код открыт: github.com/WEBzaytsev/hermes-consensus-planner. Сейчас это версия 2.1: 98 из 98 тестов проходят, плюс плагин проверен в настоящем Hermes через Telegram.

Плагин добавляет инструмент consensus_plan(task, workdir) и команду /consensus. Задача простая по формулировке и неприятная по реализации: заставить несколько моделей независимо разобрать задачу, поспорить друг с другом и не изображать согласие там, где его нет.

Почему один арбитр оказался плохой идеей#

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

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

Это неприятный, но полезный момент. Система не «врёт» в человеческом смысле. Она просто воспроизводит перекосы модели, которую ты поставил судьёй. Если судья из той же модельной семьи, что и один из участников, он уже не нейтральный.

Поэтому во второй версии я убрал привилегированного судью. Вместо него появились три вещи:

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

Главное правило HCP: если консенсуса нет, плагин не должен делать вид, что он есть.

Как сейчас идёт прогон#

Снаружи всё выглядит коротко:

Пайплайн consensus_plan: спор не замазывается финальным текстом
tool
consensus_plan
Старт запроса
context
locate
Находит релевантные файлы
agents
draft
Независимые планы
review
cross_verify
Чужая проверка каждого плана
reply
re_discuss
Ответ на критику
decision
consensus_gate
Остались ли открытые возражения
output
compile
Финальный markdown-план
human
риски
Несогласие явно уходит в результат

По-человечески это так:

  1. locate ищет релевантные файлы в репозитории.
  2. draft просит несколько моделей независимо собрать первичный план.
  3. cross_verify отправляет каждый план на проверку другому участнику.
  4. re_discuss даёт автору плана ответить на замечания.
  5. consensus_gate без нового LLM-вызова смотрит, какие возражения остались открытыми.
  6. compile собирает итоговый markdown-план из согласованных частей и явно перечисляет спорные места.

Часть имён оставлена английской, потому что это реальные названия этапов в коде и trace-файлах. Но смысл не в названиях. Смысл в том, что спор не отдаётся одному «самому умному» арбитру.

Как агент помогал писать плагин#

Я не садился писать плагин «на вдохновении». Сначала агент помог разобрать сам Hermes: как грузятся пользовательские плагины, где регистрируются инструменты, как вызов доходит до обработчика, чем CLI отличается от Telegram gateway.

После этого был план реализации. Не промпт «сделай плагин», а нормальный документ: какие API использовать, какие структуры данных нужны, где могут быть сбои, как проверять результат. Это важная разница. Если сразу попросить агента писать код, он начнёт уверенно строить не ту систему.

Дальше работа шла итерациями:

  • код;
  • тесты;
  • trace-файлы в ~/.hermes/consensus-planner/traces/<run_id>.json;
  • прогон через настоящий Telegram gateway;
  • отдельная проверка README и примеров, чтобы документация не отставала от кода.

Тесты нужны, но они не ловят всё. Настоящий запуск через Hermes и OpenRouter поймал то, что в тестах выглядело нормально. Самый показательный пример — попытка сделать «агентов внутри агента».

Где сломалась красивая идея с дочерними агентами#

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

Первая идея была простая: раз текущий Hermes-агент уже работает, давайте породим от него дочерних агентов. В реальном gateway это не взлетело. У обработчика плагина нет нормального публичного доступа к «родительскому» агенту. Telegram gateway создаёт AIAgent сам и держит его во внутреннем кэше сессии.

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

Так появился agentic_draft: true. При включённом режиме каждая модель-участник получает доступ к файловым инструментам и сама читает workdir. Старый режим с заранее собранным ограниченным контекстом остался как запасной вариант.

Самая полезная поломка#

До agentic_draft плагин сам выбирал несколько файлов и отдавал их моделям. Это работало ровно до первого серьёзного прогона на реальном Next.js-блоге.

HCP планировал фичу reading time и ошибся в деталях Outstatic API. Причина была простая: locate() подтянул README-подобные файлы, но не добрался до реальной реализации в content.ts.

Это был хороший провал. Он показал, что «модель видела контекст» и «модель видела нужный код» — разные вещи. После этого locate() пришлось чинить, а затем появился полноценный режим, где участники сами читают репозиторий.

Позже HCP уже использовался для планирования собственного skill hermes-consensus-planner-ops. Инструмент начал работать над своей же эксплуатацией и документацией. Для меня это хороший знак: если штука выдерживает применение к самой себе, доверия к ней больше.

Публичный релиз — это тоже работа#

Когда плагин заработал, его нельзя было просто открыть на GitHub одной кнопкой. Перед публикацией пришлось пройтись по хвостам:

  • вычистить приватные детали и старую историю;
  • убрать временные артефакты;
  • привести README к текущему поведению;
  • проверить примеры;
  • довести тесты до 98/98;
  • убедиться, что trace-файлы реально помогают разбирать прогоны, а не лежат для красоты.

Только после этого репозиторий стал публичным.

Что оказалось полезнее всего#

Не то, что «агент написал код». Код как раз наименее интересен.

Полезнее другое:

  • модели спорят до того, как ты начал принимать diff;
  • возражения не исчезают в финальной простыне;
  • каждый прогон оставляет след: стоимость, этапы, спорные места, сырой trace;
  • документация проверяется вместе с кодом;
  • публичный релиз заставляет держать гигиену: без случайных локальных путей, приватных деталей и устаревших инструкций.

В итоге AI-разработка перестаёт быть «модель что-то уверенно сгенерировала». Получается обычный инженерный процесс: план, проверка, реализация, тесты, прогон вживую, артефакты.

Вывод#

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

Главная работа в HCP была не в Python-коде. Главная работа была в том, чтобы система не врала про согласие там, где модели на самом деле спорят.

Если вы хотите использовать AI-агентов в разработке, ревью или планировании, главный вопрос не в количестве моделей, а в проверяемости их решений. Напишите мне в Telegram или на почту — помогу собрать процесс, где агенты спорят по делу, оставляют следы и не подменяют инженерную проверку красивым текстом.