Как ставится задача
Есть три равнозначных способа. В чате — слэш-командой:
/cron add "every 2h" "Проверить статус сервера"Из терминала — отдельной командой CLI:
hermes cron create "every 1d at 09:00" "Собрать сводку по открытым PR и здоровью CI"И просто словами в переписке: «каждое утро в 9 проверяй новости по теме и присылай мне сводку в Telegram» — агент сам вызовет нужный инструмент и создаст задачу.
Важная особенность, которая экономит часы отладки: каждая задача выполняется в чистой сессии, без истории вашей переписки. Промпт «проверь ту проблему с сервером» не сработает — агент не знает, о чём речь. Формулировка должна быть самодостаточной: какой сервер, под каким пользователем, какую команду выполнить, что считать нормой.
Выполняет задачи демон gateway — тот же процесс, который обслуживает Telegram. Он опрашивает расписание раз в минуту и запускает всё, чему пришло время. Если gateway не поднят как сервис, автоматизация живёт ровно до закрытия терминала. Про его запуск и подключение мессенджера — в статье «Hermes Agent в Telegram».
Форматы расписания
Планировщик понимает четыре нотации, и это тот случай, когда стоит выбирать самую читаемую.
Разовые отложенные задачи задаются как in 30m, in 2h, in 1d. Повторяющиеся интервалы — every 30m, every 2h, every 1d. Естественные формулировки работают не хуже: every day at 9am, weekdays at 9am, every monday 9am, monday, wednesday at 9am; время принимается в виде 9am, 14:00, noon, midnight. Для нестандартной периодичности остаются классические cron-выражения вроде 0 9 * * 1-5 (по будням в девять) или 0 */6 * * * (каждые шесть часов). Отдельная разовая задача может быть привязана к точной дате в формате ISO.
Интервалы и cron-выражения по умолчанию повторяются бесконечно, разовые — выполняются один раз; при необходимости число повторов ограничивается параметром repeat.
Куда приходит результат
Доставка настраивается параметром deliver. Результат может вернуться в тот чат, где задача создавалась, сохраниться локально в файл, уйти в конкретный чат Telegram или в конкретный топик, в Discord, Slack, WhatsApp, Signal, на почту или сразу во все подключённые каналы. Комбинации тоже допустимы — например, «в исходный чат плюс во все остальные».
Промпт не должен содержать инструкцию «отправь мне это»: финальный ответ агента доставляется автоматически по указанному адресу. Это частая ошибка при переносе сценариев из других инструментов — агент начинает дублировать сообщения.
Полезная деталь для дайджестов: по умолчанию доставленный текст оборачивается заголовком, из которого видно, что сообщение пришло от задачи по расписанию. Если вы шлёте клиенту готовый отчёт, обёртку отключают настройкой cron.wrap_response: false.
Мониторинг, который молчит, пока всё хорошо
Самый недооценённый механизм планировщика — тихое подавление доставки. Если в финальном ответе агента есть маркер [SILENT], сообщение не отправляется, но результат сохраняется локально для аудита. Промпт в этом случае формулируется так:
Проверь, работает ли nginx. Если всё в порядке — ответь только [SILENT]. Иначе опиши проблему.
Получается канал, в котором сообщение появляется только тогда, когда действительно что-то случилось. При этом упавшие задачи доставляются всегда, независимо от маркера, — сломанный мониторинг не может замолчать незаметно.
Задачи без модели: скрипт по расписанию
Не каждой рутине нужен LLM. Для сторожевых проверок — свободное место на диске, память, доступность сервиса, пинг CI — предусмотрен режим no_agent: планировщик выполняет ваш скрипт и доставляет его stdout дословно, вообще не обращаясь к модели.
hermes cron create "every 5m" \
--no-agent \
--script memory-watchdog.sh \
--deliver telegram \
--name "memory-watchdog"Пустой вывод означает тихий тик без доставки — ровно то поведение, которое нужно сторожу. Ненулевой код возврата или таймаут превращаются в аварийное уведомление. Токены при этом не тратятся вообще. Скрипты обязаны лежать внутри каталога scripts в домашней директории Hermes, а секреты провайдеров в них не передаются — это осознанное ограничение.
Промежуточный вариант — скрипт-привратник перед обычной задачей: он проверяет, изменилось ли что-то, и последней строкой выводит {"wakeAgent": false}, если будить модель не нужно. Частые опросы раз в пять минут становятся бесплатными, а модель включается только когда появились новые данные.
Цепочки задач и память между запусками
Две настройки превращают набор отдельных задач в конвейер. Параметр context_from подставляет в промпт свежий результат другой задачи: одна собирает сырые данные в семь утра, вторая ранжирует их в семь тридцать, третья в восемь готовит итоговый текст. Параметр continuity подставляет задаче её собственный предыдущий результат — именно этого не хватает мониторингам и новостным сборщикам, которые иначе каждый запуск заново рапортуют об одном и том же.
Ещё одна практичная возможность — привязка задачи к рабочему каталогу проекта. Тогда в системный промпт подтягивается проектный контекст из файлов вроде AGENTS.md, а файловые инструменты работают внутри этой директории.
Сколько это стоит и как не переплатить
Три настройки решают большую часть вопросов с бюджетом.
Первая — набор инструментов. По умолчанию задача получает тот toolset, который настроен для платформы cron, но его можно сузить прямо на уровне задачи: маленькой задаче «собери новости» не нужны браузер и делегирование, а их схемы попадают в каждый запрос к модели и раздувают промпт.
Вторая — фиксация модели. Задача может быть закреплена за конкретной моделью и провайдером, а для всего парка задач задаётся отдельная модель по умолчанию, независимая от той, в которой вы общаетесь в чате. Если модель нигде не закреплена, срабатывает защита от дрейфа: при смене глобальных настроек задача не выполнится молча на новом платном провайдере, а остановится и один раз предупредит.
Третья — предварительная валидация. Перед запуском планировщик проверяет, что ключ провайдера разрешается, подключённые навыки готовы, а цель доставки существует. Задача с битой конфигурацией получает статус blocked_config и не тратит ни одного токена.
Диагностика: задача не сработала
Начинать стоит с hermes cron doctor — это проверка всего парка задач, которая покажет, у какой упал последний запуск, где не прошла доставка, где потерялось время следующего запуска и где отсутствует привязанный скрипт. Она ничего не меняет, только отчитывается.
Дальше есть история попыток (hermes cron runs) и журнал инцидентов: повторяющаяся ошибка регистрируется отдельной записью, которую можно подтвердить командой ack, чтобы не получать одинаковое уведомление после каждого запуска. Ошибка доставки при этом отделена от ошибки выполнения: статус delivery_failed означает, что агент отработал, а сообщение не дошло.
Характерная картина «вручную запускается, сама не срабатывает» указывает не на задачу, а на gateway — в записи задачи в этом случае появляется отметка о пропущенном запуске, и обычно помогает перезапуск сервиса.
С чего начать
Не пытайтесь автоматизировать всё сразу. Возьмите одну задачу, которую вы делаете руками каждый день: утреннюю сводку по нужному источнику, проверку доступности сервиса, еженедельный отчёт по репозиторию. Доведите её до состояния, когда результат стабильно приходит и им можно пользоваться. Вторая и третья задачи после этого настраиваются за минуты.