Deer Workflow auf einem VPS selbst hosten

Was Sie erstellen

Deer Workflow ist eine codeorientierte Laufzeitumgebung für Agent-Graphen. Der Kontrollfluss steht in einer TypeScript-Datei, die Sie prüfen können. Ein Coding-Agent übernimmt nur die Aufgaben, die eine Beurteilung erfordern. Diese Anleitung installiert Deer Workflow auf einem Ubuntu-VPS, führt einen Beispiel-Graphen ohne Benutzeroberfläche unter systemd aus und schreibt den maschinenlesbaren Ereignisstrom in eine Logdatei. Bei einem Fehler können Sie darin auch um drei Uhr morgens suchen.

Die einzelnen Komponenten sind klein. Bun führt die CLI aus. Eine Coding-Agent-CLI, Codex oder Claude Code, übernimmt die Modellverarbeitung. Ein festgelegtes npm-Paket enthält die Laufzeitumgebung. Eine TypeScript-Datei enthält Ihren Graphen. Ein systemd-Service und ein systemd-Timer führen ihn nach einem Zeitplan aus. Der größte Teil dieser Anleitung behandelt die Komponenten, die tatsächlich häufig ausfallen: PATH innerhalb einer systemd-Unit, Agent-Zugangsdaten in einer Sitzung ohne Login-Shell und das Festlegen einer Abhängigkeit, die erstmals im Juli 2026 veröffentlicht wurde.

Visueller Builder, Code oder direkte Prompts an den Agenten

Wer mit einem Modell automatisiert, entscheidet sich für einen von drei Ansätzen. Diese Ansätze scheitern auf unterschiedliche Weise.

Ein visueller Builder bietet eine Arbeitsfläche, eine Sammlung von Nodes und eine Benutzeroberfläche, die auch Personen ohne Programmierkenntnisse bedienen können. Das ist ein echter Vorteil. Außerdem gibt es inzwischen so viele Lösungen, dass eine umfassende Übersicht zu self-hosted n8n-Alternativen zur Auswahl steht. Der Nachteil ist, dass die Logik als JSON-Dokument endet, das von einer Benutzeroberfläche erzeugt wird. Der Diff dieses Dokuments ist unübersichtlich. Um eine Änderung zu prüfen, müssen Sie daher die Arbeitsfläche öffnen, statt den Patch zu lesen.

Direkte Prompts an einen Agenten sind der zweite Ansatz. Sie beschreiben die gesamte Aufgabe in einem Absatz. Das Modell entscheidet dann über die Reihenfolge, die Wiederholungsversuche und den Zeitpunkt zum Beenden. Das funktioniert, bis es sich eines Tages anders entscheidet. Einen Diff gibt es nicht, weil kein Artefakt vorhanden ist. Der Plan stand in der Unterhaltung, und die Unterhaltung ist nicht mehr vorhanden.

Die Orchestrierung im Code ist der dritte Ansatz. Die Reihenfolge der Schritte, die parallele Verteilung, die Wiederholungsversuche und die Fehlerbehandlung stehen als gewöhnlicher TypeScript-Code in git. Das Modell wird nur dort aufgerufen, wo eine Bewertung erforderlich ist. Der Nachteil ist, dass jemand diesen Code schreiben und pflegen muss. Außerdem kann ein Kollege, der kein TypeScript schreibt, ihn nicht bearbeiten.

Was eine Graph-Laufzeitumgebung leistet und was sie kostet

• Kontrollfluss, den Sie prüfen können. Der Graph ist eine Datei. Eine Änderung an der Retry-Richtlinie erscheint in einem Pull Request als drei geänderte Zeilen und nicht als verschobenes Feld.
• Fehlerbehandlung in der Versionsverwaltung. Was bei einem Fehler in Schritt vier geschieht, ist dokumentiert, getestet und zusammen mit der restlichen Infrastruktur versioniert.
• Ein Agent, den Sie austauschen können. Die Laufzeitumgebung enthält Adapter für Codex, Claude Code und Pi. Welcher Agent einen Schritt ausführt, lässt sich durch einen einzigen Import ändern.
• Eine Ausführung, die Sie überwachen können. Phasen und Ereignisse werden von der Laufzeitumgebung als strukturierte Daten ausgegeben. Dadurch hinterlässt eine headless Ausführung einen Datensatz, den Sie abfragen können.

