Automatisierungen

Automatisierungen führen Anweisungen nach Zeitplan aus und liefern das Ergebnis als normale Chat-Sitzung. Tägliche Zusammenfassung, wöchentliche Prüfung oder Monatsbericht: Jede Ausführung läuft headless auf dem Server, erscheint in deiner Chatliste und kann wie jede Unterhaltung fortgesetzt werden.

Aufbau

Eine Automatisierung hat Namen, Freitextanweisung, bis zu fünf Auslöser, optionales Modell (leer bedeutet Auto: dein Standardmodell zur Laufzeit), Ziel und Benachrichtigung. Chat-Sitzung ist Standard; Work-Aufgabe startet einen isolierten Work-Sandbox, optional mit benannter Richtlinie. Fehler erscheinen bei aktivierten Meldungen auch im Posteingang. Separat davon versendet das Einschalten von Automatisierungsergebnisse unter Einstellungen → Benachrichtigungen → E-Mail-Benachrichtigungen eine E-Mail mit dem Ergebnis jedes Laufs, sobald ein Administrator einen ausgehenden Mailserver eingerichtet hat (siehe Benachrichtigungen). Name und Anweisung sind verschlüsselt; Eigentümer ist der Ersteller.

Auslöser sind once, hourly, daily, weekly, monthly und yearly. Der nächste Lauf ist die früheste kommende Auslösung in der Server-Zeitzone.

Ereignisauslöser

Eine siebte Art, event, hat überhaupt keine Uhr: Sie feuert, sobald eine deiner Benachrichtigungen eintrifft.

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

event kann jeder Benachrichtigungstyp außer automation-failed sein — eine Routine darf sich nicht anhand ihrer eigenen Fehlermeldung selbst neu starten. Das optionale match ist ein Groß-/Kleinschreibung ignorierender Teilstring-Test gegen den Titel der Benachrichtigung; ohne match löst jede Benachrichtigung dieses Typs die Routine aus.

Ein Ereignisauslöser trägt nie zu einem nächsten Lauf-Zeitpunkt bei. Eine Automatisierung, deren Auslöser ausschließlich Ereignisse sind, zeigt daher keinen nächsten Lauf: Liste und Bearbeitungsdialog zeigen stattdessen Wird ausgeführt, wenn …. Einen Ereignisauslöser mit einem Zeitplan zu mischen ist unproblematisch — die geplanten Auslöser treiben die Uhr weiterhin.

Zwei Schutzmechanismen begrenzen die Reichweite. Eine Routine feuert durch Ereignisse höchstens einmal pro Minute, egal wie geschäftig der Stream ist, und die eigene Fehlerbenachrichtigung eines Laufs löst nie erneut die Routine aus, die sie erzeugt hat.

Der Lauf erhält, was ihn ausgelöst hat, an seine Anweisungen angehängt:

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

Ausführung

Ein Scheduler tickt jede Minute hinter einem Koordinations-Lease, sodass nur eine Replik Zeitpläne fortschreibt. Bei Fälligkeit registriert er einen Lauf, reiht automation.run.v1 ein und setzt next_run_at per Compare-and-set, damit jedes Vorkommen höchstens einmal läuft. Der Job erstellt einen Chat und nutzt dieselbe dauerhafte Generierung einschließlich Routing, Persona-Standards und Persistenz.

Nach Ausfall wird das letzte Vorkommen einmal nachgeholt, ältere entfallen. Pausieren löscht den Plan; Fortsetzen oder Bearbeiten berechnet neu. Löschen entfernt den Verlauf per Fremdschlüsselkaskade. Der Job-Ledger markiert Erfolg, Dead-letter-Fehler oder stalled, wenn er nicht innerhalb von 30 Minuten startet.

Work-Ziele verwenden den Work-Lebenszyklus, verlinken die Aufgabe und gelten bei Abschluss oder Eingabeanforderung als erfolgreich. Eine Ergebnis-E-Mail für einen Work-Ziel-Lauf trägt die Zusammenfassung, die der Work-Lauf selbst gespeichert hat — womit der Agent geendet hat, derselbe Text, den der Laufverlauf der Aufgabe zeigt —, und weicht auf die einzeilige Statuszeile der Aufgabe aus, wenn ein Lauf älter ist als gespeicherte Zusammenfassungen. Entzogener Work-Zugriff führt zu work-access-denied. Richtlinie, Netzwerk und Limits werden beim Speichern geprüft. Nur direkte Anbieter und toolfähige Modelle funktionieren.

