Как настроить cron-задачу для ИИ-агента и не получить поток бесполезных сообщений

• Расписание определяет, когда задача становится доступной для запуска.
• Prompt задаёт источник, критерий изменения, формат ответа и поведение при отсутствии события.
• Delivery определяет, куда попадёт итог: локально, в исходный чат или в конкретный канал.
• Gateway или другой поддерживаемый backend обеспечивает автоматические запуски без открытого терминала.
• История запусков подтверждает, что агент действительно работал. Наличие сообщения подтверждает только доставку, а не весь цикл.

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

Начинайте не с частоты, а с решения. Ответьте на четыре вопроса:

1. Какой точный источник проверяется?
2. Что считается новым или опасным событием?
3. Какое действие должен сделать получатель?
4. Что вернуть, если ничего значимого нет?

Плохая инструкция: «Проверяй сайт и сообщай результат».

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

Маркер [SILENT] подавляет доставку успешного результата, но сам результат сохраняется локально для аудита. Ошибочные запуски он не скрывает. Если одно и то же событие может быть найдено несколько раз, храните его устойчивый идентификатор или контрольную сумму и не отправляйте повторно уже обработанное.

Проверка каждые пять минут нужна редко. Частота зависит от двух величин:

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

Для утренней сводки подходит конкретное время. Для периодического мониторинга — интервал. Для разового напоминания — дата или относительное время. Hermes принимает интервалы, понятные фразы времени, стандартные пятичастные cron-выражения и ISO timestamp.

Если расписание связано с рабочим днём, явно проверяйте часовой пояс машины и ожидаемое локальное время. Запись every 2h означает интервал от опорного момента, а не «в каждый чётный час».

Первые версии лучше создавать сразу выключенными. Так задача не успеет сработать между созданием и последующей паузой.

hermes cron create "every 2h"   "Проверить один источник; при отсутствии изменений вернуть [SILENT]."   --name "article-cron-canary"   --deliver local   --paused   --paused-reason "Article verification canary"

Команда выше реально проверена 11 сентября 2026 года в изолированном профиле Hermes Agent. Планировщик создал выключенную задачу, нормализовал расписание до every 120m и не назначил следующий запуск.

Проверьте запись:

hermes cron list --all

Ожидаемый результат: состояние paused, доставка local, расписание every 120m, следующий запуск не назначен. Флаг --all важен: без него выключенная задача может не попасть в список.

В сборке, проверенной 11 сентября 2026 года, standalone CLI не запускал paused-задачу. Это результат проверки конкретной версии, не универсальное правило всех будущих сборок. Для этой версии безопасная последовательность выглядит так:

1. проверьте prompt, доставку, skills и рабочую директорию в hermes cron list --all;
2. на короткое время выполните hermes cron resume article-cron-canary;
3. сразу выполните hermes cron run article-cron-canary;
4. проверьте outcome и историю через hermes cron runs <job-id> --limit 20;
5. если тест не прошёл или постоянное расписание пока не нужно, выполните hermes cron pause article-cron-canary.

Ручной запуск, запуск на следующем tick и фоновое исполнение зависят от версии и поверхности. В текущей документации управление агента называется cronjob_manage; пример cronjob(action=run) относится к прежней поверхности. Не переносите поведение одной сборки на другую: проверяйте outcome, историю и итоговый результат по актуальной документации Hermes. Глобальная пауза hermes pause и пауза отдельной задачи — разные состояния: текущая документация разрешает явный ручной запуск как override глобальной паузы.

Не доверяйте одному shell exit code. В проверенной сборке отказ запуска paused-задачи мог завершиться кодом 0; доказательство исполнения — текст outcome, новая запись в cron runs, обновлённое состояние и ожидаемый локальный результат.

Cron-задача не превращает обычный CLI-процесс в постоянно работающий сервис. Для запусков без открытого терминала нужен работающий Gateway, Desktop backend или другой настроенный провайдер планировщика.

Проверьте состояние:

hermes cron status
hermes cron doctor

doctor — read-only диагностика активных задач. Он находит, например, ошибки запуска или доставки, просроченный next_run_at и отсутствующую рабочую директорию. Но зелёный doctor не доказывает качество prompt, полезность сообщения или end-to-end доставку. Paused-задачи могут не входить в его активную выборку.

Если Gateway ещё не установлен, используйте документированную команду для своей системы:

hermes gateway install

На Linux для системного сервиса доступен вариант sudo hermes gateway install --system; он требует соответствующих прав. Команды выполняйте в том же профиле Hermes, где создана задача.

В production одной фразы «не повторяйся» мало. Нужны явные правила:

• хранить последний обработанный ID, дату или хеш содержимого;
• отправлять только изменение, которое влияет на решение;
• на пустом результате возвращать только [SILENT];
• для внешней записи использовать собственный idempotency key;
• не считать защиту scheduler гарантией exactly-once для платежа, публикации или другого побочного эффекта;
• не помещать ключи, токены и пароли в prompt, имя задачи или итоговый отчёт.

Для дешёвого частого мониторинга лучше сначала запускать небольшой pre-run script. Если он не нашёл изменения, агент можно не будить. Это уменьшает стоимость и число пустых ответов.

Задача не запускается

Проверьте по порядку:

1. работает ли Gateway или выбранный backend;
2. активна ли задача;
3. есть ли будущий next_run_at;
4. правильно ли разобрано расписание;
5. совпадают ли системные часы и часовой пояс с ожиданием;
6. есть ли записи в hermes cron runs.

Запуск есть, сообщения нет

Это отдельная ветка диагностики. Проверьте delivery target, подключение площадки, разрешения получателя, last_delivery_error и не вернула ли задача [SILENT]. Успешная работа агента и успешная доставка — разные события.

Приходит слишком много сообщений

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

Один эффект выполняется дважды

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

Задача долго работает или падает

Сузьте число источников, объём извлекаемого текста и доступные toolsets. Проверьте лимиты времени. Для LLM-задач действует лимит бездействия, а не обязательно фиксированное ограничение всей длительности; типовое значение зависит от конфигурации. Не передавайте агенту мегабайты вывода, если достаточно одной изменившейся записи.

• Внутри cron-сессии управление другими cron-задачами по умолчанию отключено, чтобы задача не создавала рекурсивные расписания. Это поведение можно отдельно разрешить в конфигурации.
• Toolsets для интерактивного уточнения и произвольной отправки сообщений недоступны cron-сессии; используйте штатный delivery результата.
• Preflight проверяет поставщика модели, доступность skills и конфигурацию доставки, но не заменяет реальный canary.
• Рабочая директория должна существовать и задаваться абсолютным путём.
• Секреты должны жить в предназначенном для них хранилище, а не в тексте задания или отчёте.

Cron-задачу можно оставлять активной, если:

• в prompt назван точный источник;
• определено значимое событие;
• задано поведение без изменений;
• один ручной запуск появился в истории;
• полезный результат записан или доставлен в ожидаемое место;
• повторная проверка не создаёт дубль;
• понятны владелец, частота, пауза и удаление;
• Gateway или backend действительно работает без открытого терминала.

Если агент уже работает, но Telegram-бот молчит, используйте статью «Telegram-бот создан, но не отвечает: как проверить Hermes Gateway». Если вы только собираете рабочую связку на сервере, начните с гайда «Как установить Hermes Agent на VPS».

А когда базовая задача прошла canary, переносите в расписание только тот сценарий, у которого есть измеримый повод для сообщения и понятный человек, принимающий решение. В Среде внедрения ИИ участники «Человека 2.0» разбирают такие рабочие сценарии, забирают готовые скилы и доводят автоматизацию до проверяемого результата.