Die allgemeine Vorgehensweise, bei der Sie die Schleife entwerfen, in der das Modell ausgeführt wird, statt einen einzelnen Prompt zu optimieren, heißt Loop-Engineering. Eine Graph-Laufzeitumgebung ist eine konkrete Möglichkeit, dies umzusetzen. Der Preis dafür ist zusätzlicher Einrichtungsaufwand: Sie müssen eine Laufzeitumgebung installieren und eine Agent-CLI authentifizieren. Es gibt keine Benutzeroberfläche für Personen ohne Programmierkenntnisse, und eine junge Abhängigkeit muss überwacht werden.

Das Projekt ist neu, deshalb sollten Sie die Version festschreiben

Deer Workflow steht unter der MIT-Lizenz und ist neu. Am 19. August 2026 enthält das Repository 47 Commits auf main. npm enthält drei veröffentlichte Versionen: 0.0.1 und 0.1.0 vom 26. Juli 2026 sowie 0.2.0 vom 27. Juli 2026. Für jede Version gibt es ein Git-Tag. Im Changelog sehen Sie, was sich zwischen den Versionen geändert hat. Der Abschnitt Unreleased entfernt bereits den Befehl deer-workflow agent. Daher bieten main und die neueste veröffentlichte Version nicht mehr dieselbe CLI.

Das ist kein Grund, das Projekt zu vermeiden. Installieren Sie stattdessen genau eine Version und halten Sie fest, welche Version installiert ist.

• Installieren Sie eine exakte Version, niemals einen Versionsbereich.
• Speichern Sie diese Version im selben Repository wie Ihre Graphen.
• Führen Sie nach jedem Upgrade Ihren eigenen Graph einmal manuell aus, bevor der Timer ihn erneut startet.

Bun und eine Agent-Laufzeitumgebung installieren

Alle folgenden Schritte werden als normaler Benutzer mit sudo-Berechtigungen ausgeführt. Führen Sie sie nicht als root aus. Die Agent-CLIs speichern Anmeldedaten im Home-Verzeichnis des Benutzers, der sich angemeldet hat. Die systemd-Unit muss später unter demselben Benutzer ausgeführt werden, damit sie diese Anmeldedaten findet.

sudo apt update
sudo apt install -y curl unzip jq git nodejs npm
curl -fsSL https://bun.com/install | bash

Das Bun-Installationsprogramm entpackt ein ZIP-Archiv. Daher muss unzip zuerst vorhanden sein. Das Installationsprogramm hängt seine PATH-Zeilen an Ihr Shell-Profil an. Ihre aktuelle Shell hat diese Datei bereits gelesen. Öffnen Sie daher eine neue Shell oder fügen Sie diese beiden Zeilen selbst zu ~/.bashrc hinzu und laden Sie die Datei neu.

export BUN_INSTALL="$HOME/.bun"
export PATH="$BUN_INSTALL/bin:$HOME/.npm-global/bin:$PATH"

bun --version

Damit wird eine Versionsnummer ausgegeben. bun: command not found bedeutet, dass die PATH-Zeile in der Shell fehlt, in der Sie sich gerade befinden. Das bedeutet nicht, dass die Installation fehlgeschlagen ist. Führen Sie ls ~/.bun/bin aus, bevor Sie etwas neu installieren.

Nun folgt die Agent-Laufzeitumgebung. Codex CLI ist die Standardoption und wird über npm installiert. Legen Sie ein npm-Präfix auf Benutzerebene fest, damit die globale Installation keine root-Berechtigungen benötigt.

npm config set prefix "$HOME/.npm-global"
npm install -g @openai/codex
command -v codex
codex

command -v codex sollte einen Pfad unter $HOME/.npm-global/bin ausgeben. Wenn Sie codex ohne weitere Argumente ausführen, wird die CLI geöffnet. Dort melden Sie sich mit Ihrem ChatGPT-Konto an. Führen Sie diesen Schritt jetzt einmal aus, solange Sie den Bildschirm sehen können.

Claude Code funktioniert als alternative Laufzeitumgebung und verfügt über ein eigenes Installationsprogramm.

curl -fsSL https://claude.ai/install.sh | bash
claude --version

Bei einer erfolgreichen Installation wird eine Version wie 2.1.211 (Claude Code) ausgegeben. Führen Sie claude einmal aus, um sich anzumelden. Dieser Prozess gehört zur selben Kategorie und hat denselben Zugriff auf Ihre Dateien wie jeder andere Agent, den Sie hosten. Daher gelten die Hinweise zu Konto und Absicherung unter einen Coding-Agent auf einem VPS ausführen hier unverändert.

Deer Workflow installieren und exakt auf eine Version festlegen