Agentenroutinen

Eine Work-Automatisierung kann über workTaskId an eine bestehende Work-Aufgabe gebunden werden. Dies ist die Grundlage des Bereichs Routinen im Detailbereich eines Agenten. Eine gebundene Routine erstellt bei der Auslösung keine neue Aufgabe, sondern startet einen Lauf im Workspace und in der Unterhaltung dieser Aufgabe und verwendet deren Modell, Anbieter und Laufzeitrichtlinie. Modell- und Richtlinienfelder der Automatisierung gelten daher nicht; eine angegebene Richtlinie wird beim Speichern entfernt. Die Bindung wird beim Speichern geprüft: Die Aufgabe muss existieren und dem Aufrufer gehören. Ist sie bei der Auslösung gelöscht, scheitert der Lauf mit work-task-missing. Läuft sie bereits oder besitzt eine aktive Vorschau, scheitert das Vorkommen ehrlich mit work-task-busy, statt sich dahinter einzureihen.

Webhook-Auslöser

Neben dem Zeitplan kann ein externes System eine Automatisierung auslösen: CI-Pipeline, Cron-Dienst, Hausautomatisierung. Im Bearbeitungsdialog erzeugt Webhook-Auslöser → Aktivieren ein Secret pro Automatisierung; gespeichert wird nur dessen SHA-256, der Klartext erscheint also genau einmal. Ein Rotieren entwertet das vorherige Secret sofort, Deaktivieren schließt den Endpunkt wieder.

Das externe System löst so aus:

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

(X-Libre-Webhook-Secret: lwh_... funktioniert als alternativer Header.) Die Antwort ist 202 mit der ID des eingereihten Laufs, derselbe manuelle Pfad wie Sofort ausführen; Läufe werden also identisch abgeschlossen, gemeldet und im Verlauf geführt. Der Secret-Vergleich läuft in konstanter Zeit, fehlende Automatisierung und falsches Secret antworten gleich (kein Orakel für Automatisierungs-IDs), und eine pausierte Automatisierung antwortet 409: Anders als der Eigentümer mit Sofort ausführen kann ein externer Aufrufer nicht durch eine Pause hindurch auslösen.

Ein JSON-Objekt im Request-Body reist als Trigger-Payload in den Lauf mit, sodass die Routine sieht, worauf sie reagiert:

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

Die Payload wird den Anweisungen, die der Lauf ausführt, unter einer Überschrift Trigger payload (JSON): angehängt — für Chat-Läufe, neue Work-Aufgaben und gebundene Routinen gleichermaßen. Nur JSON-Objekte werden übernommen (Arrays und skalare Werte werden ignoriert), und eine Payload, deren serialisierte Form 4000 Zeichen übersteigt, wird verworfen statt gekürzt, mit einer Warnung im Server-Protokoll. Ein Auslösen ohne Body verhält sich genau wie zuvor.

API

Alle Endpunkte außer dem Webhook-Auslöser erfordern Authentifizierung und betreffen nur eigene Automatisierungen; der Webhook-Auslöser authentifiziert stattdessen über das Secret der Automatisierung.

Methode	Pfad	Zweck
GET	/api/automations	Auflisten
POST	/api/automations	Erstellen
GET	/api/automations/occurrences?from=&to=	Kommende Vorkommen
GET	/api/automations/runs	Filterbarer Verlauf
GET	/api/automations/runs/summary	Ungesehen und 30-Tage-Gruppen
POST	/api/automations/runs/seen	Fertige als gesehen markieren
GET	/api/automations/:automationId	Lesen
PUT	/api/automations/:automationId	Aktualisieren
DELETE	/api/automations/:automationId	Löschen
POST	/api/automations/:automationId/pause	Pausieren
POST	/api/automations/:automationId/resume	Fortsetzen
POST	/api/automations/:automationId/run	Sofort ausführen (202 mit ID)
POST	/api/automations/:automationId/webhook	Per Secret auslösen (202)
POST	/api/automations/:automationId/webhook-secret	Secret erzeugen oder rotieren
DELETE	/api/automations/:automationId/webhook-secret	Webhook deaktivieren

Pro Benutzer sind 50 Automatisierungen erlaubt; Namen 200 Zeichen, Anweisungen 20,000.