> Markdown twin of https://conduitllm.com/de/automate-with-workflows.html > Baue in Conduit einen Workflow, der Releases beobachtet, jedes mit einem günstigen Modell zusammenfasst und dich nur bei Breaking Changes benachrichtigt. --- Anleitung # Aufgaben mit Conduit Workflows automatisieren Aktualisiert am 15. Oktober 2026 Manche Aufgaben lohnen sich jeden Tag, aber nicht von Hand: einen Changelog lesen, eine Seite auf Änderungen prüfen, zusammenfassen, was in einem Ordner gelandet ist. Workflows in [Conduit](https://conduitllm.com/de/), einer kostenlosen, quelloffenen Desktop-KI-App, erledigen solche Routinen für dich, nach Zeitplan oder sobald etwas Neues erscheint, und melden sich nur, wenn es etwas zu sehen gibt. ## Einleitung Ein Workflow ist eine Liste von Schritten, die der Reihe nach laufen. Manche Schritte rufen Dinge ab oder lesen sie, manche bitten ein Modell, damit zu arbeiten, und manche speichern das Ergebnis oder sagen dir Bescheid. Jeder Schritt kann nutzen, was vorherige Schritte erzeugt haben, und du kannst die ganze Liste von Hand starten, nach Zeitplan oder jedes Mal, wenn ein Feed oder ein Ordner etwas Neues bekommt. In dieser Anleitung baust du einen Workflow, der die Releases eines Tools beobachtet, auf das du dich verlässt. Das Beispiel nutzt [uv](https://github.com/astral-sh/uv), den Python-Paketmanager, weil er häufig released und seine Release Notes ausführlich sind. Bei jedem neuen Release liest der Workflow die Release Notes, bittet ein günstiges Modell um eine kurze Zusammenfassung, speichert sie und sendet dir nur dann eine Desktop-Benachrichtigung, wenn das Release Breaking Changes enthält. Du testest ihn gefahrlos, liest nach, was jeder Schritt getan hat, korrigierst einen Schritt, ohne alles neu auszuführen, und gibst ihn dann frei, damit er von selbst läuft. Du kannst mit jedem GitHub-Projekt mitmachen; nur die Feed-Adresse ändert sich. ## Das Wichtigste in Kürze - Ein Workflow kann von Hand starten, nach Zeitplan (jeden Tag, an Wochentagen oder alle paar Stunden) oder sobald ein neuer Beitrag in einem RSS- oder Atom-Feed erscheint oder eine neue Datei in einem Ordner landet. - Schritte geben Ergebnisse über Werte weiter, die du aus einem Menü einfügst, etwa den Link des Beitrags oder den Text, den ein vorheriger Schritt erzeugt hat. - Jeder Schritt, der ein Modell nutzt, kann sein eigenes wählen, sodass Routinearbeit an ein schnelles, günstiges Modell gehen kann. - Ein Schritt **Nur fortfahren, wenn…** beendet einen Lauf leise, wenn nichts deine Aufmerksamkeit verdient. - Bevor ein Workflow von selbst läuft, listet er auf, was er alles tun darf, und du gibst die Liste frei. Alles darüber hinaus hält den Lauf an und fragt nach. - Jeder Lauf hält fest, was jeder Schritt getan hat, und du kannst ab jedem Schritt neu ausführen, ohne die vorherigen zu wiederholen. - Derselbe Workflow lässt sich als Zeichenfläche darstellen, kann je nach Bedingung verzweigen und Schritte nebeneinander ausführen und kann Arbeit an Agenten weitergeben, die vorher nachfragen. ## Voraussetzungen Für diese Anleitung brauchst du Folgendes: - **Conduit, installiert** unter Windows, macOS oder Linux. Lade das neueste Release von der [Releases-Seite](https://github.com/runningpixels/conduit/releases) herunter. - **Einen in Conduit eingerichteten Modellanbieter** mit deinem eigenen API-Schlüssel. Diese Anleitung nutzt für die Zusammenfassungen GLM 5.3 Flash über OpenRouter, aber jeder Anbieter funktioniert, auch ein lokales Modell. Wie du einen einrichtest, zeigt eine der [Anbieter-Anleitungen](https://conduitllm.com/providers.html) (auf Englisch), etwa [Use OpenRouter in a desktop app](https://conduitllm.com/providers/openrouter.html) (auf Englisch). - **Erlaubte Desktop-Benachrichtigungen** für Conduit in den Einstellungen deines Betriebssystems, damit du die Meldungen des Workflows siehst. - **(Optional) Die Adresse eines Feeds, der dich interessiert.** Jedes GitHub-Repository veröffentlicht seine Releases als Atom-Feed unter `https://github.com///releases.atom`. ## Schritt 1 — Mit einem fertigen Workflow beginnen Conduit bringt fertige Workflows mit, die du unverändert nutzen oder anpassen kannst. In diesem Schritt legst du einen an, der bereits einen Feed beobachtet, und nutzt ihn als Grundlage für den Release-Beobachter. Wähle in der seitlichen Leiste **Workflows** oder drücke Strg+7 (⌘6 unter macOS). Hast du noch keine Workflows, listet die Seite die fertigen unter **Noch keine Workflows** auf; andernfalls wähle **Neuer Workflow**, um sie zu sehen. Die Liste enthält: - **Morgen-Briefing** — liest zwei Websites und speichert die wichtigsten Meldungen beider als ein Briefing. - **Eine Seite beobachten** — prüft eine Seite und sagt dir nur Bescheid, wenn sie sich geändert hat. - **Themenbeobachtung** und **Wöchentliche Recherche-Übersicht** — suchen oder recherchieren zu einem Thema und halten eine Übersicht aktuell. - **Foliensatz mit Wochenzahlen** und **Monatsbericht-Abschnitt** — aktualisieren einen Slides-Foliensatz oder einen Writing-Entwurf, den du auswählst. - **Neue Beiträge zusammenfassen** und **Eingangsordner** — laufen einmal für jeden neuen Beitrag in einem Feed oder jede neue Datei in einem Ordner. - **Notizen mit meinen Dokumenten abgleichen** — vergleicht eine Notizdatei mit Passagen aus deinen Dokumentsammlungen. - **Ganz neu beginnen** — ein leerer Workflow, den du Schritt für Schritt aufbaust. Such **Neue Beiträge zusammenfassen** und wähle **Diese Vorlage verwenden**. Conduit legt den Workflow an und öffnet seine Seite. Der neue Workflow hat bereits vier Schritte: Er ruft den Beitrag ab, bittet das Modell um eine Zusammenfassung, speichert sie und zeigt eine Benachrichtigung. Noch läuft nichts; ein Workflow, der einen Feed beobachtet, beginnt erst damit, wenn du **Automatisch ausführen** einschaltest, was du in Schritt 9 tust. Als Nächstes richtest du ihn auf die uv-Releases aus. ## Schritt 2 — Den Workflow auf einen Releases-Feed richten Was einen Workflow startet, legst du im Bereich **Startet, wenn** fest. In diesem Schritt änderst du den Feed dieses Workflows vom Rust-Blog auf die Releases von uv. Wähle auf der Seite des Workflows **Bearbeiten**. Die Kopfzeile zeigt den Namen des Workflows sowie **Als JSON bearbeiten**, **Abbrechen** und **Speichern**. Links stehen die Schritte, rechts hält eine Seitenleiste **Start** (mit den Optionen unter **Startet, wenn**), danach **Bei jedem Lauf abgefragt**, **Helfer** und **Einstellungen des Workflows**, wo du Name, Beschreibung, Modellanbieter und Ordner festlegst. **Hinweis:** Workflows lassen sich auch als Zeichenfläche darstellen. Über den Schritten wählt ein Schalter **Zeichenfläche** / **Liste** die Ansicht, und Conduit merkt sich deine Wahl. Diese Anleitung arbeitet in der Listenansicht, wähle also **Liste**, um die beschriebenen Schrittkarten zu sehen. Nimm diese Änderungen vor: 1. Ändere unter **Einstellungen des Workflows** den **Namen** in `uv releases`. 2. Lass unter **Startet, wenn** die Option **ein neuer Beitrag in einem Feed erscheint** gewählt und setze **Feed-Adresse** auf `https://github.com/astral-sh/uv/releases.atom`. 3. Setze **Prüfen alle** auf **360 Minuten**. Ein Release-Beobachter muss nicht alle 30 Minuten nachsehen; viermal am Tag genügt völlig. Die anderen Optionen unter **Startet, wenn** sind **Nur wenn ich ihn starte oder nach Zeitplan** für Workflows, die du von Hand oder zu festen Zeiten startest; **eine neue Datei im Ordner des Workflows erscheint**, wofür zuerst unter **Einstellungen des Workflows** ein Ordner gewählt sein muss; und **ein Connector etwas Neues meldet**. **Hinweis:** Beim ersten Blick auf den Feed merkt sich der Workflow nur die Releases, die schon da sind. Er fasst keine Altlast alter Releases zusammen, sondern nur die, die nach dem Einschalten erscheinen, das älteste zuerst. Kommen mehrere auf einmal, startet er pro Prüfung höchstens fünf Läufe, die übrigen warten auf die nächste. Der Workflow beobachtet jetzt den richtigen Feed. Als Nächstes siehst du, wie sein erster Schritt den Beitrag nutzt, der den Lauf ausgelöst hat. ## Schritt 3 — Die Release Notes abrufen Jeder Lauf eines Feed-Workflows betrifft einen Beitrag, und dessen Angaben stehen jedem Schritt als Werte zur Verfügung. In diesem Schritt siehst du, wie der erste Schritt einen davon nutzt, um die Release Notes abzurufen. Scrolle zu **Schritte**. Jeder Schritt ist eine Karte, betitelt mit Nummer und Typ, etwa **1. Seiten abrufen**, mit einer kurzen ID daneben, hier `fetch`. Über die ID beziehen sich spätere Schritte auf diesen. Das Feld **Seite 1** des Abruf-Schritts enthält einen Chip für den Link des Beitrags. Solche Werte fügst du über das Menü **Wert einfügen…** neben jedem Feld ein; es listet, was an dieser Stelle des Workflows verfügbar ist: - **Vom Auslöser** — Titel, Link, Zusammenfassung, Datum und ID des Beitrags. - **Vorherige Schritte** — was die Schritte darüber erzeugt haben, etwa *fetch · Text der ersten Seite*. - **Bei jedem Lauf abgefragt** — Werte, die du beim Starten des Workflows ausfüllst, falls du welche hinzufügst. Lass den Abruf-Schritt, wie er ist. Bei uv ist der Link jedes Beitrags die GitHub-Seite des jeweiligen Releases, der Schritt ruft also die Release Notes ab. Ein Abruf-Schritt liest bis zu zehn Seiten, behält von jeder bis zu 50.000 Zeichen und ruft nur öffentliche https-Adressen ab. Beachte die Einstellung **Bei Fehler erneut versuchen** auf der Karte: Ein Abruf wird standardmäßig zweimal wiederholt, was kurze Netzwerkprobleme überbrückt. Jeder Schritt hat außerdem **Weiterlaufen, wenn dieser Schritt fehlschlägt**. Lass das hier ausgeschaltet; ohne die Release Notes gibt es nichts zusammenzufassen. Der Workflow kann jetzt jedes neue Release lesen. Als Nächstes sagst du dem Modell, was es damit tun soll. ## Schritt 4 — Den Zusammenfassungs-Schritt schreiben und sein Modell wählen Ein Schritt **Das Modell fragen** schickt eine Anweisung und etwas Text an ein Modell und behält die Antwort. In diesem Schritt schreibst du eine Anweisung, die zu Release Notes passt, und wählst allein für diesen Schritt ein günstiges Modell. Such Schritt 2, **Das Modell fragen**, mit der ID `summary`. Ersetze seine **Anweisung** durch Folgendes: ``` Summarize these release notes for a developer who uses this tool every day. List new features and fixes in at most five bullet points. Then add a section titled "Breaking changes" that lists anything that could break an existing project, such as removed options, changed defaults or new minimum versions. If there are none, write exactly: No breaking changes. ``` Das Feld **Zu bearbeitender Text** enthält bereits den Titel des Beitrags gefolgt vom abgerufenen Text, das Modell weiß also, welches Release es liest. Lass es, wie es ist. Die letzte Zeile der Anweisung ist wichtig. In Schritt 6 nutzt du genau diesen Satz, um zu entscheiden, ob du benachrichtigt wirst, deshalb soll das Modell ihn jedes Mal gleich schreiben. Wähle nun das Modell. Unter **Modell für diesen Schritt** steht standardmäßig **Modell des Workflows verwenden**, und die Einstellung **Modell** des Workflows oben im Editor steht standardmäßig auf **Dem Chat-Modell folgen**, also auf dem Modell, das du zuletzt in einem Chat gewählt hast. Wähle für eine Routine-Zusammenfassung stattdessen ein schnelles, günstiges Modell. Diese Anleitung nutzt **GLM 5.3 Flash** über OpenRouter. **Hinweis:** Mit der Modellwahl pro Schritt kann ein Workflow mehrere Modelle mischen: ein günstiges für Massen-Zusammenfassungen, ein stärkeres für den abschließenden Text oder ein lokales Modell für Schritte, die mit privaten Dateien arbeiten. Ist der Anbieter, den ein Schritt nennt, nicht mehr eingerichtet, nutzt der Schritt das Chat-Modell und der Lauf vermerkt die Änderung, statt fehlzuschlagen. Der Workflow erzeugt jetzt eine Zusammenfassung mit einem vorhersehbaren letzten Abschnitt. Als Nächstes sorgst du dafür, dass jede Zusammenfassung aufbewahrt wird. ## Schritt 5 — Jede Zusammenfassung speichern Ein Schritt **Ein Dokument speichern** legt Text als Dokument ab, das du später öffnen kannst. In diesem Schritt stellst du ihn so ein, dass er pro Release ein Dokument behält. Such Schritt 3, **Ein Dokument speichern**, und stelle ein: - **Titel** — `uv ` gefolgt vom Chip *Titel des Beitrags*, damit jedes Dokument nach seinem Release benannt ist. - **Inhalt** — lass den Chip der Zusammenfassung und die Zeile `Source:` mit dem Link des Beitrags stehen. - **Speichern als** — **Dokument**. - **Bei jedem Lauf** — **Fügt ein neues Dokument hinzu**. Die andere Option für **Bei jedem Lauf**, **Ersetzt dasselbe Dokument**, behält ein einziges Dokument mit dem neuesten Ergebnis, was zu einer Seitenbeobachtung oder einem täglichen Briefing passt. Für eine Release-Historie willst du ein Dokument pro Release. Das Speichern steht absichtlich vor der Prüfung, die du als Nächstes hinzufügst: So wird jedes Release festgehalten, auch die, die heute nicht deine Aufmerksamkeit brauchen. Als Nächstes fügst du den Schritt hinzu, der entscheidet, ob du benachrichtigt wirst. ## Schritt 6 — Nur bei Breaking Changes benachrichtigen Ein Schritt **Nur fortfahren, wenn…** prüft einen Wert und beendet den Lauf leise, wenn die Prüfung scheitert. In diesem Schritt fügst du einen zwischen dem Speichern und der Benachrichtigung ein, damit du nur bei Releases mit Breaking Changes benachrichtigt wirst. Öffne am Ende von **Schritte** **Schritt hinzufügen…** und wähle **Nur fortfahren, wenn…**. Der neue Schritt wird am Ende angefügt; verschiebe ihn mit seiner ↑-Schaltfläche über **Eine Benachrichtigung anzeigen**. Stelle dann ein: - **Zu prüfender Wert** — füge *summary · Text* aus **Vorherige Schritte** ein. - **Nur fortfahren, wenn es** — **nicht enthält**. - **Text** — `No breaking changes`. Der Vergleich ignoriert Groß- und Kleinschreibung sowie überzählige Leerzeichen. Die anderen Prüfungen sind **sich seit dem letzten Lauf geändert hat**, **nicht leer ist**, **leer ist**, **enthält** und **gleich ist**; die erste nutzt die Vorlage **Eine Seite beobachten**, um dir nur dann Bescheid zu sagen, wenn sich eine Seite ändert. Aktualisiere schließlich Schritt 5, **Eine Benachrichtigung anzeigen**. Setze **Titel** auf `Breaking changes in uv` und **Nachricht** auf den Chip *Titel des Beitrags*. Vergisst das Modell einmal den genauen Satz, lässt die Prüfung die Benachrichtigung durch; im schlimmsten Fall bekommst du also eine Benachrichtigung zu viel, aber nie entgeht dir ein Breaking Change. Wähle **Speichern**. Passt etwas nicht zusammen, etwa weil ein Schritt einen Wert liest, den es noch nicht gibt, führt der Editor es unter **Behebe dies vor dem Speichern:** auf und lässt **Speichern** deaktiviert, bis es behoben ist. Nach dem Speichern listet die Seite des Workflows die fünf Schritte in einfachen Worten auf. Der Workflow ist fertig. Bevor du ihn von selbst laufen lässt, testest du ihn. ## Schritt 7 — Den Workflow mit „Jetzt ausführen“ testen Ein Testlauf zeigt dir mit echten Daten genau, was der Workflow tun wird. In diesem Schritt führst du ihn einmal von Hand aus. Wähle auf der Seite des Workflows **Jetzt ausführen**. Bei einem Workflow, der einen Feed beobachtet, nutzt ein Lauf von Hand den neuesten Beitrag des Feeds als Test, du musst also nicht auf das nächste Release warten. Die Schaltfläche wechselt zu **Wird ausgeführt…**, eine Schaltfläche **Stoppen** erscheint, und der Lauf taucht unter **Letzte Läufe** als **Testlauf:** gefolgt vom Namen des Releases auf. Fast die gesamte Laufzeit entfällt auf den Modell-Schritt. Mit GLM 5.3 Flash dauerte der hier gezeigte Testlauf weniger als eine Minute. Wenn er fertig ist, lautet sein Status **Abgeschlossen**, wenn das Release Breaking Changes hatte und du eine Benachrichtigung bekommen hast, oder **Nichts Neues**, wenn die Prüfung den Lauf nach dem Speichern der Zusammenfassung beendet hat. In beiden Fällen verweist **Gespeichert:** auf die gespeicherte Zusammenfassung. **Hinweis:** Freigaben halten einen Lauf, den du von Hand startest, nicht auf, denn du bist dabei und kannst zusehen. Freigaben, die du in Schritt 9 einrichtest, gelten für Läufe, die niemand beobachtet. Rechne damit, dass ein Modell Grenzfälle von Lauf zu Lauf unterschiedlich beurteilt. uv 0.12.24 enthielt vor allem Fehlerbehebungen, von denen einige uv strenger machen, etwa die Prüfung mitgelieferter Hashes, auch wenn die Hash-Prüfung ausgeschaltet ist. In zwei Testläufen mit diesem Release führte GLM 5.3 Flash diese Fixes einmal als Breaking Changes auf und schrieb einmal *No breaking changes.* Willst du über solche Änderungen Bescheid wissen, sag das in der Anweisung, zum Beispiel: *Count bug fixes that make uv stricter as breaking changes.* Wähle für Schritte wie diesen ein Modell, das direkt antwortet. Ein Modell, das vor der Antwort lange nachdenkt, kann bei einer langen Seite viele Minuten brauchen, und ein Lauf hält an, sobald er sein Limit von 30 Minuten erreicht. Als Nächstes öffnest du den Lauf und siehst, was jeder Schritt getan hat. ## Schritt 8 — Einen Lauf lesen und einen Schritt neu ausführen Jeder Lauf hält zu jedem Schritt fest, was hineinging, was herauskam, welches Modell er nutzte und wie lange er dauerte. In diesem Schritt liest du diese Aufzeichnung, änderst die Zusammenfassung und führst nur die Schritte neu aus, bei denen es nötig ist. Wähle unter **Letzte Läufe** den Testlauf. Der Bereich **Was dieser Lauf getan hat** listet die Schritte mit je einem Status auf: **Abgeschlossen**, **Fehlgeschlagen**, **Übersprungen** oder **Wiederverwendet**. Hat die Prüfung den Lauf beendet, steht dort **Nichts Neues – bei `check` angehalten**, mit der ID des Schritts, der ihn beendet hat. Klappe den Schritt `summary` auf. Eine Zeile wie *… verwendet (OpenRouter)* nennt das Modell und den Anbieter, auf dem er lief, und darunter stehen **Eingabe** und **Ausgabe** des Schritts. Wähle unter **Gespeichert:** den Namen des Dokuments, um die Zusammenfassung selbst zu öffnen. Angenommen, die Zusammenfassung ist dir zu lang. Wähle **Bearbeiten**, ändere `at most five bullet points` in `at most three bullet points` und speichere. Öffne dann den Testlauf erneut, such den Schritt `summary` und wähle **Ab diesem Schritt erneut ausführen**. Der neue Lauf markiert den Abruf-Schritt als **Wiederverwendet**: Er übernimmt die Release Notes aus dem vorherigen Lauf, statt sie erneut abzurufen, und führt die Zusammenfassung, das Speichern, die Prüfung und die Benachrichtigung mit deiner neuen Anweisung aus. Im unten gezeigten Lauf dauerte die erneute Ausführung 10 Sekunden gegenüber 16 beim vollständigen Lauf, weil die Seite nicht noch einmal abgerufen wurde. Bei einem längeren Workflow spart das Zeit und Modellaufrufe. Schlägt ein Lauf fehl, zeigt dieselbe Ansicht in einfachen Worten, welcher Schritt fehlgeschlagen ist und warum. Korrigiere diesen Schritt und führe dann ab ihm neu aus. Der Workflow tut, was du willst. Als Nächstes lässt du ihn von selbst laufen. ## Schritt 9 — Automatische Läufe einschalten Ein Workflow, der von selbst läuft, muss zuerst freigegeben werden. In diesem Schritt prüfst du, was der Release-Beobachter tun darf, und schaltest ihn ein. Wähle auf der Seite des Workflows den Chip **Startet** unter der Beschreibung (in der Ansicht Zeichenfläche wählst du stattdessen den Schritt Start). Die Seitenleiste Start öffnet sich mit einem Bereich **Zeitplan**; hake **Automatisch ausführen** an. (**← Zurück** in der Seitenleiste führt zum Workflow zurück.) Conduit zeigt ein Fenster mit dem Titel **Ihn von selbst laufen lassen?**, das alles auflistet, was der Workflow ohne Rückfrage tun darf. Für den Release-Beobachter lautet die Liste: - **Seiten auf github.com lesen** — um den Feed zu lesen. - **Seiten an den Adressen lesen, die der Schritt „fetch“ beim Ausführen erhält** — die Adresse des Abruf-Schritts stammt aus dem Feed, Conduit kann die Website deshalb nicht im Voraus nennen. - **Text an OpenRouter senden, online** — für den Zusammenfassungs-Schritt. - **Dokumente speichern**. Benachrichtigungen und die Prüfung brauchen keine Freigabe. Wähle **Erlauben und aktivieren**. Der Bereich zeigt nun **Überwacht github.com alle 360 Min.**, und eine Zeile, die mit **Wenn er von selbst läuft, darf er:** beginnt, hält die freigegebene Liste im Blick. Bearbeitest du den Workflow später so, dass er mehr braucht, etwa eine neue Website oder einen weiteren Anbieter, zeigt die Seite **Er braucht dein OK für mehr** mit einer Schaltfläche **Zustimmen**. Bis du zustimmst, hält ein automatischer Lauf, der diesen Schritt erreicht, an und fragt nach. Du bekommst eine Benachrichtigung, der Lauf zeigt **Wartet auf dich**, und die Startseite führt ihn unter **Braucht dich** auf. Du kannst **Einmal erlauben**, **Immer erlauben** oder **Nicht erlauben** wählen; antwortet innerhalb eines Tages niemand, wird der Schritt nicht ausgeführt. Wenn du automatische Läufe zum ersten Mal einschaltest, bietet Conduit außerdem an, **Im Infobereich weiterlaufen zu lassen**. Automatische Läufe finden nur statt, solange Conduit ausgeführt wird, nimm das Angebot also an, wenn du das Fenster oft schließt. Du kannst das später im selben Bereich ändern, zusammen mit **Conduit beim Anmelden im Infobereich starten**. **Hinweis:** Willst du einen Workflow zu festen Zeiten statt bei einer Feed-Änderung starten, wähle unter **Startet, wenn** die Option **Nur wenn ich ihn starte oder nach Zeitplan**. Dann bietet **Automatisch ausführen** **Jeden Tag** oder **An Wochentagen** zu einer Uhrzeit deiner Wahl an, oder **Alle paar Stunden**: alle 1, 2, 3, 4, 6, 8, 12 oder 24 Stunden. Der Release-Beobachter läuft jetzt von selbst. Im letzten Schritt siehst du einen schnelleren Weg, den nächsten zu starten. ## Schritt 10 — Einen Workflow beschreiben, statt ihn zu bauen Du musst nicht jeden Workflow Schritt für Schritt bauen. In diesem Schritt lässt du Conduit aus einem Satz einen entwerfen. Wähle auf der Seite Workflows **Neuer Workflow**. Tippe unter **Workflow beschreiben** ein: Lies jeden Werktag um 9:00 Uhr die Titelseite von Hacker News und die von Lobsters und speichere eine Liste der Beiträge über Rust oder Python. Wähle **Entwurf erstellen**. Das Chat-Modell schreibt einen Workflow, Conduit prüft ihn genauso wie einen Workflow, den du speicherst, und schickt Probleme zur Korrektur zurück an das Modell. Der Entwurf öffnet sich *ungespeichert* im Editor: Nichts wird gespeichert oder geplant, bis du **Speichern** wählst und ihn selbst einschaltest. Das Modell wählt nie Dinge, die nur du wählen kannst, etwa einen Ordner, einen Foliensatz oder eine Dokumentsammlung, und es schaltet keine Zeitpläne ein. Braucht ein Entwurf etwas davon, zeigt der Editor **Vor dem Speichern noch auszufüllen** mit einer kurzen Liste. Für die obige Beschreibung lautet sie *Zeitplan einschalten: jeden Werktag um 9:00 Uhr.*, eine Erinnerung, den Zeitplan nach dem Speichern auf der Seite des Workflows einzustellen. Es gibt zwei weitere Wege, einen Workflow aus Worten zu starten: - **Von der Startseite.** Tippe ins Eingabefeld, was du willst, und wähle den Chip **Automatisieren**; Conduit öffnet Workflows und entwirft ihn. - **Aus einem Chat.** Hast du etwas von Hand in einem Chat erledigt, öffne die Befehlspalette mit Strg+K (⌘K unter macOS) und wähle **Chat als Workflow speichern…**. Der Entwurf beruht darauf, was du gefragt hast und welche Tools genutzt wurden; die Seiten oder Dokumente selbst sieht das Modell nicht. So oder so: Sieh den Entwurf durch, teste ihn mit **Jetzt ausführen** und schalte erst dann **Automatisch ausführen** ein. ## Weiter gehen: Zeichenfläche, Verzweigungen und Agenten Der Release-Beobachter ist eine gerade Linie, aber ein Workflow muss das nicht sein. Vier Dinge bauen auf dem auf, was du gerade gemacht hast. - **Die Zeichenfläche.** Schalte in der Schrittansicht auf **Zeichenfläche**, um den Start, jeden Schritt, Schleifen und die Linien dazwischen zu sehen. Während eines Laufs zeigt jeder Schritt, ob er läuft, fertig ist, fehlgeschlagen ist, übersprungen wurde oder auf dich wartet, und die Auswahl eines Schritts zeigt seine Eingabe und Ausgabe. Im Editor fügst du Schritte aus einer Palette hinzu, ziehst sie in eine andere Reihenfolge und ziehst eine Verbindung von einem Schritt zu einem anderen, um zu wählen, welche Ausgabe in welches Feld geht, statt es einzutippen. - **Verzweigungen und Schritte nebeneinander.** Ein Schritt **Wenn… sonst** schickt den Lauf auf einen Ja- oder Nein-Pfad; der nicht genommene Pfad wird als *Nicht genommen* festgehalten. Ein Schritt kann auf mehrere frühere Schritte warten, sodass Schritte, die nicht voneinander abhängen, nebeneinander laufen, bis zu vier gleichzeitig, und ein späterer Schritt sie zusammenführen kann. Ersetzt du im Release-Beobachter den Schritt **Nur fortfahren, wenn…** zum Beispiel durch eine Verzweigung, könnte er auf dem einen Pfad benachrichtigen und auf dem anderen nur speichern. - **Ergebnisse.** Alles, was ein fertiger Lauf gespeichert hat, bleibt mit Vorschau erhalten. Öffne den Bereich **Ergebnisse** eines Workflows oder die Liste Ergebnisse in der Seitenleiste von Workflows für alle Workflows und lies es mit **Öffnen**. - **Agenten.** Ein Schritt **Das Modell Tools verwenden lassen** kann bis zu zehn Connector-Tools nutzen und Aufgaben an Helfer weitergeben, die du definierst, jeder mit eigenen Anweisungen, eigenem Modell und eigenem Token-Limit. Ein Connector-Tool, das etwas sendet, postet oder ändert, hält den Lauf an und fragt nach, und der **Eingang** sammelt alles, worauf deine Workflows warten. Ist **Einstellungen → Computer** eingeschaltet, kann ein Agent außerdem Befehle ausführen und Dateien in einem Ordner ändern, den du nennst, und jeder Befehl fragt zuerst nach, es sei denn, eine Regel, die du erlaubt hast, deckt ihn ab. Die [Dokumentation zu Workflows](https://conduitllm.com/docs.html#workflows) listet die Grenzen auf. ## Alle Schritttypen auf einen Blick Der Release-Beobachter nutzt fünf Arten von Schritten. Hier sind alle, so wie sie im Menü **Schritt hinzufügen…** erscheinen: | Schritt | Was er tut | | --- | --- | | Seiten abrufen | Liest bis zu zehn Webseiten, auch PDFs. Bis zu 50.000 Zeichen pro Seite. | | Das Web durchsuchen | Sucht mit dem in den Einstellungen gewählten Such-Backend und liefert bis zu 20 Ergebnisse. | | Eine Datei lesen | Liest eine Text-, Markdown-, CSV-, JSON-, PDF- oder Word-Datei aus dem Ordner des Workflows und von nirgendwo sonst. | | Text in eine Tabelle umwandeln | Macht aus CSV, TSV oder JSON Zeilen und Spalten, die spätere Schritte nutzen können. | | Ein Thema recherchieren | Führt eine Recherche der Tiefe Schnell oder Standard aus und erstellt einen Bericht mit Quellenangaben. | | Meine Dokumente durchsuchen | Findet in den Dokumentsammlungen, die du auswählst, die Passagen, die am besten zu einer Anfrage passen. | | Einen Connector nutzen | Ruft ein Tool eines deiner Connectors (MCP-Server) auf. Tools, die nur lesen, laufen von selbst; ein Tool, das etwas sendet, postet oder ändert, hält den Lauf an und fragt nach. | | Das Modell fragen | Schickt eine Anweisung und etwas Text ohne Tools an ein Modell und behält die Antwort. | | Das Modell Tools verwenden lassen | Lässt das Modell vor seiner Antwort einige Male im Web suchen, Seiten lesen, die Uhrzeit prüfen, rechnen, Connector-Tools nutzen und Aufgaben an Helfer weitergeben. Wenn du es einschaltest, kann es auch Befehle ausführen und Dateien im Ordner des Workflows ändern. | | Einen Foliensatz aktualisieren | Ändert einen Slides-Foliensatz, den du auswählst, nach Anweisung. Angehefteter Text wird nie geändert, und die Änderung lässt sich rückgängig machen. | | Einen Entwurf aktualisieren | Ändert einen Writing-Entwurf, den du auswählst, auf die gleiche Weise. | | Text schreiben | Setzt Werte aus vorherigen Schritten ohne Modell zu einem Text zusammen. | | Für jedes Element wiederholen | Führt die darin enthaltenen Schritte einmal für jedes Element einer Liste aus, bis zu 50 Elemente. | | Ein Dokument speichern | Speichert ein Dokument oder eine Webseite in Conduit, entweder bei jedem Lauf ein neues oder dasselbe ersetzt. | | Datei speichern | Schreibt eine Markdown-, Text-, CSV-, JSON- oder HTML-Datei in den Exportordner von Conduit. | | Gespeicherten Fakt vorschlagen | Schlägt etwas für den Speicher vor. Nichts wird gemerkt, bis du es annimmst. | | Mich fragen | Hält den Lauf an, um dir eine Frage zu stellen, mit Auswahl oder getippter Antwort und einem Standardwert, falls niemand antwortet. | | Eine Benachrichtigung anzeigen | Zeigt eine Desktop-Benachrichtigung, auf Wunsch nur, wenn sie sich von der des letzten Laufs unterscheidet. | | Nur fortfahren, wenn… | Beendet den Lauf leise, als *Nichts Neues*, es sei denn, ein Wert besteht eine Prüfung. | | Wenn… sonst | Schickt den Lauf mit denselben Prüfungen auf einen Ja- oder Nein-Pfad. Schritte hinter dem anderen Pfad werden als *Nicht genommen* festgehalten. | Ein Workflow kann bis zu 50 Schritte enthalten. Jedes Textfeld in jedem Schritt kann eingefügte Werte enthalten, und die ganze Definition lässt sich im Editor mit **Als JSON bearbeiten** von Hand ändern. In dieser Ansicht werden eingefügte Werte als `{{steps.summary.text}}` oder `{{trigger.link}}` geschrieben; um die geschweiften Klammern selbst zu schreiben, setze einen Backslash davor: `\{{`. Zum Nachschlagen: So zeigt die JSON-Ansicht den Release-Beobachter, den du gebaut hast: ``` { "steps": [ { "id": "fetch", "type": "fetch_page", "urls": [ "{{trigger.link}}" ] }, { "id": "summary", "input": "{{trigger.title}}\n\n{{steps.fetch.text}}", "model": { "model": "z-ai/glm-5.3-flash", "provider": "openrouter" }, "prompt": "Summarize these release notes for a developer who uses this tool every day.\n…", "type": "summarize" }, { "content": "{{steps.summary.text}}\n\nSource: {{trigger.link}}", "id": "save", "mode": "create", "title": "uv {{trigger.title}}", "type": "save_artifact" }, { "id": "check", "is": "not_contains", "text": "No breaking changes", "type": "condition", "value": "{{steps.summary.text}}" }, { "body": "{{trigger.title}}", "id": "notify", "title": "Breaking changes in uv", "type": "notify" } ], "trigger": { "everyMinutes": 360, "kind": "feed", "url": "https://github.com/astral-sh/uv/releases.atom" } } ``` ## Fragen **Läuft ein Workflow, wenn Conduit geschlossen ist?** Nein. Geplante und automatische Läufe finden statt, solange Conduit ausgeführt wird. Damit sie auch nach dem Schließen des Fensters weiterlaufen, schalte im Bereich **Zeitplan** des Workflows **Beim Schließen des Fensters im Infobereich weiterlaufen lassen** ein und optional **Conduit beim Anmelden im Infobereich starten**. Ein geplanter Lauf, der verpasst wurde, während Conduit geschlossen war, wird beim nächsten Start einmal nachgeholt, nicht einmal für jeden verpassten Zeitpunkt. **Was kostet ein Workflow-Lauf?** Conduit ist kostenlos. Schritte, die Seiten abrufen, Dateien lesen, Bedingungen prüfen, Dokumente speichern oder Benachrichtigungen anzeigen, rufen kein Modell auf und kosten nichts. Schritte, die das Modell fragen, rechnet dein Anbieter über deinen eigenen Schlüssel ab, wie jede Chat-Nachricht. Jeder Lauf ist auf 30 Minuten Laufzeit und 500.000 Modell-Token begrenzt und hält mit einer Meldung an, wenn er darüber hinausgeht. Jeder Modellaufruf eines Workflows wird unter **Einstellungen → Nutzung & Kosten** festgehalten. **Kann ein Workflow etwas in meinen anderen Apps verändern?** Ja, mit deiner Freigabe. Ein Schritt **Einen Connector nutzen** führt Tools, die nur lesen, etwa Tickets auflisten oder einen Kalender lesen, von selbst aus. Ein Tool, das etwas sendet, postet oder ändert, hält den Lauf an und zeigt den genauen Aufruf, und du wählst **Senden**, **Bearbeiten** oder **Nicht senden**; du kannst eine Aktion in diesem Workflow ab jetzt erlauben. Innerhalb von Conduit kann ein Workflow Dokumente und Dateien speichern, einen Fakt zum Merken vorschlagen, den du annehmen kannst, und einen Slides-Foliensatz oder Writing-Entwurf aktualisieren, den du auswählst. Aktualisierungen berühren nie Text, den du angeheftet hast, und mit **Dieses Update rückgängig machen** im Lauf stellst du den Foliensatz oder Entwurf wieder her. **Kann eine Webseite einen Workflow übernehmen?** Eine abgerufene Seite ist Text, mit dem spätere Schritte arbeiten; sie kann keine Schritte hinzufügen und keine Freigaben ändern. Ein Schritt **Das Modell fragen** hat überhaupt keine Tools, eine Seite mit Anweisungen kann ihn also nichts abrufen, suchen oder speichern lassen. Ein Schritt **Das Modell Tools verwenden lassen** behandelt das, was er aus dem Web liest, als Daten und nicht als Anweisungen und hat nur die schreibgeschützten Tools, die du ankreuzt. Ein Lauf, den niemand beobachtet, kann nur tun, was du beim Einschalten der automatischen Läufe freigegeben hast. **Kann ich einen Workflow mit anderen teilen?** Eine Schaltfläche zum Importieren oder Exportieren gibt es noch nicht. Du kannst einen Workflow von Hand kopieren: Wähle **Bearbeiten**, dann **Als JSON bearbeiten**, und kopiere die Definition. Die andere Person legt einen Workflow mit **Ganz neu beginnen** an, öffnet **Als JSON bearbeiten** und fügt sie ein. Freigaben sind nicht Teil der Definition, deshalb muss sie der Empfänger erneut erteilen, bevor der Workflow von selbst läuft. **Kann ich ein lokales Modell verwenden?** Ja. Wähle ein Modell von Ollama oder LM Studio als Modell des Workflows oder unter **Modell für diesen Schritt**. Im Nur-lokal-Modus schlägt ein Schritt, der einen Cloud-Anbieter nennt, mit einer entsprechenden Meldung fehl, statt Text online zu senden. ## Fazit In dieser Anleitung hast du einen Workflow gebaut, der die Releases von uv beobachtet: Er ruft die Notes jedes neuen Releases ab, fasst sie mit einem günstigen Modell zusammen, speichert jede Zusammenfassung und benachrichtigt dich nur bei Breaking Changes. Du hast ihn mit einem echten Release getestet, nachgelesen, was jeder Schritt getan hat, ab dem geänderten Schritt neu ausgeführt und genau freigegeben, was er von selbst tun darf. Dasselbe Muster — etwas abrufen, das Modell dazu befragen, das Ergebnis aufbewahren und nur Bescheid sagen, wenn es zählt — passt zu vielen Routinen. Richte eine Kopie auf die Releases jedes Tools, von dem dein Projekt abhängt, nutze **Eine Seite beobachten** für eine Preis- oder Statusseite oder lass **Eingangsordner** jede Datei zusammenfassen, die du in einen Ordner legst. Weiter geht es mit diesen Anleitungen: - [Die Dokumentation zu Workflows](https://conduitllm.com/de/docs.html#workflows) mit allen Einstellungen und Grenzen. - [Deep Research mit Conduit und Exa](https://conduitllm.com/de/research-with-exa.html), um die Recherche kennenzulernen, die der Schritt **Ein Thema recherchieren** eines Workflows nutzt. - [Die Anbieter-Anleitungen](https://conduitllm.com/providers.html) (auf Englisch), um die Modelle auszuwählen und einzurichten, die deine Workflows nutzen. [Conduit herunterladen](https://github.com/runningpixels/conduit/releases) Die Angaben zu Conduit entsprechen dem neuesten Release und lassen sich in [der Dokumentation](https://conduitllm.com/de/docs.html) und im [Quellcode](https://github.com/runningpixels/conduit) nachprüfen. Einen Fehler gefunden? [Sag uns Bescheid](https://github.com/runningpixels/conduit/discussions), wir korrigieren ihn. ## Weiterführende Links - [Deep Research mit Conduit und Exa](https://conduitllm.com/de/research-with-exa.html) — Exa-Suche einschalten, einen Recherche-Auftrag formulieren und einen Bericht mit Quellenbelegen lesen — am Beispiel Solarzellen. Ohne Exa-Schlüssel. - [Einen MCP-Server einem Kunden vorführen](https://conduitllm.com/de/mcp-distribution.html) — Einen MCP-Server zu hosten ist keine Kundendemo. Vergleich von gehostetem Chat, Claude Desktop mit Extension und einem eigenen Desktop-Client.