bun install --global @deerwork-ai/deer-workflow@0.2.0
command -v deer-workflow

command -v gibt den absoluten Pfad aus, normalerweise /home/<your user>/.bun/bin/deer-workflow. Kopieren Sie ihn an einen geeigneten Ort. Die systemd-Unit kann den reinen Namen nicht verwenden.

Behalten Sie die Version im Installationsbefehl bei. Wenn Sie @0.2.0 weglassen, wird die Version installiert, die am Tag der Ausführung aktuell ist. Bei einem Projekt mit 47 Commits kann sich dadurch die CLI ändern, während sie von einem Timer ausgeführt wird, den niemand überwacht.

Die Graphen in einem git-Repository ablegen

mkdir -p ~/workflows/logs
cd ~/workflows
git init

Codex prüft, ob es innerhalb eines git-Repositorys ausgeführt wird. Deshalb verfügt CodexAgentConfig über die Option skipGitRepositoryCheck für Fälle, in denen Sie kein Repository angeben können. Auf Ihrem eigenen VPS können Sie ein Repository angeben, und Sie sollten dies tun: Ein Graph ist Code. Der Ansatz, Orchestrierung als Code zu verwalten, funktioniert nicht, wenn der Code nicht unter Versionskontrolle steht. Erstellen Sie jetzt das Verzeichnis logs, da systemd es nicht für Sie anlegt.

Einen Graphen schreiben

Ein Workflow ist ein gewöhnliches TypeScript-Modul. Er exportiert meta, ein Objekt mit einem Namen, einer Beschreibung und der geordneten Phasenliste, sowie den Handler als default oder als benannten run-Export. Im Handler rufen Sie Hilfsfunktionen aus dem Paket auf. phase() kennzeichnet die aktuelle Phase des Laufs, log() schreibt eine Fortschrittszeile, agent() sendet eine Eingabeaufforderung an den Coding-Agenten, parallel() führt eine Liste von Aufgaben gleichzeitig aus, und pipeline() verarbeitet eine Liste von Elementen in mehreren Phasen.

Speichern Sie die Datei als ~/workflows/log-triage.ts.

import { agent, log, parallel, phase } from "@deerwork-ai/deer-workflow";

export const meta = {
  name: "log-triage",
  description: "Groups recent service errors and writes one short report.",
  phases: [{ title: "Collect" }, { title: "Classify" }, { title: "Report" }],
  exampleArgs: { service: "nginx", hours: 24 },
};

export default async function workflow(args: { service: string; hours: number }) {
  if (!args?.service) throw new Error("input needs a service name");

  phase("Collect");
  log(`Reading ${args.hours}h of logs for ${args.service}`);
  const found = await agent<{ patterns: string[] }>(
    `Read the last ${args.hours} hours of journalctl -u ${args.service} and list the distinct error patterns.`,
    {
      sandbox: "read-only",
      schema: {
        type: "object",
        properties: { patterns: { type: "array", items: { type: "string" } } },
        required: ["patterns"],
        additionalProperties: false,
      },
    },
  );

  phase("Classify");
  log(`Classifying ${found.patterns.length} patterns`);
  const notes = await parallel(
    found.patterns.map((pattern) => () =>
      agent(`Explain this error and its most likely cause: ${pattern}`, { sandbox: "read-only" }),
    ),
  );

  phase("Report");
  return agent(`Write a short operations report from these notes: ${JSON.stringify(notes.filter(Boolean))}`);
}

Vier Details in dieser Datei sind entscheidend.

• schema bei einem Aufruf von agent() fordert eine strukturierte Ausgabe an. Der Aufruf gibt das geparste Objekt zurück. found.patterns ist ein echtes Array, über das der restliche Graph iterieren kann. Ohne Schema gibt agent() eine Zeichenkette zurück, und Sie müssen den Fließtext selbst parsen.
• sandbox legt fest, worauf dieser Schritt zugreifen darf. read-only blockiert Schreibvorgänge, workspace-write erlaubt geschützte Schreibvorgänge, und danger-full-access entfernt den Schutz. Die Einstellung erfolgt pro Aufruf. Ein Graph kann daher weitreichend lesen und nur an einer Stelle schreiben.
• parallel() erwartet Funktionen, keine Promises. map((pattern) => () => agent(...)) erstellt eine Liste von Thunks, sodass die Laufzeit den Startzeitpunkt jeder Funktion bestimmen kann. Wenn Sie agent(...) direkt übergeben, würde jeder Aufruf bereits beim Erstellen der Liste gestartet.
• Eine fehlgeschlagene Aufgabe innerhalb von parallel() wird zu null, und der Lauf wird fortgesetzt, weil eine teilweise Fertigstellung absichtlich erlaubt ist. Deshalb ist notes.filter(Boolean) keine Dekoration: Wenn Sie es überspringen, fügt ein fehlgeschlagener Zweig den Text null in die Eingabeaufforderung des nächsten Schritts ein.

