Автоматизации

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

Структура

У автоматизации есть имя, свободные инструкции, до пяти триггеров, необязательная модель (пусто означает Auto: модель чата пользователя во время выполнения), цель и настройка уведомлений (в приложении или выкл.). Цель определяет результат: Chat session по умолчанию ставит инструкцию в очередь разговора, а Work task запускает изолированную песочницу Work с инструкцией как первым сообщением, при необходимости по выбранной именованной политике. При включённых уведомлениях ошибка также попадает в центр уведомлений, даже если Automations закрыта. Отдельно от этого включение Результатов автоматизаций в разделе Настройки → Уведомления → Уведомления по почте отправляет вам на почту итог каждого выполнения, как только администратор настроит сервер исходящей почты (см. Уведомления). Имена и инструкции зашифрованы в покое. Автоматизация принадлежит создателю.

Триггеры используют модель календаря — once, hourly, daily, weekly, monthly, yearly — и автоматизация может хранить до пяти. Следующее выполнение — самое раннее из будущих событий, вычисленное в локальной зоне сервера.

Триггеры событий

Седьмой вид, event, вовсе без часов: он срабатывает при поступлении одного из ваших уведомлений.

{ "kind": "event", "event": "channel-mention", "match": "release" }

event — любой тип уведомления, кроме automation-failed: процедура не должна получить возможность перезапустить себя собственным сообщением о сбое. Необязательное поле match — это проверка подстроки без учёта регистра по заголовку уведомления; без него срабатывает каждое уведомление этого типа.

Триггер события никогда не задаёт время следующего выполнения. Поэтому автоматизация, у которой все триггеры — события, не показывает следующее выполнение: список и диалог редактирования вместо этого говорят Срабатывает при…. Сочетать триггер события с расписанием можно — плановые триггеры по-прежнему определяют часы.

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

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

---
Trigger payload (JSON):
{"event":"channel-mention","title":"...","body":"...","href":"..."}

Выполнение

Планировщик с координационной арендой срабатывает каждую минуту, поэтому расписания продвигает одна реплика. При наступлении срока он записывает выполнение, ставит постоянное задание automation.run.v1 и обновляет next_run_at через compare-and-set, чтобы событие сработало максимум раз. Задание создаёт чат с названием автоматизации и передаёт инструкцию по той же постоянной цепочке генерации, включая маршрутизацию, персону и сохранение.

Если сервер был выключен, следующий тик выполняет последнее пропущенное событие раз и пропускает более старые. Приостановка очищает расписание; возобновление или правка пересчитывает его от текущего времени. Удаление каскадно удаляет историю.

Состояние берётся из постоянного журнала: успех после генерации, ошибка после dead-letter и stalled, если выполнение не началось за 30 минут.

Цель Work использует жизненный цикл Work вместо чат-задачи: запись связывается с созданной задачей, Runs ведёт к ней, успех наступает после завершения агента или запроса ввода, ошибка — при сбое или отмене. Письмо с итогом для задачи Work несёт сводку, которую сохранил сам запуск Work, — то, чем закончил агент, тот же текст, что показывает история выполнений задачи, — а если запуск старше появления сохранённых сводок, письмо падает на однострочный статус задачи. Доступ проверяется при срабатывании, поэтому его отзыв отключает автоматизации Work; выполнение честно завершается как work-access-denied. Политика проверяется при сохранении, а сеть и лимиты применяются ко всем задачам. В Work работают только прямые поставщики, модель должна поддерживать инструменты.

Процедуры агентов

Автоматизация Work может связаться с существующей задачей через workTaskId — это основа Routines в панели агента. Она не создаёт новую задачу: каждое событие запускается в её области и диалоге с моделью, поставщиком и политикой задачи, поэтому поля автоматизации не действуют, а переданная политика удаляется. Связь проверяется при сохранении. Удалённая задача даёт work-task-missing, занятая или с живым предпросмотром — work-task-busy, а не очередь.

Триггеры веб-хуков

Кроме расписания, автоматизацию может запустить внешняя система — конвейер CI, служба cron, домашняя автоматика. В окне редактирования автоматизации Триггер веб-хука → Включить создаёт секрет для этой автоматизации; хранится только его SHA-256, поэтому открытый текст показывается ровно один раз. Смена секрета немедленно аннулирует предыдущий, а отключение веб-хука снова закрывает эндпоинт.

Внешняя система запускает автоматизацию так:

curl -X POST https://your-host/api/automations/<automationId>/webhook \
  -H "Authorization: Bearer lwh_..."

(X-Libre-Webhook-Secret: lwh_... работает как альтернативный заголовок.) Ответ — 202 с идентификатором поставленного в очередь выполнения: это тот же путь ручного запуска, что и Запустить сейчас, поэтому выполнения завершаются, уведомляют и попадают в историю одинаково. Сравнение секрета выполняется за постоянное время, отсутствующая автоматизация и неверный секрет отвечают одинаково (нет оракула по идентификаторам автоматизаций), а приостановленная автоматизация отвечает 409: в отличие от «Запустить сейчас» владельца, внешний вызывающий не может пробиться через паузу.

Объект JSON в теле запроса попадает в выполнение как полезная нагрузка триггера, чтобы процедура видела, на что она реагирует:

curl -X POST https://your-host/api/automations/<automationId>/webhook \
  -H "Authorization: Bearer lwh_..." \
  -H "Content-Type: application/json" \
  -d '{"commit":"abc123","branch":"main"}'

Полезная нагрузка добавляется к инструкциям, которые выполняет запуск, под заголовком Trigger payload (JSON): — одинаково для чатов, новых задач Work и связанных процедур. Переносятся только объекты JSON (массивы и скаляры игнорируются), а нагрузка, чья сериализованная форма превышает 4000 символов, отбрасывается, а не обрезается, с предупреждением в логе сервера. Запуск без тела ведёт себя как раньше.

API

Все эндпоинты, кроме запуска веб-хуком, требуют аутентификации и работают только с автоматизациями вызывающего; запуск веб-хуком аутентифицируется секретом самой автоматизации.

Метод	Путь	Назначение
GET	/api/automations	Список
POST	/api/automations	Создание
GET	/api/automations/occurrences?from=&to=	Будущие события
GET	/api/automations/runs	История (фильтруемая)
GET	/api/automations/runs/summary	Непросмотренные + периоды 30 дней
POST	/api/automations/runs/seen	Отметить завершённые просмотренными
GET	/api/automations/:automationId	Прочитать одну
PUT	/api/automations/:automationId	Обновить
DELETE	/api/automations/:automationId	Удалить
POST	/api/automations/:automationId/pause	Приостановить
POST	/api/automations/:automationId/resume	Возобновить
POST	/api/automations/:automationId/run	Запустить сейчас (202 с ID)
POST	/api/automations/:automationId/webhook	Запуск по секрету (202)
POST	/api/automations/:automationId/webhook-secret	Создание или смена секрета
DELETE	/api/automations/:automationId/webhook-secret	Отключение веб-хука

Пользователь может хранить до 50 автоматизаций; имя ограничено 200 символами, инструкция — 20 000.