Claude Workflows automatisieren: So laufen sie von selbst

Es gibt einen Leitsatz, der zusammenfasst, wohin die Reise beim agentenbasierten Programmieren geht: Das Ziel ist nicht ein besserer Prompt, sondern ein Workflow, der abläuft, ohne dass man ihn ständig überwacht. Die meisten Leute nutzen Claude wie ein Chatfenster. Man tippt, man wartet, man liest, man tippt erneut. Das funktioniert, aber es begrenzt Ihre Ausgabe auf einen Agenten, den Sie aktiv betreuen. Ingenieure, die wirklich Nutzen aus Claude ziehen, haben etwas anderes gebaut: Workflows, die nach einem Zeitplan oder Auslöser starten, die Arbeit erledigen, ihre eigenen Ergebnisse überprüfen und einen Menschen nur dann benachrichtigen, wenn eine Entscheidung erforderlich ist.

TL;DR

Ein Claude-Workflow, der ohne Sie abläuft, benötigt fünf Teile: eine präzise schriftliche Spezifikation, eine Headless-Ausführung (nicht interaktiv), eine deterministische Verifikationsschranke, die über Erfolg oder Misserfolg entscheidet, harte Leitplanken (Berechtigungs-Allowlists, begrenzte Iterationen, Kostenobergrenzen, ein Notschalter) und eine Übergabe, die einen Menschen benachrichtigt oder im Fehlerfall eskaliert. Der Headless-Modus von Claude Code (claude -p), das Claude Agent SDK, Hooks und ein Scheduler (cron oder launchd) bieten Ihnen alle fünf. Der Agent ist nicht der riskante Teil. Ihn unbeaufsichtigt ohne Schranke und Leitplanken laufen zu lassen, ist es. Bauen Sie diese zuerst, dann lassen Sie los.

Warum „läuft ohne Sie“ das wahre Ziel ist

Überwachter Chat hat eine harte Obergrenze: Sie. Jede Iteration wartet darauf, dass ein Mensch die Ausgabe liest und entscheidet, was als Nächstes zu tun ist. Das Modell generiert in Sekunden und ist dann minutenlang untätig, während Sie den Kontext wechseln. Sie sind der Engpass in einem System, das ansonsten schnell ist.

Unbeaufsichtigte Workflows heben diese Obergrenze auf. Der Agent arbeitet, ein Skript prüft ihn, Fehler werden automatisch zurückgeleitet, und Sie greifen nur an den Rändern ein. Der Vorteil ist nicht nur Geschwindigkeit. Es ist Parallelität. Sobald ein Workflow ohne Aufsicht läuft, skalieren Sie, indem Sie Workflows hinzufügen, nicht indem Sie schneller tippen. Das ist derselbe Sprung, den wir in Claude Code dynamische Workflows behandelt haben, wo eine Sitzung in viele parallele Agenten aufgeteilt wird.

Aber „läuft ohne Sie“ erhöht den Einsatz. Ein überwachter Agent, der eine schlechte Bearbeitung vornimmt, wird erkannt, wenn Sie den Diff lesen. Ein unbeaufsichtigter Agent committet es, führt den nächsten Schritt aus und läuft weiter. Die Disziplin verlagert sich also vom Prompt-Crafting zum Systemdesign: Sie bauen eine Maschine, die korrekt, begrenzt und beobachtbar sein muss, wenn niemand hinsieht. Anthropic's Artikel über den Aufbau effektiver Agenten argumentiert dasselbe. Der Hebel kommt aus der Umgebung um das Modell herum, nicht aus einer intelligenteren Einzelnachricht.

Die fünf Teile, die jeder unbeaufsichtigte Workflow benötigt

Wenn Sie einen dieser Punkte überspringen, macht der Workflow entweder selbstbewusst das Falsche oder hört nie auf.