Der einfache Hilfsaufruf agent() verwendet die Standardlaufzeit Codex. Um stattdessen einen einzelnen Schritt an Claude Code zu senden, importieren Sie die Agent-Klasse und rufen Sie sie direkt auf.

import { ClaudeAgent } from "@deerwork-ai/deer-workflow";

const claude = new ClaudeAgent({ sandbox: "read-only" });
const summary = await claude.run<string>("Summarise ./report.md in five lines.");

So sieht ein austauschbarer Agent in der Praxis aus: ein Import und ein Konstruktor, während der umgebende Graph unverändert bleibt. Das Flag --agent codex|claude|pi der CLI gehört zu deer-workflow create, das aus einer Beschreibung eine Workflow-Datei generiert. Es ändert nicht, welche Laufzeit deer-workflow run verwendet.

Einmal manuell ausführen, danach ohne Terminal

cd ~/workflows
deer-workflow run ./log-triage.ts --input '{"service":"nginx","hours":24}'

Im interaktiven Modus erhalten Sie eine Terminaloberfläche: Die Phasen ab meta werden auf einer Seite angezeigt, das Live-Log auf der anderen. Beobachten Sie auf diese Weise einen vollständigen Lauf, bevor Sie etwas automatisieren. Wenn der Agent nicht angemeldet ist oder Ihre Eingabe nicht der Handler-Signatur entspricht, sehen Sie den Fehler innerhalb von Sekunden, statt ihn erst in der folgenden Woche in einer Logdatei zu finden.

Für die Automatisierung verschieben Sie die Eingabe in eine Datei. Speichern Sie ~/workflows/input.json:

{ "service": "nginx", "hours": 24 }

deer-workflow run ./log-triage.ts --input-file ./input.json --print >> logs/run.jsonl

--print, kurz -p, deaktiviert die Oberfläche und schreibt den Ereignisstrom nach stdout, ein JSON-Objekt pro Zeile. In diesem Modus wird nichts anderes nach stdout geschrieben. Sie können die Ausgabe daher direkt an eine .jsonl-Datei anhängen, in der jede Zeile geparst werden kann.

Der Ereignisstrom und wonach Sie um 3 Uhr suchen sollten

Jede Zeile enthält type, sequence, timestamp, workflowId, depth und scriptPath. Die Typen sind workflow:start, workflow:meta, workflow:end, workflow:error, workflow:phase:start, workflow:phase:end und log. Phasenereignisse enthalten phase, Abschlussereignisse enthalten durationMs, ein log-Ereignis enthält message, und ein workflow:error-Ereignis enthält error sowie name, message und normalerweise stack.

Diese Struktur reicht aus, um die beiden Fragen zu beantworten, die Sie um drei Uhr morgens klären müssen: Wurde der Vorgang abgeschlossen, und an welcher Stelle wurde er beendet?

grep workflow:error logs/run.jsonl
jq -r 'select(.type == "workflow:error") | .error.message' logs/run.jsonl
jq -r 'select(.type == "workflow:phase:end") | [.phase, .durationMs] | @tsv' logs/run.jsonl
jq -r 'select(.type == "log") | .message' logs/run.jsonl

