Диагностика cron

Cron-задание ведёт себя странно? Пройдитесь по проверкам ниже строго по порядку. Почти всё, что ломается в планировщике автономного ИИ-агента, сводится к четырём причинам: расписание, доставка, права доступа и загрузка навыков.

Задания не срабатывают

Проверка 1: убедитесь, что задание существует и активно

hermes cron list

Найдите своё задание в списке и посмотрите на статус. Нужен [active] — не [paused] и не [completed]. Видите [completed]? Значит, счётчик повторений исчерпан; отредактируйте задание, чтобы сбросить его.

Проверка 2: правильно ли задано расписание

Кривой формат расписания не вызовет громкой ошибки. Hermes Agent либо тихо превратит его в одноразовый запуск, либо отклонит целиком. Сверьте своё выражение с таблицей:

Выражение	Означает
`0 9 * * *`	Каждый день в 9:00
`0 9 * * 1`	Каждый понедельник в 9:00
`every 2h`	Каждые 2 часа с момента создания
`30m`	Через 30 минут
`2025-06-01T09:00:00`	1 июня 2025 года, 9:00 UTC

Если задание сработало один раз и пропало из списка, перед вами одноразовое расписание — 30m, 1d или ISO-метка времени. Так и должно быть.

Проверка 3: запущен ли шлюз?

За запуск cron-заданий отвечает фоновый поток-тикер внутри шлюза; он тикает раз в 60 секунд. Обычный сеанс CLI-чата заданий не запускает — это важная деталь, на которой спотыкаются чаще всего.

Хотите, чтобы задания срабатывали сами? Держите шлюз запущенным: hermes gateway поднимет его прямо в терминале, а hermes gateway start запустит установленный сервис. Для разовой отладки тик можно дёрнуть вручную — hermes cron tick.

Десктопное приложение: основной бэкенд десктопа гоняет собственный тикер и тикает cron-хранилище каждого локального профиля — задания на второстепенном профиле продолжают срабатывать, даже пока бэкенд этого профиля спит (десктоп усыпляет простаивающие бэкенды профилей примерно через 10 минут). Держать профиль открытым ради его запланированных заданий не нужно.

Проверка 4: системные часы и часовой пояс

Расписание привязано к локальному часовому поясу. Сбитые часы или неожиданный пояс на машине — и задания посыплются в неправильное время. Проверьте:

date
hermes cron list   # Сравните next_run с текущим местным временем

Сбои доставки

Проверка 1: правильно ли указана цель доставки

Цели доставки чувствительны к регистру, и под каждую нужна настроенная платформа. Ошиблись в цели — ответ молча уйдёт в никуда.

Цель	Требует
`telegram`	`TELEGRAM_BOT_TOKEN` в `~/.hermes/.env`
`discord`	`DISCORD_BOT_TOKEN` в `~/.hermes/.env`
`slack`	`SLACK_BOT_TOKEN` в `~/.hermes/.env`
`whatsapp`	Настроенный WhatsApp-шлюз
`signal`	Настроенный Signal-шлюз
`matrix`	Настроенный Matrix homeserver
`email`	SMTP настроен в `config.yaml`
`sms`	Настроенный SMS-провайдер
`local`	Право записи в `~/.hermes/cron/output/`
`origin`	Доставка в чат, где было создано задание

Помимо этого поддерживаются mattermost, homeassistant (плагин), dingtalk, feishu, wecom, weixin, bluebubbles, qqbot и webhook. Если нужен конкретный чат, укажите его через синтаксис platform:chat_id — например, telegram:-1001234567890.

Даже когда доставка через шлюз сообщений срывается, задание всё равно отрабатывает: просто ответ некуда отправить. Загляните в поле last_error в выводе hermes cron list, если оно доступно.

Проверка 2: использование `[SILENT]`

Нет вывода от cron-задания? Доставка подавляется. Если ответ агента содержит маркер тишины [SILENT] — доставка тоже подавляется. Для мониторинговых заданий это нормальное поведение. Но стоит проверить, не глушит ли промпт ответы там, где этого не ждёшь.

Пишите промпты вида «ответь только [SILENT], если ничего не изменилось». Не просите агента вставлять [SILENT] внутрь развёрнутого объяснения — планировщик трактует этот маркер как сигнал подавить доставку целиком.

Проверка 3: разрешения токена платформы

Боту мессенджера нужны конкретные права, иначе сообщение не дойдёт. Когда доставка молча проваливается, сверьтесь со списком:

Telegram: бот должен быть администратором целевой группы или канала
Discord: у бота должно быть право отправки в целевом канале
Slack: бот добавлен в рабочее пространство и имеет scope chat:write

Проверка 4: обёртка ответа

По умолчанию cron-ответы оборачиваются шапкой и подвалом — за это отвечает параметр cron.wrap_response: true в config.yaml. Отдельные платформы и интеграции переваривают такую обёртку плохо. Отключить просто:

cron:
  wrap_response: false

Проверка 5: платформы за релеем (Hermes Cloud / Team Gateway)

Если учётные данные платформы лежат не в вашем локальном .env, а в релей-коннекторе (например, Slack или Discord подключены через Team Gateway), единственный отправитель — живой релей-адаптер запущенного шлюза. Отдельного пути доставки в обход шлюза не существует.