1. Eine präzise Spezifikation. Eine schriftliche Beschreibung des Ziels, die der Agent zu Beginn jedes Laufs liest. Vage Spezifikationen führen zu vager Arbeit. „Repariere die API“ scheitert; „der POST /orders Endpunkt gibt 201 zurück, validiert den Body gegen das Schema, lehnt fehlende Felder mit 422 ab“ gelingt.
2. Headless-Ausführung. Claude muss ohne menschliche Eingabe laufen. Das bedeutet nicht-interaktiver Modus, nicht die Chat-Benutzeroberfläche.
3. Eine Verifikationsschranke. Eine deterministische Prüfung, die mit einem konkreten Grund bestanden oder nicht bestanden zurückgibt: Tests, ein Typcheck, eine Schema-Validierung, ein Vertragstest. Dies ist es, was dem Workflow erlaubt zu entscheiden, dass er tatsächlich fertig ist, anstatt sich auf das Wort des Modells zu verlassen.
4. Leitplanken. Berechtigungs-Allowlists, eine maximale Iterationsanzahl, eine Kostenobergrenze, Protokollierung und ein Notschalter. Diese verhindern, dass ein verwirrter Lauf Schaden anrichtet, während Sie schlafen.
5. Eine Übergabe. Wenn der Workflow abgeschlossen ist oder aufgibt, benachrichtigt er jemanden. Eine Benachrichtigung, ein Entwurf zur Überprüfung, eine Fehlermeldung. Stille ist kein Erfolg.

Die mittleren drei sind die Bereiche, in denen die meisten Setups Mängel aufweisen. Lassen Sie uns jeden davon mit den Tools bauen, die Claude Ihnen bietet.

Die Claude-Bausteine

Headless-Modus (claude -p)

Der Print-Modus von Claude Code führt einen Prompt nicht-interaktiv aus und beendet sich. Dies ist die Grundlage jedes unbeaufsichtigten Workflows. Sie übergeben ihm eine Aufgabe, beschränken seine Tools, erfassen die Ausgabe und fahren fort.

claude -p "Implement the orders endpoint per spec.md, then run the test suite" \
  --allowedTools "Edit,Write,Bash" \
  --output-format json \
  >> run.log 2>&1

Das --allowedTools-Flag ist wichtiger, als es scheint. In der Chat-Benutzeroberfläche genehmigen Sie jede Aktion manuell. Headless gibt es niemanden, der genehmigen kann, daher ist die Allowlist Ihre einzige Kontrolle darüber, was der Agent berühren darf. Beginnen Sie eng und erweitern Sie nur, wenn Sie dem Lauf vertrauen. Der vollständige Satz von Flags befindet sich in den Claude Code-Dokumenten.

Das Claude Agent SDK

Wenn ein Shell-Befehl nicht ausreicht, ermöglicht Ihnen das Claude Agent SDK, Claude programmatisch mit Python oder TypeScript zu steuern. Sie erhalten die Schleife im Code: eine Aufgabe senden, das Ergebnis streamen, Tool-Aufrufe inspizieren, entscheiden, ob fortgefahren werden soll. So umhüllen Sie den Agenten mit echtem Kontrollfluss.

import { query } from "@anthropic-ai/claude-agent-sdk";

const MAX_ITERATIONS = 8;
let feedback = "";

for (let attempt = 0; attempt < MAX_ITERATIONS; attempt++) {
  for await (const msg of query({
    prompt: `${task}\n\nPrevious failures:\n${feedback}`,
    options: { allowedTools: ["Edit", "Write", "Bash"] },
  })) {
    // stream/log messages as the agent works
  }

  const gate = runVerification();      // your deterministic check
  if (gate.passed) break;              // done
  feedback = gate.failures;            // the next prompt writes itself
}

Genaue Signaturen finden sich in der Dokumentation, aber der Kern ist: eine Schleife, die den Agenten mit dem letzten Fehler als nächsten Prompt erneut ausführt. Wenn Sie sich zwischen einer selbst implementierten Schleife und einer gehosteten Option entscheiden, erklärt unser Vergleich von verwalteten Agenten vs. dem Agent SDK, wann jede Option sinnvoll ist.

Hooks für deterministische Leitplanken