Um einen aktuell laufenden Vorgang zu überwachen, verfolgen Sie die Datei: tail -f logs/run.jsonl | jq -c 'select(.type == "log")'. Ein Vorgang schreibt nur wenige Zeilen, aber die Datei wächst dauerhaft. Fügen Sie daher für ~/workflows/logs/*.jsonl eine logrotate-Regel hinzu, sobald der Timer einige Wochen gelaufen ist.

Unter systemd ausführen

Verwenden Sie einen oneshot-Dienst mit einem Timer statt eines langlebigen Daemons. Der Graph startet, läuft und wird beendet. Schreiben Sie /etc/systemd/system/log-triage.service und ersetzen Sie deploy durch Ihren Benutzernamen.

[Unit]
Description=Log triage workflow
After=network-online.target
Wants=network-online.target

[Service]
Type=oneshot
User=deploy
WorkingDirectory=/home/deploy/workflows
Environment=HOME=/home/deploy
Environment=PATH=/home/deploy/.bun/bin:/home/deploy/.npm-global/bin:/usr/local/bin:/usr/bin:/bin
ExecStart=/home/deploy/.bun/bin/deer-workflow run ./log-triage.ts --input-file ./input.json --print
StandardOutput=append:/home/deploy/workflows/logs/run.jsonl
StandardError=journal
TimeoutStartSec=3600

Führen Sie anschließend /etc/systemd/system/log-triage.timer aus:

[Unit]
Description=Run the log triage workflow every night

[Timer]
OnCalendar=*-*-* 03:00:00
Persistent=true

[Install]
WantedBy=timers.target

sudo systemctl daemon-reload
sudo systemctl start log-triage.service
systemctl status log-triage.service
sudo systemctl enable --now log-triage.timer
systemctl list-timers log-triage.timer

Starten Sie den Dienst zuerst manuell. Ein erfolgreicher Lauf endet damit, dass die Unit erfolgreich deaktiviert wird, und logs/run.jsonl erhält einen Ereignisblock, der mit workflow:end endet. Aktivieren Sie erst danach den Timer. list-timers gibt den nächsten geplanten Lauf aus, und Persistent=true bewirkt, dass ein während des ausgeschalteten Servers verpasster Lauf beim nächsten Boot einmalig ausgeführt wird. StandardOutput=append: leitet den Ereignisstrom in die Datei um und belässt alle übrigen Meldungen im Journal, sodass journalctl -u log-triage.service lesbar bleibt.

Warum funktioniert der Graph in meiner Shell, schlägt unter systemd aber fehl?

Prüfen Sie diese vier Punkte in dieser Reihenfolge.

Die Unit findet die Binärdateien nicht. systemd liest ~/.bashrc nie ein, und der Standardwert von PATH enthält weder ~/.bun/bin noch ~/.npm-global/bin. Die Unit schlägt innerhalb von weniger als einer Sekunde fehl, und journalctl -u log-triage.service zeigt, dass die Ausführung am Befehlsnamen scheitert. Deshalb verwendet ExecStart einen absoluten Pfad. Deshalb listet Environment=PATH= weiterhin beide Verzeichnisse auf: Die Laufzeitumgebung muss beim Start eines Agent-Schritts codex oder claude finden.

Der Agent findet seine Zugangsdaten nicht. Die Agent-CLI liest die Anmeldung aus dem Home-Verzeichnis. Setzen Sie daher User= und Environment=HOME= explizit und geben Sie das Home-Verzeichnis an, mit dem Sie sich angemeldet haben. Wenn ein Lauf workflow:start erreicht und anschließend einen workflow:error erzeugt, dessen Meldung von der Agent-CLI und nicht von Ihrem eigenen Code stammt, ist dies fast immer die Ursache.

Der Lauf wird nach 90 Sekunden beendet. Für Type=oneshot wendet systemd sein Start-Timeout auf den gesamten Befehl an. Der Standardwert beträgt 90 Sekunden. Ein Agent-Graph benötigt mehrere Minuten. Das Journal protokolliert Start operation timed out. Terminating., die Unit endet in einem fehlgeschlagenen Zustand, und die Protokolldatei enthält einen unvollständigen Lauf ohne workflow:end. Mit TimeoutStartSec=3600 geben Sie dem Prozess eine Stunde. Verwenden Sie infinity, wenn der Prozess nicht aufgrund eines Zeitlimits beendet werden soll.

Relative Pfade werden an einem anderen Ort aufgelöst. ./log-triage.ts und ./input.json sind relativ zu WorkingDirectory. Lassen Sie diese Zeile weg, startet systemd den Prozess in /, wo keine der beiden Dateien vorhanden ist.

Was der Orchestrator ausführen darf

Ein Orchestrator, der Agent-Schritte zeitgesteuert ausführt, ist ein Prozess auf Ihrem Server, den niemand überwacht. Zwei Kontrollen und ein Budget sind entscheidend.

Die erste Kontrolle ist die Sandbox bei jedem agent()-Aufruf. read-only ist die richtige Standardeinstellung für jeden Schritt, der nur liest: Logs, Metriken oder ein Repository, das Sie zusammenfassen. Wechseln Sie zu workspace-write, wenn ein Schritt tatsächlich schreiben muss, und halten Sie den beschreibbaren Bereich mit additionalWritableDirectories klein, statt auf danger-full-access zurückzugreifen.

Die zweite Kontrolle ist eine Person. Einige Schritte dürfen niemals unbeaufsichtigt ausgeführt werden: E-Mails senden, Geld bewegen, Daten löschen oder die Produktionskonfiguration ändern. In einem codebasierten Graphen lässt sich das Gate einfach platzieren, weil der Schritt eine Codezeile ist. Stoppen Sie die Ausführung, protokollieren Sie die geplante Aktion, warten Sie auf die Antwort eines Menschen und fahren Sie dann fort. Ein Approval-Gate vor Agent-Aktionen platzieren beschreibt dieses Muster vollständig. Es gehört in jeden Graphen, den ein Timer startet.

Das Budget betrifft das Geld. Jeder agent()-Aufruf ist eine vollständige Agent-Sitzung, und parallel() startet mehrere Sitzungen gleichzeitig. Ein Graph, der sich auf zwölf Zweige aufteilt, führt daher jede Nacht zwölf Sitzungen aus, unabhängig davon, ob jemand den Bericht liest. Die Messung und die Begrenzungen aus AI-Agent-Kosten auf einem VPS unter Kontrolle halten gelten direkt für einen zeitgesteuerten Graphen.

Lesen Sie vor dem Upgrade der Laufzeitumgebung das Changelog, installieren Sie die neue exakte Version und führen Sie Ihren Graphen mit --print einmal manuell aus. Bei einem so jungen Projekt verändert sich die CLI-Oberfläche noch. Der Abschnitt Unreleased entfernt bereits einen Befehl, der in 0.2.0 vorhanden ist. Ein Graph unter einem Timer ist nur so zuverlässig wie die von Ihnen festgelegte Version und der letzte Lauf, den Sie tatsächlich überwacht haben.

FAQ

Benötige ich Bun, oder läuft Deer Workflow mit Node.js?

Installieren Sie Bun. Das veröffentlichte Paket verweist mit seinem deer-workflow-Binary auf src/cli.ts, eine TypeScript-Quelldatei, und die Dokumentation nennt Bun als Voraussetzung. Bun führt TypeScript direkt aus, daher ist kein Build-Schritt erforderlich. Installieren Sie Bun mit sudo apt install -y unzip gefolgt von curl -fsSL https://bun.com/install | bash und prüfen Sie die Installation anschließend mit bun --version. Node.js und npm benötigen Sie weiterhin separat, wenn Sie Codex CLI aus npm installieren.

Warum läuft mein Workflow im Terminal, schlägt aber unter systemd fehl?

Fast immer sind PATH, HOME oder das Start-Timeout die Ursache. systemd liest Ihr Shell-Profil nicht ein. Daher benötigt ExecStart den absoluten Pfad zu deer-workflow, und Environment=PATH= benötigt das Verzeichnis, das codex oder claude enthält. Die Agent-CLI liest ihre Zugangsdaten aus $HOME. Setzen Sie deshalb User= und Environment=HOME= auf den Account, mit dem Sie sich angemeldet haben. Außerdem verwendet Type=oneshot standardmäßig ein Start-Timeout von 90 Sekunden. Dadurch wird ein Agent-Lauf vorzeitig beendet, und im Journal bleibt Start operation timed out. Terminating. zurück. Setzen Sie daher TimeoutStartSec=3600.

Wie verwende ich für einen Schritt Claude Code statt Codex?

Der einfache agent()-Helper verwendet die Standard-Runtime Codex. Importieren Sie ClaudeAgent aus dem Paket, erzeugen Sie eine Instanz und rufen Sie .run() für die Schritte auf, die Claude Code ausführen soll. Das Flag --agent codex|claude|pi gehört zu deer-workflow create, dem Befehl, der aus einer Beschreibung eine Workflow-Datei erzeugt. Es wirkt sich nicht auf deer-workflow run aus. Der verwendete Agent benötigt eine eigene installierte CLI und muss als derselbe Benutzer angemeldet sein, unter dem der Dienst läuft.

Welche Version von Deer Workflow sollte ich installieren?

Genau die Version, die Sie getestet haben. Am 19. August 2026 ist die neueste veröffentlichte Version 0.2.0 vom 27. Juli 2026, und das Repository enthält 47 Commits. Tragen Sie @0.2.0 oder die zum Zeitpunkt der Lektüre aktuelle Version in den Installationsbefehl ein, halten Sie diese Versionsnummer in git neben Ihren Graphen fest und führen Sie nach jedem Upgrade einen Graphen manuell aus, bevor der Timer ihn wieder startet.