Wird geladen

Geplante Aufgaben und Headless

Lektion 67 Min.
Wird geladen

Geplante Aufgaben und Headless

Sobald du Claude bei einer Aufgabe vertraust, besteht der nächste Schritt darin, sie nicht mehr manuell auszuführen. Wenn es sich um denselben Prompt bei einem wiederkehrenden Trigger handelt, solltest du nicht jedes Mal selbst dabei sitzen und ihn manuell starten müssen. Diese Lektion behandelt zwei Möglichkeiten, diese Arbeit abzugeben: geplante Cloud-Aufgaben (früher Routinen), bei denen du nichts baust, und den Headless-Modus, bei dem du die volle Kontrolle über deine eigenen Skripte hast.

Stell es dir als Spektrum vor. An einem Ende stehen geplante Cloud-Aufgaben, die auf Anthropics verwalteter Infrastruktur laufen. Am anderen Ende stehen der Headless-Modus und das Agent SDK, die Claude Code aus deinem eigenen Code heraus ausführen. Beginnen wir an dem Ende, an dem du am wenigsten baust.

Geplante Aufgaben: ein gespeicherter Prompt, der in der Cloud läuft

Eine geplante Cloud-Aufgabe ist der direkteste Weg, wiederkehrende Arbeit zu automatisieren. Es gibt kein Skript und keinen Server. Sie bündelt drei Dinge: einen Prompt, das Repository, mit dem sie arbeitet, und alle Konnektoren, die sie benötigt. Dann führt sie dieses Bündel in der Cloud aus, sobald es ausgelöst wird.

Der entscheidende Punkt ist, dass die Infrastruktur Anthropic gehört. Es gibt keine eigene Maschine, die über Nacht laufen muss, und keine Workflow-Datei, die du pflegen musst. Du beschreibst die Aufgabe einmal, und sie läuft einfach.

Eine geplante Aufgabe braucht keinen Zeitplan. Sie kann durch einige Arten von Triggern ausgelöst werden:

  • Einen Cron-Zeitplan, zum Beispiel jeden Morgen um 9 Uhr.
  • Einen HTTP-POST an ihren API-Endpunkt, sodass dein eigener Code sie auslösen kann.
  • Ein GitHub-Ereignis, wie das Eintreffen eines neuen Pull Requests.

Alles, was derselbe Prompt bei einem wiederkehrenden Trigger ist, passt gut. Ein morgendliches Dependency-Audit. Ein PR-Triager, der ausgelöst wird, wenn ein neuer Pull Request eingeht. Ein täglicher Scan deiner Sentry-Tickets, um herauszufinden, was am dringendsten ist.

Hier ist das mentale Modell dafür, was eine geplante Aufgabe miteinander verbindet: ein Prompt, das Repo, Konnektoren und ein Trigger.

Zwei Möglichkeiten, eine zu erstellen

Du kannst eine geplante Aufgabe im Web unter claude.ai/code/routines erstellen. Du gibst ihr einen Namen, schreibst die Anweisungen, die beschreiben, was Claude in jeder Sitzung tun soll, wählst ein Repository aus und legst einen Trigger fest.

Du kannst eine geplante Aufgabe auch direkt aus Claude Code heraus erstellen, ohne dein Terminal zu verlassen. Führe einfach den Befehl /schedule aus und beschreibe in einfacher Sprache, was du möchtest, zum Beispiel:

/schedule daily dependency audit at 9am

Gleiche Idee, egal welchen Einstiegspunkt du wählst. Nimm, was zu deinem Workflow passt.

Drei Dinge, die du wissen solltest, bevor du dich auf geplante Cloud-Aufgaben verlässt

Bevor du dich bei irgendetwas Wichtigem auf geplante Cloud-Aufgaben verlässt, behalte diese drei Einschränkungen im Hinterkopf.

  • Geplante Cloud-Aufgaben sind eine Research Preview. Verhalten und Einschränkungen werden sich weiterhin ändern, sei also nicht überrascht, wenn sich Dinge ändern.
  • Ein wiederkehrender Zeitplan läuft höchstens stündlich. Wenn du etwas Häufigeres benötigst, ist eine geplante Cloud-Aufgabe nicht das richtige Werkzeug.
  • Ausführungen starten von einem frischen Klon deines Standard-Branches und pushen zu einem claude/-Branch, sofern dein Prompt nicht einen anderen Branch nennt. Wenn ein GitHub-Pull-Request-Ereignis die Ausführung auslöst, startet das Repository des Pull Requests stattdessen vom Head-Commit des Pull Requests, sofern es das erste Repository in der geplanten Aufgabe ist. Um zu steuern, zu welchen Branches eine Ausführung pushen darf, verwende Branch-Protection-Regeln oder Rulesets auf GitHub. GitHub wendet diese auf den von dir verbundenen GitHub-Zugriff an, sodass eine Regel, die dein Zugriff umgehen kann, den Push nicht blockiert.

Headless-Modus: wenn du deine eigene Umgebung brauchst