Hooks führen Ihre eigenen Befehle an festen Punkten im Lebenszyklus von Claude aus, ohne dass ein Modell beteiligt ist. Sie sind die Art, wie Sie Regeln durchsetzen, um die sich der Agent nicht herumreden kann. Möchten Sie, dass die Testsuite nach jeder Dateiänderung ausgeführt wird? Ein PostToolUse-Hook erledigt dies deterministisch.

{
  "hooks": {
    "PostToolUse": [
      {
        "matcher": "Edit|Write",
        "hooks": [{ "type": "command", "command": "npm test --silent" }]
      }
    ]
  }
}

Da ein Hook einfacher Code ist und keine Anfrage an das Modell, wird er immer ausgelöst. Das ist die Eigenschaft, die Sie für Leitplanken in einem unbeaufsichtigten Lauf wünschen. Der Agent kann nicht entscheiden, ihn zu überspringen.

Ein Scheduler zum Auslösen von Läufen

Ein Workflow, der ohne Sie läuft, benötigt etwas, das ihn ohne Sie startet. Auf einem Server ist das cron; auf einem Mac ist es launchd. So oder so starten Sie den Headless-Befehl nach einem Zeitplan.

# jeden Werktag um 7 Uhr morgens: den Wartungs-Workflow ausführen, alles protokollieren
0 7 * * 1-5  cd /srv/api && claude -p "$(cat tasks/nightly-maintenance.md)" \
  --allowedTools "Edit,Bash" >> logs/run-$(date +\%F).log 2>&1

Das ist das gesamte Rückgrat eines autonomen Setups: Ein Scheduler startet den Headless-Claude, der Agent arbeitet gegen eine Spezifikation, Hooks und eine Schranke halten ihn ehrlich, und die Logs sagen Ihnen, was passiert ist.

Entwerfen Sie die Schleife, nicht den Prompt

Hier ist die Denkweise, die alles zusammenhält. Hören Sie auf zu fragen „Was soll ich Claude sagen?“ Beginnen Sie zu fragen „Welche Schleife würde Claude dazu bringen, sich selbst zu sagen?“ Der Agent ist ein schneller Generator ohne verlässliches Gefühl dafür, ob er richtig liegt. Die Schleife liefert dieses Gefühl durch die Schranke. Wir haben dies in Hören Sie auf, Ihren Code-Agenten zu prompten, bauen Sie stattdessen die Schleife ausführlich behandelt, und es ist die tragende Idee für unbeaufsichtigte Arbeit: Die Zuversicht des Modells spielt keine Rolle mehr, nur das Urteil der Schranke zählt.

Deshalb schlägt eine klare Spezifikation auch einen cleveren Prompt. Dieselbe Spezifikation treibt jede Iteration an und dient gleichzeitig als Dokumentation. Eine design.md- oder AGENTS.md-Datei, die Absicht, Einschränkungen und die Definition des Ziels erfasst, gibt dem Agenten bei jedem Lauf ein stabiles Ziel, anstatt dass Sie jedes Mal den Kontext neu erklären müssen.

Ein konkretes Beispiel: unbeaufsichtigte API-Wartung

Machen wir es konkret. Nehmen wir an, Sie möchten einen Workflow, der eine Reihe von API-Endpunkten mit ihrer OpenAPI-Spezifikation synchron hält, jeden Morgen läuft und niemals einen fehlerhaften Endpunkt ausliefert. Hier ist die Struktur.

1. Spezifikation. Der Vertrag lebt in einer OpenAPI-Datei; das Verhalten lebt in Testfällen. Der Agent liest beides zu Beginn des Laufs.
2. Auslöser. Ein Cron-Job um 7 Uhr morgens startet den Headless-Claude mit der Wartungsaufgabe.
3. Generieren. Der Agent gleicht die Implementierung mit der Spezifikation ab: fügt fehlende Endpunkte hinzu, korrigiert nicht übereinstimmende Antwortstrukturen, verschärft die Validierung.
4. Schranke. Der Workflow führt die API-Testsuite gegen den laufenden Dienst aus. Status-Assertions, JSON-Schema-Validierung bei jeder Antwort, Vertragstests gegen die Spezifikation. Fehler kommen strukturiert zurück: „Erwartet 422 bei fehlender customer_id, erhalten 500.“ „Antwortfeld total ist ein String, Schema sagt Zahl.“
5. Schleife oder Eskalation. Rote Schranke? Der strukturierte Fehler wird zum nächsten Prompt, und der Agent behebt die spezifische Lücke, bis zur Iterationsgrenze. Grün? Es öffnet einen PR-Entwurf. Keine Versuche mehr? Es meldet einen Alarm mit dem letzten Fehler und stoppt.
6. Übergabe. Ein Mensch erhält entweder einen sauberen PR zur Überprüfung oder einen präzisen Fehlerbericht. Niemals einen stillen Commit.