Запланированные срабатывания работают, пока шлюз запущен: доставку через релей ведёт именно его тикер.
Автономный вызов hermes cron run <id> автоматически пересылает запуск на шлюз через api_server (POST /api/jobs/{id}/run). Для этого нужно, чтобы платформа api_server была включена и задан API_SERVER_KEY (16+ символов). Контекст --prompt / cronjob(action='run', prompt=...) пересылается вместе с запросом и действует только для этого единственного срабатывания.
Если шлюз недоступен, запуск падает с ошибкой вида «relay-fronted … start the gateway» — вместо вводящей в заблуждение platform 'slack' not configured/enabled. Запустите шлюз и повторите попытку.

Ошибки загрузки навыков

Проверка 1: убедитесь, что навыки установлены

hermes skills list

Привязать навык к cron-заданию можно только после того, как он установлен. Нет нужного навыка в списке — поставьте его командой hermes skills install <skill-name> или через /skills прямо в CLI.

Проверка 2: имя навыка и имя папки навыка

Имена навыков чувствительны к регистру и обязаны посимвольно совпадать с именем папки установленного навыка. Если задание ссылается на ai-funding-report, сверьте точное написание через hermes skills list — лишняя буква или дефис всё сломают.

Проверка 3: навыки, которым нужны интерактивные инструменты

В контексте cron агент стартует с отключёнными наборами инструментов cronjob, messaging и clarify. Так движок контекста закрывает три лазейки сразу: рекурсивное создание cron-заданий, прямую отправку сообщений (за доставку и так отвечает планировщик) и интерактивные запросы к пользователю. Навык, который держится на этих наборах, в cron попросту не заработает.

Загляните в документацию навыка и проверьте, поддерживает ли он неинтерактивный (headless) режим.

Проверка 4: порядок загрузки нескольких навыков

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

/cron add "0 9 * * *" "..." --skill context-skill --skill target-skill

Здесь context-skill загрузится раньше target-skill.

Ошибки и сбои заданий

Проверка 1: просмотр вывода последнего запуска

Когда задание падает с ошибкой, контекст сбоя ищите в трёх местах:

В чате, куда настроена доставка, — если она вообще прошла
В ~/.hermes/logs/agent.log лежат сообщения планировщика (предупреждения — в errors.log)
В метаданных поля last_run, доступных через hermes cron list

Проверка 2: типичные паттерны ошибок

“No such file or directory” для скриптов Путь script должен быть абсолютным — либо относительным к директории конфигурации Hermes. Проверьте:

ls ~/.hermes/scripts/your-script.py   # Файл должен существовать
hermes cron edit <job_id> --script ~/.hermes/scripts/your-script.py

“Skill not found” при выполнении задания Навык должен стоять именно на той машине, где крутится планировщик. Переехали на другой сервер — навыки сами не подтянутся, переустановите их через hermes skills install <skill-name>.

Задание запускается, но ничего не доставляет Чаще всего виновата цель доставки (см. «Сбои доставки» выше), пустой вывод или ответ с маркером тишины [SILENT].

Задание зависает или ловит таймаут Планировщик считает таймаут от неактивности: по умолчанию 600 с, меняется переменной окружения HERMES_CRON_TIMEOUT, а 0 снимает ограничение совсем. Пока агент активно вызывает инструменты, он может работать сколько угодно — таймер срабатывает только после долгого простоя. Под длинные задачи отдавайте сбор данных скрипту, а агенту передавайте лишь итоговый результат.

Проверка 3: конкуренция блокировок

Чтобы тики не наезжали друг на друга, планировщик берёт файловую блокировку. Запустили два экземпляра шлюза (или CLI-сессия конфликтует со шлюзом) — и задания начинают задерживаться или вовсе пропускаться.

Завершите лишние процессы шлюза:

ps aux | grep hermes
# Завершите дублирующиеся процессы, оставьте только один

Проверка 4: права на jobs.json

Задания хранятся в ~/.hermes/cron/jobs.json. Если ваш пользователь не может ни читать, ни писать этот файл, планировщик откажет — и снова молча:

ls -la ~/.hermes/cron/jobs.json
chmod 600 ~/.hermes/cron/jobs.json   # Файл должен принадлежать вашему пользователю

Проблемы с производительностью

Медленный старт задания

Под каждое cron-задание поднимается свежая сессия AIAgent, а вместе с ней — аутентификация у провайдера модели и загрузка самой модели. Для расписаний, чувствительных ко времени, закладывайте запас: скажем, 0 8 * * * вместо 0 9 * * *.

Слишком много перекрывающихся заданий

Внутри одного тика задания выполняются последовательно, одно за другим. Назначили несколько штук на одну минуту — они выстроятся в очередь. Разнесите расписания: например, 0 9 * * * и 5 9 * * * вместо двух заданий на 0 9 * * *, и задержки уйдут.

Большой вывод скрипта

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

Диагностические команды

hermes cron list                    # Показать все задания, статусы, время next_run
hermes cron run <job_id>            # Запланировать на следующий тик (для тестирования)
hermes cron edit <job_id>           # Исправить настройки задания
hermes logs                         # Показать недавние логи Hermes
hermes skills list                  # Проверить установленные навыки

Дополнительная помощь

Прошли все проверки, а cron на VPS по-прежнему упрямится? Тогда:

Запустите задание через hermes cron run <job_id> (сработает на следующем тике шлюза) и следите за ошибками в выводе чата
Проверьте ~/.hermes/logs/agent.log на сообщения планировщика и ~/.hermes/logs/errors.log на предупреждения
Откройте issue на github.com/NousResearch/hermes-agent и приложите:
- ID задания и расписание
- Цель доставки
- Что ожидалось и что вышло на самом деле
- Подходящие сообщения об ошибках из логов

Полная справка по cron — в разделах Автоматизация с помощью cron и Запланированные задачи (cron).