Hermes Agent

← На главную

Опубликовано

Автоматизация внутри Hermes Agent: триггеры, доставка, живые примеры

Автор: Гусев Николай [портфолио]

Темы: hermes-agent, avtomatizaciya, cron, webhook

Когда агент перестаёт быть собеседником и начинает работать сам, происходит одно из двух. Либо он превращается в бесплатного сотрудника, который дежурит по ночам и не просит перерыв. Либо в источник спама, который каждое утро присылает отчёт «всё в порядке». Разница между этими двумя состояниями не в модели. Она в том, как устроены триггеры, доставка и правила молчания.

У Hermes Agent автоматизация построена на трёх типах триггеров. Расписание: агент просыпается по cron-выражению и делает то, что прописано в задаче. Событие из GitHub: открылся pull request, упала сборка, появился issue, и webhook будит агента с полезной нагрузкой. Внешний вызов: любая система, умеющая POST JSON, может запустить агентный прогон: мониторинг, платёжный шлюз, CI-пайплайн после деплоя.

Три типа триггеров, один и тот же исполнитель. В этой статье разберу, как это устроено внутри, и покажу живые примеры из реальной эксплуатации: 28 cron-задач, которые прямо сейчас работают на моей машине.

Расписание: cron-задача как сотрудник на дежурстве

Cron-задача в Hermes Agent состоит из четырёх частей: расписание, промпт, скиллы и цель доставки. Расписание поддерживает четыре формата, от простого every 30m до классического пятиполевого выражения 0 9 * * 1-5. Промпт это то, что агент получит вместо сообщения человека. Скиллы загружаются в контекст перед прогоном, как при обычном диалоге. Доставка определяет, куда уйдёт результат: тот же чат, Telegram-канал, Discord, Slack, SMS или локальный файл.

И вот первое правило, которое я вывел из эксплуатации: настройка автоматизации это два места, и сессия агента из них первое. Обычный путь выглядит так: вы пишете в чат «каждую ночь в два проверяй новые issues в репозитории, предлагай приоритет и категорию, если новых нет, молчи». Агент создаёт задачу собственным инструментом cronjob_manage, уточняет у вас доставку и всё, задача в расписании. Никакого CLI, никаких флагов, весь путь это обычный диалог.

Если удобнее консоль, то же самое делается командой:

hermes cron create "0 2 * * *" \
  "Проверь новые issues в репозитории за последние 24 часа.
Каждому предложи приоритет и категорию.
Если новых issues нет, ответь [SILENT]." \
  --name "Ночной триаж бэклога" \
  --deliver telegram

Оба пути пишут в один и тот же стор jobs.json, но консоль это резерв: для разовой задачи, для скрипта установки, для случая, когда агента под рукой нет. Повседневная настройка живёт в сессии.

Ключевая деталь здесь: маркер [SILENT]. Когда ответ агента содержит этот маркер, доставка подавляется. Это главный паттерн против спама: вы получаете сообщение только тогда, когда есть что сообщить. Без него любой мониторинг превращается в ежедневную сводку «ничего не случилось», которую человек перестаёт читать на третий день.

Живые примеры: 28 задач на одной машине

Теория синих примеров дала бы честную, но бесполезную картину. Поэтому я разобрал собственный jobs.json, файл, в котором живут все cron-задачи моего агента. 28 задач, из них 14 активных. Вот что там есть.

Ночная синхронизация базы знаний. Каждый день в 02:00 агент синхронизирует источники корпоративных данных: Jira, Confluence, внутренние репозитории. Задаче подключён скилл auto-rag, в промпте перечислены коннекторы, доставка идёт в локальный файл. 85 завершённых прогонов, статус ok. Это пример автоматизации, которую вообще нельзя делать человеком: никто не будет вручную гонять синхронизацию четырёх источников каждую ночь три месяца подряд.

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

Напоминание о лекарствах. Каждый день в 09:00, скилл медкарты, доставка в тот же чат. Промпт заслуживает цитаты: «Это НАПОМИНАНИЕ, а не список из памяти. Используй ТОЛЬКО график, приведённый ниже. Скопируй из него строки дословно, не меняй названия, дозировки, время». Данные подставляет скрипт-источник даты, агент не вычисляет и не вспоминает. Это пример автоматизации, где цена ошибки выше стоимости задачи: модель обязана быть рупором, а не автором.

Мониторинг цен аптеки. В 08:00 агент обходит аптеку, сравнивает цены с целевыми и молчит, если ничего не изменилось. 70 прогонов.

Дайджест новостей по будням. В 18:00 с понедельника по пятницу агент ищет новости и присылает не больше восьми пунктов по одной строке со ссылкой. Промпт содержит два правила: дедупликация против прошлых прогонов и [SILENT], если новостей нет.

Общая картина по парку задач: пауза стоит на 14 из 28. Это нормально. Cron-парк это не музей, задачи паузятся, когда потребность ушла, и возвращаются, когда вернулась. Живой парк всегда больше активного.

События: webhook как тревожная кнопка

Расписание отвечает на вопрос «когда». Webhook ловит момент: «что случилось». Открылся pull request, упал CI, пришёл спорный платёж: внешняя система отправляет POST на ваш эндпоинт, Hermes проверяет HMAC-подпись и запускает агент с телом события в контексте.