Die Schranke in Schritt 4 macht das Ganze sicher für den unbeaufsichtigten Betrieb. Ohne sie bearbeitet der Agent Code und meldet Erfolg basierend auf seiner eigenen Interpretation, genau so gelangen fehlerhafte Endpunkte in die Produktion. Hier passt Apidog in einen autonomen Workflow: das API-Design, das Schema, der Mock-Server und die automatisierten Tests leben in einem Arbeitsbereich, sodass Schranke und Spezifikation standardmäßig synchron bleiben. Sie richten den Lauf auf ein Apidog-Testszenario aus, und der Agent erhält bei jeder Iteration eine Schema-validierte Pass/Fail-Meldung. Der Mock-Server ersetzt Abhängigkeiten, die nicht verfügbar sind, sodass ein 3-Uhr-Morgens-Lauf nicht durch das Warten auf einen unzuverlässigen Drittanbieter blockiert wird. Teams, die den Endpunktzugriff des Agenten über den Apidog AI Agent Debugger verdrahten, lassen ihn Endpunkte auf die gleiche Weise ansteuern und inspizieren, wie es ein menschlicher Tester tun würde. Apidog herunterladen, wenn Sie die Schranke lieber visuell als manuell implementieren möchten.

Leitplanken, die unbeaufsichtigte Läufe sicher machen

Dies ist der Teil, der einen Workflow, dem Sie über Nacht vertrauen, von einem unterscheidet, der Sie um 3 Uhr morgens weckt. Ein unbeaufsichtigter Agent benötigt harte Grenzen, keine guten Absichten.

• Enge Berechtigungs-Allowlists. Im Headless-Betrieb ist die Allowlist Ihre einzige Kontrolle darüber, was der Agent tun kann. Erteilen Sie die minimalen Tools, die die Aufgabe benötigt. Geben Sie einem unbeaufsichtigten Lauf niemals uneingeschränkte Shell- oder destruktive Befehle ohne Sandbox.
• Begrenzte Iterationen. Begrenzen Sie die Schleife. Ein Lauf, der in N Versuchen keine grüne Schranke erreichen kann, sollte stoppen und eskalieren, nicht ewig mahlen.
• Eine Kostenobergrenze. Unbeaufsichtigte Schleifen verbrennen Token, ohne dass ein Mensch es bemerkt. Legen Sie ein Ausgabenlimit fest und protokollieren Sie die Ausgaben pro Lauf. Eine Schleife, die nicht konvergiert, sollte das Limit auslösen und anhalten. Unsere Hinweise zum Reduzieren der Agenten-Token-Kosten gelten hier direkt.
• Schranke schützen. Halten Sie Testdateien und die Spezifikation aus dem Satz von Dateien heraus, die der Agent bearbeiten darf. Wenn er den Test umschreiben kann, um ihn zu bestehen, haben Sie eine Maschine zur Vortäuschung von Fortschritt gebaut.
• Eine Sandbox. Führen Sie unbeaufsichtigte Arbeit in einem isolierten Arbeitsbereich oder Container aus, nicht auf main. Ein Git-Worktree oder ein Einweg-Branch begrenzt den Explosionsradius eines schlechten Laufs.
• Protokollierung und ein Notschalter. Erfassen Sie jeden Lauf in einem Protokoll, das Sie tatsächlich lesen, und halten Sie eine Möglichkeit bereit, einen Job mitten im Flug zu stoppen. Sie können nicht debuggen, was Sie nicht aufgezeichnet haben.
• Menschliche Genehmigung an den Rändern. „Ohne Sie“ bedeutet nicht „ohne jemanden, jemals.“ Platzieren Sie eine Person am Anfang (Aufgabe genehmigen) oder am Ende (PR genehmigen), nur nicht in der inneren Schleife. Die Verdrahtungsmuster und Fehlermodi hier stimmen mit der agentenbasierten Workflow-Tool-Verdrahtung überein.