Geplante Cloud-Aufgaben sind großartig, wenn die Arbeit auf Anthropics Infrastruktur laufen kann. Aber manchmal braucht die Aufgabe deine Umgebung oder Logik, die um die Ausführung herum gewickelt ist. Dann wechselst du in den Headless-Modus, den die Dokumentation jetzt als nicht-interaktiven Modus bezeichnet.

Der Kern des Headless-Modus ist das Flag -p (kurz für --print). Es führt Claude Code als einmaligen Befehl ohne interaktive Benutzeroberfläche aus. Es liest von der Standardeingabe und schreibt in die Standardausgabe, lässt sich also wie jedes andere Shell-Tool per Pipe verwenden:

claude -p "summarize the changes in this diff"

Eine Sache, die du wissen solltest: Für sich allein lädt -p denselben Kontext wie eine interaktive Sitzung, einschließlich Hooks, Skills, Plugins, MCP-Servern und der CLAUDE.md-Datei. Um all das zu überspringen, füge --bare hinzu, das weiter unten behandelt wird.

Strukturierte Ausgaben zurückbekommen

Da sich der Headless-Modus wie jedes Shell-Tool per Pipe verwenden lässt, möchtest du oft strukturierte Daten statt Fließtext zurückbekommen. Du kannst ein JSON-Schema mit dem JSON-Ausgabeformat kombinieren, und Claude beschränkt seine Ausgabe darauf, deinem Schema zu entsprechen.

Das Objekt, das deinem Schema entspricht, landet im Feld structured_output der JSON-Antwort. Du kannst es also mit einem jq-Befehl herausziehen und per Pipe in eine Datenbank oder ein anderes Skript leiten:

bash
claude -p "Extract the exported function names from src/core/style.js" \
  --output-format json \
  --json-schema '{"type":"object","properties":{"functions":{"type":"array","items":{"type":"string"}}},"required":["functions"]}' \
  | jq '.structured_output.functions'

Das ergibt ein sauberes Array, das du an alles weitergeben kannst, was als Nächstes kommt.

Mehrstufige Automatisierung mit Sitzungen

Bei Arbeiten, die sich über mehrere Schritte erstrecken, musst du nicht alles in einen einzigen Befehl quetschen. Erfasse die Sitzungs-ID aus der JSON-Ausgabe und setze sie später fort:

claude --resume "$(jq -r .session_id /tmp/plan.json)"

Ein Skript stößt die Arbeit an. Ein anderes setzt sie später mit vollem Kontext fort. Das ist praktisch, wenn der erste Durchlauf einen Plan erstellt und ein zweiter Durchlauf ihn umsetzt.

Konsistente Ausführungen für CI

Wenn CI auf jeder Maschine dasselbe Setup benötigt, gibt es dafür einen eigens entwickelten Modus.

Das Flag --bare überspringt die automatische Erkennung von Hooks, Skills, Plugins, MCP-Servern und der CLAUDE.md-Datei. Du bekommst Claude mit den Tools Bash, Datei lesen und Datei bearbeiten, plus allem, was du mit einem Flag wie --settings oder --mcp-config übergibst. So startet jede Maschine mit demselben Setup, und der Start ist schneller. Der Bare-Modus nutzt nicht deinen Abonnement-Login, setze also zuerst ANTHROPIC_API_KEY.

Das Agent SDK: Claude Code in deiner eigenen App

Der letzte Schritt auf dem Spektrum ist das Agent SDK. Damit erhältst du eine Bibliothek, die Claude Code in deine eigenen TypeScript- oder Python-Anwendungen einbettet.

Beide Sprachen stellen eine query-Funktion und dieselben Primitiven wie die CLI bereit. Du übergibst einen Prompt plus Optionen, wie zum Beispiel:

  • allowedTools, um zu steuern, was Claude tun darf,
  • einen System-Prompt,
  • und einen Berechtigungsmodus.

Dann iterierst du über die Nachrichten, die Claude per Streaming zurücksendet, und verarbeitest sie so, wie es deine App benötigt. Es ist dieselbe Engine wie die CLI, nur aus deinem Produkt heraus aufrufbar.

Wofür solltest du dich entscheiden?

Hier ist der schnelle Entscheidungsleitfaden:

  • Geplante Cloud-Aufgaben sind die Standardwahl für wiederkehrende Arbeiten. Sie laufen auf Anthropics Infrastruktur, ohne dass du etwas hosten musst.
  • Headless-Modus mit -p eignet sich, wenn die Aufgabe deine Pipeline benötigt und du Daten per Pipe durch ein Skript leiten möchtest.
  • --bare eignet sich, wenn CI auf jeder Maschine dasselbe Setup benötigt.
  • Das Agent SDK eignet sich, wenn die Arbeit in dein eigenes Produkt gehört.

Beginne mit geplanten Cloud-Aufgaben. Gehe im Spektrum nur dann weiter nach unten, wenn die Aufgabe die zusätzliche Kontrolle benötigt.