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, 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 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 (auf Englisch), etwa Use OpenRouter in a desktop app (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/<owner>/<repo>/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.

— vergrößern Vergrößern

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.

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.

— vergrößern Vergrößern

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.

— vergrößern Vergrößern

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.

— vergrößern Vergrößern

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.

— vergrößern Vergrößern

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.

— vergrößern Vergrößern

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.

— vergrößern Vergrößern

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.

— vergrößern Vergrößern

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.

— vergrößern Vergrößern

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 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:

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

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 mit allen Einstellungen und Grenzen.
• Deep Research mit Conduit und Exa, um die Recherche kennenzulernen, die der Schritt Ein Thema recherchieren eines Workflows nutzt.
• Die Anbieter-Anleitungen (auf Englisch), um die Modelle auszuwählen und einzurichten, die deine Workflows nutzen.

Conduit herunterladen

Die Angaben zu Conduit entsprechen dem neuesten Release und lassen sich in der Dokumentation und im Quellcode nachprüfen. Einen Fehler gefunden? Sag uns Bescheid, wir korrigieren ihn.

Weiterführende Links

• Deep Research mit Conduit und Exa — 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 — Einen MCP-Server zu hosten ist keine Kundendemo. Vergleich von gehostetem Chat, Claude Desktop mit Extension und einem eigenen Desktop-Client.