Die meisten davon laufen auf eine Regel hinaus: Ein unbeaufsichtigter Agent sollte seine Aufgabe erfüllen können und nichts anderes. Beschränken Sie die Tools, begrenzen Sie die Schleife, isolieren Sie den Arbeitsbereich und machen Sie jeden Lauf beobachtbar.

Häufige Fehler

Einige Muster lassen autonome Workflows schnell scheitern.

• Keine Schranke, nur Gefühle. Wenn die einzige Prüfung ist „Agent, bist du fertig?“, haben Sie keinen Workflow, sondern einen unbeaufsichtigten Chatbot. Die Schranke muss extern zum Agenten sein.
• Eine riesige Aufgabe. Ein Lauf, dem gesagt wird, er solle „den gesamten Dienst warten“, konvergiert selten. Zerlegen Sie ihn in Endpunkt-große Aufgaben, jede mit ihrer eigenen Schranke. Kleine Läufe werden fertig; große geraten ins Stocken.
• Weit offene Berechtigungen. Jedes Tool zu gewähren, weil es bequem ist, verwandelt einen kleinen Fehler in einen großen Vorfall, wenn niemand zuschaut. Beschränken Sie die Allowlist streng.
• Stiller Erfolg oder stiller Misserfolg. Ein Workflow, der committet, ohne jemanden zu informieren, oder stirbt ohne Alarm, ist schlimmer als kein Workflow. Immer übergeben.
• Dem Selbstbericht des Modells vertrauen. Der Agent wird sagen, er sei fertig. Die Schranke entscheidet, ob dem so ist. Bauen Sie für die Lücke zwischen „sieht fertig aus“ und „ist fertig“, denn unbeaufsichtigt ist niemand da, um es zu bemerken.

Wenn Sie dies richtig machen, erledigt ein Claude-Workflow die Arbeit eines Tages – begrenzt und verifiziert – bevor Sie Ihren Kaffee getrunken haben. Wenn Sie sie falsch machen, haben Sie die Produktion von selbstbewusstem, ungetestetem Code automatisiert. Der Unterschied liegt in der Schranke und den Leitplanken, nicht im Modell. Wenn Sie die tiefere Architektur wünschen, behandelt unsere Analyse des Agent Harness Designs, wie die Teile in großem Maßstab zusammenpassen.

Das Fazit

Claude-Workflows zu bauen, die ohne Sie ablaufen, dreht sich weniger um Claude und mehr um das System, das Sie darum herum bauen. Fünf Teile tragen die Last: eine präzise Spezifikation, Headless-Ausführung, eine deterministische Verifikationsschranke, harte Leitplanken und eine saubere Übergabe. Machen Sie das richtig, und das Modell wird zu einem schnellen Arbeiter in einer Maschine, die korrekt, begrenzt und beobachtbar ist, wenn Sie nicht hinschauen.

Beginnen Sie mit einem Workflow. Schreiben Sie eine präzise Spezifikation, führen Sie ihn headless gegen eine schnelle Verifikationsschranke aus, erlauben Sie die Tools, begrenzen Sie die Iterationen, isolieren Sie den Arbeitsbereich und lassen Sie sich bei Abschluss oder Fehler benachrichtigen. Für alles, was APIs betrifft, ist Ihre Testsuite die Schranke, die unbeaufsichtigte Läufe sicher macht, und Apidog bietet Ihnen Design, Mocking und automatisierte Tests in einem Arbeitsbereich, um dies zu realisieren. Laden Sie es herunter, verdrahten Sie die Schranke und lassen Sie den Workflow seine Runden drehen, während Sie etwas anderes tun.