Со вебхуками то же правило двух мест: сессия сначала, консоль резервом. Вы пишете агенту «настрой вебхук на новые pull request'ы в этот репозиторий: ревью безопасности и качества, результат комментарием на PR». Агент подхватывает скилл webhook-subscriptions, сам собирает подписку, прогоняет команду подписки через свой терминал-инструмент и отдаёт вам URL с секретом, которые осталось прописать в настройках GitHub. Одна деталь заслуживает честности: команда подписки нарочно не принимает флаг toolsets, расширение инструментов для webhook-маршрута делается правкой конфига. Это защита от удобного пути, а не жёсткая граница: агент с терминалом и включённым YOLO всё равно сможет отредактировать конфиг сам, и это одна из причин, почему webhook-прогоны по умолчанию получают урезанный набор инструментов без терминала. Гарды здесь снижают риск случайного самоусиления, но не останавливают того, кто целенаправленно их обходит.

Как это выглядит под капотом, если полезть в консоль:

hermes webhook subscribe github-pr-review \
  --events "pull_request" \
  --prompt "Review this pull request:
PR #{pull_request.number}: {pull_request.title}
Diff URL: {pull_request.diff_url}

Проверь безопасность, производительность и качество кода.
Пост ревью на PR." \
  --skills github-code-review \
  --deliver github_comment

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

Шаблон {pull_request.title} подставляет поля из JSON-полезной нагрузки прямо в промпт. Агент забирает diff по ссылке, прогоняет его через скилл ревью и постит комментарий прямо на PR. Человек открывает pull request утром, а там уже разбор с приоритетами.

У маршрутов есть свойства, которые превращают webhook из «расскажи мне о событии» в самостоятельный конвейер. filters отсекает события по полям полезной нагрузки до запуска агента: платёжный шлюз шлёт десятки типов событий, а обрабатывать нужно два. coalesce склеивает очередь событий по одной сущности: пять коммитов в PR за минуту не должны порождать пять ревью. deliver_only пропускает агента целиком и доставляет отрендеренный шаблон как уведомление без LLM-затрат, когда агентная обработка не нужна. cron_job запускает по событию не новый прогон, а существующую cron-задачу с её скиллами и моделью.

Внешние вызовы: любой POST становится агентом

Третий тип триггера покрывает всё, что не GitHub. Мониторинг упавшего сервиса, CI после деплоя, платёжная система, датчик умного дома. Если система умеет отправлять HTTP POST с JSON, она может будить агента.

Классический пример: проверка деплоя. Ваш пайплайн после выката дёргает эндпоинт:

curl -X POST http://your-server:8644/webhooks/deploy-verify \
  -H "Content-Type: application/json" \
  -H "X-Hub-Signature-256: sha256=..." \
  -d '{"service":"api","environment":"prod","version":"2.1.0"}'

Агент проверяет health-эндпоинт, ищет ошибки в логах и сообщает в Telegram вердикт: healthy, degraded или failed. Если всё хорошо, короткое подтверждение. Если нет, диагностика с вероятными причинами.

Доставка: куда и когда сообщать

Автоматизация живёт или умирает на доставке. У Hermes целей доставки больше десятка: тот же чат (origin), Telegram, Discord, Slack, SMS, email, комментарий на GitHub, Mattermost, локальный файл. Формат всегда одинаковый: --deliver telegram, --deliver sms:+7..., --deliver telegram:-100123:456 (конкретный топик форума).

Правило, которое я выведал шишками: доставка по умолчанию должна быть тихой, а не громкой. Дефолт «докладывай всё» убивает доверие к каналу за неделю. Дефолт «молчи, пока не случится изменение» держит его живым месяцами. Паттерн [SILENT] не украшение промпта, а архитектурное решение: агент по умолчанию наблюдатель, докладывает только при отклонении.

Планирование против событий: что выбрать

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

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

Если нет, расписание. Новые issues в репозитории не «случаются» в конкретный момент, они накапливаются. Цена на препарат меняется плавно. База знаний дрейфует. Здесь периодический прогон с правилом молчания честнее и дешевле.

Гибридные схемы законны: webhook ловит событие, но вместо запуска нового прогона дёргает cron-задачу с готовым набором скиллов и моделью. Так событийный триггер получает планировочную дисциплину.

Модели для автоматизации: дёшево и стабильно

Автоматизация это то место, где оправданы дешёвые модели. Ночная синхронизация, мониторинг цен, дайджест новостей: задачи с низкими ставками и высокой регулярностью. Модель уровня 30B в free-тарифе справляется с дедупликацией новостей и сравнением цен. Дорогая модель здесь не улучшает результат, она только повышает стоимость каждого прогона.

Противоположный полюс: задачи с высокой ценой ошибки. Напоминание о лекарствах работает на мощной модели с жёстким промптом, который запрещает генерировать и требует копировать. Разница не в «умности», а в цене ошибки: перепутать дозировку дороже, чем пропустить новость.

Cron-задача в Hermes позволяет закрепить модель за задачей: скажите агенту в чате «закрепи за этой задачей текущую модель», и он пропишет пин своим инструментом. Ночной парк на дешёвых, критичные напоминания на надёжных, ревью PR на сильных кодовых.

Что почитать по механике

Автоматизация внутри агента это не «замени человека роботом». Это перенос рутины туда, где человек не нужен: ночные синхронизации, бесконечные проверки цен, дежурство по бэклогу. Человек остаётся для того, что требует суждения. Агент для того, что требует повторения. Три типа триггеров и правило молчания, вот и вся архитектура, которая для этого нужна.