Ich stelle oft fest, dass ich Automatisierung nutzen möchte, mich aber durch die aktuelle Funktionsweise eingeschränkt fühle. Oftmals gibt es in einem Skript etwas, das ich brauche, aber dieser Teil muss im Kontext eines anderen Skripts funktionieren.
Es scheint, dass dies größtenteils mit der Art und Weise zusammenhängt, wie Automatisierungen derzeit funktionieren und eingerichtet sind. Ich würde gerne sehen, dass die Dinge in Auslöser (Triggers) und Aktionen (Actions) aufgeteilt werden.
Beispielauslöser:
Wenn ein Thema erstellt/aktualisiert wird
Wenn ein Beitrag erstellt/aktualisiert wird
Wenn eine Website-Einstellung geändert wird
Wenn ein Thema geschlossen wird
Wenn ein Benutzer eine Auszeichnung erhält
usw.
Beispielaktionen:
Ein Banner-Thema erstellen
Ein Thema schließen
Auf ein Thema antworten
Ein Thema erstellen
Ein Thema taggen
LLM-Aufruf ausführen
Eine Slack-Nachricht senden
usw.
Diese Einrichtung würde ein paar Dinge ermöglichen:
Mehrere Aktionen, die einem Auslöser zugeordnet werden können (z. B. Wenn Thema erstellt wird > LLM-Aufruf ausführen > Beitrag taggen > Auf das Thema antworten)
Ermöglichen, dass Trigger-Payload-Daten (und nachfolgende Daten, die von Aktionen verfügbar gemacht werden – z. B. LLM-Aufruf-Antwort) dynamisch innerhalb von Aktionen verwendet werden können.
Letztendlich glaube ich, dass Automatisierung viel Potenzial hat, aber jedes Skript ist auf eine Weise isoliert, die es sehr schwierig macht, es an individuelle Bedürfnisse anzupassen. Jedes geht derzeit davon aus, dass die verfügbaren Aktionen für jeden funktionieren werden.
Ich habe angefangen, mit dieser Idee für meinen persönlichen Assistenten Jarvis herumzuspielen:
Was hältst du davon? Es gibt sogar eine interaktive Demo.
Ich finde diese Kette aus Auslöser (Trigger) → Filter → Aktion (Action) → Aktion sehr ansprechend. Sie macht die Automatisierung weitaus flexibler und übersichtlicher.
Ich mag diesen Vorschlag sehr! Er scheint die meisten (wenn nicht sogar alle) Schmerzpunkte zu lösen, die Automatisierungen derzeit haben.
Er fühlt sich auch viel skalierbarer für neue Auslöser (Triggers) und Aktionen (Actions) an. Ich stelle mir vor, dass dies die Tür öffnet, um einfach zusätzliche Auslöser hinzuzufügen – wie theme_created oder theme_updated –, ohne sich Gedanken darüber machen zu müssen, wie diese mit bereits vorhandenen Skripten interagieren. Neue Auslöser würden sofort Zugriff auf jede bestehende Aktion erhalten (Slack-Benachrichtigungen, PN, LLM-Aufrufe usw.). Dasselbe gilt für die Erstellung zusätzlicher Aktionen wie assign_badge, add_to_group, add_to_logs_and_screening und so weiter.
Ohhh, und „Trockenlauf“ (Dry run) und „Ausführungsprotokolle“ (Execution logs) sind ebenfalls genau richtig – dieses Maß an Beobachtbarkeit, wie Dinge tatsächlich ablaufen, ist eine absolute Lebensrettung.
Ich springe nur kurz ein: Zusätzlich zu Auslöser/Filter/Aktion wäre die Möglichkeit, Verzögerungen hinzuzufügen, sehr wertvoll.
(Beispiel: Onboarding/Anstupser, Nachricht eine Woche nach dem Beitritt zur Community senden, dann zwei Monate später, oder wenn ein Mitglied x Tage nach dem Beitritt nicht gepostet oder gelesen hat, etwas tun… definitiv nichts, was irgendeine Community nutzen würde, aber für die aktive Support-Community-Art wie unsere wäre es das!)
Obwohl dies noch in der konzeptionellen Phase ist, werde ich weiter darüber nachdenken
Hinsichtlich der Bedingungen habe ich mich gefragt, wie viel Flexibilität tatsächlich eingebaut werden könnte. Es wäre großartig, etwas wie den Screenshot zu implementieren, bei dem der Benutzer die volle Kontrolle darüber hat, wie Kriterien aufgebaut werden. Den Benutzern zu ermöglichen, Daten aus dem trigger_context auszuwählen, zu definieren, wie diese ausgewertet werden, und festzulegen, womit sie verglichen werden – und ihnen gleichzeitig die Wahl zwischen UND / ODER-Logik zu lassen.
Dies würde komplexere Szenarien ermöglichen und gleichzeitig einfach und intuitiv zu verstehen bleiben, wie zum Beispiel:
wenn {{kategorie}} eines von {{vom Benutzer ausgewählter Wert}} istUND
wenn {{tag}} nicht {{vom Benutzer ausgewählter Wert}} ist
Der Screenshot zeigt auch, was nach der Bedingungsprüfung zu tun ist, aber dies würde sich wahrscheinlich nur auf verzweigte Pipelines beziehen – bei einer linearen Pipeline, die die meisten Fälle abdeckt, würde es wahrscheinlich einfach enden
